Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

To restrict ordinary users from reading a sensitive Active Directory attribute, set bit 7 of that attribute’s schema searchFlags value: decimal 128 (0x80). This marks it confidential. A reader then needs both the ordinary READ_PROPERTY right and CONTROL_ACCESS for the attribute or its property set. The setting is an authorization check—not encryption—and it only provides the intended protection when every domain controller and relevant client path has been accounted for.

What the confidentiality bit does

Active Directory keeps an attribute’s schema definition in an attributeSchema object. Its searchFlags value is a bit field: bit 7, decimal 128 or hexadecimal 0x80, is the confidentiality flag, named fCONFIDENTIAL in the Active Directory technical specification. Microsoft describes it this way: “Bit 7 (128) designates the attribute as confidential.” See Microsoft’s instructions for marking an attribute confidential and the MS-ADTS specification.

Once the flag is set, permission to read the attribute requires both READ_PROPERTY and CONTROL_ACCESS. The latter can be granted for the attribute or for a property set containing it. Microsoft notes that administrators have CONTROL_ACCESS to all objects by default, and that administrators can delegate the right to other users or groups. The flag does not encrypt the value at rest or make it inaccessible to administrators and other principals explicitly granted the required access.

How to set searchFlags to 128

Changing an existing searchFlags value requires preserving its other bits. Microsoft gives the calculation as 128 + current searchFlags value = new searchFlags value. In practice, first check whether bit 7 is already set; if it is, do not add 128 again. Otherwise, set the new value by adding 128 to the existing value, or equivalently setting that bit while leaving all other bits unchanged.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
#1 Best Overall
Sale
Mastering Active Directory: Design, deploy, and protect Active Directory Domain Services for Windows Server 2022
  • Mastering Active Directory: Design, deploy, and protect Active Directory Domain Services for Windows Server 2022, 3rd Edition
  • ABIS BOOK
  • Packt Publishing
  1. Identify the attribute. Confirm the exact attribute to protect. If the sensitive value needs a new attribute, design and approve that schema change before proceeding.
  2. Read its current schema value. Locate the attribute’s attributeSchema object and record its existing searchFlags value. Do not assume it is zero.
  3. Calculate the new value. Set bit 7 while preserving the other existing flags. If the bit is already set, no change is needed for confidentiality.
  4. Test and approve the schema change. Microsoft documents Ldp.exe, Adsiedit.msc, and LDIF files as ways to work with schema attributes. Use the method and change-control process approved for your environment; test first in a lab that mirrors the production forest.
  5. Grant required readers access. Assign CONTROL_ACCESS to the application or administrator group that must read the value. The permission can be explicit or inherited; tools such as Dsacls.exe can assign it. Verify the scope and inheritance of the ACE rather than granting access broadly.
  6. Test allowed and denied identities. Check reads with accounts that should and should not have access. Test searches that request the attribute and searches whose filter references it, then validate any synchronization or application-specific paths that use the attribute.

Compatibility and operational risks

Microsoft’s implementation guidance says confidentiality enforcement requires domain controllers running Windows Server 2003 SP1 or later and warns that older domain controllers in a mixed environment can still expose the value. Confirm the versions of all domain controllers that could handle relevant requests before relying on the flag.

Schema changes affect the forest, so a mistake can have a broad impact. Incorrect ACL scope can either block applications that need the attribute or allow more principals to read it than intended. Test both outcomes in a production-like lab, plan a rollback, and monitor access failures after deployment.

Check each access path, not just an ordinary LDAP read

Do not assume that a successful test through one LDAP client proves every access path is behaving as intended. Validate the ordinary searches, synchronization controls, Global Catalog usage, and application-specific APIs that matter in your environment. The MS-ADTS specification notes that DirSync controls can return a confidential attribute with an empty value when object-security flags are used. A consumer that treats an empty result as a valid value may behave differently from one that treats it as missing, so test the actual synchronization workflow.

LDAP transport settings matter too. The current MS-ADTS specification says the dSHeuristics encryption-disable setting governs searches, modifications, and adds involving confidential attributes. With no disable bits set, encrypted transport or SASL encryption is required. Keep LDAP signing and channel encryption enabled; do not weaken the forest-wide heuristic to accommodate a legacy client.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

When to use this instead of broader permissions changes

Approach Scope Key consideration
Confidentiality bit Targets reads of a particular attribute, with access controlled through CONTROL_ACCESS. Requires supported domain controllers, appropriate delegation, and testing of relevant protocol paths.
Object or OU ACL changes Can affect access to objects or broader sets of properties, depending on the ACE scope. Review inheritance and application dependencies carefully to avoid broader access changes than intended.
Transport encryption Protects LDAP communications in transit. It does not replace attribute authorization; retain encrypted LDAP sessions alongside access controls.

The confidentiality bit is most useful when the goal is to enforce an additional read authorization check on a specific attribute without changing access to every property on an object. It should be treated as one part of the control design: schema support, explicit reader delegation, compatible LDAP behavior, and secure transport all need to line up.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.