Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Nov 2010 11:43:12 -0500
From:      bluethundr <bluethundr@gmail.com>
To:        freebsd-questions <freebsd-questions@freebsd.org>
Subject:   Problems Hooking Sudoers into PAM/LDAP (corrected post)
Message-ID:  <AANLkTin-i%2BMisuXQGg41P5aicsbUvjU80BORnDuaYezs@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
Hey list!! Sorry for the accidentally truncated post I sent a little
while ago...heh! That was actually the result of a fat-fingered
copy-paste...


 At any rate, 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 and TLS
turned on and it is ALL happening through PAM!! Well almost all of
it..

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. 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:

http://ldap.acadaca.net/docs/openldap.txt


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:

http://ldap.acadaca.net/docs/securelogs.txt

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

http://ldap.acadaca.net/docs/sudov.txt


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

http://ldap.acadaca.net/docs/schema.txt


Best regards, and thanks for your help!!

--
Here's my RSA Public key:
gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9

Share and enjoy!!



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTin-i%2BMisuXQGg41P5aicsbUvjU80BORnDuaYezs>