Seeing as I don’t have the schema extensions in my test lab, we will step through a similar scenario, but we’ll update the users description property instead.

In this example we have two test users:

We’re interested in the two User properties: Office and Telephone number. These would make up part of the SIP information for LCS, but in our example we just want to add them to the description property for easier viewing in AD User’s and Computers.

Presuming, that we want to update the description field against a large selection of users we will take advantage of how PowerShell handles CSV’s:

set-usrdesc.ps1

A couple of points of interest, from the script above:
The Username is the CN (usually the displayName property), and is added with the ouName provided in the CSV, and the distinguishedName of the domain to build the ADSI binding to the user object.

The get(),put() and setinfo() methods are pretty self explanatory, especially if you’ve done any ADSI scripting before.

What’s nice about PowerShell is that you can user variables “inline”. It doesn’t work when constructing the ADSI binding, but it does when constructing strings (in this case for out put() method).

The (!$?) if block is a nice error checking step that check’s if the the last command wasn’t successful.

The !error[0] if block tests if we have had any errors in our process, and provides feedback to the console accordingly.

Running the script gives us the following output:

And if we check the user account, we can see that the description field has been updated for easy viewing , if we had a lot of users.

Control Access Rights are similar to Standard Rights in the permissions applied, however it is applied to a specific object, or property set. This property is also represented by a system.guid like we have previously seen with Extended Rights.

In this case however the GUID is the schemaIDGUID attribute on the object located in the Schema partition. Provided the Common Name (cn) is known of the object needed the function below will retrieve the GUID in question:
Get-SchemaGUID.ps1

Once we have the GUID for the object or Property Set, we can then start thinking about our ACE. For Control Access Rights there are two types of scenarios, and hence two constructors available. We would use the following constructor when delegating the ability to create and delete computer objects in the computers container, for example.

The ACE can be further controlled by specificing the type of object that may inherit the ACE. In that scenario you would use the following constructor:

As you can see with two GUID’s in the syntax it becomes much easier to get things in the wrong order and in turn get an unexpected result.

MSDN has a clearer description of the constructors, and you can see that the GUID’s are for different objects.

So, armed with the GUID of the object, and the rest of the of our information we can go about setting the Control Access Right.
Set-CAR.ps1

The above example gives the Bella account the rights to link Group Policy objects in the Test OU, and any sub OU’s (due to the inheritances flag).

Now we’ve covered the three types of permissions within the Active Directory, you should be able to apply any combination of permissions you need to organise the delegation model within your environment.

It makes me smile when I think back to the old NT4 days! ;)

[Updated:] The paragraph describing InheritedObjectTypes was rewritten to try and clarify the difference between the constructors.

Extended Rights exists in AD as objects stored within the Extended-Rights container, which is located in the Configuration partition.

If you’re not sure about the different partitions within AD there is an excellent primer on TechNet about AD Architecture.

So how do we set an Extended Right permission? It’s actually very similiar to applying a Standard Rights ACE. The difference comes in the parameters we pass, and hence the constructor we use in the ActiveDirectoryAccessRule method.

In this case the ActiveDirectoryRights value is the keyword “ExtendedRight“, and the system.Guid refers to an attribute of the Extended Rights object called the rightsGUID.

I’ve got a function that takes the CN of the right as input and returns the GUID.

Lookup Extended-Right GUID:
get-erGUID.ps1

If you don’t know the right you’re looking for you have a couple of options. TechNet have a reference that lists them, but we can also look them up.
RightsTbl.ps1

The function above enumerates through the Extended-Rights container and loads the values for the displayName and cn into an associative array (hash table). Now we can look them up by either typing

Which will list our complete hash table, or we can lookup specific translations

So far so good. So putting it all together then. A code block to add the Change PDC right on the domain:
ChangeFSMORight.ps1

Next time we’ll look at our last post in on the topic of Active Directory permissions when we look at Control Access Rights.

