Did you miss the part where I said this impacts root? And regardless of why I want (or don't want) to do this, it should be my choice. I may have scripts that process the output of getent to check for expired users, etc that rely on getting the password hash. In NIS or a non-shadow environment, this is the case anyway.
We primarily use SSO with kerberos (from AD), so our password hashes do not contain a password in (our) LDAP (not AD)... but they do contain strings that are used to denote the state of the user. Kevin -----Original Message----- From: Kinzel, David [mailto:[email protected]] Sent: Thursday, December 09, 2010 1:55 PM To: Collins, Kevin [BEELINE]; [email protected] Subject: RE: [rhelv6-list] getent weirdness (was: nscd weirdness) What seems wrong is wanting the password hash to be given to regular users. Why? ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Collins, Kevin [BEELINE] Sent: Thursday, December 09, 2010 12:23 PM To: [email protected] Subject: Re: [rhelv6-list] getent weirdness (was: nscd weirdness) I have found the root (no pun intended!) of this problem in the /usr/share/doc/nss-pam-ldapd-0.7.5/NEWS file included in the RPM: changes from 0.6.11 to 0.7.0 ---------------------------- ... ... * password hashes are no longer returned to non-root users (based on a patch by Alexander V. Chernikov) ... So, I can sort of see the point of this, but I think that this daemon should return what the calling user has access to. If the password hash is not protected, it can be via ACLs from the LDAP server or it can be mapped to a different value. At the very least, there should be an option to allow that behavior. Deciding to just say "no" seems wrong... Where this becomes interesting is the case where you run nslcd *and* nscd: since nscd runs as user 'nscd' (not root), root will never get the password hash either since the nss calls are routed via nscd. Not sure if anyone else cares since I have seen no replies, but I figured it's worth documenting. I will probably open a support case just to see what the response is. Thanks, Kevin Kevin This email communication and any files transmitted with it may contain confidential and or proprietary information and is provided for the use of the intended recipient only. Any review, retransmission or dissemination of this information by anyone other than the intended recipient is prohibited. If you receive this email in error, please contact the sender and delete this communication and any copies immediately. Thank you. http://www.encana.com _______________________________________________ rhelv6-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv6-list
