So this seemed like a good time fix that …

We need to bind to some objects in AD, starting with the Users OU, and a fictional OU for our example, Service Accounts where we will move our objects to.

Now that we have bindings to the directory locations, we need to bind to an account we’d like to move.

The actually moving of an object isn’t made available through the PowerShell wrapper from what I could see. So to achieve this we need to expose the raw .Net methods using psbase.

I already knew the name of the method we’d need to use MoveTo(), so we used a where-object cmdlet to reduce our output to just what we needed. Looking at the above method, we can see that we can also rename the object by passing a second set of parameters.

Having bound to the Service Accounts OU, and the Administrator account, the only thing left to do is the actual move:

Something to bear in mind if we want to rename an object, is that we could pass the same DirectoryEntry location as the object current exists in, or a new location. This method won’t update the sAMAccountName attribute.

If you want to change attributes on an object, it’s worth doing this before the move, and the binding becomes invalid. In our example of renaming the account, there’s a couple of attributes worth changing:

Renaming, the Administrator account, and keeping it in the Users container:

Renaming the Administrator account, and moving it to our Service Accounts OU:

Alternatively, you could use the Quest AD cmdlets to move or rename. Sometimes, however you don’t always have the tools available that you might like!

This issue occurs because of the permissions that are set in the Active Directory directory service….
The members of the DnsAdmins group do not have permissions on the following application partitions:
CN=MicrosoftDNS,DC=ForestDNSZones,DC=Domain…
CN=MicrosoftDNS,DC=DomainDNSZones,DC=Domain…

The documented solution is to edit your Active Directory with ADSIEdit and go in to fix the problem:

To resolve this issue, set permissions for the DnsAdmins group on the DomainDNSZones application partition and on the ForestDNSZones application partition.

We have taken a pretty close look at manipulating permissions in AD with PowerShell before, covering:
Standard Rights
Removing Rights in AD
Inheritance and Propagation
Extended Rights
and Controlling Access Rights in AD

We’re going to build a function similar to Add-DsAce.ps1 we used in the Standard Rights post, but this time we’re going to use a slightly different constructor, so that we can apply the correct inheritance. We want this to affect “This object and all Child Objects”, which means we need to use:

So, our modified function looks like this:
Add-DsAce2.ps1

Now that we have the ability to modify the AD, and presuming we dot source the newly created function we could do the following:

Basically, we’ve bound to AD via ADSI so that we can dynamically provide the domain DN, and the two locations in AD we want to apply the ACE to. Then it’s just a matter of passing the created function the parameters needed.

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.

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.