I have an OpenLDAP server setup. I currently have two users added to my server. As far as my testing goes, a single user instance work just perfectly. My first issue arise when i have two users on the LDAP repository.
Directly after adding my 2nd user, i have attempted to login to my linux machine, and it's always asking me to change password when it's the first login (which is perfect).
Although, when i log-in with my first temporary password, you can see in the output below that User2 is attempting to log in, but then when it's asking to change the password, it's attempting to change it for 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:
I beleive this is an issue with my ACL, so i will let you guys see what my current acls are on the 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
Now assuming it's not an issue with my ACL's, I am wondering if it's simply how I add users to my LDAP server. I normally add users using this command :
ldapadd -x -W -D "cn=admin,dc=domain,dc=com" -f user.ldif
Finally, here is the output on what there currently is on my server
[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
Both of your user definitions include
uidNumber: 16859. The scenario you describe where user2's password change actually updates the password for user1 is likely due to LDAP locating the user account for which to change the password by searching theuid, locating it in the user1 entry, and applying the new password. I'm not an expert with LDAP but it seems logical auidNumbercollision in LDAP would produce this result, though it seems odd for openLDAP to even allow two entries to have the same value for such a critical property.Thank you for providing details on your overall setup so a second set of eyes on the issue could spot the potential culprit.