Fine-Tuning Active Directory Access

Controlling who gets access to what in Active Directory means digging into the depths of AD. So grab a shovel and come along.

• By Bill Boswell
• November 01, 2003

The Active Directory database is a powerful tool, perhaps too powerful. How can one set the permissions and define roles that allow which attributes each user can view about a particular user? For example, I’d like the mail clerk to be able to see the office where his boss works, but it would be a very bad idea for him to be able to see his home address with all the things floating around in the mail these days. I imagine I’d have to customize the Schema, but how, where and in what way?
—Jeff

Jeff’s concern about free access by average users to information in AD echoes the concerns of many administrators. Not only do authenticated users have Read permissions on virtually every object in AD, they don’t need any special administrative tools to view that information. The Windows Address Book in the Accessories folder displays lots of information about users (see Figure 1).

Figure 1. The properties window of a user selected from the Windows Address Book. (Click image to view larger version.)

To expand on Jeff’s question a bit, let’s say that the mailroom clerks in his organization use the Windows Address Book to look up user locations. The Facilities manager wants the clerks to update any locations they find to be incorrect. The HR Director doesn’t want the mailroom clerks to see the users’ home addresses, which HR populates as part of its emergency contact information.

So, not only do we need to control access to discrete properties for selected classes of objects, we want to deny access to certain of those properties. This requires some clamoring around inside the pipes and support struts of AD and eventually, if we dig deeply enough, we’ll get to a point where, as Jeff feared, we’ll have to change the schema. Let’s see why.

Where to Assign Permissions
Start by using the AD Users and Computers (ADUC) console to create an Organizational Unit called TestOU that holds a few users along with an account called MailroomClerk and a group called Mailroom_Clerks. I’ll use a Universal security group in this example because Jeff’s forest might have multiple domains and the mailroom clerks might deliver mail to users in any of those domains. In a single domain, a Global group suffices.

If you right-click the TestOU in the ADUC console, you’ll see a Delegate Control option at the top of the property menu. This opens the Delegation of Control Wizard, a utility designed to assign access permissions to objects and their properties. (As you’ve probably noticed if you’ve worked with Windows 2000 for long, the developers appear to have been heavily influenced by Harry Potter. There’s a wizard for everything.)

You might be tempted to fire up the Delegation of Control Wizard and set to work modifying permissions, but hold off just a second. The wizard is designed to permit access. It’s not designed to deny access. Because we want both to permit access to certain attributes and deny access to others, we’ll need to make changes more or less directly to the security descriptors of the objects themselves.

In the Properties window of every AD object, you’ll find a Security tab that exposes an Access Control List (ACL) Editor. The initial (generic) view of the ACL Editor shows users and groups assigned access permission to the object. Checkboxes below the name indicate the general access permissions. Dimmed checkboxes indicate that a permission has been inherited from above.

Click Advanced to see the individual Access Control Entries (ACEs) that comprise the ACL in the order that the system evaluates them. In Win2K, the icon for a directly applied ACE displays in full color and the icon for an inherited ACE is dimmed slightly. The ACL Editor in Windows Server 2003 explicitly states that an ACE is directly applied or inherited and it shows the origin of any inherited ACEs.

Click Add and add the Mailroom_Clerks group to the ACL. This opens a window where you can modify object permission or property permission. Select the Properties tab. The Apply Onto drop-down field lists several options for targeting inheritance along with a list of object classes. Select User objects. This modifies the property list displayed by the ACL Editor to show User properties rather than OU properties (see Figure 2).

Figure 2. The Advanced view of the ACL Editor, showing Properties tab with list of User attributes to use for assigning access permissions.

What Permissions to Assign
The next chore is to figure out exactly what properties you want to control with security permissions. We want to give the mailroom clerks Allow Write access to the attribute that holds a user’s location and Deny Read for the attribute that holds a user’s home address. This isn’t as simple as it sounds, because you can’t always match the field label in the Windows Address Book or the ADUC console with a property listed in the ACL Editor. For example, the field labeled Office in the Windows Address Book and the ADUC console is populated from an AD attribute called PhysicalDeliveryOfficeName.

