AD confidential attributes: verify read access

What Are AD Confidential Attributes?

AD confidential attributes are directory attributes subject to an additional read access check. Start by identifying which custom attributes actually contain sensitive business data, then verify who can read them. A classification reminder alone does not establish that data is exposed, that an attribute lacks protection, or that the organization fails a compliance requirement.

This guide uses a narrow example: a custom attribute approved for a particular business purpose, with a named owner and a documented list of readers. It describes a laboratory verification procedure using dummy values. No Active Directory test was executed for this article, and none of the expected outcomes below is presented as an observed result.

The useful deliverable is a read-access decision record: the attribute's classification, schema eligibility, effective readers, expected application behavior, and any measured difference from that expectation. Complete that record before proposing a schema change.

How the Confidential Read Check Works

The MS-ADTS searchFlags definition identifies fCONFIDENTIAL as bit 0x80 (128). It requires an extended access check. Other flags have separate meanings, so recording the whole existing value matters.

For an attribute carrying that flag, MS-ADTS Extended Access Checks requires both READ_PROPERTY and CONTROL_ACCESS. Without the required rights, the value is treated as absent in returned attributes and the LDAP filter. An absent value is consequently not enough to distinguish access restriction from an empty attribute.

Microsoft's confidential attribute guidance excludes base schema attributes, identified by FLAG_SCHEMA_BASE_OBJECT (0x10) in systemFlags. Its example distinguishes employeeID, a base attribute, from an eligible attribute. A sensitive business meaning does not override that schema restriction.

The same guidance explains that Full Control includes CONTROL_ACCESS, and that generic grants can be broader than attribute-specific ACEs. Explicit grants and inherited grants both matter. Treat a screenshot of one permission entry as an input to the review, rather than a complete answer about effective access.

Detection: Build an Approved Attribute Inventory

Step 1 — Agree the classification and owner

Ask the data owner which custom attributes contain information that requires restricted reading. Record the approved classification and purpose without copying production values into the review. A field name such as "private" or "confidential" is not an approved classification.

For each candidate, record its LDAP display name, schema object DN, object classes where it is used, business owner, legitimate readers, and consuming applications. Also identify who can authorize a change. Where ownership or classification is unresolved, leave the access expectation unresolved and route that question to the responsible team.

A small review sheet is more useful than a blanket list of every attribute:

Keep the inventory limited to genuinely sensitive custom attributes. If the investigation discovers credentials in ordinary notes, follow the separate password exposure removal and rotation workflow. Changing a confidentiality flag is not a substitute for addressing that exposure.

Step 2 — Read the schema before considering a change

Use a designated laboratory domain controller and a known candidate from the approved inventory. These examples require the ActiveDirectory PowerShell module. Replace the sample server and attribute with laboratory equivalents; do not run them against production as part of this procedure.

The Get-ADRootDSE documentation exposes schemaNamingContext. Get-ADObject supports LDAP filters, a search base, an explicit server and additional properties. The following is an illustrative read-only combination of those documented parameters:

$dc = 'dc01.lab.example'
$schema = (Get-ADRootDSE -Server $dc).schemaNamingContext
Get-ADObject -Server $dc -SearchBase $schema -LDAPFilter '(lDAPDisplayName=labSensitiveReference)' -Properties lDAPDisplayName,searchFlags,systemFlags,schemaIDGUID,attributeSecurityGUID

Record the returned object's DN and the complete flag values. If the query fails or does not identify the intended attribute, stop that candidate's assessment. Do not convert an unsuccessful lookup into "not confidential" or "eligible."

Review whether the confidentiality bit is already present and whether the base-schema bit excludes the proposed use. Retain the existing flag values in the evidence, including unrelated bits. At this stage, the output is an eligibility assessment, not a request to set every sensitive-looking field to 128.

Step 3 — Explain effective read access

For each approved reader and each representative identity outside the approved reader set, inspect the target object's security descriptor and the relevant parent-container inheritance. Include group context, applicable denies, attribute or property-set scope, generic ACEs, and any disabled inheritance. Record the reason for the access expectation.

Check READ_PROPERTY and, when confidentiality applies, CONTROL_ACCESS separately. A reader's ability to browse the object does not settle its ability to obtain the candidate value. Likewise, a narrowly described application role can still receive broad access through another group or inherited entry.

Pay particular attention to Full Control and generic control-access grants. The practical question is whether those grants already give an identity the additional right, not whether an ACE happens to contain the attribute's name. Document the grant's origin so a future reviewer can reproduce the reasoning.

