Zentyal domain takover schlägt fehl

Hallo,

wir versuchen gerade eine Zentyal Domain zu UCS zu migrieren. Leider ohne Erfolg.

ad-takeoverlog:

[quote]2017-01-10 01:12:53,101 Failed to commit objects: WERR_DS_DRA_MISSING_PARENT
2017-01-10 01:12:53,152 Could not find machine account in secrets database: Failed to fetch machine account password for GR from both secrets.ldb (Could not find entry to match filter: ‘(&(flatname=GR)(objectclass=primaryDomain))’ base: ‘cn=Primary Domains’: No such object: dsdb_search at …/source4/dsdb/common/util.c:4575) and from /var/lib/samba/private/secrets.tdb: NT_STATUS_CANT_ACCESS_DOMAIN_INFO
2017-01-10 01:12:53,310 ERROR(runtime): uncaught exception - (8460, “Failed to process ‘chunk’ of DRS replicated objects: WERR_DS_DRA_MISSING_PARENT”)
2017-01-10 01:12:53,310 File “/usr/lib/python2.7/dist-packages/samba/netcmd/init.py”, line 176, in _run
2017-01-10 01:12:53,311 return self.run(*args, **kwargs)
2017-01-10 01:12:53,311 File “/usr/lib/python2.7/dist-packages/samba/netcmd/domain.py”, line 659, in run
2017-01-10 01:12:53,313 keep_existing=keep_existing)
2017-01-10 01:12:53,313 File “/usr/lib/python2.7/dist-packages/samba/join.py”, line 1260, in join_DC
2017-01-10 01:12:53,313 ctx.do_join()
2017-01-10 01:12:53,313 File “/usr/lib/python2.7/dist-packages/samba/join.py”, line 1160, in do_join
2017-01-10 01:12:53,314 ctx.join_replicate()
2017-01-10 01:12:53,314 File “/usr/lib/python2.7/dist-packages/samba/join.py”, line 897, in join_replicate
2017-01-10 01:12:53,314 replica_flags=ctx.domain_replica_flags)
2017-01-10 01:12:53,314 File “/usr/lib/python2.7/dist-packages/samba/drs_utils.py”, line 258, in replicate
2017-01-10 01:12:53,314 schema=schema, req_level=req_level, req=req)
[/quote]

was könnte der grund dafür sein?

Können Sie die Umgebung etwas genauer beschreiben und das gesamte Log anhängen?

Wir sind aktuell auf einer Zentyal Domain Version 3.3.10

UCS komplett neu aufgesetz, anbei der komplette ad-takeover.log
ad-takeover.log (18.9 KB)

Hm, das Log ist leider nicht zu aussagekräftig. Es gibt zwar einen “schön” klaren Traceback, aber die Ursache dafür ist leider nicht ebenso leicht zu erkennen. Die S4 Informationen die der UCS bekommt um den Join korrekt durchführen zu können, scheinen nicht korrekt oder unvollständig zu sein. Ist denn sicher, dass auf der Zentyal Seite soweit alles in Ordnung ist?

ja würde ich behaupten, wir können ohne Probleme anderen Maschine joinen mit den gleichen zugangsdaten

Haben Sie irgendwelche BuiltIn-Accounts (Administrator) oder -Container verschoben, oder liegen diese bei Zentyal nicht dort wo sie von MS-Ad bzw. Samba-AD erwartet werden?

nein das haben wir nicht:

hallo nochmal, scheint wohl keine lösung dafür zu geben?

dumme frage… muss ich den samba service auf dem zentyal ad vor dem takeover abschalten?

Nein, ich denke nicht, das ein Abschalten des Samba auf der Zentyal Domäne hier zum Erfolg führt. Ich habe gerade keinen Überblick über die Zentyal Versionen - ist es machbar hier ein Update durchzuführen und den Takeover erneut zu versuchen?

Ich habe mit meinem Zentyal 3.2 Server das gleiche Problem und laufe in die gleiche Fehlermeldung.
Mich wundert allerdings die Fehlermeldung :

Could not find machine account in secrets database: Failed to fetch machine account password for xx from both secrets.ldb…
ERROR(runtime): uncaught exception

Das scheint doch eher ein Problem auf auf dem USC zu sein oder ist das nicht die entscheidene Stelle ?

Der vollständige Auszug ist dieser hier:

2017-01-10 01:36:56,483 Failed to commit objects: WERR_DS_DRA_MISSING_PARENT 2017-01-10 01:36:56,532 Could not find machine account in secrets database: Failed to fetch machine account password for [b]GR[/b] from both secrets.ldb (Could not find entry to match filter: [b]'(&(flatname=GR)(objectclass=primaryDomain))'[/b] base: 'cn=Primary Domains': No such object: dsdb_search at ../source4/dsdb/common/util.c:4575) and from /var/lib/samba/private/secrets.tdb: NT_STATUS_CANT_ACCESS_DOMAIN_INFO 2017-01-10 01:36:56,685 ERROR(runtime): uncaught exception - (8460, "Failed to process 'chunk' of DRS replicated objects: WERR_DS_DRA_MISSING_PARENT")

UCS bekommt da offensichtlich eine Information nicht, die für den Join benötigt wird. Es wird ja ein Filter angewendet um die existierende Domäne zu finden. Wenn ich das richtig sehe, wird die Domäne aber nicht gefunden. Nachdem der Filter aber generisch ist, müsste das Problem überall auftreten (MS oder Zentyal) wenn der Filter fehlerhaft ist, oder habe ich einen Denkfehler?

Meine Kenntnisse diesbezüglich sind leider recht beschränkt, ich bin da keine grosse Hilfe.
Da wir nur eine rechte beschränkte Anzahl von Personen und Computer im Zentyal AD haben würde ich ggf. “manuell” umziehen.
Hat jemand vielleicht einen Link mit Tips für mich ?
Danke schon mal vorab.

Ich könnte schonmal mit diesem Link dienen: http://wiki.univention.de/index.php?title=Migrate_to_UCS Leider ist der Hauptartikel der AD-Takeover. Eventuell kann man mit Zentyal aber auch die anderen Punkte versuchen. Eine echte manuelle Migration würde ich mit einer Installation, Einrichtung einer neuen Domäne und dem manuellen Einrichten der Konten durchführen.

manuell ist leider nicht möglich bei uns… auch mit den anderen punkten komm ich nicht wirklich weiter…

die entwickler lesen das forum hier nicht oder?

Doch natürlich, aber es ist nicht immer möglich ad-Hoc Lösungen im kostenfreien Support aus dem Ärmel zu schütteln. Wir hatten aber vor kurzem einen Fall mit einer ähnlichen Fehlermeldung - kurz gesagt war da das Problem, dass ein Server in der Umgebung mit dem Attribut “isCriticalSystemObject” in eine OU verschoben wurde, die dieses Attribut nicht hat. Das Problem mit den “isCriticalSystemObject” besteht in der Reihenfolge der Replikation, Critical Objects werden vor allen anderen bearbeitet und wenn (wie in diesem Fall) die OU dabei noch nicht existiert, dann hängt das Objekt bildlich gesprochen in der Luft. Dabei tritt der beobachtete Fehler auf: “MISSING_PARENT”.

Es gibt mehrere Möglichkeiten das Problem ad Hoc zu beheben. Zum Einen könnte die OU manuell ein “isCriticalSystemObject” werden - das ist der einfachste Weg, erfordert aber eine Manipulation der sam.ldb und Vorsicht (wegen dem --relax werden Sicherheitsfunktionen ausgehebelt):

root@master:~# ldbedit -H /var/lib/samba/private/sam.ldb ou=<betreffende OU> --relax

Dort dann hinterlegen: “isCriticalSystemObject: TRUE” und das Ganze mit :wq speichern und nun sollten Sie die erfolgreiche Manipulation sehen: # 0 adds 1 modifies 0 deletes

Eine weitere Möglichkeit ist die Applikation eines Patches, der die Replikation direkt verändert:

root@master:~# apt-get install patch root@master:~# wget --no-check-certificate 'https://forge.univention.org/bugzilla/attachment.cgi?id=8448' -O sambabug12398_workaround.patch root@master:~# patch -d /usr/share/pyshared -p2 < sambabug12398_workaround.patch

Inwieweit das anwendbar ist, muss aber vorher geprüft werden. Nicht einfach blind installieren.

Ich habe den Patch auf einem Test UCS angewendet und der takeover lief durch.
Benutzer und Computerkonten sind angelegt worden.
Jetzt teste ich mal weiter.

Vielen Dank.

vielen dank, der patch hat funktioniert!

Mastodon