Sensitive terms in Active Directory description: review DA, admin, and privileged

Sensitive terms in Active Directory description fields can disclose which identities deserve closer attention even when no password appears in the text. This guide separates a broad manual review of DA, admin, and privileged labels from the five patterns implemented by etc-collector, then shows how to inventory, clean, and recheck individual descriptions.

What Sensitive Terms in Active Directory Description Reveal

A description such as domain admin — backup operator is a statement about an account's purpose. The security inference is that a reader could use that statement to shortlist potential targets. It does not establish that the account actually has administrative rights. The example is fictional; it is neither a production observation nor a confirmed attack.

The same distinction applies to DA, emergency access notes, and service labels. A reviewer might interpret them as clues about an identity's role, but local terminology matters. admin can refer to administrative work outside IT. service client can describe a business department. An old description can survive a change of duties. Ask the owner what the text means before treating it as evidence of current privilege.

This article concerns target identification without a secret. For exact passwords, temporary values, or credential hints, follow password exposure, rotation, and investigation in AD description fields. Deleting a role label and responding to an exposed credential are different tasks; discovering a secret changes the response required.

Use a review record that distinguishes the observed wording, its interpretation, and the evidence still needed. For example, record “description contains privileged” separately from “owner confirmed this is an administrative identity.” Keep an unresolved case open when the owner is unknown. Do not convert a lexical match into a statement that the account is compromised, bypasses MFA, or belongs to Domain Admins.

How Description Read Access Works

Microsoft's privileged accounts and groups guide explains that ACLs commonly grant Authenticated Users access to general object information. Its permissions section explicitly includes general user properties. This supports reviewing description exposure with an ordinary authenticated identity, rather than assuming the field is visible only to administrators. Authenticated does not mean anonymous, and permission to read does not imply permission to edit.

The historical confidential attribute documentation also describes default attribute read access and the role of READ_PROPERTY. Actual access depends on the object's effective permissions. A local permission change may alter what a reader receives, so verify the deployment instead of assuming every object follows the default.

The description schema reference identifies the LDAP attribute as description, with searchFlags=0x00000000 and systemFlags=0x00000010. Its remarks distinguish single-valued descriptions for SAM-managed classes, including security principals, from potentially multiple values on other classes. An expanded object review should preserve those values instead of assuming every description is one user-account string.

For a useful exposure comparison, choose a known populated object and run the same scoped read with an ordinary reader and an authorized reviewer. Record the identity used, domain controller, search base, time, and any errors. This is a recommended measurement procedure, not a claim that those tests have been performed here. Keep the review material in an access-controlled location; a cleanup exercise should not become a new broadly shared list of sensitive identities.

Detection

Step 1 — Inventory populated user descriptions

The commands below are adapted from Microsoft Learn, using the documented parameters of Get-ADUser and Get-ADObject. They have not been executed against a directory for this article. Replace the example DN and server, use the ActiveDirectory module, and select the reader whose access you intend to measure. Each block is a separate measure.

Start with populated user descriptions:

Get-ADUser -LDAPFilter '(description=*)' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Requesting -Properties description asks for the attribute; it does not grant access. Treat an empty response as something to investigate. Check the scope, permissions, and whether a known populated object is returned before declaring the directory free of sensitive descriptions.

Step 2 — Separate enabled and disabled accounts

Microsoft's Get-ADUser example 5 uses the LDAP bitwise test for userAccountControl bit 2 to exclude disabled accounts. The inventory below adds the description condition and uses the parenthesized NOT form documented in Microsoft's LDAP search filter syntax:

Get-ADUser -LDAPFilter '(&(description=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

For the complementary review, retain the bit test without negation:

Get-ADUser -LDAPFilter '(&(description=*)(userAccountControl:1.2.840.113556.1.4.803:=2))' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

This separates account state, not actual privilege. Keep disabled objects in the cleanup queue and review their descriptions before any planned reactivation. Do not interpret the disabled flag as proof that nobody can read the object or that all historical sessions have been invalidated.

Step 3 — Review lexical matches and wider local labels

A substring shortlist can make the first pass manageable:

Get-ADUser -LDAPFilter '(|(description=*admin*)(description=*privileged*))' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

This LDAP shortlist is not equivalent to the collector regexes. Review the original populated-description inventory for DA, break-glass, service, local abbreviations, and terms in other languages. Otherwise, a narrow query can hide the very labels the manual exercise is intended to assess.

The exact collector patterns are defined in accounts/privileged/domain-admin-description.go:35–41, relative to public/internal/audit/detectors/ad/:

(?i)domain\s*admin
(?i)enterprise\s*admin
(?i)administrator
(?i)admin\s*account
(?i)privileged

All five ignore case. They have no word boundary or start/end anchor, and \s* allows zero whitespace. Consequently, domainadmin matches the first pattern and unprivileged matches the last. The latter can describe the opposite of what a reviewer expects; examine the complete value rather than treating the matched substring as a verdict.

These outcomes follow the source patterns; they are not reported results from a live audit. Keep three separate conclusions: matched wording, owner-confirmed purpose, and independently verified access. That separation makes a false positive explainable without pretending the broader inventory is complete.

Step 4 — Expand objects and monitor changes

