Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1049029

Thanks for your report, Alberto.

Can we have your WindowsReplicationAgreement?

$ ldapsearch -LLLx -h localhost -p 489 -D 'cn=directory manager' -w password -b "cn=config" "(objectClass=nsDSWindowsReplicationAgreement)"

You wrote:

Changeg the OU of the user via windows to:
NEW DN: CN=Alberto Viana,OU=NEW,DC=homolog,DC=rnp
Does this mean you have
OU=TESTE,DC=homolog,DC=rnp
as well as
OU=NEW,DC=homolog,DC=rnp
and moved CN=Alberto Viana from OU=TESTE,DC=homolog,DC=rnp to OU=NEW,DC=homolog,DC=rnp on AD (Active Directory on Windows 2008 R2)?

Then, you see both uid=Alberto.Viana,OU=TESTE,DC=homolog,DC=rnp and uid=Alberto.Viana,OU=NEW,DC=homolog,DC=rnp on DS?

Next you deleted uid=Alberto.Viana,OU=TESTE,DC=homolog,DC=rnp on DS, then it deleted uid=Alberto.Viana,OU=NEW,DC=homolog,DC=rnp, as well?

389 DS deletes all users from the group on both sides (389DS and windows)
You don't mean other users (.e.g., uid=john.smith,ou=TESTE,DC=homolog,DC=rnp et. al.) by this "all users", but just uid=Alberto.Viana, I guess. Am I correct?

I have another question on this statement.

Just to let you know that I have others versions of 389DS running (389-Directory/1.3.1.3 and 389-Directory/1.2.10.12), and just the fact to change the DN/OU of one user in a group, deletes all users from this group (not from 389 DS).
You observed this same behavior on 1.2.10.12 and 1.3.1.3? And the behavior would be if you move a user (let's say "cn=test user) from ou=TESTE to ou=NEW on AD, then the user entry "cn=test user" was deleted an DS? (but you wrote not from 389 DS... I'm confused...)

We fixed a bug https://fedorahosted.org/389/ticket/355 for 1.2.11.12 and newer (including 1.3.1). You may want to take a look at the ticket. The fix introduced a config parameter winSyncMoveAction to WinSyncReplicationAgreement.
{{{
winSyncMoveAction has 3 values:
none - ignore moved entries (like older versions of DS)
delete - delete DS entries when the AD entry moves out of scope - like current
versions of DS
unsync - new behavior - if the DS entry is currently synced with the AD entry
this will cause the DS entry to be "unlinked" from the AD entry so
that they will no longer be in sync
The default value is "none" because we should not unexpectedly delete DS
entries (principle of least astonishment).
}}}
The symptom you described on 1.2.10.12 and 1.3.1.3 may be "winSyncMoveAction: delete". Could you please explicitly specify "winSyncMoveAction: unsync" and see if it solve your problem?
Thank you!!

Thanks for your report, Alberto.
Can we have your WindowsReplicationAgreement??
$ ldapsearch -LLLx -h localhost -p 489 -D 'cn=directory manager' -w password -b "cn=config" "(objectClass=nsDSWindowsReplicationAgreement)".

