What I meant by "sniffed kerberos passwords" was "sniffed kerberos exchanges" You can still run an offline dict/brute force on it.
http://www.google.com/search?hl=en&q=kerberos+%22looks+like+a+timestamp%22&btnG=Search turning off forwardable tickets is annoying only if you've every been used to having them! %99.99r users wont notice or care that they're off. And yes, winbind is the devil. =) -s On 8/23/07, Joshua Putnam <[EMAIL PROTECTED]> wrote: > I'm not sure what you mean by "sniffed kerberos passwords." Kerberos > never places any passwords on the wire, encrypted or not, so how would > you sniff them? > > I've done extensive testing of both home-rolled AD authentication to > Unix and Commercial products (Centrify, Vintela Authentication Services, > aka. VAS). The home-rolled solutions are cumbersome to implement and > require patches/changes to system libraries, which may not be a problem > in production environments but is unacceptable in most development > environments. Home rolled solutions, depending on pam_nss, are also not > available for some older Unix platforms. > > The biggest gotcha is the vulnerability of forwardable Kerberos tickets > to theft by any user with root priviledges. If a user has root, they > can steal any other user's ticket cache from /tmp or the user's homedir > on a Unix system and use it to impersonate that user anywhere else on > the network. But with forwardable tickets disabled (from the AD domain > controller), single-sign on will only work from a Windows client to the > first Unix box. A user will not be able to then single-sign on to a > second Unix box from there. > > SAMBA/Winbind also has significant limitations on the assignment of > consistent UIDs on multiple Unix/Linux hosts. > > Of course, you could audit the Unix boxes with forwardable tickets from > another, secure system, to see if anyone is abusing the tickets. > > :) > > Joshua Putnam > Sr. Unix Administrator > Intersystems Corporation > 1 Memorial Drive > Cambridge, MA 02142 > > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Sean OMeara > Sent: Thursday, August 23, 2007 10:09 AM > To: Scott Ehrlich > Cc: [email protected] > Subject: Re: [BBLISA] Single sign-on help requested > > Also the use of NTLM makes sniffed passwords extremly easy to crack > using rainbow tables > > http://www.antsight.com/zsl/rainbowcrack/ > > sniffed kerberos passwords are still vulnerable to an offline > dictionary/brute force attack, but you you cant use the neato time/space > tradeoff like you can on ntlm > > > On 8/23/07, Sean OMeara <[EMAIL PROTECTED]> wrote: > > To paraphrase my previous post: > > > > 1) It's not true single sign on, only unified passwords > > > > 2) the passwords will fall out of sync between the windows and linux > > side unless they're changed from windows > > > > > > On 8/23/07, Scott Ehrlich <[EMAIL PROTECTED]> wrote: > > > Sorry to top-post, but it is my intention to use samba on the RH 5 > > > box to act as my domain controller. I thought I read somewhere that > > > > accounts > > > (user/pass) can be easily synced ldap and samba, including home > > > dirs? Am I wrong? > > > > > > Thanks. > > > > > > Scott > > > > > > On Thu, 23 Aug 2007, Sean OMeara wrote: > > > > > > > Scott: > > > > > > > > If you want TRUE single sign on capabilities and you intend to > > > > involve Windows in any way, you absolutely have to use an Active > > > > Directory as your kerberos KDC. There is ABSOLUTELY NO WAY around > > > > it. (unless of course you're adventurous enough to use samba4) > > > > > > > > By TRUE sigle sign on I mean: > > > > passwordless authentication to network resources (ssh, samba > > > > shares/ > > > > NFSv4 servers, (homedirs!) apache/mod_spnego, jabber/sasl, > > > > ssh/gssapi, ldap/sasl, AFS, the works) from both the XP clients > > > > and the linux/unix clients. > > > > > > > > The only way to do it is: > > > > authentication > > > > *Active Directory KDC + LDAP + RPC for windows > > > > authentication/authorization *Active Directory KDC for unixland > > > > kerberos authentication > > > > > > > > authorization > > > > * Active Directory ldap server schema extensions (ms SFUv3.5) to > > > > house the unix posix data (uid, gid, homedir, shell, supplemental > > > > gids > > > > ((/etc/group)) > > > > > > > > or > > > > * seperate ldap resource (openldap, fedoraDS) dedicated to housing > > > > > the unix posix data > > > > * scripting fun to keep your groups in order > > > > > > > > The reason for this lies in the way Windows handles the > > > > authorization part of the sign on process. ( unix clients dig > > > > their authorization data out of ldap, windows clients have it > > > > returned in the PAC field within their kerberos ticket) > > > > > > > > It's actually not that bad really.... AD can be manipulated from > > > > the linux command line via samba tools (net ads user add, net ads > > > > group delete, etc) > > > > > > > > ...... > > > > > > > > now barring all that... if what you meant by "single sign on" is > > > > actually "unified passwords", then you can do it without AD using > > > > samba and ldap no problem. (well, only small problems anyway) > > > > > > > > > > > > No matter what you'll have to maintain TWO password databases, one > > > > > for windows, and one for everyone else. > > > > > > > > The standard configuration for this is one of the two of these: > > > > > > > > a) > > > > authentication > > > > * Windows NT4 style NTLMv2 Samba v3 authentication > > > > * Samba looks at an ldap backend for: > > > > sambaLMPassword: > > > > sambaNTPassword: > > > > > > > > * unixland clients attempt a bind to the ldap server, testing > against the field: > > > > userPassword > > > > > > > > authorization: > > > > Samba looks at an ldap backend for, and then returns to the > > > > windows machine via rpc: > > > > sambaAcctFlags > > > > sambaPrimaryGroupSID: > > > > sambaLogonTime: > > > > sambaPasswordHistory > > > > sambaSID > > > > sambaPwdCanChange: > > > > sambaAcctFlags: > > > > sambaPwdLastSet: > > > > sambaPwdMustChange > > > > > > > > b) > > > > authentication: > > > > samba stuff for windows > > > > unixland looks to an MIT or Heimdal KDC for authentication > > > > > > > > authorization: > > > > same stuff for windows > > > > unixland looks in the ldap directory for: > > > > uidNumber > > > > gidNumber > > > > homeDirectory > > > > groups information > > > > > > > > The consequences of the dual password sources will boil down to > this: > > > > > > > > When a user changes his password via the unix passwd utility, it > > > > will only change: > > > > the userPassword field in the ldap record or the password on the > > > > kerberos principal. > > > > > > > > Windows users change it via samba, which can call a script to > > > > change both the sambaNTPassword fields and the userPassword fields > > > > > in the ldap record. > > > > > > > > I'm not sure if its possible to have samba call a script to set > > > > the sambaNTPassword and change the kerberos princ. > > > > > > > > PS if you're going to get kerberos involved in any way, every > > > > machine needs to be able to resolve their FQDN, both forward and > > > > reverse. This means you either need to maintain lots of /etc/hosts > > > > > entries in the > > > > form: > > > > > > > > 127.0.0.1 localhost localhost.localdomain > > > > 127.0.0.1 somebox.mit.edu sombox > > > > > > > > or proper 1 to 1 mapped forward and reverse DNS. > > > > > > > > If your machine can't correctly do hostname and hostname -f, > > > > kerberos will NOT WORK. > > > > > > > > ..... > > > > > > > > To answer your questions about the homedirs: > > > > > > > > You want a fileserver running both samba and NFS. > > > > Windows clients will use roaming profiles to mount their homedirs > > > > via SMB, linux will use NFS. > > > > > > > > Your error messages look like your ldap server isnt running. > > > > > > > > -s > > > > > > > > > > > > > > > > PS I live around the corner from MIT and I'm much better at > > > > explaining things when people buy me ronnie burgers ;) > > > > > > > > -s > > > > > > > > > > > > On 8/23/07, Scott Ehrlich <[EMAIL PROTECTED]> wrote: > > > >> I have a RHEL5 Server and some dual-boot XP/CentOS 5 systems > (Linux systems all > > > >> 64-bit). All Linux is out-of-box, with all packages, minus > international > > > >> languages, installed. No patching has been done. > > > >> > > > >> On the server, I selected system-config-authentication and > > > >> enabled LDAP for User Information, Kerberos, LDAP, and SMB for > > > >> Authentication, and Shadow and > > > >> MD5 Passwords, along with Authenticate system accounts by network > > > > >> services for Options. > > > >> > > > >> All machines are on an isolated LAN, with no DNS server (I could > > > >> always enable and configure DNS on the server if it helps the > cause). > > > >> > > > >> I also don't know if it matters, but the server is running the > > > >> virtualization kernel (xen), but the clients are not. > > > >> > > > >> I only have LDAP service enabled on the server. Kerberos > services are enabled > > > >> on both client and server. > > > >> > > > >> I tweaked the LDAP and Kerberos settings using the CentOS/RH > > > >> GUIs, and have the clients looking to the RH box for > authentication. > > > >> > > > >> I also have the firewall enabled, but am letting kerberos and > > > >> ldap ports through as tcp. > > > >> > > > >> During a login test, /var/log/messages on the client showed: > > > >> > > > >> lin1 gdm[pid]: nss_ldap: failed to bind to LDAP server > ldap://192.168.1.100: > > > >> Can't contact LDAP server > > > >> > > > >> lin1 gdm[pid]: nss_ldap: reconnecting to LDAP server (sleeping 32 > seconds)... > > > >> > > > >> lin1 dbus-daemon: nss_ldap: failed to bind to LDAP server > ldap://192.168.1.100: > > > >> Can't contact LDAP server > > > >> > > > >> lin1 dbus-daemon: dss_ldap: failed to bind to LDAP server... > > > >> > > > >> lin1 xfs: ... > > > >> > > > >> > > > >> During boot time, Starting system message bus: [long pause] then > > > >> error messages about DB_CONFIG and /var/lib/ldap, the usual > > > >> cannot find DB_CONFIG in /var/lib/ldap, showing the example.com > > > >> instead of my customized ldap settings, etc. > > > >> > > > >> I've checked openldap.org, but I figured if the configuration > > > >> appears to be simplified via an included GUI, I shouldn't have > > > >> much trouble gettigns things going. > > > >> > > > >> Anyway, what am I missing? Anything special RH 5 is doing > compared to the > > > >> openldap docs? > > > >> > > > >> Both servers have been rebooted since adding the respective ports > > > > >> in the firewall. > > > >> > > > >> The goal is a to permit my test user, created on the server, to > > > >> sit at a workstation, boot into either Linux or XP, and get their > home directory. > > > >> > > > >> Ideally, the server only needs to consist of one account for > > > >> them, which they get upon login on the workstation. > > > >> > > > >> I want to highly restrict _any_ third-party tools/apps/etc. I > will be happy > > > >> to take suggestions and leads, but I want to try and rely on what > > > > >> RH has provided. > > > >> > > > >> Thanks for any insight/help. > > > >> > > > >> Scott > > > >> > > > >> _______________________________________________ > > > >> bblisa mailing list > > > >> [email protected] > > > >> http://www.bblisa.org/mailman/listinfo/bblisa > > > >> > > > > > > > > > > > _______________________________________________ > bblisa mailing list > [email protected] > http://www.bblisa.org/mailman/listinfo/bblisa > _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
