ich habe ein recht dringendes Problem nach der Übernahme eines AD mit AD-Takeover in ein UCS 3.2 System:
Innerhalb des S4-LDAPs scheint die Base DN einen Großbuchstaben zu beinhalten, im OpenLDAP aber nicht. Dies ist unentdeckt geblieben, da es vorerst auch keinerlei Probleme gab.
Beim Hinzufügen neuer PCs zu Domäne scheitert nun allerdings die connector-s4 Synchronisation, da die DNS-Forwardzone “Firma.de” nicht vorhanden ist (sondern eben nur “firma.de”)
Das Problem äußerst sich ziemlich exakt wie das hier
beschriebene.
Leider ist das Problem lange unentdeckt geblieben, so dass das das System schon Produktiv im Einsatz ist. Gibt es irgendeine Möglichkeit dem connector-s4 zu sagen, dass die DNS-Zone nicht Case-Sensitive zu Handhaben ist? Oder die DNS-Zone umbenennen?
Vielen Dank für jede Hilfe!
Ich habe mal die letzten Zeilen der connector-s4.log als Anhang hinzugefügt.
es scheint sich hier tatsächlich um das gleiche (oder mindestens ein sehr ähnliches) Verhalten zu handeln. Hatten Sie Gelegenheit, die im anderen Thread besprochenen Dinge zu testen und den Patch einzuspielen?
Wenn ich den Thread richtig gelesen habe, dann konnte die Ursache so vollständig gelöst werden (Sehen Sie hierzu insbesondere den Beitrag vom “Di 11. Feb 2014, 20:51” von Herrn Gohmann).
danke für die schnelle Antwort. Ich habe die Lösung aus dem angesprochenen Thread bisher nicht ausprobiert, weil ich die die Sache so verstanden habe, dass in jenem Fall die DNS Zone gar nicht vorhanden war.
Ich verstehe die Lösung so, dass in jenem Fall die Zone _msdcs.nelle-ms.site angelegt wurde.
Aber richtig, vielleicht liegt mein Problem ja ebenfalls in dem Zusatz “_msdcs” und gar nicht an der Groß- Kleinschreibung.
Ich werde also heute Nacht mal versuchen die Lösung umzusetzen. Dann habe ich hinterher ja zwei DNS-Zonen. Aber danach müsste ich ja Objekte von der einen in die Andere Zone bringen können?
nachvollzogen, obwohl ich ich sagen muss, dass ich nur eingeschränkt verstanden habe was ich da tue. Insgesamt war das aber wohl erfolgreich, denn von den vielen rejects sind nur wenige übriggeblieben.
Es wäre schön, wenn Sie mir bei der Bewertung / Auflösung noch helfen könnten, damit ich das System wieder in einen definierten Zustand habe.
Ich habe 6 S4-Rejectes, von denen 5 “Object exists” als Grund haben, daher wohl unwichtig sind? Aber wie kann ich diese den dann löschen / verwerfen?
07.08.2014 22:22:05,912 LDAP (PROCESS): sync to ucs: Resync rejected dn: DC=europro5,CN=Deleted Objects,DC=Europro,D,DC=Europro.de,CN=MicrosoftDNS,CN=System,DC=Europro,DC=de
07.08.2014 22:22:05,914 LDAP (PROCESS): sync to ucs: [ dns] [ delete] DC=europro5,cn=deleted objects,dc=europro,d,dc=europro.de,cn=dns,dc=europro,dc=de
07.08.2014 22:22:05,914 LDAP (ERROR ): sync of rejected object failed
DC=europro5,CN=Deleted Objects,DC=Europro,D,DC=Europro.de,CN=MicrosoftDNS,CN=System,DC=Europro,DC=de
07.08.2014 22:22:05,915 LDAP (ERROR ): Traceback (most recent call last):
File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", line 2043, in resync_rejected
sync_successfull = self.sync_to_ucs(property_key, mapped_object, premapped_s4_dn, object)
File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 1328, in sync_to_ucs
position.setDn( string.join( ldap.explode_dn( object['dn'] )[1:], "," ) )
File "/usr/lib/python2.6/dist-packages/ldap/dn.py", line 79, in explode_dn
dn_decomp = str2dn(dn,flags)
File "/usr/lib/python2.6/dist-packages/ldap/dn.py", line 53, in str2dn
return ldap.functions._ldap_function_call(_ldap.str2dn,dn,flags)
File "/usr/lib/python2.6/dist-packages/ldap/functions.py", line 57, in _ldap_function_call
result = func(*args,**kwargs)
DECODING_ERROR
Ignorieren? Wegmachen?
Unter UCS rejected gibt es 4 Meldungen. 3 Beziehen sich auf das Löschen einer Gruppenrichtlinie und Ihrer Untercontainer Machine und User. Ich habe versucht den Container im Univention LDAP einfach mal anzulegen, damit s4-connector ihn erfolgreich löschen kann, das hat aber nichts gebracht.
07.08.2014 22:22:05,856 LDAP (PROCESS): sync from ucs: Resync rejected file: /var/lib/univention-con
nector/s4/1405855466.662452
07.08.2014 22:22:05,857 LDAP (PROCESS): sync from ucs: [ container] [ delete] cn=machine,cn={6a
c1786c-016f-11d2-945f-00c04fb984f9},cn=policies,cn=system,dc=europro,dc=de
07.08.2014 22:22:05,861 LDAP (WARNING): sync failed, saved as rejected
/var/lib/univention-connector/s4/1405855466.662452
07.08.2014 22:22:05,862 LDAP (WARNING): Traceback (most recent call last):
File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 780, in __sync_file_from_ucs
or (not old_dn and not self.sync_from_ucs(key, object, premapped_ucs_dn, old_dn, old, new))):
File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", line 2501, in sync_from_ucs
self.delete_in_s4( object, property_type )
File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", line 2531, in delete_in_s4
self.lo_s4.lo.delete_s(compatible_modstring(object['dn']))
File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 285, in delete_s
return self.delete_ext_s(dn,None,None)
File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 805, in delete_ext_s
return self._apply_method_s(SimpleLDAPObject.delete_ext_s,*args,**kwargs)
File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 766, in _apply_method_s
return func(self,*args,**kwargs)
File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 279, in delete_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)
UNWILLING_TO_PERFORM: {'info': "00002035: objectclass: Cannot delete cn=machine,cn={6ac1786c-016f-11d2-945f-00c04fb984f9},cn=policies,cn=system,dc=europro,dc=de, it isn't permitted!", 'desc': 'Server is unwilling to perform'}
Als letztes als UCS rejected soll wohl noch ein Client gelöscht werden.
Insgesamt empfehle ich Ihnen an dieser Stelle noch den SDB-Artikel Samba 4 Troubleshooting, welcher insbesondere auch auf das händische Auflösen von S4-Connector Rejects eingeht.
Direkt zu den 4 Punkten:
Ganz generell ist ein Reject erst einmal nicht “schlimm” und eigentlich auch immer auflösbar - das auflösen selbst ist allerdings nicht zwangsläufig notwendig, sofern es sich nur um kosmetische Auswirkungen handelt .
Dieser Reject ist harmlos - es handelt sich um ein so genanntes “Deleted Object” (Samba 4 - Deleted Objects) und ich würde vorschlagen das Objekt und den Reject zu entfernen.
GPO-Objekte können momentan nicht immer im LDAP entfernt werden - das ist bekannt und wird in einer kommenden Version verbessert werden. Auch diese Art Reject ist harmlos.
Sofern Sie den Client nicht verwenden würde ich das Objekt im S4 und im LDAP entfernen und den Reject anschließend auflösen.
Insgesamt würde ich die Situation so einschätzen, dass alle (6) Rejects harmlos sind. Wenn Sie möchten, können Sie anhand des oben erwähnten SDB-Artikels die Rejects entfernen.