Which Directory Service do you use for your network?
None NIS LDAP LDAP + Kerberos Samba Active Directory eDirectory other ( 787 votes ~ 15 comments )
You are not currently logged in. If you do not have a user account then please consider creating one and logging in before you post your comment. This will allow you to track replies to your comment, and take part in the site much more freely.
To add your comment, fill in all the boxes below and then preview it to make sure you're happy with the way that it looks.
This is the comment you were replying to, attached to the weblog PAM and LDAP oddities.
#2 Re: PAM and LDAP oddities. Posted by daemon (155.232.xx.xx) on Fri 23 Mar 2007 at 06:56 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]...)
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]...)
Posting Format:
Inappropriate comments will be removed.
Some help on entry formatting is available
Username:
Password:
[ Advanced Login ]
Register Account
