Bug 818762
Summary: | winsync should not delete entry that appears to be out of scope | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Rich Megginson <rmeggins> |
Component: | 389-ds-base | Assignee: | Rich Megginson <rmeggins> |
Status: | CLOSED ERRATA | QA Contact: | Sankar Ramalingam <sramling> |
Severity: | urgent | Docs Contact: | |
Priority: | urgent | ||
Version: | 6.4 | CC: | cww, dpal, jgalipea, jr.aquino, mkubik, nkinder, rrivera, syeghiay |
Target Milestone: | rc | Keywords: | ZStream |
Target Release: | 6.4 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | 389-ds-base-1.2.11.12-1.el6 | Doc Type: | Bug Fix |
Doc Text: |
Cause: Having an entry in DS with the same user/group name as an entry in AD but the entry in AD is out of scope of the Windows sync agreement, either because it was already there, or it was moved.
Consequence: The DS entry is deleted.
Fix: Allow the user to specify the behavior of out of scope AD entries with the new DS attribute for the Windows sync agreement entry, winSyncMoveAction. If the value is "none", an out of scope AD entry will do nothing to the corresponding DS entry. If the value is "delete", an out of scope AD entry will delete the corresponding DS entry. If the value is "unsync", an out of scope AD entry will be un-synchronized with the corresponding DS entry - changes made to either entry will not be sync'd. The default value is "none" which solves the original problem of deleted entries.
Result: By default, the DS entry is not deleted when the corresponding AD entry is out of sync, and the user can specify what behavior to take when the AD entry is out of scope.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2013-02-21 08:17:09 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 839812, 868187 |
Description
Rich Megginson
2012-05-03 21:18:28 UTC
This is not a regression - removing Regression keyword r6908 | rmeggins | 2012-08-29 17:56:11 -0600 (Wed, 29 Aug 2012) | 7 lines Resolves: bug 818762 winsync should not delete entry that appears to be out of scope Resolves: bug 847868 [RFE] support posix schema for user and group sync The tests have been enhanced to cover more posix attribute checking. Added tests for ticket 355/bug 818762 The tests by default will ignore errors caused by tickets 415 and 428 *** Bug 839812 has been marked as a duplicate of this bug. *** Verification steps: 1. Create DS user, verify sync to AD $ AddNDSUsr dstestusr adding new entry uid=dstestusr,ou=people,dc=brq,dc=redhat,dc=com $ ChkNADUsr dstestusr ; echo $? 0 2. Create AD user, verify sync to DS $ AddNADUsr adtestusr adding new entry CN=adtestusr,cn=Users,dc=brq,dc=redhat,dc=com $ ChkNDSUsr adtestusr ; echo $? 0 3. Move AD user out of scope of synchronization agreement, entry on DS should not be deleted. $ ldapsearch -h windir -p 389 -D "cn=administrator,cn=users,dc=brq,dc=redhat,dc=com" -w Secret123 -b "dc=brq,dc=redhat,dc=com" cn=adtestusr dn dn: CN=adtestusr,OU=BadUsers,DC=brq,DC=redhat,DC=com $ ChkNDSUsr adtestusr ; echo $? 0 4. Remove AD user. Synchronized user on DS should be deleted as well $ ldapdelete -h windir -p 389 -D "cn=administrator,cn=users,dc=brq,dc=redhat,dc=com" -W CN=adtestusr,OU=BadUsers,DC=brq,DC=redhat,DC=com $ echo $? 0 $ ChkNDSUsr adtestusr ; echo $? ldap_search: No such object ldap_search: matched: ou=people,dc=brq,dc=redhat,dc=com 1 adtestusr entry is deleted. The bug is verified. 389-ds-base-1.2.11.15-3.el6.i686 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0503.html *** Bug 824073 has been marked as a duplicate of this bug. *** |