Tech Line
AD May I? No!
So you don’t want your users to read all of your Active Directory attributes. Here’s how to stop them.
Chris: We saw your article, "
AD Your Way," and are considering implementing it, but we have security concerns. Since anyone can read ADSIEdit, anyone can find the path where the .vbs file is suppose to reside. Thus, anyone could put a malicious .vbs file in the correct location. Of course, machines which actually have the .vbs file can be locked down such that the .vbs file cannot be replaced; however, on machines without the .vbs file or a blank placeholder file, a malicious one can be put in place.
We have discussed this and, true, it is a bit of a stretch when one considers the long route a malicious person would have to take to use this vulnerability and it seems that if a malicious person did obtain access to a machine, there would be a number of other routes he/she would take before this one.
Do you have any suggestions or comments concerning the possible vulnerability or ways to mitigate the danger?
— Mark
Mark: Actually you've just foiled my plan for world domination. Now I have to start all over again! Seriously, this is an excellent question. Since I started writing this column a couple of months ago, one thing that I quickly realized is that nothing gets by all of you readers.
In my last column, I described how to tweak the AD schema to provide support for editing the employeeID attribute of a user object in Active Directory Users and Computers. This process involved modifying the user-Display object in the Active Directory schema. In short time, alert readers like Mark pointed out the drawbacks to this approach. Giving users Read-only access to the Active Directory database is needed to support user queries to the database, which is used by many applications today. However, users don’t need to see everything either.
This is why the granularity of Active Directory permissions is really helpful. If you want to prevent users from reading the user-Display object with ADSIEdit, you can change its default permissions. In a simple test, I removed the Authenticated Users group from the user-Display object’s ACL. This created an implicit deny for all users that are not a part of the Domain Admins or Enterprise Admins user groups. By default, Domain Admins, Enterprise Admins, the System group, and Authenticated Users are on the user-Display object’s ACL. Authenticated Users are assigned read permission.
Tech Help—Just An
E-Mail Away |
|
Got a Windows, Exchange or virtualization question
or need troubleshooting help? Or maybe you want a better
explanation than provided in the manuals? Describe
your dilemma in an e-mail to the MCPmag.com editors
at mailto:[email protected];
the best questions get answered in this column and garner
the questioner with a nifty MCPmag.com baseball-style
cap.
When you send your questions, please include your
full first and last name, location, certifications (if
any) with your message. (If you prefer to remain anonymous,
specify this in your message, but submit the requested
information for verification purposes.)
|
|
|
If you create the implicit deny for Authenticated Users, you’ll see the following results:
- Users will still be able to query the AD as normal, such as by using the Address Book tool.
- Users will no longer be able to read the attributes of user-Display using ADSI edit, thus no longer allowing them to see the script location mentioned in my last column.
- If a normal user (not a member of Domain Admins or Enterprise Admins) attempts to right-click a user object in Active Directory Users and Computers, no Active Directory-specific actions will be listed in the context menu, except for Properties. If the user attempts to view another user object’s properties, he will only see the Terminal Services-related properties.
Just in case you’re finding yourself in one of those “What is he talking about?” moments, here are the steps I used to change the default permissions of the DisplaySpecifiers user-Display object using ADSIEdit:
- Install the Windows Server 2003 support tools. This will give you access to ADSIEdit.
- Click Start | Run, then type “adsiedit.msc” in the Run dialog box and click OK.
- In the ADSI Edit MMC, expand the Configuration node to CN=Configuration,<Domain>,CN=DisplaySpecifiers,CN=409. Note that your domain will be a part of the CN=Configuration path. For example, I needed to navigate past CN=Configuration,DC=MCPMag,DC=com.
- With the CN=409 DisplaySpecifier selected, right-click on the “CN=user-Display” object in the right pane of the MMC and select Properties.
- In the CN=user-Display Properties dialog box, click the Security tab.
- Click the Authenticated Users group object and then click Remove.
- Click OK to close the CN=user-Display Properties dialog box and apply the changes.
- Close ADSIEdit.
If you’re interested in reading more about DisplaySpecifiers, take a look at the TechNet article, "Step-by-Step Guide to Using Active Directory Schema and Display Specifiers." Now if I can only turn off some of my own personal DisplaySpecifiers… Then I wouldn’t see the five cars in my neighbor’s driveway!
[Chris Wolf has just released Virtualization:
From the Desktop to the Enterprise (Apress) and also welcomes your virtualization
questions for this column. —Editors]