Hello List
I am attempting to setup various pam modules to consult our new LDAP services in order to do what it needs to do. My LDAP server is FreeBSD but the clients are CentOS...
I have setup my /etc/pam.d sudo file on the client (for example) this way in the attempt to accomplish this via LDAP:
[root@VIRCENT03:~]#cat /etc/pam.d/sudo #%PAM-1.0 auth include system-auth auth required pam_ldap.so account include system-auth account required pam_ldap.so password include system-auth password required pam_ldap.so session optional pam_keyinit.so revoke session required pam_limits.so session required pam_ldap.so
but even tho the user is part of the %wheel group under LDAP it is unable to sudo to any other account (including root). If I try to sudo this is what happens:
[bluethundr@VIRCENT03:~]#sudo bash [sudo] password for bluethundr: bluethundr is not in the sudoers file. This incident will be reported.
It would appear that sudo support for ldap is compiled in:
[root@VIRCENT03:~]#ldd $(which sudo)| grep -i ldap libldap-2.3.so.0 => /usr/lib/libldap-2.3.so.0 (0x00552000)
This is how I setup my ldap.conf file
[root@VIRCENT03:~]#cat /etc/openldap/ldap.conf # # LDAP Defaults #
# See ldap.conf(5) for details # This file should be world readable but not world writable.
#BASE dc=example, dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666
#SIZELIMIT 12 #TIMELIMIT 15 #DEREF never URI ldap://ldap.acadaca.net/ BASE dc=acadaca,dc=net TLS_CACERTDIR /etc/openldap/cacerts sudoers_base ou=sudoers,ou=Services,dc=acadaca,dc=net
In my openldap logs on the LDAP server there appears to be no activity when I sudo. however in the secure logs on the client I do..
Nov 8 16:05:34 VIRCENT03 su: pam_unix(su-l:session): session opened for user root by bluethundr(uid=500) Nov 8 16:05:37 VIRCENT03 su: pam_unix(su-l:session): session opened for user bluethundr by bluethundr(uid=0) Nov 8 16:05:44 VIRCENT03 sudo: bluethundr : user NOT in sudoers ; TTY=pts/5 ; PWD=/home/bluethundr ; USER=root ; COMMAND=/bin/bash
Conversely when I sudo via LDAP on my FreeBSD ldap server this is what I see...
Nov 8 19:44:25 LBSD2 sudo: bluethundr : TTY=pts/11 ; PWD=/usr/home/bluethundr ; USER=root ; COMMAND=/bin/bash Nov 8 19:44:51 LBSD2 sudo: bluethundr : TTY=pts/10 ; PWD=/usr/home/bluethundr ; USER=root ; COMMAND=/bin/bash
Works there!
I do see other events in secure.log that appear to be pam successes however. am i interpreting this correctly that at least part of the system is communicating with pam on the ldap server?
thanks
On Mon, 8 Nov 2010, bluethundr wrote:
[root@VIRCENT03:~]#cat /etc/openldap/ldap.conf
[...]
TLS_CACERTDIR /etc/openldap/cacerts sudoers_base ou=sudoers,ou=Services,dc=acadaca,dc=net
I don't believe that "sudoers_base" is a recognized OpenLDAP configuration directive. As such, this line may belong in a file other than "/etc/openldap/ldap.conf" on your system.
I have created a symlink from /etc/openldap/ldap.conf to /etc/ldap.conf... that seems to have gotten the majority of the system communicating with PAM/LDAP. I guess that making a .ldaprc file in the users home directory and putting those directives in there would be about the equivalent.
The only thing eluding me currently is getting the client to listen to sudoers which is currently working thru ldap on the ldap server itself.
[root@VIRCENT03:~]#cat /etc/pam.d/sudo #%PAM-1.0 auth include system-auth auth required pam_ldap.so account include system-auth account required pam_ldap.so password include system-auth password required pam_ldap.so session optional pam_keyinit.so revoke session required pam_limits.so session required pam_ldap.so
AFAIK the above should get pam_ldap communicating with the LDAP server on the behalf of sudoers. the other pam configs (such as sshd and su) appear to be getting their info from the system auth which is currently communicating with the LDAP server.
Does anyone have any tips on how to get sudoers working through pam /ldap?
thanks!!
On Mon, Nov 8, 2010 at 4:29 PM, Aaron Richton richton@nbcs.rutgers.edu wrote:
On Mon, 8 Nov 2010, bluethundr wrote:
[root@VIRCENT03:~]#cat /etc/openldap/ldap.conf
[...]
TLS_CACERTDIR /etc/openldap/cacerts sudoers_base ou=sudoers,ou=Services,dc=acadaca,dc=net
I don't believe that "sudoers_base" is a recognized OpenLDAP configuration directive. As such, this line may belong in a file other than "/etc/openldap/ldap.conf" on your system.
I have created a symlink from /etc/openldap/ldap.conf to /etc/ldap.conf... that seems to have gotten the majority of the system communicating with PAM/LDAP. I guess that making a .ldaprc file in the users home directory and putting those directives in there would be about the equivalent.
Those two files do not serve the same purpose, nor use the same options.
/etc/openldap/ldap.conf is for ldap tools - ie ldapsearch, ldapmodify, etc. Primarily only on openldap servers (and perhaps admin work stations).
/etc/ldap.conf is used by pam.
Symlinking from to the other won't help.
For reference, here are examples of my ldap.conf from a NON ldap server:
# /etc/ldap.conf uri ldaps://ldap-vip.example.net timelimit 30 bind_timelimit 30 bind_policy hard_open base dc=example,dc=net scope sub ssl on tls_checkpeer no tls_cacertfile /etc/openldap/cacert.pem pam_login_attribute uid pam_lookup_policy yes pam_password exop nss_base_passwd ou=people,dc=example,dc=net?one
# /etc/openldap/ldap.conf URI ldap://ldapconsole.example.net/ BASE " dc=example,dc=net" TLS_CACERTDIR /etc/openldap/cacerts
On the box I pulled these from, the latter file is never used - nor will it even work.
If that line is a pam config directive, it belongs in /etc/ldap.conf.
If you keep straight what you're working on, it will likely help.
- chris
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/11/2010, at 09:16, bluethundr wrote:
I have created a symlink from /etc/openldap/ldap.conf to /etc/ldap.conf... that seems to have gotten the majority of the system communicating with PAM/LDAP. I guess that making a .ldaprc file in the users home directory and putting those directives in there would be about the equivalent.
The only thing eluding me currently is getting the client to listen to sudoers which is currently working thru ldap on the ldap server itself.
[root@VIRCENT03:~]#cat /etc/pam.d/sudo #%PAM-1.0 auth include system-auth auth required pam_ldap.so account include system-auth account required pam_ldap.so password include system-auth password required pam_ldap.so session optional pam_keyinit.so revoke session required pam_limits.so session required pam_ldap.so
AFAIK the above should get pam_ldap communicating with the LDAP server on the behalf of sudoers. the other pam configs (such as sshd and su) appear to be getting their info from the system auth which is currently communicating with the LDAP server.
Does anyone have any tips on how to get sudoers working through pam /ldap?
thanks!!
I have had a similar issue on my OpenLDAP setup. I have a posixgroup in ldap, into which i placed a list of users for sudo access, and it never works. both full dn, and just the uid or id number of the user in the posixgroup dont work.
Sudo supports some LDAP based configuration from what i understand, but i think that is different to what you are trying to achieve in this case.
-- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9
Share and enjoy!!
William Brown
pgp.mit.edu
On Tuesday, 9 November 2010 00:07:27 Indexer wrote:
I have had a similar issue on my OpenLDAP setup. I have a posixgroup in ldap, into which i placed a list of users for sudo access, and it never works.
Works just fine here. Seems your nss setup is broken.
both full dn, and just the uid or id number of the user in the posixgroup dont work.
Sudo supports some LDAP based configuration from what i understand, but i think that is different to what you are trying to achieve in this case.
No, it is what the OP is trying to achieve.
Here is an example with sudo rules in LDAP, applied to groups that only exist in LDAP:
[bgmilne@saturn ~]$ grep bgmilne /etc/passwd [bgmilne@saturn ~]$ grep bgmilne /etc/group [bgmilne@saturn ~]$ groups sysadmins build developers dbas ispservices [bgmilne@saturn ~]$ sudo -l User bgmilne may run the following commands on this host:
LDAP Role: BUILD Commands: /usr/bin/eash /usr/local/bin/eash
[...]
[bgmilne@saturn ~]$ ldapsearch -LLL -x "(&(objectclass=sudoRole)(cn=BUILD))" dn: cn=BUILD,ou=SUDOers,dc=xxx.... objectClass: top objectClass: sudoRole cn: BUILD sudoHost: ALL sudoOption: !authenticate sudoUser: %sysadmins sudoUser: %build sudoCommand: /usr/bin/eash sudoCommand: /usr/local/bin/eash
[bgmilne@saturn ~]$ sudo eash [i] trying 192.168.123.16:5554 ... connected. Awaiting EAS central server validation ... granted. All privileged access to this host is audited. Exit your shell if you do not accept the conditions of privileged access to this host. [saturn:~]# id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=user_u:system_r:unconfined_t
Regards, Buchan
bluethundr wrote:
I have created a symlink from /etc/openldap/ldap.conf to /etc/ldap.conf... that seems to have gotten the majority of the system
This is a RHEL-based linux system, right? If so, you don't want to do that. They serve two completely different services.
/etc/openldap/ldap.conf is used by the ldap client command-line tools (ldapsearch, ldapadd, etc.). And I've confirmed that it's used by the the name service switch, too. I don't think last part os documented anywhere.
/etc/ldap.conf is for the pam_ldap module.
If adding that symlink fixed your problem, I think there's something else wrong with your system.
communicating with PAM/LDAP. I guess that making a .ldaprc file in the users home directory and putting those directives in there would be about the equivalent.
The only thing eluding me currently is getting the client to listen to sudoers which is currently working thru ldap on the ldap server itself.
[root@VIRCENT03:~]#cat /etc/pam.d/sudo #%PAM-1.0 auth include system-auth auth required pam_ldap.so account include system-auth account required pam_ldap.so password include system-auth password required pam_ldap.so session optional pam_keyinit.so revoke session required pam_limits.so session required pam_ldap.so
AFAIK the above should get pam_ldap communicating with the LDAP server on the behalf of sudoers. the other pam configs (such as sshd and su) appear to be getting their info from the system auth which is currently communicating with the LDAP server.
Does anyone have any tips on how to get sudoers working through pam /ldap?
thanks!!
On Mon, Nov 8, 2010 at 4:29 PM, Aaron Richton richton@nbcs.rutgers.edu wrote:
On Mon, 8 Nov 2010, bluethundr wrote:
[root@VIRCENT03:~]#cat /etc/openldap/ldap.conf
[...]
TLS_CACERTDIR /etc/openldap/cacerts sudoers_base ou=sudoers,ou=Services,dc=acadaca,dc=net
I don't believe that "sudoers_base" is a recognized OpenLDAP configuration directive. As such, this line may belong in a file other than "/etc/openldap/ldap.conf" on your system.
On Monday, 8 November 2010 22:16:51 bluethundr wrote:
Hello List
I am attempting to setup various pam modules to consult our new LDAP services in order to do what it needs to do. My LDAP server is FreeBSD but the clients are CentOS...
I have setup my /etc/pam.d sudo
If you have already setup /etc/pam.d/system-auth for LDAP (e.g. with authconfig), you should not need to make changes to other pam service files.
However, it appears your problem isn't authentication:
but even tho the user is part of the %wheel group under LDAP it is unable to sudo to any other account (including root). If I try to sudo this is what happens:
[bluethundr@VIRCENT03:~]#sudo bash [sudo] password for bluethundr: bluethundr is not in the sudoers file. This incident will be reported.
So authentication works. PAM doesn't do anything further here ...
It would appear that sudo support for ldap is compiled in:
[root@VIRCENT03:~]#ldd $(which sudo)| grep -i ldap libldap-2.3.so.0 => /usr/lib/libldap-2.3.so.0 (0x00552000)
Well, now we are getting away from your $subject, which was asking about pam. This has *nothing* to do with PAM (applications wanting to authenticate via pam_ldap don't need to be linked to libldap).
This is how I setup my ldap.conf file
[root@VIRCENT03:~]#cat /etc/openldap/ldap.conf
[...]
sudoers_base ou=sudoers,ou=Services,dc=acadaca,dc=net
sudo+ldap looks for that in /etc/ldap.conf. Please don't mix /etc/ldap.conf and /etc/openldap/ldap.conf.
In my openldap logs on the LDAP server there appears to be no activity when I sudo. however in the secure logs on the client I do..
[..]
Works there!
These logs are irrelevant. More interesting would be the logs on the server- side, to see if *any* searches are done. However, the 'sudo -l' output may be useful.
I do see other events in secure.log that appear to be pam successes however. am i interpreting this correctly that at least part of the system is communicating with pam on the ldap server?
PAM seems to work, as your password is accepted. Nothing further relates to pam at all. Everything else relates *only* to sudo. Please read your /usr/share/doc/sudo-*/README.LDAP file. For example, the coverage of the 'sudoers_debug' option may be interesting.
Regards, Buchan
openldap-technical@openldap.org
-
Aaron Richton -
bluethundr -
Buchan Milne -
Chris Jacobs -
Indexer -
Prentice Bisbal