If descriptions on other object classes are in scope, use a separate inventory:

Get-ADObject -LDAPFilter '(description=*)' -Properties description -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

This includes any returned object class with a populated description. It is a manual extension beyond the two user detectors, not evidence that their automatic coverage includes those objects. Preserve multiple description values where the schema permits them.

For reintroduction monitoring, Microsoft's Event ID 5136 reference documents directory modifications. Configure Audit Directory Service Changes and an appropriate Write SACL for the objects and attributes being monitored. Select events where AttributeLDAPDisplayName=description; inspect the actor, object, and value. Where both Value Deleted and Value Added events are available, correlate them using OpCorrelationID and the same object and attribute.

An absent 5136 event does not prove nobody read the previous text. These change events and the posture inventory answer different questions: what is written now, and what audited modification occurred.

Remediation

Step 1 — Agree on the replacement information

For a role-only disclosure, the recommended workflow is to move sensitive context into an inventory or runbook with appropriate access controls. Have the owner approve what should remain in AD. An opaque reference such as Managed record INV-01234 can preserve an operational pointer without naming the privilege or emergency procedure. The referenced system must also enforce access; obscuring a record name alone is not authorization.

Define examples of acceptable and unacceptable wording with the team that provisions accounts. Include local labels that automated checks miss. Review helpdesk templates, handover instructions, and who can edit descriptions so the same note is not restored at the next maintenance task. Make a decision per object instead of clearing every populated description indiscriminately.

Step 2 — Preview and confirm one field change

These examples adapt Set-ADUser's documented Clear, Description, WhatIf, and Confirm parameters. Example 4 specifically clears description. Choose either removal or replacement for the selected account.

Preview removal:

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Clear description -Server 'dc01.corp.example' -WhatIf

After owner approval, request confirmation for the actual removal:

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Clear description -Server 'dc01.corp.example' -Confirm

Alternatively, preview a neutral replacement:

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Description 'Managed record INV-01234' -Server 'dc01.corp.example' -WhatIf

Then confirm that replacement separately:

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Description 'Managed record INV-01234' -Server 'dc01.corp.example' -Confirm

-WhatIf does not apply the change or prove application compatibility. Retain the selected object's identity and approved action in the change record, then verify the written value. These commands are documented examples, not a global remediation script or a report of completed cleanup.

Step 3 — Avoid unsupported confidentiality shortcuts

If local read restrictions are considered, commission an effective-permission and dependency review first. The Microsoft permissions and confidential-attribute pages explain ACEs, inheritance, and read checks; they do not validate a universal ACL recipe for this deployment. Adding a dedicated reader does not remove a broad grant already present. Do not remove Authenticated Users read access globally without auditing consumers and delegation.

Prefer storing confidential operational information in a protected reference system. A schema extension or redesigned permission model requires its own tested project. Cleaning descriptions reduces one clue; it does not replace privilege reduction or conceal every other directory property.

Validation After Cleanup

Use the documented Get-ADObject Identity read to inspect the selected object after the authorized write:

Get-ADObject -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Properties description -Server 'dc01.corp.example'

The recommended acceptance record should state whether the intended value is present, whether the owner can use the protected reference, and whether legitimate tools still work. Recheck the inventory with the same reader and scope used initially. Account for replication between domain controllers when comparing directory servers, and preserve the DC identity so differing reads can be investigated instead of dismissed.

Validate broader labels as well as regex matches. A clean automated result after replacing domain admin with DA would leave the targeting clue in place. Conversely, an approved phrase containing unprivileged can remain a lexical match whose context is benign. Record that decision explicitly; do not claim that every remaining match represents dangerous access or that every negative result proves safe wording.

Actual rights need a separate review. Privileged access drift validation examines effective membership, delegated ACL paths, and replication rights against a baseline. Use that workflow when a description suggests administrative access. Changing the description itself is not evidence that the account's rights were reduced.

Finally, verify the change-monitoring configuration with an approved test change and check that the expected 5136 data reaches the review process. Review any new sensitive wording with its owner. If a secret is discovered during validation, route it to the credential-exposure workflow instead of closing the case after editing the field. Define the next review owner so descriptions on disabled identities are also checked before reactivation.

How EtcSec Detects This

The two etc-collector implementations reviewed for this article operate on data.Users and the collected Description string. Both skip empty descriptions and stop after the first recognized pattern for a user. They use the same five regexes, while selecting opposite account-state populations.

The enabled-account predicate is at lines 47–61 of the first file; the disabled-account predicate is at lines 43–57 of the second. Their findings count affected users. Detail entities are attached only when IncludeDetails is true and at least one user is affected, at lines 72–74 and 68–70 respectively.

Neither Detect() reads memberOf, verifies actual rights, searches for passwords, or analyzes directory events. The identifier DOMAIN_ADMIN_IN_DESCRIPTION therefore describes a lexical exposure check, not proof that an affected user belongs to Domain Admins. The High/Low values are collector policy classifications, not measured attack outcomes or Microsoft severity ratings.

Treat these findings as review inputs: inspect the wording, confirm purpose with the owner, clean the approved field, and rerun the scoped check. A negative lexical finding does not establish the absence of sensitive labels, and removing a label does not establish the removal of privilege.