someone reminded me that i was missing the posix account information I needed i LDAP.
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: [bluethu...@lcen0t02:~]$: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 [r...@lcen0t02:/usr/local/etc/openldap]#tail -f /var/log/openldap.log Oct 11 02:12:44 LCEN0T02 slapd[42790]: conn=1000 op=1 RESULT tag=97 err=49 text= Oct 11 02:12:44 LCEN0T02 slapd[42790]: conn=1000 op=2 UNBIND Oct 11 02:12:44 LCEN0T02 slapd[42790]: conn=1000 fd=11 closed Oct 11 02:17:01 LCEN0T02 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 LCEN0T02 slapd[42790]: conn=1001 op=0 BIND dn="cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" method=128 Oct 11 02:17:01 LCEN0T02 slapd[42790]: conn=1001 op=0 RESULT tag=97 err=49 text= Oct 11 02:17:01 LCEN0T02 slapd[42790]: conn=1001 op=1 BIND dn="cn=pam_ldap,ou=Services,dc=summitnjhome,dc=com" method=128 Oct 11 02:17:01 LCEN0T02 slapd[42790]: conn=1001 op=1 RESULT tag=97 err=49 text= Oct 11 02:17:01 LCEN0T02 slapd[42790]: conn=1001 op=2 UNBIND Oct 11 02:17:01 LCEN0T02 slapd[42790]: conn=1001 fd=11 closed this is what is going on in the message logs: Oct 11 02:12:44 LCEN0T02 su: pam_ldap: error trying to bind (Invalid credentials) Oct 11 02:12:44 LCEN0T02 su: pam_ldap: error trying to bind (Invalid credentials) Oct 11 02:12:44 LCEN0T02 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::: On Sat, Oct 9, 2010 at 4:36 PM, Tim Dunphy <bluethu...@gmail.com> wrote: > Hey guys! > > Unfortunately I have a new wrinkle. While I certainly got to make my > sudoers work through LDAP (thanks to those who helped) unfortunately > PAM is unhappy at the moment. > > So, while sudo is working in ldap, 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: > > > > [bluethu...@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 LCENT01 su: pam_ldap: error trying to bind (Invalid > credentials) > Oct 9 20:25:11 LCENT01 su: pam_ldap: error trying to bind (Invalid > credentials) > Oct 9 20:25:11 LCENT01 su: in _openpam_check_error_code(): > pam_sm_acct_mgmt(): unexpected return value 11 > Oct 9 20:25:11 LCENT01 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: > > > LCENT01# 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( > > > On Fri, Oct 8, 2010 at 11:01 PM, Scott Robbins <scot...@nyc.rr.com> wrote: >> On Fri, Oct 08, 2010 at 10:52:54PM -0400, Tim Dunphy wrote: >>> I just recopied openLDAP.schema as sudoers.schema and added it to slapd.conf >>> >>> >>> [bluethu...@bluethundr-desktop:~/txt/ldif ] $:ldapadd -h ldap -a -W -x >>> -D "cn=Manager,dc=summitnjhome,dc=com" -f >>> /home/bluethundr/txt/sudoers2.ldif >>> adding new entry >>> "cn=%summitnjops,ou=sudoers,ou=Services,dc=summitnjhome,dc=com" >> >> <snip> >>> >>> MAJOR WIN and THANKS to scott !!! >> >> Glad you got it sorted and you're more than welcome. >> >> >> -- >> Scott Robbins >> PGP keyID EB3467D6 >> ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) >> gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 >> >> Buffy: Oh, look at my poor neck... all bare and tender and >> exposed. All that blood, just pumping away. >> Giles: Oh, please. >> Spike: Giles, make her stop! >> Giles: If those two don't kill each other, I might lend a hand. >> >> _______________________________________________ >> CentOS mailing list >> CentOS@centos.org >> http://lists.centos.org/mailman/listinfo/centos >> > > > > -- > Here's my RSA Public key: > gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 > > Share and enjoy!! > -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!! _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos