Univention Bugzilla – Bug 47380
S4 rejects because of SID violation between Group and DNS account
Last modified: 2023-06-12 15:26:32 CEST
$ univention-app info UCS: 4.3-1 errata148 Installed: cups=2.2.1 dhcp-server=12.0 samba4=4.7 squid=3.5 ucsschool=4.3 v4 Upgradable: As far as I can tell, the rejects already occured on UCS 4.2 before the upgrade to 4.3. Today I came across a customer environment where *all* of the schoolservers had multiple S4 connector rejects for the same object: > 19.07.2018 11:37:35,583 LDAP (PROCESS): sync from ucs: [ group] [ modify] cn=Computers,cn=groups,DC=school,DC=example,DC=org > 19.07.2018 11:37:35,601 LDAP (PROCESS): sync_from_ucs: error during add, searching for conflicting deleted object in S4 > 19.07.2018 11:37:35,603 LDAP (PROCESS): sync_from_ucs: no conflicting deleted object found > 19.07.2018 11:37:35,606 LDAP (WARNING): sync failed, saved as rejected > /var/lib/univention-connector/s4/1530007361.139229 > 19.07.2018 11:37:35,607 LDAP (WARNING): Traceback (most recent call last): > File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 898, in __sync_file_from_ucs > if ((old_dn and not self.sync_from_ucs(key, mapped_object, pre_mapped_ucs_dn, unicode(old_dn, 'utf8'), old, new)) or (not old_dn and not self.sync_from_ucs(key, mapped_object, pre_mapped_ucs_dn, old_dn, old, new))): > File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/__init__.py", line 2550, in sync_from_ucs > self.lo_s4.lo.add_ext_s(compatible_modstring(object['dn']), compatible_addlist(addlist), serverctrls=ctrls) # FIXME encoding > File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 195, in add_ext_s > resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all=1,timeout=self.timeout) > File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 514, in result3 > resp_ctrl_classes=resp_ctrl_classes > File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 521, in result4 > ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) > File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 106, in _ldap_call > result = func(*args,**kwargs) > ALREADY_EXISTS: {'info': '00002071: ../ldb_tdb/ldb_index.c:1339: Failed to re-index objectSid in CN=Computers,CN=Groups,DC=school,DC=example,DC=org - ../ldb_tdb/ldb_index.c:1259: unique index violation on objectSid in CN=Computers,CN=Groups,DC=school,DC=example,DC=org', 'desc': 'Already exists'} Master OpenLDAP: dn: cn=Computers,cn=groups,dc=school,dc=example,dc=org sambaSID: S-1-5-21-4265642949-7774261057-427984201-1103 Schoolserver OpenLDAP: dn: cn=Computers,cn=groups,dc=school,dc=example,dc=org sambaSID: S-1-5-21-4265642949-7774261057-427984201-1103 Schoolserver Samba AD: $ univention-s4search objectSID=S-1-5-21-4265642949-7774261057-427984201-1103 dn | grep ^dn: dn: CN=dns-dc-school01,CN=Users,DC=school,DC=example,DC=org --> On every schoolserver, the RID 1103 is assigned to the local "dns-$servername" account and this collides with the RID 1103 of the group CN=Computers.
After discussing this with Felix, we came to the following conclusion: 0. We are in the join process of the school server. 1. "62ucs-school-slave.inst" adds the user "dns-$hostname" to the S4 Connector Ignorelist (UCRV connector/s4/mapping/user/ignorelist) 2. The "dns-$hostname" account is created in "96univention-samba4slavepdc.inst" via "create_spn_account.sh". This uses "samba-tool user add" which adds the user only in Samba. 3. Because of 1., this user "dns-$hostname" is never synced to OpenLDAP (I also assume this would not work, because afaik a schoolserver is not allowed to create a user in cn=users,$ldap_base because of LDAP ACL restrictions). 4. This obviously can lead to situations where the local Samba AD of the schoolserver assigns the same RID to "host-$hostname" that UDM on the UCS Master already assigned to another object. Maybe this is some kind of race condition during the join because the S4-Connector gets initialized later in "97univention-s4-connector.inst"? The question is, why did this happen in this specific environment, but not anywhere else (as far as we know)?
Maybe the "dns-$hostname" could be created in the same way as the "http-proxy-$hostname" account in "98univention-squid-samba4.inst": - create account via udm - wait until the account is replicated to the local Samba AD directory - create keytab
Good idea, we would like to do that too. The challenge is, that the OpenLDAP Kerberos schema doesn't know a servicePrincipalName (Bug #34669). As discussed, I guess you run into this bug if you first install a standard UCS with Samba/AD and then later install UCS@school. We have a concept to be implemented that should avoid these many different ways of installation that lead to differing results.
Happened on a customer who tried to limit the enctypes. Additionally to revert his changes he did not remove the UCRV but set them to an empty string and therefore the needed key still did not get created. ucr unset kerberos/allow/weak/crypto ucr unset kerberos/defaults/enctypes/permitted ucr unset kerberos/defaults/enctypes/tgs ucr unset kerberos/defaults/enctypes/tkt