Hallo,

ich mache bereits seit einem halben Jahr immer mal wieder Tests mit den jeweils neuesten UCS Versionen und versuche einen AD Takeover durchzuführen.
Leider immer erfolglos.

Der Übernahmeprozeß an sich läuft in der Weboberfläche ohne Fehlermeldungen durch und meldet “alles erfolgreich”, dem ist aber leider nicht so.
Ich habe hinterher immer das Problem, daß der Domänenbeitritt von neuen Clients mit den hier (sdb.univention.de/1263) beschriebenen Phänomen fehlschlägt, sprich das erstellen der DNS Einträge schlägt fehl.

Ich habe mich nun etwas tiefer in das Problem verbissen und konnte herausfinden, daß die Namensauflösung der ForestDomainZone _msdcs… nicht funktioniert.
/usr/share/univention-samba4/scripts/check_essential_samba4_dns_records.sh
meldet für alle benötigten Hosts in _msdcs… : not found: 2(SERVFAIL)

Eine Analyse des Samba DNS mit samba-tool und Microsoft DNS MMC hat aber ergeben daß die host Einträge in der Samba DNS Datenbank existieren.
bei einer DNS Anfrage per host werden sie nur nicht gefunden!

Mir ist ebenfalls aufgefallen, daß im Samba DNS keine Reverse Lookup Zone mehr existiert.

Irgendetwas scheint beim AD Takeover Prozeß beim Erstellen der DNS Datenbank gewaltig schiefzugehen.
Wie wäre das weitere Vorgehen um das Problem zu lösen?

MfG

Können Sie bitte nach folgendem SDB Artikel: http://sdb.univention.de/content/6/223/en/s4-connector-neu-initialisieren.html zunächst den S4 Connector neu initialisieren? Dabei müssen relativ sicher keine Clients neu gejoint werden. Falls das nicht ausreichend ist um das Problem zu beheben, prüfen Sie bitte den folgenden SDB Artikel: http://sdb.univention.de/content/6/274/en/re_provisioning-samba4-on-a-dc-master.html - dieser ist sehr umfangreich und erfordert den Neu-Join von Clients, da hierbei die Samba-Datenbank komplett neu aufgebaut wird.

Bitte geben Sie Bescheid ob die Probleme danach gelöst sind.

Vielen Dank für die schnelle Rückmeldung.

Ich werde Ihren ersten Vorschlag

ausprobieren und Ihnen Rückmeldung geben.

Sollte es damit nicht klappen ist Ihr zweiter Vorschlag

leider keine Option für mich.
Ziel ist es eine Domäne mit über 100 Clients umzustellen und diese alle neu joinen zu müssen ist zuviel Aufwand.

Aber vielleicht klappt ja schon Option 1

Ich den SDB Artikel: sdb.univention.de/content/6/223/ … ieren.html
nun ausprobiert, zuerst leider ohne Erfolg.

Dann habe ich die UCS Version des VM-Images, das ich zum testen verwende, von 4.1-4 errata324
auf 4.1-4 errata371 aktualisiert und den ganzen Prozeß des AD Takeover nochmal probiert.
Schon das AD Takeover war hier “etwas” erfolgreicher, denn nun waren bereits nach dem Takeover Prozeß DNS Einträge der Clients in der DNS Ansicht der Weboberfläche
vorhanden. Mit der Version 4.1-4 errata324 waren dort nur Einträge des Servers vorhanden.

die Namensauflösung der ForestDomainZone _msdcs… funktionierte aber immer noch nicht.
/usr/share/univention-samba4/scripts/check_essential_samba4_dns_records.sh
meldete für alle benötigten Hosts in _msdcs… immer noch : not found: 2(SERVFAIL)

Ein erneutes Durchexerzieren des SDB Artikel: sdb.univention.de/content/6/223/ … ieren.html
hat daran auch nichts geändert.

