Differences between version 10 and revision by previous author of LDAPAuthentication.
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
| Newer page: | version 10 | Last edited on Sunday, March 9, 2003 7:34:47 pm | by DanielLawson | Revert |
| Older page: | version 1 | Last edited on Friday, February 28, 2003 11:39:18 am | by NeilHoughton | Revert |
@@ -34,10 +34,10 @@
Seemed to work for me, or at least, it stopped the migration script from barfing halfway through.
You also want to make sure you've got the correct ACLs. Something like this is required to let the admin see the shadowed crypted passwords, and nobody else:
- access to attribute=userPassword,ntPassword,lmPassword,pwdlastset,shadowlastcha
- by dn="cn=admin,o
=niche
,c
=nz" write
+ access to attribute=userPassword
+ by dn="cn=admin,dc=wlug,dc
=org
,dc
=nz" write
by anonymous auth
by self write
by * none
@@ -45,9 +45,9 @@
__Migrating your Configuration__
Once slapd is up and running, after choosing a sensible base dn and so on (this is beyond the scope of this document -- does someone want to wiki setting up slapd? or I'll do it later), it's time to migrate your existing files. This is easiest done by using PADL's excellent MigrationTools. See http://www.padl.com/OSS/MigrationTools.html for them, or simply apt-get install migrationtools if you're lucky enough to be running Debian.
-Edit your migration_common.ph file and enter in the values appropriate for your setup. Under Debian, it'll be in /usr/share/migrationtools. You'll want to pay attention to any gids/uids you want to ignore. It's probably a good idea to ignore 'system' users and groups. The defaults in Debian are users below 1000 (probably a good idea) and groups below 100. However, I have several groups I would consider 'system' groups (netsaint, etc, among others) at 101, 102... user groups don't start until 1000. So I suggest ignoring groups below 1000. Greig says this is inclusive, so maybe ignore below 999. Another issue I had was that if I tell it to ignore ANY groups, it ignores ALL the groups, so my groups ended up empty on my LDAP server. I had to tell it to ignore none and delete the ones I didn't want manually. Greig says this works for him under Woody and RH, but it certainly didn't work for me. [YMMV].
+Edit your migration_common.ph file and enter in the values appropriate for your setup. Under Debian, it'll be in /usr/share/migrationtools. You'll want to pay attention to any gids/uids you want to ignore. It's probably a good idea to ignore 'system' users and groups. The defaults in Debian are users below 1000 (probably a good idea) and groups below 100. However, I have several groups I would consider 'system' groups (netsaint, etc, among others) at 101, 102... user groups don't start until 1000. So I suggest ignoring groups below 1000. Greig says this is inclusive, so maybe ignore below 999. Another issue I had was that if I tell it to ignore ANY groups, it ignores ALL the groups, so my groups ended up empty on my LDAP server (''This is to do with a bug in the migration script, which I'm surprised didn't leap out at you straight away. It was comparing the higher and lower GID settings with a variable called $uid -- which didn't exist. $gid was the one it was reading from the group file. This has been fixed in unstable, but its not in stable (woody) nor ever will be I think -- DanielLawson'')
. I had to tell it to ignore none and delete the ones I didn't want manually. Greig says this works for him under Woody and RH, but it certainly didn't work for me. [YMMV].
After you've configured this, run the script migrate_all_online.sh and let the tools do all the work. I had a few hiccups here, but that was mainly due to slapd being horribly misconfigured. If you have any problems you can't find solutions to, it's probably a good idea to restart slapd several times, or simply stop it for a while, and try again. I don't really know why, but this seemed to fix some of my problems magically.
__Setting up PAM__
@@ -75,9 +75,9 @@
base o=niche,c=nz
ldap_version 3
scope sub
-Note the lack of rootbinddn, nss doesn't need to bind as admin. Note, however, that if this file is readable only by root, users won't be able to resolve anything! As a solution, you can either install [
nscd]
, a caching daemon which runs as root (this is a good idea anyway, see later) or set this file world readable.
+Note the lack of rootbinddn, nss doesn't need to bind as admin. Note, however, that if this file is readable only by root, users won't be able to resolve anything! As a solution, you can either install nscd(8)
, a caching daemon which runs as root (this is a good idea anyway, see later) or set this file world readable.
Now that that's done, you probably want to edit /etc/nsswitch.conf and tell it to look at your LDAP server by default. This is done easily enough, change the lines:
passwd: compat
@@ -105,5 +105,73 @@
So once you can telnet to the pop3 port and log on with pop3 against LDAP, start shifting some other services over, and test them as you go. Note that ssh likes to be restarted after you change it's pam.d file, this caught me out. Be careful shifting things like 'login' over. :)
__The End__
-And that's it! After the services you want to use are shifted over, you're now running a system authenticating off LDAP. Delete your local users and leave the LDAP ones there. Don't delete user root, and don't put root on the LDAP server. It's probably not a good idea. Things may be going a little slowly, so you might want to install [
nscd]
to speed things up, as it caches all ldap requests. To set up other machines to authenticate off this server, just perform the steps from "Setting up PAM" and onwards on the other machine, but using the IP of your real LDAP server instead of 127...1 (obviously).
+And that's it! After the services you want to use are shifted over, you're now running a system authenticating off LDAP. Delete your local users and leave the LDAP ones there. Don't delete user root, and don't put root on the LDAP server. It's probably not a good idea. Things may be going a little slowly, so you might want to install nscd(8)
to speed things up, as it caches all ldap requests. To set up other machines to authenticate off this server, just perform the steps from "Setting up PAM" and onwards on the other machine, but using the IP of your real LDAP server instead of 127...1 (obviously).
+
+__Troubleshooting__
+
+1) Everything is working fine, but any authentication I do is REALLY slow. I expected some slowdown, but not this. What's wrong with my machine?
+
+Actually, there isn't really any slowdown when using LDAP for authentication, even on very slow machines. I had this problem, and eventually discovered it was because I had turned loglevel up to around 40 in slapd.conf, which was causing pages of logs to spew out every time I touched the server, reducing it to running like a dog or some other slow running animal. Turn the logging off once you have everything working, and it's fine.
+
+2) How can I tell if I'm really pulling information out of LDAP?
+
+Make sure you have a user entry, or group entry, that is only in LDAP. Removing a user or group from your /etc/passwd or /etc/group is a good way of ensuring this. As said before, do NOT remove root.
+
+Verify the user doesn't exist in /etc/passwd
+ # cat /etc/passwd | grep daniel
+ #
+
+Now use getent to check that nsswitch can see the user
+ # getent passwd daniel
+ daniel:x:1000:1000:Daniel Lawson (LDAP):/home/daniel:/bin/bash
+ #
+
+So this verifies that nsswitch can see the user. As long as you have your pam setup appropriately, you should be able to login as this user
+
+3) I can't access protocols / services / host / ethers / etc information after I migrated to LDAP / libnss_ldap
+
+EG: you can't do telnet hostname imap, you have to use the numeric port. Or you can't ping - it says unknown protocol icmp (see CommonErrors)
+
+You (or your system package manager when you installed libnss_ldap) have probably told /etc/nsswitch.conf that your LDAP server is authoritative for these, whereas in fact its not. Remove the bits for these databases that pertain to LDAP, and you should be fine. Or, set up the protocols / services / hosts / ethers or what have you groups in the LDAP tree correctly. Duh!)
+
+
+!!!RedHat Specific
+
+This assumes you've migrated at least your /etc/{passwd,group,shadow} files into working LDAP server and can browse this information using a client like gq (http://biot.com/gq/)
+
+Configuring clients to authentication off your [LDAP] server is pretty easy. Just run authconfig and select LDAP where nessessary and enter in your server settings. It is advisable to enable TLS as without it passwords are sent over your network in clear text.
+
+The only "tweak" I made was to edit /etc/pam_ldap.conf to have the "pam_password" attribute set to "exop". In my experiementation I could only get the "clear", "crypt", and "exop" pam_password methods working. MD5 always failed. I think it might have had something to do with the way OpenLDAP & GQ were interacting when setting passwords encoded with MD5 tho. You might have better luck. Anyway when you use "pam_password exop" and then use passwd(1) to set your passwords in the LDAP directory they are stored encrypted using the very secure SSHA algorythm.
+
+__Note:__ I think I discovered a bug in authconfig. If you run it multiple times it can bugger up you /etc/pam.d/system-auth file. It appears to append lines to the end of existing configurations. So you end up with lines like this:
+
+ password sufficient /lib/security/pam_ldap.so use_authtokpassword sufficient /lib/security/pam_ldap.so
+
+This is bad. You need to make sure your system-auth file is properly setup. It should look like this:
+
+ auth required /lib/security/pam_env.so
+ auth sufficient /lib/security/pam_unix.so likeauth nullok
+ auth sufficient /lib/security/pam_ldap.so use_first_pass
+ auth required /lib/security/pam_deny.so
+
+ account required /lib/security/pam_unix.so
+ account [[default=ok user_unknown=ignore service_err=ignore system_err=ignore] /lib/security/pam_ldap.so
+
+ password required /lib/security/pam_cracklib.so retry=3
+ password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow
+ password sufficient /lib/security/pam_ldap.so use_authtok
+ password required /lib/security/pam_deny.so
+
+ session required /lib/security/pam_limits.so
+ session required /lib/security/pam_unix.so
+ session optional /lib/security/pam_ldap.so
+
+Be aware that if you edit this file it is likely to be overwritten the next time you run authconfig.
+
+Authconfig also edits your /etc/nsswitch.conf file to enable looking up users and groups via LDAP. You shouldn't need to edit this file unless you also want to add things like aliases, networks, and ethers etc into your LDAP tree.
+
+
+!!!SASL Notes
+
+If you are using any tools that link against libsasl (and openldap2 is one of them, by default), and are trying to use any services that also link against libsasl, you'll probably run into an issue where the calling application (eg, Cyrus IMAPd) dies with SIGSEGV (SIG11, Segmentation Fault). This is to do with a non-rentrant bug in libsasl. See [SASLNotes] for more information
