Hi
I use openldap to do authentication on RHEL 6 machines. The problem I'm having is that 2 users doesn't get authenticated. When I do a getent passwd for these users it is as if they doesn't exist but a "ldapsearch -x" shows them. I would appreciate it if someone can point me int the right direction.
having is that 2 users doesn't get authenticated. When I do a getent passwd for these users it is as if they doesn't exist but a "ldapsearch -x" shows them.
Sounds as though an attribute type is missing from the users' entries; are they of objectClass `posixAccount' ? Maybe show us the LDIF of one of the "bad" entries?
-JP
On 20/06/2012 09:55, Jan-Piet Mens wrote:
having is that 2 users doesn't get authenticated. When I do a getent passwd for these users it is as if they doesn't exist but a "ldapsearch -x" shows them.
Sounds as though an attribute type is missing from the users' entries; are they of objectClass `posixAccount' ? Maybe show us the LDIF of one of the "bad" entries?
-JP
The LDIF for these users looks exactly ass all the other users. dn: uid=izak,ou=People,dc=flamengro,dc=com uid: izak cn: Izak Veldsman objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword: {crypt}Something shadowLastChange: 15264 shadowMin: 0 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 504 gidNumber: 100 homeDirectory: /home/izak gecos: Izak Veldsman
dn: uid=bertus,ou=People,dc=flamengro,dc=com uid: bertus cn: Bertus Smit objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword: {crypt}Something shadowLastChange: 15260 shadowMin: 0 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 500 gidNumber: 100 homeDirectory: /home/bertus gecos: Bertus Smit
What happens when I run "getent passwd" on the server .
getent passwd izak izak:*:504:100:Izak Veldsman:/home/izak:/bin/bash getent passwd bertus bertus:*:500:100:Bertus Smit:/home/bertus:/bin/bash
On one client nothing for these specific users, the other users work fine.
On Wed, Jun 20, 2012 at 11:08:27AM +0200, Chris wrote:
What happens when I run "getent passwd" on the server .
getent passwd izak izak:*:504:100:Izak Veldsman:/home/izak:/bin/bash getent passwd bertus bertus:*:500:100:Bertus Smit:/home/bertus:/bin/bash
On one client nothing for these specific users, the other users work fine.
It may be that they are 'negatively cached' in nscd. Try this on the problem client:
service nscd restart getent passwd izak
Andrew
On 2012-06-20 21:39, Andrew Findlay wrote:
[...] It may be that they are 'negatively cached' in nscd. Try this on the problem client:
service nscd restart
This won't help if nscd is configured to store its cache on disk ("persistent").
It's usually better to use nscd -i passwd -i, --invalidate=TABLE Invalidate the specified cache
Or, even better: While trying to configure and/or debug the nameservice, stop nscd completely :)
hth,
On Thu, Jun 21, 2012 at 08:36:30AM +0200, Martin Schuster (IFKL IT OS DS CD) wrote:
service nscd restart
This won't help if nscd is configured to store its cache on disk ("persistent").
It's usually better to use nscd -i passwd -i, --invalidate=TABLE Invalidate the specified cache
Good point.
Or, even better: While trying to configure and/or debug the nameservice, stop nscd completely :)
Agreed, but there are some cases where that actually breaks the nameservice entirely :-( The problem cases are where the relevant ldap.conf file contains a DN and password for access to the LDAP service and has therefore been made readable only by root. With nscd running all LDAP access is done by the nscd process which runs as root so it works. With nscd stopped the LDAP operations are done directly by client processes, many of which cannot read the config file.
A better solution would be to use nslcd: http://arthurdejong.org/nss-pam-ldapd/ or OpenLDAP's NSS overlay (currently in contrib, so not built by default).
Andrew
openldap-technical@openldap.org
-
Andrew Findlay -
Chris -
Jan-Piet Mens -
Martin Schuster (IFKL IT OS DS CD)