User-Anmeldung nach Servertausch nicht möglich

[WIVO 0]

Hallo Leute,

 

bin gerade ganz frisch bei Euch angemeldet - HALLO.

 

...und da habe ich auch schon ein kleines Problemchen ;-)

Ich habe mir im Büro eine Testumgebung aufgebaut, also kein Problem wenn was daneben geht.

Situation:

Ein Server, welcher ohne Daten von einem Kunden per Image (Acronis) auf unseren Testserver kopiert wurde.

Dabei handelt es sich um den einzigen DC mit Server 2003 Enterprise (64) in der Domäne.

 

Ein neuer Server wurde komplett neu mit Server 2008 R2 Datacenter installiert und in die Domäne aufgenommen.

Laut super Anleitungen aus diesem Forum - hierzu ein herzliches DANKESCHÖN!!, habe ich den neuen Server als Master mit ADPREP und DCPROMO installiert. Auch die DNS und Schemamaster sowie der globale Katalogserver wurden erfolgreich übertragen. Alle Rollen sind wunderbar am neuen Server angekommen...

Hier laufen auch DNS- und WINS Server.

 

Ein Kunden-PC, welcher vorher bereits in der Domäne war, wurde ebenfalls der Umgebung zugefügt.

Nun wollte ich diesen PC an der Dom anmelden und genau da liegt mein Problem. Alle Dom-User können sich nicht mit diesem PC in der Domäne anmelden.

Erst wenn ich den PC aus der Dom in eine Arbeitsgruppe schiebe und dann neu an der Domäne anmelde, klappt es.

 

Nun möchte ich dieses Vorgehen beim Kunden natürlich vermeiden ;-)

 

Alle Rechner haben feste IP´s und den neuen Server als prim-DNS und den alten Server als sec-DNS eingetragen.

 

Bin für alle Hinweise und Beiträge dankbar und bedanke mich schon im Voraus!

 

LG

WIVO

[monstermania 53]

Moin,

das verhalten ist normal! Sind absolute Basics im AD.

Jedes Domänenmitglied (Workstation) bekommt ein Computerkonto im AD. Dieses Konto wird bei laufender Umgebung regelmäßig zwischen DC und Workstation aktualisiert (Computerkennwort, automatische Änderung standardmäßig alle 30 Tage).

Ich gehe mal davon aus, dass die besagte Workstation in der Domäne (Echtumgebung) weiter genutzt wurde und das Kennwort des Computerkonto's zwischen AD und der WS aktualisiert wurde. Hängst Du jetzt die WS in Deine Testumgebung passt natürlich das Computerkonto auf der WS nicht mehr zum Computerkonto im AD zu deinem Test-DC. Folglich kann sich auch kein User über diesen PC an der Domäne anmelden. 

 

Lösung hast Du ja auch schon gefunden.

bearbeitet 11. November 2015 von monstermania

[WIVO 0]

Moin,

das verhalten ist normal! Sind absolute Basics im AD.

Jedes Domänenmitglied (Workstation) bekommt ein Computerkonto im AD. Dieses Konto wird bei laufender Umgebung regelmäßig zwischen DC und Workstation aktualisiert (Computerkennwort, automatische Änderung standardmäßig alle 30 Tage).

Ich gehe mal davon aus, dass die besagte Workstation in der Domäne (Echtumgebung) weiter genutzt wurde und das Kennwort des Computerkonto's zwischen AD und der WS aktualisiert wurde. Hängst Du jetzt die WS in Deine Testumgebung passt natürlich das Computerkonto auf der WS nicht mehr zum Computerkonto im AD zu deinem Test-DC. Folglich kann sich auch kein User über diesen PC an der Domäne anmelden. 

 

Lösung hast Du ja auch schon gefunden.

Hallo Monstermania,

 

vielen Dank für die Erklärung.

Der PC war schon ein paar Wochen vorher im Ruhestand. Die 30 Tage sind jetzt bei der Wiedereinschaltung in der Testumgebung überschritten.

