Kategorie: Windows Server 2012

Nach dem in einem vorherigen Artikel der Export des Attributes SIDHistory dargestellt wurde, geht es heute um das Leeren des Feldes

Auch hier ist der Powershell-Code sehr überschaubar:

$SAMID = $args[0]
import-module activedirectory
Get-ADGroup $SAMID -server "dc01.testingdomain.local" -Properties sidhistory | foreach {Set-ADGroup $_ -remove @{sidhistory=$_.sidhistory.value}}

Empfehlung: Es sollten die ObjectSIDs genutzt werden. Bei diesen können Umlaute, Sonderzeichen und Leerzeichen ignoriert werden und funktionieren sehr zuverlässig

Selbstverständlich gibt es das ganze auch für Benutzer:

$UserID = $args[0]
import-module activedirectory
Get-ADUser $UserID -server "dc01.testingdomain.local" -Properties sidhistory | foreach {Set-ADUser $_ -remove @{sidhistory=$_.sidhistory.value}}

Über die DHCP-Option im Windows-Server ist es möglich zusätzliche statische Routen zu definieren.

Es gibt allerdings 2 verschiedene Optionen, die nach Server-Version von einander abweichen:

• Option 249 bei Windows Server 2003
• Option 121 ab Windows Server 2008

Dort können wir manuell über den Befehl NETSH Routen definiert werden. Dafür werden folgende Daten benötigt:

• Ziel-Range
• Subnetmask der Zielrange
• Gateway

Die Betriebssysteme ab Vista bzw. Windows Server 2008 können beide Optionen verarbeiten. Sollte man diese Funktionalität für Systeme vor den genannten Betriebssystemen (wie z.B. Windows XP) verwenden wollen, muss die Option 249 verwandt werden.

Bei einer Domänencontroller-Migration passierte für mich etwas ungewöhnliches. Der Domänencontroller war hinzugefügt und die Betriebsmasterrolen übertragen. Für einen Test trennte ich das Netzwerk vom abzulösenden Server und wollte mich an einem Client vergewissern, dass der Umzug erfolgreich war.

Leider griffen die Anmeldeskripte nicht mehr. Auch eine Freigabe NETLOGON auf dem  hinzugefügten Domänencontroller konnte nicht erreicht werden. Bei einem Blick auf den Server musste ich feststellen, dass die erforderliche Freigabeauf dem Server nicht verfügbar war.

Nach etwas Recherche fand ich einen Technet-Artikel, welcher mich zum Ziel führte:

Pfad: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

Objekt: SysvolReady

Dieser Eintrag ist bereits vorhanden und wird auf dem Wert „1“ stehen. Dieser muss nun 2-mal gewechselt werden. Der Wert muss einmal auf „0“ und dann direkt wieder auf „1“ gesetzt werden.

Nach einem anschließenden Neustart steht die Freigabe NETLOGON wieder zur Verfügung.

Weitere Informationen: hier

Um die Berechtigungen für Anmeldeskripte zu vergeben muss der Bearbeiter das Recht des Schreibens im Ordner „Skripts“ unter dem „SYSVOL“ der Domäne.

Zwar wird das SYSVOL auf allen Domänencontrollern repliziert, was nicht für Berechtigungen gilt. Diese muss auf allen Domänencontrollern manuell eingetragen werden. Ansonsten ist der Zugriff für die berechtigten Administratoren nur auf dem angepassten Domänencontroller möglich.

Viele Administratoren arbeiten nicht mit getrennten Accounts zur allgemeinen Arbeit und der administrativen Tätigkeit. Entsprechend kann es zu möglichen Sicherheitslücken kommen, obwohl diese gar nicht eingeplant sind.

Wenn ein Benutzer zum Beispiel Mitglied der Gruppe  „Kontenoperator“ ist, ist es ihm möglich Passwörter zu zurückzusetzen. Das gilt allerdings dann auch für sein eigenes Kennwort. Somit ist es ihm möglich sein Passwort zum Ablauf des maximalen Kennwortalters auf das selbe Passwort zu setzen, was bereits im alten Zyklus genutzt wurde und somit auch die vorgegeben Kennwortchronik der definierten Anzahl der gespeicherten Passwörter zu untergraben.

In einer entsprechenden Konstellation kann es Sinn machen, dass die Benutzer der Gruppe „Kontenoperatoren“ oder auch andere Mitglieder, zum Beispiel zur delegierten OU-Verwaltung eingerichteten Gruppen, bei Ihren Benutzerobjekten in der Berechtigung „Self“ die folgenden Rechte verweigert bekommen:

• Reset Passwort
• Write Accountexpires
• Write UserAccountControl

Über die Anpassung des Rechtes „Reset Passwort“ kann der entsprechende Benutzer sein Kennwort nicht mehr direkt zurücksetzen als Beispiel auf den alten Stand.

Durch die Anpassung des Rechtes „Write Accountexpires“ wird dem Benutzer die Berechtigung verwehrt sein Ablaufdatum selberständig zu editieren.

Mit der Anpassung der Berechtigung „Write UserAccountControl“ wird verhindert, dass sich der Anwender seinen deaktivierten Account wieder freigibt und die Option setzt, dass sein Kennwort nicht mehr abläuft.

Mit diesen Maßnahme ist eine deutliche Verbesserung der Sicherheit für administrative Benutzer bzw. Benutzern mit erweiterten Berechtigungen.