What to do about windows sync when AD entries move out of scope
On 08/22/2012 04:23 PM, Rich Megginson wrote:
On 08/22/2012 02:18 PM, Mark Reynolds wrote: On 08/22/2012 04:09 PM, Rich Megginson wrote: Let's say you have a windows sync agreement AD: cn=Users,dc=example,dc=com DS: ou=People,dc=example,dc=com Let's say you also have another user container in AD: cn=OtherUsers,dc=example,dc=com Let's say you have a user in AD in cn=Users in sync with a user in DS in ou=People. What should happen if you move the user in AD from cn=Users to cn=OtherUsers? Should DS "disconnect" the entry (i.e. remote the ntuser attributes) so the entry is no longer in sync? Should winsync do something else? Is it feasible to "mark" the entry as moved, or placed it in some kind of list, and then use a config option on whether to keep it in sync or not? When we receive the AD entry in a search request, we will know if there is a DS entry with the same userid, and whether or not the DS entry is in sync (i.e. has the ntuser attributes). Not sure what you mean by "mark" - maybe add some sort of attribute to the DS entry that says "hey, this entry has the same userid as an entry in AD but the AD entry is out of scope of the winsync agreement and/or the DS entry is not set up to be a winsync entry"? Yes, exactly. Maybe something like: "winsyncPreviousScope: cn=People, dc=example,dc=com"? Conversely, what should happen if a user is moved from cn=OtherUsers to cn=Users? Should DS treat it as adding a new user or "connect" an existing user if the userids match? Depending if it is "marked" or not, we would know what to do with it. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- Mark Reynolds Senior Software Engineer Red Hat, Inc mreynolds@redhat.com -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
What to do about windows sync when AD entries move out of scope
On 08/22/2012 04:31 PM, Mark Reynolds wrote:
On 08/22/2012 04:23 PM, Rich Megginson wrote: On 08/22/2012 02:18 PM, Mark Reynolds wrote: On 08/22/2012 04:09 PM, Rich Megginson wrote: Let's say you have a windows sync agreement AD: cn=Users,dc=example,dc=com DS: ou=People,dc=example,dc=com Let's say you also have another user container in AD: cn=OtherUsers,dc=example,dc=com Let's say you have a user in AD in cn=Users in sync with a user in DS in ou=People. What should happen if you move the user in AD from cn=Users to cn=OtherUsers? Should DS "disconnect" the entry (i.e. remote the ntuser attributes) so the entry is no longer in sync? Should winsync do something else? Is it feasible to "mark" the entry as moved, or placed it in some kind of list, and then use a config option on whether to keep it in sync or not? When we receive the AD entry in a search request, we will know if there is a DS entry with the same userid, and whether or not the DS entry is in sync (i.e. has the ntuser attributes). Not sure what you mean by "mark" - maybe add some sort of attribute to the DS entry that says "hey, this entry has the same userid as an entry in AD but the AD entry is out of scope of the winsync agreement and/or the DS entry is not set up to be a winsync entry"? Yes, exactly. Maybe something like: "winsyncPreviousScope: cn=People, dc=example,dc=com"? I meant: "winsyncPreviousScope: cn=Users, dc=example,dc=com" Conversely, what should happen if a user is moved from cn=OtherUsers to cn=Users? Should DS treat it as adding a new user or "connect" an existing user if the userids match? Depending if it is "marked" or not, we would know what to do with it. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- Mark Reynolds Senior Software Engineer Red Hat, Inc mreynolds@redhat.com -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users |
| All times are GMT. The time now is 12:00 AM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.