The chronicles of a Bostonian tech geek navigating through life, technology, and general geekiness.

Menu

Tag Archives: security

I’ve been busy over the past month nerding out on some pet projects. I thought it would be fun to share one of those pet projects with you. If you had a chance to check out my last series, I walked through my first Python experiment which was to write a re-usable tool that could be used to pull data from Microsoft’s Graph API (Microsoft Graph).

For those of you unfamiliar with Microsoft Graph, it’s the Restful API (application programming interface) that is used to interact with Microsoft cloud offerings such as Office 365 and Azure. You’ve probably been interacting with it without even knowing it if through the many PowerShell modules Microsoft has released to programmatically interact with those services.

One of the many resources which can be accessed through Microsoft Graph are Azure AD (Active Directory) security and audit reports. If you’re using Office 365, Microsoft Azure, or simply Azure AD as an identity platform for SSO (single sign-on) to third-party applications like SalesForce, these reports provide critical security data. You’re going to want to capture them, store them, and analyze them. You’re also going to have to account for the window that Microsoft makes these logs available.

The challenge is they are not available via the means logs have traditionally been captured on-premises by using syslogd, installing an SIEM agent, or even Windows Event Log Forwarding. Instead you’ll need to take a step forward in evolving the way you’re used to doing things. This is what moving to the cloud is all about.

Microsoft allows you to download the logs manually via the Azure Portal GUI (graphical user interface) or capture them by programmatically interacting with Microsoft Graph. While the former option may work for ad-hoc use cases, it doesn’t scale. Instead we’ll explore the latter method.

If you have an existing enterprise-class SIEM (Security Information and Event Management) solution such as Splunk, you’ll have an out of box integration. However, what if you don’t have such a platform, your organization isn’t yet ready to let that platform reach out over the Internet, or you’re interested in doing this for a personal Office 365 subscription? I fell into the last category and decided it would be an excellent use case to get some experience with Python, Microsoft Graph, and take advantage of some of the data services offered by AWS (Amazon Web Services). This is the use case and solution I’m going to cover in this post.

Last year I had a great opportunity to dig into operational and security logs to extract useful data to address some business problems. It was my first real opportunity to examine large amounts of data and to create different visualizations of that data to extract useful trends about user and application behavior. I enjoyed the hell out of it and thought it would be fun to experiment with my own data.

I decided that my first use case would be Office 365 security logs. As I covered in my last series my wife’s Office 365 account was hacked. The damage was minor as she doesn’t use the account for much beyond some crafting sites (she’s a master crocheter as you can see from the crazy awesome Pennywise The Clown she made me for Christmas).

The first step in the process was determining an architecture for the solution. I gave myself a few requirements:

The solution must not be dependent on my home lab infrastructure

Storage for the logs must be cheap and readily available

The credentials used in my Python code needs to be properly secured

The solution must be automated and notify me of failures

The data needs to be available in a form that it can be examined with an analytics solution

Based upon the requirements I decided to go the serverless (don’t hate me for using that tech buzzword 🙂 ) route. My decisions were:

AWS Lambda would run my code

Amazon CloudWatch Events would be used to trigger the Lambda once a day to download the last 24 hours of logs

Amazon Athena would hold the schema for the logs and make the data queryable via SQL

Amazon QuickSight would be used to visualize the data by querying Amazon Athena

The high level architecture is pictured below.

I had never done a Lambda before so I spent a few days looking at some examples and doing the typical Hello World that we all do when we’re learning something new. From there I took the framework of Python code I put together for general purpose queries to the Microsoft Graph, and adapted it into two Lambdas. One Lambda would pull Sign-In logs while the other would pull Audit Logs. I also wanted a repeatable way to provision the Lambdas to share with others and get some CloudFormation practice and brush up on my very dusty Bash scripting. The results are located here in one of my Github repos.

I’m going to stop here for this post because we’ve covered a fair amount of material. Hopefully after reading this post you understand that you have to take a new tact with getting logs for cloud-based services such as Azure AD. Thankfully the cloud has brought us a whole new toolset we can use to automate the extraction and storage of those logs in a simple and secure manner.

In my next post I’ll walk through how I used Athena and QuickSight to put together some neat dashboards to satisfy my nerdy interests and get better insight into what’s happening on a daily basis with my Office 365 subscription.

