AdminSDHolder

Wenn ich Sie auf diese Seite geleitet habe, dann dürften Sie eines der folgenden Probleme habe:

Spätestens jetzt sollten Sie wissen wollen, was ihnen da immer wieder in ihr Handwerk pfuscht, wo sie doch in bester Absicht als Administrator alles richtig machen wollen. Das Problem ist aber hier nicht Windows, sondern das Problem sind Sie und ist darin begründet, dass Windows seine privilegierten Benutzer schützt. Doch eins nach dem anderen.

Windows schützt seine Administratoren

In einem Active Directory gibt es Administratoren und normale Benutzer. Und es gibt besondere Gruppen, über die ein Benutzer mehr Berechtigungen erhalten kann (wie z.B. Kontenoperatoren). Bei einer ungeschickten Konfiguration könnte dies zu einer Sicherheitslücke führen: Beispiel:

Nun könnte der Helpdesk Mitarbeiter ja das Kennwort des administrativen Kontos zurücksetzen, sich damit anmelden und Schaden anrichten. Genau das gilt es zu verhindern.

AdminSDHolder Thread

Daher gibt es einen Hintergrundprozess, welcher einmal pro Stunde auf dem PDC-Emulator gestartet wird, um eben solche administrativen Konten zu ermitteln und dann drei Dinge durchzuführen:

Also stellt sich die Frage, welche Gruppen denn als "schützenswert" zählen.

Geschützte Gruppen

Windows schützt die eingebauten administrativen Gruppen gegen zu viele Berechtigungen. Dazu sind im Active Directory so genannte Standardrechte hinterlegt die auf gekennzeichnete Objekte immer wieder angewendet werden. Die sind z.B. die Gruppen:

Zusätzlich sind auch noch folgende Benutzer besonders geschützt:

Der Schutz bezieht sich aber nicht nur auf die Gruppen selbst, sondern auch auf die Konten, die Mitglieder dieser Gruppen sind. Dabei wirken sich sogar indirekte Mitgliedschaften über andere Gruppen hinweg aus und auch die Mitgliedschaft über Verteiler aus, also Gruppen ohne SID. Das ist zu beachten, da das Tool "WHOAMI" solche Verteiler nicht mit berücksichtigt.

Betroffene Konten finden

Welche Objekte nun durch diese Funktion "geschützt" sind, können Sie zum einen einfach dadurch prüfen, in welchen der genannten Gruppen diese Mitglied sind. Auf der anderen Seite führt Windows selbst das Feld "adminCount" bei den Objekten mit. Wenn der Wert <>0 ist, dann ist das Objekt unter Beobachtung und Kontrolle. Mit einer einfachen LDAP-Abfrage können Sie dies z.B. gegen den DC abfragen. Im GC ist das Attribut nicht vorhanden !

ldifde -d "dc=msxfaq,dc=de" -r "(admincount=*)" -f admincount.txt -l "dn,admincount"

Die Ausgabedatei enthält dann alle Objekte mit ihrem AdminCount. Eine Abfrage mit Softerra LDAP oder LDP funktionieren genauso. Selbst mit der normalen MMC für Benutzer und Computer können Sie eine passende benutzerdefinierte Suche ausführen:

LDAP-Suche nach AdminCount

Bei Exchange 2007 kann auch ein Eventlogeintrag hilfreich sein. Wenn ein Benutzer erstmals ein Postfach bekommt, dann versucht Exchange die Mailbox Security Descriptoren zu setzen. Das funktioniert natürlich auch nicht, wenn der Benutzer keine vererbten Berechtigungen hat. Im Eventlog findet sich dann:

Ereignistyp: Warnung
Ereignisquelle: MSExchangeIS
Ereigniskategorie: Allgemein
Ereignis-ID: 9554
Datum: 12.09.2008
Zeit: 19:22:44
Benutzer: Nicht zutreffend
Computer: SRV01
Beschreibung:
Die Postfach-SD in der DS konnte nicht aktualisiert werden. Postfach-Guid:
12345678-1234-1234-1234-123456789abd. Fehlercode 0x80070005

