Univention Bugzilla – Bug 56792
AD-Connector reading from forest child domain doesn't read referenced objects in root domain
Last modified: 2023-11-21 17:57:01 CET
When using the AD-Connector configured against a forest child domain, the connector-ad.log shows tracebacks for group member DNs that point to objects in the forest root domain. The following lines are from a UCS test system that syncs against Sub240.AutoTest240.test and show tracebacks because "Enterprise Admins" and "Schema Admins" are located in the root domain, outside of the child domain: === 2.11.2023 09:55:30.518 LDAP (PROCESS): sync to ucs: [ group] [ add] cn=Denied RODC Password Replication Group,cn=users,dc=Sub240,dc=AutoTest240,dc=test 02.11.2023 09:55:31.026 LDAP (ERROR ): Could not get object 02.11.2023 09:55:31.031 LDAP (ERROR ): Traceback (most recent call last): File "/usr/lib/python3/dist-packages/univention/connector/ad/__init__.py", line 822, in get_object ad_object = self.lo_ad.get(dn, attr=attrlist) [...] ldap.REFERRAL: {'desc': 'Referral', 'info': 'Referral:\nldap://AutoTest240.test/CN=Enterprise%20Admins,CN=Users,DC=AutoTest240,DC=test'} 02.11.2023 09:55:31.032 LDAP (ERROR ): Could not get object 02.11.2023 09:55:31.032 LDAP (ERROR ): Traceback (most recent call last): File "/usr/lib/python3/dist-packages/univention/connector/ad/__init__.py", line 822, in get_object ad_object = self.lo_ad.get(dn, attr=attrlist) ldap.REFERRAL: {'desc': 'Referral', 'info': 'Referral:\nldap://AutoTest240.test/CN=Schema%20Admins,CN=Users,DC=AutoTest240,DC=test'} === AD-search confirms: === root@admember240:~# univention-adsearch "cn=Denied RODC Password Replication Group" # record 1 dn: CN=Denied RODC Password Replication Group,CN=Users,DC=Sub240,DC=AutoTest240,DC=test objectClass: top objectClass: group cn: Denied RODC Password Replication Group description: Members in this group cannot have their passwords replicated to a ny read-only domain controllers in the domain member: CN=Enterprise Admins,CN=Users,DC=AutoTest240,DC=test member: CN=Schema Admins,CN=Users,DC=AutoTest240,DC=test [...] === The AD-Connector doesn't handle this as a reject though, so it doesn't cause a persistent entry in univention-connector-list-rejected. As a first step it would be good to adjust the AD-Connector to handle this exception and output an informative log message.
In case the AD-Connector is configured as part of a AD-Member configuration (ad/member: true in UCR), we are using Kerberos. In that case access to the root domain is transparent if a MS AD DC in the root domain is resolvable via DNS. E.g. this works: ucr set hosts/static/10.210.43.250=EC2AMAZ-SKKU189.AutoTest240.test ldbsearch -H ldap://EC2AMAZ-SKKU189.AutoTest240.test --use-kerberos=required cn="Enterprise Admins" And then one has two additional tickets in the Kerberos cache: === root@admember240:~# klist Credentials cache: FILE:/tmp/krb5cc_0 Principal: admember240$@SUB240.AUTOTEST240.TEST Issued Expires Principal Nov 2 10:25:02 2023 Nov 2 20:25:02 2023 krbtgt/SUB240.AUTOTEST240.TEST@SUB240.AUTOTEST240.TEST Nov 2 10:25:02 2023 Nov 2 20:25:02 2023 ldap/EC2AMAZ-TAS69AH.Sub240.AutoTest240.test@SUB240.AUTOTEST240.TEST Nov 2 10:25:19 2023 Nov 2 20:25:02 2023 cifs/admember240@SUB240.AUTOTEST240.TEST Nov 2 10:26:22 2023 Nov 2 20:25:02 2023 krbtgt/AUTOTEST240.TEST@SUB240.AUTOTEST240.TEST Nov 2 10:26:22 2023 Nov 2 20:25:02 2023 ldap/EC2AMAZ-SKKU189.AutoTest240.test@AUTOTEST240.TEST === So basically one has three requirements for this: 1. Known and resolvable FQDN of MS AD DC in forest root domain 2. SSL certificate of that domain (if connector/ad/ldap/ssl=yes in UCR) (But maybe one already has the SSL CA cert from that EnterpriseRootCa) 3. Credentials (in case the AD-Connector is used with plain username+password)
Looks like accounts in the child domain can also do LDAP simple bind to the forest root domain (probably every domain in the forest?) just with their plain username. In my test scenario the SSL CA was on the forest root and automatically also covered the child domain NTDS service. So that leaves the DNS resolvability of the root domain and that also doesn't seem to be an issue in my setup: With an account root@admember240:~# samba-tool user create -H ldap://EC2AMAZ-R0PDH2L.Sub240.AutoTest240.test \ -UAdministrator%'[...]' subtest1 SomeSecretPassword root@admember240:~# ldbsearch -H ldap://EC2AMAZ-U6JJ7F8.AutoTest240.test -Usubtest1%'SomeSecretPassword' samaccountname=subtest1 [Not found in the root domain] # Referral ref: ldap://Sub240.AutoTest240.test/DC=Sub240,DC=AutoTest240,DC=test # Referral ref: ldap://ForestDnsZones.AutoTest240.test/DC=ForestDnsZones,DC=AutoTest240,DC=test # Referral ref: ldap://DomainDnsZones.AutoTest240.test/DC=DomainDnsZones,DC=AutoTest240,DC=test # Referral ref: ldap://AutoTest240.test/CN=Configuration,DC=AutoTest240,DC=test # returned 4 records [...] root@admember240:~# host Autotest240.test Autotest240.test has address 10.210.80.5 root@admember240:~# host Sub240.AutotesT240.test Sub240.AutotesT240.test has address 10.210.241.61 root@admember240:~# ucr search nameserver1 nameserver1: 10.210.241.61 The first DNS server to be used. So, back to the original problem: Based on the DN of a member account the AD-Connector could attempt to naively map the Base-part of the DN to the domain name and do an LDAP search there (i.e. at a DC in the Forest root domain).
Interesting: The AD child domain behaves differently in the AD-Connector scenario and the corresponding AD-Member scenario: 1. test/scenarios/ad-connector/autotest-240-adsync-w2k19-english-forest-child.cfg 2. test/scenarios/ad-membermode/autotest-240-admember-w2019-english-forest-child.cfg In the first case the group object "CN=Denied RODC Password Replication Group" has ============================================================================== member: CN=S-1-5-21-2967080851-34744088-2931722904-519,CN=ForeignSecurityPrincipals,DC=sub240,DC=autotest240win,DC=test member: CN=S-1-5-21-2967080851-34744088-2931722904-518,CN=ForeignSecurityPrincipals,DC=sub240,DC=autotest240win,DC=test member: CN=Domain Admins,CN=Users,DC=sub240,DC=autotest240win,DC=test member: [...] ============================================================================== In the AD-Member scenario the object instead has ============================================================================== member: CN=Enterprise Admins,CN=Users,DC=AutoTest240,DC=test member: CN=Schema Admins,CN=Users,DC=AutoTest240,DC=test member: CN=Domain Admins,CN=Users,DC=Sub240,DC=AutoTest240,DC=test member: [...] ============================================================================== So the AD-domains behave a little different: * In the first case, the object DNs are local to the child domain. * In the second case, the DNs for "Enterprise Admins" and "Schema Admins" refer to objects in the forest root domain. AFAICS, the main difference is that in the AD-Member scenario we install a CA on the forest root domain. Maybe that's "more trusted" and "more forest".
3295cf3b43 | Make AD-Connector skip referrals to objects 90d19a4d80 | ucs-test: Explicitly nudge certificate enrollment Package: univention-ad-connector Version: 14.0.16-5 Branch: ucs_5.0-0 Scope: errata5.0-5
OK
<https://errata.software-univention.de/#/?erratum=5.0x884>