Eu tenho um antigo Centos Directory Server e um novo 389 Directory Server. Eu não quero usar sssd no momento, então vamos manter essa sugestão fora da mesa.
Eu faço os seguintes servidores do RHEL 6.4:
authconfig --disablesssd --disablesssdauth --enablelocauthorize --enableldap --enableldapauth --ldapserver=ldap://**ldap02** --ldapbasedn=dc=example,dc=com --enablerfc2307bis --enableforcelegacy --update
Está quebrado e não me permite fazer login. Ele mostra as informações corretas quando eu faço uma id
uid=3333(myname) gid=134(mygroup) groups=134(mygroup),887(sysadmin)
Mas se eu apontar o authconfig no servidor antigo e depois alterar as configurações do ldap.conf depois ele funciona:
authconfig --disablesssd --disablesssdauth --enablelocauthorize --enableldap --enableldapauth --ldapserver=ldap://**ldap01** --ldapbasedn=dc=example,dc=com --enablerfc2307bis --enableforcelegacy --update
Em seguida, altero /etc/pam_ldap.conf e /etc/openldap/ldap.conf para apontar para ldap02 . Bingo eu posso logar, mas parece não reconhecer o grupo sysadmin que eu estou dentro.
uid=3333(myname) gid=134(mygroup) groups=134(mygroup)
O servidor antigo não tem o grupo sysadmin, o que me diz que o servidor ainda está procurando por informações sobre ldap01 e fazendo autenticação do ldap02.
Para testar essa teoria, mudei minhas senhas no antigo servidor ldap01. Agora só posso fazer login com a senha ldap02. Mas quando eu crio um novo usuário em ldap02 e faço um id eles não aparecem e nem um ldapsearch.
Alguém sabe por que o servidor está fazendo pesquisas em um servidor e autenticando em outro. Isso afeta apenas meus servidores RHEL 6. Meus servidores RHEL 5 estão funcionando perfeitamente.
Aqui está o conteúdo de pam_ldap.conf e ldap.conf
ssl start_tls
tls_checkpeer no
TLS_REQCERT allow
TLS_CACERTDIR /etc/openldap/cacerts
URI ldap://ldap02/
BASE dc=example,dc=com
Alguém sabe o que está acontecendo aqui?
Veja informações adicionais se isso ajudar:
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
Eu pensei que também poderia ser um problema de cache, mas o nscd está parado ...
Bem, eu encontrei parte do problema finalmente. Havia uma entrada em /etc/nslcd.conf para ldap01. Eu mudei e reiniciei nslcd e poof .. não consigo logar novamente. Eu mudei de volta para o lda01 e eu posso logar com a senha do ldap02 novamente. Isso é tão estranho.
Portanto, a resposta foi que as instalações mínimas do RHEL não incluem o ksh, que é meu shell padrão. Eu uso o ksh por causa de problemas de compatibilidade com nossas máquinas HP-UX que não possuem Bash. Por que a instalação do miminum não instala todos os shells básicos é algo que me deixa perplexo. Eu acho que mereço ser downvoted para o inferno por não verificar o secure log anterior. Eu presumi que algo assim estaria no messages log.
Tags authentication ldap rhel