There are three types of permissions in regards to Active Directory security: Standard Rights, Extended Rights, and Control Access Rights. We’ve covered Standard Rights in a recent post, and in building up to the remaining two we’ll take a look at Inheritance and Propagation.

Now if we’re dealing with NTFs permissions, we use the System.Security.AccessControl namespace and the Inheritance and Propagation flags.

In AD we use a different method, but the concept is the same. There is only one flag used, and this is ActiveDirectorySecurityInheritance.

For example in NTFS you may have used:

In Active Directory the same result would be achieved by:

An article that explains this subject well can be found on MSDN here. In particular the paragraph on inheritance and figure 5.

If we want to stop permissions being inherited from the parent Organizational Unit or container, you can use the SetAccessRuleprotection method. The syntax for which is available here
And a simple example:
BlockInheritance.ps1

In the next post we’ll build a couple of useful functions for retrieving data needed for Extended and Access Control Rights.

Below is our function:
remove-DSace.ps1

Points of interest then:
Details on the parameters for GetAccessRules are here. We then filter our rules to those that match our Group/Account as defined by the IdentityReference attribute on the object, and store these in the $rar variable. By testing if this variable is an array or not we can determine if we have one ACE or several that need removing.

Using an If..Else code block we remove the ACE or ACEs as applicable and commit our changes back to the directory. If the ACE was configured to propagate down the directory this will have the effect of completely removing that permission from everywhere.

Tomorrow we really will look into Propagation and Inheritence ;)

Marc covered this topic on his old blog, while PowerShell was still in beta (Pre RC2). The approach is basically the same, but you need to utilise psbase in PowerShell 1.0.

So, we want to give our test user bella full control over the Test OU. I would suggest not making permission changes to your AD if you don’t know what you’re doing because things can get nasty very quickly. A bit of useful reading on the subject can be found here and here.

Below is our basic function:
function add-DSace.ps1

Okay, so points of interest then:

Once we’ve created a variable for the OU we want to add an ACE to, we then define our Security Principal. This can be either a user or a group, and we can present this in either SID format or as the account name.

In this example we’re targeting a user. We could have validated the account by retrieving it’s SID, but for this we’re presuming that everything exists and no checking is performed.

There are several constructors available for the ActiveDirectoryAccessRule. You can see what’s available, by looking at the constructors:

I’ve found this to be a really useful way of discovering the specific requirements for a method. Once you know what types the method is expecting you can then investigate what each element is. In this instance we are utilising the following constructor:

You can then either look them up on MSDN or feed in some false data, and see if the constructor will provide you with details on what it needs.

Once we have the ACE, the last two lines are where we add the ACE to the Security Descriptor and then commit our changes back to the directory.

As you can see we need to use psbase. This gives us the “raw” view of the object. I find using psbase very difficult. It’s almost a fall back, for when you can’t seem to make it work any other way. At the moment I just put it down as one of PowerShell’s little quirks ;)

Over the next few days we’ll take a closer look at Propagation, Inheritance and Active Directory Extended Rights.

I’m in the process of sorting them out, and will be posting them up there in the next 24 hours or so. For those that aren’t a member, I’ve created a Code Sample page in the sidebar where I’ll post them also.

They come with the usual all care, no responsibility tag line. I hope you find them of some use!

Next week John and Sally have a two day seminar on in London. Here is the link on the UK TechNet Events website. I know it’s a little late, and there may not be any places left, but I can tell you without doubt it will be a great two days.

A few years ago I was working on an AD project for a large environment and at the time I was struggling to achieve some of the automation mile stones. After several weeks of scouring the web and news groups I completed all my tasks. Just after this I got a copy of John and Sally’s book. The pound to page ratio on this is quite high, but what I found within was all the obscure answers for the problems I’d spent weeks searching for.

Now before you ask, I’m not affiliated with these guys in any way, and am not being paid for this. These guys are just good, and well worth a look if AD is in any way your thing ;)

Since we’ve looked at searching the Directory yesterday, this seems like a good time to take a closer look into this.
Microsoft have a good article here on what features are available depending on you functionality level.

