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 _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"