Univention Bugzilla – Bug 26535
Reject nach DC Slave Join auf UCS@School MS1 Master wegen objectSid des Slave
Last modified: 2012-06-11 06:29:42 CEST
In UCS@School MS1 wurde per "create_ou SITE1 slave" eine OU vorbereitet. Nach dem Join des DC Slaves gibt es S4 Connector rejects beim Sync von UCS nach Samba4, die sich auf das objectSid-Attribut beziehen. Traceback hangt unten an. Ursache scheint folgender Ablauf zu sein: 1. In UCS wird beim create_ou für den DC Slave eine SID per UDM vergeben und auf dem Master nach Samba4 synchronisiert. Das Samba4-Objekt liegt dann unter der gleichen DN wie das im OpenLDAP. 2. Beim samba4-join des DC Slave löscht Samba4 auf dem Master das DC-Objekt in seinem Datenbestand und legt es unter "OU=Domain Controllers" mit einer neuen SID aus seinem RID-Pool neu an. 3. Die Delete-Operation wird durch das S4-Connector-mapping nicht nach UCS übertragen. Anschliessend versucht der S4 Connector die Attribute am OpenLDAP-Objekt nach Samba4 zu übertragen, unter anderem die von UDM festgelegte SID. Samba4 verweigert dies mit Hinweis darauf, dass die SID im LDB-Index nicht eindeutig sei. In der Tat ist die SID noch im LDB-Index zu finden, weil das zuvor gelöschte Rechner-Objekt noch mit objectSid-Attribut unter "CN=Deleted Objects" gespeichert ist. ============================================================================ 15.03.2012 16:18:58,968 LDAP (PROCESS): sync from ucs: [ dc] [ modify] cn=qaslave,ou=domain controllers,dc=arschool3i1,dc=qa 15.03.2012 16:18:58,977 LDAP (WARNING): sync failed, saved as rejected 15.03.2012 16:18:58,978 LDAP (WARNING): Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 747, in __sync_file_from_ucs or (not old_dn and not self.sync_from_ucs(key, object, premapped_ucs_dn, old_dn, old))): File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", line 2182, in sync_from_ucs f(self, property_type, object) File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/sid_mapping.py", line 82, in sid_to_s4 s4connector.lo_s4.lo.modify_ext_s(s4_dn, modlist, serverctrls=controls) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 295, in modify_ext_s return self.result(msgid,all=1,timeout=self.timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 422, in result res_type,res_data,res_msgid = self.result2(msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 426, in result2 res_type, res_data, res_msgid, srv_ctrls = self.result3(msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 432, in result3 ldap_result = self._ldap_call(self._l.result3,msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 96, in _ldap_call result = func(*args,**kwargs) ALREADY_EXISTS: {'info': '00002071: Entry already exists - ../ldb_tdb/ldb_index.c:1121: unique index violation on objectSid in CN=QASLAVE,OU=Domain Controllers,DC=arschool3i1,DC=qa', 'desc': 'Already exists'} ============================================================================
Wie besprochen wäre hier zu prüfen, ob AD bei Deleted Objects überhaupt die Attribute weiterhin am Objekt speichert. Falls das so ist, sollte man das in Samba4 analog handhaben.
*** Bug 26647 has been marked as a duplicate of this bug. ***
Auch AD entfernt die objectSid nicht von den "Tombstone Objects": "[AD] Strips all attributes that are not needed by Active Directory. A few key attributes, including objectGuid , objectSid , distinguishedName , nTSecurityDescriptor , and usnChanged , are preserved on the tombstone." -- http://technet.microsoft.com/en-us/library/cc961798.aspx
Ggf. tritt das Problem nach der Umstellung auf die Provision-Variante nicht mehr auf: Bug #26504.
Trat bei mir nach der Umstellung von samba domain join auf secondary provision (Bug 26504 Comment 5) nicht mehr auf.
(In reply to comment #5) > Trat bei mir nach der Umstellung von samba domain join auf secondary provision > (Bug 26504 Comment 5) nicht mehr auf. Ja, bei mir tritt das Problem auch nicht mehr auf.
Verified: * Auf dem DC Master wird durch das separate DC Slave provision wird das Objekt nicht erst im SD des Master angelegt, beim samba-tool domain join wieder gelöscht, und vom S4 Connector wieder angelegt, sondern es geschieht nur der erste Schritt. * Der UCS@School 3.0 Samba 4 DC Slave hingegen legt beim Provision das Rechnerobjekt zunächst mit RID 1000 an (er ist für sich der RID Master) und der S4 Connector synchronisiert dann die zuvor im UDM für ihn vergebene SID in den Samba Verzeichnisdienst. Beim Join wird direkt durch Skriptaufruf von samba4-idmap.py die korrekte Zuordnung von UDM SID und Posix ID in die idmap.ldb geschrieben.
UCS@school 3.0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS@school erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"