[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Authentication and group/username resolving problem



Mark wrote:
I have LDAP setup to do userid, groupid and password handling for me.
I added "ldap" to 3 categories in nsswitch: passwd, shadow and group
Do I need to add LDAP to any others?

The problem I have is the following:
I can logon with a user (for example bob) that is setup in the LDAP
directory and does not exist locally.
When bob logs in, there is are error messages saying :
id: cannot find name for user ID 20002
id: cannot find name for group ID 20001
id: cannot find name for group ID 20003
id: cannot find name for group ID 20002
id: cannot find name for group ID 20000

If bob does "finger bob" or "groups bob", it says no such user.

If root does "finger bob" or "groups bob", everything comes up fine.

Is this a permission problem that prevents users other than root to use
LDAP?

I checked/modified ldap.conf, nsswitch.conf and pam.d/system-auth . Are
there any other files I need to modify to get authentication via LDAP going?

I also tried ldapsearch -x "uid=bob" when logged in as user bob and when
logged in as root.
The result of the LDAP query is exactly the same when I do it as root and
when I do it as regular user (logged in via LDAP authentication).
So that part is ok, guess it is somewhere in the user/group-handling process
on the machine after the data comes back from LDAP and gets processed
internally...

The system id Fedora core 1. I have the same configurations running on other
machines using the same LDAP server and I don't have the problem there...
Could this be related to a different kernel version (the one if the problem
is the more current one)? I always use the precompiled updated fedora
kernels, no own compile.

Thanks,

MARK



It's most likely an authentication problem.


When nss_ldap looks up uid/gid info. as root it binds to the LDAP server using the value of rootbinddn in /etc/ldap.conf and uses the password in /etc/ldap.secret. For any other user it does either an anonymous bind to the LDAP server or an unauthenticated bind with the id of binddn from /etc/ldap.conf. To get the info as a mortal user your LDAP server must allow unauthenticated binds as the binddn id, or it must be readably anonymously (i.e. by *).

To get around this you can run nscd, which binds as root on your behalf and also caches the info.


-- Nigel Wade, System Administrator, Space Plasma Physics Group, University of Leicester, Leicester, LE1 7RH, UK E-mail : nmw ion le ac uk Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]