AdminSDHolder

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

  • Sie vergeben Rechte auf ein AD-Objekt und diese sind nach einigen Minuten wieder weg
    d.h. irgend etwas setzt alle Rechte auf einem Objekt wieder auf einen noch nicht bekannten Standard zurück
  • Sie aktivieren die Vererbung auf dem AD-Objekt und auch dies wird wieder rückgängig gemacht.
    Vielleicht haben Sie ja schon gesehen, dass Rechte auf das fragliche Objekt nicht vererbt wurden und sie wollten das korrigieren. Schade nur dass ihre Änderung nach einiger Zeit von irgendwas schon wieder rückgängig gemacht wurde.
  • Ein Benutzer mit Blackberry kann auch nach wiederholtem Eintragen eines "SendAs"-Rechts nicht arbeiten.
    Was auf den den ersten Punkt zurückführt: Etwas nimmt vergebene Rechte wieder weg
  • OWA2007/2010 kann nicht genutzt werden, da die "Spracheinstellung" nicht gesetzt werden kann.
    Nicht mal der Exchange Server hat die Rechte, bei einem Benutzer die OWA-Sprache in das entsprechende AD-Feld zu schreiben
  • Exchange 2010 "New-LocalMoveRequest" geht nicht mit "Client Permission"
    Bei der Migration bricht Exchange ab, da er angeblich keine Rechte auf das Postfach hat.
  • ActiveSync funktioniert nicht
    Alle anderen Benutzer können normal arbeiten nur dieser fragliche Benutzer kann kein Pushmail nutzen.
  • Mails an öffentliche Ordner von Administratoren
    Wenn ein Ordner "mailaktiviert" wird und ein Administrator dort was hin senden will, er aber auch in dem Ordner sich Rechte gegeben hat., dann kann es sein dass er einen "554 5.2.1 unzustellbar" bekommt. weil der Store den Absender "prüfen" möchte und er dazu keine Rechte hat. Normale Anwender können solche Ordner aber erreichen.
  • Und diverse andere Effekte
    Das ist nur eine kurze Liste die bei weitem nicht vollständig ist.

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:

  • Ein Helpdesk Mitarbeiter hat das Recht, Kennworte auf andere Benutzer zurück zu setzen.
  • Ein administrativer Benutzer mit Privilegien ist in einer dieser OUs angelegt

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

Das Active Directory "schützt" daher seine Adminkonten. Dieser Prozess läuft auf jeden DC per Default alle Stunde und kann er Registrierung angepasst werden.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"AdministratorenDProtectFrequency"=dword:00000e10

Der Wert wird in Sekunden angegeben und kann zwischen 60 und 7200 (2 Stunde) liegen.

  • 817433 Delegated permissions are not available and inheritance is automatically disabled
  • 232199 Description and Update of the Active Directory AdminSDHolder object
  • 318180 AdminSDHolder thread affects transitive members of distribution groups

Genau dieser Hintergrundthread sucht regelmäßig nach Objekten in administrativen Gruppen und führt dann vier Dinge aus:

  • Feld AdminCount  = 1
  • Deaktivierender Vererbung der Berechtigungen
  • Setzt die Rechte anhand des AdminSDHolder-Templates
    AdminSDHolder im AD
    Gerade dieser letzter Punkt ist für Exchange relevant, weil damit auch jedes "SendAs"-Recht immer wieder außer Kraft gesetzt wird. Bitte prüfen Sie genau, ob eine Änderung des Templates der richtige Weg ist.
  • Eintrag im Eventlog
    Zumindest bei Windows 2008R2 DCs haben ich folgenden Eintrag gefunden
Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Event ID:      4780
Task Category: user Account Management
Level:         Information
Keywords:      Audit Success
Computer:      dc1.msxfaq.de
Description:
The ACL was set on accounts which are members of administrators groups.
 
 
Subject:
      Security ID:        ANONYMOUS LOGON
      Account Name:       ANONYMOUS LOGON
      Account Domain:     NT AUTHORITY
      Logon ID:           0x3e6
 
Target Account:
      Security ID:        MSXFAQ\DC1 $
      Account Name:       DC1$
      Account Domain:     DC=msxfaq,DC=de
 
Additional Information:
      Privileges:         -
 
Every hour, the Windows domain controller that holds the primäry domain controller
 (PDC) Flexible Single Master Operation (FSMO) role compares the ACL on all security
 principal accounts (users, groups, and machine accounts) present für its domain in
 Active Directory and that are in administrative groups against the ACL on the
 AdminSDHolder object.  If the ACL on the principal account differs from the ACL
 on the AdminSDHolder object, then the ACL on the principal account is reset to
 match the ACL on the AdminSDHolder object and this event is generated.

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:

  • Enterprise Administratoren
  • Schema Administratoren
  • Domain Administratoren
  • Administrators
  • Account Operators
  • Server Operators
  • Print Operators
  • Backup Operators
  • Cert Publishers

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

  • Administrator
    Der Default Administrator
  • krbtgt
    Kerberos Account

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.

Der Schutz durch AdminCount ist wichtig, da z.B. Exchange 2010 der Gruppe "Organization Management" umfangreiche Berechtigungen vergibt, z.B. Um die Mitglieder von Verteilern zu pflegen. Leider unterscheidet hier nicht zwischen Gruppen die für Exchange relevant und andere Gruppen. Nur dank AdminSDHolder kann sich also ein Exchange Administrator nicht zum Domänen Administrator aufschwingen.

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.

