https://bugzilla.redhat.com/show_bug.cgi?id=171078
+++ This bug was initially created as a clone of Bug #170149 +++ Description of problem: Entries in sub containers stopped sync'ing in the latest candidate build (regression in this candidate build or due to SSL enabled sync?) Version-Release number of selected component (if applicable): DS 7.1 SP1 candidate build 3 (20051006.2) HP-UX How reproducible: Consistently? Steps to Reproduce: 1. Set up SSL win sync between AD 2003 and RHDS 2. Verify entries sync both ways 3. Create sub container (cn=new_ou) under the sync suffixes on both side manually 4. Create user entries under the sub container on AD and RHDS Actual results: The entries are not sync'ing over to the other side. Expected results: This used to work in the previous candidate (which was non-SSL sync). ok... it seems if a sub container is created, a full-resync is required to get the entries underneath to sync both ways. Is this the expected behaviour? If so we can probably close this bug, but may be worth mentioning the need of a full resync in the doc. Right now it only mentions that admin will need to manually create sub containers. Per today's bug council, this bug will not be fixed for DS 7.1 SP1 Marking this as resolved pending documentation. Re-assigning to kwade and cloning a new bug for 7.2
batch update moving tickets to future
set default ticket origin to Community
Added initial screened field value.
Yes, it is an expected behaviour.
Metadata Update from @rmeggins: - Issue set to the milestone: FUTURE
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/226
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Invalid)
Login to comment on this ticket.