Microsoft Workloads on AWS

Enhance security of your AWS app integration with AWS Managed Microsoft AD

In this blog post, I will show you how you can strengthen security when using two-way trusts between your self-managed Microsoft Active Directory and your AWS Managed Microsoft AD for accessing AWS applications.

Introduction

Customers often want their self-managed Active Directory users to have a seamless authentication and authorization experience when using Amazon Web Services (AWS) applications. For AWS applications that do not integrate directly with self-managed Active Directory, a common approach is to use AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) as a resource forest for the integration. AWS Managed Microsoft AD allows customers to integrate with AWS managed applications like Amazon Relational Database Service (Amazon RDS), Amazon WorkSpaces, AWS IAM Identity Center, and other applications. However, if you already run self-managed Active Directory on-premises or on Amazon Elastic Compute Cloud (Amazon EC2), you can use your existing identities for authentication to AWS applications by establishing a one-way or a two-way trust between your self-managed AD and your AWS Managed Microsoft AD.

Solution overview

Depending on the AWS application, a one-way or a two-way trust between your self-managed Active Directory and your AWS Managed Microsoft AD provides your self-managed users access to AWS applications. For example, Amazon RDS, Amazon FSx, and Amazon EC2 are AWS services that are accessible via a one-way outgoing trust from your AWS Managed Microsoft AD to your self-managed AD, as shown in figure 1.

Figure 1 shows a diagram depicting how to use a one-way trust with AWS Managed Microsoft AD to access AWS applications

Figure 1: Using one-way trust with AWS Managed Microsoft AD to access AWS applications

With one-way trusts, users from your self-managed AD domain can access resources in your AWS Managed AD domain but not the other way round. For in-depth details about Active Directory trusts, please refer to this blog post.

When you authorize an AWS application on AWS Managed Microsoft AD, AWS Directory Service grants specific permissions to allow for seamless integration with your Active Directory. AWS applications are only granted the access necessary for their use case. For more information, see authorization for AWS applications and services using AWS Directory Service.

As part of this automated authorization process, AWS Directory Service creates application specific service accounts for the AWS application. For AWS applications like AWS IAM Identity Center, Amazon WorkSpaces, and Amazon QuickSight that use a two-way trust, this application-specific service account is used to query your on-premises Active Directory to provision and grant access to AWS resources for that user. For example, when creating an Amazon WorkSpace for an on-premises user, AWS Directory Service queries your on-premises Active Directory for that user in order to provision the WorkSpace for them. This is why a two-way trust is needed to make that query succeed.

By default, when you create a domain or forest-wide two-way trust, users can authenticate across the trust in both directions. To enhance security, you can limit who can authenticate across the trust from your AWS Managed Microsoft AD to your self-managed AD by using selective authentication on your self-managed AD side of the trust as shown in figure 2. Selective authentication enables only selected identities to authenticate to your on-premises domain. This aligns with the principle of least privilege and ensures you have visibility into who authenticates against your self-managed Active Directory over the trust.

Figure 2 shows a diagram depicting how to use a two-way trust with AWS Managed Microsoft AD to access AWS applications

Figure 2: Using two-way trust with AWS Managed Microsoft AD to access AWS applications.

Similarly, you may want to limit who can authenticate across the trust from your self-managed AD to your AWS Managed Microsoft AD. In this case, you can also enable selective authentication on your AWS Managed AD side of the trust. Refer to creating a trust relationship in the AWS Directory Service documentation. However, the focus of this blog is for the former use case.

Depending on the AWS application you are integrating, you can grant allowed to authenticate permission to the AWS application specific service account from your AWS Managed Microsoft AD.

Prerequisites

The steps in this post assume you have the following:

1.   A self-managed Active Directory environment running either on-premises or on Amazon EC2.
2.  An AWS Managed Microsoft AD.
3.  Created a trust between your self-managed AD and your AWS Managed Microsoft AD.

Configure selective authentication on your self-managed Active Directory

Complete the steps below to configure selective authentication on your self-managed AD side of the trust.

1.  On your self-managed AD, open Active Directory Domains and Trusts snap-in.
2.  Open the properties of the trust and select the Authentication tab as shown in figure 3.
3.  Select Selective Authentication and select OK.

Figure 3 shows how to configure selective authentication in the Active Directory Domains and Trusts snap-in.

Figure 3: Configure selective authentication on the self-managed AD side of the trust.