Over the past year I’ve done deep dives into both Amazon’s AWS Managed Microsoft Active Directory and Microsoft’s Azure Active Directory Domain Services. These services represent each vendor’s offering of a managed Windows Active Directory (AD) service. I extensively covered the benefits of a service over the course of the posts, so today I’m going to cover the key features of each service. I’m also going to include two tables. One table will outline the differences in general features while the other outlines the differences in security-related features.

Let’s hit on the key points first.

Amazon provides a legacy (Windows AD is legacy folks) managed service while Microsoft provides a modernized service (Azure AD) which has been been integrated with a legacy service.

Microsoft synchronizes users, passwords hashes, and groups from the Azure AD to a managed instance of Windows Active Directory. The reliance on this synchronization means the customer has to be comfortable synchronizing both directory data and password hashes to Azure AD. Amazon does not require any data be synchronized.

Amazon provides the capability to leverage the identities in the managed instance of Windows AD or in a forest that has a trust with the managed instance to be leveraged in managing AWS resources. In this instance Amazon is taking a legacy service and enabling it for management of the modern cloud management plane.

The pricing model for the services differs where Amazon bills on a per domain controller basis while Microsoft bills on the number of objects in the directory.

Amazon’s service is eligible to be used in solutions that require PCI DSS Level 1 or HIPAA.

Both services use a delegated model where the customer has full control over an OU rather the directory itself. Highly privileged roles such as Schema Admin, Enterprise Admins, and Domain Admins are maintained by the cloud provider.

Both services provide LDAP for legacy applications customers may be trying to lift and shift. Microsoft limits LDAP to read operations while Amazon supports both read and write operations.

Both services do not allow the customer to modify the Default Domain Policy or Default Domain Controller Policies. This means the customer cannot modify the password or lockout policy applied to the domain. Amazon provides a method of enforcing custom password and lockout policies through Fine Grained Password Policies. Additionally, the customer does not have the ability to harden the OS of the domain controllers for either service so it is important to review the vendor documentation.

Well folks that sums it up. As you can see from both of the series as well as this summary post both vendors have taken very different approaches in providing the service. It will be interesting to see how these offerings evolve over the next few years. As much as we’d love to see Windows Active Directory go away, it will still be here for years to come.

Welcome back fellow geek. Today I’m continuing my deep dive series into AWS Managed Microsoft AD. This will represent the seventh post in the series and I’ve covered some great content over the series including:

Today I’m going cover three additional capabilities of AWS Managed Microsoft AD which includes the creation of trusts, access to the Domain Controller event logs, and scalability.

I’ll first cover the capabilities around Active Directory trusts. Providing this capability opens up the possibility a number of scenarios that aren’t possible in managed Windows Active Directory (Windows AD) services that don’t support trusts such as Microsoft’s Azure Active Directory Domain Services. Some of the scenarios that pop up in my head are resource forest, trusts with trusted partners to maintain collaboration for legacy applications (applications dependent on legacy protocols such as Kerberos/NTLM/LDAP), trusts between development, QA, and production forests, and the usage of features features such as selective authentication to mitigate the risk to on-premises infrastructure.

For many organizations, modernization of an entire application catalog isn’t feasible but those organizations still want to take advantage of the cost and security benefits of cloud services. This is where AWS Managed Microsoft AD can really shine. It’s capability to support Active Directory forests trusts opens up the opportunity for those organizations to extend their identity boundary to the cloud while supporting legacy infrastructure. Existing on-premises core infrastructure services such as PKI and SIEM can continue to be used and even extended to monitor the infrastructure using the managed Windows AD.

As you can see this is an extremely powerful capability and makes the service a good for almost every Windows AD scenario. So that’s all well and good, but if you wanted marketing material you’d be reading the official documentation right? You came here for the deep dive, so let’s get into it.

The first thing that popped into my mind was the question as to how Amazon would be providing this capability in a managed service model. Creating a forest trust typically requires membership in privileged groups such as Enterprise Admins and Domain Admins, which obviously isn’t possible in a manged service. I’m sure it’s possible to delegate the creation of Active Directory trusts and DNS conditional forwarders with modifications of directory permissions and possibly user rights, but there’s a better way. What is this better way you may be asking yourself? Perhaps serving it up via the Directory Services console in the same way schema modifications are served up?

