2

I have an old Centos Directory Server and a new 389 Directory Server. I don't want to use sssd at the moment so lets keep that suggestion off the table.

I do the following my RHEL 6.4 servers:

authconfig --disablesssd --disablesssdauth --enablelocauthorize --enableldap --enableldapauth --ldapserver=ldap://**ldap02** --ldapbasedn=dc=example,dc=com --enablerfc2307bis --enableforcelegacy --update

It's broke and won't let me log in. It does show the correct info when I do an id

uid=3333(myname) gid=134(mygroup) groups=134(mygroup),887(sysadmin)

But if I point the authconfig at the old server and then change the ldap.conf settings afterwards it works:

authconfig --disablesssd --disablesssdauth --enablelocauthorize --enableldap --enableldapauth --ldapserver=ldap://**ldap01** --ldapbasedn=dc=example,dc=com --enablerfc2307bis --enableforcelegacy --update

Then I change /etc/pam_ldap.conf and /etc/openldap/ldap.conf to point to ldap02. Bingo I can log in, but it doesn't seem to acknowledge the sysadmin group I'm in.

uid=3333(myname) gid=134(mygroup) groups=134(mygroup)

The old server doesn't have the sysadmin group so that tells me that the server is still looking for info on ldap01 and doing authentication from ldap02.

To test that theory I changed my passwords on the old ldap01 server. Now I can only log in with the ldap02 password. But when I create a new user on ldap02 and do an id they don't show up and neither does a ldapsearch.

Anyone have any idea why the server is doing lookups on one server and authentication on another. This only effects my RHEL 6 servers. My RHEL 5 servers are working perfectly.

Here is the contents of pam_ldap.conf and ldap.conf

ssl start_tls
tls_checkpeer no
TLS_REQCERT allow
TLS_CACERTDIR /etc/openldap/cacerts
URI ldap://ldap02/
BASE dc=example,dc=com

Anyone know what's going on here?

Here is additional information:

    cat /etc/sysconfig/authconfig
IPADOMAINJOINED=no
USEMKHOMEDIR=no
USEPAMACCESS=no
CACHECREDENTIALS=yes
USESSSDAUTH=no
USESHADOW=yes
USEWINBIND=no
USEDB=no
FORCELEGACY=yes
USEFPRINTD=yes
FORCESMARTCARD=no
PASSWDALGORITHM=md5
USELDAPAUTH=yes
USEPASSWDQC=no
IPAV2NONTP=no
USELOCAUTHORIZE=yes
USECRACKLIB=yes
USEIPAV2=no
USEWINBINDAUTH=no
USESMARTCARD=no
USELDAP=yes
USENIS=no
USEKERBEROS=no
USESYSNETAUTH=no
USESSSD=no
USEHESIOD=no

I though it could also be a caching issue but nscd is stopped...


Well I found part of the problem finally. There was an entry in /etc/nslcd.conf for ldap01. I changed it and restarted nslcd and poof.. I can't log in again. I changed it back to the lda01 and I can log in with the ldap02's password again. This is so odd.

1

So the answer was that minimum installations of RHEL don't include ksh which is my default shell. I use ksh because of compatibility issues with our HP-UX machines that don't have Bash. Why the miminum install doesn't install all the basic shells is something that baffles me. I think I deserve to be downvoted to hell for not checking the secure log earlier. I assumed something like that would be in the messages log.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.