That's not completely true. He can set up cross-realm authentication in Kerberos to have AD accept the TGTs and vice-versa. This way, people can use their Unix credentials to access AD resources. There is plenty of documentation on the Microsoft site and on the Internet about setting it up.
<br><br><div><span class="gmail_quote">On 8/23/07, <b class="gmail_sendername">Sean OMeara</b> <<a href="mailto:someara@gmail.com">someara@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Scott:<br><br>If you want TRUE single sign on capabilities and you intend to involve<br>Windows in any way, you absolutely have to use an Active Directory as<br>your kerberos KDC. There is ABSOLUTELY NO WAY around it. (unless of
<br>course you're adventurous enough to use samba4)<br><br>By TRUE sigle sign on I mean:<br>passwordless authentication to network resources (ssh, samba shares/<br>NFSv4 servers, (homedirs!) apache/mod_spnego, jabber/sasl, ssh/gssapi,
<br>ldap/sasl, AFS, the works) from both the XP clients and the linux/unix<br>clients.<br><br>The only way to do it is:<br>authentication<br>*Active Directory KDC + LDAP + RPC for windows authentication/authorization<br>*Active Directory KDC for unixland kerberos authentication
<br><br>authorization<br>* Active Directory ldap server schema extensions (ms SFUv3.5) to house<br>the unix posix data (uid, gid, homedir, shell, supplemental gids<br>((/etc/group))<br><br>or<br>* seperate ldap resource (openldap, fedoraDS) dedicated to housing the
<br>unix posix data<br>* scripting fun to keep your groups in order<br><br>The reason for this lies in the way Windows handles the authorization<br>part of the sign on process. ( unix clients dig their authorization<br>data out of ldap, windows clients have it returned in the PAC field
<br>within their kerberos ticket)<br><br>It's actually not that bad really.... AD can be manipulated from the<br>linux command line via samba tools (net ads user add, net ads group<br>delete, etc)<br><br>......<br><br>
now barring all that... if what you meant by "single sign on" is<br>actually "unified passwords", then you can do it without AD using<br>samba and ldap no problem. (well, only small problems anyway)<br>
<br><br>No matter what you'll have to maintain TWO password databases, one for<br>windows, and one for everyone else.<br><br>The standard configuration for this is one of the two of these:<br><br>a)<br>authentication<br>
* Windows NT4 style NTLMv2 Samba v3 authentication<br>* Samba looks at an ldap backend for:<br>sambaLMPassword:<br>sambaNTPassword:<br><br>* unixland clients attempt a bind to the ldap server, testing against the field:<br>
userPassword<br><br>authorization:<br>Samba looks at an ldap backend for, and then returns to the windows<br>machine via rpc:<br>sambaAcctFlags<br>sambaPrimaryGroupSID:<br>sambaLogonTime:<br>sambaPasswordHistory<br>sambaSID
<br>sambaPwdCanChange:<br>sambaAcctFlags:<br>sambaPwdLastSet:<br>sambaPwdMustChange<br><br>b)<br>authentication:<br>samba stuff for windows<br>unixland looks to an MIT or Heimdal KDC for authentication<br><br>authorization:
<br>same stuff for windows<br>unixland looks in the ldap directory for:<br>uidNumber<br>gidNumber<br>homeDirectory<br>groups information<br><br>The consequences of the dual password sources will boil down to this:<br><br>
When a user changes his password via the unix passwd utility, it will<br>only change:<br>the userPassword field in the ldap record or the password on the<br>kerberos principal.<br><br>Windows users change it via samba, which can call a script to change
<br>both the sambaNTPassword fields and the userPassword fields in the<br>ldap record.<br><br>I'm not sure if its possible to have samba call a script to set the<br>sambaNTPassword and change the kerberos princ.<br><br>
PS if you're going to get kerberos involved in any way, every machine<br>needs to be able to resolve their FQDN, both forward and reverse. This<br>means you either need to maintain lots of /etc/hosts entries in the<br>
form:<br><br><a href="http://127.0.0.1">127.0.0.1</a> localhost localhost.localdomain<br><a href="http://127.0.0.1">127.0.0.1</a> <a href="http://somebox.mit.edu">somebox.mit.edu</a> sombox<br><br>or proper 1 to 1 mapped forward and reverse DNS.
<br><br>If your machine can't correctly do<br>hostname and hostname -f, kerberos will NOT WORK.<br><br>.....<br><br>To answer your questions about the homedirs:<br><br>You want a fileserver running both samba and NFS.
<br>Windows clients will use roaming profiles to mount their homedirs via<br>SMB, linux will use NFS.<br><br>Your error messages look like your ldap server isnt running.<br><br>-s<br><br><br><br>PS I live around the corner from MIT and I'm much better at explaining
<br>things when people buy me ronnie burgers ;)<br><br>-s<br><br><br>On 8/23/07, Scott Ehrlich <<a href="mailto:scott@mit.edu">scott@mit.edu</a>> wrote:<br>> I have a RHEL5 Server and some dual-boot XP/CentOS 5 systems (Linux systems all
<br>> 64-bit). All Linux is out-of-box, with all packages, minus international<br>> languages, installed. No patching has been done.<br>><br>> On the server, I selected system-config-authentication and enabled LDAP for
<br>> User Information, Kerberos, LDAP, and SMB for Authentication, and Shadow and<br>> MD5 Passwords, along with Authenticate system accounts by network services for<br>> Options.<br>><br>> All machines are on an isolated LAN, with no DNS server (I could always enable
<br>> and configure DNS on the server if it helps the cause).<br>><br>> I also don't know if it matters, but the server is running the virtualization<br>> kernel (xen), but the clients are not.<br>><br>
> I only have LDAP service enabled on the server. Kerberos services are enabled<br>> on both client and server.<br>><br>> I tweaked the LDAP and Kerberos settings using the CentOS/RH GUIs, and have the<br>> clients looking to the RH box for authentication.
<br>><br>> I also have the firewall enabled, but am letting kerberos and ldap ports<br>> through as tcp.<br>><br>> During a login test, /var/log/messages on the client showed:<br>><br>> lin1 gdm[pid]: nss_ldap: failed to bind to LDAP server ldap://192.168.1.100:
<br>> Can't contact LDAP server<br>><br>> lin1 gdm[pid]: nss_ldap: reconnecting to LDAP server (sleeping 32 seconds)...<br>><br>> lin1 dbus-daemon: nss_ldap: failed to bind to LDAP server ldap://192.168.1.100:
<br>> Can't contact LDAP server<br>><br>> lin1 dbus-daemon: dss_ldap: failed to bind to LDAP server...<br>><br>> lin1 xfs: ...<br>><br>><br>> During boot time, Starting system message bus: [long pause] then error messages
<br>> about DB_CONFIG and /var/lib/ldap, the usual cannot find DB_CONFIG in<br>> /var/lib/ldap, showing the <a href="http://example.com">example.com</a> instead of my customized ldap settings,<br>> etc.<br>><br>
> I've checked <a href="http://openldap.org">openldap.org</a>, but I figured if the configuration appears to be<br>> simplified via an included GUI, I shouldn't have much trouble gettigns things<br>> going.
<br>><br>> Anyway, what am I missing? Anything special RH 5 is doing compared to the<br>> openldap docs?<br>><br>> Both servers have been rebooted since adding the respective ports in the<br>> firewall.
<br>><br>> The goal is a to permit my test user, created on the server, to sit at a<br>> workstation, boot into either Linux or XP, and get their home directory.<br>><br>> Ideally, the server only needs to consist of one account for them, which they
<br>> get upon login on the workstation.<br>><br>> I want to highly restrict _any_ third-party tools/apps/etc. I will be happy<br>> to take suggestions and leads, but I want to try and rely on what RH has<br>
> provided.<br>><br>> Thanks for any insight/help.<br>><br>> Scott<br>><br>> _______________________________________________<br>> bblisa mailing list<br>> <a href="mailto:bblisa@bblisa.org">bblisa@bblisa.org
</a><br>> <a href="http://www.bblisa.org/mailman/listinfo/bblisa">http://www.bblisa.org/mailman/listinfo/bblisa</a><br>><br><br>_______________________________________________<br>bblisa mailing list<br><a href="mailto:bblisa@bblisa.org">
bblisa@bblisa.org</a><br><a href="http://www.bblisa.org/mailman/listinfo/bblisa">http://www.bblisa.org/mailman/listinfo/bblisa</a><br></blockquote></div><br>