Ein weiterer Vergleich der DNS Einträge des alten Windows Servers mit denen des Samba4 DNS hat mit darauf gebracht daß
im windows DNS in der Domain-zone ein Eintrag _msdcs existiert, der auf den Nameserver der Domainzone verweist.
Dieser Eintrag fehlte im Samba4 DNS, er wurde vom AD Takeover Prozeß anscheinend nicht erstellt.
Ich habe dann händisch im Samba4 DNS einen Alias erstellt, der auf den UCS Server verweist, dann erneut SDB Artikel: sdb.univention.de/content/6/223/ … ieren.html
angewendet und siehe da, die Namensauflösung der ForestDomainZone _msdcs… funktioniert nun.

Der Beitritt eines neuen clients zur Domäne funktioniert nun ohne Fehler

[quote]Failed to change the DNS name for the primary domain in this computer
"’. Name “domain.local” is maintained.
Error: The specified server can not perform the requested operation.[/quote]
Allerdings wurde für den neuen Client beim Domain-Join immer noch kein DNS Eintrag im UCS erstellt. Ich musste auf dem Client nachträglich “ipconfig /registerdns” ausführen, dann war der DNS Eintrag vorhanden.

Auch die DNS Reverse Lookup Zonen scheinen mir noch nicht ganz koscher zu sein.
Die Reverse Lookup Zone des IP-Adressbereichs, in dem sich der UCS und die Clients befinden, existiert nur in der DNS Webansicht (was wohl die bind9 datenbank darstellt?) nicht aber im Samba4 DNS.
Ich habe auch ein paar zusätzliche Reverse Lookup Zonen, diese sind aber nur im Samba4 DNS vorhanden nicht jedoch in der DNS Webansicht.

Ebenso zeigt sich ein seltsames Verhalten wenn Windows Clients auf die Sysvol Freigabe des UCS zugreifen wollen.
Ein Zugriff per \ucs-4567\sysvol funktioniert problemlos, die Verwendung der IP \192.168.1.20\sysvol jedoch funktioniert nicht. Es ercheint ein Dialog zu Passworteingabe, aber der Domänenlogin wird nicht akzeptiert, Meldung: “Zugriff verweigert”
in /var/log/univention/connector-s4.log finden sich viele Fehlermeldungen wie diese:

[quote]06.01.2017 15:56:56,788 LDAP (PROCESS): sync to ucs: Resync rejected dn: DC=27,DC=76.168.192.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=testdomain,DC=local
06.01.2017 15:56:56,790 LDAP (PROCESS): sync to ucs: [ dns] [ add] relativeDomainName=27,zoneName=76.168.192.in-addr.arpa,cn=dns,dc=testdomain,dc=local
06.01.2017 15:56:56,794 LDAP (ERROR ): Unknown Exception during sync_to_ucs
06.01.2017 15:56:56,795 LDAP (ERROR ): Traceback (most recent call last):
File “/usr/lib/pymodules/python2.7/univention/s4connector/init.py”, line 1472, in sync_to_ucs
result = self.property[property_type].ucs_sync_function(self, property_type, object)
File “/usr/lib/pymodules/python2.7/univention/s4connector/s4/dns.py”, line 1644, in con2ucs
ucs_ptr_record_create(s4connector, object)
File “/usr/lib/pymodules/python2.7/univention/s4connector/s4/dns.py”, line 1060, in ucs_ptr_record_create
newRecord = univention.admin.handlers.dns.ptr_record.object(None, s4connector.lo, position, dn=None, superordinate=superordinate, attributes=[], update_zone=False)
File “/usr/lib/pymodules/python2.7/univention/admin/handlers/dns/ptr_record.py”, line 97, in init
univention.admin.handlers.simpleLdap.init(self, co, lo, position, dn, superordinate, attributes=attributes)
File “/usr/lib/pymodules/python2.7/univention/admin/handlers/init.py”, line 571, in init
self._validate_superordinate()
File “/usr/lib/pymodules/python2.7/univention/admin/handlers/init.py”, line 606, in validate_superordinate
raise univention.admin.uexceptions.insufficientInformation((‘No superordinate object given.’))
insufficientInformation: No superordinate object given.

