https://fedorahosted.org/389/ticket/428https://fedorahosted.org/389/attachment/ticket/428/0001-Ticket-428-posix-wi…
Description: User/group entries added to DS do not have their
posix attributes synced to AD. This is due to a limitation in
the winsync v1 api. The v2 and later api support a pre add
callback for DS to AD entries.
This patch was originally provided by
From: Carsten Grzemba <cgrzemba(a)opencsw.org>
Date: Fri, 25 Jan 2013 14:59:32 +0100
Subject: ticket 428: add initial sync from DS to AD
Thank you for your contribution, Carsten!
It was reviewed and couple of minor bugs were fixed by nhosoi.
1) Commented out posix_group_del_memberuid_callback in
posix-group-task.c to clean up a compiler warning.
2) In posix_winsync_pre_ad_add_user_cb and posix_winsync_
pre_ad_add_group_cb, nisdomainname is added to the
to-be-added-to-AD entry only if nisdomainname is given.
3) In +posix_winsync_pre_ad_add_group_cb, a local variable
to scan array attr_map was unexpectedly shared with the
outer for loop for getting attribute value.
https://fedorahosted.org/389/ticket/47327https://fedorahosted.org/389/attachment/ticket/47327/0001-Ticket-47327-erro…
Bug description: Windows Sync synchronizes member attributes
in a group entry if the member entry itself is synchronized.
The entries in the sync scope are basically to be synchronized.
But there is an exception such as a container in the scope is
not synchronized due to the objecttype constraints. Such an
unsync'ed entry could have users in it. Users are the target
of Windows Sync. But since the parent container is not synch-
ronized, the users in the container are not, neither. If a
group contains such special user as a member, synchronization
failed there and the other normal members are failed to get
synchronized.
Fix description: Windows Sync has a helper function
is_subject_of_agreement_remote, which checks if the entry is
in the scope to be synchronized. This patch adds the check
if the checking entry's parent locally exists in the DS. If
it does not exist, it considers the entry is out of scope.
AD strictly checks if the entry exists prior to adding it
to a group entry as a member. That is, a member to be added
is supposed to be in the server, as well as its parent is.
With this change, the AD user which is not synchronized to
the DS is just skipped to add to the group in the DS in the
same manner as an user out of scope is.
This fix proposal is a bit different from the discussion on the ticket 47327. I thought it is straightforward that we handle the in-scope but not-sync'ed DN in the same way as out-of-scope DN.