MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

AD Confidential Attribute

Wussten Sie, dass ein "Domain Benutzer" auf ihrem Active Directory sehr viele Rechte hat und alle Eigenschaften aller Objekte lesen kann?. Die Werkzeuge dazu sind auf jedem Windows Client vorinstalliert oder einfach zu erhalten, um so eine CSV-Datei zu exportieren. Sicher können Sie die Vererbung von Berechtigungen auf OUs unterbrechen mit einem DENY verbieten, um Bereiche zu schützen aber das ist weder elegant noch für die Mehrheit praktikabel. Mit "Confidential Attributes" können Sie aber Felder im Active Directory Schema definieren, die nicht unter "Alle Eigenschaften lesen" fallen.

Default Rechte und Beschränkungen

Wenn Sie ein Active Directory einrichten, dann legt Microsoft in der Domain automatische einige Benutzer und Gruppen samt Berechtigungen an. Diese Standardberechtigungen sind im nicht per Definition unsicher, denn es gibt als Benutzer nur "Administrator" und weitere Benutzer werden eben vom Administrator erst angelegt. Microsoft legt auch mehrere Berechtigungsgruppen (Administratoren. Drucker-Operatoren Schema-Administratoren etc.) an, die nur den Administrator enthalten. Sobald Sie aber den ersten "Benutzer" anlegen, ist auch dieses Anmeldekonto in der Gruppe "DomainUser" und hat für die Funktion erforderliche Berechtigungen. Hier habe ich die "effektiven Berechtigungen" eines Kontos "ADUser1" in einem Active Directory ermittelt:

Das ist nur die Domäne selbst und wenn Sie sich die ACL der Domäne anschauen, dann finden Sie einen Eintrag, der "Authentifizierte Benutzer" quasi alle lesen lässt.

Sie können es einfach ausprobieren, indem Sie als Benutzer einfach einen der folgenden Befehle auf einem Windows-Client ausführen

CSVDE.EXE /f domain.csv
LDIFDE.EXE /f domain.ldf
GET-ADObject -filter * | export-CliXML domain.xml

Gerade LDIFIDE liefert schon sehr umfangreiche Daten über Gruppen und Mitgliedschaften, Dienstkonten, LastLogonTime etc. und sie haben eigentlich kaum eine Möglichkeit diese Abfragen zu verhindern. Das ist zum Teil auch der langen Historie von Windows geschuldet, dass damals die Sicherheit noch keinen allzu hohen Stellenwert hatte. Aber auch heute können und sollten Sie ihr Active Directory natürlich absichern und z.B. verhindern, dass Anwender selbst bis zu 10 Computerkonten anlegen können u.a.

Sie könnten auch anfangen, auf OUs die Vererbung von Berechtigungen der Domain zu unterbrechen und eigene Berechtigungen zu vergeben oder mit "DENY" den Zugriff auf Teilbereiche zu untersagen. Das können Sie tun aber testen und prüfen Sie die Funktion der davon abhängigen Programme und sperren Sie sich insbesondere als Administrator nicht unabsichtlich aus. Für kritische Dinge kann auch eine eigene Domain oder sogar separater Forest mit selektiven Trusts ein Thema sein.

Sie können gerne meine Kollegen oder mich ansprechen, wenn Sie hierzu weitere Informationen benötigen. Net at Work und MSXFAQ

Confidential Attribute

Seit Windows 2003 SP1 gibt es aber eine neue Variante, ausgewählte Informationen der Allgemeinheit zu verbergen und damit auch bei Export mit LDIFDE/CSVDE gar nicht mehr auszuliefern. Diese Funktion ist auf individuellen Attributen konfigurierbar, indem diese als "Confidential" klassifiziert werden. Das ist im Schema ein eigenes Bit in einem Attribut und funktioniert am besten mit einer eigenen AD Schema Erweiterung.

Bitte ändern Sie nicht die Einstellungen der von Microsoft vorgegebenen Schema-Attributen

Insofern ist es auch nicht ratsam, eines der bestehenden Felder über die Funktion "Confidential Attribute" zu verbergen. Alle als "Confidential" gekennzeichneten Attribute sind nur für folgende Identitäten lesbar:

  • Administratoren
    Hier brauchen Sie keine weiteren Berechtigungen vergeben.
  • Mitglieder der Gruppe "Prä-Windows 2000 kompatibler Zugriff"
    Diese spezielle Gruppe ist eigentlich leer und sollte nur für Systeme genutzt werden die noch NT4-Domain-Daten abfragen. Eigentlich ist diese Gruppe leer.
  • Explizit gewährte Berechtigungen
    Wenn Sie einem Benutzer oder einer Gruppe explizit die Rechte auf das entsprechende Feld geben, dann werden die Daten auch geliefert.

