#47443 Winsync replication fails with single label domain names.
Closed: wontfix None Opened 10 years ago by jcarloscamargo.

Winsync replication marks matched entries as "out of scope" when nsds7WindowsReplicaSubtree is set at the top of the Active Directory tree and the domain name is single-labeled (SLD).

1.- Same replication agreement created on a 1.2 version works fine against the same SLD active directory tree.

2.- Replication agreements work on a 1.3 version if nsds7WindowsReplicaSubtree is set deeper on the tree.


I installed 389-ds-base-1.2.11 and set up Windows Sync against AD on Windows2008R2.

I configured the agreement with the AD's top suffix like this (I have only one suffix):
nsds7WindowsReplicaSubtree: dc=EXAMPLE,dc=COM

Is it different from your working case?

Then, I did total update, which did not fail, but did not sync anything.
[] NSMMReplicationPlugin - Beginning total update of replica "agmt="cn=trac47443" (192:389)".
[] NSMMReplicationPlugin - Finished total update of replica "agmt="cn=trac47443" (192:389)". Sent 0 entries

Probably, I'm missing something. To reproduce the issue you are facing, could you attach your nsDSWindowsREplicationAgreement on 1.2.x as well as the error log on 1.3.x to this ticket?

Also, if you had to modify schema and prepare anything else on the DS, please share them with us.
Thanks!

Replying to [comment:3 nhosoi]:

I installed 389-ds-base-1.2.11 and set up Windows Sync against AD on Windows2008R2.

I configured the agreement with the AD's top suffix like this (I have only one suffix):
nsds7WindowsReplicaSubtree: dc=EXAMPLE,dc=COM

Is it different from your working case?

I believe that you need to set up AD with a single-label domain name, like "EXAMPLE" instead of "EXAMPLE.COM". You are currently using what AD refers to as a FQDN domain name, as it has multiple domain components.

I've installed Windows 2003R2 with the Domain "single" (suffix: dc=single).

I could successfully synchronize (both total update and incremental update) between 389-ds-base and AD.

$ ldapsearch <389-ds-base options> -b "ou=people,dc=single" "(uid=*user0)" dn
dn: uid=dsuser0,ou=People,dc=single <== added to 389-ds-base
dn: uid=aduser0,ou=People,dc=single <== added to AD

$ ldapsearch <AD options> -b "cn=users,dc=single" "(cn=*user0)" dn
dn: CN=ds user0,CN=Users,DC=SINGLE
dn: CN=ad user0,CN=Users,DC=SINGLE

jcarloscamargo: What's the versions of your Windows? Probably, your windows sync agreement and error log(s) might help us to figure out what's missing in our test env?

jcarloscamargo: Hi, again.

Do you still have the problem?
If yes, could you provide us the info on your environment, config file and error logs?
. Version of Windows
. rpm -q 389-ds-base
. /etc/dirsrv/slapd-ID/dse.ldif (especially, nsDSWindowsReplicationAgreement entry)
. /var/log/dirsrv/slapd-ID/errors*

Thanks.

Since we cannot reproduce the problem, closing this ticket for now.

Please feel free to reopen it with a reproducer if it is still a problem.

Metadata Update from @nhosoi:
- Issue assigned to nhosoi
- Issue set to the milestone: 1.3.4 backlog

7 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/780

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: Invalid)

3 years ago

Login to comment on this ticket.

Metadata