Hinweis:
Das Feld "AdminCount" ist nicht in den GC repliziert. Wer mehrere Domänen hat, muss also nacheinander alle Domains durchlaufen und absuchen.

Admin-Count Attribute http://msdn.microsoft.com/en-us/library/windows/desktop/ms675212(v=vs.85).aspx

Mit einer einfachen LDAP-Abfrage können Sie dies z.B. gegen den DC abfragen. Im GC ist das Attribut nicht vorhanden !

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

Export auf Bildschirm

dsquery * -filter "(admincount=1)"

Wer die PowerShell hat, kann sogar mit einem Einzeiler direkt die Information erhalten

# Suche der Adminaccounts in der aktuellen Domain
([adsisearcher]"(AdminCount=1)").findall()

Die Ausgabe 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.

Es könnte aber auch sein, dass einfach so die Vererbung abgeschaltet ist. Aber auch dann hilft ADFind ( http://www.joeware.net/freetools/tools/adfind/) weiter.

adfind -sc aclnoinherit -b "dc=msxfaq,dc=de"

Am Bildschirm werden dann alle Objekte ausgegeben, bei denen die Vererbung deaktiviert ist. Besonders perfide sind natürlich Gruppenmitgliedschaften, die man auf den ersten Blick auch mal übersehen kann.

Auf den ersten Blick fällt es nicht wirklich auf, dass es sich dabei um die lokale Administratoren-Gruppe der Domäne handelt, in der hier jemand irrtümlicherweise die Domänenbenutzer addiert hat.

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:

  • MMC für Benutzer
    In der erweiterten Ansicht gibt es mittlerweile einen Knopf zum Zurücksetzen
    Standards mit MMC zurücksetzen
  • ResetAccountsAdminSDHolder.vbs
    Microsoft hat im KB-Artikel "817433 Delegated permissions are not available and inheritance is automatically disabled" das Verhalten ebenfalls erklärt und ein VBScript veröffentlicht, um AdminSDHolder und Berechtigungen zurück zu setzen. Da KB-Artikel manchmal auch "verschwinden", habe ich mir das Skript hier als Download hingelegt

resetaccountsAdminSDHolder.vbs.txt

  • DSACLS
    Über das Kommandozeilenprogramm DSACLS können Sie ebenfalls die Standardrechte auf einzelne Objekte oder ganze OUs und Domains anwenden.

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.

AdminSDHolder und Exchange

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 Freeware-Tool 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 zu finden 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.

Auch im EWS unterliegen Administratoren weiteren Beschränkungen:

„The calling account cannot be a member of any administrator group.
This permission is explicitly denied to those groups“

Quelle: Configuring Exchange Impersonation (Exchange Web Services) http://msdn.microsoft.com/en-us/library/exchange/bb204095(v=exchg.80).aspx

Auch ActiveSync kann davon betroffen sein, Exchange den untercontainer nicht mehr anlegen kann

AdminSDHolder und Lync

Auch hier trifft ein AdminSDHolder bei der Migration auf Probleme z.B. beim Verschieben von Benutzern während der Migration von OCS nach Lync

Auch das "neu Aktivieren" von Benutzer geht nicht

Die Lync Dienste haben für Administratoren einfach zu wenig Berechtigungen. Auch hierhilft wieder nur die Aussage:

Administrative Benutzer sind keine Regelarbeitskonten mit Postfach, SIP-Adresse o.ä. sondern eben nur für die Administration vorgesehen.

Weitere Links

  • Adminkonzept
  • AG-Rechte
  • Senden als
  • RBAC
    So wird gesteuert, wer was administrieren kann
  • AdminSDHolder - or where did my permissions go?
    http://msmvps.com/blogs/ulfbsimonweidner/archive/2005/05/29/49659.aspx
  • Exchange 2010 and Resolution of the AdminSDHolder Elevation Issue
    http://blogs.technet.com/b/exchange/archive/2009/09/23/3408362.aspx
  • Adding Domain or Enterprise Administratoren to Lync Server 2010
    http://blog.unplugthepbx.com/2010/09/14/adding-domain-or-enterprise-Administratoren-to-lync-server-2010/
  • 232199 Description and Update of the Active Directory AdminSDHolder object
  • 817433 Delegated permissions are not available and inheritance is automatically disabled
  • 281146 How to use Dsacls.exe in Windows Server 2003 and Windows 2000
  • 301188 Security tab of the AdminSDHolder object does not display all properties
  • 318180 AdminSDHolder Thread Affects Transitive Members of Distribution Groups
  • 555433 Troubleshooting Event ID 9554 using ADFind utility
  • 817433 Delegated permissions are not available and inheritance is automatically disabled
    VB-Skript um alle Objekte mit Admincount=1 wieder auf 0 zu setzen und die Vererbung zu aktivieren
  • 907434 The "Send As" right is removed from a user object after you configure the "Send As" right in the Active Directory users and Computers snap-in in Exchange Server
  • 912918 users cannot send e-mail messages from a mobile device or from a shared mailbox in Exchange 2000 Server and in Exchange Server 2003
  • Function: Set-AdminUser – Clear AdminCount and Enable Security Inheritance
    http://www.ehloworld.com/1621