Wenn man automatisiert Benutzerkonten in einer AD-Umgebung erzeugt, kann es – je nach Methode – vorkommen, dass diese Konten keine Kennwörter haben. Das passiert etwa, wenn man solche Konten mit dem uralten Kommando csvde.exe erzeugt. Die Konten sind dann auch deaktiviert, es entsteht also keine direkte Gefahr. Es lauert aber eine – mit der man wahrscheinlich nicht rechnet.

Hinter den Kulissen setzen solche Tools nämlich oft ein Attribut bei den Konten, damit sie diese überhaupt mit leerem Kennwort erzeugen können, auch wenn die Kennwortrichtlinie das gar nicht zulässt. Das Attribut heißt “PasswordNotRequired” oder auch “PASSWD_NOTREQD”. Das Perfide daran: die grafischen AD-Tools zeigen das Attribut nicht an. Und auch sonst ist es nicht ganz einfach zu handhaben, es ist nämlich ein Flag in einem Binärfeld des AD, nämlich “userAccountControl” (mehr dazu findet sich bei Microsoft Learn).

Manche Schwachstellen-Scanner schlagen aber – zu Recht – an, wenn sie solche Accounts auffinden. Aber wie wird man das Attribut nun wieder los?

Da man es meist wohl einfach für alle Konten zurücksetzen will, habe ich hier ein Holzhammer-Skript. Es sucht alle Konten, bei denen das Flag gesetzt ist, und setzt es bei jedem dieser Accounts zurück. Am Ende prüft es noch mal, ob das auch geklappt hat.

$SuspectUsers = (Get-ADUser -Filter {PasswordNotRequired -eq $true})

$Count = $SuspectUsers.Count

"Found $Count suspect users."


$SuspectUsers | ForEach-Object {

    "Correcting $_.name ..."

    Set-ADUser $_ -PasswordNotRequired $false

}


$SuspectUsers = (Get-ADUser -Filter {PasswordNotRequired -eq $true})

$Count = $SuspectUsers.Count

"$Count suspect users left."

Wer sich schnell einen Überblick über die Objektstruktur einer Active-Directory-Umgebung verschaffen möchte, kommt oft sehr weit mit der Information, in welchen OUs wie viele Objekte liegen. Diese Daten lassen sich mit der PowerShell recht schnell zusammentragen.

Das folgende Skript liest die OU-Struktur der Domäne aus und bringt sie in eine sortierbare und übersichtliche Form. Für jede OU zählt es dann, wie viele User-, Computer- und Gruppenobjekte sich dort befinden. Öffnet man das Ergebnis dann in Excel (oder einem vergleichbaren Programm), dann lässt es sich gut auswerten:

• Die OU-Liste ist alphabetisch geordnet nach der Spalte “canonicalName”, was die Anordnung der OUs logisch korrekt abbildet
• Die Spalte “Depth” gibt die OU-Ebene an, also die Verschachtelungstiefe
• Die Spalte “Structure” stellt den Namen der OU eingerückt dar, indem es eine Reihe Leerzeichen je nach Verschachtelungstiefe voranstellt. Das ist simpel, aber ausreichend, um die Hierarchie auch optisch zu erkennen.
• Die letzten drei Spalten geben an, wie viele “Users”, “Groups” und “Computers” es in der jeweiligen OU gibt.

Hier das Skript. Es ist recht kurz, daher einfach in einen Editor kopieren und ausführen.

'distinguishedName;name;canonicalName;Depth;Structure;Users;Groups;Computers' | Out-File OU-Objects.txt
$OUs = Get-ADOrganizationalUnit -Filter * -Properties canonicalName | Sort-Object -Property canonicalName
foreach ($OU in $OUs) {
    $DN = $OU.distinguishedName
    $Name = $OU.name
    $Path = $OU.canonicalName
    $Depth = @([regex]::Matches($Path, "/")).count
    $Structure = ('   ' * ($Depth-1)) + $Name
    $Users = @(Get-ADUser -SearchBase "$DN" -SearchScope OneLevel -Filter *).count
    $Groups = @(Get-ADGroup -SearchBase "$DN" -SearchScope OneLevel -Filter *).count
    $Computers  = @(Get-ADComputer -SearchBase "$DN" -SearchScope OneLevel -Filter *).count
    "$DN;$Name;$Path;$Depth;$Structure;$Users;$Groups;$Computers" | Out-File OU-Objects.txt -Append
}

Hinweis: Das Skript erzeugt in großen Umgebungen u.U. eine hohe oder unerwartete Abfragelast: Es stellt pro OU drei recht umfassende Abfragen an Active Directory. Es kann daher sein, dass ein SIEM oder Monitoring-System verdächtige Aktivitäten meldet. Das Skript sollte in solchen Umgebungen nur in Abstimmung mit der Security-Administration ausgeführt werden. Gedacht ist es vor allem für überschaubare Domänen.