Duplicated using ipa 3.2 beta 1 release and Windows 2003 Server.
389-ds-base-1.3.0.5-1.fc18.x86_64
Passsync bits came from 389-ds wiki
Steps to reproduce:
These seem like the relevant logs in access:
[25/Apr/2013:15:30:46 -0400] conn=30 fd=67 slot=67 SSL connection from 192.168.166.24 to 192.168.166.46 [25/Apr/2013:15:30:46 -0400] conn=30 SSL 128-bit RC4 [25/Apr/2013:15:30:46 -0400] conn=30 op=0 BIND dn="uid=passsync,cn=sysaccounts,cn=etc,dc=greyoak,dc=com" method=128 version=3 [25/Apr/2013:15:30:46 -0400] conn=30 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=passsync,cn=sysaccounts,cn=etc,dc=greyoak,dc=com" [25/Apr/2013:15:30:46 -0400] conn=30 op=1 SRCH base="cn=users,cn=accounts,dc=greyoak,dc=com" scope=2 filter="(ntUserDomainId=ldaptest)" attrs=ALL [25/Apr/2013:15:30:46 -0400] conn=30 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [25/Apr/2013:15:30:46 -0400] conn=31 fd=68 slot=68 SSL connection from 192.168.166.24 to 192.168.166.46 [25/Apr/2013:15:30:46 -0400] conn=31 SSL 128-bit RC4 [25/Apr/2013:15:30:46 -0400] conn=31 op=0 BIND dn="uid=ldaptest,cn=users,cn=accounts,dc=greyoak,dc=com" method=128 version=3 [25/Apr/2013:15:30:46 -0400] conn=31 op=0 RESULT err=53 tag=97 nentries=0 etime=0 [25/Apr/2013:15:30:46 -0400] conn=31 op=1 UNBIND [25/Apr/2013:15:30:46 -0400] conn=31 op=1 fd=68 closed - U1 [25/Apr/2013:15:30:46 -0400] conn=30 op=2 MOD dn="uid=ldaptest,cn=users,cn=accounts,dc=greyoak,dc=com" [25/Apr/2013:15:30:46 -0400] conn=30 op=2 RESULT err=0 tag=103 nentries=0 etime=0 csn=51798466000000030000 [25/Apr/2013:15:30:46 -0400] conn=30 op=3 UNBIND [25/Apr/2013:15:30:46 -0400] conn=30 op=3 fd=67 closed - U1
couple of seconds of error log with error-level 8192 errors
I could duplicate the problem without IPA.
Steps Add user in AD, ldaptest change password in AD confirm that passsync is working by using ldapsearch against IPA, binding as the user. I double-checked passsync logs too. Just be sure everything is a-ok before proceeding. On DS: * enable Password Policy * inactivate ldaptest * On AD: * disable ldaptest * reset password
PassSync? --> DS scenario repeat endlessly: PassSync? binds as the specified DN and searches (ntUserDomainId=ldaptest), which is successful (connection 1). PassSync? binds as uid=ldaptest..., which usually fails with err=49 but now err=53 since the account is inactivated. * Using the connection 1, modify the password, which goes fine.
git patch file (master) 0001-Ticket-47351-Passsync-loops-when-updating-password-o.patch
Bug description: If a password of a user is updated/reset, whose account is disabled/inactivated on both AD and DS, the password update is endlessly repeated on AD and DS.
Fix description: A method CanBind in syncserv is used to determine modify password is needed in the first round as well as to check the modification was successful in the second round. The following modification in SyncPassword invokes the server side's WinSync plugin to send the modify back, and SyncPassword is invoked as the second round. If the return code from CanBind is not LDAP_INVALID_ CREDENTIALS (e.g., LDAP_UNWILLING_TO_PERFORM for the inactivated account), the second round CanBind wound not return LDAP_SUCCESS even if the password is correctly updated. That's said, if Can- Bind returns any error other than LDAP_INVALID_CREDENTIALS, we should defer the password update.
Note: Changes in passhook.cpp are all indentation fix.
Reviewed by Rich (Thank you!!)
Pushed to master: commit fb017b47317eb759da2625b3c2c798554b7de8ba
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=962574
Metadata Update from @nhosoi: - Issue assigned to nhosoi - Issue set to the milestone: passsync 1.1.5
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/688
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.