Welcome back to my series on AWS Managed Microsoft Active Directory (AD).  In my first post I provided an overview of the service.  In the second post I covered the setup of an AWS Managed Microsoft AD directory instance and demoed the seamless domain-join of a Windows EC2 instance.  I’d recommend you reference back to those posts before you jump into this.  I’ll also be referencing my series on Azure Active Directory Domain Serices (AAD DS), so you may want to take a read through that as well with the understanding it was written in February of 2018 and there may be new features in public preview.

For this post I’m going to cover the directory structure, security principals, group policy objects, and permissions which are created when a new instance of the managed service is spun up.  I’ll be using a combination of PowerShell and the Active Directory-related tools from the Remote Server Administrator Tools.  For those of you who like to dig into the weeds, this will be a post for you.  Shall we dive in?

Let’s start with the basics.  Opening the Active Directory Users and Computers (ADUC) Microsoft Management console (MMC) as the “Admin” account I created during setup displays the directory structure.  Notice that there are three organizational units (OU) that have been created by Amazon.

The AWS Delegated Groups OU contains the groups Amazon has configured that have been granted delegated rights to perform typical administrative activities in the directory.  A number of the activities would have required Domain Admin or Enterprise Admin by default which obviously isn’t an option within a managed service where you want to limit the customer from blowing up AD.  Notice that Amazon has properly scoped each of the groups to allow for potential management from another trusted domain.

The group names speak for themselves but there are a few I want to call out.  The AWS Delegated Administrators group is the most privileged customer group within the service and has been nested into all of the groups except for the AWS Delegated Add Workstations To Domain Users, which makes sense since the AWS Delegated Administrators group has full control over the customer OU as we will see soon.

The AWS Delegated Kerberos Delegation Administrators group allows members to configure account-based Kerberos delegation.  Yes, yes, I know Resource-Based Constrained Delegation is far superior but there may be use cases where the Kerberos library being used doesn’t support it.  Take note that Azure Active Directory Domain Services (AAD DS) doesn’t support account-based Kerberos Constrained Delegation.  This a win for Amazon in regards to flexibility.

Another group which popped out to me was AWS Delegated Sites and Services.  Members of this group allow you to rename the Default-First-Site.  You would do this if you wanted it to match a site within your existing on-premises Windows AD to shave off a few seconds of user authentication by skipping the site discovery process.

The AWS Delegated System Management Administrators grants members full control over the domainFQDN\System\System Management container.  Creation of data in the container is a requirement for applications like Microsoft SCOM and Microsoft SCCM.

There is also the AWS Delegated User Principal Name Suffix Administrators which grants members the ability to create explicit user principal names.  This could pop up as a requirement for something like synchronize to Office 365 where your domain DNS name isn’t publicly routable and you have to go the alternate UPN direction.  Additionally we have the AWS Delegated Enterprise Certificate Authority Administrators which allows for deployment of a Microsoft CA via Active Directory Certificate Services (AD CS) by granting full control over CN=Public Key Services is the Configuration partition.  We’ll see why AD CS is important for AWS Managed Microsoft AD later in the series.  I like the AWS Delegated Deleted Object Lifetime Administrators which grants members the ability to set the lifetime for objects in the Active Directory Recycle Bin.

The next OU we have is the AWS Reserved OU.  As you can imagine, this is Amazon’s support staff’s OU.  Within it we have the built-in Administrator.  Unfortunately Amazon made the same mistake Microsoft did with this account by making it a god account with membership in Domain Admins, Enterprise Admins, and Schema Admins. With the amount of orchestration going into the solution I’d have liked to see those roles either broken up into multiple accounts or no account holding standing membership into such privileged roles via privileged access management system or red forest design.   The AWS Application and Service Delegated Group has a cryptic description (along with typos). I poked around the permissions and see it has write to the ServicePrincipalName attribute of Computer objects within the OU.  Maybe this comes into play with WorkDocs or WorkMail integration?  Lastly we have the AWSAdministrators which has been granted membership into the AWS Delegated Administrators group granting it all the privileges the customer administrator account has.  Best guess is this group is used by Amazon for supporting the customer’s environment.

The last OU we’ll look at is the customer OU which takes on the NetBIOS name of the domain.  This is where the model for this service is similar to the model for AAD DS in that the customer has full control over an OU(s).  There are two OUs created within the OU named Computers and Users.  Amazon has setup the Computers OU and the User OU as the default locations for newly domain-joined computer objects and new user objects.   The only object that is pre-created in these OUs is the customer Admin account which is stored in the Users OU.  Under this OU you are free to do whatever needs doing.  It’s a similar approach as Microsoft took with AAD DS but contained one OU deep vs allowing for creation of new OUs at the base like in AAD DS.