Administratoren sollten kein Postfach haben oder Benutzer mit Postfach sollten nie auch Administrator sein.

AdminCount und Default Rechte zurücksetzen

Das Problem ist natürlich auch Microsoft nicht unbemerkt geblieben, dass Administratoren auch "normale Anwender" in vielleicht nur temporär administrative Gruppen addieren und die Folgen nicht bedenken. Um solche einen Irrtum rückgängig zu machen, reicht es leider nicht, den Benutzer wieder aus der Gruppe zu entfernen, denn die Änderungen werden dabei nicht rückgängig gemacht. Das Entfernen aus einer Admingruppe ist aber der Anfang der "Reparatur".

Microsoft selbst hat ein VBScript (resetaccountsadminsdholder.vbs im KB Artikel 817433 Delegated permissions are not available and inheritance is automatically disabled) veröffentlicht, um alle Objekte mit "admincount=1" zu finden und sowohl die Vererbung wieder zu aktivieren als auch den Admincount auf 0 zu setzen. Es ist ziemlich ungefährlich, dieses Skript zu aktivieren, da der Hintergrundprozess entsprechende Administratoren schnell wieder schützt. Sie können also das Skript starten und einen Stunde später wieder nach dem Admincount suchen, um verbliebene Administratoren zu finden.

Allerdings setzt dieses Skript nicht die Standardrechte zurück. Dies ist aber auf zwei Wege möglich:

resetaccountsadminsdholder.vbs.txt

Achtung:
Prüfen Sie genau, ob Sie nicht absichtlich auf bestimmten Objekten zusätzliche Berechtigungen vergeben haben. So gibt man oft einem Clusterdienstkonto das Recht, den ServicePrincipalName (Siehe Kerberos) zu setzen.
DSACLS ersetzt auch Rechte auf OUs, d.h. eventuell zur Delegierung von administrativ vergebene Berechtigungen werden ebenfalls entfernt.
Verschiedene Programme (z.B. OCS) vergeben auch Berechtigungen an Dienstkonten

Daher sollten Sie DSACLS nie auf der kompletten Domäne ausführen, sondern immer nur auf ausgewählte Objekte.

Dsacls <dn> /S /T

Als DN kann entweder direkt ein Objekt oder auch eine OU angegeben werden. Ohne Angabe einer OU werden alle Objekte in der aktuellen Domäne wieder auf die "Standardwerte" zurückgesetzt. Details hierzu finden Sie auch auf "281146 How to Use Dsacls.exe in Windows Server 2003 and Windows 2000". Leider kann man nicht mit DSQUERY eine Liste der User per STDIN /STDOUT an DSACLS zu senden.

Windows Even 9554

Wenn ein Benutzer z.B. die Vererbung als administratives Konto deaktiviert hat, kommt auch Exchange nicht mehr an das Postfach heran. Das zeigt sich z.B. in einem Eventlogeintrag wie diesem:

Nun müssen Sie natürlich erst mal das Postfach mit der GUID finden. So einfach ist das nicht, da die Schreibweise hier nicht dem Feldinhalt im AD entspricht. Aber auch hier gib es Hilfe durch das Freewaretool ADFIND (http://www.joeware.net/win/free/tools/adfind.htm), welches mit dem passenden Aufruf auch die GUID in der Schreibweise aus dem Eventlog nimmt und nach dem passenden Objekt sucht

adfind -gc -b "" -binenc -f " msExchMailboxGUID={{GUID: 68821c31-2938-4179-8a6b-96019c1e348c}}" -dn

Bei Exchange 200772010 kann auch die Powershell helfen:

Get-Mailbox | fl name,guid > guid.txt

In der Textdatei können Sie dann auch versuchen die GUID z ufinden

Allerdings ist es mir auch schon passiert, dass ein Objekt nicht gefunden wurde. Ich tippe dann mal auf eine Mailbox, die z.B. "Disconnected" ist oder von einer Migration als Rest zurück geblieben ist und es daher im Active Directory kein entsprechendes Objekt mehr gibt.

Weitere Links

Keywords: Admin AdminCount AdminSDHolder