Yes folks, we’re at the six post for the series on AWS Managed Microsoft AD (AWS Managed AD. I’ve covered a lot of material over the series including an overview, how to setup the service, the directory structure, pre-configured security principals, group policies, and the delegated security model, how to configure LDAPS in the service and the implications of Amazon’s design, and just a few days ago looked at the configuration of the security of the service in regards to protocols and cipher suites. As per usual, I’d highly suggest you take a read through the prior posts in the series before starting on this one.
Today I’m going to look the capabilities within the AWS Managed AD to handle Active Directory schema modifications. If you’ve read my series on Microsoft’s Azure Active Directory Domain Services (AAD DS) you know that the service doesn’t support the schema modifications. This makes Amazon’s service the better offering in an environment where schema modifications to the standard Windows AD schema are a requirement. However, like many capabilities in a managed Windows Active Directory (Windows AD) service, limitations are introduced when compared to a customer-run Windows Active Directory infrastructure.
If you’ve administered an Active Directory environment in a complex enterprise (managing users, groups, and group policies doesn’t count) you’re familiar with the butterflies that accompany the mention of a schema change. Modifying the schema of Active Directory is similar to modifying the DNA of a living being. Sure, you might have wonderful intentions but you may just end up causing the zombie apocalypse. Modifications typically mean lots of application testing of the schema changes in a lower environment and a well documented and disaster recovery plan (you really don’t want to try to recover from a failed schema change or have to back one out).
Given the above, you can see the logic of why a service provider providing a managed Windows AD service wouldn’t want to allow schema changes. However, there very legitimate business justifications for expanding the schema (outside your standard AD/Exchange/Skype upgrades) such as applications that need to store additional data about a security principal or having a business process that would be better facilitated with some additional metadata attached to an employee’s AD user account. This is the market share Amazon is looking to capture.
So how does Amazon provide for this capability in a managed Windows AD forest? Amazon accomplishes it through a very intelligent method of performing such a critical activity. It’s accomplished by submitting an LDIF through the AWS Directory Service console. That’s right folks, you (and probably more so Amazon) doesn’t have to worry about you as the customer having to hold membership in a highly privileged group such as Schema Admins or absolutely butchering a schema change by modifying something you didn’t intend to modify.
Amazon describes three steps to modifying the schema:
Let’s review each of the steps.
In the first step we have to create a LDAP Data Interchange Format (LDIF) file. Think of the LDIF file as a set of instructions to the directory which in this could would be an add or modify to an object class or attribute. I’ll be using a sample LDIF file I grabbed from an Oracle knowledge base article. This schema file will add the attributes of unixUserName, unixGroupName, and unixNameIinfo to the default Active Directory schema.
To complete step one I dumped the contents below into an LDIF file and saved it as schemamod.ldif.
dn: CN=unixUserName, CN=Schema, CN=Configuration, DC=example, DC=com changetype: add attributeID: 1.3.6.1.4.1.42.2.27.5.1.60 attributeSyntax: 2.5.5.3 isSingleValued: TRUE searchFlags: 1 lDAPDisplayName: unixUserName adminDescription: This attribute contains the object's UNIX username objectClass: attributeSchema oMSyntax: 27 dn: CN=unixGroupName, CN=Schema, CN=Configuration, DC=example, DC=com changetype: add attributeID: 1.3.6.1.4.1.42.2.27.5.1.61 attributeSyntax: 2.5.5.3 isSingleValued: TRUE searchFlags: 1 lDAPDisplayName: unixGroupName adminDescription: This attribute contains the object's UNIX groupname objectClass: attributeSchema oMSyntax: 27 dn: changetype: modify add: schemaUpdateNow schemaUpdateNow: 1 - dn: CN=unixNameInfo, CN=Schema, CN=Configuration, DC=example, DC=com changetype: add governsID: 1.3.6.1.4.1.42.2.27.5.2.15 lDAPDisplayName: unixNameInfo adminDescription: Auxiliary class to store UNIX name info in AD mayContain: unixUserName mayContain: unixGroupName objectClass: classSchema objectClassCategory: 3 subClassOf: top
For the step two I logged into the AWS Management Console and navigated to the Directory Service Console. Here we can see my instance AWS Managed AD with the domain name of geekintheweeds.com.
I then clicked hyperlink on my Directory ID which takes me into the console for the geekintheweeds.com instance. Scrolling down shows a menu where a number of operations can be performed. For the purposes of this blog post, we’re going to focus on the Maintenance menu item. Here we the ability to leverage AWS Simple Notification Service (AWS SNS) to create notifications for directory changes such as health changes where a managed Domain Controller goes down. The second section is a pretty neat feature where we can snapshot the Windows AD environment to create a point-in-time copy of the directory we can restore. We’ll see this in action in a few minutes. Lastly, we have the schema extensions section.
Here I clicked the Upload and update schema button and entered selected the LDIF file and added a short description. I then clicked the Update Schema button.
If you know me you know I love to try to break stuff. If you look closely at the LDIF contents I pasted above you’ll notice I didn’t update the file with my domain name. Here the error in the LDIF has been detected and the schema modification was cancelled.
I went through made the necessary modifications to the file and tried again. The LDIF processes through and the console updates to show the schema change has been initialized.
Hitting refresh on the browser window updates the status to show Creating Snapshot. Yes folks Amazon has baked into the schema update process a snapshot of the directory provide a fallback mechanism in the event of your zombie apocalypse. The snapshot creation process will take a while.
While the snapshot process, let’s discuss what Amazon is doing behind the scenes to process the LDIF file. We first saw that it performs some light validation on the LDIF file, it then takes a snapshot of the directory, then applies to the changes to a single domain controller by selecting one as the schema master, removing it from directory replication, and applying the LDIF file using the our favorite old school tool LDIFDE.EXE. Lastly, the domain controller is added back into replication to replicate the changes to the other domain controller and complete the changes. If you’ve been administering Windows AD you’ll know this has appeared recommended best practices for schema updates over the years.
Once the process is complete the console updates to show completion of the schema installation and the creation of the snapshot.
Journey Of The Geek 