Here’s a quick way to find the true attribute name that lies behind a field in the GUI. First, use the ADUC console to put values in the fields for a particular user. For example, a user might have an Office entry of Bldg H, Floor 7, Cubicle 3H41 and a Street entry of Number 4 Privet Drive.

Then use the LDIFDE utility to list the AD attributes for that user as follows:

Here is a partial listing of the LDIFDE output:

Connecting to “w2k3-s1.company.com”
Logging in as current user using SSPI
Exporting directory to file con
Searching for entries...
Writing out entries.dn: CN=TestUser22,OU=TestOU,DC=company,DC=com
changetype: add
objectClass: user
cn: TestUser22
physicalDeliveryOfficeName: Bldg H, Floor 7, Cubicle 3H41
streetAddress: Number 4 Privet Drive

How to Assign Permissions
So, we want to assign Allow Write permissions to the PhysicalDeliveryOfficeName attribute for User objects in TestOU, and we want to assign Deny Read permissions to the StreetAddress attribute on those same objects.

Click the Properties tab and scroll through the list to find the properties. You’ll find an entry corresponding to StreetAddress easily enough, but you’ll look in vain for the PhysicalDeliveryOfficeName.

There’s a couple of reasons for this. First, sometimes Microsoft chooses to use the AD Service Interface (ADSI) property name for an attribute’s listing in the Properties tab rather than its standard LDAP property name. PhysicalDeliveryOfficeName might be listed as Office Location. You can find a table mapping ADSI property names with their LDAP counterparts at msdn.microsoft.com/library/default.asp?url=/library/en-us/netdir/adsi/mapping_
between_iadsuser_properties_and_active_directory_properties.asp.

But you won’t find Office Location on the list, either. That’s because the property has been flagged as hidden in a file called Dssec.dat, located in %windir%\System32. Dssec.dat is a text file that can be viewed and modified with Notepad. When you open Dssec. dat, you’ll notice that it’s divided into headings based on object class. Be sure to go to the [User] heading to make modifications. Otherwise, you won’t see any effect on the GUI display. To show the PhysicalDeliveryOfficeName property in the GUI, change the Dssec.dat value from 7 to 0 and save the change.

Close and reopen the ADUC console and go back to the Properties tab of the Advanced view of the ACL Editor for TestOU. Make sure you select Users in the Apply To field. Scan down the property list until you find Street Address and Office Location.

Select Allow next to Write Office Location and select Deny for Read Street Address and save the change. Acknowledge the warning that Deny takes precedence over Allow permissions by clicking OK.

At this point, the security permissions for TestOU should have two ACEs for the Mailroom_Clerks group, one Deny type for Read Property and one Allow type for Write Property. Notice that the Deny ACE is at the top of the permission list. This is how Deny entries take precedence over Allow entries. There’s a subtlety to this, though, as we’re about to see.

Verifying Effective Permissions
To test the permission settings, log on using credentials of an average test user in the Mailroom_Clerks group at a desktop in the test domain. You won’t be able to log on at a domain controller unless you override the group policy that blocks console logons by non-admins.

At the desktop, open the Windows Address Book (Start | Programs | Accessories) and search for a user in TestOU. In the Business tab, note that most of the fields are dimmed, indicating that you don’t have Write privileges. The Office field should have a white background, though. Make a change and apply it to verify that you have sufficient permissions.

Now select the Address tab. Here you’ll probably get a surprise. The Street value is still displayed. This leads us to the last bit of complexity in assigning permissions.