Ein solches "Confidential Attribut" ist damit der ideale Platz, um zusätzliche Informationen an AD-Objekten zu speichern, die aber ohne besondere Berechtigungen von niemandem mit den Standard-Berechtigungen gesehen werden. Allerdings funktioniert das am besten mit eigenen Attributen, die Sie im Rahmen einer AD Schema Erweiterung natürlich einrichten müssen. Das ist aber nicht besonders schwer. Früher wurde davon oft abgeraten und man müsste erst eine eindeutige OID bei einer Organisation beantragen.

Confidential-Status sehen und ändern

Ob ein Attribut als "Confidential" behandelt wird, ist im Schema ihres Active Directory Forest in dem Feld "Search-Flags" definiert.


Quelle: Search-Flags attribute https://learn.Microsoft.com/en-us/windows/win32/adschema/a-searchflags

Damit dürfen per Default nur noch Objekte diese Feld sehen und lesen, die das Recht "CONTROL_ACCESS" haben. Das sind in der Standardeinstellung nur Administratoren.

By default, only administrators have CONTROL_ACCESS permissions to all objects. Therefore, only Administrators can read confidential attributes. Administrators may delegate these permissions to any user or to any group.
Quelle: https://learn.Microsoft.com/en-us/troubleshoot/windows-server/windows-security/mark-attribute-as-confidential#generic-and-object-specific-access-control-entries 

Microsoft macht das mit eigenen Feldern vor, z.B.:

  • PasswordHash
    Bei Benutzern und Computern speichert Microsoft den Hashwert des Kennworts. Das sollten natürlich nicht alle Anwender einfach auslesen und gegen Rainbow-Tables prüfen können
  • TPM
    Auch die Sicherheitsinformationen eines TPM-Chips, z.B. die PIN kann im Active Directory an einem Computer hinterlegt werden und sollte nur ausgewählten Administratoren zugänglich sein.
  • LAPS
    Durch LAPS können sie das Kennwort des lokalen Administrators regelmäßig ändern und im Active Directory speichern. Diese Information sollte auch nicht in fremde Hände fallen.

"Password is protected in AD by AD ACL, so granular security model can be easily implemented"
Quelle: https://docs.Microsoft.com/en-us/previous-versions/mt227395(v=msdn.10)

Die Steuerung über das SearchFlag sehen wie bei vielen Feldern, z.B. in der Schema-Erweiterung für LAPS 

Name: ms-LAPS-Password
LDAP display name: msLAPS-Password
OID: 1.2.840.113556.1.6.44.1.2
Syntax: 2.5.5.5
OmSyntax: 19
IsSingleValued: True
IsMemberOfPartialAttributeSet: False
SearchFlags: 904
AttributeSecurityGuid: <not set>

Das SearchFlags:904 enthält 128, womit erst einmal nur "Domain Admins" diese Felder lesen dürfen. Viel einfacher geht es aber auch direkt per ADSIEDIT:

Hier können Sie direkt den Wert setzen

Berechtigungen auf Confidential Attribute

Durch "Searchflag=128" sehen nur noch Administratoren und explizit berechtigte Personen die Attribute. Wenn nun Dienstkonten oder Gruppen von Benutzern das geschützte Attribut lesen oder schreiben wollen, gibt es zwei Optionen:

  • Default ACL im Schema ändern
    Sie können an einem Attribut im Schema die Rechte ändern. Ich beschreibe da im nächsten Abschnitt aber rate davon ab
  • ACLs auf Domain und OUs
    Der bessere Weg ist die Vergabe der Rechte auf der Domain oder sogar nur OU, was viel selektiver ist und Änderungen nicht im Schema erfolgen müssen.

Um die Rechte zu ändern, können sie die Kommandozeile DSACLS oder die GUI "LDP.EXE" nutzen. Die Änderungen sind nicht per ADSIEDIT oder "AD Users&Computer" möglich. Die Schritte per LDP sind schnell erklärt

  • LDP.EXE Starten
    Dazu müssen Sie auf einem Windows Client sein, der die AD Management Tools hat
  • LDP: Verbinden zum DC und Anmelden
    Dann stellen Sie zuerst die LDAP-Verbindung zu einem Domaincontroller her und melden sich mit einem privilegierten Konto an
  • LDP: Anzeige des "Tree"
    Dann lassen Sie sich den Baum anzeigen und wechseln auf die OU, auf der sie das Recht delegieren wollen
  • LDP: Rechte Maustaste - Erweitert - SecurityAttribute
    Sie sehen dann die aktuellen Berechtigungen
  • LDP: Berechtigungen addieren
    Rechts gibt es den "Hinzufügen"-Button, mit dem sie idealerweise einer AD-Gruppe addieren und z.B. das Recht "Read" oder !Write" geben. Vergessen Sie unten nicht das "Inherit", damit das Rechte auch auf Objekte in der Domain/OU gelten.

