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
