Rückstufung der Domänen Controller
Nach einer Woche wurde die alten DCs wieder ans Netz genommen und einen Tag gewartet, bis die zwischenzeitlich fünf Domänen Controller wieder im Einklang schnurrten.
In den nächsten Tagen wurde jeden Tag je ein alter DC zu einem normalen Server heruntergestuft.
Dieser Vorgang war dann nach drei Tagen abgeschlossen.
Anheben der Funktionslevel
Als nur noch die zwei neuen DCs vorhanden waren, wurden die Gesamtstrukturfunktionsebene (Forest Function Level) und Domänenfunktionsebene (Domain Functional Level) auf die für uns höchstmögliche Version angehoben.
Am nächsten Tag stellte ich die SYSVOL-Migration von NTFRS auf DFSR um. Als Anleitung diente, wie sonst auch, dieser Blogeintrag. Hier ist ebenso Geduld gefragt, bis bei jedem Zwischenschritt alle Domain Controller fertig sind. Lieber beginnt man damit gleich am Morgen, als kurz vor Dienstschluß. Bei zwei DCs ohne Sub-Domänen geht das relativ zügig. Nach knapp zwei Stunden wurde nur noch per DFSR repliziert.
Damit waren die geplanten Arbeiten für das Jahr 2019 beendet
Weitere Arbeiten
Im neuen Jahr wurde zur Sicherheit ein letztes Backup der Server gemacht, diese aus der Domäne entfernt und hinterher gelöscht.
Anschließend ging es daran das DNS auf verwaiste Einträge zu prüfen und ggfs. hier aufzuräumen.
Ein langgehegter Wunsch war noch offen: Die Abschaffung der Berechtigungen der normalen Benutzerkonten mit lokalen Administratorenrechten sowie die automatische Passwort-Änderung der lokalen Client-Administratoren. Letzteres sollte LAPS von Microsoft beheben.
Ein Praxis-Artikel dazu war auch in der c’t 14/ 2019.
Das Vorgehen hierbei in Stichpunkten:
- LAPS-Client auf allen Client-Rechner installieren
- LAPS mit Fat Client UI, PowerShell-Modul und Gruppenrichtlinien-Vorlagen auf einem Domänen Controller installieren
- Active Directory Schema erweitern
- Vorgesehene OU berechtigen
- GPO erstellen und verknüpfen
LAPS kommt auf alle Clients
Da uns eine Softwareverteilung fehlt, hat sich die Verteilung des LAPS-Clients auf alle Rechner über ein paar Wochen hingezogen. Die Installation über eine AD-GPO-Richtlinie haben wir im Vorfeld schon verworfen. Das ist immer eine ziemliche Krücke und läuft suboptimal. Häufig holt man sich mehr Probleme ins Haus, als es wert ist.
Nach dem Abschluß dieser Tätigkeit letzter Woche ging es an die Installation auf dem ersten DC.
LAPS auf dem DC
Im Vergleich zum Client benötigen wir hier wegen der Bequemlichkeit die graphische Oberfläche, das PowerShell-Modul und die GPO-Vorlagen.
Der “Next, next, finish”-Assistent ist schnell durchgeklickt.
Danach öffnet man als Administrator eine Powershell-Konsole und importiert das dazugehörige Modul.
Mit “Update-AdmPwdADSchema” wird das Active Directory Schema um zwei Attribute erweitert.
Um die eigenen OU, in der Rechner liegen, für LAPS zu berechtigen sucht man sich am einfachsten den CN-Namen der OU über den Reiter “Attribut-Editor” in “Active Directory Benutzer und Computer” (dazu sollte die Erweiterte Ansicht aktiviert sein) und kopiert diesen in die PowerShell-Konsole. Das vermeidet Tippfehler: Set-AdmPwdComputerSelfPermission -OrgUnit “CN=\<unsere Computer-OU\>, DC= \<unser DC-Name\> ,DC= \<unser DC-Endung\> “
Trick 17 mit Selbstüberlistung
An dieser Stelle sind wir böse in eine Falle getappt, die auch im c’t-Artikel nicht behandelt wurde: Die Installation verschiebt die GPO-Vorlagen nur in die Standardverzeichnisse. Deshalb waren die Gruppenrichtlinien für LAPS unter den “Administrative Vorlagen” erstmal nicht verfügbar.
Wer einen “Zentralen Speicher” (central store) für die Gruppenrichtlinien betreibt, muss zwingend die zwei Templates da hin kopieren. Nächstes Hindernis: die Vorlagen heissen nicht, wie ich erwartet hätte, laps.admx und laps.adml. Man muss nach “admpwd.admx” und “admpwd.adml” suchen. Die Sprachdatei “admpwd.adml” gibt es ausschließlich auf Englisch. Daher ist diese in den “en-us”-Ordner im PolicyRepository zu kopieren.
Nachdem diese Hürde erfolgreich umschifft war, konnte man im Gruppenrichtlinien-Editor auf die Einstellungen zugreifen. Einmal GPO-Editor schließen und erneut öffnen ist ebenso hilfreich.
Eine neue Gruppenrichtlinie
Wie stets, wurde ein eigenes, neues Gruppenrichtlinienobjekt unter dem Knoten “Gruppenrichtlinienobjekt” erstellt. Damit stellt man sicher, dass die GPO erst wirksam wird, wenn man sie komplett konfiguriert hat und explizit mit einer OU verknüpft.
Es gibt nur vier Gruppenrichtlinien, somit kann man die Konfiguration zügig abschließen. Als “Gürtel und Hosenträger-ITler” (Gruß an Bud Spencer) sind, wurde sicherheitshalber ein Rechner in unsere Test-OU verschoben. Anschließend die GPO mit dieser OU verknüpft. Der Test verlief erfolgreich.
Damit konnte die Richtlinie mit den Client-OUs verknüpft werden.
“Läuft”
Tags darauf hatten alle Clients ein neues Passwort für unseren zusätzlichen lokalen Administrator. Der Built-in Administrator war vorher schon überall deaktiviert.
Als letzter Punkt steht noch die weitere Verringerung der lokalen Administratoren auf der Agenda. Doch das ist für einen anderen Tag.