Providing self-service multi-account access to AWS Managed Microsoft AD

Introduction

In this blog post, I will show you how to selectively share a central AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) directory across your multi-account environment through a self-service model using AWS Service Catalog.

In a large and growing AWS Organizations environment with decentralized teams, you want to remove as much as friction as possible when building new projects. Using separate AWS accounts for different projects offers a number of advantages including: adding isolation, limiting scope of unplanned events, and managing costs. If accounts require access to AWS Managed Microsoft AD, you can share the directory with those accounts to enable the benefits of seamless Amazon Elastic Compute Cloud (EC2) domain joins or enabling AD authentication for Amazon Relational Database Service (Amazon RDS).

Requiring your decentralized teams to contact a central team to manually share a directory when required and to unshare the directory when it’s no longer needed can result in process bottlenecks and slow down the pace of operations. Sharing the directory with every AWS account in the Organization can be costly due to the additional hourly fee associated with directory sharing. This may not be the most cost-effective approach, especially if there is uncertainty about whether the directory will be required by all accounts.

In this post, I will go through automating the process of sharing an AWS Managed Microsoft AD by using a self-service Service Catalog product accessible by designated roles from every account in an AWS Organizations environment or selected Organizational Units (OUs). Launching the Service Catalog product results in the directory being shared to the requesting account and automatically configures Amazon Route 53 Resolver DNS forwarding rules required for AD to work.

Solution overview

The solution involves the following components (Figure 1):

1. A shared Service Catalog product available on all AWS accounts in your Organization or on selected OUs, which allows users using designated AWS IAM Identity Center permission sets or IAM roles to request an AWS Managed Microsoft AD share.
2. The Service Catalog product creates an AWS CloudFormation stack that orchestrates sharing the central AWS Managed Microsoft AD to the requesting AWS account.
3. The CloudFormation stack also associates a shared Route 53 Resolver forwarding rule to forward DNS queries for the AD domain, such as corp.example.com, to the AWS Managed Microsoft AD IP addresses.
4. Windows and Linux EC2 instances with supported AMIs can seamlessly join AWS Managed Microsoft AD using an instance profile IAM role with the required permissions.
5. RDS for SQL Server, RDS for MySQL, and RDS for PostgreSQL, Aurora PostgreSQL, and Aurora MySQL can be configured to authenticate users using the shared AWS Managed Microsoft AD.

Figure 1 – Overview of the self-service AWS Managed Microsoft AD sharing solution

AWS account administrators will see the Service Catalog product in the product list (Figure 2).

Figure 2 – Service Catalog product list

After selecting the: Request AWS Managed Microsoft AD product, enter a name for the provisioned product and select a VPC to have access to the shared directory (Figure 3).

Figure 3 – Service Catalog product parameters

Within a few minutes after launching the product, the central AWS Managed Microsoft AD is automatically shared with the requester’s AWS account. This can be verified by accessing the AWS Directory Service page (Figure 4).

Figure 4 – Shared directory visible after product launch

The selected VPC is automatically configured with an Amazon Route 53 Resolver forwarding rule to forward DNS requests for AD to the AWS Managed Microsoft AD IP addresses. This can be verified by checking the Route 53 Resolver rules page on the requester’s AWS account (Figure 5).

Figure 5 – Route 53 Resolver rule automatically configured after product launch

At this stage, the account can benefit from many of the features of AWS Managed Microsoft AD. For example, when launching Windows or Linux EC2 instances you can enable seamless EC2 domain joining by selecting the shared directory and the included IAM instance profile (Figure 6) that is created as part of the Service Catalog product launch, which enables the domain join.

Figure 6 – EC2 instance launch with seamless domain joining

Not all services support shared directories. For example, at the time of writing, Amazon Workspaces does not yet support shared directories (check the Workspaces documentation on directory integration for the latest status on support for shared directories). Some examples of services that support shared directories include Amazon FSx for Windows File Server and Amazon RDS. If the shared directory is no longer needed the Service Catalog product can be terminated, which unshares the directory.

Prerequisites

The solution requires you have:

1. Administrator level access to AWS Organizations.
2. An AWS account to host AWS Managed Microsoft AD, for example a shared services or infrastructure account. This blog post goes through the steps to create the directory in this AWS account, if you haven’t already done so.This solution is best suited for AWS Managed Microsoft AD Enterprise Edition, which has a default quota of sharing with up to 125 accounts, as opposed to the Standard Edition quota of 5 accounts at the time of writing. Contact AWS Support if you need to upgrade your Standard edition directory to Enterprise edition.
3. One or more AWS accounts to consume the Service Catalog product.
4. Authentication using AWS IAM Identity Center or federated IAM role names in every AWS account for users accessing the Service Catalog product.
5. Amazon Virtual Private Cloud (VPC) networking configured in each AWS account that allows communication with the AWS Managed Microsoft AD VPC using VPC peering or Network Orchestrator for AWS Transit Gateway. If your VPC does not have access to the internet, use AWS PrivateLink to enable access to the AWS Directory Services endpoint.

Walkthrough

There are four steps in this solution:

1. AWS Organizations configuration to allow Organization wide resource sharing.
2. AWS Managed Microsoft AD creation. Required if you do not have an existing directory.
3. Amazon Route 53 Resolver outbound endpoints and forwarding rule(s) creation to forward DNS requests for the directory domain(s) to AWS Managed AD.
4. Service Catalog product creation to allow users to request the directory share.

Step 1 – AWS Organizations configuration

There are three changes required for the AWS Organizations management AWS account:

1. Service Catalog Organizations sharing needs to be enabled and the account hosting AWS Managed Microsoft AD needs to be one of the delegated administrators for Service Catalog. This allows sharing the Service Catalog product to other AWS accounts in the Organization.To enable this, log into the AWS Management Console of the management AWS account, launch the AWS CloudShell service and type the following commands. Replace the aws_managed_microsoft_ad variable with the ID of the account that is or will be, hosting the AWS Managed Microsoft AD instance:

   # Set a variable with the ID of the account hosting AWS Managed Microsoft AD
   aws_managed_microsoft_ad_account_id=012345678910
   
   # Enable AWS Organizations integration in Service Catalog
   aws servicecatalog enable-aws-organizations-access
   
   # Nominate the AWS Managed Microsoft AD account to be one of the delegated administrators for Service Catalog
   aws organizations register-delegated-administrator --account-id $aws_managed_microsoft_ad_account_id --service-principal servicecatalog.amazonaws.com

2. Enable AWS directory service trusted access in Organizations to share AWS Managed Microsoft AD with accounts in the Organization:

   aws organizations enable-aws-service-access --service-principal ds.amazonaws.com

3. AWS Resource Access Manager (AWS RAM) sharing needs to be enabled for sharing Amazon Route 53 Resolver Rules to allow Service Catalog product consumers to query AD:

   aws ram enable-sharing-with-aws-organization

Step 2 – AWS Managed Microsoft AD

If you already have AWS Managed Microsoft AD, note the directory ID and skip this step.

The following creates a sample AWS Managed Microsoft AD using CloudFormation with:

• Logging enabled to write to Amazon CloudWatch Logs.
• A randomly generated administrator password kept in AWS Secrets Manager. The password needs to be rotated manually or automatically using AWS Systems Manager and AWS Secrets Manager.
• Directory status notifications with Amazon Simple Notification Service (Amazon SNS).

If you choose to setup a Managed AD instance using this template, be aware of the responsibilities you assume for maintaining it. It is important that you have a plan in place to keep it secure. For example, use strong authorization mechanisms, keep this instance up to date with patches, protect it from unauthorized access and monitor it to detect potential security events. For more a more in depth guide see, Secure your AWS Managed Microsoft AD directory and Security in AWS Directory Service.

Log into the console of the AWS account that will host the directory, select the appropriate region, and follow the steps below:

1. Download the CloudFormation template for creating the AWS Managed Microsoft AD.
2. Navigate to the AWS CloudFormation console.
3. Click on Create stack -> With new resources (standard).
4. Select Upload a template file and upload the CloudFormation template downloaded earlier: AWS_Managed_Microsoft_AD.yaml, click Next.
5. Enter a stack name.
6. Select the VPC and two private subnet IDs (in different Availability Zones) the directory should be created in (Figure 7).

Figure 7 – AWS_Managed_Microsoft_AD.yaml networking CloudFormation parameters

7. Enter details about the AWS Managed Microsoft AD to be created (Figure 8)

Figure 8 – AWS_Managed_Microsoft_AD.yaml directory CloudFormation parameters

The template (Figure 9) has the option of creating a Windows EC2 instance, which can be used to configure AD if required. This requires the VPC to either have internet access or VPC endpoints for “ssm”, “ssmmessages” and “ec2messages”.