Let’s walk through the process of setting up an Active Directory forest trust with a customer-managed traditional implementation of Windows Active Directory and an instance of AWS Managed Microsoft AD. For this I’ll be leveraging my home Hyper-V lab. I’m actually in the process of rebuilding it so there isn’t much there right now. The home lab consists of two virtual machines, one named JOG-DC running Windows Server 2016 and functions as a domain controller (AD DS) and certificate authority (AD CS) for the journeyofthegeek.com Active Directory forest. The other virtual machine is named named JOG-CLIENT, runs Windows 10, and is joined to the journeyofthegeek.com domain. I’ve connected my VPC with my home lab using AWS’s Managed VPN to setup a site-to-site IPSec VPN connection with my local pfSense box.

Prior to setting up the trusts there are a few preparatory steps that need to be completed. The steps will be familiar to those of you who have established forests trusts across firewalled network segments. At a high level, you’ll want to perform the following tasks:

For the first step I played it lazy since this is is a temporary configuration (please don’t do this in production). I allowed all traffic from the VPC address range to my lab environment by modifying the firewall rules on my pfSense box. On the AWS side I needed to adjust the traffic rules for the security group SERVER01 is in as well as the security group for the managed domain controllers.

To establish DNS resolution between the two forests I’ll be using conditional forwarders setup within each forest. Setting the conditional forwarders up in the journeyofthegeek.com forest means I have to locate the IP addresses of the managed domain controllers in AWS. There are a few ways you could do it, but I went to the AWS Directory Services Console and selected the geekintheweeds.com directory.

On the Directory details section of the console the DNS addresses list the IP addresses the domain controllers are using.

After creating the conditional forwarder in the DNS Management MMC in the journeyofthegeek.com forest, DNS resolution of a domain controller from geekintheweeds.com was successful.

I next created the trust in the journeyofthegeek.com domain ensuring to select the option to create the trust in this domain only and recording the trust password using the Active Directory Domains and Trusts. We can’t create the trusts in both domains since we don’t have an account with the appropriate privileges in the AWS managed domain.

Next up I bounced back over to the Directory Services console and selected the geekintheweeds.com directory. From there I selected the Network & security tab to open the menu needed to create the trust.

From here I clicked the Add trust relationship button which brings up the Add a trust relationship menu. Here I filled in the name of the domain I want to establish the trust with, the trust password I setup in the journeyofthegeek.com domain, select a two-way trust, and add an IP that will be used within configuration of the conditional forwarder setup by the managed service.

After clicking the Add button the status of the trust is updated to Creating.

The process takes a few minutes after which the status reports as verified.

Opening up the Active Directory Users and Computers (ADUC) MMC in the journeyofthegeek.com domain and selecting the geekintheweeds.com domain successfully displays the directory structure. Trying the opposite in the geekintheweeds.com domain works correctly as well. So our two-way trust has been created successfully. We would now have the ability to setup any of the scenarios I talked about earlier in the post including a resource forest or leveraging the managed domain as a primary Windows AD service for on-premises infrastructure.

The second capability I want to briefly touch on is the ability to view the Security Event Log and DNS Server logs on the managed domain controllers. Unlike Microsoft’s managed Windows AD service, Amazon provides ongoing access to the Security Event Log and DNS Server Log. The logs can be viewed using the Event Log MMC from a domain-joined machine or programmatically with PowerShell. The group policy assigned to the Domain Controllers OU enforces a maximum event log size of 256MB but Amazon also archives a year’s worth of logs which can be requested in the event of an incident. The lack of this capability was a big sore spot for me when I looked at Azure Active Directory Domain Services. It’s great to see Amazon has identified this critical use case.

Last but definitely not least, let’s quickly cover the scalability of the service. Follow Microsoft best practices and you can take full advantage of scaling horizontally with the click of a single button. Be aware that the service only scales horizontally and not vertically. If you have applications that don’t follow best practices and point to specific domain controllers or perform extremely inefficient LDAP queries (yes I’m talking to you developers who perform searches using front and rear-facing wildcards and use LDAP_MATCHING_RULE_IN_CHAIN filters) horizontal scaling isn’t going to help you.

