LDAP que altera a senha do usuário errado?

2

Eu tenho uma configuração do servidor OpenLDAP. Atualmente tenho dois usuários adicionados ao meu servidor. No que diz respeito aos meus testes, uma única instância de usuário funciona perfeitamente. Meu primeiro problema surge quando eu tenho dois usuários no repositório LDAP.

Logo após adicionar meu segundo usuário, tentei fazer o login na minha máquina linux, e ele sempre me pede para alterar a senha quando é o primeiro login (o que é perfeito).

Embora, ao fazer login com minha primeira senha temporária, você possa ver na saída abaixo que Usuário2 está tentando efetuar login , mas quando está pedindo para alterar a senha, > está tentando mudá-lo para o User1 .

login as: user2
Authenticating with public key "user2-rsa-key"
Further authentication required
[email protected]'s password:
You are required to change your password immediately (root enforced)
You are required to change your LDAP password immediately.
Last login: 'Date' From 'Hostname'
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for user user1.    <----- This is where it messes up !
Enter login(LDAP) password:

Acredito que este é um problema com minha ACL, então deixarei que vocês vejam quais são as minhas acls atuais no olcDatabase = {2} bdb.ldif

olcAccess: {0}to attrs=userPassword by self write by dn.base="cn=admin,dc=domain,dc=com" write by anonymous auth by * none
olcAccess: {1}to * by dn.base="cn=admin,dc=domain,dc=com" write by self write by * read

Agora, supondo que não seja um problema com as ACLs, estou imaginando se é simplesmente como eu adiciono usuários ao meu servidor LDAP. Eu normalmente adiciono usuários usando este comando:

ldapadd -x -W -D "cn=admin,dc=domain,dc=com" -f user.ldif 

Finalmente, aqui está a saída do que existe atualmente no meu servidor

[root@localhost ~]# ldapsearch -x -W -D "cn=admin,dc=domain,dc=com" -b "dc=domain,dc=com" "(objectclass=*)"
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=domain,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# domain.com
dn: dc=domain,dc=com
objectClass: dcObject
objectClass: organization
o: domain.com
dc: domain
# users, domain.com
dn: ou=users,dc=domain,dc=com
objectClass: organizationalUnit
objectClass: top
ou: users
# groups, domain.com
dn: ou=groups,dc=domain,dc=com
objectClass: organizationalUnit
objectClass: top
ou: groups
# user1, users, domain.com
dn: uid=user1,ou=users,dc=domain,dc=com
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: ldapPublicKey
cn: user1
uid: user1
uidNumber: 16859
gidNumber: 100
homeDirectory: /home/user1
loginShell: /bin/bash
gecos: user1
shadowMax: 0
shadowWarning: 0
sshPublicKey: some rsa keys
userPassword:: crypted password
shadowLastChange: 16991

# user2, users, domain.com
dn: uid=user2,ou=users,dc=domain,dc=com
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: ldapPublicKey
cn: user2
uid: user2
uidNumber: 16859
gidNumber: 100
homeDirectory: /home/user2
loginShell: /bin/bash
gecos: user2
shadowLastChange: 0
shadowMax: 0
shadowWarning: 0
sshPublicKey: some rsa keys
userPassword:: crypted password
# search result
search: 2
result: 0 Success
# numResponses: 6
# numEntries: 5
    
por Stacknerd 10.07.2016 / 03:14

1 resposta

2

Ambas as definições do usuário incluem uidNumber: 16859 . O cenário que você descreve onde a mudança de senha do user2 na verdade atualiza a senha para user1 provavelmente é devido ao LDAP localizar a conta de usuário para a qual alterar a senha pesquisando o uid , localizando-o na entrada user1 e aplicando a nova senha. Eu não sou um especialista com LDAP, mas parece lógico que uma colisão de uidNumber no LDAP produziria esse resultado, embora pareça estranho para o openLDAP permitir que duas entradas tenham o mesmo valor para uma propriedade tão crítica.

Obrigado por fornecer detalhes sobre sua configuração geral para que um segundo par de olhos sobre o assunto possa identificar o possível culpado.

    
por 29.08.2016 / 13:08