Summary: Learn how to use Windows PowerShell to explore Active Directory Security settings on objects.

 Hey, Scripting Guy! I have a problem. My boss told me I need to document the access rights for objects that are in Active Directory. I have absolutely no idea how to do this. I open up Active Directory Users and Computers and I do not see anything about security settings. To be honest, I have never modified security on any object in Active Directory in my life—and I have been doing this sort of stuff for nearly a decade. I am too embarrassed to ask my boss (also just a bit scared if the truth be told), so I thought I would give you a shout out. Your blogs have saved my bacon more than once, although this is the first time I have ever written. I know you must get thousands of emails every week, I just hope you will see fit to answer mine. Sitting with my fingers crossed…

—HJ

 Hello HJ,

Microsoft Scripting Guy, Ed Wilson, is here. I am sitting here sipping a cup of green tea with a cinnamon stick in it. Nothing fancy—no gunpowder, no dragons or other exotic creatures in my tea cup, just a simple cup of green tea. Sometimes the simple things in life are worth contemplating. I thought I would jump over and check the scripter@microsoft.com email, and HJ, I ran across your email. First of all, I feel that I should say one should never be embarrassed because one does not know something. I often admit that I do not know something, and I am not embarrassed because the world of computers has exploded in the last decade. No one can be expected to know everything about everything. In fact, I am highly suspicious when I run into someone and they claim to be “an expert on Active Directory” or some other topic. Areas like Active Directory are huge, and are highly complex, and I know people who specialize in very minute areas of Active Directory. I know of only a few people who would qualify as a total expert on all facets of Active Directory.

But I digress…I am going to talk about three ways to find security information on an object in Active Directory. I am going to use an organizational unit named posh.

First, the GUI way

The first way I need to show you is by using the Active Directory Users and Computers MMC. The reason you did not see anything related to security is that by default the security information is hidden. You need to use the View menu and select Advanced from the Action menu. When Advanced is selected, the security tab becomes visible. In addition to revealing additional tabs about objects in Active Directory, it also shows hidden containers and other items that are normally not messed with during day-to-day administration. It is probably a good idea to clear the Advanced option when it is not in use—that is what I do on a normal basis. The image that follows shows the View menu from Active Directory Users and Computers with the Advanced option selected.

Once the Advanced option is selected, the Security tab (and other tabs) appear. One tab that I especially like is the Attribute editor tab because it is like ADSI Edit, and it is convenient having it built into the tool. The Security tab showing security settings for the posh organizational unit is shown in the image that follows.

Using DSACLS

Anyone who needs to do much work with Active Directory, especially in the security arena, should become familiar with DSACLS. DSACLS is a tool that permits viewing and assigning security rights to objects in Active Directory. The syntax is a bit convoluted, but once mastered, it is a very easy tool to use, and it can integrate easily within Windows PowerShell.

Note   For more information about using legacy commands from within Windows PowerShell, see this series of Hey, Scripting Guy! Blogs.

When used with no parameters, DSACLS enters query mode and returns security information. Therefore, to view the security settings on the posh organizational unit, I need to use only the DSACLS command and provide it with the distinguished name of the object. An example of this is shown here.

dsacls "ou=posh,dc=iammred,dc=net"

The command and the associated output are shown in the image that follows.

Using the Active Directory Provider

I have read a lot of blogs bemoaning the fact that there is no cmdlet to get the security settings of an object in Active Directory. By corollary, there would not be a cmdlet to set security either. But there really is! I can use the same cmdlets that I use for the file system, for the registry, and for other items. The cmdlets are Get-ACL and Set-ACL. That’s right, you do not need to learn a new cmdlet. This is the great thing about Windows PowerShell providers—they are extensible.

So the first thing I do is enter a remote Windows PowerShell session to a computer that has the ActiveDirectory module installed. By default it is the domain controllers in my network. I have not installed the RSAT on my computer since I rebuilt it a week or so ago. Upon establishing the remote Windows PowerShell session, I import the Active Directory module, and I set my working location to the Active Directory drive. These commands are shown here.

Enter-PSSession dc3 -Credential iammred\administrator

Import-Module activedirectory

set-location ad:

Now, it is really simple, I use the Get-ACL cmdlet to retrieve the security access settings for my organizational unit. I then pipe the results to the Format-Table cmdlet, and I choose the IdentityReference and the AccessControlType attributes. This is shown here.

(Get-Acl 'ou=posh,dc=iammred,dc=net').access | ft identityreference, accesscontroltype -AutoSize

The commands and the associated output are shown here.

If I do not happen to know the value of the DistinguishedName attribute of the object that I am interested in examining, I can use the Get-ADOrganizationalUnit cmdlet to retrieve the DistinguishedName value for me. An example of this is shown here.

(get-acl (Get-ADOrganizationalUnit -Filter 'name -eq "posh"').distinguishedname).access | ft identityreference, accessControlType –AutoSize

As seen in the image that follows, the results are the same as in the previous command.

Now, this command is getting really hairy, and you may be asking, “Why don’t I just stick to DSACLS?” And of course, you can. But the great thing about using Windows PowerShell is that the commands build, and they also mix and match. Instead of needing to parse text, I can work with objects. One really cool thing to do is to send the output to Out-GridView. But this command does not work in a remote Windows PowerShell session. So to do something like that would require installing the RSAT tools on my local computer or using RDP to connect to the server that has the Active Directory module.

HJ, that is all there is to working with Active Directory security. Join me tomorrow as we once again return to Windows PowerShell Coolsville.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy