Controlling Object Visibility – Deny List Content
A common requirement is to limit what a user or group of users can see in Active Directory. One possible solution is to deny “List contents” on OUs or the root of the domain itself to stop users from displaying possible sensitive information. Keep in mind that this is going to be an explicit deny, accounts that need access to or the ability look-up objects in the domain could be blocked from doing so. Test that your solution’s scope isn't too broad before applying this in a production implementation.
Current Setup
- 3x Windows Server 2012 R2 Servers
- 1x Windows 7 SP 1 Workstation
- 2x Active Directory Forest
Forum Question
Below is a link to a Directory Services forum post on Technet where a user wanted to limit access to Organizational Units, this post aims to help by showing how this can be accomplished in Active Directory step-by-step. This is just one possible solution that some administrators may find useful.
Alternative Solution
An alternative solution would be list object mode, this will be detailed in Controlling Object Visibility – List Object Mode in Active Directory
Test Cases
Case 1
Betty A. Boop, who resides in the Lab.Local domain, needs to be denied access to view the contents of an OU which hold sensitive accounts within her domain. The sensitive OU is the Users OU which is nested under Accounts > !HighTouch > Lab.Local
Case 2
Domain Administrators from the Lab-Forest-2.Local domain need to be denied access to view all the contents of Lab.Local.
Denying List Contents – Intraforest Test Case 1
Using an account with proper privileges, open Active Directory Users and Computers in Lab.Local. Once open, select View
In the View drop down menu select Advanced Features
Right-click the appropriate OU and select properties, in this case it will be the Users OU defined in Case 1
After the properties dialog box of the OU appears select the Security tab
Then select Advanced
On the Advanced properties dialog box select Add
On the Permission Entry dialog box select, Select a Principal
In the text box, enter the object name you want to deny list contents to and then select Check Names
In this example, a previously created group named Deny,HighTouch.Listcontent was created and Betty A. Boop was added as a member.
Enter your group or user name and select Check Names. Once the name is confirmed select OK
Back on the Permission Entry dialog box, scroll down and select Clear All, then scroll back to the top of the dialog box.
On the Type dropdown select Deny, for permissions select List contents. Click OK
At the Advanced Security Settings dialog box select Apply
After selecting Apply, a warning box will appear letting you know that you about to set a deny permission and that it will take priority over allow permissions. To continue, click Yes.
Finally, you’re left with the Properties dialog box of the OU and the Security tab selected. At this point you can check your work to make sure that there is in fact a new entry in the list of group or user names, and that it has a special deny permission set. Once finished click OK to complete the final step.
Testing Denying List Contents – Intraforest Test Case 1
Once the work has been completed, testing needs to take place to insure it’s working as expected. Testing deny list contents is a pretty unexciting task, normally we test and we expect something grand to happen. After this work has been completed and tested, the expected outcome is to see nothing.
To test that everything is working correctly, I’ve logged into a Windows 7 workstation with RSAT installed and the AD DS and AD LDS tools selected.
After logging in, open Active Directory Users and Computers. If everything worked correctly there should be no users visible in the Users OU.
For the second test open PowerShell, Import-Module activedirectory and then try the get-aduser command on a user known to be in the OU that has been denied the List contents
If everything was done correctly you should not be able to see the contents of the OU that has been denied List contents and you should see the error above when using the Get-ADUser command on a user in the same OU.
Denying List Contents – Interforest Test Case 2
For Test Case 1 we denied a group, called Deny,HighTouch,Listcontent and it’s members, the ability to list the contents of a third level OU called Users. In Test Case 2 we’re going to deny Domain Administrators from the Lab-Forest-2.Local access to view all the contents of Lab.Local. The steps involved are almost identical so let’s focus on what’s different by quickly completing the following steps.
Using an account with proper privileges, open Active Directory Users and Computers in Lab.Local. Once open, select View
In the View drop down menu select Advanced Features
Right-click the domain and select properties, in this case it will be Lab.local
After the properties dialog box appears, select Security and then select Advanced
On the Advanced properties dialog box select Add
On the Permission Entry dialog box select, Select a Principal
After the Select User, Computer, Service Account, or Group box appears you need to select Locations.
In the Locations dialog box you need to select the trusted forest and select OK. In this case Lab-Forest-2.Local is selected
Back on the Select User, Computer, Service Account, or Group dialog box you’ll need to select Domain Admins group and then click Check Names. If prompted, enter credentials from the trusted forest to verify the group name. Once completed, select OK.
On the Permission Entry dialog box, scroll down and select Clear All, then scroll back to the top of the dialog box.
On the Type dropdown select Deny, for permissions select List contents. Click OK
As in Test Case 1, at the Advanced Security Settings dialog box select Apply then select OK
Finally, you’re left with the Properties dialog box of the domain and the Security tab selected. At this point you can check your work or if finished, click OK to complete the final step.
Testing Denying List Contents – Interforest Test Case 2
To test that everything is working correctly, I’ve logged into a Windows 2012 R2 server.
After logging in, open Active Directory Users and Computers and connect to the forest your working with, in this case we’re connecting to Lab.Local. The same low dramatic testing applies for Test Case 2 as it did for Test Case 1. If everything worked correctly, there should be nothing displayed.
Conclusion
Active Directory is very flexible out of the box and you can delegate and manage permissions to fit the needs of your organization. However, to many changes, to quickly, untested, and out of proper change control can cause you hours, days, or an eternity of headaches. Always make changes in a controlled setting and never make changes directly to a production AD DS implementation. Remember, this article walks you through setting up a deny rule, this may not be appropriate in all situations. Use deny rules carefully! In some instances they can be very useful.