There are some lose ends in the openldap documentation at <http://www.gentoo.org/doc/en/ldap-howto.xml> w. regard to PAM integration. Configuring ldap support for pam according to the directions in the HOWTO, I couldn't update passwords, either as root or as a nom-priv user. Trying to do so resulted in the following error (or one of several similar errors): $ passwd Enter login(LDAP) password: New UNIX password: Retype new UNIX password: New password: Re-enter new password: LDAP password information update failed: Unknown error entry modify failed passwd: Permission denied I made a few changes which were not documented, and managed to make password updates work, however there are still problems. The critical piece appears to be the inclusion of specific write access for root in the AC spec in /etc/openldap/slapd.conf, so now I have: access to * by dn="uid=root,ou=people,dc=fmp,dc=com" write by self write by users read by anonymous auth Without this addition, nothing else I tried would work. Appending code listing 4.1 to /etc/pam.d/system-auth won't work, since the existing standard gentoo system-auth contains several module-types with a 'sufficient' control-flag which, should module execution succeed, preempts further consideration of modules for the same module-type, including the ldap modules. Putting the suggested lines at different points in system-auth may solve the problem, however there are no instructions other than "Add the following lines ..." Rather than work with /etc/pam.d/system-auth, as instructed in the HOWTO, I copied the suggested /etc/pam.d/passwd from /usr/share/doc/pam_ldap-156/pam.d/passwd.gz. This appears to execute modules for password updates in something resembling a reasonable order, and updates both the Unix and LDAP passwords. I suspect it may be possible to improve on the sequence. The third and final piece required was the continued inclusion of the root LDAP password in /etc/ldap.secrets. This appears to be necessary not only for root to update user passwords, but also for individual non-priv users to update their own passwords. If the password in /etc/ldap.secrets is absent or incorrect, module execution falls through to updating the Unix password, which isn't what we want. This is obviously a nasty security hole, but I don't know how to plug it. This is the result of much tinkering with various configurations and options, and getting lots of errors such as "passwd: Authentication information cannot be recovered" and "passwd: Authentication token manipulation error" and more ... Having determined that it's possible to make password updates work with pam_ldap, I'll leave it to the devs who understand pam and ldap better than I do to make it pretty (and to fix security!). I'll be happy to post any of my current config files if anyone wants them.
there is a flaw in your snippet of ACL spec. 'by self write' effectively allows users to change any of their data, not just their password. all the attribures of objectclass posixAccount and shadowAccount are at risk with that, thus the user could in theory change their uidNumber to 0 and that would be a problem. The snippet below should be better: access to * by dn="uid=root,ou=people,dc=fmp,dc=com" write by users read by anonymous auth access to attrs=userPassword,gecos,description,loginShell by self write
Noted. Thanks, Robin. I ain't no ldap guru, in fact I'm pretty much a novice. I just poked at things until they worked, and hopefully you note will make it into the Gentoo openldap HOWTO. Fortunately, the box in question is a desktop system well protected by a firewall, and only my wife and I are on the LAN (and she doesn't use Linux).
I've updated the ldap-howto to reflect this (so that users cannot change their UID). I'll mark this one as fixed then?
This actually only addresses one of several things I had to deal with in getting this working, so it's really not resolved. The line above listing 4.6 says "The next ACL is a bit more secure as it blocks normal users to read other people their shadowed password". It doesn't. It allows anyone read access to anything, so it's hardly more secure than the previous AC setup. Also, you almost certainly want to replace "fmp" with "genfic" in the AC write rule for root in listing 4.5 to be consistent with with usage elsewhere. My system just happens to be fmp.com, but using this in one listing in place of "genfic" will doubtless confuse some people. The security issue of /etc/ldap.secret isn't addressed. This file appears to be required in order for users to change their own passwords, which is contrary to the info in the HOWTO, and a DEFINITE security hole! If someone knows how to allow user password changes without requiring this file then it needs to be documented. It didn't work for me. I would also suggest that listing 4.1 be replaced with the following: #%PAM-1.0 auth sufficient /lib/security/pam_ldap.so auth required /lib/security/pam_unix_auth.so use_first_pass account sufficient /lib/security/pam_ldap.so account required /lib/security/pam_unix_acct.so password required /lib/security/pam_cracklib.so retry=3 password sufficient /lib/security/pam_ldap.so password required /lib/security/pam_pwdb.so try_first_pass with instructions to put this into /etc/pam.d/passwd instead of adding lines to system-auth. It should be pointed out that this is nothing more than the contents of /usr/share/doc/pam_ldap-156/pam.d/passwd.gz, altough someone with more knowledge of ldap may be able to improve on it. /etc/pam.d/system.auth needs a bit more attention also. The one I have at this point looks like this: #%PAM-1.0 auth sufficient /lib/security/pam_ldap.so use_first_pass auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_unix.so likeauth nullok nodelay auth required /lib/security/pam_deny.so account sufficient /lib/security/pam_ldap.so account required /lib/security/pam_unix.so password required /lib/security/pam_cracklib.so retry=3 password sufficient /lib/security/pam_unix.so nullok md5 shadow use_authtok password required /lib/security/pam_deny.so session required /lib/security/pam_limits.so session required /lib/security/pam_unix.so session required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0 session optional /lib/security/pam_ldap.so Added lines for pam_ldap are inserted into this file so as to group module types together in such a way that the control flags make more sense, although I haven't thought this out entirely - it just works. I'm reopening this in the hopes that maybe some focused attention can be given to the problem by someone who knows openldap and pam a lot better than I do, and at very least so the typos and inconsistencies introduced by this partial fix can be addressed. If you want to sweep it under the rug, go ahead and close it again and I'll not reopen it again, but the docs will remain broken.
ERRATA The reference above my second pam.d listing should be to "/etc/pam.d/system-auth", not to "/etc/pam.d/system.auth" Sorry .....
Heh, it wasn't my intention to mark this one as fixed just to close off a bug :) I just thought it was sufficient to deal with. Sorry about that.
I've temporarily unlinked the guide from the main index (security issues are too important) until this one is fixed.
Changing my password works fine here without ldap.secrets(on debian though). The rules should be: access to attribute=userPassword by dn="uid=root,ou=people,dc=genfic,dc=com" write by dn="uid=John,ou=People,dc=genfic,dc=com" write by anonymous auth by self write by * none access to * by dn="uid=root,ou=people,dc=genfic,dc=com" write by * read
/etc/pam.d/passwd should be as it is, but system-auth should be improved
for system-auth: auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_unix.so likeauth nullok shadow auth sufficient /lib/security/pam_ldap.so use_first_pass auth required /lib/security/pam_deny.so account sufficient /lib/security/pam_unix.so account sufficient /lib/security/pam_ldap.so account required /lib/security/pam_deny.so password required /lib/security/pam_cracklib.so retry=3 password sufficient /lib/security/pam_unix.so nullok use_authtok shadow md5 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 required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0 session optional /lib/security/pam_ldap.so
CCing woodchip since he's our PAM expert.
woodchip is on the pam-bugs alias ... we formed a group for pam since all the pam stuff was overloading woodchip
Does this bug belong to security@ ? If a GLSA is not needed for this then could the apprioate herd take this bug please.
It's purely documentation-related now, so reassigning.
Hi, last month I've migrated from NIS to LDAP, here's my ACL setup: access to dn=".*,dc=infis.univ.trieste,dc=it" attr="userPassword" by anonymous auth by self write by users search access to dn=".*,dc=infis.univ.trieste,dc=it" attr="shadowLastChange,shadowExpire" by self write by * read access to * by * read It correctly handle shadow password expiration when users update their password with passwd. I also strongly suggest this in slapd.conf, it provides a huge performance increase. index objectClass,uid,uidNumber,gidNumber pres,eq
Okay I don't know whether to post this here or else where. If I follow the LDAP Administration HOWTO it just does not seem to work for me, or for many other people by looking through the forums. Suggestions/Corrections 1. List what version of LDAP was used for the document. I went to 2.1.26 so I could use slapcat for testing. 2. Between Coding Listing 2.5 and 2.6 code needs to be added that actually creates the database. My solution was to do this: ldapadd -D "cn=Manager,dc=genfic,dc=com" -W -f /root/start.ldif start.ldif contains: dn: dc=genfic,dc=com objectclass: dcObject objectclass: organization o: genfic company name dc: genfic Tell the user to check that the database exists by checking that /usr/lib/openldap-ldbm has more than one file in it. 3. Coding Listing 3.1 seems broken. I had to specify: $EXTENDED_SCHEMA = 0; $DEFAULT_MAIL_DOMAIN = "genfic.com"; $DEFAULT_MAIL_HOST = "mail.genfic.com"; I set EXTENDED_SCHEMA to 0 because there seems to be a krbName not found issue. 4. I added all the schemas, I am not sure whether this is important or not. 5. During migration nothing seemed to work correctly, so I used the migrate_all_online.sh script instead. I added -c the slapadd commands to force the databases to be created. This helped get around the problems of krbName. This was very helpful in trying to understand why things weren't working. echo "Importing into LDAP..." if [ -x /usr/sbin/slapadd ]; then $LDAPADD -c -x -h $LDAPHOST -D "$LDAP_BINDDN" -w "$LDAP_BINDCRED" -f $DB elif [ -x /usr/local/sbin/slapadd ]; then $LDAPADD -c -x -h $LDAPHOST -D "$LDAP_BINDDN" -w "$LDAP_BINDCRED" -f $DB else $LDAPADD -c -h $LDAPHOST -D "$LDAP_BINDDN" -w "$LDAP_BINDCRED" -f $DB fi 6. If you receive an error, try adding -d 255 to increase the verbosity and solve the issue you have. Okay maybe a link to somewhere helpful. This sounds like a "go RTFM!" kind of thing. How about a link to the forums or something. The rest of the doc I haven't dealt with yet, but I will be trying to do pam, autofs, and samba authentication. This is an excellent doc, just some tweaks need to be made. Thanks
It shouldn't be necessary to go dig in the forums to get a proper functioning openldap installation. One of the nice (and essential!) things about the best of Gentoo's documentation is that although it deals with system administration issues at a pretty bare-bones level, it's well written and provides a clear and unambiguous step by step path to getting varioius facilities working. If one follows the directions carefully, things just work, and you don't have to ask any more questions. Newbies, or people who have other things to do besides hack gentoo expect this. I'm somewhere in the middle. I often don't have a lot of time or patience when it comes to making things work in Linux that don't, especially if I need them to do a job, but I do enjoy problem solving and spend more time than I probably should in debugging stuff like this :-) Openldap is a very complex pacakge of tools, right up there with samba and sendmail, maybe moreso if you include TLS authentication. I _did_ get a working openldap installation by following the Gentoo HOWTO, with the exceptions noted, and I had to dicker with it for hours to figure this out. IMHO, the HOWTO is 75% of the way there, it only needs to have a few things changed, added or clarified. OpenLDAP isn't mission-critical on my gentoo desktop system, and I'd be happy to un-install it, revert to non-LDAP PAM, and beta test any revised/improved instructions and report results.
I've unlinked the guide from the documentation page because there are no maintainers for it. Too complex material apparently :)
Anyone know if this [w|c]ould be an alternative for the full fledge OpenLDAP implementation in order to hace centralized authentications: http://www.fefe.de/tinyldap/ It look much smaller, hence it must be easier to set up.
Reopening
I've updated the system-auth listing according to comment #10 and the acls based on comment #8.
Hi, Is the HOWTO at http://www.gentoo.org/doc/en/ldap-howto.xml still maintained? I followed until the migration point, where is fails because of kerberosSecurityObject. After searching on internet for a while, I read that these kerberos stuff is RedHat specific and should be removed. I added this step: # grep -P -e "krbName|kerberosSecurityObject" --invert-match /tmp/passwd.ldif >tmp/passwd-fixed.ldif # ldapadd -x -D "cn=Manager,dc=greisberger,dc=net" -W -f /tmp/passwd-fixed.ldif The password migration is now ok and I'll continue, hoping that it was the only problem.
(In reply to comment #22) > Hi, > Is the HOWTO at http://www.gentoo.org/doc/en/ldap-howto.xml still maintained? Nope, as stated at the beginning of the document: "Disclaimer : This document is not valid and is not maintained anymore."
