[991] in athena10
Re: nss: hesiod -> ldap for groups?
daemon@ATHENA.MIT.EDU (Quentin Smith)
Mon Jan 26 18:51:44 2009
Date: Mon, 26 Jan 2009 18:50:20 -0500 (EST)
From: Quentin Smith <quentin@MIT.EDU>
To: Geoffrey Thomas <geofft@mit.edu>
cc: Jonathan Reed <jdreed@mit.edu>, Evan Broder <broder@mit.edu>,
athena10@mit.edu
In-Reply-To: <alpine.DEB.2.00.0901261623420.5605@vinegar-pot.mit.edu>
Message-ID: <Pine.LNX.4.64L.0901261846590.4790@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Mon, 26 Jan 2009, Geoffrey Thomas wrote:
>> Based on several hallway conversations, I will make the assertion that NFS
>> groups should be considered legacy in the Athena 10 world, and that we
>> should move forward with getting group information from somewhere like AD.
>
> Hm, I'm not familiar with MIT's AD setup. Is the LDAP server win.mit.edu, or
> something else? I'm not sure how to bind to it to query and poke at it;
> there's no ldap/win.mit.edu keytab, and it seems not to accept simple
> authentication (-x).
I think that we're confusing things by mentioning AD; there are two LDAP
servers that are run by Network. One is ldap.mit.edu, which does support
Kerberos authentication. The other is the LDAP servers that are part of
the WIN.MIT.EDU Active Directory domain, which are found with host -t srv
_ldap._tcp.win.mit.edu:
_ldap._tcp.win.mit.edu has SRV record 0 100 389 m24dc2.WIN.MIT.EDU.
_ldap._tcp.win.mit.edu has SRV record 0 100 389 w92dc2.WIN.MIT.EDU.
_ldap._tcp.win.mit.edu has SRV record 0 100 389 w92dc1.WIN.MIT.EDU.
I think it would be better for us to use the ldap.mit.edu servers and not
add a dependency on the WIN.MIT.EDU domain for Athena 10.
I believe the current blocker on using ldap.mit.edu for group information
is that the group entries in the LDAP server are not of objectClass
"posixGroup", i.e., they do not have a gid associated with them.
> I completely agree with the concept of deprecating "NFS groups", i.e., Hesiod
> groups. I'm curious if we can do the same thing for other Hesiod
> dependencies, since LDAP as a technology is in general better supported by
> the Real World than Hesiod. It appears that autofs (which we no longer use,
> but...) even supports automount maps in LDAP as well as in Hesiod.
I would caution you that LDAP is more heavyweight than Hesiod, and as I
think you are aware, much more complex.
--Quentin
