This site is now 100% read-only, and retired.

XML logo

PAM and LDAP oddities.
Posted by daemon on Thu 22 Mar 2007 at 12:26
Tags: ,

I recently had to set up some user accounts on a server that should auth from a central LDAP server (running Novell eDirectory). It was supposed to be simple, users only needed sftp access, so I'm using scponly as their shell, and it was all straight forward enough.

User entries were added to /etc/passwd, with no corresponding entry in /ets/shadow, and they all had one locally defined group as their primary group. While this may look non-standard, it works perfectly for two test accounts that are setup in the exact same manner -- the test acconts have no issues.

However, oddly enough, the non test accounts have odd behaviour. When using getent, some reply, correctly, with the locally defined information, while others reply with the LDAP defined information. This plays havoc with normal use, because the uid, gid, home and shell information is different in each source (e.g. they should have a shell of /usr/bin/scponly, but the LDAP definition uses /bin/bash, the locally defined $HOME is /home/cs1/[user], but the LDAP definition uses /home/[user]).

While all that is strange enough, what's really odd is that even though they can log in, browse happily, and that they have rwx owner permissions on their $HOME, they can't write unless they have group write permissions too (and seeing as they're all members of the same group, that's not very good in this situation).

I've disabled, re-enabled, and re-configured nscd (removing the group caching entry), which initially solved the getent reply issue, but not any more, I've tinkered with libnss-ldap.conf (which is symlinked to pam_ldap.conf), and culled LDAP from the "group" entry in nsswitch.conf.

If anyone else here come across anything like this before, did you managed to find out what was going on? Any hints and tips?

All help gratefully received ;-)

 

Comments on this Entry

Re: PAM and LDAP oddities.
Posted by Anonymous (213.164.xx.xx) on Thu 22 Mar 2007 at 21:20
I think you answered your own question.. either you have the account information in ldap, or you have it in the passwd file. Ditch it from the passwd file, turn off nscd, and retest. What happens?

[ Parent ]

Re: PAM and LDAP oddities.
Posted by daemon (155.232.xx.xx) on Fri 23 Mar 2007 at 06:56
[ View Weblogs ]

The difficulty is, is that there are upwards of 6000 users defined in the eDirectory (available via LDAP), but we only want ~450 of those to have access to this machine, and we can't easily filter by baseDN or other LDAP details, hence the (albeit) kludge of the local passwd entries.

To add extra difficulty, the LDAP defined users have as their primary groupID the same as the locally defined GID for the groups `shadow`, so as you can imagine, I really don't want them running around any of our debian/ubuntu machines, as they'll have unfettered read access to /etc/shadow and /etc/gshadow (not that the latter is too important security wise these days).

What makes the situation really annoying, is that it works in some cases, completely as in the two test accounts; partially in some, such as those who's getent replies with the correct details, but oddly aren't allowed to write to their $HOMEs; and is completely non-working in others, whose getent returns LDAP defined details, and who also dont' have write access, but can usually still log in anyway.

All tolled, it's a headache waiting to happen, but one that I have to try and fix regardless...

Cheers.

(PS. The setup works perfectly on a FreeBSD box that's trying to be replaced by a debian box, so it is possible, just annoying, as both boxes are essentially configured exactly the same as far as LDAP/PAM are concerned. [Sigh]...)

[ Parent ]

Re: PAM and LDAP oddities.
Posted by mangler (24.84.xx.xx) on Thu 29 Mar 2007 at 06:48
What about using something like the pam_user_auth module?

http://www-dev.cites.uiuc.edu/pam/

I've never used it, but if you can enumerate the users who should have access, then you should be able to put them in a list to be checked by pam.

If you do get this working, please post your configuration, as it's a great project.

PS, one of these modules might be closer to your needs tho, http://www.kernel.org/pub/linux/libs/pam/modules.html

[ Parent ]

Re: PAM and LDAP oddities.
Posted by Anonymous (149.149.xx.xx) on Fri 30 Mar 2007 at 00:10
pam_listfile should be able to stand in for your dummy passwd entries.

[ Parent ]