freebsd6 authenticating against openldap 2.4?

[Jonathan McKeown]

Hi Dave

If you don't mind I'm going to reply on-list in case anyone else has
comments. I might also teach you to suck eggs, a bit, because, not
knowing your setup or experience level, I'm going to start a bit
further back than your initial question, and mention a few things that
I either think are important, or found useful to have in place. This
is a long message, but I think it covers most of the things that
tripped me up.

You're going to be installing a number of ports/packages on all your
machines to get LDAP authentication working. When I took over my
current post, every server had its own source tree, its own ports
tree, and just in terms of base OS we were running everything from
4.7-RELEASE to 5.3-RELEASE, including a couple of boxes running STABLE
snapshots. Every box was configured differently and ports trees had
been installed/updated more or less at random.

I now have a fast box with a ports tree and source tree, both
initially created with cvsup/csup (otherwise you can run into trouble
with cvsup not deleting files because it didn't create them). It
builds every kernel configuration I need, and the source, object and
ports trees are NFS-mountable on all my other servers. All machines
are configured to look for packages on my build server only, and
whenever I build a port for the first time, I build a package from it
which is written back to the build server. I also have a standard
``base'' server buildout which includes portupgrade, lynx, bash, sudo,
and the LDAP stuff, among others.

If you've got something like this in place, you can start planning
your LDAP migration. The first thing is to decide what else you're
going to use LDAP for so you can plan your directory. The painful
mistake to avoid is to do with the class of the objects in your
directory. There are two types of objectClass, structural and
auxiliary, and although an object can belong to several auxiliary
classes, it can only be in one structural class: if you pick the wrong
one it's a pain to recover.

My user accounts have a structural objectClass of inetOrgPerson, and
auxiliaries of posixAccount and extensibleObject (the last is to allow
me to use the host: attribute, of which more later). I'm currently
able to run shell accounts on different boxes on a per-user basis,
SMTP AUTH with sendmail, and user authentication for Cyrus IMAP and
squirrelmail, among other things, from the user account information,
and I'm working on using LDAP for maps in sendmail.

The other thing you need to watch out for, both before the migration
and on an ongoing basis afterwards, is user account numbers. There are
two problems. First of all, you have to make sure that each user is
able to have the same uid number on every machine.

The second and in some ways more difficult problem is what I call NPCs
- accounts which don't correspond to a human user because they were
created by ports. Some of these have reserved numbers but most simply
use pw useradd to create a new user. If you haven't planned for this
you can find that the same uid number represents one user on one host,
a different user on another host, and an NPC account such as dhcpd on
a third.

I renumbered all my accounts, both user and NPC, so that real users
start at 1100 for my primary site, 1200, 1300 and so on on my other
sites, and NPC accounts are 1000-1099. To make sure this stays the
case, I create /etc/pw.conf on every machine, containing:

reuseuids yes
reusegids yes

to use the lowest currently-unused uid number. Otherwise each time you
install a port, it picks a uid number one higher than the highest
currently in use, which screws up your numbering again.

It's seriously worth getting all this right before you start
implementing LDAP - once you've done so, LDAP itself is relatively
straightforward.

You need OpenLDAP itself - I'm not sure what the differences are
between 2.3 and 2.4 but 2.3 works for me - plus nss_ldap and
pam_ldap, both of which are in the ports tree. Create your user
accounts, configure pam_ldap and nss_ldap, and make a few changes in
/etc/pam.d and /etc/nsswitch.conf. These are the easy bits!

Some last considerations: you can use the host: attribute in user
accounts to limit which hosts each user can log in to, and you can
install an additional port, pam_mkhomedir, which will create the home
directory on login on each host, if you want local homedirs rather
than an NFS mount.

You will also find that users can't change their LDAP password through
the normal channels. Although passwd(1) was rewritten a few years ago
to be able to use PAM, the necessary code is diked out.

Another issue which has come up on the list a few times: your LDAP
server(s) is/are going to need some tweaking because there is a
chicken-and-egg problem during booting. Before the system can use an
account, it has to enumerate every group that account belongs to to
make sure the right privileges are available. If you're starting the
LDAP server as user ldap, the system tries to consult all the sources
of group information, which in an LDAP-enabled system is /etc/passwd,
/etc/group and the LDAP server - which isn't running yet. If you find
your LDAP server takes anything up to 5 minutes to boot, this is why -
it's waiting for a reply from the LDAP server before it can start the
LDAP server. Off the top of my head, I think setting bind_policy to
soft in nss_ldap.conf reduces this time.

Feel free to come back to me on- or off-list for more details on any
of the above - just bear in mind I'm in South Africa which is seven
hours ahead of Eastern Time - which may affect how quickly I can
respond.

Jonathan