Mythen zu AD-Computerkonten (Neuinst., Weiterverwenden Computername, SID)

[notimportant 0]

Hallo zusammen,

da hierzu bei uns immer wieder Unstimmigkeiten auftreten und im Netz viel Falsches niedergeschrieben wird, wollte ich das Thema hier einmal diskutieren.

 

Folgendes Szenario, wie es bei uns oft vorkommt:

Ein Client in der Domäne wird neu installiert, da das Blech aus der Garantie fällt. Ziel: Gleicher Hostname. Methode: eigenes Deployment inkl. autom. Domain-Join.

(Zusatzinfo: Die AD-Clients bekommen IPs über DHCP, reservieren ihre DNS-Records eigenständig im DNS über sichere DDNS-Updates. Der DHCP ist über einen srv-Account auf das DNS berechtigt, nutzt das aber primär für nicht-AD-Geräte wie MFGs)

 

Wir haben jetzt zwei Vorgehensweisen, die stark differieren, aber beide funktionieren.

Die einen Kollegen machen vor einer Neuinstallation im Prinzip _nichts_ und haben keinerlei Probleme. Andere wiederum gehen auf Nummer sicher, benennen die Clients um, warten auf AD und DNS-Replikation und installieren dann den Client mit "altem" Namen neu. Zweitere Vorgehensweise funktioniert natürlich. Die erstere bereitet mir ein wenig Kopfzerbrechen, sodass ich sie noch einmal genau nachvollzogen habe.

 

(1) Client "PC-Eins" erstmalig installieren. Kein namensgleiches Konto im AD vorhanden. Adresse per DHCP 10.0.1.1. Der DNS Record hat als Owner "PC-Eins$", die SID lautet: S-1-2-3-4

(2) Client herunterfahren

(3) Nicht(!!) das Computerkonto zurücksetzen!

(4) Neuen Client mit gleichen Namen "PC-Eins" installieren.

 

Beobachtungen:

Ich habe Computer-FullControl-Rechte auf die OU des Clients. Ich werde nicht gefragt, ob ich das Konto übernehmen will bzw. darauf hingewiesen, dass der Name im AD bereits existiert. Der Client wird einfach deployt und übernimmt das Konto.

Die Domain-SID bleibt gleich! S-1-2-3-4

Die IP-Adresse ist 10.0.1.2 - der DNS Record wird aktualisiert, da der "neue" Client (da gleiche SID 1-2-3-4 in der ACL des DNS-RR) ja das Recht dazu hat.

Wie zu erwarten verliert der "alte" Rechner die Vertrauensstellung zur Domäne. Der "neue" kann mit Domain-Konten genutzt werden. Alles paletti.

 

Fragen:

Ich dachte eher, dass bei o.g. Vorgehensweise das Computerobjekt eine neue SID bekommt. Das scheint nicht zu stimmen. Ist das das Standardverhalten? Existiert ein Szenario in dem die Domain-SID neu gesetzt wird?

 

Warum wird immer empfohlen das Computerkonto zurückzusetzen? Soweit ich das verstehe wird dadurch "nur" der SecureChannel repariert und das Computerpasswort AD<->Client versucht zu synchronisieren.

Wenn ich über "Konto zurücksetzen" das Computerpasswort resette muss ich die betroffene Maschine _nicht_ neu in die Domäne aufnehmen - wir fixen so ab und an den Verlust der Vertrauensstellung.

Welchen Unterschied würde das bei o.g. Szenario bewirken? Durch die Übernahme des Computerkontos wird das Computerpasswort ja sowieso neu gesetzt. Passiert noch mehr?

 

Gibt es einen sinnvollen Grund die oft propagierte "saubere" Methode "Client aus der Domäne nehmen + Computerkonto löschen -> mit "altem" Namen neu installieren" zu nutzen? In meinen Augen nicht. Vielmehr verliert man ja alle Gruppenmitgliedschaften und muss diese ggf. nachhziehen + Warten auf das Ziehen der GPOs nach Wiedeaufnahme usw...

 

Wann werde ich darauf hingewiesen, dass bereits ein Computerkonto in der Domäne existiert? Nur wenn der zu übernehmende Client gerade läuft?

 

Vielleicht kann man hier ein wenig Licht ins Dunkel bringen.

 

Grüße

bearbeitet 10. Dezember 2019 von notimportant

[daabm 1.366]

Wenn Du einen Client in ein bestehendes Computerkonto "reinjoinst", bleibt die SID des Domain Accounts natürlich gleich. Nur das Secure Channel Password (=Computerpasswort) wird neu gesetzt.

Wann da ein Hinweis kommt und wann nicht, weiß ich nicht - wir machen das nicht von Hand

[notimportant 0]

Danke. Keine Ahnung woher ich jetzt den Gedanken hatte, dass die SID neu gesetzt wird. Per Hand wird das bei uns normalerweise auch nicht gemacht. Ich habe allerdings ein wenig getestet, da der Defaultwert für den Standarduser für Domain-Joins aus historischen Gründen aktiv gelassen wurde.

 

Hier werde ich tatsächlich gewarnt, dass das Computerobjekt von einem anderen Account erstellt wurde und ich darf es nicht übernehmen. Das Zurücksetzen des Computerpassworts bringt gar nichts. Warum auch... Das ist mir noch nicht klar, warum das immer empfohlen wird... Um Problemen vorzubeugen?

 

Normalerweise wird ja versucht das Passwort zwischen AD und Rechner zu synchronisieren. Wenn der Rechner nicht online ist, wird lediglich das Passwort auf dem Computerobjekt neu gesetzt und mehr doch nicht?

[NilsK 2.957]

Moin,

 

ich verstehe ehrlich gesagt den Grund der Frage nicht, weil mir das Ziel der Vorgänge unklar ist. Warum würde man in dem Szenario überhaupt das Computerkonto weiterverwenden? Es geht doch um Clients? In wie vielen Gruppen werden die schon Mitglied sein? Und "ziehen" muss der Client die GPOs sowieso, er wurde ja neu installiert.

 

Gruß, Nils

 

[notimportant 0]

Die Frage ist eher akademisch.

 

Die Lage ist einfach so, dass bestimmte Teams das Computerkonto weiterverwenden und andere eben den "sicheren" Weg gehen.

 

Gedanken machen müssen wir uns primär deswegen, weil im derzeitigen Prozess das DNS Probleme macht. Die Clients sind Owner der Records und das DNS ist auf den DomainAdmin-Kreis delegiert. Wird ein Computerkonto weitergenutzt, kann der Record aufgrund derselben SID vom neu installierten Client genutzt werden.

Lösche ich das Computerkonto, kann sich der Client nicht im DNS registrieren, da seine "alte" SID der Owner des DNS-Records bleibt.

 

Konzeptuell werden die A-Records nicht vom DHCP gesetzt und das Scavenging benötigt einige Tage um aufzuräumen...

[NilsK 2.957]

Moin,

 

wobei sich der Prozess ja leicht so erweitern ließe, dass beim Löschen des Computerkontos auch der DNS-Eintrag ausdrücklich gelöscht wird. Intuitiv erschiene mir das logischer und sinnvoller als ein Workaround mit dem Wiederverwenden des Kontos. Die Client-Installation hat ja auch lokal eine andere Identität (lokaler SID).

 

Am Ende akademisch, wie du schon sagst. Wichtig ist, dass man seine Prozesse im Griff hat.

 

Gruß, Nils

 

[Dukel 455]

Neuer Computername für einen neuen Rechner, dann ist der DNS Eintrag auch neu.

 

Sprich ich habe pc-0001 bis pc-0100 und lösche pc-0065 vergebe ich diesen nicht neu sondern der nächste Rechner bekommt pc-0101.

[NilsK 2.957]

Moin,

 

vor 3 Stunden schrieb notimportant:

Normalerweise wird ja versucht das Passwort zwischen AD und Rechner zu synchronisieren. Wenn der Rechner nicht online ist, wird lediglich das Passwort auf dem Computerobjekt neu gesetzt und mehr doch nicht?

nein, wenn der Rechner nicht online ist, geschieht gar nichts. Einfach aus dem Grund, dass es der Client ist, der das Kennwort neu setzt. Ginge ja auch kaum anders.

 

[Wann läuft ein Maschinenaccount / Computerkonto ab? Gar nicht! | Aktives Verzeichnis Blog]
https://blogs.technet.microsoft.com/deds/2009/01/20/wann-luft-ein-maschinenaccount-computerkonto-ab-gar-nicht/ 
 

Gruß, Nils

PS. ... ach ja, Fabian ... der war auch schon lange nicht mehr hier.

bearbeitet 13. Dezember 2019 von NilsK

[notimportant 0]

vor 1 Stunde schrieb NilsK:

wobei sich der Prozess ja leicht so erweitern ließe, dass beim Löschen des Computerkontos auch der DNS-Eintrag ausdrücklich gelöscht wird. Intuitiv erschiene mir das logischer und sinnvoller als ein Workaround mit dem Wiederverwenden des Kontos.

Die Prozesse sind von Microsoft designt worden : ) Da rüttelt niemand so einfach daran. Ich würde das auch lieber den DHCPs überlassen. (Oder gibt es noch einen eleganteren Weg?) Aber erstaunlicherweise gibt es so gut wie immer einen Grund, warum etwas nicht auf dem einfacheren Weg gemacht wurde.

 

vor 1 Stunde schrieb Dukel:

Neuer Computername für einen neuen Rechner, dann ist der DNS Eintrag auch neu.

Das wäre klar. Und im Prinzip nutzen gewisse Teams auch diesen Weg, wenn sie die alten Rechner umbenennen und dann erst den neuen installieren, oder zunächst neue Namen verwenden und dann zurückbenennen. Im Prinzip haben wir auch kein Problem, man kenn seine Vorgehensweisen.

 

vor 1 Stunde schrieb NilsK:

nein, wenn der Rechner nicht online ist, geschieht gar nichts. Einfach aus dem Grund, dass es der Client ist, der das Kennwort neu setzt. Ginge ja auch kaum anders.

Ich habe das zwar vermutet, aber auch Fachliteratur ist ab und an verwirrend geschrieben. Ah, ok, danke, der Link ist interessant mit ein paar Feinheiten. Dass Computeraccounts nicht ablaufen ist klar, damit haben wir zum Glück kein Problem, da andere Prozesse deutlich früher greifen.

 

Danke für die Antworten!

[Dukel 455]

16 minutes ago, notimportant said:

Das wäre klar. Und im Prinzip nutzen gewisse Teams auch diesen Weg, wenn sie die alten Rechner umbenennen und dann erst den neuen installieren, oder zunächst neue Namen verwenden und dann zurückbenennen. Im Prinzip haben wir auch kein Problem, man kenn seine Vorgehensweisen. 

Wieso brauchen neue Rechner einen alten Namen?

[NilsK 2.957]

Moin,

 

vor 29 Minuten schrieb notimportant:

Oder gibt es noch einen eleganteren Weg?

ein Skript, das das Konto und den DNS-Record löscht?

 

Gruß, Nils

 

[notimportant 0]

vor 4 Stunden schrieb Dukel:

Wieso brauchen neue Rechner einen alten Namen?

Die Rechnernamen sind einem Konzept untergeordnet, die u.a. den Standort, Zugehörigkeit, TelNummern o.ähnliches wiedererkennen lassen. Bei einer 5-stelligen Anzahl...

 

vor 4 Stunden schrieb NilsK:

ein Skript, das das Konto und den DNS-Record löscht?

Das ginge technisch sicherlich. Die organisatorische Frage ist da schwieriger : ) (Behörde) Vielleicht eher die Umsetzung, dass die DHCPs beide Records schreiben.

 

Grüße

[NilsK 2.957]

Moin,

 

Das mit dem DHCP ist ... so mittelzuverlässig.

 

Gruß, Nils

[daabm 1.366]

vor 12 Stunden schrieb notimportant:

Die Lage ist einfach so, dass bestimmte Teams das Computerkonto weiterverwenden und andere eben den "sicheren" Weg gehen. 

lol - wie viele "Teams" deployen denn bei Euch neue Computer? Eigentlich sollten das max. 3 sein (Domain Controller, Server, Clients)

 

Edit: Die Rechnernamen haben Bestandteile, die eigentlich in ein Asset Management (CMDB) gehören? Das geht IMHO gar nicht, auch wenn das viele Reviews ausdrücklich loben...

bearbeitet 13. Dezember 2019 von daabm

[notimportant 0]

vor 13 Stunden schrieb NilsK:

Das mit dem DHCP ist ... so mittelzuverlässig.

Ok. Wir können aber auch mit dem derzeitigen Verhalten problemlos leben. In Zukunft wird man sicherlich über neue Ansätze nachdenken.

vor 9 Stunden schrieb daabm:

Eigentlich sollten das max. 3 sein (Domain Controller, Server, Clients)

Flächenbehörde mit best. Anforderungen. Für DCs ganz klar ja, für Server teilweise, für Clients ist eine Konzentration nicht möglich und nicht gewollt. Wäre bei dieser Anzahl und Struktur auch unmöglich.