IDSync 6.0 Bug with updating passwords
I have noticed this problem with IDsync, does anyone know if this is a bug or feature? and if there is a workaround? Here is the bug and steps to reproduce it.
-User has a SSHA hash in DS using IDSync 6.0, aka, not his first time logging in to DS
-User changes password in AD, dsvalidate is set to "true", so the password should be updated.
-If user binds to DS with his new password, the hash is updated and dsvalidate is removed. This all works perfectly.
-But, if the user binds to DS and uses his old password, DS returns a successful bind(assuming it checks the current hash...therefore never looking to AD). This isn't horrible, but the problem is it also removes the dsvalidate field. This causes the passwords to be out of sync unless dsvalidate is set manually again.
I think DS should look to dsvalidate before it checks against the hash, and therefore should know that the current hash is DS is invalid and should look to AD no matter what. I am not sure why when the IDsync plugin sets dsvalidate to true, that it doesn't also invalidate the current hash?
This is causing problems because users have password saved in their email clients and the first time the log in after changing there AD password, that old password is attempted by email and although it works, then their passwords are out of sync.
Any incite or help is appreciated.
-Nick
[1415 byte] By [
Nick1472a] at [2007-11-27 8:20:29]
# 5
Sinha,
I set up the scenario and watched the logs and tried to grab as much as I could in sequential order. I know this probably won't help you debug my problem much, but I just wanted to give the a better idea of the order of event and show that the plug in was working successfully as well.
From Audit, Error and Access logs
Create New User:
time: 20070622105259
dn: cn=pass test,ou=***,dc=***
changetype: add
cn: pass test
sn: test
givenName: pass
displayName: pass test
uid: passtest
dspswuserlink:: EZKsz+oW0EewlJg3x2P/zw==
objectClass: dspswuser
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
objectClass: person
dspswloop: true
userPassword: {PSWSYNC}*ON-DEMAND*SYNCHRONIZATION*REQUIRED*
dspswvalidate: true
creatorsName: uid=pswconnector,dc=***
modifiersName: uid=pswconnector,dc=***
entrydn: cn=pass test,ou=***,dc=***
modifyTimestamp: 20070622145259Z
time: 20070622105300
dn: cn=pass test,ou=***,dc=***
delete: dspswloop
-
replace: modifiersname
modifiersname: uid=pswconnector,dc=***
replace: modifytimestamp
modifytimestamp: 20070622145300Z
Bind in for first time:
time: 20070622105300
dn: cn=pass test,ou=***,dc=***
changetype: modify
delete: dspswloop
-
replace: modifiersname
modifiersname: uid=pswconnector,dc=***
-
replace: modifytimestamp
modifytimestamp: 20070622145300Z
userPassword: {SSHA}rkOUETlMqRybQ9ALypk779g/gs//JSs57WxRDQ==
Change PW in AD:
time: 20070622110225
dn: cn=pass test,ou=***,dc=***
changetype: modify
replace: dspswvalidate
dspswvalidate: true
-
replace: dspswloop
dspswloop: true
-
replace: dspswloop
-
replace: modifiersname
modifiersname: uid=pswconnector,dc=***
-
replace: modifytimestamp
modifytimestamp: 20070622150225Z
-
[22/Jun/2007:11:02:25.595 -0400] FINE530 CNN101 **** "LDAP Modify Request: [REPLACE dspswvalidate: true] [REPLACE dspswloop: true] [REPLACE dspswloop: ] "
[22/Jun/2007:11:02:25.642 -0400] FINE530 CNN101 **** "Successfully modified user 'cn=pass test,ou=***,dc=***', action=Type: MODIFY SUL: MiscUsers {Data Attrs: [REPL dspswvalidate: true]}." (Action ID=CNN100-1134FA70F88-16, SN=7)
[22/Jun/2007:11:02:25.649 -0400] INFO530 CNN101 **** "Successfully modified user cn=pass test,ou=***,dc=***" (Action ID=CNN100-1134FA70F88-16, SN=8)
Bind With Old Password, Success: [note: hash does change, but it is a hash of old password and dsvalidate is not longer set]
[22/Jun/2007:11:03:49.684 -0400] INFO535 CNN101 **** "DS Plugin (SUBC100): on-demand validation has been successfully completed for 'cn=pass test,ou=***,dc=***' by authenticating the user against ldap://****:389"
dn: cn=pass test,ou=***,dc=***
dspswvalidate: [no value]
userPassword: {SSHA}GVKtDoIEbo1XQIFqPO2S70StyeemerM1D3DZaA==
Now try new password:
Fail,
dn: cn=pass test,ou=***,dc=***
pwdfailuretime: 20070622151105.0000001603Z
Reset Password again:
time: 20070622111741
dn: cn=pass test,ou=***,dc=***
changetype: modify
replace: dspswvalidate
dspswvalidate: true
-
replace: dspswloop
dspswloop: true
-
replace: dspswloop
-
replace: modifiersname
modifiersname: uid=pswconnector,dc=***
-
replace: modifytimestamp
modifytimestamp: 20070622151741Z
[22/Jun/2007:11:17:42.149 -0400] FINE527 CNN101 **** "LDAP Modify Request: [REPLACE dspswvalidate: true] [REPLACE dspswloop: true] [REPLACE dspswloop: ] "
[22/Jun/2007:11:17:42.202 -0400] FINE527 CNN101 **** "Successfully modified user 'cn=pass test,ou=***,dc=***', action=Type: MODIFY SUL: MiscUsers {Data Attrs: [REPL dspswvalidate: true]}." (Action ID=CNN100-1134FA70F88-17, SN=7)
[22/Jun/2007:11:17:42.206 -0400] INFO527 CNN101 **** "Successfully modified user cn=pass test,ou=***,dc=***" (Action ID=CNN100-1134FA70F88-17, SN=8)
Log in with New Password again to verify things also work as they should
[22/Jun/2007:11:20:03.889 -0400] INFO535 CNN101 **** "DS Plugin (SUBC100): on-demand validation has been successfully completed for 'cn=pass test,ou=***,dc=***' by authenticating the user against ldap://****:389"
dn: cn=pass test,ou=***,dc=***
userpassword: {SSHA}r8oWXeADpQQc3MSPwVyiBlTdauMRbgVt1zYXRQ==
Hopefully this will help. Let me know what you think or if you want me to try anything else.
Thanks, Nick
# 6
Bind With Old Password, Success: [note: hash does change, but it is a hash of old password and dsvalidate is not longer set]
[22/Jun/2007:11:03:49.684 -0400] INFO 535 CNN101 **** "DS Plugin (SUBC100): on-demand validation has been successfully completed for 'cn=pass test,ou=***,dc=***' by authenticating the user against ldap://****:389"
dn: cn=pass test,ou=***,dc=***
dspswvalidate: [no value]
userPassword: {SSHA}GVKtDoIEbo1XQIFqPO2S70StyeemerM1D3DZaA==
>> It seems that the plugin is somehow skipping the on-demand though it's printing the message ( I guess that the ldap://**:389 points to your AD setup..right?).
Other interesting thing to note is that the dspswvalidate isn't getting deleted in the case above. The plugin is just resetting it value. I would like to know if you have any special settings in DS in terms of password policy, history or anything like that.
It would be of great help if you can get us a reproducible testcase with all the steps clearly mentioned.