With this configuration, even with the two-way trust in place, your AWS Managed Microsoft AD is not allowed to authenticate to your on-premises domain. For example, if you wanted to provision an Amazon WorkSpace for an on-premises user, you would see the following error message shown in figure 4.

Figure 4 shows a screenshot of an error that occurs with Amazon WorkSpaces when you initially configure selective authentication.

Figure 4: Error caused by improperly configured selective authentication.

To successfully provision Amazon WorkSpaces for your self-managed AD users, you will need to configure the Amazon WorkSpaces application specific service account to authenticate across the trust. The next sections show how to configure your self-managed Active Directory for various AWS applications.

Identify the AWS application specific service account.

Depending on the AWS application you have authorized for AWS Directory Service, you can find the application specific service account on your AWS Managed Microsoft AD by following these steps.

1.  Logon to your AWS Managed Microsoft AD directory administration EC2 instance.
2.  Open Active Directory Users and Computers snap-in.
3.  Navigate to the AWS Reserved organization unit.

For example, figure 5 shows the AWS application specific service accounts for AWS IAM Identity Center and Amazon WorkSpaces.

Figure 5 shows a screenshot highlighting the AWS application specific service account for AWS IAM Identity Center and Amazon WorkSpaces.

Figure 5: AWS application specific service accounts for IAM Identity Center and Amazon WorkSpaces

Refer to the following table for a list of AWS application specific service accounts.

AWS Application Service Account
Amazon WorkSpace AWS_WorkSpaces
IAM Identity Center AWS_iss_prod_region (E.g., AWS_iss_prod_IAD)
Amazon Connect AWS_LilyAuthregionProd (E.g., AWS_LilyAuthIADProd)
Amazon QuickSight AWS_SpaceNeedle-prod
AWS Client VPN AWS_SecureConnect
AWS Transfer Family AWS_TransferFamily
Amazon WorkMail AWS_WorkMail
Amazon Chime AWS_WorkTalk
Amazon WorkMail AWS_WorkMail
AWS Management Console AWS_MGMTConsole
AWS License Manager This varies with a description “DO NOT DELETE: Provided by AWS for administration of License Manager objects”

Configure least privilege permission for your AWS application specific service account

In this step, you will configure the allow to authenticate permission for the AWS application you have authorized for your AWS Managed Microsoft Active Directory.

1.  On your on-premises Active Directory, navigate to the Active Directory Users and Computers snap-in.
2.  Select your Domain Controller and open its properties.
3.  Select the Security tab.

If you do not see the security tab, select View from the menu bar, then select Advanced Features, and then try again.

4.  Select Add and select Locations
5.  For location, select your AWS Managed Microsoft AD Forest and select OK.
6.  Enter the applicable service account, select Check Names and select OK.
7.  With the application service account still selected, check the allowed to authenticate box, as shown in figure 6.

Figure 6 shows a screenshot of how to grant AWS application specific service accounts "allowed to authenticate" access to self-managed AD resources over the trust.

Figure 6: Grant “allowed to authenticate” permissions to AWS application specific service account

You will now be able to provision Amazon WorkSpaces for your users in your self-managed AD. If you have authorized your AWS Managed Microsoft AD to give other AWS applications and services access to your directory, repeat steps 1 to 7 for each AWS application specific account. With this configuration, you have streamlined access to your self-managed Active Directory only to AWS service accounts required to work with AWS applications.

Cleanup

If you no longer need it, you can follow the steps to delete your AWS Managed Microsoft AD.

Conclusion

In this blog post, I showed you how you can enhance the security of your Active Directory environment by granting least privilege permissions through selective authentication when integrating your self-managed Active Directory with your AWS Managed Microsoft AD for access to AWS applications. This configuration ensures that only the necessary AWS application specific service accounts can authenticate to your self-managed Active Directory for AWS applications that use two-way trusts.

Read further to see how AWS Directory Service simplifies Active Directory management and integration for your directory-aware workloads and resources on AWS.


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.

Tekena Orugbani

Tekena Orugbani

Tekena is a Sr. Specialist Solutions Architect at Amazon Web Services and a technologist of over 20 years, specializing in Microsoft technologies. At AWS, Tekena is focused on helping customers architect, migrate and modernize their Microsoft workloads on the AWS Cloud. Outside work, he enjoys hanging out with his family and watching soccer.