Summary: Guest blogger, Andy Schneider, discusses extending the Active Directory schema.
Microsoft Scripting Guy, Ed Wilson, is here. We welcome back guest blogger, Andy Schneider. Andy has a two-part blog series that will conclude tomorrow.
Andy Schneider is the Identity and Access Management Architect for IT Services at Avanade. His team’s job is to ensure that the right people can access the right things at the right time. Andy is very passionate about automation and the DevOps movement. He is a huge fan of Windows PowerShell, and he has been using it since it was first released as Monad. Andy’s personal blog is Get-PowerShell, and his twitter handle is @andys146.
This is the first post in a two-part series that walks through some information about the Active Directory Schema and Windows PowerShell. This post provides a short overview of what the schema is and then goes into some details about how we can use Windows PowerShell to look at the schema. Tomorrow, I will walk through the process of adding custom classes and attributes to the schema with pure Windows PowerShell code.
Many Active Directory administrators are often fearful of doing anything that requires changes to the schema in Active Directory. However, if you have been administering Active Directory for any length of time, you have probably had to extend the schema for at least one or two software installations or upgrades—for example, installing Exchange or Lync, or upgrading domain controllers to a new operating system.
However, the practice of adding custom extensions that only your company would use is often frowned upon. The fact is that with good planning and understanding, extending the schema is actually pretty straightforward and should not induce a great amount of fear. There is a great article written by Brian Desmond that addresses this issue and goes into detail about planning for and designing schema extensions: Extending the Active Directory Schema.
I think one of the biggest concerns with schema extensions is that they cannot be removed. In IT, you always need to know when you are driving down a one-way street and cannot turn back. Schema extensions are a one-way street.
However, it is actually possible to disable an extension. You can set the isDefunct property on a schema object to True, and the class that had the attribute will no longer be able to use it. For more information, see Deactivating Schema Objects.
As with anything in IT, it is always good to have solid backup and restore plans for your Active Directory environment. Also, always test your changes in a development or test environment before you go hacking around in your production Active Directory environment.
With that background, let’s get going...
The Active Directory schema consists of two major categories: classes and attributes. This is very similar to the objects that we know and love in Windows PowerShell. An object in Windows PowerShell is based on a class, and that class has certain properties. Similarly, Active Directory has classes, and these classes have attributes.
Two very common classes in Active Directory are the user and computer classes. The user class has a bunch of attributes that you have probably seen, such as samAccountName, userAccountControl, sn, and givenName. If you use the Get-ADUser cmdlet and specify –properties *, you can see all the attributes on the returned users. These properties refer to the attributes of the user class.
Let’s do a little spelunking around Active Directory and see what we can come up with in regards to dealing with the schema.
By using the Get-ADRootDSE cmdlet, we can find all kinds of cool information about our Active Directory environment. It turns out that one of those properties is called SchemaNamingContext.
This looks promising. There is no Get-ADSchema cmdlet, but there is a generic Get-ADObject cmdlet, which can get any kind of object we want from Active Directory. We simply need to provide the correct path to search for objects. If we set the SearchBase to the SchemaNamingContext distinguished name, we can get the following:
Like Get-ADUser, Get-ADObject does not return all the properties by default. You have to specify them. When we do this, we find all kinds of goodies in these objects. Let’s look for the user class object. You can try this out with the following code:
$schemaPath = (Get-ADRootDSE).schemaNamingContext
Get-ADObject -filter * -SearchBase $schemaPath -Properties * | where Name -like "user"
There are a lot of properties here that we can look at and see what’s going on. In the next post, I will take a look at which of these properties are necessary to create custom attributes.
Thanks Andy, I'm looking forward to Part 2 tomorrow.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at firstname.lastname@example.org, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy