Windows Server 2012 R2

Group Managed Service Accounts erstellen

Zuletzt aktualisiert: 05. November 2015 | Veröffentlicht: 05. November 2015 | Geschrieben von Köck Bernhard | Zugriffe: 3118

Bewertung: 5 / 5

Seit Windows Server 2008 gibt es sogenannte Managed Service Accounts (MSA). Diese MSAs konnten allerdings immer nur für einen Server verwendet werden. Mit Windows Server 2012 hat Microsoft diese Einschränkung mit der Einführung der Group Managed Service Accounts (GMSA) aufgehoben. Ein Service Account kann nun mit einer Gruppe von Computern verknüpft werden.

Das Erstellen und Konfigurieren eines gMSA wird über die Powershell durchgeführt.

Voraussetzungen: Ein Domain Controller (DC) auf Basis von Windows Server 2012 oder höher muss im Netzwerk vorhanden sein.

Erstellen eines gMSA (als Gedächtnisstütze für mich)

Powershell (admin) starten:

Add-KDSRootKey–EffectiveImmediately (kann je nach Anzahl der DCs bis zu 10 Stunden dauern)

deshalb kleiner Trick:

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

überprüfen mit Get-KdsRootKey

Im AD habe ich eine Sicherheitsgruppe angelegt (GG_GMSA), in der alle Server als Mitglieder hinzugefügt werden, die den gMSA verwenden werden

Anlegen des gMSA

New-ADServiceAccount GMSA -DNSHostName DC01.winxperts.intern -PrincipalsAllowedToRetrieveManagedPassword GG_GMSA -ManagedPasswordIntervalInDays 30 -ServicePrincipalNames http/DC01.winxpertsintern

Server neu starten

Install-AdServiceAccount GMSA

Test-AdServiceAccount GMSA

Aufgabenplanung mit gMSA (geht nicht über GUI sondern nur mit Powershell)

Nicht vergessen, dem Account das Recht zum Anmelden als Stapelverarbeitung bzw. als Dienst einzuräumen (GPO)

Beispiel:

$action = New-ScheduledTaskAction "Powershell.exe -ExecutionPolicy Bypass -File c:\!scripts\wsus.ps1"

$trigger = New-ScheduledTaskTrigger -At 21:00 -Weekly -DaysOfWeek Friday

$principal = New-ScheduledTaskPrincipal -UserID winxperts4all\GMSA$ -LogonType Password

Windows Server 2012 – WSUS Server Bereinigung mittels Powershell

Zuletzt aktualisiert: 09. September 2015 | Veröffentlicht: 09. September 2015 | Geschrieben von Köck Bernhard | Zugriffe: 2856

Bewertung: 5 / 5

Die WSUS Datenbank sollte in regelmäßigen Abständen werden. Dies lässt sich über eine graphische Oberfläche in den Windows Update Services erledigen. Eine automatische regelmäßige Bereinigung lässt sich aber am besten über die Power Shell einrichten.

Seit Windows Server 2012 sind dafür eigene cmdlets verfügbar.

Invoke-WsusServerCleanup [-CleanupObsoleteComputers] [-CleanupObsoleteUpdates] [-CleanupUnneededContentFiles] [-CompressUpdates] [-DeclineExpiredUpdates] [-DeclineSupersededUpdates] [-InformationAction <System.Management.Automation.ActionPreference> {SilentlyContinue | Stop | Continue | Inquire | Ignore | Suspend} ] [-InformationVariable <System.String> ] [-UpdateServer <IUpdateServer> ] [-Confirm] [-WhatIf] [ <CommonParameters>]

Parameters:

-CleanupObsoleteComputers: Computer bereinigen
-CleanupObsoleteUpdates: Nicht mehr benötigte Updates bereinigen
-CleanupUnneededContentFiles: Nicht benötigte Dateien bereinigen
-CompressUpdates: Nicht mehr benötigte Revisionen der Updates bereinigen
-DeclineExpiredUpdates: Abgelaufende Updates bereinigen
-DeclineSupersededUpdate: Ersatzte Update bereinigen

Daraus kann nun ein zeitgesteuertes Script mit Mail Benachrichtigung gebastelt werden.

FSMO-Rollen zwangsweise übernehmen

Zuletzt aktualisiert: 14. Mai 2015 | Veröffentlicht: 13. Mai 2015 | Geschrieben von Köck Bernhard | Zugriffe: 2439

Bewertung: 5 / 5

Heute hatte ich einen merkwürdigen Fall. Ein virtualisierter Domänencontroller wurde exportiert und auf einem anderen Hyper-V wieder importiert. Dieser ist der einzige DC in der Domäne.

Alles lief zunächst wunderbar, bis ich über den WDS einen PC installieren wollte. Wie immer wollte ich dem neuen Computer über die WDS einen Namen geben, doch dies scheiterte mit einer Fehlermeldung.

Also hinein ins AD und manuell ein Computerkonto anlegen. Doch auch dies scheiterte mit einer Fehlermeldung.

Im Eventlog tauchen Einträge auf, die auf ungültige FSMO Rollen hinweisen.

Da ich keine Computerkonten anlegen kann, muss etwas mit dem RID Master nicht stimmen. Da es keinen zweiten DC zum Übertragen der Rollen gibt, muss es mit einer erzwungenen Übertragung gehen.

Kommandozeile: ntdsutil eingeben

roles

connections

connect to server ‹Servername›

q

seize ‹FSMO-Rolle›

‹Servername› ist dabei derjenige Server, welcher die Rolle erhält.

Die für die FSMO-Rollen verwendeten Schlüsselwörter sind

seize infrastructure master Infrastruktur-Master
seize naming master Domänennamen-Master
seize PDC PDC-Emulator
seize RID master RID-Master
seize schema master Schemamaster

Nun funktioniert der RID Master wieder.

Quelle für die Befehle: http://www.windowspro.de/andreas-kroschel/fsmo-rollen-im-ad-schema-uebernehmen#comment-34104

Windows UEFI USB Boot Medium erstellen

Zuletzt aktualisiert: 29. Mai 2015 | Veröffentlicht: 29. Mai 2015 | Geschrieben von Köck Bernhard | Zugriffe: 3962

Bewertung: 5 / 5

Um ein UEFI-Setup vom USB-Stick zu starten,muss dieser mit FAT32 formatiert sein. Ein Problem von FAT32 ist, dass die Größe einer einzelnen Datei mit 4 GB begrenzt ist.
Möchte man z.B. Windows Server 2012 R2 verwenden, dann ist die WIM Datei über 5 GB groß.

Hier muss man nun ein wenig in die Trickkiste greifen. Aber das Problem lässt sich mit Windows eigenen Boardmitteln elegant lösen.

Mein Lösungsweg sieht folgendermaßen aus:

Windows Server 2012 R2 ISO mounten und Inhalt in einen Ordner kopieren.
Nun muss man die >5GB große install.wim Datei aufsplitten. Dies erreicht man mit folgendem Befehl:
Dism /Split-Image /ImageFile:D:\install.wim /SWMFile:D:\install.swm /FileSize:4000 /CheckIntegrity
Je nach eingestellter FileSize erhält man nun mehrere install.swm Dateien; die install.wim Datei kann gelöscht werden.
Nun kann man entweder wieder eine ISO Datei erstellen oder man kopiert den Inhalt auf einen bereits für UEFI formatierten USB Stick.

Für das Erstellen des USB Sticks habe ich das Programm Rufus verwendet

weitere interessante Seiten zu diesem Thema:

https://www.thomas-krenn.com/de/wiki/Windows_UEFI_Boot-Stick_unter_Windows_erstellen

http://www.win-lite.de/forum/windows-8/how-to-uefi-usb-bootstick-mit-wims-4gb/

Kennwörter über GPP zu verteilen ist leider keine gute Idee

Zuletzt aktualisiert: 27. April 2015 | Veröffentlicht: 27. April 2015 | Geschrieben von Köck Bernhard | Zugriffe: 1674

Bewertung: 5 / 5

Über GPP (Group Policy Preferences) lassen sich auch Kennwörter für bestimmte Aufgaben vertielen (z. B. Lokale Benutzer und Gruppen). So kann man z. B. das Kennwort des lokalen Admin Kontos auf einem Client recht schnell ändern.

Das Kennwort wird in einer XML Datei verschlüsselt gespeichert. (Verzeichnis SYSVOL, Attribut cPassword, 32-bit AES Verschlüsselung)

Leider ist die verwendete Verschlüsselung realtiv schwach und es wurde der Schlüssel veröffentlicht.

Schlüssel: The 32-byte AES key is as follows:

4e 99 06 e8  fc b6 6c c9  fa f4 93 10  62 0f fe e8
f4 96 e8 06  cc 05 79 90  20 9b 09 a4  33 b6 6c 1b

Mit einem Powershell Script kann die XML Datei ausgelesen werden und das Kennwort entschlüselt werden. Dazu sucht man einfach im SYSVOL Verzeichnis nach allen Dateien die Groups.xml heißen.

Microsoft hat schon vor längerer Zeit einen Security Patch dazu veröffentlicht. Nach dem Einspielen des Patches steht das Ändern von Kennwörtern über die GPP nicht mehr zur Verfügung.