Hi All,
I am having an issue with 389DS after an upgrade and I was hoping someone could help me out. According to people on the 389 IRC Channel, someone has had this before.
Firstly, please understand I am a little out of my league, so please be patient.
So this afternoon, our RHEL5 box did a yum update which included 389DS. But after the upgrade, user's can't login using profiles in ldap. All the data is there, but it seems that the password fields are messed.
As an example, our apache websites use Directory Server for Authentication. If I take any of the usernames and passwords that exist and try login, I get a "password mismatch" in apache. I.e. wrong password. This worked before the upgrade.
But .. If I, using Apache Directory Studio, edit the password on one of those profiles, and commit. That person can login.
Its as if the password attributes data is corrupted, and has to be manually reset to work again. Users can't even reset their own passwords, as the Perl module (Net::LDAP) can modify the password value, but it still won't let them login. I can even use Directory studio to verify the password, and its correct. Seems the only way I can use a password is if I use Directory Studio to change it.
Has anyone has this? Or know where I can start looking, or how to fix it?
Not sure what other information I need to give.
Thanks,
Theunis
Theunis De Klerk wrote:
Hi All,
I am having an issue with 389DS after an upgrade and I was hoping someone could help me out. According to people on the 389 IRC Channel, someone has had this before.
Firstly, please understand I am a little out of my league, so please be patient.
So this afternoon, our RHEL5 box did a yum update which included 389DS.
32-bit or 64-bit?
But after the upgrade, user’s can’t login using profiles in ldap.
I'm not sure what you mean by "using profiles in ldap".
Does ldapsearch work? Can you try /usr/bin/ldapsearch -x -D "uid=username,ou=people,dc=yoursuffix,dc=com" -w thepassword -s base -b "" ?
All the data is there, but it seems that the password fields are messed.
As an example, our apache websites use Directory Server for Authentication. If I take any of the usernames and passwords that exist and try login, I get a “password mismatch” in apache. I.e. wrong password. This worked before the upgrade.
But …. If I, using Apache Directory Studio, edit the password on one of those profiles, and commit. That person can login.
Its as if the password attributes data is corrupted, and has to be manually reset to work again. Users can’t even reset their own passwords, as the Perl module (Net::LDAP) can modify the password value, but it still won’t let them login. I can even use Directory studio to verify the password, and its correct. Seems the only way I can use a password is if I use Directory Studio to change it.
Has anyone has this? Or know where I can start looking, or how to fix it?
Not sure what other information I need to give.
Thanks,
Theunis
-- 389 users mailing list 389-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
32-bit or 64-bit?
64-bit.
I'm not sure what you mean by "using profiles in ldap".
A person is technically just an entry with attributes.
Does ldapsearch work? Can you try /usr/bin/ldapsearch -x -D "uid=username,ou=people,dc=yoursuffix,dc=com" -w thepassword -s base -b "" ?
Yes that works fine. That's what I don't get. All the data is there! I can even search for a user and all their information is there. Even the password.
Theunis De Klerk wrote:
32-bit or 64-bit?
64-bit.
I'm not sure what you mean by "using profiles in ldap".
A person is technically just an entry with attributes.
Does ldapsearch work? Can you try /usr/bin/ldapsearch -x -D "uid=username,ou=people,dc=yoursuffix,dc=com" -w thepassword -s base -b "" ?
Yes that works fine.
Wait - you mean ldapsearch -D "uid=username,ou=people,dc=yoursuffix,dc=com" -w thepassword works? So the user is able to successfully authenticate using the password after upgrade using ldapsearch? Just not with some other tool? * ldapsearch works * OS login fails * Apache mod_ldap fails * other apps?
I'm trying to figure out what the common thread is here.
For the apps that fail - can you take a look at the directory server access log in /var/log/dirsrv/slapd-instance/access and see what the sequence of operations is? I just want to see if those apps are attempting to retrieve the userPassword attribute and doing the password comparison themselves, or using the LDAP Compare operation, rather than just doing an LDAP BIND operation with the clear text password (which is what ldapsearch -x -D "dn" -w cleartextpw does
That's what I don't get. All the data is there! I can even search for a user and all their information is there. Even the password.
-- 389 users mailing list 389-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Wait - you mean ldapsearch -D "uid=username,ou=people,dc=yoursuffix,dc=com" -w thepassword works? So the user is able to successfully authenticate using the password after upgrade using ldapsearch? Just not with some other tool?
- ldapsearch works
- OS login fails
- Apache mod_ldap fails
- other apps?
Yes, if I do an ldapsearch for a specific user, I get all their details just fine. If I use Apache Directory Studio, also fine. Those are the only to that I can test with to get information out of the directory server. Apache is set to authenticate certain website from the Directory Server. And that's where it fails. Apache is the only one that uses the directory server for authentication. Postfix does as well, but none of the users have email accounts.
I'm trying to figure out what the common thread is here.
For the apps that fail - can you take a look at the directory server access log in /var/log/dirsrv/slapd-instance/access and see what the sequence of operations is? I just want to see if those apps are attempting to retrieve the userPassword attribute and doing the password comparison themselves, or using the LDAP Compare operation, rather than just doing an LDAP BIND operation with the clear text password (which is what ldapsearch -x -D "dn" -w cleartextpw does
There is nothing in the dirsrv access log. But there is this in the apache logs: auth_ldap authenticate: user user@domain.com authentication failed; URI /profile/ [ldap_simple_bind_s() to check user credentials failed][Invalid credentials], referer: https://www.domain.com/profile/ mod_auth_form: user 'user@domain.com': authentication failure for "/profile/": password Mismatch, referer: https://www.domain.co.za/profile/
Does that help?
And here is a curve ball that makes no sense, might be useless information, but anyway. If do a search on uid=username,ou=people,dc=yoursuffix,dc=com. All their correct information is there. So the data itself looks perfect. But if I take their uid and password and try login via apache, I get the above error. Makes sense, the password could be wrong or data corruption. Apache Directory Studio has a feature where you can verify a password field. So I put in the password that I just tried to login with and it verifies! i.e. Apache Directory Studio tells me the password for that user is correct. Then just to make it interesting, if copy and paste, that exact password (that wouldn't let me login via apache, but verified on Apache Directory Studio) and create a new password via Apache Directory Studio for that same user, apache then lets me login. Which is exactly why I think its data corruption, cause as soon as Apache Directory Studio writes to the password field, it 'repairs' the field.
Theunis De Klerk wrote:
Wait - you mean ldapsearch -D "uid=username,ou=people,dc=yoursuffix,dc=com" -w thepassword works? So the user is able to successfully authenticate using the password after upgrade using ldapsearch? Just not with some other tool?
- ldapsearch works
- OS login fails
- Apache mod_ldap fails
- other apps?
Yes, if I do an ldapsearch for a specific user, I get all their details just fine.
I don't mean ldapsearch _for_ a specific user - I mean ldapsearch _as_ a specific user - ldapsearch -x -D "uid=username,..." -w cleartextpassword
This will send the LDAP BIND operation with the user's DN and clear text password i.e. will test the internal directory server password comparison code.
If I use Apache Directory Studio, also fine. Those are the only to that I can test with to get information out of the directory server. Apache is set to authenticate certain website from the Directory Server. And that's where it fails. Apache is the only one that uses the directory server for authentication. Postfix does as well, but none of the users have email accounts.
I'm trying to figure out what the common thread is here.
For the apps that fail - can you take a look at the directory server access log in /var/log/dirsrv/slapd-instance/access and see what the sequence of operations is? I just want to see if those apps are attempting to retrieve the userPassword attribute and doing the password comparison themselves, or using the LDAP Compare operation, rather than just doing an LDAP BIND operation with the clear text password (which is what ldapsearch -x -D "dn" -w cleartextpw does
There is nothing in the dirsrv access log. But there is this in the apache logs: auth_ldap authenticate: user user@domain.com authentication failed; URI /profile/ [ldap_simple_bind_s() to check user credentials failed][Invalid credentials], referer: https://www.domain.com/profile/ mod_auth_form: user 'user@domain.com': authentication failure for "/profile/": password Mismatch, referer: https://www.domain.co.za/profile/
Does that help?
Yes. It means apache is using the LDAP BIND operation to authenticate the user, which is what ldapsearch does.
And here is a curve ball that makes no sense, might be useless information, but anyway. If do a search on uid=username,ou=people,dc=yoursuffix,dc=com. All their correct information is there. So the data itself looks perfect. But if I take their uid and password and try login via apache, I get the above error. Makes sense, the password could be wrong or data corruption. Apache Directory Studio has a feature where you can verify a password field. So I put in the password that I just tried to login with and it verifies! i.e. Apache Directory Studio tells me the password for that user is correct. Then just to make it interesting, if copy and paste, that exact password (that wouldn't let me login via apache, but verified on Apache Directory Studio) and create a new password via Apache Directory Studio for that same user, apache then lets me login. Which is exactly why I think its data corruption, cause as soon as Apache Directory Studio writes to the password field, it 'repairs' the field.
I'm still trying to reproduce this problem. el5 i386 does not have the problem - now trying el5 x86_64
-- 389 users mailing list 389-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
I'm still trying to reproduce this problem. el5 i386 does not have the problem - now trying el5 x86_64
Well, I got 1 step closer. Along with users not being able to login, when they reset their passwords (done via a perl module; which worked before the upgrade), it would update ldap, but they still couldn't login. Then taking a shot in the dark in the code that updated/created the password instead of passing an SSHA'd password to ldap update command, I now pass a plaintext password and it works.
Is it possible that in the latest 389 version, that the values for the userPassword attributes are being stored/read differently?
Theunis De Klerk wrote:
I'm still trying to reproduce this problem. el5 i386 does not have the problem - now trying el5 x86_64
Well, I got 1 step closer. Along with users not being able to login, when they reset their passwords (done via a perl module; which worked before the upgrade), it would update ldap, but they still couldn't login. Then taking a shot in the dark in the code that updated/created the password instead of passing an SSHA'd password to ldap update command, I now pass a plaintext password and it works.
Is it possible that in the latest 389 version, that the values for the userPassword attributes are being stored/read differently?
Yes. The upgrade doesn't touch the actual data, but 1.2.1 may have slightly altered the way password comparisons are done.
In general, you should always pass the clear text password to the directory server, and let it hash it and compare it. This also allows you to use the password policy features of the directory server (e.g. password syntax checking does not work with pre-hashed passwords).
Were these applications that pre-hashed the SSHA passwords, then sent the pre-hashed SSHA password to the server, when adding a user or modifying the password? If so, then it could be that the legacy SSHA handling was broken.
-- 389 users mailing list 389-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
In general, you should always pass the clear text password to the directory server, and let it hash it and compare it. This also allows you to use the password policy features of the directory server (e.g. password syntax checking does not work with pre-hashed passwords).
Oh.
Were these applications that pre-hashed the SSHA passwords, then sent the pre-hashed SSHA password to the server, when adding a user or modifying the password? If so, then it could be that the legacy SSHA handling was broken.
They were pre-hashed, and sent in the pre-hash format to the add and modify commands.
Were these applications that pre-hashed the SSHA passwords, then sent the pre-hashed SSHA password to the server, when adding a user or modifying the password? If so, then it could be that the legacy SSHA handling was broken.
Here is an example of the perl code I used to create the password.
<snip> my $password = 'thepassword'; use Digest::SHA1; use MIME::Base64; my $ctx = Digest::SHA1->new; $ctx->add($password); $ctx->add('salt'); my $hashedPasswd = '{SSHA}' . encode_base64($ctx->digest . 'salt' ,''); </snip>
i.e: the way not to do it.
Theunis De Klerk wrote:
Were these applications that pre-hashed the SSHA passwords, then sent the pre-hashed SSHA password to the server, when adding a user or modifying the password? If so, then it could be that the legacy SSHA handling was broken.
Here is an example of the perl code I used to create the password.
<snip> my $password = 'thepassword'; use Digest::SHA1; use MIME::Base64; my $ctx = Digest::SHA1->new; $ctx->add($password); $ctx->add('salt'); my $hashedPasswd = '{SSHA}' . encode_base64($ctx->digest . 'salt' ,''); </snip>
i.e: the way not to do it.
thanks - https://bugzilla.redhat.com/show_bug.cgi?id=518520
-- 389 users mailing list 389-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
389-users@lists.fedoraproject.org
-
Rich Megginson -
Theunis De Klerk