06.01.2017 15:55:04,7 LDAP (PROCESS): sync to ucs: Resync rejected dn: DC=@,DC=testdomain.local,CN=MicrosoftDNS,DC=DomainDnsZones,DC=testdomain,DC=local
06.01.2017 15:55:04,10 LDAP (PROCESS): sync to ucs: [ dns] [ modify] zonename=testdomain.local,cn=dns,dc=testdomain,dc=local
06.01.2017 15:55:04,11 LDAP (ERROR ): Unknown Exception during sync_to_ucs
06.01.2017 15:55:04,11 LDAP (ERROR ): Traceback (most recent call last):
File “/usr/lib/pymodules/python2.7/univention/s4connector/init.py”, line 1472, in sync_to_ucs
result = self.property[property_type].ucs_sync_function(self, property_type, object)
File “/usr/lib/pymodules/python2.7/univention/s4connector/s4/dns.py”, line 1638, in con2ucs
ucs_host_record_create(s4connector, object)
File “/usr/lib/pymodules/python2.7/univention/s4connector/s4/dns.py”, line 975, in ucs_host_record_create
newRecord = univention.admin.handlers.dns.host_record.object(None, s4connector.lo, position=None, dn=searchResult[0][0], superordinate=superordinate, attributes=[], update_zone=False)
File “/usr/lib/pymodules/python2.7/univention/admin/handlers/dns/host_record.py”, line 155, in init
univention.admin.handlers.simpleLdap.init(self, co, lo, position, dn, superordinate, attributes=attributes)
File “/usr/lib/pymodules/python2.7/univention/admin/handlers/init.py”, line 571, in init
self._validate_superordinate()
File “/usr/lib/pymodules/python2.7/univention/admin/handlers/init.py”, line 621, in validate_superordinate
raise univention.admin.uexceptions.insufficientInformation((‘The DN must be underneath of the superordinate.’))
insufficientInformation: The DN must be underneath of the superordinate.
[/quote]

Diverse DNS Einträge / ReverseDNS Einträhe scheinen dem S4 Connector nicht zu “schmecken”

Ich hoffe die Informationen helfen weiter.

MfG

Wie ich schon im vorigen Post geschrieben habe, habe ich auch ein paar zusätzliche Reverse Lookup Zonen, diese waren nach dem AD Takeover aber nur im Samba4 DNS vorhanden nicht jedoch in der DNS Webansicht.

Ich war nun in der Lage die Sync-Fehler der zusätzliche Reverse Lookup Zonen, wie z.B. diesen hier

[quote]06.01.2017 15:56:56,788 LDAP (PROCESS): sync to ucs: Resync rejected dn: DC=27,DC=76.168.192.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=testdomain,DC=local
06.01.2017 15:56:56,790 LDAP (PROCESS): sync to ucs: [ dns] [ add] relativeDomainName=27,zoneName=76.168.192.in-addr.arpa,cn=dns,dc=testdomain,dc=local
06.01.2017 15:56:56,794 LDAP (ERROR ): Unknown Exception during sync_to_ucs
06.01.2017 15:56:56,795 LDAP (ERROR ): Traceback (most recent call last):
File “/usr/lib/pymodules/python2.7/univention/s4connector/init.py”, line 1472, in sync_to_ucs
result = self.property[property_type].ucs_sync_function(self, property_type, object)
File “/usr/lib/pymodules/python2.7/univention/s4connector/s4/dns.py”, line 1644, in con2ucs
ucs_ptr_record_create(s4connector, object)
File “/usr/lib/pymodules/python2.7/univention/s4connector/s4/dns.py”, line 1060, in ucs_ptr_record_create
newRecord = univention.admin.handlers.dns.ptr_record.object(None, s4connector.lo, position, dn=None, superordinate=superordinate, attributes=[], update_zone=False)
File “/usr/lib/pymodules/python2.7/univention/admin/handlers/dns/ptr_record.py”, line 97, in init
univention.admin.handlers.simpleLdap.init(self, co, lo, position, dn, superordinate, attributes=attributes)
File “/usr/lib/pymodules/python2.7/univention/admin/handlers/init.py”, line 571, in init
self._validate_superordinate()
File “/usr/lib/pymodules/python2.7/univention/admin/handlers/init.py”, line 606, in validate_superordinate
raise univention.admin.uexceptions.insufficientInformation((‘No superordinate object given.’))
insufficientInformation: No superordinate object given.[/quote]
zu beseitigen indem ich die fehlenden Reverse Lookup Zonen in der DNS Webansicht manuell erstellt habe.

