# pam ldap authentication



## bluethundr (Oct 9, 2010)

Well I managed to get my sudo working through ldap. Thanks to all who have helped! But for any of the services that need to authenticate through pam (i.e. ssh and su) it is still a no-go. I am getting pam authentication errors in my log files.

But LDAP is certainly doing it's job!

Using the account I have setup in LDAP as the pam user I can search my base DN:


```
[bluethundr@bluethundr-desktop:~ ] $:ldapsearch -x -h ldap -D "cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" -w secret -b "dc=summitnjhome,dc=com"
# extended LDIF
#
# LDAPv3
# base <dc=summitnjhome,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# summitnjhome.com
dn: dc=summitnjhome,dc=com
dc: summitnjhome
objectClass: dcObject
objectClass: organization
o: Summit NJ Home

# staff, summitnjhome.com
dn: ou=staff,dc=summitnjhome,dc=com
ou: staff
objectClass: organizationalUnit

# summitnjops, staff, summitnjhome.com
dn: ou=summitnjops,ou=staff,dc=summitnjhome,dc=com
ou: summitnjops
objectClass: organizationalUnit

# people, summitnjhome.com
dn: ou=people,dc=summitnjhome,dc=com
objectClass: organizationalUnit
ou: people

# Services, summitnjhome.com
dn: ou=Services,dc=summitnjhome,dc=com
ou: services
objectClass: organizationalUnit

# pam_ldap, Services, summitnjhome.com
dn: cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com
cn: pam_ldap
objectClass: top
objectClass: inetOrgPerson
sn: PAM
userPassword:: e1NTSEF9K2NsWktBUXVDWEhkbjVBcVRDbFVMb0ROZVcvelltelIg

# sudoers, Services, summitnjhome.com
dn: ou=sudoers,ou=Services,dc=summitnjhome,dc=com
ou: sudoers
objectClass: organizationalUnit

# defaults, sudoers, Services, summitnjhome.com
dn: cn=defaults,ou=sudoers,ou=Services,dc=summitnjhome,dc=com
objectClass: top
objectClass: sudoRole
cn: defaults
description: Default sudoOption's go here

# root, sudoers, Services, summitnjhome.com
dn: cn=root,ou=sudoers,ou=Services,dc=summitnjhome,dc=com
objectClass: top
objectClass: sudoRole
cn: root
sudoUser: root
sudoHost: ALL
sudoRunAsUser: ALL
sudoCommand: ALL

# %wheel, sudoers, Services, summitnjhome.com
dn: cn=%wheel,ou=sudoers,ou=Services,dc=summitnjhome,dc=com
objectClass: top
objectClass: sudoRole
cn: %wheel
sudoUser: %wheel
sudoHost: ALL
sudoRunAsUser: ALL
sudoCommand: ALL
sudoOption: !authenticate

# %summitnjops, sudoers, Services, summitnjhome.com
dn: cn=%summitnjops,ou=sudoers,ou=Services,dc=summitnjhome,dc=com
objectClass: top
objectClass: sudoRole
cn: %summitnjops
sudoUser: %summitnjops
sudoHost: ALL
sudoRunAsUser: ALL
sudoCommand: ALL
sudoOption: !authenticate

# search result
search: 2
result: 0 Success

# numResponses: 12
# numEntries: 11
```


And this is the entry I have in my LDAP database for the pam_ldap user:


```
5 cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com
cn: pam_ldap
objectClass: top
objectClass: inetOrgPerson
sn: PAM
userPassword: secret
```

So far so good, everything works. 

However, this is how I have my ldap.conf file setup:


```
host ldap.summitnjhome.com
base dc=summitnjhome,dc=com
binddn cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com
bindpw secret
scope sub
pam_password exop
nss_base_passwd ou=staff,dc=summitnjhome,dc=com
nss_base_shadow ou=staff,dc=summitnjhome,dc=com
```

( I have also tried setting the host to 127.0.0.1 as well, with no joy)

And observe what happens if I try to su using pam/ldap


