S4-connector Problem mit gross- kleinschreibung

german

#1

Hallo Forum,

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.

Gerd Wilhelm
tail-connector-s4.log (26.8 KB)


#2

Hallo,

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).

Mit freundlichen Grüßen,
Tim Petersen


#3

Hallo Herr Petersen,

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?

Beste Grüße

Gerd Wilhelm


#4

Hallo Herr Perterson, hallo Univention Team.

ich habe die Lösungsschritte aus dem Thread

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?

Ein S4 Reject sieht so aus:

4: S4 DN: DC=europro5,CN=Deleted Objects,DC=Europro,D,DC=Europro.de,CN=Mi UCS DN: <not found>

Der Logauszug hiezu ist:

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?

  1. 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.

UCS DN: cn=Machine,cn={6AC1786C-016F-11D2-945F-00C04FB984F9},cn=Policies,cn=System,dc=europro,dc=de S4 DN: cn=machine,cn={6ac1786c-016f-11d2-945f-00c04fb984f9},cn=policies,cn=system,dc=europro,dc=de Filename: /var/lib/univention-connector/s4/1405855466.662452

Der Logeintrag dazu:

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.

1: UCS DN: cn=EP82,ou=Clients,ou=Europro,dc=europro,dc=de S4 DN: cn=ep82,ou=clients,ou=europro,dc=europro,dc=de Filename: /var/lib/univention-connector/s4/1405776495.553480

Logeintrag:

07.08.2014 22:22:05,727 LDAP (PROCESS): sync from ucs: Resync rejected file: /var/lib/univention-con nector/s4/1405776495.553480 07.08.2014 22:22:05,732 LDAP (PROCESS): sync from ucs: [windowscomputer] [ delete] cn=ep82,ou=clien ts,ou=europro,dc=europro,dc=de 07.08.2014 22:22:05,786 LDAP (WARNING): delete subobject: CN=RouterIdentity,CN=EP82,OU=Clients,OU=Euro pro,DC=Europro,DC=de 07.08.2014 22:22:05,854 LDAP (WARNING): sync failed, saved as rejected /var/lib/univention-connector/s4/1405776495.553480 07.08.2014 22:22:05,855 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 2553, in delete_in_s4 if not self.sync_from_ucs(key, subobject, object_mapping['dn']): File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", line 2219, in sync_from_ucs if self.property[property_type].sync_mode in ['read', 'none']: KeyError: None

Vielen Dank nochmal für Ihre Mühe.

Gerd Wilhelm


#5

Guten Morgen Herr Wilhelm,

das sieht doch schon sehr gut aus!

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:

  1. 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 .
  2. 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.
  3. 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.
  4. 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.

Mit freundlichen Grüßen,
Tim Petersen