Es zeigt sich weiterhin das seltsame Verhalten wenn Windows Clients auf die Sysvol Freigabe des UCS zugreifen wollen.
Ein Zugriff per \ucs-4567\sysvol funktioniert problemlos, die Verwendung der IP \192.168.1.20\sysvol jedoch funktioniert nicht. Es ercheint ein Dialog zu Passworteingabe, aber der Domänenlogin wird nicht akzeptiert, Meldung: “Zugriff verweigert”

Desweiteren habe ich festgestellt, das Domänen-Clients, die DHCP verwenden, zwar korrekt in den “Forward” DNS eingetragen werden, aber nicht in die Reverse Lookup Zone.

MfG

Gilt das merkwürdige Verhalten auch für Clients die neu gejoint werden?

Hallo,

Ja, das Verhalten von alten übernommenen Clients und neu gejointen Clients ist gleich “merkwürdig”.

MfG

Können Sie den Bind neustarten

# service bind9 restart

und dann mal das resultierende syslog hier anhängen? Wie ist die Ausgabe von:

# ucr search --brief connector/s4/mapping/dns/position

[quote=“Thorp-Hansen”]Können Sie den Bind neustarten

# service bind9 restart

und dann mal das resultierende syslog hier anhängen? [/quote]

Das Syslog des Bind9 Neustarts habe ich Ihnen angehängt.

die Ausgabe von

# ucr search --brief connector/s4/mapping/dns/position

ist:

connector/s4/mapping/dns/position: <empty>

MfG
syslog.txt (6.26 KB)

Das kann ein Problem sein:

Jan 25 08:34:01 ucs-4567 named[4112]: samba_dlz: trying partition 'CN=MicrosoftDNS,CN=System,DC=testdomain,DC=local' Jan 25 08:34:01 ucs-4567 named[4112]: samba_dlz: configured writeable zone '124.168.192.in-addr.arpa' Jan 25 08:34:01 ucs-4567 named[4112]: samba_dlz: pre-W2k3 zone found [...] Jan 25 08:34:01 ucs-4567 named[4112]: samba_dlz: Ignoring duplicate zone '124.168.192.in-addr.arpa' from 'DC=@,DC=124.168.192.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=testdomain,DC=local' [...] Jan 25 08:34:01 ucs-4567 named[4112]: samba_dlz: Ignoring dnsZone _msdcs.testdomain.local

Ich würde zunächst eine Sicherung des Objekts durchführen:

# univention-s4search -b "DC=124.168.192.in-addr.arpa,CN=MicrosoftDNS,CN=System,$(ucr get samba4/ldap/base)" > backup1.ldif

Dann sichergehen, dass die Systemgesundheit an sich okay ist:

# samba-tool dbcheck --fix

Ich würde dann prüfen ob sich das Verhalten ändert, wenn das DNS Backend auf LDAP steht:

[code]# ucr set dns/backend=‘ldap’

service bind9 restart[/code]

Wenn ja, gehe ich davon aus, dass für eine letztendliche Lösung die Zone ‘124.168.192.in-addr.arpa’ an einem falschen Ort liegt und verschoben werden müsste. Ein Script Beispiel habe ich angehängt, aber bitte beachten: das ist kein offizielles Errata Update, sondern ein Script. Damit konnten wir bei einigen Kunden die Zone verschieben, aber ich kann keine Vorhersage für Ihre Umgebung treffen.
move_dns_zone.sh (707 Bytes)