Die Einstellungen können Sie auch mit ADSIEDIT vornehmen. Achten Sie darauf, dass Sie hier den Objekttyp auswählen, damit sie zumindest die üblichen Attribute finden: 


ADSIEDIT: ACL-Details für eine OU

Allerdings habe ich noch nicht ermitteln können, warum hier nicht alle meine eigens addierte Felder aufgeführt werden. Daher nutze ich immer noch die alten Kommandozeilentools DSACLS. Der Aufruf ist einfach

REM DSCACLS zur Vergabe von Berechtigungen an AD-Objekte und Attribute
REM
REM Aufruf:
REM
REM DACLS <cn des Zielobjects> /G <Name der Gruppe/User>:CA;<feldname> /I:S
REM
REM
REM Befehkl um auf der Domain einer Gruppe SUG-ACL-MSXFAQFelder das Lese-Recht inkl Unter-OUs zu geben.

DSACLS DC=msxfaq,DC=de /G MSXFAQ\SUG-ACL-MSXFAQFelder:CA;MSXFAQ-MitarbeiterID3 /I:S

Wichtig:
Wenn Sie so ein privates Feld nutzen, um z.B. die Entra ID Connect Sync-Replikation zu filtern, dann müssen Sie dem DirSync-Konto die entsprechenden Berechtigungen zum Lesen geben. Ein Blick in den ConnectorSpace zeigt, ob das Feld gesehen wird.

Meine Empfehlung:
Sie werden ja keine hundert eigene Felder addieren. Legen Sie eine globale/universelle Sicherheitsgruppe an, welche die Berechtigungen auf das Feld und eine passende Beschreibung bekommt. So können Sie über die Mitgliedschaft in dieser Gruppe einfach steuern und sehen, wer diese Inhalte lesen darf.

Vergessen Sie nicht die Änderungen zu dokumentieren. Es ist sehr einfach solche Rechte zu setzen aber sehr aufwändig im Nachhinein diese wieder zu finden. Im Gegensatz zu Novell können Sie in Windows nicht auf eine Gruppe gehen und alle Stellen suchen, wo diese in ACLs verwendet wurde.

Confidential Attribute im Schema auflisten

Da wir nun wissen, dass das Feld "SearchFlags" der Schlüssel ist, können wir ja schnell ermitteln, welche Attribute im eigenen Forest als "Confidential" gekennzeichnet sind. Ich besorge mir mit "Get-ADRootDSE" den LDAP-Pfad zur Schema-Partition und suche alle Attribute Objekte. Leider kann "-Filter" kein "-band"-Operator auf "SearchFlags" anwenden, so dass ich nachgelagert filtere. Das ist aber bei ca. 4000 Attributen kein Problem.

Get-ADObject `
   -SearchBase ((Get-ADRootDSE).schemaNamingContext) `
   -Filter 'objectclass -eq "attributeSchema"' `
   -Properties searchFlags `
| where {$_.searchflags -band 128} `
| ft name

Bei meinem Windows 2022 Domain Controller finde ich folgende Felder.

"ms-Mcs-AdmPW"  ist z.B. mit LAPS - Local Admin Password Solution verbunden während "ms-FVE-RecoveryPassword" Das Bitlocker Wiederherstellungskennwort (Full Volume Encryption) eines Computers enthält. Auch die anderen Felder lassen sich einfach bei Microsoft ausfindig machen.

Confidential Attribute lesen und schreiben

Mit den entsprechenden Berechtigungen können Sie natürlich diese Attribute ganz normal per LDAP lesen und schreiben. Allerdings werden Sie bei vielen Commandlets mittels "-Properties" mitgeben müssen, dass Sie auch diese Felder beim Lesen zurückerhalten wollen. Ansonsten liefert der LDAP-Service nur eine gekürzte Liste der Standardfelder.

Get-ADUser -Properties SamAccountName,GeheimProperty | ft SamAccountName,GeheimProperty

Weitere Links