Well folks that rounds out this entry into the series. As we saw in the post Amazon has added key capabilities that Microsoft’s managed service is missing right now. This makes AWS Managed Microsoft AD the more versatile of the two services and more than likely a better fit in almost any scenario where there is a reliance on Windows AD.

In my final posts of the series I’ll provide a comparison chart showing the differing capabilities of both AWS and Microsoft’s services.

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.

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.

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.

You didn’t think I was done with AWS Managed Microsoft AD yet did you? In this post I’m going to perform some tests to evaluate the protocols and ciphers suites available for LDAPS as well as checking out the managed Domain Controllers support for NTLMv1 and the cipher suites supported for Kerberos. I’ll be using the same testing mechanisms I used when for my series on Microsoft Azure Active Directory Domain Services.

For those of you who are new to the series, I’ve been performing a deep dive review of AWS Managed Microsoft AD which is Amazon’s answer to a managed Windows Active Directory service. In the first post I provided a high level overview of the service, in the second post I covered the setup of the service, the third post reviewed the directory structure, pre-configured security principals and group policies, and the delegated security model, and in the fourth entry I delved into how Amazon has managed to delegate configuration of LDAPS and the requirements that pop up due to their design choices. I highly recommend you review those posts as well as my series on Microsoft Azure AD Domain Services if you’d like to compare the two services.

I’ve made a modification to my lab and have added another server named SERVER02 which will be running Linux. The updated Visio looks like this.

Server01 has been configured with the Windows Remote Server Administration Tools (RSAT) for Active Directory as well as holding the Active Directory Certificate Services (AD CS) role and being configured as a root Enterprise CA. I’ve also done all the necessary configuration to distribute the certificates to the managed domain controllers and have successfully tested LDAPS. Server02 will be used to test SSLv3 and NTLM. I’ve modified the instance to use the domain controllers as DNS servers by overriding DHCP settings as outlined in this article.

The first thing I’m going to do is test to see if SSLv3 has been disabled on the managed domain controllers. Recall that the managed Domain Controllers are running Windows Server 2012 R2 which has SSLv3 enabled by default. It can be disabled by modifying the registry as documented here. Believe it or not you can connect to the managed domain controllers registry via a remote registry connection. Checking the registry location shows that the SSLv3 node hasn’t been created which is indicative of SSLv3 still being enabled.

To be sure I checked it using the same method that I used in my Azure AD Domain Services post which is essentially compiling another version of openssh that supports SSLv3. After the customized version was installed and I queried the Domain Controller over port 636 which you can see in the screenshot below that SSLv3 is still enabled. Suffice to say this surprised me considering what I had seen so far in regards to the security of the service. This will be a show stopper for some organizations in adopting the service especially since it isn’t configurable by the customer that I observed.

So SSLv3 is enabled and presents a risk. Have the cipher suites been hardened? For this I’ll again use a tool developed by Thomas Pornin. The options I’m using perform an exhaustive search across the typically offered cipher suites, space the connections out by 1 second, and start with a minimum of sslv3.

The results are what I expected and mimic the results I saw when testing Azure AD Domain Services, minus the support for SSLv3 which Microsoft has disabled in their managed offering. The supported cipher suites look to be the out of the box defaults for Server 2012 R2 and include RC4 and 3DES which are ciphers with known vulnerabilities. The inability to disallow the ciphers might again be a show stopper for organizations with strict security requirements.

The Kerberos protocol is a critical component of Windows Active Directory providing the glue to hold the service together including (but in no way exhaustive) being behind the users authentication to a domain-joined machine, the single sign-on experience, and the ability to form trusts with other forests. Given the importance of the protocol, it’s important to ensure its backed by strong ciphers. The ciphers supported by a Windows Active Directory are configurable and can be checked by looking at the msDS-SupportedEncryptionTypes attribute of a domain controller object.

I next pulled up a domain controller object in ADUC and reviewed the attribute. The attribute on the managed domain controllers has a value of 28, which is the default for Windows Server 2012 R2. The value translates to support of the following cipher suites:

RC4_HMAC_MD5

AES128_CTS_HMAC_SHA1

AES256_CTS_HMAC_SHA1_96