Es hat ein wenig gedauert bis ich mal wieder Zeit gefunden habe mich ein wenig mit UCS zu beschäftigen.
Die erste Hürde war rauszufinden, wieso das alte Forum nicht mehr "funktioniert" - hat ein paar Minuten gedauert bis ich den Hinweis auf den Umzug gefunden habe
Leider war der Umzug meines Forum-Users genauso problembehaftet wie die ganze UCS AD Takeover/Synchronisationsgeschichte bisher. Login mit dem alten User/Passwort wurde verweigert - glücklicherweise hat wenigstens der Passwort-Reset funktioniert - aber im Ernst, ein 10stelliges Passwort für ein Forum??? Ist nicht etwas Overkill?

Nun zum Feedback:

Systemgesundheit habe ich mit

# samba-tool dbcheck --fix

getestet - keine Fehler gefunden.

> Ich würde dann prüfen ob sich das Verhalten ändert, wenn das DNS Backend auf LDAP steht:

> # ucr set dns/backend='ldap'
> # service bind9 restart

Habe ich ebenfalls ausprobiert => keine Änderungen des Verhaltens.

Inzwischen habe ich die AD Takeover Geschichte aufgegeben und den Versuch ad Acta gelegt - dann wird es wohl doch ein Windows Domain Controller bleiben...

Ich habe noch einen weiteren Versuch gestartet den UCS ledliglich als Teil einer Active Directory Domäne zu betreiben.
Auch das funktioniert nicht.
Der AD Connector synchronisiert nur einen Bruchteil der Windows Benutzerkonten vom AD in den UCS Master.

Das Logfile /var/log/univention/connector.log
strotzt nur so vor "Unkown Exceptions":

