[Bug 171338] Enhancement: winsync modrdn not synce https://bugzilla.redhat.com/show_bug.cgi?id=171338 Problem Descriptions:Rename (modrdn) with newsuperior has not been implemented on the RH/389 DS. Therefore, even if entries were moved on AD, WinSync could not synchronize the change on the DS. Now, the functionality is being added to the DS. Using it, the rename operation should be able to get synchronized.
Fix Descriptions: windows_protocol_util.c: 1. Implemented process_replay_rename for DS --> AD rename (modrdn) synchronization. It checks the new local superior and the current remote superior. If they don't match, it calls windows_conn_send_rename. If the entry is a user, the leaf RDN on AD is ntUserDomainId, which is not the leafRDN on DS. Thus, newrdn passed to windows_conn_send_rename is the leaf RDN of
AD, which won't be changed in this process_replay_rename. If the entry is a group, the leaf RDN on AD is the same as the one on DS. Thus, newrdn is passed to windows_conn_send_rename. If the rename on AD failed by LDAP_NO_SUCH_OBJECT, the target entry might have been deleted on AD. To recover the problem, add the renamed entry to AD.2. Modified windows_update_local_entry to update the local entry if the rename
operation occurred on AD (AD --> DS). In the function, a code to checkthe local and remote superiors is added. If they don't match, the local entry is
renamed. Similar to DS --> AD, the rename only takes care of newsuperior change for a user; it could update both newrdn and newsuperior for a group. windows_connection.c: fixed a typo Proposed Fix: https://bugzilla.redhat.com/attachment.cgi?id=385774&action=diffgit diff ldap/servers/plugins/replication/{windows_connection.c, windows_protocol_util.c}
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-devel