Here's my sync agreement:
dn: cn=AD - HMG1,cn=replica,cn=dc\3Dhomolog\2Cdc\3Drnp,cn=mapping tree,cn=config
objectClass: top
objectClass: nsDSWindowsReplicationAgreement
description:: U3luYyB3aXRoIEFEIA==
cn: AD - HMG1
nsds7WindowsReplicaSubtree: dc=homolog,dc=rnp
nsds7DirectoryReplicaSubtree: dc=homolog,dc=rnp
nsds7NewWinUserSyncEnabled: on
nsds7NewWinGroupSyncEnabled: on
nsds7WindowsDomain: homolog.rnp
nsDS5ReplicaRoot: dc=homolog,dc=rnp
nsDS5ReplicaHost: hmg1.homolog.rnp
nsDS5ReplicaPort: 636
nsDS5ReplicaBindDN: CN=Conta de sincronizacao do AD com LDAP 389,ou=APLICACOES,ou=RNP,dc=homolog,dc=rnp
nsDS5ReplicaTransportInfo: SSL
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaCredentials: {DES}Zdi9SkO9E8Jpy/LJq528zg==
nsds7DirsyncCookie:: TVNEUwMAAABMKiP45SDPAQAAAAAAAAAAKAAAAH6XAQAAAAAAAAAAAAAAA
AB+lwEAAAAAAHap0a4AZLVOiWVwbLI8XiEBAAAAAAAAAAEAAAAAAAAAdqnRrgBktU6JZXBssjxeIX
+XAQAAAAAA
nsds50ruv: {replicageneration} 52ab03c6000000010000
nsds50ruv: {replica 1 ldap://hmg3.homolog.rnp:389} 52ab0739000000010000 52ab0a
6c000200010000
nsruvReplicaLastModified: {replica 1 ldap://hmg3.homolog.rnp:389} 52ab0a6c
nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 20140203134144Z
nsds5replicaLastUpdateEnd: 20140203134144Z
nsds5replicaChangesSentSinceStartup:: MToxNC8wIA==
nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental upd
ate succeeded
nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 20131213164935Z
nsds5replicaLastInitEnd: 20131213164952Z
nsds5replicaLastInitStatus: 0 Total update succeeded

You wrote:
Changeg the OU of the user via windows to:
NEW DN: CN=Alberto Viana,OU=NEW,DC=homolog,DC=rnp
Does this mean you have
OU=TESTE,DC=homolog,DC=rnp as well as
OU=NEW,DC=homolog,DC=rnp
and moved CN=Alberto Viana from OU=TESTE,DC=homolog,DC=rnp to OU=NEW,DC=homolog,DC=rnp on AD (Active Directory on Windows 2008 R2)?.

Yes, I have both DN's OU=TESTE,DC=homolog,DC=rnp and OU=NEW,DC=homolog,DC=rnp. Yes I moved the user from OU=TESTE,DC=homolog,DC=rnp to OU=NEW,DC=homolog,DC=rnp on AD.

Then, you see both uid=Alberto.Viana,OU=TESTE,DC=homolog,DC=rnp and uid=Alberto.Viana,OU=NEW,DC=homolog,DC=rnp on DS?
Next you deleted uid=Alberto.Viana,OU=TESTE,DC=homolog,DC=rnp on DS, then it deleted >uid=Alberto.Viana,OU=NEW,DC=homolog,DC=rnp, as well?

No. DS moved/changed my user correctly, so there's only one user (uid=Alberto.Viana,OU=NEW,DC=homolog,DC=rnp), but DS did not upgrade in my group as below:

dn: cn=GSG_TESTE,ou=GRUPOS,ou=RNP,dc=homolog,dc=rnp
objectClass: top
objectClass: groupofuniquenames
objectClass: ntGroup
ntGroupDeleteGroup: true
cn: GSG_TESTE
uniqueMember: uid=alberto.viana,ou=TESTE,dc=homolog,dc=rnp
uniqueMember: uid=test1,ou=TESTE,dc=homolog,dc=rnp
uniqueMember: uid=test2,ou=FINC,dc=homolog,dc=rnp
uniqueMember: uid=jonh,ou=TI,dc=homolog,dc=rnp

389 DS deletes all users from the group on both sides (389DS and windows)
You don't mean other users (.e.g., uid=john.smith,ou=TESTE,DC=homolog,DC=rnp et. al.) by this "all users", but just uid=Alberto.Viana, I >guess. Am I correct?

No, when I remove this specific user from the group, DS removes all users from this group, so the group is completely empty on both sides(AD and 389DS).

Ldif that I used:
dn: cn=GSG_TESTE,ou=GRUPOS,ou=RNP,dc=homolog,dc=rnp
changetype: modify
delete: uniqueMember
uniqueMember: uid=alberto.viana,ou=TESTE,dc=homolog,dc=rnp

Just to remember that the user is still there (on DS and AD) -> uid=Alberto.Viana,OU=NEW,DC=homolog,DC=rnp

Am I made myself clear enough?

I have another question on this statement.
Just to let you know that I have others versions of 389DS running (389-Directory/1.3.1.3 and 389-Directory/1.2.10.12), and just the fact >to change the DN/OU of one user in a group, deletes all users from this group (not from 389 DS).
You observed this same behavior on 1.2.10.12 and 1.3.1.3? And the behavior would be if you move a user (let's say "cn=test user) from >ou=TESTE to ou=NEW on AD, then the user entry "cn=test user" was deleted an DS? (but you wrote not from 389 DS... I'm confused...)

I Observed a very similar behavior on 1.2.10.12 and 1.3.1.3. The behavior is if I move a user "cn=test user" from "ou=TESTE" to "ou=NEW" and this user belongs to the group "cn=GROUP_TEST" (with others users) on AD, DS removes all users from this group, so what I trying to say that user stills exists, but the group cn=GROUP_TEST is now empty on both sides (AD and DS).

I can reproduce the problem in my lab if you need.

I hope that I explained better this time

We fixed a bug ​https://fedorahosted.org/389/ticket/355 for 1.2.11.12 and newer (including 1.3.1). You may want to take a look at the >ticket. The fix introduced a config parameter winSyncMoveAction to WinSyncReplicationAgreement?.
winSyncMoveAction has 3 values:
none - ignore moved entries (like older versions of DS)
delete - delete DS entries when the AD entry moves out of scope - like current
versions of DS
unsync - new behavior - if the DS entry is currently synced with the AD entry
this will cause the DS entry to be "unlinked" from the AD entry so
that they will no longer be in sync
The default value is "none" because we should not unexpectedly delete DS
entries (principle of least astonishment).
The symptom you described on 1.2.10.12 and 1.3.1.3 may be "winSyncMoveAction: delete". Could you please explicitly specify >"winSyncMoveAction: unsync" and see if it solve your problem?
Thank you!!

I do not think that is my problem, because the user still exists. I was unable to give you a good explanation about it.

Bug Description: When an entry is moved on AD, and the entry is
a member of a group, the value of the member in the group is
automatically updated. But Windows Sync Control request only
returns the renamed entry; it does not return the group having
the member in it even though the value is updated. This is
because an AD group stores DNT (Distinguish Name Tag -- ID in
integer) instead of the dn itself. Since the rename operation
does not change DNT, the group entry on AD has no change, either.

On the DS side, the group entry stores the full DN which needs
to be adjusted to the renamed DN to complete the synchronization
with AD.

Fix Description: Once rename operation is received from AD,
windows_update_local_entry searches groups having a member value
matches the pre-renamed dn on DS, and replaces the old dn with the
renamed one.

{{{

5321                    /* Search entries which have pre-renamed members */ 
5322                    filter_string = PR_smprintf("(&(objectclass=ntGroup)(|(member=%s)(uniquemember=%s)))",  
5323                                                slapi_entry_get_ndn(orig_local_entry), 
5324                                                slapi_entry_get_ndn(orig_local_entry));

}}}
I think you will have to escape the filter values since the DNs may contain characters that have to be escaped in filters. See find_entry_by_attr_value() where it escapes the filter.
{{{

5361                                                            if (0 == strcasecmp(s, prev_member)) { 
5362                                                                    type = "member"; 
5363                                                                    break; 
5364                                                            }

}}}
Do you have to normalize s first?

If an attribute is a DN type, the value is normalized in the DS.
The "s" in strcasecmp is from the DS search result.
(Please search "valuearray_dn_normalize_value" in slapd.)
So, I think it's safe to call strcasecmp to compare...

Replying to [comment:12 nhosoi]:

If an attribute is a DN type, the value is normalized in the DS.
The "s" in strcasecmp is from the DS search result.
(Please search "valuearray_dn_normalize_value" in slapd.)
So, I think it's safe to call strcasecmp to compare...

ok

The fix looks good. I have two remarks.

I believe map_entry_dn_inbound_ext may return 0 but with NULL mapped_sdn (fail to match the entry and no 'username' (samAccountName) in the entry).
If it is possible it may crash when computing strlen(new_member).

If the moved entry belong to a group as 'member' and 'uniquemember', only 'member' attribute is updated. Why not 'uniquemember' ?

Replying to [comment:14 tbordaz]:

The fix looks good. I have two remarks.

I believe map_entry_dn_inbound_ext may return 0 but with NULL mapped_sdn (fail to match the entry and no 'username' (samAccountName) in the entry).
If it is possible it may crash when computing strlen(new_member).

A good catch! (If it occurred, even the current code had crashed here first... :p)
{{{
4717 / Compare the local and mapped RDNs if it is a group /
4718 / If they don't match, set it to newrdn. /
4719 if (is_group && strcmp(slapi_entry_get_ndn(local_entry),
4720 slapi_sdn_get_ndn(mapped_sdn))) {
}}}

I'm adding more error setting/check...
{{{
index ce817f1..2566ba4 100644
--- a/ldap/servers/plugins/replication/windows_protocol_util.c
+++ b/ldap/servers/plugins/replication/windows_protocol_util.c
@@ -4264,6 +4264,7 @@ map_entry_dn_inbound_ext(Slapi_Entry e, Slapi_DN dn, const Repl_Agmt ra, int
} else
{
/ Error, no username /
+ retval = ENTRY_NOTFOUND;
}
}
if (new_dn)
@@ -5242,7 +5243,7 @@ windows_update_local_entry(Private_Repl_Protocol prp,Slapi_Entry remote_entry,
* guid or username. We want to get the mapped DN just as we would
* if we were creating a new entry. /
retval = map_entry_dn_inbound_ext(remote_entry, &mapped_sdn, prp->agmt, 0 / use_guid /, 0 / use_username */);
- if (retval != 0) {
+ if (retval || (NULL == mapped_sdn)) {
slapi_log_error(SLAPI_LOG_REPL, windows_repl_plugin_name,
"unable to map remote entry to local DN\n");
return retval;
}}}

If the moved entry belong to a group as 'member' and 'uniquemember', only 'member' attribute is updated. Why not 'uniquemember' ?
Well, I believe member and uniquemember do not coexist in one entry. member belongs to groupOfNames and uniquemember does to groupOfUniqueNames. To be honest, I don't think both attrs are found in the search. I added it for the odd corner case (which I don't expect to see...)

git patch file (master; take 2) -- fixed NULL deref
0001-Ticket-47642-Windows-Sync-group-issues.2.patch

git patch file (master; take 2) -- fixed NULL deref
0001-Ticket-47642-Windows-Sync-group-issues.patch

Thanks to Thierry for pointing out the possibility of NULL dereference. The problem is fixed in https://fedorahosted.org/389/attachment/ticket/47642/0001-Ticket-47642-Windows-Sync-group-issues.patch.

Do you need to escape the filter values? I think even a normalized DN may contain characters that need to be escaped in a filter.

Replying to [comment:17 rmeggins]:

Do you need to escape the filter values? I think even a normalized DN may contain characters that need to be escaped in a filter.

You are right, Rich. I'm attaching a new patch (take 3)...

git patch file (master, take3) -- escape the search filter value
0001-Ticket-47642-Windows-Sync-group-issues.3.patch

Reviewed by Rich and Thierry (Thank you!!)

Pushed to master:
e5b83f5..98ddd81 master -> master
commit 98ddd81

Pushed to 389-ds-base-1.3.2:
56e3a09..86515d1 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit 86515d1

389-ds-base-1.3.1 & 1.2.11 requires the fix for Ticket #415 - winsync doesn't sync DN valued attributes if DS DN value doesn't exist

Pushed to 389-ds-base-1.2.11:
86fb137..737169e 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit 5324aec

Pushed to 389-ds-base-1.3.1:
377266e..8772ea1 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
commit ab4893c

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

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.