18.03.17 12:43:35.667 DEBUG_INIT
18.03.17 12:43:35.809 LDAP ( PROCESS ) : Renaming 'cn=Domain Admins,cn=groups,dc=testdomain,dc=local' to 'Domänen-Admins' in UCS LDAP.
18.03.17 12:43:35.810 LDAP ( WARN ) : rename cn=Domänen-Admins
18.03.17 12:43:35.830 LDAP ( PROCESS ) : Renaming 'cn=Domain Users,cn=groups,dc=testdomain,dc=local' to 'Domänen-Benutzer' in UCS LDAP.
18.03.17 12:43:35.830 LDAP ( WARN ) : rename cn=Domänen-Benutzer
18.03.17 12:43:35.851 ADMIN ( WARN ) : No settings/cn superordinate was given.
18.03.17 12:43:35.852 LDAP ( PROCESS ) : Modifying 'cn=default,cn=univention,dc=testdomain,dc=local' in UCS LDAP.
18.03.17 12:43:35.852 ADMIN ( WARN ) : No settings/cn superordinate was given.
18.03.17 12:43:35.859 LDAP ( PROCESS ) : Renaming 'cn=Domain Guests,cn=groups,dc=testdomain,dc=local' to 'Domänen-Gäste' in UCS LDAP.
18.03.17 12:43:35.859 LDAP ( WARN ) : rename cn=Domänen-Gäste
18.03.17 12:44:40.821 DEBUG_INIT
18.03.2017 12:44:41,856 MAIN (------ ): DEBUG_INIT
18.03.2017 12:44:41,896 LDAP (ERROR ): Failed to lookup AD LDAP base, using UCR value.
18.03.2017 12:44:41,949 LDAP (PROCESS): Building internal group membership cache
18.03.2017 12:44:42,116 LDAP (PROCESS): Internal group membership cache was created
18.03.2017 12:44:42,127 LDAP (PROCESS): Using testdomain as AD Netbios domain name
18.03.2017 12:44:42,230 LDAP (PROCESS): Scan all changes from UCS ...
18.03.2017 12:44:42,939 LDAP (PROCESS): initialize AD: last USN is 0, sync all
18.03.2017 12:44:43,353 LDAP (PROCESS): sync to ucs: [ container] [ modify] CN=Users,dc=testdomain,dc=local
18.03.2017 12:44:43,381 LDAP (PROCESS): sync to ucs: [ container] [ modify] CN=Computers,dc=testdomain,dc=local
18.03.2017 12:44:43,435 LDAP (PROCESS): sync to ucs: [ user] [ add] uid=Gast,cn=users,dc=testdomain,dc=local
18.03.2017 12:44:43,796 LDAP (PROCESS): sync to ucs: [ group] [ add] cn=Domänencomputer,cn=users,dc=testdomain,dc=local
18.03.2017 12:44:44,243 LDAP (PROCESS): sync to ucs: [ group] [ add] cn=Zertifikatherausgeber,cn=users,dc=testdomain,dc=local
18.03.2017 12:44:44,346 LDAP (PROCESS): sync to ucs: [ group] [ add] cn=RAS- und IAS-Server,cn=users,dc=testdomain,dc=local
18.03.2017 12:44:44,444 LDAP (PROCESS): sync to ucs: [ group] [ add] cn=Richtlinien-Ersteller-Besitzer,cn=users,dc=testdomain,dc=local
18.03.2017 12:44:44,546 LDAP (PROCESS): sync to ucs: [ group] [ add] cn=Domänencontroller,cn=users,dc=testdomain,dc=local
18.03.2017 12:44:44,630 LDAP (WARNING): group_members_sync_to_ucs: failed to identify object type of ad member, ignore membership: CN=IGM48,OU=Domain Controllers,DC=testdomain,DC=local
18.03.2017 12:44:44,637 LDAP (PROCESS): sync to ucs: [ group] [ add] cn=Organisations-Admins,cn=users,dc=testdomain,dc=local
18.03.2017 12:44:44,750 LDAP (PROCESS): sync to ucs: [ group] [ modify] cn=Domänen-Gäste,cn=groups,dc=testdomain,dc=local
18.03.2017 12:44:44,761 LDAP (ERROR ): failed in post_con_modify_functions
18.03.2017 12:44:44,762 LDAP (ERROR ): Traceback (most recent call last):
File "/usr/lib/pymodules/python2.7/univention/connector/__init__.py", line 1309, in sync_to_ucs
f(self, property_type, object)
File "/usr/lib/pymodules/python2.7/univention/connector/ad/__init__.py", line 157, in set_univentionObjectFlag_to_synced
connector.lo.lo.lo.modify_s(univention.connector.ad.compatible_modstring(ucs_object['dn']), [(ldap.MOD_REPLACE, 'univentionObjectFlag', flags)])
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 364, in modify_s
return self.result(msgid,all=1,timeout=self.timeout)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 465, in result
resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 469, in result2
resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all,timeout)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 476, in result3
resp_ctrl_classes=resp_ctrl_classes
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 483, in result4
ldap_result = self.ldapcall(self.l.result4,msgid,all,timeout,addctrls,add_intermediates,add_extop)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 106, in ldapcall
result = func(*args,**kwargs)
NO_SUCH_OBJECT: {'matched': 'cn=groups,dc=testdomain,dc=local', 'desc': 'No such object'}