Quickly looking at Sites and Subnets displays a single default site (which can be renamed as I mentioned earlier).  Amazon has defined the entirety of the available private IP address space to account for any network whether it be on-prem or within a VPC.

As for the domain controllers, both domain controllers are running Windows Server 2012 at the forest and domain functional levels of 2012 R2.

Shifting over group policy, Amazon has made some interesting choices and has taken extra steps to further secure the managed domain controllers.  As you can see from the screenshot below, there four custom group policy objects (GPOs) created by default by Amazon.  Before we get into them, let’s first cover the Default Domain Policy (DDP) and Default Domain Controllers Policy (DDCP) GPO.  If you look at the image below, you’ll notice that while the DDCP exists it isn’t linked to the Domain Controllers OU.  This is an interesting choice, and not one that I would have made, but I’d be very curious as to their reasoning for their decision to remove the link.  Best practice would have been to leave it linked but create additional GPOs would override the settings in it with your more/less restrictive settings.  The additional GPOs would be set with a lower link order which would give them precedence over the DDCP.  At least they’re not modifying default GPOs, so that’s something. 🙂

Next up we have the DDP which is straight out of the box minus one change to the setting Network Security: Force logoff when logon hours expire.  By default this setting disabled and Amazon has enabled it to improve security.

The ServerAdmins GPO at the top of the domain has one setting enabled which adds the AWS Delegated Server Administrators to the BUILTIN\Administrators group on all domain-joined machine.  This setting is worth paying attention because it explains the blue icon next to the AWS Reserved OU.  Inheritance has been blocked on that OU probably to avoid the settings in the ServerAdmin GPO being applied to any Computer objects created within it.  The Default Domain Policy has then been directly linked to the OU.

Next up we have the other GPO linked to the AWS Reserved OU named AWS Reserved Policy:User.  The policy itself has a few User-related settings intended to harden the experience for AWS support staff including turning on screensavers and password protecting them and preventing sharing of files within profiles.  Nothing too crazy.

Moving on to the Domain Controllers OU we see that the two policies linked are AWS Managed Active Directory Policy and TimePolicyPDC.  The TimePolicyPDC GPO simply settings the authoritative the NTP settings on the domain controllers such as configuring the DCs to use Amazon NTP servers.  The AWS Managed Active Directory Policy is an interesting one.  It contains all of the policies you’d expect out of the Default Domain Controllers Policy GPO (which makes sense since it isn’t linked) in addition to a bunch of settings hardening the system.  I compared many of the settings to the STIG for Windows Server 2012 / 2012 R2 Domain Controllers and it very closely matches.  If I had to guess that is what Amazon is working with on a baseline which might make sense since Amazon touts the managed service as PCI and HIPAA compliant with a few minor changes on the customer end for password length/history and account lockout.  We’ll cover how those changes are possible in a few minutes.

Compare this to Microsoft’s AAD DS which is straight up defaults with no ability to further harden.  Now I have no idea if that’s in the roadmap for Microsoft or they’re hardening the system in another manner, but I imagine seeing those GPOs that are enforcing required settings will make your auditors that much happier.  Another +1 for Amazon.

So how would a customer harden a password policy or configure account lockout?  If you recall from my blog on AAD DS, the password policy was a nightmare.  There was a zero character required password length making complexity dictate your length (3 characters woohoo!).  If you’re like me the thought of administrators having the ability to set three character passwords on a service that can be exposed to the Internet via their LDAPS Internet endpoint (Did I mention that is a terrible design choice) you have a recipe for disaster.  There was also no way to setup fine grained password policies to correct this poor design decision.

Amazon has taken a much saner and more security sensitive approach.  Recall from earlier there was a group named AWS Delegated Fine Grained Password Policy Administrators.  Yes folks, in addition to Amazon keeping the Default Domain Policy the out of the box defaults (better than nothing), Amazon also gives you the ability to customize five pre-configured fine grained password policies.  With these policies you can set the password and lockout settings that are required by your organization.  A big +1 for Amazon here.

That wraps up this post.  As you can see from this entry Amazon has done a stellar job building security into this managed service, allowing some flexibility for the customer to further harden the systems, all the while still being successful in delegating commonly performed administrative activities back to the customer.

In my next post I’ll walk through the process to configure LDAPS for the service.  It’s a bit funky, so it’s worth an entry.  Once LDAPS is up and running, I’ll follow it up by examining the protocols and cipher suites supported by the managed service.

See you next post!