Bug 47380 - S4 rejects because of SID violation between Group and DNS account
S4 rejects because of SID violation between Group and DNS account
Status: NEW
Product: UCS@school
Classification: Unclassified
Component: Samba 4 - Slave PDC
UCS@school 4.3
Other other
: P5 normal (vote)
: ---
Assigned To: Samba maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-07-19 11:48 CEST by Michael Grandjean
Modified: 2021-08-30 17:53 CEST (History)
2 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 4: Minor Usability: Impairs usability in secondary scenarios
Who will be affected by this bug?: 3: Will affect average number of installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.137
Enterprise Customer affected?:
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Grandjean univentionstaff 2018-07-19 11:48:27 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.
Comment 1 Michael Grandjean univentionstaff 2018-07-19 12:36:17 CEST
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)?
Comment 2 Michael Grandjean univentionstaff 2018-07-19 12:53:49 CEST
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
Comment 3 Arvid Requate univentionstaff 2018-08-08 21:19:40 CEST
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.
Comment 4 Christian Völker univentionstaff 2020-09-11 15:51:50 CEST
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