# Problems Hooking Sudoers into PAM/LDAP



## bluethundr (Nov 10, 2010)

Hello again FreeBSD! 

 I am attempting to solve a rather thorny issue and I was
hoping that someone might have some insight into what is going on
here..

At this point I have an openLDAP  server that is working quite splendidly! 

I have a working directory with users able to authenticate it. TLS
is turned on and it is ALL happening through PAM!! Well almost all of
it.. x(

The one sticking point I am currently having is getting sudoers to
authenticate against LDAP.

The server is FreeBSD 8.1 but the clients are all CentOS 5.4.
Although, knowing this shouldn't make much difference in how this
works AFAIK. PAM is PAM I'm told and I'm sure that is very true. On the client I have my /etc/ldap.conf file setup like
this:


```
URI ldap://ldap.acadaca.net/
BASE dc=acadaca,dc=net
TLS_CACERTDIR /etc/openldap/cacerts
pam_login_attribute     uid
pam_lookup_policy       yes
pam_password            exop
nss_base_passwd         ou=staff,dc=acadaca,dc=net
sudoers_debug 2
```

I have added the user I am testing to a couple of groups (two regular
DNs and one posixGroup)  all of which had the sudoRole objectClass in
the hopes that this might be related to the issue:



```
46 cn=%sa,ou=sudoers,ou=Services,dc=acadaca,dc=net
objectClass: top
objectClass: sudoRole
cn: %sa
sudoHost: ALL
sudoRunAsUser: ALL
sudoCommand: ALL
sudoOption: !authenticate
sudoUser: %sa
sudoUser: bluethundr


50 cn=role1,ou=sudoers,ou=Services,dc=acadaca,dc=net
objectClass: sudoRole
objectClass: top
cn: role1
sudoUser: bluethundr
sudoHost: ALL
sudoCommand: ALL

51 cn=sa,ou=Group,dc=acadaca,dc=net
objectClass: posixGroup
objectClass: top
cn: sa
userPassword: {crypt}*
gidNumber: 20004
```

However that didn't seem to do the trick. When I do attempt to sudo
from the client machine this is what I see on the command line:


```
[bluethundr@VIRCENT03:~]#sudo bash
[sudo] password for bluethundr:
bluethundr is not in the sudoers file.  This incident will be reported.
[bluethundr@VIRCENT03:~]#sudo -l
[sudo] password for bluethundr:
Sorry, user bluethundr may not run sudo on VIRCENT03.
```

Also I notice that the client can't seem to find it's groups stored in
LDAP even tho I would think that system auth would point sudoers
to them just as it does sshd and su.


```
[bluethundr@VIRCENT03:~]#groups bluethundr
id: cannot find name for group ID 1002
```

I am not entirely sure that this is a separate issue, honestly but I
think it may be related.


The other pam services I am working with, su and sshd, trigger events
in the openldap logs on the server. Everything is going smoothly with
these services, apparently:

In the openldap logs on the server here is a sample of what I see:


```
Nov  9 14:03:56 ldap slapd[31269]: bdb_search_candidates: id=1 first=54 last=54
Nov  9 14:03:56 ldap slapd[31269]: => test_filter
Nov  9 14:03:56 ldap slapd[31269]:     AND
Nov  9 14:03:56 ldap slapd[31269]: => test_filter_and
Nov  9 14:03:56 ldap slapd[31269]: => test_filter
Nov  9 14:03:56 ldap slapd[31269]:     EQUALITY
Nov  9 14:03:56 ldap slapd[31269]: => access_allowed: search access to
"uid=bluethundr,ou=sa,ou=staff,dc=acadaca,dc=net" "objectClass"
requested
Nov  9 14:03:56 ldap slapd[31269]: => acl_get: [1] attr objectClass
Nov  9 14:03:56 ldap slapd[31269]: => acl_mask: access to entry
"uid=bluethundr,ou=sa,ou=staff,dc=acadaca,dc=net", attr "objectClass"
requested
Nov  9 14:03:56 ldap slapd[31269]: => acl_mask: to value by "", (=0)
Nov  9 14:03:56 ldap slapd[31269]: <= acl_mask: [1] applying read(=rscxd) (stop)
Nov  9 14:03:56 ldap slapd[31269]: <= acl_mask: [1] mask: read(=rscxd)
Nov  9 14:03:56 ldap slapd[31269]: => access_allowed: search access
granted by read(=rscxd)
```
More complete logs that I hope will provide a bit more context can be
found here:

openLDAP Log Excerpt


What I've done was clear the openldap logs with an echo " "
> statement just before sudoing to root on the client.  Honestly, I wish
I was better at parsing these log files but unfortunately I'm not
quite there as of yet. 

Back on the client side I see this noticeable event, amongst quite a
lot of successful pam events in the secure log:


```
Nov  9 15:37:39 VIRCENT03 sudo: bluethundr : user NOT in sudoers ;
TTY=pts/3 ; PWD=/home/bluethundr ; USER=root ; COMMAND=/bin/bash
```

A more complete version of the secure log can be found here:

Secure Logs Excerpt

And here is my (surprisingly verbose) sudo -V output:

sudo -V Output


And lastly a copy of the schema that I am working with can be found here:

Our Schema


Best regards, and thanks for your help!!


----------



## gordon@ (Nov 11, 2010)

So, it's not a pam problem. You are correctly authenticating against the LDAP server, but you are not able to get the sudoers information from LDAP. Have you followed http://www.gratisoft.us/sudo/readme_ldap.html correctly?


----------



## bluethundr (Nov 12, 2010)

*fully functioning LDAP server*



			
				gordon@ said:
			
		

> So, it's not a pam problem. You are correctly authenticating against the LDAP server, but you are not able to get the sudoers information from LDAP. Have you followed http://www.gratisoft.us/sudo/readme_ldap.html correctly?



Hello I now have all the core functionality I need out of this LDAP server (for the time being). following and understanding the above guide was ultimately what did it. All it really took was a simple edit on nsswitch.conf on the client to get this working. I am a very happy guy as of now!! :stud


----------