Back at the domain controller where you’re logged on as an administrator, open the Advanced view of the ACL Editor for the user object you selected in the Windows Address Book. Remember that the Advanced view shows the ACEs in the order used by the system when evaluating access rights. Notice that the Deny you assigned to the Mailroom_Clerks object is sorted below quite a few other entries, including a set of Allow ACEs for the Authenticated Users group (see Figure 3).

Figure 3. The ACL Editor showing inherited Deny ACE under a set of directly applied Allow ACEs. (Click image to view larger version.)

AD permission inheritance has a basic rule. ACEs directly applied to an object always have precedence over ACEs inherited from above at each level in the tree. Because the Allow Read ACEs for Authenticated Users are directly applied to the user object while the Deny Read ACE is inherited from TestOU, the mailroom clerk can still see the Street Address property you tried to hide.

Modifying the Default Security Descriptor
Which brings us, at last, to the Schema. The direct apply ACEs you see in the ACL Editor come from a default security descriptor stored in the Schema object that defines the class. You can view and modify the contents of this default security descriptor using the Schema snap-in. (My thanks to Ron Beekelaar, an official Very Smart Security Guy, for educating me on this feature.)

First, register the Schema snap-in by opening a console prompt, navigating to the %windir%\System32 folder, and typing regsvr32 schmmgmt.dll. Then open an MMC console and use the Add/Remove snap-in option from the Console menu (File menu in Windows Server 2003) to load the AD Schema snap-in. Drill down to the User object under Classes, open the Properties window, and select the Security tab. (In Windows 2003, the tab is more appropriately called Default Security.)

In Win2K, before you can modify the security descriptor, you must set a Registry flag. Do this via the Schema snap-in by right-clicking the AD Schema icon and selecting Operations Master from the context menu. Check the option The Schema May Be Modified On This Domain Controller and click OK. This isn’t required in Windows 2003. In either case, you must be a member of the Schema Admins group.

Now scroll down through the entries under Classes and open the Properties window for the User object. Select the Security tab. Click Advanced then click Add. Add the Mailroom_Clerks group. Select the Properties tab. Set the Apply Onto field to This Object Only. Scroll down the property list and select Deny for Read Street Address.

Click OK to save the change and acknowledge the warning that Deny takes precedence over Allow permissions.

Now go back to the ADUC console and create a new user. Be sure to put values in the Street and Office fields. Verify that the Mailroom_Clerks group appears twice on the new object’s ACL, one for the inherited Allow Write ACE and one direct apply ACE for the Deny Read.

Now go to the desktop where you’re logged on as the mailroom clerk. Search for the new user and verify that you can change the Office entry but you can’t see the Street entry.

Don’t decide simply to remove Authenticated Users completely from the default security descriptor. The accounts need to see many of the control attributes to get logged on and to do other operations in the domain.

Updating Existing Permission Assignments
Once Jeff has a set of permissions in the default security descriptor for User objects that meets his needs, he may want to assign that same security descriptor to one or more users. Assuming that he hasn’t made any direct changes to individual user security permissions, he can use the Dsacls utility from the Support Tools to revert the security descriptor for an object back to the default security descriptor stored in the Schema. The syntax for a User object in an OU named Phoenix in a domain called Company.com would be:

dsacls cn=userobjectname,ou=Phoenix, dc=Company,dc=com /S

Note that Dsacls switches are case-sensitive. The ACL Editor in Windows 2003 has an option to reassign the default security descriptor.

If Jeff has lots of User objects to change, he can use the Dsacls /T (tree) switch on a container, such as an OU, to reset the security descriptor of any object in that container. Use extreme caution with this command. Resetting directly applied security permissions can make someone very unpopular. The /T switch affects objects of all clas-ses, so inspect the container contents carefully prior to using the switch.

All this messing around with security descriptors and Schema settings and inheritance flags may seem like a lot of work just to keep a mailroom clerk from seeing a street address, but once you get the hang of managing access permissions, it isn’t difficult to implement a set of security settings. Just remember: If it were easy, then anyone could do it, and we’d all have to go back to earning an honest living.