```
Oct  9 20:25:11 LBSD2 su: pam_ldap: error trying to bind (Invalid credentials)
Oct  9 20:25:11 LBSD2 su: pam_ldap: error trying to bind (Invalid credentials)
Oct  9 20:25:11 LBSD2 su: in _openpam_check_error_code(): pam_sm_acct_mgmt(): unexpected return value 11
Oct  9 20:25:11 LBSD2 su: bluethundr to root on /dev/pts/0
```


ssh has roughly the same effect on the logs but in order for me to demonstrate that I would likely have to gain physical access to the box to fix it. So hopefully the above example will suffice. 

This is how my pam su file is configured:


```
LBSD2# cat /etc/pam.d/su 
#
# System-wide defaults
#

# auth
auth            sufficient      pam_opie.so             no_warn no_fake_prompts
auth            requisite       pam_opieaccess.so       no_warn allow_local
#auth           sufficient      pam_krb5.so             no_warn try_first_pass
#auth           sufficient      pam_ssh.so              no_warn try_first_pass
auth            sufficient      pam_ldap.so
auth            required        pam_unix.so        no_warn try_first_pass nullok

# account
#account        required        pam_krb5.so
account         required        pam_login_access.so
account         sufficient      pam_ldap.so
account         required        pam_unix.so

# session
#session        optional        pam_ssh.so
session         required        pam_ldap.so
session         required        pam_lastlog.so          no_fail

# password
#password       sufficient      pam_krb5.so             no_warn try_first_pass
password        required        pam_unix.so             no_warn try_first_pass
```