This review concerns the contract for reading a custom attribute. For the separate investigation of schema write permissions and defaultSecurityDescriptor, use the schema permissions and default security descriptor audit.

Laboratory Verification: Compare Two Reader Identities

Step 4 — Establish a known dummy value

Prepare an isolated test object with a clearly artificial value in the approved candidate attribute. Have the laboratory operator confirm that the value exists, record its marker in the test record, and document the setup. Do not use actual personnel data, operational secrets, or a production directory export.

Select one identity that the owner has approved to read the value and one representative identity that should not read it. Document their group context. Neither identity should be silently replaced by the administrator account used to inspect the schema.

Use the same endpoint, object and requested attribute for both reads. The documented Get-ADObject credential parameter accepts an account name and prompts for its password. These are proposed laboratory commands, not recorded executions:

Get-ADObject -Server 'dc01.lab.example' -Identity 'CN=ReadContractTest,OU=Lab,DC=lab,DC=example' -Properties labSensitiveReference -Credential 'LAB\ApprovedReader'

Get-ADObject -Server 'dc01.lab.example' -Identity 'CN=ReadContractTest,OU=Lab,DC=lab,DC=example' -Properties labSensitiveReference -Credential 'LAB\OutsideReader'

Inspect the requested property in each returned object. Record whether it contains the known dummy marker, is absent or empty, or whether the command errors. Keep failed authentication, connectivity errors and missing test data distinct from an access restriction.

Step 5 — Record the difference without inventing a pass

The following table specifies expectations to evaluate; it contains no measured result:

If both identities read the marker, investigate the effective grants and the current flag state. If neither reads it, first verify the fixture, endpoint, credentials and requested property. If the approved reader succeeds and the outside reader does not, retain the evidence and its scope: that comparison covers those identities and that configuration.

Do not generalize a single comparison into proof that every user or application is correctly restricted. Add representative reader groups and inheritance boundaries according to the approved inventory. Record the date, operator, endpoint, schema values, query, identity context, outcome and unresolved questions for each case.

For applications using a different query path, reproduce that path separately with dummy data. The searchFlags specification notes behavior differences involving DirSync controls. Record the controls and client behavior when applicable; a PowerShell read alone does not validate an application's synchronization contract.

Remediation: Decide Before Changing the Schema

Step 6 — Select the action from the evidence

If classification or ownership is missing, obtain that decision first. If current access already matches the approved contract, retain the evidence and review schedule. If a read-access gap is measured, propose a specific correction with its affected identities and applications.

A proposed schema modification needs a separate documented decision. Include the attribute's eligibility, original flag values, required readers, grant scope, implementation owner, consumer compatibility plan, verification criteria and rollback approach. Preserve unrelated searchFlags bits in the proposed configuration. Avoid treating 128 as a universal replacement value.

Microsoft recommends testing attribute changes in a laboratory that mirrors the production forest. Use that testing to validate the exact proposed combination of schema configuration and permissions. The historical guidance contains version-specific tooling instructions; review their suitability for the target environment before implementation.

Step 7 — Validate compatibility and rollback

Ask each consuming application's owner which operation depends on the attribute and under which identity. Validate the approved function with dummy values, including how the application handles an unreadable or missing property. An authorized directory read and a working business workflow are separate acceptance checks.

Define rollback before deployment approval: record the original schema flag value, the exact permission entries involved, who may restore them, and how restoration would be verified. Restoring an earlier configuration may reopen reading, so include that consequence in the decision. Do not describe a rollback as erasing previously read or copied data.

The review closes only when three questions have explicit answers: which data has an approved classification and owner; whether the attribute is eligible and which effective rights give access; and which legitimate consumers must remain compatible after a possible change. Assign any unresolved answer to an owner rather than marking the assessment complete.

How EtcSec Detects This

DATA_CLASSIFICATION_MISSING is an informational review reminder in etc-collector. At collector commit 0423094759d50002457031317098417993e19510, public/internal/audit/detectors/ad/compliance/industry/data-classification.go:23 defines a Detect() that ignores both data and ctx and consumes no provider.

It always returns one finding with severity Info and a fixed Count: 1. Its title, description, sensitive-data examples and recommendations are static. The count is not a number of exposed attributes, missing classifications, or failed read tests.

This detector measures neither data classification nor confidential-attribute configuration, effective rights or consumer compatibility. Its finding supplies no evidence of exposure or non-compliance. Use it to initiate the inventory and laboratory decision record above, and keep those manual observations separate from the detector output.

Technical sources and collector implementation reviewed on 4 October 2026. The laboratory comparison remains a procedure for the reader to execute with approved dummy data.