These are the same cipher suites supported by Microsoft’s Azure AD Domain Services service. In this case both vendors have left the configuration to the defaults.

Lastly, to emulate my testing Azure AD Domain Services, I tested support for NTLMv1. By default Windows Server 2012 R2 supports NTLMv1 due to requirements for backwards compatibility. Microsoft has long recommended disabling NTLMv1 due to the documented issues with the security of the protocol. Sadly there are a large number of applications and devices in use in enterprises which still require NTLMv1.

To test the AWS managed domain controllers I’m going to use Samba’s smbclient package on SERVER02. I’ll use the client to connect to the domain controller’s share from SERVER02 using NTLM. I first installed the smbclient package by running:

yum install samba-client.

The client enforces the use NTLMV2 in smbclient by default so I needed to make some modifications to the global section of the smb.conf file by adding client ntlmv2 auth = no. This option disables NTLMv2 on smbclient and will force it to use NTLMv1.

In order to see whether or not the client was using NTLMv1 when connecting to the domain controllers, I started a packet capture using tcpdump before initiating a connection with the smbclient.

I then transferred the packet capture over to my Windows box with WinSCP, opened the capture with WireShark, and navigated to the packet containing the Session Setup Request. In the parsed capture we don’t see an NTLMv2 Response which means NTLMv1 was used to authenticate to the domain controller indicating NTLMv1 is supported by the managed domain controllers.

So what can we take from the findings of this analysis?

Amazon has left the secure transport protocols to the defaults which means SSLv3 is supported.

Amazon has left the cipher suites to the defaults which means both RC4 and 3DES cipher suites are supported for both LDAPS and Kerberos.

I’d really like to see Amazon address the support for SSLv3 as soon as possible. There is no reason I can see why that shouldn’t be shut off by default. Similar to my requests to Microsoft, I’d like to see Amazon allow the supported cipher suites to be configurable via the AWS Management Console. These two changes would save organizations with strict security requirements, such as those in the public sector, to utilize the services without introducing significant risk (and audit headaches).

In my next post I’ll demonstrate how the service can be leveraged to provide Windows Active Directory service to on-premises machines or machines in another public cloud as well as exploring how to create a forest trust with the service.

I’m back again with another entry in my deep dive into AWS Managed Microsoft Active Directory (AD). So far I’ve provided an overview of the service, covered how to configure the service, and analyzed the Active Directory default configuration such as the directory structure, security principals, password policies, and group policy setup by Amazon for new instances. In this post I’m going to look at the setup of LDAPS and how Amazon supports configuration of it in the delegated model they’ve setup for the service.

Those of you that have supported a Windows AD environment will be quite familiar with the wonders and sometimes pain of the Lightweight Directory Access Protocol (LDAP). Prior to the modern directories such as AWS Cloud Directory, Azure Active Directory the LDAP protocol served critical roles by providing both authentication and a method of which to work with data stored in directory data stores such as Windows AD. For better or worse the protocol is still relevant today when working with Windows AD for both of the above capabilities (less for authentication these days if you stay away from backwards-thinking vendors). LDAP servers listen on port 389 and 636 with 389 maintaining traffic in the clear (although there are exceptions where data is encrypted in transit such as Microsoft’s usage of Kerberos encryption or the use of StartTLS(credit to my friend Chris Jasset for catching my omission of StartTLS)) and 636 (LDAPS) providing encryption in transit via an SSL tunnel (hopefully not anymore) or a TLS tunnel.

Windows AD maintains that pattern and serves up the content of its data store over LDAP over ports 389 and 636 and additionally ports 3268 and 3269 for global catalog queries. In the assume breach days we’re living in, we as security professionals want to protect our data as it flows over the network which means we’ll more often than not (exceptions are again Kerberos encryption usage mentioned above) be using LDAPS over ports 636 or 3269. To provide that secure tunnel the domain controllers will need to be setup with a digital certificate issued by a trusted certificate authority (CA). Domain Controllers have unique requirements for the certificates they use. If you’re using Active Directory Certificate Services (AD CS) Microsoft takes care of providing the certificate template for you.

