#47351 Passsync loops when updating password of locked user
Closed: wontfix None Opened 8 years ago by rcritten.

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:

  • Install IPA
  • Install Win2k3 with AD and a CA
  • Create winsync replication agreement
  • Set up Passsync
  • 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.
  • ipa user-disable ldaptest
  • Reset password in AD
  • Watch the 389-ds error log go wild.

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.

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

Metadata Update from @nhosoi:
- Issue assigned to nhosoi
- Issue set to the milestone: passsync 1.1.5

4 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

a year ago

Login to comment on this ticket.

Metadata