In Active Directory entscheiden Attribute darüber, wie Identitäten beschrieben, Berechtigungen abgeleitet und Richtlinien technisch durchgesetzt werden. Wer Benutzer-, Gruppen- oder Computerobjekte auswertet, stößt schnell auf widersprüchliche Bezeichnungen zwischen LDAP-Attributname, LDAP-Display-Name und den Feldern in Verwaltungstools. Gleichzeitig hängt die Aussagekraft vieler Abfragen davon ab, ob ein Attribut mehrwertig ist, welchen Syntax- und Datentyp es hat, ob es im Global Catalog verfügbar ist und wie es repliziert wird. In der Praxis führt fehlende Klarheit zu fehlerhaften Filtern, unvollständigen Inventarisierungen, unzuverlässigen Reports über Domänengrenzen hinweg oder zu unerwarteten Datenabflüssen, wenn sensible Attribute zu breit auslesbar sind. Leser benötigen daher eine belastbare Referenz, die AD-Attribute eindeutig identifizierbar macht, ihr Verhalten im Verzeichnisdienst erklärt und die sicherheitsrelevanten Implikationen so einordnet, dass Abfragen, Audits und Automatisierungen nachvollziehbar und überprüfbar bleiben.
Inhalt
- AD-Attributmodell im Schema: LDAP-Attributname, LDAP-Display-Name, OID, Syntax, Datentyp und Mehrwertigkeit
- Replikations- und Suchverhalten: GC-Partial Attribute Set, indexierte Attribute, RODC-Filterung und Auswirkungen auf LDAP-Filter
- Global Catalog und Partial Attribute Set (PAS): was repliziert wird und was nicht
- Indexierung, Ambiguous Name Resolution (ANR) und Filterkosten
- RODC: Password Replication Policy, Attributvertraulichkeit und „Filtered Attribute Set“
- Konkrete Auswirkungen auf LDAP-Filter und Attributauswahl (Return Attributes)
- Sicherheitsrelevanz und Auswertung: Zugriffsrechte auf Attribute, sensible Felder, Objektzuordnungen (User/Group/Computer) sowie PowerShell- und LDAP-Query-Beispiele
- Zugriffsrechte auf Attribute: Lese-/Schreibpfade, vertrauliche Attribute und effektive Berechtigungen
- Objektzuordnungen (User/Group/Computer): sicherheitsrelevante Beziehungen und typische Abbildungspfade
- PowerShell-Auswertung: gezielte Attribut-Reads, Rechteindikatoren und Anomaliesuche
- LDAP-Query-Beispiele: präzise Filter, OID-Matching-Rules und GC/Replications-Fallstricke
AD-Attributmodell im Schema: LDAP-Attributname, LDAP-Display-Name, OID, Syntax, Datentyp und Mehrwertigkeit
Active Directory beschreibt Attribute im Schema als Instanzen der Klasse attributeSchema. Jedes Attribut besitzt dabei mindestens zwei „Namen“ mit unterschiedlichen Zielsetzungen: den LDAP-Attributnamen (historisch, häufig in RFC- oder X.500-Kontexten geführt) und den LDAP-Display-Name (kanonischer Bezeichner für LDAP-Operationen, Filter und die meisten Verwaltungswerkzeuge). OID, Syntax und Datentyp definieren, wie Werte gespeichert, verglichen und indiziert werden können; die Mehrwertigkeit steuert, ob ein Attribut 0..n Werte aufnehmen darf und ob Reihenfolgen semantisch relevant sind.
In der Praxis entscheidet der LDAP-Display-Name über die Schreibweise in Suchfiltern und in Abfragen, während OID und Syntax die technische Kompatibilität bestimmen. Eine Schemaänderung an diesen fundamentalen Eigenschaften ist typischerweise nicht vorgesehen; deshalb lohnt die saubere Einordnung bereits beim Lesen des Schemas, etwa über Get-ADObject gegen den Schema-Naming-Context.
Feldnamen im Schema: LDAP-Attributname vs. LDAP-Display-Name
Der LDAP-Display-Name (Schemafeld lDAPDisplayName) ist der operative Schlüssel für LDAP: Er erscheint in Filtern, in AttributesToLoad sowie in vielen PowerShell-Ausgaben. Der LDAP-Attributname (Schemafeld ldapDisplayName existiert nicht; gemeint ist in der Regel der X.500-/LDAP-Name bzw. das Attribut attributeID als OID) wird häufig in Dokumentationen und Standardbezügen geführt, ist aber nicht zwingend identisch mit dem Display-Namen. Zusätzlich existiert das Schemafeld cn als „Common Name“ des Schemaobjekts, das zwar menschenlesbar ist, aber nicht als Attributschlüssel in LDAP-Abfragen dient.
Für die eindeutige Identität eines Attributs ist die OID maßgeblich (Schemafeld attributeID). Sie bleibt stabil, auch wenn Anzeigenamen oder Beschreibungen variieren. Bei der Fehlersuche (z. B. nach uneinheitlichen Schemas in Multi-Forest-Umgebungen) ist die OID daher das robustere Vergleichsmerkmal als reine Namen.
| Schemaeigenschaft | Bedeutung | Typische Nutzung |
|---|---|---|
lDAPDisplayName |
Kanonischer Attributschlüssel für LDAP | Filter wie (sAMAccountName=...), Attributlisten, PowerShell-Propertynamen |
attributeID (OID) |
Weltweit eindeutige Kennung des Attributs | Schemaabgleich, Referenzen in Standards, Identitätsprüfung bei Konflikten |
attributeSyntax / oMSyntax |
LDAP-Syntax und AD-interne Syntaxklassifizierung | Validierung, Vergleichsregeln, Speicher- und Indexverhalten |
isSingleValued |
Einwertig vs. mehrwertig | Clientlogik, Änderungsoperationen (replace vs. add/delete) |
OID und Identität: Was eine Attributdefinition eindeutig macht
Die OID in attributeID ist der eindeutige Primärschlüssel des Attributes. In Active Directory gilt: Namen können kollidieren oder im Zeitverlauf wechseln, OIDs nicht. Bei der Integration von Schemaerweiterungen (z. B. Applikationsschemas) entscheidet die OID darüber, ob ein Attribut als identisch, kompatibel oder konfliktär bewertet wird. In der Schema-Partition werden Attributobjekte wie andere AD-Objekte repliziert; eine fehlerhafte oder doppelt verwendete OID erzeugt entsprechend nachhaltige Inkonsistenzen.
OID-Zuordnungen werden außerdem von Vergleichsregeln beeinflusst: Die Syntax bestimmt, ob ein Attribut als String, Integer, Boolean, DN oder Binärwert behandelt wird und welche Matching Rules (Gleichheit, Ordnung, Substring) semantisch zulässig sind. Das erklärt, weshalb sich etwa objectGUID (binär) und objectSid (binär) in Filtern und Ausgaben anders verhalten als Textattribute wie displayName.
Syntax, Datentyp und Matching Rules: Auswirkungen auf Suche und Speicherung
Im Schema werden Syntaxeigenschaften über attributeSyntax (LDAP-Syntax-OID) und oMSyntax (numerische AD-Klassifizierung) beschrieben. Zusammen definieren sie den Speicher- und Vergleichstyp. Ein Unicode-String verhält sich in Substringfiltern anders als ein DN; Integerwerte unterstützen Ordnung und Bereichsabfragen; Bitmasks wie userAccountControl sind Integer, werden aber typischerweise mit dem LDAP-Matching-Rule-OID 1.2.840.113556.1.4.803 (bitwise AND) gefiltert.
Besonders relevant ist die Unterscheidung zwischen DN-basierten Attributen (z. B. member, managedBy) und reinen Identifikatoren (z. B. objectGUID, mS-DS-ConsistencyGuid). DN-Werte sind pfadabhängig und können sich bei Umbenennungen ändern; GUIDs bleiben stabil und eignen sich für robuste Korrelationen, erfordern aber häufig binäre Filterdarstellungen.
- Unicode-String (Text): Substring- und Präfixsuche ist grundsätzlich möglich, Filterform wie
(displayName=Meier*); Sortierung und Vergleich folgen der zugewiesenen Matching Rule. - Integer/Enum/Bitmask: Gleichheit wie
(sAMAccountType=805306368)sowie bitweise Filter über(userAccountControl:1.2.840.113556.1.4.803:=2)für gesetzte Flags. - Distinguished Name (DN): Werte verweisen auf Objekte, Filter typischerweise
(managedBy=CN=...,OU=...,DC=...); Umbenennungen wirken auf DN-Werte, nicht auf GUIDs. - Octet String (binär): Ausgabe in Tools oft als Bytearray; Filter benötigen korrekte Darstellung, z. B. für
objectGUIDje nach Clientbibliothek in escaped Hex-Notation.
Mehrwertigkeit: isSingleValued, Reihenfolge, Teiländerungen
Die Schemaeigenschaft isSingleValued trennt einwertige Attribute (z. B. mail) von mehrwertigen Attributen (z. B. proxyAddresses, memberOf als konstruiertes Attribut). Bei mehrwertigen Attributen ist entscheidend, ob Clients Teiländerungen ausführen dürfen und wie das Verzeichnis Werte intern behandelt. LDAP-Modifikationsoperationen unterscheiden zwischen add, delete und replace; bei Mehrwertigkeit ist replace oft riskant, weil es die gesamte Wertmenge überschreibt.
Active Directory speichert mehrwertige Attribute nicht als „Liste mit garantierter Reihenfolge“ im Sinne typischer Anwendungsdatenstrukturen. Einige Attribute tragen zwar eine semantische Sortierung (z. B. bestimmte Link-Backlinks oder systemgenerierte Mehrwerte), für benutzerdefinierte Auswertungen sollte jedoch nicht auf eine feste Reihenfolge vertraut werden. Für Abfragen sind außerdem Indizierung und Matching Rules wichtiger als Mehrwertigkeit: Ein mehrwertiges, indiziertes Attribut lässt sich performant filtern, ein unindiziertes kann trotz geringer Wertmenge teuer werden.
| Beispiel (LDAP-Display-Name) | Mehrwertig | Datentyp/Syntax (konzeptionell) | Typische Besonderheit |
|---|---|---|---|
proxyAddresses |
Ja | Unicode-String | Wertpräfixe wie SMTP: bzw. smtp: kodieren Primär-/Sekundäradresse in der Applikationslogik |
member |
Ja | DN (verlinktes Attribut) | Link-Value; Gegenstück als Backlink memberOf wird berechnet und nicht direkt geschrieben |
userPrincipalName |
Nein | Unicode-String | Login-Identität; Vergleichsregeln beeinflussen Normalisierung und Eindeutigkeit |
objectGUID |
Nein | Octet String | Stabile Objektidentität, aber Filterdarstellung ist clientabhängig und fehleranfällig |
Replikations- und Suchverhalten: GC-Partial Attribute Set, indexierte Attribute, RODC-Filterung und Auswirkungen auf LDAP-Filter
Global Catalog und Partial Attribute Set (PAS): was repliziert wird und was nicht
Der Global Catalog (GC) hält eine partielle, domänenübergreifende Sicht auf Objekte im Forest. Für Suchvorgänge über mehrere Domänen entscheidet das Partial Attribute Set (PAS), welche Attribute zusätzlich zu einer kleinen Menge basisreplizierter Felder in den GC repliziert werden. Attribute im PAS stehen damit für forestweite Abfragen auf Port 3268 (LDAP) bzw. 3269 (LDAPS) zur Verfügung; alle übrigen Attribute bleiben domänenspezifisch und erfordern Abfragen gegen einen DC der jeweiligen Domäne (typisch 389/636) oder eine nachgelagerte Auflösung via distinguishedName.
Die PAS-Zugehörigkeit wird im Schema über das Flag isMemberOfPartialAttributeSet am Attribut definiert. Änderungen an dieser Eigenschaft sind Schemaänderungen: Sie replizieren forestweit, können Auswirkungen auf Replikationsvolumen und GC-Datenbankgröße haben und beeinflussen messbar die Antwortzeiten von Suchvorgängen, die viele Attribute zurückliefern. In der Praxis entsteht häufig ein Missverständnis: Ein Objekt kann über den GC gefunden werden, obwohl ein für die Auswertung relevantes Attribut nicht im GC liegt. Dann liefert der GC Treffer, aber nicht die erwarteten Attributwerte, was sich in leeren Attributlisten oder zusätzlichen Nachfragen an domänenspezifische DCs äußert.
| Suchziel / Abfragepfad | Typische Folge | Technische Konsequenz |
|---|---|---|
Forestweite Suche gegen GC (3268/3269) |
Attribute außerhalb PAS fehlen in den Ergebnissen | Für Detailattribute zweiten Query gegen Domänen-DC durchführen oder gezielt nur PAS-Attribute anfordern |
Domänenspezifische Suche gegen DC (389/636) |
Vollständiger Attributsatz verfügbar (sofern leseberechtigt) | Bei Multi-Domain-Szenarien ggf. pro Domäne suchen oder DN-Resolution nutzen |
| GC-Suche mit großem Attribut-Returnset | Mehr Last auf GC, größere Antwortpakete | Nur benötigte Attribute anfordern, serverseitig filtern, Paging verwenden |
Indexierung, Ambiguous Name Resolution (ANR) und Filterkosten
Die Suchperformance hängt stark davon ab, ob der Directory-Server einen Index nutzen kann. Viele häufig verwendete Attribute sind indiziert; andere führen bei unselektiven Filtern zu teuren Scans. Indexierung ist dabei nicht gleichbedeutend mit GC-Verfügbarkeit: Ein Attribut kann domänenspezifisch indiziert sein, aber nicht im PAS liegen, oder im PAS liegen, ohne eine sinnvolle Indexstrategie für den jeweiligen Filtertyp zu bieten. Außerdem unterscheiden sich Equality-, Substring- und Range-Filter erheblich in ihrer Ausführungscharakteristik.
ANR (Ambiguous Name Resolution) nutzt das Konstrukt (anr=...) und mappt serverseitig auf eine definierte Attributmenge (unter anderem Namensfelder). ANR ist komfortabel, aber in komplexen Umgebungen schwerer vorherzusagen, insbesondere hinsichtlich Trefferqualität und Last. Für präzise Auswertungen bleiben explizite Filter auf klar definierte Attribute in der Regel besser kontrollierbar.
- GC-Abfrage, attributbewusst:
(&(objectCategory=person)(objectClass=user)(|(userPrincipalName=*)(mail=*))) - ANR für Namenssuche (breit, weniger deterministisch):
(&(objectCategory=person)(objectClass=user)(anr=Mustermann)) - Selektiver Equality-Filter auf Login-Attribut:
(&(objectClass=user)(sAMAccountName=jmustermann)) - Substrings gezielt einsetzen (potenziell teuer):
(&(objectClass=user)(mail=*@example.com))
Bei Substring-Filtern entscheidet die Kombination aus Indexierung, Tokenisierung und Datenverteilung über die tatsächlichen Kosten; pauschale Aussagen sind unzuverlässig. Praktisch relevant bleibt: Filter sollten möglichst früh einschränken (z. B. über objectCategory und objectClass) und nur dann Wildcards nutzen, wenn sie fachlich notwendig sind.
RODC: Password Replication Policy, Attributvertraulichkeit und „Filtered Attribute Set“
Read-Only Domain Controller (RODC) verändern das Replikations- und Sicherheitsmodell durch schreibgeschützte Datenhaltung und eine restriktive Passwortreplikation (Password Replication Policy, PRP). Für LDAP-Abfragen ist zusätzlich relevant, dass bestimmte als vertraulich markierte Attribute nicht zu einem RODC repliziert werden. Dieses Verhalten wird über die Eigenschaft searchFlags im Schema gesteuert; das sogenannte „Filtered Attribute Set“ umfasst Attribute, die auf RODCs nicht vorhanden sind, um eine Exfiltration sensibler Werte in Außenstellen zu erschweren.
Für Such- und Auswertelogik ergeben sich daraus zwei typische Fehlerbilder: Erstens liefern Abfragen gegen einen RODC leere Werte, obwohl das Attribut auf einem beschreibbaren DC gesetzt ist. Zweitens schlagen Filter fehl, wenn sie auf einem Attribut basieren, das auf dem RODC nicht repliziert wird; der Filter kann dann keine Treffer bilden, obwohl sie im Verzeichnis existieren. In sicherheitsrelevanten Auswertungen empfiehlt sich daher, für sensitive Attribute gezielt gegen beschreibbare DCs zu suchen und das Zielsystem (RODC vs. DC) explizit zu kontrollieren.
- Schema-Flag für vertrauliche Attribute (Konzept):
searchFlagsmit gesetztem „confidential“-Bit bewirkt Ausschluss aus RODC-Replikation (Filtered Attribute Set) - Abfrageziel erzwingen (PowerShell):
Get-ADUser -Server dc01.corp.example -LDAPFilter "(sAMAccountName=jmustermann)" -Properties * - RODC-spezifische Fehlersuche:
Get-ADDomainController -Filter "IsReadOnly -eq $true" | Select-Object HostName,Site,IsGlobalCatalog
Konkrete Auswirkungen auf LDAP-Filter und Attributauswahl (Return Attributes)
Filterlogik und Attributrückgabe sollten getrennt geplant werden. Ein Filter kann ausschließlich mit Attributen arbeiten, die auf dem Zielserver vorhanden und durchsuchbar sind; die Attributrückgabe (attributesToLoad in vielen LDAP-Clients) entscheidet unabhängig davon, welche Werte zurückgeliefert werden. Besonders im GC-Kontext ist es üblich, den Filter forestweit auszuführen, aber nur PAS-Attribute zurückzugeben und anschließend gezielt „nachzuschlagen“, sobald ein Objektkandidat feststeht.
Ein bewährtes Muster ist die zweistufige Auflösung: Zuerst eine GC-Abfrage zur Identifikation anhand von stabilen, häufig PAS-verfügbaren Identifikatoren (z. B. UPN, Mail, Name), dann eine domänenspezifische Abfrage über den distinguishedName oder die Objekt-GUID gegen einen DC, um nicht im PAS enthaltene Felder oder RODC-gefilterte Attribute auszulesen. Dabei ist die Rechteprüfung nicht zu unterschätzen: Selbst wenn ein Attribut repliziert wurde, kann es durch ACLs oder Vertraulichkeitsflags vor dem Lesenden verborgen sein.
| Filterabsicht | Robuster Filterkern | Hinweis zur Serverwahl |
|---|---|---|
| Forestweite Identifikation eines Users | (&(objectCategory=person)(objectClass=user)(userPrincipalName=jmustermann@corp.example)) |
GC geeignet; Detailattribute ggf. per DC nachladen |
| Gruppenmitgliedschaft auflösen (direkt) | (&(objectClass=group)(member=CN=...,OU=...,DC=...)) |
Member-Liste kann groß sein; DC-Abfrage oft planbarer, GC nur wenn Attribut verfügbar ist |
| Computerobjekt nach Hostname | (&(objectClass=computer)(dNSHostName=pc01.corp.example)) |
GC möglich, sofern Attribut im PAS; sonst domänenspezifisch suchen |
Für reproduzierbare Resultate lohnt sich die explizite Angabe von Attributlisten statt pauschalem „alles“. Das reduziert Antwortgrößen, vermeidet Überraschungen bei GC/RODC-Teilbeständen und begrenzt die Abhängigkeit von Attributen, die zwar existieren, aber nicht repliziert oder nicht lesbar sind. In Multi-Domain- und Außenstellen-Topologien wird die Serverauswahl damit zu einem integralen Bestandteil jedes LDAP-Filters, nicht zu einer nachgeordneten Transportentscheidung.
Sicherheitsrelevanz und Auswertung: Zugriffsrechte auf Attribute, sensible Felder, Objektzuordnungen (User/Group/Computer) sowie PowerShell- und LDAP-Query-Beispiele
Zugriffsrechte auf Attribute: Lese-/Schreibpfade, vertrauliche Attribute und effektive Berechtigungen
Active-Directory-Attribute werden nicht nur über Objekt-ACLs, sondern zusätzlich über attributbezogene Rechte kontrolliert. In der DACL eines Objekts wirken dabei Property-Specific-ACEs (z. B. „Read Property“/„Write Property“) auf einzelne Attribute, während generische Rechte wie „Read All Properties“ breitere Wirkung entfalten. Für die Bewertung zählt stets die effektive Berechtigung nach Gruppenmitgliedschaften, Vererbung, Deny-ACE-Priorität und ggf. AdminSDHolder-bedingter Schutzmechanik für privilegierte Konten.
Ein weiterer, häufig unterschätzter Sicherheitshebel sind „vertrauliche“ Attribute (confidential attributes). Diese werden im Schema durch das Flag searchFlags als vertraulich markiert. Das hat zur Folge, dass das Attribut selbst bei generischen Leserechten nicht automatisch ausgelesen werden darf; es ist eine explizite Berechtigung „Read Property“ auf dieses Attribut erforderlich. Klassische Beispiele sind Unix-bezogene Kennwortfelder in gemischten Umgebungen oder bestimmte LSA-/Service-bezogene Geheimnisse, sofern sie als Attribut im Verzeichnis geführt werden.
Bei „Write Property“ ist zusätzlich zu beachten, dass einzelne Attribute Sonderlogik besitzen: Validierung durch den DC (z. B. Syntax/Constraints), Beschränkungen auf Self-Write (z. B. für bestimmte „Validated Writes“) oder erweiterte Rechte („Extended Rights“) wie beim Zurücksetzen von Kennwörtern. Für Audits empfiehlt sich die Trennung in (1) wer darf lesen, (2) wer darf schreiben, (3) wer kann indirekt Änderungen auslösen, etwa über Gruppenmitgliedschaften oder Delegationsmodelle.
| Attribut (LDAP-Display-Name) | Warum sensibel | Typische Schutz-/Audit-Punkte |
|---|---|---|
msDS-KeyCredentialLink |
Enthält Key-Material-Verknüpfungen für passwortlose Anmeldung; Missbrauch ermöglicht Shadow-Credentials-Angriffe. | Schreibrechte streng begrenzen; Änderungen auditieren; ungewöhnliche Schreibquellen korrelieren. |
servicePrincipalName |
Steuert Kerberos-SPNs; Manipulation kann Kerberoasting-/Impersonation-Pfade öffnen oder Dienste brechen. | Schreibrechte delegationsarm; Dublettenprüfung; Änderungshistorie überwachen. |
userAccountControl |
Schaltet Sicherheitsflags (z. B. Deaktivierung, Preauth, Delegation); Fehlkonfiguration erhöht Angriffsfläche. | Änderungen nur über kontrollierte Prozesse; Audit auf Flag-Transitions. |
msDS-AllowedToDelegateTo |
Kerberos Constrained Delegation; falsche Ziele ermöglichen lateral movement. | Schreibrechte sehr restriktiv; Ziel-Services whitelisten; Review bei Admin-Konten. |
member / memberOf |
Gruppenmitgliedschaften steuern Rechteketten; Write-Zugriff entspricht oft Privileggewinn. | „Write Members“ und „Write Property“ getrennt prüfen; Admin-Gruppen besonders härten. |
Objektzuordnungen (User/Group/Computer): sicherheitsrelevante Beziehungen und typische Abbildungspfade
Viele sicherheitskritische Auswertungen entstehen erst aus der Beziehung mehrerer Objekttypen. Benutzerkonten (Klasse user) referenzieren Gruppen über memberOf (berechnet) und über die Gruppenseite über member (autoritativer Beziehungsanker). Computerkonten (Klasse computer) sind technisch ebenfalls Sicherheitsprinzipale und tragen für Kerberos, Delegation und lokale Administratorzuweisungen eine ähnliche Relevanz wie Benutzer.
Für Abfragen ist die Richtung der Beziehung entscheidend: Gruppenmitgliedschaften werden zuverlässig über Gruppenobjekte ausgewertet ((member=...)), während memberOf je nach Zugriffsmethode und Tokenbildung eher als Komfortfeld betrachtet wird. Besonders bei verschachtelten Gruppen ist die rekursive Auflösung erforderlich; LDAP bietet hierfür das Matching-Rule-in-Chain, sofern die DC-Funktionalität verfügbar ist. Zusätzlich existieren Querbeziehungen, etwa Manager-/Direct-Reports, Delegationslisten oder „Allowed-To-Act“-Einträge für ressourcenbasierte constrained Delegation.
- Benutzer ↔ Gruppe (direkt): Autoritativ über
group:member; typische Filter:(member=CN=...,OU=...,DC=...) - Benutzer ↔ Gruppe (rekursiv): Matching-Rule-in-Chain:
(member:1.2.840.113556.1.4.1941:=CN=...,OU=...,DC=...) - Computer als Sicherheitsprinzipal: Relevante Attribute wie
servicePrincipalName,msDS-AllowedToDelegateTo,userAccountControlund gruppenbasierte Zuweisungen viamemberOf/member - RBCD (ressourcenbasiert): Steuerung über
msDS-AllowedToActOnBehalfOfOtherIdentityam Zielcomputer/-dienst; Auswertung erfordert das Parsen der Security Descriptor-Struktur.
PowerShell-Auswertung: gezielte Attribut-Reads, Rechteindikatoren und Anomaliesuche
Für präzise Auswertungen eignen sich die ActiveDirectory-PowerShell-Module (RSAT) und der direkte Zugriff auf nTSecurityDescriptor bzw. auf einzelne Attribute. In produktiven Umgebungen sollten Abfragen attributselektiv erfolgen (-Properties statt „*“), um Last zu begrenzen und Fehlannahmen durch nicht gelesene Felder zu vermeiden. Für Sicherheitsprüfungen ist es hilfreich, mutierbare Attribute mit Privilegwirkung (z. B. Delegation, SPNs, KeyCredentials) separat zu inventarisieren und zeitlich gegen Change-Events (Directory Service Changes) zu korrelieren.
- SPN-Inventar (Benutzer/Computer):
Get-ADObject -LDAPFilter "(servicePrincipalName=*)" -Properties servicePrincipalName,objectClass | Select-Object DistinguishedName,objectClass,servicePrincipalName - Delegation-Flags (UAC) finden:
Get-ADObject -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)" -Properties userAccountControl,objectClass | Select-Object DistinguishedName,objectClass,userAccountControl - KeyCredentialLink prüfen (Shadow-Credentials-Indikator):
Get-ADObject -LDAPFilter "(msDS-KeyCredentialLink=*)" -Properties msDS-KeyCredentialLink,objectClass | Select-Object DistinguishedName,objectClass - Admin-Gruppen rekursiv auflösen:
Get-ADGroupMember -Identity "Domain Admins" -Recursive | Select-Object objectClass,SamAccountName,DistinguishedName
LDAP-Query-Beispiele: präzise Filter, OID-Matching-Rules und GC/Replications-Fallstricke
LDAP-Filter sollten die Attributsyntax und das Replikations-/GC-Verhalten berücksichtigen. Attribute, die nicht im Global Catalog enthalten sind, liefern im GC-Kontext keine Werte; das betrifft je nach Schema- und Forestkonfiguration viele nicht zur Partial Attribute Set (PAS) gehörende Felder. Ebenso sind „constructed attributes“ (z. B. memberOf) keine replizierten Werte; sie entstehen zur Laufzeit und können je nach Zugriffsmethode anders wirken als die Auswertung über den autoritativen Anker (group:member).
Für bitweise Prüfungen werden in LDAP üblicherweise Matching-Rules genutzt. 1.2.840.113556.1.4.803 prüft ein gesetztes Bit (bitwise AND ungleich 0), 1.2.840.113556.1.4.804 prüft exakte Bitmaskenbedingungen. Für verschachtelte Gruppen dient 1.2.840.113556.1.4.1941 („in chain“) der rekursiven Mitgliedschaftsauswertung. Diese Regeln sind DC-spezifisch implementiert; Portabilität zu Nicht-AD-LDAPs ist nicht gegeben.
- Deaktivierte Konten:
(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2)) - Konten ohne Preauth (AS-REP-roastbar, falls weitere Bedingungen passen):
(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=4194304)) - Mitglieder einer Gruppe rekursiv:
(&(objectCategory=person)(objectClass=user)(memberOf:1.2.840.113556.1.4.1941:=CN=Domain Admins,CN=Users,DC=example,DC=com)) - Computer mit RBCD-Eintrag (Existenzprüfung):
(&(objectClass=computer)(msDS-AllowedToActOnBehalfOfOtherIdentity=*))
Bei sicherheitsrelevanten Feldern lohnt sich zusätzlich eine negative Suche nach „Überraschungen“: etwa SPNs auf Benutzerkonten außerhalb erwarteter Service-OU-Strukturen oder Delegationsattribute auf Konten mit hoher Privilegierung. Für belastbare Ergebnisse muss die Abfragebasis (DC vs. GC), die Sichtbarkeit vertraulicher Attribute und die Aktualität replizierter Werte (insbesondere bei standortübergreifender Replikation) in die Interpretation einfließen.
