# LDAP-Authentification (NSS and PAM)

## twam

Hi

I'm trying to make my gentoo work with LDAP Authenfication and found this nice Tutorial.

Logon is working and root can also do getent passwd oder whoami. But if a normal user logs in he always says in the prompt "I have no name!@pluto" and whoami returns "/usr/bin/whoami: cannot find username for UID 500". The problem , I think is that whoami tries to get these information via an anonymous bind to the LDAP server. If I set a binddn and bindpw in /etc/ldap.conf everything is working fine.

Is there a way to do this without setting a special user in /etc/ldap.conf and without giving anonymous all rights? Why isn't he using the user credentials to get these information?

Regards

  Tobias

----------

## tecknojunky

 *twam wrote:*   

> Is there a way to do this without setting a special user in /etc/ldap.conf and without giving anonymous all rights?

 Yes, since I'm doing it  :Razz: 

 *twam wrote:*   

> Why isn't he using the user credentials to get these information?

 It depends on many factors.  You do have a user listed with iudNumber 500 when you do getent passwd?  Is pluto also listed when you do getent shadow?  Does that user have a home folder with proper rights set (mainly owned by the user), ....

With so few details, it's not easy to give you straight answer.  For proof, nobody answers. :Sad: 

----------

## twam

Thanks for your reply. Here are my results:

As root:

pluto ~ # getent passwd|grep :500:

twam:x:500:1001:Tobias Mueller:/home/twam:/bin/bash

pluto ~ #

As user twam (uid500):

I have no name!@pluto ~ $ getent passwd | grep :500:

I have no name!@pluto ~ $

Why should "pluto" (the hostname) listed in getent shadow? And the user hast a home folder with 777-rights created by "session required        /lib/security/pam_mkhomedir.so  skel=/etc/skel/ umask=0" in /etc/pam.d/system-auth

----------

## tecknojunky

 *twam wrote:*   

> Why should "pluto" (the hostname) listed in getent shadow? 

 Because I thought it was the name of the user.  Sorry.  The "I have no name" is probably due to the fact you have not set "dnsdomainname" file.

----------

## twam

I set the domain name in /etc/dnsdomainname, but den login screen does recognize it yet.  :Sad: 

----------

## j-m

 *twam wrote:*   

> I set the domain name in /etc/dnsdomainname, but den login screen does recognize it yet. 

 

/etc/init.d/domainname restart or reboot...

----------

## twam

I tried this and rebooting more than once.  :Smile: 

----------

## j-m

 *twam wrote:*   

> I tried this and rebooting more than once. 

 

If you actually said this we could save three posts. How I am supposed to know that you did it?  :Confused: 

http://gentoo-wiki.com/TIP_Setup_Your_FQDN

----------

## twam

Hmm... I did't had the file /etc/conf.d/domainname (I wasn't mentioned in the gentoo-install-manual), but this didn't help either. It still says:

This is pluto.(none) (Linux i686 2.6.10-gentoo-r6-twam-12) 18:35:33

Here are my settings:

```
pluto ~ # rc-update show | egrep "(domain|host)"

          domainname | boot

            hostname | boot

pluto ~ # cat /etc/hostname

pluto

pluto ~ # cat /etc/domainname

space.twam.info

pluto ~ # cat /etc/dnsdomainname

space.twam.info

pluto ~ # cat /etc/conf.d/domainname

domainname space.twam.info

pluto ~ # cat /etc/env.d/01hostname

HOSTNAME="pluto"

pluto ~ # cat /etc/hosts

127.0.0.1       localhost

192.168.10.5    pluto pluto.space.twam.info

::1 ip6-localhost ip6-loopback

fe00::0 ip6-localnet

ff00::0 ip6-mcastprefix

ff02::1 ip6-allnodes

ff02::2 ip6-allrouters

ff02::3 ip6-allhosts

```

----------

## gsurbey

```
server / # ls -l /etc/ldap.conf

-rw-r-----  1 root users 8486 Apr 20 12:57 /etc/ldap.conf
```

Try more open permissions like above on that file.

----------

## obmun

Have you been able to finally solve this issue? I'm experiencing the same problem... pam_ldap is properly configured, as I can login. But the same that was happening to twam is happening to me. whoami is not able to find the username related to the UID. Under root user, "getent shadow user_name" returns properly the value. Under user_name user, "getent shadow user_name" isn't able to obtain the shadowed password; but I don't think this is related to this whoami problem at all. I have the following ACL in OpenLdap config:

 *Quote:*   

> access to attrs="userPassword"
> 
>   by dn="uid=root,ou=People,dc=design" write
> 
>   by anonymous auth
> ...

 

How should be whoami trying to get username? Probably nss_ldap would just need to send a search by uid and thet the uidNumber field, not needing special access rights. So the access to * entry bith the by * read, should be enought. nsswitch.conf and ldap.conf in /etc have correct rights (644).

Anyone has any idea of what can be happening?

----------

## obmun

OK. Good news!!! I have solved the problem, at least in my case.

This was what the OpenLDAP daemon was shouting in my log files when a user was trying to log in from a terminal:

```
May 27 11:45:11 riemann slapd[22935]: conn=0 op=3 SRCH base="ou=People,dc=design" scope=1 filter="(&(objectClass=posixAccount)(uid=moises))"

May 27 11:45:11 riemann slapd[22935]: conn=0 op=3 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass

May 27 11:45:11 riemann slapd[22935]: conn=0 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text=

May 27 11:45:11 riemann slapd[22935]: conn=0 op=4 SRCH base="ou=People,dc=design" scope=1 filter="(&(objectClass=posixAccount)(uid=moises))"

May 27 11:45:11 riemann slapd[22935]: conn=0 op=4 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass

May 27 11:45:11 riemann slapd[22935]: conn=0 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text=

May 27 11:45:11 riemann slapd[22935]: conn=1 fd=15 ACCEPT from IP=192.168.0.12:53623 (IP=0.0.0.0:636)

May 27 11:45:11 riemann slapd[22935]: conn=1 op=0 BIND dn="" method=128

May 27 11:45:11 riemann slapd[22935]: conn=1 op=0 RESULT tag=97 err=0 text=

May 27 11:45:11 riemann slapd[22935]: conn=1 op=1 SRCH base="ou=People,dc=design" scope=2 filter="(&(objectClass=posixAccount)(uid=moises))"

May 27 11:45:11 riemann slapd[22935]: conn=1 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=

May 27 11:45:11 riemann slapd[22935]: conn=0 op=5 SRCH base="ou=People,dc=design" scope=1 filter="(&(objectClass=posixAccount)(uid=moises))"

May 27 11:45:11 riemann slapd[22935]: conn=0 op=5 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass

May 27 11:45:11 riemann slapd[22935]: conn=0 op=5 SEARCH RESULT tag=101 err=0 nentries=1 text=

May 27 11:45:11 riemann slapd[22935]: conn=0 op=6 SRCH base="ou=People,dc=design" scope=1 filter="(&(objectClass=posixAccount)(uid=moises))"

May 27 11:45:11 riemann slapd[22935]: conn=0 op=6 SEARCH RESULT tag=101 err=0 nentries=1 text=

May 27 11:45:11 riemann slapd[22935]: conn=0 op=7 SRCH base="ou=Group,dc=design" scope=1 filter="(&(objectClass=posixGroup)(|(memberUid=moises)(uniqueMember=uid=moises,ou=people,dc=design)))"

May 27 11:45:11 riemann slapd[22935]: conn=0 op=7 SRCH attr=gidNumber

May 27 11:45:11 riemann slapd[22935]: <= bdb_equality_candidates: (uniqueMember) index_param failed (18)

May 27 11:45:11 riemann slapd[22935]: conn=0 op=7 SEARCH RESULT tag=101 err=0 nentries=2 text=

May 27 11:45:11 riemann slapd[22935]: conn=0 op=8 SRCH base="ou=People,dc=design" scope=1 filter="(&(objectClass=posixAccount)(uid=moises))"

May 27 11:45:11 riemann slapd[22935]: conn=0 op=8 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass

May 27 11:45:11 riemann slapd[22935]: conn=0 op=8 SEARCH RESULT tag=101 err=0 nentries=1 text=

May 27 11:45:11 riemann login(pam_unix)[22946]: session opened for user moises by (uid=0)

May 27 11:45:11 riemann slapd[22935]: conn=0 op=9 SRCH base="ou=People,dc=design" scope=1 filter="(&(objectClass=posixAccount)(uid=moises))"

May 27 11:45:11 riemann slapd[22935]: conn=0 op=9 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass

May 27 11:45:11 riemann slapd[22935]: conn=0 op=9 SEARCH RESULT tag=101 err=0 nentries=1 text=

May 27 11:45:11 riemann slapd[22935]: conn=2 fd=17 ACCEPT from IP=192.168.0.12:53624 (IP=0.0.0.0:636)

May 27 11:45:11 riemann slapd[22935]: conn=1 op=2 UNBIND

May 27 11:45:11 riemann slapd[22935]: conn=1 fd=15 closed

May 27 11:45:11 riemann slapd[22935]: conn=2 op=0 BIND dn="" method=128

May 27 11:45:11 riemann slapd[22935]: conn=2 op=0 RESULT tag=97 err=0 text=

May 27 11:45:11 riemann slapd[22935]: conn=2 op=1 SRCH base="ou=People,dc=design" scope=1 filter="(&(objectClass=posixAccount)(uidNumber=1001))"
```

As you can see, pam_unix was properly logging in user "moises", after asking for its information in the ldap database. But, as I have commented in my previous post, whoami wasn't properly getting the username. Also doing a su moises from a root login, the program was complaining about user moises not existing. The username was properly set in LDAP, as a getent passwd | grep moises was showing everything except for the user password:

 *Quote:*   

> obmun@riemann ~/Desktop $ getent passwd | grep moises
> 
> moises:x:1001:100:moises:/home/moises:/bin/bash

 

I thought there could be a problem with nss_ldap. Looking in nss_ldap config it is clearly said that the default method for connecting to LDAP is anonymous binding. That could be a problem. But in the OpenLDAP ACLs I had given access for anonymous user to everything excect for the password of posixAccount object (check my ACL in my last post); this was clearly not the problem as doing a getent passwd was working.

If you see the log above, you'll find a nice error saying that "index_param failed" for parameter uniqueMember. I decided to touch the indexes in BDB and see if something has changed. Originally my indexes were:

 *Quote:*   

> index   objectClass     eq
> 
> index   uidNumber       eq
> 
> index   gidNumber       eq
> ...

 

But I decided to change them to:

 *Quote:*   

> # Indexes
> 
> # By default: indexes of "present" and "equality"
> 
> index default pres,eq
> ...

 

I stopped the slapd daemon and rebuild the indexes (with slapdindex). And suddenly everything worked!!!!!!!!!

I always thought that indexes were only needed to speed up things during searches in the LDAP service... Why a change on indexes make whoami and su to properly obtain or find de username on the LDAP service? Please, could someone give me an explanation for this behaviour?

----------