Figure 9 – AWS_Managed_Microsoft_AD.yaml management EC2 host CloudFormation parameters

8. Click Next, then optionally enter tags and click Next Acknowledge the capabilities and click on Submit. Wait for the stack creation to finish. If you get an error about a specific Availability Zone, try selecting a subnet on a different Availability Zone.

The Outputs tab has information about the created directory (Figure 10).

Figure 10 – AWS_Managed_Microsoft_AD.yaml outputs

To access the automatically generated Admin password, click on the AWS Secrets Manager link next to ManagedADPassword and click on Retrieve secret value.

Optionally, to configure AD, click on the AWS Systems Manager Fleet Manager link next to RDPWebURL. Systems Manager Fleet Manager is a capability of Systems Manager. Enter the username Admin with the password copied from Secrets Manager earlier, click on Connect. You can then create a user by opening the AD Users and Computers MMC that is pre-installed (Figure 11).

Figure 11 – Configure Active Directory, with Fleet Manager

The admin password will need to be rotated manually as required or on a schedule using instructions from the blog post: Rotate Active Directory credentials stored in AWS Secrets Manager.

Step 3 – Amazon Route 53 Resolver forwarding rules

The following steps create an Amazon Route 53 Resolver outbound endpoint and shared forwarding rule that forwards DNS queries for the directory DNS name (e.g. corp.example.com) to the AWS Managed Microsoft AD IP addresses. The Service Catalog product later associates this rule with the VPC of the account requesting the AWS Managed Microsoft AD share.

The template can optionally configure an additional DNS forwarding rule for another domain, which is useful if you plan to set up a trust relationship with another directory (e.g. an on-premises AD domain).

Log into the console of the AWS account that is hosting the directory. Make sure you are in the correct region, and then:

1. Download the CloudFormation template for creating the Route 53 Resolver forwarding rules.
2. Navigate to the AWS CloudFormation page.
3. Click on Create stack -> With new resources (standard).
4. Select Upload a template file and upload the CloudFormation template downloaded earlier: Route53-Rules.yaml and click Next.
5. Enter a stack name and the parameter values as needed (Figure 12).For the parameter: Principal ARN to share rule with, enter the principal ARN or account ID to share the Route 53 Resolver rule with. If testing with a specific account in the Organization enter the account ID here. Alternatively, if you want to share the rule with the entire Organization, paste the command listed in the parameter description in AWS CloudShell to get the principal ARN.Select the VPC where the directory is located and the associated private subnets.

Figure 12 – Route53-Rules.yaml rule sharing parameters

If you plan to configure a trust relationship with another domain, enter details about the other domain to configure the DNS rules (Figure 13). The trust must be manually configured after DNS is configuration is complete.

Figure 13 – Route53-Rules.yaml trust relationship domain parameters

Finally, enter the details about your AWS Managed Microsoft AD (Figure 14). If you used the CloudFormation template linked earlier in this blog post to create the directory, you can leave the parameters blank to import the values automatically.

Figure 14 – Route53-Rules.yaml AWS Managed Microsoft AD directory details

6. Click Next, then optionally enter tags and click Next Acknowledge the capabilities and click Submit. Wait for the stack creation to finish.
   If you get an error: AWSServiceRoleForResourceAccessManager already exists, delete the stack and recreate it with the Create RAM Service Linked IAM Role? parameter set to No.

Step 4 – Service Catalog product

Finally, run an included script that creates the CloudFormation templates required for the Service Catalog product to share the AWS Managed Microsoft AD directory.

To run the script, log into the console of the AWS account and region that is hosting the directory and start the AWS CloudShell service. In the terminal, enter the following commands:

git clone https://github.com/aws-samples/providing-self-service-multiaccount-access-to-aws-managed-microsoft-ad.git

cd providing-self-service-multiaccount-access-to-aws-managed-microsoft-ad/Service_Catalog_Product

./install.sh

Figure 15 – Service Catalog install.sh script

The script will ask for the following information (Figure 15):

• The Service Catalog provider display name, which can be your company or organization name.
• The Service Catalog product version, which defaults to v1. Increment this if you make a change in the product CloudFormation template file.
• The principal type that will be using the Service Catalog product. If you are using AWS IAM Identity Center, enter: IAM_Identity_Center_Permission_Set. If you have federated IAM roles configured, select: IAM role name.
• The principal(s) that will have access to the Service Catalog product across the AWS accounts.
  If you are using IAM Identity Center, this will be a permission set name, (e.g. AWSAdministratorAccess). Otherwise, enter an IAM role name that is available in every AWS account.

