Real-World Active Directory Delegation Examples

Three concrete Active Directory delegation problems with concrete solutions: hide mobile and pager numbers from regular users without affecting other personal info, restrict national-ID attributes to HR using the schema confidential bit, and make a published shared folder invisible in AD to everyone except a specific group. Each scenario uses a different ACL technique — attribute-level Deny ACEs, the searchFlags confidential bit, and volume-object ACLs respectively.

Scenario 1: Hide mobile and pager numbers for engineers

The problem

Your company has a Hardware Support team. When an employee has a problem, the help desk assigns a specific engineer to visit them. The trouble: regular users find the engineer’s mobile and pager numbers in Active Directory and call them directly, bypassing the help desk.

Management wants to stop the direct calls but keep the engineer’s name visible — they still want a friendly face attached to the support ticket.

Where the data lives

Each user account in AD stores attributes like name, phone, email, mobile, pager, address, and so on. Mobile and pager are part of the Personal Information property set — a collection of 46 related attributes grouped together for permission management.

Why everyone can read them today

If you check the ACL on a user object, you’ll see two relevant entries:

1. Pre-Windows 2000 Compatible Access has the Read Property (RP) right.
2. Authenticated Users has explicit Read Property on the Personal Information property set.

Right now everyone in the domain can read every attribute in that property set, including mobile and pager.

Four options — and the right one

Option 1: Remove mobile/pager from the property set. You’d edit the AD schema and re-add per-attribute permissions everywhere else. Schema-level work, forest-wide impact, lots of follow-on changes. Don’t.

Option 2: Strip Personal Info access from every user object. Affects every user in the forest, breaks lots of legitimate use cases, requires manual fix-ups elsewhere. Don’t.

Option 3: Per-engineer Deny on the whole Personal Information set. This works for the engineers but hides all 46 attributes — not just mobile and pager. You’ll break things you didn’t intend to.

Option 4 (best): Per-engineer Deny on the specific mobile and pager attributes. Targeted at the two attributes that are actually causing the problem; everything else stays visible. Won’t break if domain mode changes later. Clean, focused, safe.

Step-by-step plan (Option 4)

1. Create a new OU called Engineers inside the existing Hardware Support Staff OU.
2. Move all engineer user accounts into the Engineers OU.
3. For each engineer user, open Properties → Security tab → Advanced and add a Deny entry that targets:
   • mobile
   • pager

   Deny Read permission only, scoped to the This object only property pattern.

4. Optional: write a script to apply the same Deny ACEs to any future engineer accounts moved into the OU. dsacls or PowerShell’s Set-Acl on AD objects both work.

Why not the confidential bit here?

The confidential bit is forest-wide and affects every user object — it’s the wrong tool for hiding two attributes on a small group of users. It also doesn’t apply to Category 1 (system) attributes, and the Personal Information members include several Category 1 entries. Use targeted Deny ACEs instead.

Scenario 2: Restrict national/regional ID numbers to HR

The goal

Store a national ID number (NID, SSN, or equivalent) on each user object in AD. Only the HR team and Domain Admins should be able to read it. Everyone else — regular users, IT staff, helpdesk — should not.

The mechanism: the confidential bit

This is exactly the case the confidential bit was designed for.

Step 1: Add a custom attribute. Use the AD schema (Schema MMC, schema.msc after registering schmmgmt.dll) or PowerShell to add a new attribute to the user object — for example, employeeNationalID.

Step 2: Set the confidential bit. When you create the attribute, set searchFlags = 128 (the SEARCH_FLAGS_CONFIDENTIAL bit). That tells AD: this attribute is confidential, hide it unless the requester has the Control Access right for it. The data on disk is not encrypted — the bit only changes the read-permission semantics.

Step 3: Create an HR-only group. Create a security group named HR-Confidential and add the HR staff who legitimately need to read the ID number.

Step 4: Grant Control Access. At the root of the domain, grant the HR-Confidential group Control Access on the new attribute, with inheritance flowing down to all user objects.

The result:

• HR can read the ID number on any user account.
• Everyone else cannot — even though they have Read Property on the user object as a whole.
• Domain Admins can still read it (see below).

What about Domain Admins?

Domain Admins can read the confidential attribute. That’s a feature of AD, not a bug — Domain Admins have effectively unlimited access to the directory. You can stack a Deny ACE on top of the Control Access grant, but a Domain Admin can simply remove the Deny if they want to. There’s no trick that hides anything from a Domain Admin without involving systems outside AD.

If you really need to hide from Domain Admins

If the data is sensitive enough that even Domain Admins must not read it, AD ACLs alone are not enough. Two options:

• Encrypt at the application layer. Store the ID number as ciphertext encrypted with a key that only HR has access to. Domain Admins can read the attribute but only see ciphertext.
• Store the data outside AD. Put the ID numbers in a dedicated HR system or encrypted database that doesn’t share its access controls with AD. Domain Admins can’t bypass an ACL on a system they don’t administer.

Summary

The confidential bit + Control Access grant is the right answer for the common HR scenario. If your threat model includes the Domain Admins themselves, you’re no longer in “use AD permissions” territory — you need encryption or out-of-band storage.

Scenario 3: Hide a published shared folder from everyone except Finance

The goal

Finance has a new shared folder Budget_Details. NTFS / share permissions already restrict who can open the files — that part is fine. The remaining problem: the share is published in Active Directory, so anyone browsing AD can see that Budget_Details exists, even if they can’t open it. Finance wants the share to be invisible in AD to anyone outside their team.

What’s happening behind the scenes

When you publish a shared folder in AD, it becomes a volume object in the directory tree. The volume object has its own ACL, separate from the underlying NTFS / share permissions. By default, the ACL grants Authenticated Users Read access on the volume object — which is what makes the share visible when users browse AD.

How to fix it

1. Open Active Directory Users and Computers with View → Advanced Features enabled.
2. Locate the volume object representing Budget_Details.
3. Right-click → Properties → Security.
4. Remove the Authenticated Users entry — this kills general visibility.
5. Click Add and select the Finance security group. Grant Read and List Contents.
6. Click Apply → OK.

The result:

• Finance members can find Budget_Details when they browse AD.
• Everyone else doesn’t see it listed at all — the volume object is filtered out of their view.

Summary

Volume-object visibility in AD is governed by the volume object’s own ACL, not by the share/NTFS permissions on the file system. To hide a published share from non-members, remove Authenticated Users from the volume object’s ACL and grant Read/List only to the group that should see it.

Conclusion

Three different delegation tools for three different problems:

• Targeted Deny ACEs when you need to hide a small set of attributes from a specific group of user objects without changing schema or affecting the rest of the forest.
• The schema confidential bit when an entire attribute should be HR-only (or some-other-team-only) across the whole forest, with Control Access granted to the appropriate group.
• Volume-object ACLs when a published share should be visible only to its intended audience.

The common pattern across all three: AD permissions are layered — defaults are inherited, the requester sees the union of every applicable ACE, and Deny entries beat Allow at the same scope. Pick the smallest, most targeted change that solves the problem, and you’ll avoid the cascade of side-effects that the broader options inflict.