So how do you provision a certificate to a Domain Controller’s certificate store when you don’t have administrative privileges such as the case for a managed service like AWS Managed Active Directory? For Microsoft Azure Active Directory Domain Services (AAD DS) the public certificate and private key are uploaded via a web page in the Azure Portal which is a solid way of doing it. Amazon went in a different and instead takes advantage of certificate autoenrollment. If you’re not familiar with autoenrollment take a read through this blog. In short, it’s an automated way to distribute certificates and eliminate some of the overheard of manually going through the typical certificate lifecycle which may contain manual steps.

If we bounce back to the member server in my managed domain, open the Group Policy Management Console (GPMC), and navigate to the settings tab of the AWS Managed Active Directory Policy we see that autoenrollment has been enabled on the domain controllers. This setting explains why Amazon requires a member server joined to the managed domain be configured running AD CS. Once the AD CS instance is setup, the CA has been configured either to as a root or subordinate CA, and a proper template is enabled for autoenrollment, the domain controllers will request the appropriate certificate and will begin using it for LDAPS.

If you’ve ever worked with AD CS you may be asking yourself how you’ll be able to install AD CS in a domain where you aren’t a domain administrator when the Microsoft documentation specifically states you need to be a member of the Enterprise Admins and root domains Domain Admins group. Well folks that is where the AWS Delegated Enterprise Certificate Authority Administrators group comes into play. Amazon has modified the forest to delegate the appropriate permissions to install AD CS in a domain environment. If we navigate to the CN=Public Key Services, CN=Services, CN=Configuration using ADSIEdit and view the Security for the container we see this group has been granted full permissions over the node allowing the necessary objects to be populated underneath it.

I found it interesting that in the instructions provided by Amazon for enabling LDAPS the instructions state the Domain Controller certificate template needs to modified to remove the Client Authentication EKU. I’d be interested in knowing the reason for modifying the Domain Controller certificate. If I had to guess it’s to prevent the domain controller from using the certificate outside of LDAPS such as for mutual authentication during smart card logon. Notice that from this article domain controllers only require the Server Authentication EKU when a certificate is only used to secure LDAPS.

I’ve gone ahead and installed AD CS on SERVER01 as an Enterprise root CA and thanks to the delegation model, the CA is provisioned with all the necessary goodness in CN=Public Key Services. I also created the new certificate template following the instructions from Amazon. The last step is to configure the traffic flow such that the managed domain controllers can contact the CA to request a certificate. The Amazon instructions actually have a typo in them. On Step 4 it instructs you to modify the security group for your CA and to create a new inbound rule allowing all traffic from the source of your CA’s AWS Security group. The correct security group is actually the security group automatically configured by Amazon that is associated with the managed Active Directory instance.

At this point you’ll need to wait a few hours for the managed domain controllers to detect the new certificates available for autoenrollment. Mine actually only took about an hour to roll the certificates out.

To test the service I opened LDP.EXE and established a secure session over port 636 and all worked as expected.

Since I’m a bit OCD I also pulled the certificate using openssl to validate it’s been issued by my CA. As seen in the screenshot below the certificate was issued by the geekintheweeds-CA which is the CA I setup earlier.

Beyond the instructions Amazon provides, you’ll also want to give some thought as to how you’re going to handle revocation checks. Keep in mind that by default AD CS stores revocation information in AD. If you have applications configured to check for revocation remember to ensure those apps can communicate with the domain controllers over port 389 so design your security groups with this in mind.

Well folks that will wrap up this post. Now that LDAPS is configured, I’ll begin the tests looking at the protocols and ciphers supported when accessing LDAPS as well as examining the versions of NTLM supported and the encryption algorithms supported with Kerberos.

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.

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.

Post navigation

About Me

Hi there! My name is Matt Felton and I am a long time geek with a passion for technology. I have over 10 years experience in the industry that spans the technology stack. Over the past few years I’ve had the opportunity to dig deeper into security and identity which I’ve been more than happy to do.

I started Journey Of The Geek over 6 six years ago when I saw an opportunity to provide in-depth technical deep dives to peel back the onion on technologies and products. I enjoy sharing what I’ve learned and giving back to the industry. Plus there is no better way to learn a topic than to teach it.

I hope you enjoy and if you have questions feel free to reach out via the comments, LinkedIn, or Twitter.

DISCLAIMER

All views expressed on this site are my own and do not represent the opinions of any entity whatsoever of which I have been, am now, or will be affiliated.