So we’d start with:

And presuming our DC’s are located in the default location, we can narrow our search down:

The key to our search is going to be the filter() that we use. If you look around there’s a few different ways of identifying what we might want to search on.

In KB article 322692 there is a good filter for finding NT4 Domain Controllers:

Here we’re filtering on the computer object, the OS version, and the UAC value. Let’s break this down a bit more. The first one is pretty obvious, the OS version is easy enough too. Anything with a 4 in the version relates to NT4. Windows 2000 is 5.0, and Windows 2003 is 5.2. So what’s with the UAC filter? The bitwise filter is an Object ID (OID) that means all the flags have to be set for a match. The value of 8192 specifies that the account is a Domain Controller.

We can search for Windows 2000 Domain Controllers using the following filter, as described in KB article 325379

Similar to the above example, we’re filtering on the computer object again. This time rather than use the UAC approach though we’ve used the PrimaryGroupID which we’ve touched on previously. The OS version corresponds to the versions discussed above.

It seems to me that our best approach would be to filter on any computer account, that’s not Windows 2003. As we’re only searching in the Domain Controllers OU we shouldn’t need to try and check the UAC or Primary Group information, but you could just to be sure if you felt that way inclined.

There’s a subtle difference between this filter and the first example. Basically we’re looking for OS version that’s not (!) equal to Windows 2003. In theory this should give us all the other Domain Controllers ;)

So to finish off then:

Of course just because we have accounts in AD doesn’t actually mean that there are machines still out there. You could tie this into a function that then calls a ping test against the names that are retrieved. That’s still not gospel, but if it’s a DC, it’s more likely to be up if it’s still out there!

If you’re new to LDAP queries and would like more information Microsoft have a good primer here.

The easy solution to this is to have enough information to hand, to allow a quick rummage through the Directory, and let the script
retrieve the details it needs. In fact being able to extract information from an AD search is pretty much the corner stone of any AD scripting tool box, as you’ll see over the next couple of posts.

I’ll show you a couple of ways of searching and then mention a few points to be aware of regarding performance, and your impact on the servers whose workload you’re adding to.

There isn’t a lot of specific PowerShell code in the function above. Its pretty LDAP orientated. We have a simple function that returns you the distinguishedName of an object when you provide the objectClass and cn.
So to find the DN of my test user account:

The $result variable is a System.DirectoryServices.SearchResult which we cast into System.DirectoryServices.DirectoryEntry with the GetDirectoryEntry() method. I like this as it gives us a much nicer way of retrieving the objects properties.

The other method of searching AD I have seen, is similar, but with a PS slant to it:

Straight away you can see some PowerShell in the function above. Rather then use the $query.filter, we pipe the results into a where-object and then filter for our search criteria. We also handle the properties returned differently.

This function would be called exactly the same as our previous example:

Now I’ve had problems with this function. I’ve found it worked fine for “some” objects, but I have had trouble retrieving others. Despite the SearchScope being set to “SubTree” I’ve had it fail to retrieve objects that are a few OU’s deep. I suspect this is a flaw with my function as apposed to anything flawed in PS ;)

Search Tips
So now we’ve seen the basics, I thought it worth mentioning a couple of ways to improve on performance, and speed:

[1] Scope: If you can, narrow your SearchScope. There’s three options: “Base”, “OneLevel”, and “SubTree”. If you’re not sure, there’s a good explanation on MSDN here.

[2] Filter: Always try and provide a filter to reduce how much data you’re trying to retrieve. There’s obviously not much point retrieving every user account in your domain and enumerating through them all just for the one you want. Think about the Filter() method, and use the relevant FindOne() FindAll() methods.

I’m not sure how our second examples works with this. My hunch is that it retrieves ALL the objects and trawls through each with the where-object. I could be wrong here of course ;)

[3] Properties: If you’re only after say, the distinguishedName it would be a good idea to reduce the properties returned by using the PropertiesToLoad method.

The Microsoft Scripting Guy’s, have an example here