<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style></style></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1>Just as a follow-up for future list readers, I thought I would post a summary of the case I opened with Redhat on this.<o:p></o:p><o:p> </o:p>The response essentially boiled down to:<o:p></o:p><o:p> </o:p>Regardless of the fact that other passwd backends (files, NIS, etc) expose the password hash with getent (regardless of calling user), they don’t see it as an issue that the backend for LDAP masks the password hash with ‘*’. The logic is that the hash is not used in pam_ldap authentication (an LDAP bind with password is).<o:p></o:p><o:p> </o:p>To the point that nslcd specifically DOES expose the hash when the user is root, but since nscd runs as non-root the root user can not see it either, was that you either a) don’t run nscd or b) don’t query a specific user - instead use enumeration since nscd doesn’t handle enumeration. Rather than run ‘ getent passwd oracle’ run ‘getent passwd | grep ^oracle:’.<o:p></o:p><o:p> </o:p>I personally still think this crap - getent should have consistent behavior regardless of the backend... but I am tired of fighting this battle.<o:p></o:p><o:p> </o:p>Thanks,<o:p></o:p><o:p> </o:p>Kevin<o:p></o:p><o:p> </o:p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>From: rhelv6-list-bounces@redhat.com [mailto:rhelv6-list-bounces@redhat.com] On Behalf Of Collins, Kevin [BEELINE] Sent: Thursday, December 09, 2010 11:23 AM To: rhelv6-list@redhat.com Subject: Re: [rhelv6-list] getent weirdness (was: nscd weirdness)<o:p></o:p></div></div><o:p> </o:p>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:<o:p></o:p><o:p> </o:p>changes from 0.6.11 to 0.7.0<o:p></o:p>----------------------------<o:p></o:p>...<o:p></o:p>...<o:p></o:p>* password hashes are no longer returned to non-root users (based on a patch<o:p></o:p> by Alexander V. Chernikov)<o:p></o:p>...<o:p></o:p><o:p> </o:p>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...<o:p></o:p><o:p> </o:p>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.<o:p></o:p><o:p> </o:p>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.<o:p></o:p><o:p> </o:p>Thanks,<o:p></o:p><o:p> </o:p>Kevin<o:p></o:p><o:p> </o:p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>From: rhelv6-list-bounces@redhat.com [mailto:rhelv6-list-bounces@redhat.com] On Behalf Of Collins, Kevin [BEELINE] Sent: Wednesday, December 08, 2010 4:05 PM To: rhelv6-list@redhat.com Subject: Re: [rhelv6-list] getent weirdness (was: nscd weirdness)<o:p></o:p></div></div><o:p> </o:p>I have narrowed this down to nslcd by using strace:<o:p></o:p><o:p> </o:p>[pid 7141] read(12, "\202\1\35\4\"uid=oracle,ou=People,dc=afis,dc=sr0\201\3660\17\4\3uid1\10\4\6oracle0\24\4\2cn1\16\4\fOracle Owner0+\4\vobjectClass1\34\4\7account\4\fposixAccount\4\3top0&\4\fuserPassword1\26\4\24{crypt}No_Login*****0\33\4\nloginShell1\r\4\v/usr/bin/sh0\22\4\tuidNumber1\5\4\0032000\22\4\tgidNumber1\5\4\0032000\32\4\rhomeDirectory1\t\4\7/oracle0\27\4\5gecos1\16\4\fOracle Owner", 288) = 288<o:p></o:p>[pid 7141] select(1024, NULL, [6], NULL, {0, 0}) = 1 (out [6], left {0, 0})<o:p></o:p>[pid 7141] sendto(6, "\1\0\0\0\351\3\0\0\0\0\0\0\6\0\0\0oracle\1\0\0\0*\310\0\0\0\310\0\0\0\f\0\0\0Oracle Owner\7\0\0\0/oracle\v\0", 64, MSG_NOSIGNAL, NULL, 0) = 64<o:p></o:p><o:p> </o:p>Notice the read() gets back the actual password data “{crypt}No_Login*****” but the sendto() is sending “*”?<o:p></o:p><o:p> </o:p>Now to research...<o:p></o:p><o:p> </o:p>Kevin<o:p></o:p><o:p> </o:p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>From: rhelv6-list-bounces@redhat.com [mailto:rhelv6-list-bounces@redhat.com] On Behalf Of Collins, Kevin [BEELINE] Sent: Wednesday, December 08, 2010 11:18 AM To: rhelv6-list@redhat.com Subject: Re: [rhelv6-list] getent weirdness (was: nscd weirdness)<o:p></o:p></div></div><o:p> </o:p>After further investigation, this seems to be an issue with getent. If the effective UID is not 0, it returns ‘*’ as the passwd hash. This is not the behavior exhibited in previous versions, and explains why I see the issue from root when nscd is running - nscd does a setuid to the user ‘nscd’.<o:p></o:p><o:p> </o:p>I checked this on another RHEL6 server that is resolving via NIS and it does *not* exhibit this behavior, so it has some relationship to LDAP. But, I can run ldapsearch and get back the passwd hash as any user (our LDAP allows anonymous read-only to all attributes).<o:p></o:p><o:p> </o:p>Now my suspicion is that this is caused by nss_ldap, which is different in RHEL6 since this is now part of nss-pam-ldapd.<o:p></o:p><o:p> </o:p>Any thoughts?<o:p></o:p><o:p> </o:p>Thanks,<o:p></o:p><o:p> </o:p>Kevin<o:p></o:p><o:p> </o:p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>From: rhelv6-list-bounces@redhat.com [mailto:rhelv6-list-bounces@redhat.com] On Behalf Of Collins, Kevin [BEELINE] Sent: Monday, December 06, 2010 10:06 AM To: rhelv6-list@redhat.com Subject: [rhelv6-list] nscd weirdness<o:p></o:p></div></div><o:p> </o:p>I am seeing different output in the password field of the passwd output from ‘getent’ when I have nscd runnng versus when I don’t:<o:p></o:p><o:p> </o:p># ps -ef | grep -E 'nscd|nslcd'<o:p></o:p>nscd 18126 1 0 09:42 ? 00:00:00 /usr/sbin/nscd<o:p></o:p>nslcd 18206 1 0 09:44 ? 00:00:00 /usr/sbin/nslcd<o:p></o:p><o:p> </o:p><o:p> </o:p># getent passwd oracle<o:p></o:p>oracle:*:200:200:Oracle Owner:/oracle:/usr/bin/sh<o:p></o:p><o:p> </o:p># service nscd stop<o:p></o:p>Stopping nscd: [ OK ]<o:p></o:p><o:p> </o:p># getent passwd oracle<o:p></o:p>oracle:No_Login*****:200:200:Oracle Owner:/oracle:/usr/bin/sh<o:p></o:p><o:p> </o:p># nscd -i passwd<o:p></o:p><o:p> </o:p># getent passwd oracle<o:p></o:p>oracle:No_Login*****:200:200:Oracle Owner:/oracle:/usr/bin/sh<o:p></o:p><o:p> </o:p># service nscd start<o:p></o:p>Starting nscd: [ OK ]<o:p></o:p><o:p> </o:p># getent passwd oracle<o:p></o:p>oracle:*:200:200:Oracle Owner:/oracle:/usr/bin/sh<o:p></o:p><o:p> </o:p>As you can see, I have tried flushing the passwd cache and restarting nscd with no luck. The backend in this case is LDAP - the problem does not appear when I am getting information from an ID in /etc/passwd.<o:p></o:p><o:p> </o:p>Any ideas?<o:p></o:p><o:p> </o:p>Thanks,<o:p></o:p><o:p> </o:p>Kevin<o:p></o:p></div></body></html>