Univention Bugzilla – Bug 40419
UCS@school Slave reject: LDAP sambaSID != S4 objectSID == SID(Master)
Last modified: 2021-11-25 13:13:17 CET
Created attachment 7402 [details] slave-logfiles.tgz This situation happened today independently to Felix and me. Version: UCS 4.0-4 Errata 381 We had a strange S4-Connector reject directly after setting up an UCS@school Slave: ========================================================================= root@slave112:~# univention-s4connector-list-rejected UCS rejected 1: UCS DN: cn=master110,cn=dc,cn=computers,dc=ar404school,dc=r2 S4 DN: <not found> Filename: /var/lib/univention-connector/s4/1452608408.477371 S4 rejected last synced USN: 3849 root@slave112:~# univention-s4search cn=slave112 objectsid WARNING: No path in service IPC$ - making it unavailable! NOTE: Service IPC$ is flagged unavailable. # record 1 dn: CN=SLAVE112,OU=Domain Controllers,DC=ar404school,DC=r2 objectSid: S-1-5-21-230079219-2150547264-1222636400-1000 root@slave112:~# univention-ldapsearch -xLLL '(&(cn=slave112)(sambasid=*))' sambaSID dn: cn=slave112,cn=dc,cn=server,cn=computers,ou=school2,dc=ar404school,dc=r2 sambaSID: S-1-4-2008 root@slave112:~# univention-ldapsearch -xLLL '(&(cn=master110)(sambasid=*))' sambaSID dn: cn=master110,cn=dc,cn=computers,dc=ar404school,dc=r2 sambaSID: S-1-5-21-230079219-2150547264-1222636400-1000 ========================================================================= In my case the environment was set up like this: 1. Installation of UCS Master with Samba/AD 2. Installation of the School Installer Wizzard via Master Appcenter 3. Installation and direct automatic join of an UCS Slave 4. Installation of the School Installer wizzard via Slave Appcenter 5. Configuration of the UCS@school Slave with Samba/AD via UMC
The view on Samba4 of the Master: root@master110:~# univention-s4search cn=slave112 objectsid WARNING: No path in service IPC$ - making it unavailable! NOTE: Service IPC$ is flagged unavailable. # record 1 dn: CN=slave112,CN=dc,CN=server,CN=computers,OU=school2,DC=ar404school,DC=r2 objectSid: S-1-4-2008 My current guess is, that the univention-cli-server might have been running still (or something like that) and did not yet pick up directory/manager/samba3/legacy: yes which is set on Master and Slave. Not a convincingly precise explanation, but maybe it's something in that direction.
At Ticket #2016051821000246 we had the same reject but the sambaSID of the Slave was ok in OpenLDAP. We could not come up with a suitable approach to analyze the origin of this. According to the connector-s4.log the Slave account has been synchronized to Samba/AD (at some point). We fixed the issue by running /usr/share/univention-s4-connector/resync_object_from_ucs.py \ "$(ucr get ldap/hostdn)" on the UCS@school Slave PDC.
Created attachment 7717 [details] connector-s4-log from fresch installed UCS@school slave, latest errata I was able to reproduce the case of Comment 2 in my test setup like this: 1. Starting point: Master & Backup UCS 4.1-2 e191, both Samba/AD, joined 2. Installation of UCS@school on UCS Master via Appcenter (not on Backup) 3. Open Wizard, configure for Multi-School 4. Installed a plain Slave (no software components) 5. Updated slave to 4.1-2 e191: univention-upgrade --ignoreterm --ignoressh --n 6. joined the slave 7. Installed UCS@school Configuration wizard from UCS Master on UCS Slave 8. Opened UCS@school Configuration wizard module on UCS slave, configured it as AD Edu Slave for "school1" After that: root@slave14:~# univention-s4connector-list-rejected UCS rejected 1: UCS DN: cn=master10,cn=dc,cn=computers,dc=ar41i1,dc=qa S4 DN: <not found> Filename: /var/lib/univention-connector/s4/1448308160.226258 S4 rejected last synced USN: 3869 root@slave14:~# univention-s4search cn=slave14 objectsid # record 1 dn: CN=SLAVE14,OU=Domain Controllers,DC=ar41i1,DC=qa objectSid: S-1-5-21-2660895256-1678062113-3852026326-1000 root@slave14:~# univention-ldapsearch -xLLL cn=slave14 sambasid dn: cn=slave14,cn=school1,cn=dhcp,ou=school1,dc=ar41i1,dc=qa dn: cn=slave14,cn=dc,cn=server,cn=computers,ou=school1,dc=ar41i1,dc=qa sambaSID: S-1-5-21-2660895256-1678062113-3852026326-5020
*** Bug 42207 has been marked as a duplicate of this bug. ***
Please revert the following patch once the issue has been fixed: test/ucs-ec2-tools/examples/jenkins/utils/utils.sh (r75014): UCS@school monkeypatch: Remove rejected Master DN (Bug #40419)
Might be fixed with http://errata.software-univention.de/ucs/4.1/367.html but that's only a very vague hope, because in UCS@school the UDM should never have issued a temporary SID.
Same here, no connector reject though UCS 4.2 master UCS@school on master S4 on master 4.2 slave joined 4.2 slave2 joined UCS@school slave UCS@school slave2 UCS and samba RID differs for all samba DC'S master: dn: cn=slave,cn=dc,cn=server,cn=computers,ou=school1,dc=four,dc=two sambaSID: S-1-5-21-3006362628-2186033213-1690935345-5014 objectSid: S-1-5-21-3006362628-2186033213-1690935345-5014 dn: cn=slave2,cn=dc,cn=server,cn=computers,ou=school2,dc=four,dc=two sambaSID: S-1-5-21-3006362628-2186033213-1690935345-5016 objectSid: S-1-5-21-3006362628-2186033213-1690935345-5016 dn: cn=master,cn=dc,cn=computers,dc=four,dc=two sambaSID: S-1-5-21-3006362628-2186033213-1690935345-5002 objectSid: S-1-5-21-3006362628-2186033213-1690935345-1000 slave: dn: cn=slave,cn=dc,cn=server,cn=computers,ou=school1,dc=four,dc=two sambaSID: S-1-5-21-3006362628-2186033213-1690935345-5014 objectSid: S-1-5-21-3006362628-2186033213-1690935345-1000 dn: cn=master,cn=dc,cn=computers,dc=four,dc=two sambaSID: S-1-5-21-3006362628-2186033213-1690935345-5002 objectSid: S-1-5-21-3006362628-2186033213-1690935345-5002 slave2: dn: cn=slave2,cn=dc,cn=server,cn=computers,ou=school2,dc=four,dc=two sambaSID: S-1-5-21-3006362628-2186033213-1690935345-5016 objectSid: S-1-5-21-3006362628-2186033213-1690935345-1000 So the UCS/Samba RID sync is always broken for the local DC.
Ok, I can explain the original situation reported in the original Description, where the Slave account continues having a temporary SID in OpenLDAP: Install UCS 4.1-4 Master with Samba/AD and Slave without. When the Slave joins UDM assigns a temporary sambaSID, because in standard UCS Samba/AD is expected to assign SIDs. But the S4-Connector doesn't sync the Slave machine account to Samba/AD because the match_filter of the 'dc' mapping key doesn't apply to UCS DCs that don't offer "univentionService=Samba 4". As a result the accounts od non-Samba/AD UCS DCs always have a temporary non-domain-SID. That doesn't change when the Domain is converted to UCS@school and the Slave gets configured as Samba/AD Slave PDC.
I want to add that the most common order to install is the other way round, atm: 1. UCS Master with Samba/AD 2. UCS Slave without Samba/AD 3. Install UCS@school App on Slave 4. UCS@school installs Samba/AD as dependency on Slave This order was (is?) necessary to avoid DNS and DRS issues, when the Slave registers as Samba AD DC with the central Samba AD DCs (=Master) at first and then gets moved to its OU and configured as Samba/AD Slave PDC later on.
I came across a case that is similiar to Comment 7, but had a reject for the UCS Master on every school slave: > UCS rejected > > 1: UCS DN: cn=ucs,cn=dc,cn=computers,dc=example,dc=org > S4 DN: <not found> > Filename: /var/lib/univention-connector/s4/1492506428.710477 > > > S4 rejected > > > last synced USN: 86693 The SIDs were valid domain SIDs, but the RIDs differed/conflicted on the Slaves: UCS Master: dn: cn=ucs-327,cn=dc,cn=server,cn=computers,ou=327,dc=example,dc=org sambaSID: S-1-5-21-2422323242-444428286-1234123112-54538 sambaSID: S-1-5-21-2422323242-444428286-1234123112-54538 dn: cn=ucs,cn=dc,cn=computers,dc=example,dc=org sambaSID: S-1-5-21-2422323242-444428286-1234123112-1000 objectSid: S-1-5-21-2422323242-444428286-1234123112-1000 -> OK UCS@school Slave: dn: cn=ucs-327,cn=dc,cn=server,cn=computers,ou=327,dc=example,dc=org sambaSID: S-1-5-21-2422323242-444428286-1234123112-54538 objectSid: S-1-5-21-2422323242-444428286-1234123112-1000 dn: cn=ucs,cn=dc,cn=computers,dc=example,dc=org sambaSID: S-1-5-21-2422323242-444428286-1234123112-1000 objectSid: -> Object "ucs" not present in Samba/AD -> Not OK In this case it was sufficient to manually trigger a resync the UCS@school Slave object: > /usr/share/univention-s4-connector/resync_object_from_ucs.py cn=ucs-327,cn=dc,cn=server,cn=computers,ou=327,dc=example,dc=org This corrected the RID of the UCS@school Slave in Samba/AD (objectSid). The S4 reject of the Master was then resolved automatically during the next resync interval for S4 rejects.
Same here: Ticket #2017090721000249 The following command has to execute on every school slave: /usr/share/univention-s4-connector/resync_object_from_ucs.py "$(ucr get ldap/hostdn)"
(In reply to Stefan Gohmann from comment #11) > Same here: Ticket #2017090721000249 > > The following command has to execute on every school slave: > > /usr/share/univention-s4-connector/resync_object_from_ucs.py "$(ucr get > ldap/hostdn)" Another similar case in Ticket #2017090721000249: The dns-<hostname> was only created in Samba 4 and had a objectSID which conflicted with the group CN=Computers from OpenLDAP. The RID pool of the school slaves should be different from the DC master RID pool. That would fix it, wouldn't it?
Another one: Ticket #2017092621000534.
Re: Comment 12: As discussed offline: Bug 30115 has a proposal to fix this for dns-service accounts. This bug here should be reserved to the issue of Master vs Slave SID.
Created attachment 9275 [details] bug40419-proposal1.patch I think we could and should simply do this.
Created attachment 9276 [details] bug40419-proposal1.patch
Occured during customer workshop today
Happened again. Other workshop, other customer, same problem.
resync hostdn object from ucs to s4 in connector join script if connector/s4/mapping/sid_to_s4 i strue univention-s4-connector a98322f8fa645988ab54dae42fd5756bae15a466 yaml c53672aaa5b592dd084c07ea9ffb58bfc3d170e4
Ok, this fixes it for new installations, can't we also fix it during package update?
(In reply to Arvid Requate from comment #20) > Ok, this fixes it for new installations, can't we also fix it during package > update? OK a7d9c4ad893d7330d8fbdb7285ab04a3a2010518 - univention-s4-connector 15f5b89458ac92c9f4174ab7fe13c7bdc051f225 - yaml
Ok, thnaks, works, updater.log says: resync triggered for cn=slave81,cn=dc,cn=server,cn=computers,ou=school2,dc=ar423s1,dc=school and the SID is synchronized after that. Advisory ok.
<http://errata.software-univention.de/ucs/4.3/4.html>
*** Bug 47443 has been marked as a duplicate of this bug. ***