Scenario: Synchronize parts of an AD tree into UCS-LDAP. The AD connector allows to configure which LDAP/AD subtrees shall be synced withe the `connector/ad/mapping/allowsubtree` ucr variable. According to the documentation: "the AD Connection only considers Active Directory objects for synchronization that *locate in subtrees specified* by one of these UCR variables". This becomes very cumbersome to configure in situations with nested subtrees: When you want to synchronize one out of several neighbouring subsubtrees: The AD connector cannot sync a specific subsubtree without having the subtree itself in its configuration. But adding the subtree itself would mean to either sync or explicitly ignore all neighbours. Example: In a scenario with ou=1,ou=a,dc=example,dc=org ou=2,ou=a,dc=example,dc=org ou=3,ou=a,dc=example,dc=org ou=1,ou=b,dc=example,dc=org you could only select ou=1,ou=a,dc=example,dc=org for sync when adding ou=a,dc=example,dc=org for sync and ignoring ou=2,ou=a,dc=example,dc=org and ou=3,ou=a,dc=example,dc=org. Without adding ou=a,dc=example,dc=org you run into rejects because ou=a,dc=example,dc=org cannot be created. Thus you have to explicitly list every other neighbouring subsubtree that you want to ignore just to hand over the subtree. This configuration has to be maintained over time, too, and is thus hard to handle. New objects in AD should not accidentally be synced to UCS (also see #57394).
An other customer has this issue. Funny we found this one day later. Mapping looks like this connector/ad/mapping/allowsubtree/POZ-NU-DP2_1/ad: OU=POZ-NU-DP2,OU=Administration,OU=Pozilei,OU=sun,DC=ext,DC=schein,DC=me connector/ad/mapping/allowsubtree/POZ-NU-DP2_2/ad: OU=POZ-NU-DP2,OU=Administration,OU=Pozilei,OU=sun,dc=intern,dc=schein,dc=net connector/ad/mapping/allowsubtree/POZ-NU-DP_1/ad: OU=POZ-NU-DP,OU=Administration,OU=Pozilei,OU=sun,DC=ext,DC=schein,DC=me connector/ad/mapping/allowsubtree/POZ-NU-DP_2/ad: OU=POZ-NU-DP,OU=Administration,OU=Pozilei,OU=sun,dc=intern,dc=schein,dc=net This causes > 400 rejects, synchronizing users and groups, because the OUs are not added automatically, because they are rejected. 24.02.2025 12:09:14.244 LDAP (PROCESS): sync to ucs: Resync rejected dn: OU=Pozilei,OU=sun,DC=ext,DC=schein,DC=me 24.02.2025 12:09:14.244 LDAP (INFO ): Search AD with filter: (|(uSNChanged=290964527)(uSNCreated=290964527)) 24.02.2025 12:09:14.245 LDAP (INFO ): object_from_element: olddn: OU=Pozilei,OU=sun,DC=ext,DC=schein,DC=me 24.02.2025 12:09:14.245 LDAP (INFO ): _object_mapping: map with key ou and type con 24.02.2025 12:09:14.245 LDAP (ALL ): _object_mapping_con: object_out : {'dn': 'OU=Pozilei,OU=sun,dc=intern,dc=schein,dc=net', 'attributes': {'objectClass': [b'top', b'organizationalUnit'], 'ou': [b'Pozilei'], 'description': [b'Freunde der Sonne'], 'distinguishedName': [b'OU=Pozilei,OU=sun,DC=ext,DC=schein,DC=me'], 'instanceType': [b'4'], 'whenCreated': [b'20101110101029.0Z'], 'whenChanged': [b'20220819084053.0Z'], 'uSNCreated': [b'46011'], 'uSNChanged': [b'290964527'], 'name': [b'Pozilei'], 'objectGUID': [b'\xe2SiNy\x03mI\xaec\xd5\xb3\x08vN\x9b'], 'objectCategory': [b'CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=schein,DC=me'], 'gPLink': [b'[LDAP://cn={0FD78B9A-C805-4438-A4A9-DF8CCE3F3B03},cn=policies,cn=system,DC=ext,DC=schein,DC=me;0][LDAP://cn={802AE1A7-BFC9-429A-8FFE-24B7558BD39F},cn=policies,cn=system,DC=ext,DC=schein,DC=me;2]'], 'dSCorePropagationData': [b'20240821084016.0Z', b'20240311163030.0Z', b'20221216081633.0Z', b'20220819084053.0Z', b'16010101181633.0Z']}, 'modtype': 'modify'} 24.02.2025 12:09:14.246 LDAP (INFO ): _ignore_object: ignore object because it is not in one of the allowed subtrees: ['ou':'OU=Pozilei,OU=sun,dc=intern,dc=schein,dc=net'] So the structure has to be added manually, which is an imposition for the customer.
Created attachment 11286 [details] Teil1zwei
Created attachment 11287 [details] Teil1drei
Created attachment 11288 [details] Teil2zwei
Created attachment 11289 [details] Teil2drei
This is not a FR because it created rejects, and even if the variable description says "A separate variable must be set for each subtree that is to be included in the synchronization." is this also a wrong behaviour, because you then also have to specify, what should not be synced, because with the next ou other objects will be synced. In a simple test: root@dc01:~# ucr search --brief allowsub con.*/ad/mapping/allowsubtree/.*/ad: <empty> con.*/ad/mapping/allowsubtree/.*/ucs: <empty> connector/ad/mapping/allowsubtree/Teil1zwei/ad: ou=Teil1zwei,ou=Teil1,dc=ad,dc=schein,dc=me connector/ad/mapping/allowsubtree/Teil1zwei/ucs: ou=Teil1zwei,ou=Teil1,dc=schein,dc=sun connector/ad/mapping/allowsubtree/teil1/ad: ou=Teil1drei,ou=Teil1zwei,ou=Teil1,dc=ad,dc=schein,dc=me connector/ad/mapping/allowsubtree/teil1/ucs: ou=Teil1drei,ou=Teil1zwei,ou=Teil1,dc=schein,dc=sun connector/ad/mapping/allowsubtree/teil2/ad: ou=Teil2drei,ou=Teil2zwei,ou=Teil2,dc=ad,dc=schein,dc=me connector/ad/mapping/allowsubtree/teil2/ucs: ou=Teil2drei,ou=Teil2zwei,ou=Teil2,dc=schein,dc=sun connector/ad/mapping/allowsubtree/teil2zwei/ad: ou=Teil2zwei,ou=Teil2,dc=ad,dc=schein,dc=me connector/ad/mapping/allowsubtree/teil2zwei/ucs: ou=Teil2zwei,ou=Teil2,dc=schein,dc=sun  AD rejected 1: AD DN: CN=Holz Schüssel,OU=Teil2drei,OU=Teil2zwei,OU=Teil2,DC=ad,DC=schein,DC=me UCS DN: <not found> tried: 10/10 times 2: AD DN: OU=Teil2drei,OU=Teil2zwei,OU=Teil2,DC=ad,DC=schein,DC=me UCS DN: <not found> tried: 10/10 times 3: AD DN: CN=Feder weißer,OU=Teil1zwei,OU=Teil1,DC=ad,DC=schein,DC=me UCS DN: <not found> tried: 9/10 times 4: AD DN: CN=Erdnuss Flipp,OU=Teil2zwei,OU=Teil2,DC=ad,DC=schein,DC=me UCS DN: <not found> tried: 9/10 times 5: AD DN: CN=Bob Baumeister,OU=Teil1drei,OU=Teil1zwei,OU=Teil1,DC=ad,DC=schein,DC=me UCS DN: <not found> And the screenshots from the AD structure. Maybe it is clear that this is not usable for ad with a little bit more structure
My understanding here is that adding "ou=1,ou=a,dc=example,dc=org" to the allow list will lead to rejects for "ou=a,dc=example,dc=or". I consider this to be a bug.
We will change the behavior of the AD-Connector in a way that ancestors are also synchronized, on the condition that the new UCR-V `connector/ad/mapping/allow-subtree-ancestors` is set to a truthy value. The allowsubtree UCRVs were intended to be used in a way that you manually create the necessary parents on either side, AD or UCS. If the subtree existed beforehand and was ignored through some other rule, you will still, even with the new UCR-V, need to do a resync with the cli tools, as otherwise you will get rejects, that has not changed and was the case with or without any complex tree structure. As such, I agree with Jan Luca, it is more of a feature request then really a bug.
Package: univention-ad-connector Version: 16.3.0 Release: 5.2-0 Scope: errata5.2-2 univention-ad-connector.yaml 6df3d437eb9d | feat(ad-connector): Allow synchronization of subtree ancestors univention-ad-connector (16.3.0) dc3363d91d61 | feat(ad-connector): Resync ancestors of subtrees 6df3d437eb9d | feat(ad-connector): Allow synchronization of subtree ancestors ucs-test (12.2.33) 2f564a43645f | test(ad-connector): Add and update allowsubtree tests
Verified: * Package update * Functional tests (using the test cases) * Documentation * Advisory
<https://errata.software-univention.de/#/?erratum=5.2x162>