The script creates the following CloudFormation stacks:

• Managed-AD-Sharing-Hub.yaml: creates an Amazon SNS topic that triggers an AWS Lambda function to share the directory with the calling account.
• Managed-AD-Sharing-SC-Bucket.yaml: creates an Amazon Simple Storage (Amazon S3) bucket that contains the file: Managed-AD-Sharing-Product.yaml CloudFormation template file associated with the Service Catalog product. When the Service Catalog user launches the product and thus the CloudFormation stack, it calls the Amazon SNS topic created earlier as well as associates the shared Route 53 Resolver forwarding rule created earlier with the VPC given in the product parameters.
• Managed-AD-Sharing-ServiceCatalog.yaml: creates a Service Catalog portfolio and product using the Amazon S3 bucket from the previous step and gives permissions to the required principals to launch the product.

After the script finishes installation, it asks whether it should automatically share this Service Catalog portfolio with the entire Organization, a specific account, or configure sharing to specific OUs manually.

To manually configuring sharing with an OU, go to Service Catalog -> Portfolios, select Request AWS Managed Microsoft AD share, in the Share tab click add a share, select AWS Organization, and select the OU (Figure 16). The product will be shared to all accounts and child OUs within the selected OU.

Figure 16 – Service Catalog portfolio OU sharing

Ensure that you select Principal Sharing (Figure 17), click Share.

Figure 17 – Service Catalog Principal sharing

Log into an AWS account that has access to the shared Service Catalog product, ensuring you are logged in with the designated IAM Identity Center Permission Set or IAM role. Launch the product in Service Catalog to request an AWS Managed Microsoft AD share.

Additional notes

Users that request access to AWS Managed Microsoft AD using Service Catalog will need Administrator level access on their AWS accounts. If you want to grant users without Administrator access the ability to request a AWS Managed Microsoft AD share, the README.md document in the GitHub repo has details of how to deploy privileged resources like IAM roles outside of Service Catalog, so that Administrator level access is no longer required.

To expand this solution across regions, enable AWS Managed Microsoft AD multi-region replication, ensuring that there is multi-region network connectivity and then instantiating this Service Catalog solution in additional regions.

To make this solution work with multiple VPCs in each AWS account, create a separate CloudFormation template that has a Route 53 Resolver Rule association to the VPC selected as a parameter. Associate that template with a separate Service Catalog product, which can be requested as many times as there are VPCs.

Cleanup

There are pay-as-you-go costs associated with running an AWS Managed Microsoft AD directory, sharing the directory, the EC2 management host instance, the Route 53 Resolver Endpoints, and the VPC resources like NAT Gateways.

To avoid ongoing charges created during testing of this solution, follow these steps:

• In the test workload account(s):
  • Terminate any test EC2 instances or RDS databases created to test the AWS Managed Microsoft AD integration.
  • Go to Service Catalog provisioned products and terminate the associated provisioned product(s). This unshares the directory from the requesting account and disassociates the shared Route 53 resolver rule.
• In the AWS account hosting the directory:
  • Go to Service Catalog, portfolios, click on Request AWS Managed Microsoft AD share, go to the Share tab, select the items in the list and click on Actions -> Unshare.
  • Go to CloudFormation, delete the Managed-AD-Sharing-Service-Catalog
  • Go to Amazon S3, select the bucket starting with managed-ad-sharing-sc-bucket, click on Empty and empty the bucket.
  • Go to CloudFormation, delete the following stacks in order:
    1. Managed-AD-Sharing-SC-Bucket.
    2. Managed-AD-Sharing-Hub.
    3. The stack with the Route 53 rules.
    4. The AWS Managed Microsoft AD stack.

Conclusion

This blog post illustrates enablement of a Service Catalog based self-service mechanism to request an AWS Managed Microsoft AD share across a large multi-account Organization. This removes the need for directory administrators to manually share the directory with teams that need it for enabling seamless EC2 domain joins or authentication with Amazon RDS databases and reduces costs by only sharing directories with accounts that have requested it.

AWS has significantly more services, and more features within those services, than any other cloud provider, making it faster, easier, and more cost effective to move your existing applications to the cloud and build nearly anything you can imagine. Give your Microsoft applications the infrastructure they need to drive the business outcomes you want. Visit our .NET on AWS and AWS Database blogs for additional guidance and options for your Microsoft workloads. Contact us to start your migration and modernization journey today.