habe vorhin einen AD-Takeover auf auf einem Server durchgeführt, auf dem auch auch UVMM installiert ist.
Somit hat die Maschine eine bridge, anstatt des lokalen Interfaces eth0. Soweit alles klar.
Der Takeover ist auch fast ganz ohne Fehler durchgegangen, nur zum Schluss gabs eine Meldung:
Error: given IP %s was not mapped to a hostname in phase I.
Please complete phase I of the takeover before initiating the FSMO takeover.
2017-02-10 19:18:23,350 Der Beitritt zur Active Directory Domäne wurde noch nicht erfolgreich abgeschlossen.
Das dürfte passiert sein, weil man dem bridge-Interface keine zweite IP (die des übernommenen Servers) zuweisen kann?
Nun ist die Frage ob der Takeover ansonsten abgeschlossen ist, oder ob ein wichtiger Teil aufgrund dieses Fehlers noch fehlt?
Es klingt als würden die FSMO Rollen noch fehlen (zuminest lese ich das so aus den drei Zeilen) die sind schon essentiell wichtig. Können Sie die mal prüfen:
root@ucs-7437:~# samba-tool fsmo show
Dann wäre natürlich auch das adtakeover.log noch interessant.
Ich muss dazu sagen, dass ich gestern noch folgendes gemacht habe, lt. dieser Seite:
Sieht gut aus, oder?
Andere kleine Frage: Wo könnte ich am besten einen Autostart-Befehl unterbringen, welcher mir die 2. IP (vom übernommenen Server) auf die bridge setzt (ifconfig br0:1 192.168.2.3)?
Ansonsten muss ich das bei jedem Neustart wieder von Hand machen, also etwas umständlich…
Irgendwas scheint da nicht zu stimmen:
Wenn ich einen Rechner in die UCS-Domain aufnehmen will, bricht Windows sofort mit der Fehlermeldung ab,
dass die Domain nicht gefunden werden konnte:
[code]Der folgende Fehler ist beim Abfragen von DNS über den Ressourceneintrag der Dienstidentifizierung (SRV) aufgetreten,
der zur Suche eines Active Directory-Domänencontrollers für die Domäne “BAUR-********” verwendet wird:
Fehler: “Der DNS-Name ist nicht vorhanden.”
(Fehlercode 0x0000232B RCODE_NAME_ERROR)
Es handelt sich um die Abfrage des Dienstidentifizierungseintrags (SRV) für _ldap._tcp.dc._msdcs.BAUR-********.[/code]
Die DNS-Einträge sollten aber eigentlich alle passen, habe das mit einem anderen Server verglichen (anderer Kunde).
DHCP oder statisch Adressen hab ich probiert, ändert nichts am Problem.
Ein nslookup auf dem UCServer liefert einen Feher:
root@ucserver:~# nslookup
> set q=srv
> _ldap._tcp.dc._msdcs.baur-********.local
Server: 192.168.2.2
Address: 192.168.2.2#53
** server can't find _ldap._tcp.dc._msdcs.baur-********.local: NXDOMAIN
Bitteschön, scheint in der Tat das Problem zu sein:
root@ucserver:~# univention-s4search --cross-ncs objectClass=dnsZone dn
# record 1
dn: DC=baur-********.local,CN=MicrosoftDNS,DC=DomainDnsZones,DC=baur-********,DC=local
# record 2
dn: DC=_msdcs.baur-********.local,CN=MicrosoftDNS,DC=ForestDnsZones,DC=baur-********,DC=local
# record 3
dn: DC=2.168.192.in-addr.arpa,CN=MicrosoftDNS,CN=System,DC=baur-********,DC=local
# record 4
dn: DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=baur-********,DC=local
# returned 4 records
# 4 entries
# 0 referrals
Feb 14 11:36:15 ucserver named[16658]: Loading 'samba4.zone' using driver dlopen
Feb 14 11:36:15 ucserver named[16658]: samba_dlz: started for DN DC=baur-********,DC=local
Feb 14 11:36:15 ucserver named[16658]: samba_dlz: starting configure
Feb 14 11:36:15 ucserver named[16658]: samba_dlz: trying partition 'CN=MicrosoftDNS,CN=System,DC=baur-********,DC=local'
Feb 14 11:36:15 ucserver named[16658]: samba_dlz: configured writeable zone '2.168.192.in-addr.arpa'
Feb 14 11:36:15 ucserver named[16658]: samba_dlz: pre-W2k3 zone found
Feb 14 11:36:15 ucserver named[16658]: samba_dlz: trying partition 'CN=MicrosoftDNS,DC=DomainDnsZones,DC=baur-********,DC=local'
Feb 14 11:36:15 ucserver named[16658]: samba_dlz: configured writeable zone 'baur-********.local'
Feb 14 11:36:15 ucserver named[16658]: samba_dlz: Ignoring dnsZone _msdcs.baur-********.local
Ich habe testweise das DNS-Backend von samba4 auf ldap umgestellt, damit hat die Aufnahme in die Domain glücklicherweise geklappt!
Gibt es irgendwelche Nachteile mit dem ldap-Backend, oder sollte die Zone auf jeden Fall verschoben werden mit dem genannten Skript?
Wird es für dieses Problem evtl. auch ein Errata Update geben? Ich denke das kommt öfters vor…?
Ich würde empfehlen, das Backend auf LDAP zu lassen, das hat keine Nachteile. Wie wollen langfristig aber eigentlich dafür sorgen das diese Fälle (in denen Zonen an der falschen Stelle sind) automatisch an die richtige Stelle verschoben werden. Meine Empfehlung geht dann eher dahin, ein Update abzuwarten was das behebt.
Vielen Dank für ihren Hinweis, so hab ich das nun eingestellt und es passt soweit alles!
Vielleicht könnten sie hier im Forum darüber berichten, sobald das Problem gefixt worden ist?
