#2688 WinSync In FreeIPA 2.2 (2.1.90) Deletes Users matched from AD
Closed: Duplicate None Opened 11 years ago by jraquino.

Following the document here: https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/managing-sync-agmt.html#tab.sync-agmt-attrs

All users who's Active Directory samAccountName matched FreeIPA Uid's had their FreeIPA Uid's and Kerberos Principals deleted...

I double-checked /var/log/slapd-INSTANCE/audit and I can confirm that I see the MemberOf plugin Deleting the users from their previously associated Groups, but I DO NOT see any logs clearly showing the WinSync plugin deleting them. Ldap searches confirm that the users no longer exist in LDAP OR Kerberos...

Package Versions:
freeipa-server-selinux-2.1.90.rc1-0.fc16.x86_64
freeipa-server-2.1.90.rc1-0.fc16.x86_64
freeipa-admintools-2.1.90.rc1-0.fc16.x86_64
freeipa-client-2.1.90.rc1-0.fc16.x86_64
freeipa-python-2.1.90.rc1-0.fc16.x86_64
389-ds-base-libs-1.2.10.6-1.fc16.x86_64
389-ds-base-1.2.10.6-1.fc16.x86_64


I've been trying to reproduce - this is what I've done

  • set up 389-ds-base 1.2.10.latest
  • built ipa-winsync plugin from ipa-2-2 branch
  • set up winsync agreement with windows 2008 r2
  • add several users to 389 and to AD - some users in common, some not
  • do a total update of the sync agreement

after it completes, all users are as they should be - not really sure what to do at this point - can one of you guys run the server in gdb and reproduce the problem?

What is the newest 389-ds-base 1.2.10? Mine is listed as .6-1?
or
Perhaps we have different things in our agreements?

How did you setup the Agreement and what steps did you do to update?

I did:

  • ipa-replica-manage connect --winsync --binddn cn=administrator,cn=users,dc=example,dc=com --bindpw Windows-secret --passsync secretpwd --cacert /etc/openldap/cacerts/windows.cer adserver.example.com -v

Then:

$ ldapmodify -x -D "cn=directory manager" -w password

dn: cn=ipa-winsync,cn=plugins,cn=config
changetype: modify
replace: nsds7WindowsReplicaSubtree
nsds7WindowsReplicaSubtree: CN=People,DC=example,DC=com

modifying entry "cn=ipa-winsync,cn=plugins,cn=config"

And finally:

  • ipa-replica-manage force-sync --from==adserver.example.com

I am not using IPA at all - just trying with plain old 389 + the ipa winsync plugin.

Can you attach the output of

ldapsearch -x -D "cn=directory manager" -W -b cn=config objectclass=nsDSWindowsReplicationAgreement

and

ldapsearch -x -D "cn=directory manager" -W -b cn=config "cn=ipa-winsync"

?

still cannot reproduce - steps

  • fresh up-to-date f-16 machine
  • installed freeipa-server 2.1.90.rc1 and 389-ds-base 1.2.10.6 - note - did not set up with CA, DNS, or NTP
  • added tuser1 and tuser2 to IPA
  • added tuser2 and tuser3 to AD (win2008 r2)
  • ipa-replica-manage connect w2k8x8664.testdomain.com --winsync --binddn="cn=administrator,cn=users,dc=testdomain,dc=com" --bindpw=thepassword --cacert=/path/to/windowsCA.cer --win-subtree="cn=testusers,ou=Test OU,dc=testdomain,dc=com" --passsync=thepassword -p dmpasswd

Afterwards, ipa find-user and ldapsearch found all 3 users in IPA

Deleted the users from AD, waited a few minutes, users were deleted from IPA

Readded the users to IPA and AD, ran a re-initialize

found all 3 users in IPA

So I'm not really sure what to do at this point - I cannot reproduce the problem

This was related to the fact that JR was changing the subtree after the agreement was set up. winsync wasn't seeing the entries in scope so was deleting them on the ipa side. When I had duplicated it I had passed --subtree and perhaps I pointed to the wrong location.

This will be addressed in 389-ds-base in ticket https://fedorahosted.org/389/ticket/355

The most we'll need to do on the ipa side is set the n-v-r of 389-ds-base.

Currently targeted for 389-ds-base 1.3, moving to the 3.1 release.

This ticket is now superseded by #2927.

Replying to [comment:3 jraquino]:

What is the newest 389-ds-base 1.2.10? Mine is listed as .6-1?
or
Perhaps we have different things in our agreements?

How did you setup the Agreement and what steps did you do to update?

I did:

  • ipa-replica-manage connect --winsync --binddn cn=administrator,cn=users,dc=example,dc=com --bindpw Windows-secret --passsync secretpwd --cacert /etc/openldap/cacerts/windows.cer adserver.example.com -v

Ok. This creates the windows sync agreement entry e.g.

dn: cn=WSA,cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config
nsds7WindowsReplicaSubtree: cn=users,dc=example,dc=com
nsds7DirectoryReplicaSubtree: cn=users,cn=accounts,dc=example,dc=com

For the windows subtree, it takes the first namingContexts value from the AD root DSE "".

Then:

$ ldapmodify -x -D "cn=directory manager" -w password

dn: cn=ipa-winsync,cn=plugins,cn=config
changetype: modify
replace: nsds7WindowsReplicaSubtree
nsds7WindowsReplicaSubtree: CN=People,DC=example,DC=com

modifying entry "cn=ipa-winsync,cn=plugins,cn=config"

This would have done nothing (or given an error). I think you meant the replication agreement entry e.g.

dn: cn=WSA,cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config
changetype: modify
replace: nsds7WindowsReplicaSubtree
nsds7WindowsReplicaSubtree: CN=People,DC=example,DC=com

correct?

So under cn=Users and cn=People in AD, you have users that have userids that correspond to userids under cn=users,cn=accounts in IPA. And when you did the force-sync, was it the userids from cn=Users or cn=People that were deleted from IPA?

This is what is happening:

  • ipa-replica-manage connect creates the sync agreement entry for the default cn=users and starts the total update (re-initialize).
  • ldapmodify of nsds7WindowsReplicaSubtree changes the subtree in the middle of the update - so some of the updates should be ignored, depending on the timing
  • winsync sees that the entries being returned by the search are out of the scope of the current sync subtree, and deletes them

So there are really two bugs here:
1) improper handling of subtree change during init/update
2) should not delete entries

I think what should happen is that, if there is an update in progress, the init/update should complete with the original subtree, and store any subsequent subtree changes to be applied after the init/update is complete. And entries should only be deleted if actually deleted by a delete operation.

It seems that related ticket is closed. Can we close this one too?
See #2927

Metadata Update from @jraquino:
- Issue assigned to rcritten
- Issue set to the milestone: FreeIPA 3.0.1 (bug fixing)

7 years ago

Login to comment on this ticket.

Metadata