Univention Bugzilla – Bug 41550
Temporary S-1-4- SIDs synchronized to Samba/AD
Last modified: 2020-07-03 20:55:18 CEST
In the customer environment of Ticket#: 2016060821000334 (UCS 4.1-1 e160 Samba/AD) I found a couple of computers/windows (plus one regular user account) with temporary sambaSID from the S-1-4- namespace that UDM uses exclusively. It is normal that UDM temporarily writes these to OpenLDAP as all relevant UCR variables had default values: connector/s4/mapping/sid/sid_to_ucs: <empty> connector/s4/mapping/sid: true connector/s4/mapping/sid_to_s4: <empty> directory/manager/samba3/legacy: <empty> The irritating new thing this bug here is about is that these temporary SIDs also had been synchronized to Samba/AD and thus became permanent. The only hint I could find is that the "cn=RID Set" object in Samba/AD had rIDNextRID: 1218 and this RID was already assigned to some particular machine account. It might be difficult to get cleaner forensics data from this particular case, as the Master in this environment has some special, unique history. But we should do a test setup and check how Samba/AD behaves in case the S4-Connector passes a temporary SID and rIDNextRID is already taken. Maybe Samba/AD then just accepts the temporary (invalid) SID?
More info: The special thing about that master is that http://sdb.univention.de/1282 had been performed to recover from some storage-level corruption. I can see that rIDNextRID: 1215 had been extracted from the Samba/AD before reprovisioning.
Actually rIDNextRID is the last assigned SID (thank's MS!), so that is consistent. So I currently have no theory as to how the temporary SIDs ended up in Samba/AD.
Created attachment 8222 [details] fix_cases_of_bug41550.sh The attached script may be useful to fix all affected accounts by assigning new DNs to them. The script tries to avoid a race condition during the increment of the rIDNextRID attribute (unfortunately Samba/AD neither implements rfc4525 nor rfc4527). In case a race condition occurs on this attribute due to other accounts getting created on the same Samba/AD DC while the script is running, the following error message will occur: ERR: (No such attribute) "attribute 'rIDNextRID': no matching attribute value while deleting attribute [...] In this case the script aborts and can simply be run again to continue the job.
Note: Ticket #2016113021000354 also had temporary SIDs in Samba/AD, but in that case one of the UCR variables had an unexpected/non-default value. Please note that this was *not* and UCS@school domain. This can be reproduced simply by: ucr set connector/s4/mapping/sid_to_s4=yes; service univention-s4-connector restart; udm users/user create --set username=user1 --set lastname=name1 \ --set password=univention So that's a different issue. But the Script of Comment 3 seems to be able to fix this too (*Not* suitable for UCS@school): ucr unset connector/s4/mapping/sid_to_s4 service univention-s4-connector restart; ./fix_cases_of_bug41550.sh
This issue has been filed against UCS 4.2. UCS 4.2 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.