Anyone know how to hash the ldap.secret (the rootbinddn passwd) file so you don't have to store it as clear text? In Solaris you are able to store the password as an NS1 hash in /var/ldap/ldap_client_cred, but I can't seem to use any hashes (tried MD5, Crypt, NS1) with Linux. This is normally not an issue because ldap.secret is owned only by root, however it so happens this particular Linux servers has a couple non-admins that need root access.
Authenticating systems to LDAP is great. Especially because there's so much possible versatility. For example, not only can you authenticate logins, but you can also setup AutoFS to pull automount information from LDAP, and even better, you can actually pull SUDO access rules from LDAP (to replace the sudoers file).This makes it *so* much easier to remove direct root login, and force administrators to use sudo. It also makes it easier to selectively grant additional access to users.
There doesn't seem to be any easy facility to emulate with LDAP what can be done with NIS and the compat stuff. It would be very useful if netgroup like functionality was available for nss_ldap/pam_ldap.I have bodged something up by modifying the filters used to look for certain values in the host LDAP attribute, but this does not allow you to override information like you can do with NIS.
>I have bodged something up by modifying the filters used to look for certain values in the host LDAP attribute, but this>does not allow you to override information like you can do with NIS.Here is what I did for my company.....we just add an extra set of "ou" attributes to each user like say "ou=accounting", or "ou=oracle_dba".....you can do that because ou is an enherited attribue for posixaccount...and you can have multiples of them...this creates an additional attribute on the user account entry that specifies which user types or whatever you want to call it, they are a member of.and in the LDAP client system you just put in LDAP Search filters so that something like this is on your system:password=passwd:ou=people,ou=unix,o=hp.com?sub?(objectclass=posixAccount)shadow= (same as above).You can then basically configure any individual server to allow logins for the specificed list of user groups by each server having a particular set of user types listed in its search filter for what search query it does against the LDAP directory to determine its virtual /etc/passwd and virtual /etc/shadow files look like.ITS MUCH easier than the old fashioned host attribute thing...there you have to add every host to every user that needs access to that host. I am sure thats fine for a few dozen people on a few machines....but that is ZERO help when you have 500 machines and thousands of users which all need access to just a particular set of systems. Just adding ou=oracle_dba to someone's user entry and having that automatically give them access to the whole list of accounting systems is MUCH easier than adding all the individual host attributes to their account.Research search filters and how to apply them to LDAP's nsswitch lookups and you will be golden.
sdnick484Aug 25, 2006
Anyone know how to hash the ldap.secret (the rootbinddn passwd) file so you don't have to store it as clear text? In Solaris you are able to store the password as an NS1 hash in /var/ldap/ldap_client_cred, but I can't seem to use any hashes (tried MD5, Crypt, NS1) with Linux. This is normally not an issue because ldap.secret is owned only by root, however it so happens this particular Linux servers has a couple non-admins that need root access.
starthornAug 25, 2006
Authenticating systems to LDAP is great. Especially because there's so much possible versatility. For example, not only can you authenticate logins, but you can also setup AutoFS to pull automount information from LDAP, and even better, you can actually pull SUDO access rules from LDAP (to replace the sudoers file).This makes it *so* much easier to remove direct root login, and force administrators to use sudo. It also makes it easier to selectively grant additional access to users.
jbirdmanAug 26, 2006
There doesn't seem to be any easy facility to emulate with LDAP what can be done with NIS and the compat stuff. It would be very useful if netgroup like functionality was available for nss_ldap/pam_ldap.I have bodged something up by modifying the filters used to look for certain values in the host LDAP attribute, but this does not allow you to override information like you can do with NIS.
fucknutAug 26, 2006
that's very easy to do. you just list your host attributes, where each host is where you are allowed to login. use "*" for all access.voila.
nixfuAug 26, 2006
>I have bodged something up by modifying the filters used to look for certain values in the host LDAP attribute, but this>does not allow you to override information like you can do with NIS.Here is what I did for my company.....we just add an extra set of "ou" attributes to each user like say "ou=accounting", or "ou=oracle_dba".....you can do that because ou is an enherited attribue for posixaccount...and you can have multiples of them...this creates an additional attribute on the user account entry that specifies which user types or whatever you want to call it, they are a member of.and in the LDAP client system you just put in LDAP Search filters so that something like this is on your system:password=passwd:ou=people,ou=unix,o=hp.com?sub?(objectclass=posixAccount)shadow= (same as above).You can then basically configure any individual server to allow logins for the specificed list of user groups by each server having a particular set of user types listed in its search filter for what search query it does against the LDAP directory to determine its virtual /etc/passwd and virtual /etc/shadow files look like.ITS MUCH easier than the old fashioned host attribute thing...there you have to add every host to every user that needs access to that host. I am sure thats fine for a few dozen people on a few machines....but that is ZERO help when you have 500 machines and thousands of users which all need access to just a particular set of systems. Just adding ou=oracle_dba to someone's user entry and having that automatically give them access to the whole list of accounting systems is MUCH easier than adding all the individual host attributes to their account.Research search filters and how to apply them to LDAP's nsswitch lookups and you will be golden.
cptcomicSep 19, 2006
thx, nixfu, for the helpful comment. Can't believe I found such a treasure in the digg comments