Ticket #200 (new defect)

Opened 15 years ago

Last modified 12 years ago

Investigate moving to LDAP for user management

Reported by: broder Owned by:
Priority: normal Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:


Anyone who's involved in more than 2 crusty student groups starts getting punted from groups in Hesiod, and Murphy dictates that you get punted from the groups you want to key on for ACLs.

We should figure out something else to use as a group database (LDAP?), or what needs to be modified to make something else usable as a group database.

Change History

comment:1 Changed 15 years ago by jdreed

From athena10[1715]:

I talked with Richard Edelson about this at the end of IAP. He said that as far as he knew, the LDAP servers definitely knew about moira GIDs, so it was probably a matter of just figuring out how to do it. So the next step is that some debathena-dev folks should find a time to sit down with Richard (and possibly a few other people) and hash out what Debathena needs and how we can get it. Bill and/or I can probably help with facilitating this meeting.

comment:2 Changed 15 years ago by jdreed

  • Priority changed from critical to major
  • Milestone set to IAP 2010

comment:3 Changed 15 years ago by broder

I finally took a stab at the LDAP configuration. Here's what I have so far to add to /etc/ldap.conf:

host ldap-dev-1.mit.edu
ssl on
base dc=mit,dc=edu

pam_member_attribute member
nss_base_passwd ou=users,ou=moira,?one
nss_base_group ou=lists,ou=moira,?one
nss_map_objectclass posixGroup group
nss_map_attribute uniqueMember member

It doesn't quite work, because nss_ldap tries to use a memberUid field in addition to the member field when querying group membership, and ldap-dev-1.mit.edu seems to reject any queries that include memberUid. I've e-mailed mark to ask if he can change that configuration.

comment:4 Changed 14 years ago by broder

I've made some major progress on this by replacing "hesiod" with "ldap" in /etc/nsswitch.conf and using libnss-ldapd + nslcd instead of libnss-ldap.

Brief aside: libnss-ldap does NSS resolutions through LDAP by running the queries directly in the context of the user doing the NSS lookup. libnss-ldapd does NSS resolutions through LDAP by bouncing the queries off to a persistently running daemon, nslcd, which bounces the results back. nslcd does not do any caching of results - it leaves that responsibility to nscd.

The necessary configuration to nss-ldapd is very straightforward. Here's what needs to go into /etc/nss-ldapd.conf:

uri ldap://ldap-dev-1.mit.edu/
base dc=mit,dc=edu
scope one
base   group  ou=lists,ou=moira,dc=mit,dc=edu
base   passwd ou=users,ou=moira,dc=mit,dc=edu
tls_reqcert demand
filter passwd (objectClass=posixAccount)
filter group (&(objectClass=group)(gidNumber=*))
map group uniqueMember member
uid nslcd
gid nslcd

Right now, nss-ldapd works for passwd lookups:

root@login-test:~# getent passwd broder
broder:x:41803:65534:Evan Broder:/afs/athena.mit.edu/user/b/r/broder:/bin/athena/bash

However, mark reverted the change that allowed me to query membership and GIDs of NFS groups unauthenticated, so I can't do group lookups.

I can reconfigure nslcd to use my tickets, so I know it's possible to make it work.

However, it is slow - slow on the order of a several seconds to do all the necessary queries to handle a login. We need a caching solution, and nscd won't cut it. See also #486

comment:5 Changed 14 years ago by geofft

  • Milestone changed from IAP 2010 to Summer 2010

We're not going to get this done by the end of IAP, since it requires a lot of work to make it sufficiently performant and a fair amount of testing.

comment:6 Changed 14 years ago by jdreed

  • Milestone changed from Summer 2010 (Lucid Deploy) to The Distant Future

comment:7 Changed 13 years ago by jdreed

  • Summary changed from Hesiod makes a crappy group database to Investigate moving to nss_ldap
  • Milestone changed from The Distant Future to Natty Beta

comment:8 Changed 13 years ago by jdreed

  • Summary changed from Investigate moving to nss_ldap to Investigate moving to LDAP for user management

comment:9 Changed 13 years ago by jdreed

  • Milestone changed from Natty Beta to Fall 2011

comment:10 Changed 13 years ago by geofft

ldap-dev-1 is firewalled from off-campus, which makes it effectively useless for private machines, laptops, etc. (In order for logins to work, the computer need to be able to get name service information before prompting the user for authentication...)

comment:11 Changed 12 years ago by jdreed

  • Milestone changed from Precise Beta to The Distant Future

comment:12 Changed 12 years ago by andersk

I think it’s dumb to firewall the LDAP servers from off campus; surely at least authenticated+encrypted access should be allowed. However, if that isn’t going to change, can we at least make sure that the firewall gracefully REJECTs packets instead of DROPping them on the floor, so that off-campus clients don’t hang waiting for a timeout?

Note: See TracTickets for help on using tickets.