Das bedeudet, dass bei der tatsächlichen Umstellung alle Client-PC´s, welche innerhalb dieser 30 Tage wieder angemeldet werden, sich ganz normal an der Dom anmelden könne, oder?

[daabm 1.185]

Nein, das Verhalten ist "nicht deterministisch". Wenn Du auf die sichere Seite willst: Deaktiviere die Änderung von Computerkennwörtern in der Kundendomäne.

[blub 115]

Nein, das Verhalten ist "nicht deterministisch". Wenn Du auf die sichere Seite willst: Deaktiviere die Änderung von Computerkennwörtern in der Kundendomäne.

Das meinst du jetzt aber nicht wirklich ernst, einfach beim Kunden produktiv ein wichtiges Securityfeature abdrehen?

https://technet.microsoft.com/en-us/library/cc785826.aspx -> notes

 

abgesehen davon dürfte das besprochene Problem eher mit dem Clonen und damit einer neuen Domain-SID zu tun haben. Der Maschinenaccount eines Clients im AD läuft in dem Sinne ja nicht ab. Client und AD können sich auch nach Ablauf der 30 Tage  problemlos synchronisieren 

http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx

 

blub

[monstermania 53]

@WIVO

Evtl. wäre es sinnvoll, wenn Du hier mal kurz erklären würdest, was Du mit deinem Konstrukt bezwecken möchtest. Geht es ums Testen der Migration 2003 -> 2008R2!? :confused:  

[WIVO 0]

Guten Morgen,

 

also wenn jetzt die Dom Benutzer-Kennwörter damit gemeint waren, die wurden mit Sicherheit in der Zwischenzeit nicht verändert.

 

 

Sinn und Zweck:

ich selbst habe so eine Migration noch nicht in der Praxis durchgeführt! Jeder muß ja mal anfangen...

Wenn man natürlich die Möglichkeit hat eine solche Testumgebung aufzubauen, was in kleinen Firmen leider nicht selbstverständlich ist, und darin dann einfach nur machen kann, ja, das sollte man nutzen...

 

Wenn dann Schwierigkeiten auftauchen, was in der Praxis meist vorkommt, dann ist es auf Jedenfall sehr lehrreich. Ein Forum wie dieses hier ist dann natürlich genial! - DANKE

 

Gruß

WIVO

[monstermania 53]

@WiVO

Also nur zum testen!?

Dann ist es ja nicht weiter schlimm. Aber ich verstehe nicht, wieso Du dann Angst hast, dass das Problem mit den anderen Clients beim Kunden dann später auch auftreten sollte!?

So etwas passiert halt bzw. kann passieren, wenn man einen DC mal eben in eine Testumgebung clont. Bei der Echtmigration hast Du das Problem ja nicht!

 

Du solltest Dich mal mit den absoluten AD-Grundlagen beschäftigen. Einfach mal Google fragen. In dem Zusammenhang kannst Du auch gerne mal nach dem Begriff "USN-Rollback" suchen. Tritt gerne mal auf, wenn man es mit mehreren DC's und clonen versucht ;).  

Nochmal:

Computerkonten sind keine Benutzerkonten!

Computerkennwörter sind keine Benutzerkennwörter!

Den Unterschied sollte man auf jedem Fall verstehen...

 

Teste die Migration und dokumentiere alle Schritte. Wenn die Testmigration sauber abgeschlossen wurde, kannst Du anhand Deiner Aufzeichnungen die Echtmigration entspannt angehen.

[WIVO 0]

Ja, zuerst zum Test. In ca 1-2 Wochen (hängt dann vom Kunden ab) ist dann der Ernstfall mit dem neuen Server.

 

Das mit der Doku in der Testumgebung habe ich gemacht und bin auch froh drüber. Manchmal stolpert man ja auch über seine eigenen Füße ;-)))

Ja, das mit den Konten habe ich schon verstanden, war nur kurz verunsichert...

Auch den Tipp mit USN-Rollback werde ich beherzigen!

 

Besten Dank!