I assume that whatever is breaking su is breaking ssh. Does anyone have any ideas as to why slapd cannot access the pam_ldap account user automatically through /usr/local/etc/ldap.conf? x(


----------



## bluethundr (Oct 9, 2010)

by the way, pam_ldap was certainly installed with the following command:


```
portinstall pam_ldap
```


----------



## aragon (Oct 10, 2010)

If you set your loglevel in slapd to 256 you'll get some useful logging information about clients connecting and the searches they run.  If 256 isn't enough, check OpenLDAP docs for adding more detail.

Currently your setup won't work because you have no Posix user accounts in LDAP.  Remember that the binddn option in ldap.conf is purely for letting pam_ldap search your database for the user that its trying to authenticate.  Once it finds the account it attempts to rebind to the LDAP server using the searched out DN and the password from PAM.

In other words, you need the cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com binddn entry in LDAP _and_ a Posix entry in LDAP corresponding to the login you want to use on your workstation.

(actually you don't really need the binddn entry - the norm is to search anonymously)


----------



## bluethundr (Oct 11, 2010)

*posixAccount added*

Greatly clarified! thanks

I have added the corresponding posix accounts in LDAP I wish to use:


```
12 uid=bluethundr,ou=summitnjops,ou=staff,dc=summitnjhome,dc=com
ou: summitnjops
ou: staff
cn: Tim
objectClass: top
objectClass: organizationalUnit
objectClass: posixAccount
uid: bluethundr
uidNumber: 1001
gidNumber: 1002
homeDirectory: /home/bluethundr
userPassword: secret
gecos: Tim


13 cn=root,ou=staff,dc=summitnjhome,dc=com
ou: staff
cn: Enoch Root
cn: Root, Enoch
cn: root
objectClass: top
objectClass: organizationalUnit
objectClass: posixAccount
uid: root
uidNumber: 1
gidNumber: 1
homeDirectory: /root
userPassword: secret
gecos: Enoch Root
```

So tho anon search can work this more specific one used in ldap.conf can in fact find the entries:


```
ldapsearch -x -h ldap -D "cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" -w secret -b "dc=summitnjhome,dc=com"

# bluethundr, summitnjops, staff, summitnjhome.com
dn: uid=bluethundr,ou=summitnjops,ou=staff,dc=summitnjhome,dc=com
ou: summitnjops
ou: staff
cn: Tim
objectClass: top
objectClass: organizationalUnit
objectClass: posixAccount
uid: bluethundr
uidNumber: 1001
gidNumber: 1002
homeDirectory: /home/bluethundr
gecos: Tim

# root, staff, summitnjhome.com
dn: cn=root,ou=staff,dc=summitnjhome,dc=com
ou: staff
cn: Enoch Root
cn: Root, Enoch
cn: root
objectClass: top
objectClass: organizationalUnit
objectClass: posixAccount
uid: root
uidNumber: 1
gidNumber: 1
homeDirectory: /root
gecos:: RW5vY2ggUm9vdCA=
```

Yet su to these accounts is still broken:



```
[bluethundr@LBSD2:~]$:su - root
Password: 
Last login: Sun Oct 10 14:57:29 on pts/9
```

Logging in slapd.conf has been set to 256


```
loglevel        256
pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args
```

syslog.conf has been told to log openldap errors to /var/log/openldap.log


```
local4.*                                        /var/log/openldap.log
```


```
[root@LBSD2:/usr/local/etc/openldap]#tail -f /var/log/openldap.log 
Oct 11 02:12:44 LBSD2 slapd[42790]: conn=1000 op=1 RESULT tag=97 err=49 text=
Oct 11 02:12:44 LBSD2 slapd[42790]: conn=1000 op=2 UNBIND
Oct 11 02:12:44 LBSD2 slapd[42790]: conn=1000 fd=11 closed
Oct 11 02:17:01 LBSD2 slapd[42790]: conn=1001 fd=11 ACCEPT from IP=127.0.0.1:60289 (IP=0.0.0.0:389)
Oct 11 02:17:01 LBSD2 slapd[42790]: conn=1001 op=0 BIND dn="cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" method=128
Oct 11 02:17:01 LBSD2 slapd[42790]: conn=1001 op=0 RESULT tag=97 err=49 text=
Oct 11 02:17:01 LBSD2 slapd[42790]: conn=1001 op=1 BIND dn="cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" method=128
Oct 11 02:17:01 LBSD2 slapd[42790]: conn=1001 op=1 RESULT tag=97 err=49 text=
Oct 11 02:17:01 LBSD2 slapd[42790]: conn=1001 op=2 UNBIND
Oct 11 02:17:01 LBSD2 slapd[42790]: conn=1001 fd=11 closed
```



This is what is going on in the message logs:


```
Oct 11 02:12:44 LBSD2 su: pam_ldap: error trying to bind (Invalid credentials)
Oct 11 02:12:44 LBSD2 su: pam_ldap: error trying to bind (Invalid credentials)
Oct 11 02:12:44 LBSD2 su: in _openpam_check_error_code(): pam_sm_acct_mgmt(): unexpected return value 11
```

Any idea why su _still_ isn't authenticating even tho the user accounts have been added to LDAP??? :::sigh:::


----------



## aragon (Oct 11, 2010)

I don't know, but err=49 means invalid credentials.  Somewhere there is a password mismatch with the cn=pam_ldap entry.


----------



## bluethundr (Oct 15, 2010)

*pam ldap battle rages on*

PAM appears to still be broken after I have added posix account entries for my users into LDAP.

 I have verified that the same password is being used in my LDAP database for the pam_ldap user and in ldap.conf

 LDAP:

```
5 cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com
cn: pam_ldap
objectClass: top
objectClass: inetOrgPerson
sn: PAM
userPassword: secret
```

/usr/local/etc/openldap/ldap.conf

```
host ldap.summitnjhome.com
base dc=summitnjhome,dc=com
binddn cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com
bindpw secret
scope sub
pam_password exop
nss_base_passwd ou=staff,dc=summitnjhome,dc=com
nss_base_shadow ou=staff,dc=summitnjhome,dc=com
sudoers_base ou=sudoers,ou=Services,dc=summitnjhome,dc=com
```

The only thing I am a little unclear of is the role of the pam_password.  AFAIK I am binding on the password 'secret'.

When I test pam authentication with su:



```
BSD2# su - bluethundr
Password: 
Last login: Fri Oct 15 14:46:26 from 38.121.138.51
[bluethundr@LBSD2:~]$:
```


It produces these results in messages:

/var/log/messages:


```
Oct 15 15:02:52 LBSD2 su: pam_ldap: error trying to bind (Invalid credentials)
Oct 15 15:02:52 LBSD2 su: pam_ldap: error trying to bind (Invalid credentials)
Oct 15 15:02:52 LBSD2 su: in _openpam_check_error_code(): pam_sm_acct_mgmt(): unexpected return value 11
```

And this is what happens in the LDAP log:

/var/log/openldap.log

```
Oct 15 15:02:52 LBSD2 slapd[3610]: conn=1198 op=1 BIND dn="cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" method=128
Oct 15 15:02:52 LBSD2 slapd[3610]: conn=1198 op=1 RESULT tag=97 err=49 text=
Oct 15 15:02:52 LBSD2 slapd[3610]: daemon: activity on 1 descriptor
Oct 15 15:02:52 LBSD2 slapd[3610]: daemon: activity on:
Oct 15 15:02:52 LBSD2 slapd[3610]:  14r
Oct 15 15:02:52 LBSD2 slapd[3610]: 
Oct 15 15:02:52 LBSD2 slapd[3610]: daemon: read activity on 14
Oct 15 15:02:52 LBSD2 slapd[3610]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 15 15:02:52 LBSD2 slapd[3610]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 15 15:02:52 LBSD2 slapd[3610]: connection_read(14): input error=-2 id=1198, closing.
Oct 15 15:02:52 LBSD2 slapd[3610]: connection_closing: readying conn=1198 sd=14 for close
Oct 15 15:02:52 LBSD2 slapd[3610]: daemon: activity on 1 descriptor
Oct 15 15:02:52 LBSD2 slapd[3610]: daemon: waked
Oct 15 15:02:52 LBSD2 slapd[3610]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 15 15:02:52 LBSD2 slapd[3610]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 15 15:02:52 LBSD2 slapd[3610]: connection_close: deferring conn=1198 sd=14
Oct 15 15:02:52 LBSD2 slapd[3610]: conn=1198 op=2 UNBIND
Oct 15 15:02:52 LBSD2 slapd[3610]: connection_resched: attempting closing conn=1198 sd=14
Oct 15 15:02:52 LBSD2 slapd[3610]: daemon: removing 14
Oct 15 15:02:52 LBSD2 slapd[3610]: conn=1198 fd=14 closed
```


I don't really see the pam_ldap user doing a search for the bluethundr user. 



The pam_ldap account can log into LDAP:


```
[bluethundr@LBSD2:~]$:ldapsearch -x -h ldap -D "cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" -W -b "dc=summitnjhome,dc=com"
# extended LDIF
#
# LDAPv3
# base <dc=summitnjhome,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# summitnjhome.com
dn: dc=summitnjhome,dc=com
dc: summitnjhome
objectClass: dcObject
objectClass: organization
o: Summit NJ Home

# staff, summitnjhome.com
dn: ou=staff,dc=summitnjhome,dc=com
ou: staff
objectClass: organizationalUnit

# pam_ldap, Services, summitnjhome.com
dn: cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com
cn: pam_ldap
objectClass: top
objectClass: inetOrgPerson
sn: PAM
```

So can the user I am trying to su into:


```
[bluethundr@LBSD2:~]$:ldapsearch -x -h ldap -D "uid=bluethundr,ou=summitnjops,ou=staff,dc=summitnjhome,dc=com" -W -b "dc=summitnjhome,dc=com"
# extended LDIF
#
# LDAPv3
# base <dc=summitnjhome,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# summitnjhome.com
dn: dc=summitnjhome,dc=com
dc: summitnjhome
objectClass: dcObject
objectClass: organization
o: Summit NJ Home

# bluethundr, summitnjops, staff, summitnjhome.com
dn: uid=bluethundr,ou=summitnjops,ou=staff,dc=summitnjhome,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
cn: Tim Dunphy
gidNumber: 1001
homeDirectory: /home/bluethundr
sn: Dunphy
uid: bluethundr
uidNumber: 1001
gecos: Tim Dunphy
givenName: Tim
loginShell: /bin/bash
mail: bluethundr@gmail.com
userPassword:: secret
```

Also (and I know this may be a separate issue) I am attempting to get my CentOS clients to authenticate with this LDAP server. I have set everything up on the CentOS boxes using authconfig. 

I _do_ see evidence in the logs of a search being conducted for the user when I attempt to log in via LDAP...

When I try to ssh to the client (sum2) this is what I see in my LDAP logs on the LDAP server (bsd2)


```
Oct 15 16:42:55 LBSD2 slapd[3610]: daemon: read activity on 14
Oct 15 16:42:55 LBSD2 slapd[3610]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 15 16:42:55 LBSD2 slapd[3610]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 15 16:42:55 LBSD2 slapd[3610]: connection_read(14): input error=-2 id=1275, closing.
Oct 15 16:42:55 LBSD2 slapd[3610]: connection_closing: readying conn=1275 sd=14 for close
Oct 15 16:42:55 LBSD2 slapd[3610]: daemon: activity on 1 descriptor
Oct 15 16:42:55 LBSD2 slapd[3610]: daemon: waked
Oct 15 16:42:55 LBSD2 slapd[3610]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 15 16:42:55 LBSD2 slapd[3610]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 15 16:42:55 LBSD2 slapd[3610]: connection_close: deferring conn=1275 sd=14
Oct 15 16:42:55 LBSD2 slapd[3610]: conn=1275 op=2 UNBIND
Oct 15 16:42:55 LBSD2 slapd[3610]: connection_resched: attempting closing conn=1275 sd=14
Oct 15 16:42:55 LBSD2 slapd[3610]: daemon: removing 14
Oct 15 16:42:55 LBSD2 slapd[3610]: conn=1275 fd=14 closed
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: activity on 1 descriptor
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=7 busy
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: activity on 1 descriptor
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: waked
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: listen=7, new connection on 14
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: added 14r (active) listener=0x0
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: activity on 1 descriptor
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: waked
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: activity on 1 descriptor
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: activity on:
Oct 15 16:43:11 LBSD2 slapd[3610]:  14r
Oct 15 16:43:11 LBSD2 slapd[3610]: 
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: read activity on 14
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: conn=1276 fd=14 ACCEPT from IP=192.168.1.45:50867 (IP=0.0.0.0:389)
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: activity on 1 descriptor
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: waked
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: conn=1276 op=0 BIND dn="" method=128
Oct 15 16:43:11 LBSD2 slapd[3610]: conn=1276 op=0 RESULT tag=97 err=0 text=
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: activity on 1 descriptor
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: activity on:
Oct 15 16:43:11 LBSD2 slapd[3610]:  14r
Oct 15 16:43:11 LBSD2 slapd[3610]: 
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: read activity on 14
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 15 16:43:11 LBSD2 slapd[3610]: begin get_filter
Oct 15 16:43:11 LBSD2 slapd[3610]: AND
Oct 15 16:43:11 LBSD2 slapd[3610]: begin get_filter_list
Oct 15 16:43:11 LBSD2 slapd[3610]: begin get_filter
Oct 15 16:43:11 LBSD2 slapd[3610]: EQUALITY
Oct 15 16:43:11 LBSD2 slapd[3610]: end get_filter 0
Oct 15 16:43:11 LBSD2 slapd[3610]: begin get_filter
Oct 15 16:43:11 LBSD2 slapd[3610]: EQUALITY
Oct 15 16:43:11 LBSD2 slapd[3610]: end get_filter 0
Oct 15 16:43:11 LBSD2 slapd[3610]: end get_filter_list
Oct 15 16:43:11 LBSD2 slapd[3610]: end get_filter 0
Oct 15 16:43:11 LBSD2 slapd[3610]: conn=1276 op=1 SRCH base="dc=summitnjhome,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=bluethundr))"
Oct 15 16:43:11 LBSD2 slapd[3610]: conn=1276 op=1 SEARCH RESULT tag=101 err=50 nentries=0 text=
Oct 15 16:43:11 LBSD2 slapd[3610]: daemon: activity on 1 descriptor
```

I've enclosed more complete logs as an attachement (slapd-logs.txt). I've also included a portion of a tcpdump in the hopes that may shed some light on the situation (tcpdump.txt).



thanks for all the help I've gotten so far...


----------



## aragon (Oct 16, 2010)

Perhaps there is a problem with pam_ldap's binddn feature.  Can you try without it? (ie. anonymous search)

Looks like the Centos system is binding anonymously, searches for your uid, but doesn't find anything.  Try run the search manually:


```
ldapsearch -x -h ldap -b "dc=summitnjhome,dc=com" "(&(objectClass=posixAccount)(uid=bluethundr))"
```

That should return your posixAccount entry...

The pam_password directive tells pam_ldap what password scheme to use when it sets an LDAP password via passwd(1).  The "exop" setting is one of many schemes.  Others include md5, ssha, crypt, etc.


----------



## aragon (Oct 16, 2010)

aragon said:
			
		

> Looks like the Centos system is binding anonymously, searches for your uid, but doesn't find anything.


I just noticed the err=50 flag in the log.  That means insufficient access.  You need to permit anonymous searches in your slapd.conf.


----------



## bluethundr (Oct 16, 2010)

*ldap anonymous searches*

Hello,

 At first I wasn't able to do anonymous searches of ldap as should be clear by this point.

 So what I did was move anonymous reads from the bottom of the ACL list to the very top of the list, like so:


```
access to *
            by read

access to attrs=userPassword by self write
                             by anonymous auth
access to * by self write
            by dn.children="ou=summitnjops,ou=staff,dc=summitnjhome,dc=com" write
            by users read
            by anonymous auth

access to   attrs=shadowLastChange,userPassword
            by self write
            by * auth

access to * by self write
            by users read
            by anonymous auth
```


I tried to su both with and without the following lines commented out after making the above changes to slapd.conf. I commented out these lines thinking this would force the pam_ldap user to search anonymously:

/usr/local/etc/openldap/ldap.conf

```
host ldap.summitnjhome.com
base dc=summitnjhome,dc=com
#binddn cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com
#bindpw secret
scope sub
pam_password exop
nss_base_passwd ou=staff,dc=summitnjhome,dc=com
nss_base_shadow ou=staff,dc=summitnjhome,dc=com
sudoers_base ou=sudoers,ou=Services,dc=summitnjhome,dc=com
```

Anonymous searches _are_ working now:


```
[bluethundr@bt-laptop:~]$:ldapsearch -x -h ldap -b "dc=summitnjhome,dc=com" "(&(objectClass=posixAccount)(uid=bluethundr))"
# extended LDIF
#
# LDAPv3
# base <dc=summitnjhome,dc=com> with scope subtree
# filter: (&(objectClass=posixAccount)(uid=bluethundr))
# requesting: ALL
#

# bluethundr, summitnjops, staff, summitnjhome.com
dn: uid=bluethundr,ou=summitnjops,ou=staff,dc=summitnjhome,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
cn: Tim Dunphy
gidNumber: 1001
homeDirectory: /home/bluethundr
sn: Dunphy
uid: bluethundr
uidNumber: 1001
gecos: Tim Dunphy
givenName: Tim
loginShell: /bin/bash
mail: bluethundr@gmail.com
userPassword:: e0NSWVBUfWNySmg3NGtXbHRXeVE=

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
```


So while sudo is as mentioned working su is still not authenticating:

/var/log/messages

```
Oct 16 20:20:50 LBSD2 sudo: bluethundr : TTY=pts/5 ; PWD=/usr/home/bluethundr ; USER=root ; COMMAND=/usr/local/bin/bash
Oct 16 20:21:09 LBSD2 su: pam_ldap: error trying to bind (Invalid credentials)
Oct 16 20:21:09 LBSD2 su: pam_ldap: error trying to bind (Invalid credentials)
Oct 16 20:21:09 LBSD2 su: in _openpam_check_error_code(): pam_sm_acct_mgmt(): unexpected return value 11
```

And I'm still getting error 49's (credential errors) in the ldap logs:


```
Oct 16 20:21:09 LBSD2 slapd[60645]: conn=1000 op=1 BIND dn="cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" method=128
Oct 16 20:21:09 LBSD2 slapd[60645]: conn=1000 op=1 RESULT tag=97 err=49 text=
Oct 16 20:21:09 LBSD2 slapd[60645]: daemon: activity on 1 descriptor
Oct 16 20:21:09 LBSD2 slapd[60645]: daemon: activity on:
Oct 16 20:21:09 LBSD2 slapd[60645]:  11r
Oct 16 20:21:09 LBSD2 slapd[60645]: 
Oct 16 20:21:09 LBSD2 slapd[60645]: daemon: read activity on 11
Oct 16 20:21:09 LBSD2 slapd[60645]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 16 20:21:09 LBSD2 slapd[60645]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 16 20:21:09 LBSD2 slapd[60645]: connection_read(11): input error=-2 id=1000, closing.
Oct 16 20:21:09 LBSD2 slapd[60645]: connection_closing: readying conn=1000 sd=11 for close
Oct 16 20:21:09 LBSD2 slapd[60645]: daemon: activity on 1 descriptor
Oct 16 20:21:09 LBSD2 slapd[60645]: daemon: waked
Oct 16 20:21:09 LBSD2 slapd[60645]: daemon: select: listen=6 active_threads=0 tvp=NULL
Oct 16 20:21:09 LBSD2 slapd[60645]: daemon: select: listen=7 active_threads=0 tvp=NULL
Oct 16 20:21:09 LBSD2 slapd[60645]: connection_close: deferring conn=1000 sd=11
Oct 16 20:21:09 LBSD2 slapd[60645]: conn=1000 op=2 UNBIND
Oct 16 20:21:09 LBSD2 slapd[60645]: connection_resched: attempting closing conn=1000 sd=11
Oct 16 20:21:09 LBSD2 slapd[60645]: daemon: removing 11
Oct 16 20:21:09 LBSD2 slapd[60645]: conn=1000 fd=11 closed
```

:::guh:::


----------



## bluethundr (Oct 16, 2010)

*moderate progress*

In moderately good news, ldap authentication on foreign hosts seems to be creaking to life!


```
[bluethundr@LCENT02:~]$:ssh mon
bluethundr@mon's password: 
Last login: Sat Oct 16 16:34:18 2010 from 192.168.1.45
#########################################################
#               SUMMITNJHOME.COM                        #
#               TITLE:       VIRTCENT11 BOX             #
#               LOCATION:    SUMMIT BASEMENT            #
#                                                       #
#########################################################


id: cannot find name for group ID 1001
```

Not perfect yet but it's coming along.....


----------



## aragon (Oct 16, 2010)

bluethundr said:
			
		

> And I'm still getting error 49's (credential errors) in the ldap logs:
> 
> 
> ```
> ...


The BIND log entry above says that pam_ldap is still trying to authenticate for searches (and failing).  The dn= parameter should be blank with an anonymous bind.


----------



## bluethundr (Oct 26, 2010)

*pam / LDAP success!!!*

I have a NEW development!! PAM now appears to be authenticating through LDAP!!! whew!! Apparently I was using the encrypted password for the pam services in ldap.conf when the setup wasn't working. Don't know why I didn't think of this sooner, but when I tried putting the pam user's password in plain text in the ldap.conf file everything came to life!!! :stud

Sorry for being such a needy pain in this thread but in the end I'm glad it all came together and THANKS to everyone who helped!!!


----------