18.03.2017 12:44:44,762 LDAP (WARNING): sync to ucs was not successfull, save rejected
18.03.2017 12:44:44,762 LDAP (WARNING): object was: CN=Domänen-Gäste,CN=Users,DC=testdomain,DC=local
18.03.2017 12:44:44,768 LDAP (PROCESS): sync to ucs: [ group] [ modify] cn=Domänen-Benutzer,cn=groups,dc=testdomain,dc=local
18.03.2017 12:44:44,785 LDAP (ERROR ): failed in post_con_modify_functions
18.03.2017 12:44:44,785 LDAP (ERROR ): Traceback (most recent call last):
File "/usr/lib/pymodules/python2.7/univention/connector/__init__.py", line 1309, in sync_to_ucs
f(self, property_type, object)
File "/usr/lib/pymodules/python2.7/univention/connector/ad/__init__.py", line 157, in set_univentionObjectFlag_to_synced
connector.lo.lo.lo.modify_s(univention.connector.ad.compatible_modstring(ucs_object['dn']), [(ldap.MOD_REPLACE, 'univentionObjectFlag', flags)])
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 364, in modify_s
return self.result(msgid,all=1,timeout=self.timeout)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 465, in result
resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 469, in result2
resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all,timeout)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 476, in result3
resp_ctrl_classes=resp_ctrl_classes
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 483, in result4
ldap_result = self.ldapcall(self.l.result4,msgid,all,timeout,addctrls,add_intermediates,add_extop)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 106, in ldapcall
result = func(*args,**kwargs)
NO_SUCH_OBJECT: {'matched': 'cn=groups,dc=testdomain,dc=local', 'desc': 'No such object'}

18.03.2017 12:44:44,785 LDAP (WARNING): sync to ucs was not successfull, save rejected
18.03.2017 12:44:44,785 LDAP (WARNING): object was: CN=Domänen-Benutzer,CN=Users,DC=testdomain,DC=local
18.03.2017 12:44:44,789 LDAP (PROCESS): sync to ucs: [ group] [ modify] cn=Domänen-Admins,cn=groups,dc=testdomain,dc=local
18.03.2017 12:44:44,808 LDAP (ERROR ): failed in post_con_modify_functions
18.03.2017 12:44:44,808 LDAP (ERROR ): Traceback (most recent call last):
File "/usr/lib/pymodules/python2.7/univention/connector/__init__.py", line 1309, in sync_to_ucs
f(self, property_type, object)
File "/usr/lib/pymodules/python2.7/univention/connector/ad/__init__.py", line 157, in set_univentionObjectFlag_to_synced
connector.lo.lo.lo.modify_s(univention.connector.ad.compatible_modstring(ucs_object['dn']), [(ldap.MOD_REPLACE, 'univentionObjectFlag', flags)])
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 364, in modify_s
return self.result(msgid,all=1,timeout=self.timeout)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 465, in result
resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 469, in result2
resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all,timeout)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 476, in result3
resp_ctrl_classes=resp_ctrl_classes
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 483, in result4
ldap_result = self.ldapcall(self.l.result4,msgid,all,timeout,addctrls,add_intermediates,add_extop)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 106, in ldapcall
result = func(*args,**kwargs)
NO_SUCH_OBJECT: {'matched': 'cn=groups,dc=testdomain,dc=local', 'desc': 'No such object'}