[Dukel 436]

Wieso Server 2008 und kein aktuellen Server?

Wenn du so eine Migration testen willst dann würde ich als erstes einen DC und einen Client übernehmen und den Zugriff testen und dann die Migration durchführen.

 

Im zweifel einfach nochmal von vorne anfangen.

[daabm 1.185]

Das meinst du jetzt aber nicht wirklich ernst, einfach beim Kunden produktiv ein wichtiges Securityfeature abdrehen?

https://technet.microsoft.com/en-us/library/cc785826.aspx -> notes

Doch, das meine ich. Ob ich einen Hash klaue, der gestern gesetzt wurde oder einen Hash, der vor einem Jahr gesetzt wurde, spielt keine Rolle. Oder doch?

Ein "wichtiges" Security Feature ist das für Workstations IMHO nicht...

[blub 115]

Am Computerpasswort hängt die gesamte Sicherheit der Kerberosmimik. d.h. mit dem Computerpasswort lässt sich das Sessionticket einer Maschine faken.

Passwörter bzw. Hashes sollen regelmäßig geändert werden, das hat seine Gründe!

 

Welchen Sinn soll denn die Deaktivierung machen? Der "Ablauf" des Computerpassworts jedenfalls nicht!

http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx

 

Und wenn Microsoft schon selbst sehr deutlich schreibt:

"This security setting should not be enabled."

https://technet.microsoft.com/en-us/library/cc785826.aspx

[ChrisRa 42]

Mit dem Passwort des Computerkontos wird der Securechannel aufgebaut, worüber dann u.a. auch die Kerberosauthentifizierung läuft. Daher sollte es unbedingt(!) regelmäßig geändert werden.

 

 

Doch, das meine ich. Ob ich einen Hash klaue, der gestern gesetzt wurde oder einen Hash, der vor einem Jahr gesetzt wurde, spielt keine Rolle. Oder doch?

Ein "wichtiges" Security Feature ist das für Workstations IMHO nicht...

 

​Doch, Stichwort Bruteforce. ;-)

bearbeitet 13. November 2015 von ChrisRa

[AustriaWien 10]

Hi WIVO,

 

wenn ich dein erstes Posting durchgehe verstehe ich dein Testszenario folgendermaßen:

 

1. "alter" DC zum laufen bringen & läuft
2. "neuen" DC hinzufügen
3. Rollen übergeben
4. PC "dazuhängen"/einbinden

 

Ich würde den Test allerdings mit einem veränderten Testszenario wiederholen.

 

1. "alter" DC zum laufen bringen & läuft
2. PC "dazuhängen"/einbinden
3. "neuen" DC hinzufügen
4. Rollen übergeben

 

Somit hast du die "alte" Domäne schonmal mit dem Kunden-PC am laufen und bist näher an der Realität.
Wenn dann bei Schritt 2. Anmeldeprobleme auftreten weißt du, daß es nicht an der Migration liegt (sondern z.B. abgelaufenes Computerkennwort).

 

Btw. Soll der "alte" DC dann rausgenommen werden? Wenn Ja, dann kannst du das ja auch noch testen.

lg
D.

bearbeitet 20. November 2015 von AustriaWien

[WIVO 0]

Hallo,

 

@ AustriaWien

Herzlichen Dank für deine Antwort.

Ja, du hast damit recht! Das ist ein guter Ansatz.

Ob der alte DC wirklich aus der Dom genommen wird weiß ich noch nicht.

Der Testaufbau hat gezeigt, dass noch ältere Programme auf dem neuen Server nicht mehr laufen.

Also so wie es ausschaut, lasse ich ihn noch in der Dom mit den lauffähigen Programmen und sitze die Zeit aus, in der die Nutzungsdauer der alten Software so langsam ausläuft. Ist eben natürlich auch eine Geldfrage, denn es sind schon in Summe enorme Kosten, die für neue Lizenzen fällig werden...

Aber den Fall kann ich in meiner Testumgebung auch noch testen ;-)

 

 

LG

WIVO