On Tue, 25 May 2010, Andy Akins wrote: > 8. Confirmed user is not in /etc/passwd > 9. Confirmed using “getent passwd | grep username” that the user is listed. > 10. Confirmed using “getent passwd” shows two records for each user except > ldap-only users (one for /etc/passwd, one for LDAP). > > However, > > “id username” > > Returns unknown user Before the heavy troubleshooting starts, double-check that nscd is installed, configured, and working. You might want to restart it to make sure. Second -- and I personally hate this, though I can attest it sometimes works -- rebooting the machine will sometimes fix this. In particular, I've see the nss_ldap stuff have trouble in TLS environments when the server cert (or the CA that signed it) wasn't present at boot time. The next step would be to run something like strace -o /tmp/getent.trace getent passwd username strace -o /tmp/id.trace id username I'd identify where id is trying to locate user info and make sure it looks like the same place getent is using. On my CentOS systems, I note that id uses read() to access nscd while getent uses recvmsg(). I'm unsure if that difference would cause the problem, but it might be a place to look if you've got SELinux logs auditing things. -- Paul Heinlein <> heinlein at madboa.com <> http://www.madboa.com/