18.03.2017 12:44:44,808 LDAP (WARNING): sync to ucs was not successfull, save rejected
18.03.2017 12:44:44,808 LDAP (WARNING): object was: CN=Domänen-Admins,CN=Users,DC=testdomain,DC=local
18.03.2017 12:44:44,815 LDAP (PROCESS): sync to ucs: [ user] [ modify] uid=Administrator,cn=users,dc=testdomain,dc=local
18.03.2017 12:44:44,912 LDAP (PROCESS): sync to ucs: [ group] [ add] cn=Schema-Admins,cn=users,dc=testdomain,dc=local
18.03.2017 12:44:45,70 LDAP (PROCESS): sync to ucs: [ group] [ add] cn=WINS-Benutzer,cn=users,dc=testdomain,dc=local
18.03.2017 12:44:45,169 LDAP (PROCESS): sync to ucs: [ group] [ add] cn=DHCP-Benutzer,cn=users,dc=testdomain,dc=local
18.03.2017 12:44:45,273 LDAP (PROCESS): sync to ucs: [ group] [ add] cn=DHCP-Administratoren,cn=users,dc=testdomain,dc=local
18.03.2017 12:44:45,386 LDAP (PROCESS): sync to ucs: [ group] [ add] cn=DnsAdmins,cn=users,dc=testdomain,dc=local
18.03.2017 12:44:45,487 LDAP (PROCESS): sync to ucs: [ group] [ add] cn=DnsUpdateProxy,cn=users,dc=testdomain,dc=local
18.03.2017 12:44:45,587 LDAP (PROCESS): sync to ucs: [ group] [ add] cn=Sysadmins,cn=users,dc=testdomain,dc=local
18.03.2017 12:44:45,682 LDAP (PROCESS): sync to ucs: [ group] [ add] cn=IIS_WPG,cn=users,dc=testdomain,dc=local
18.03.2017 12:44:45,772 LDAP (PROCESS): sync to ucs: [ ou] [ add] OU=Rechner,dc=testdomain,dc=local
18.03.2017 12:44:45,798 LDAP (PROCESS): sync to ucs: [ group] [ add] cn=CVSUser,cn=users,dc=testdomain,dc=local
18.03.2017 12:44:45,888 LDAP (PROCESS): sync to ucs: [ group] [ add] cn=CVSAdmin,cn=users,dc=testdomain,dc=local
18.03.2017 12:44:45,994 LDAP (PROCESS): sync to ucs: [ group] [ add] cn=Domänen-Sicherungsoperatoren,cn=users,dc=testdomain,dc=local
18.03.2017 12:44:46,95 LDAP (PROCESS): sync to ucs: [ user] [ add] uid=testadmin,ou=benutzer normal,ou=benutzer,dc=testdomain,dc=local
18.03.2017 12:44:46,302 LDAP (ERROR ): Unknown Exception during sync_to_ucs
18.03.2017 12:44:46,303 LDAP (ERROR ): Traceback (most recent call last):
File "/usr/lib/pymodules/python2.7/univention/connector/__init__.py", line 1281, in sync_to_ucs
result = self.add_in_ucs(property_type, object, module, position)
File "/usr/lib/pymodules/python2.7/univention/connector/__init__.py", line 1135, in add_in_ucs
return ucs_object.create() and self._modifycustom_attributes(property_type, object, ucs_object, module, position)
File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 305, in create
return self._create()
File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 759, in _create
self.lo.add(self.dn, al)
File "/usr/lib/pymodules/python2.7/univention/admin/uldap.py", line 382, in add
raise univention.admin.uexceptions.ldapError(err2str(msg), originalexception=msg)
ldapError: No such object

18.03.2017 12:44:46,303 LDAP (WARNING): sync to ucs was not successfull, save rejected
18.03.2017 12:44:46,303 LDAP (WARNING): object was: CN=Thomas Wagner (Admin),OU=Benutzer normal,OU=Benutzer,DC=testdomain,DC=local

Hallo Flu,

Tut mir leid, dass das für dich nicht klar war. Wir haben im alten Forum drei Ankündigungen geschaltet, eine am 03. März als Vorwarnung, eine am 14. März als die Migration losging und eine am 16. März als sie abgeschlossen war. Am 03. und am 16. März haben wir an alle Foren-User auch entsprechende E-Mails verschickt. In beiden E-Mails stand auch, dass wir die Passwort-Hashes nicht migrieren und man daher sein Passwort zurücksetzen muss.

Nein →
https://blog.codinghorror.com/your-password-is-too-damn-short/

Schönen Gruß,
Michael Grandjean

Vielen Dank für die Rückmeldung.
Leider wird mir aus Ihrer Antwort nicht ganz klar, wie ich weiter vorgehen soll.
Eine Diskrepanz zwischen wo Domänen-Admins im LDAP und wo sie im AD liegen kann ich nicht feststellen.
Die wenigen Accounts die übertragen wurden, liegen im LDAP in der selben "Baumstruktur" wie sie auch im AD vorhanden ist.

Gibt es "cn=groups,dc=testdomain,dc=local" und "CN=Users,DC=testdomain,DC=local" im LDAP?

For future reference: https://blog.codinghorror.com/hacker-hack-thyself/