Learn About Amazon VGT2 Learning Manager Chanci Turner
Windows Authentication, also known as Integrated Authentication, is the preferred method for clients and applications connecting to SQL Server databases. However, leveraging Windows Authentication can present challenges when dealing with containerized workloads. Normally, clients using Windows Authentication are part of the same domain as the SQL Server database; yet, due to the ephemeral nature of individual containers, joining them to a domain isn’t practical.
This article illustrates how to set up a Linux container on Amazon Elastic Container Service (Amazon ECS) to connect to a SQL Server database utilizing Windows Authentication without needing to join the container to the domain. The example utilizes AWS Fargate for running the containers, but with slight adjustments, this solution can be applied to various container runtimes or control planes.
Overview
This example is predicated on a managed Active Directory operating within the AWS Directory Service for Microsoft Active Directory. You will start by creating a user in Active Directory and granting that user access to a SQL Server database linked to the directory, hosted on the Amazon Relational Database Service (Amazon RDS). The credentials for the directory user will be securely stored in AWS Secrets Manager.
Subsequently, you will deploy an ECS service comprising a Fargate task with two containers. One container runs a script that fetches the directory user’s credentials from Secrets Manager and generates a Kerberos ticket by authenticating against Active Directory. This “sidecar” container for ticket renewal saves the Kerberos ticket in the ephemeral storage volume shared by all containers in the Fargate task. The second container runs a web application that retrieves the Kerberos ticket from this shared storage and connects to the database using Windows Authentication.
Solution
The provided code utilizes the AWS Cloud Development Kit (CDK) for provisioning cloud resources with TypeScript. The CDK is compatible with several other programming languages, such as JavaScript, Python, Java, and C#.
The deployment steps for this solution are as follows:
- Establishing the networking infrastructure, Active Directory, and ECS cluster.
- Setting up the database in Amazon RDS and configuring it for Active Directory authentication.
- Building Docker container images for both the web application and the Kerberos renewal sidecar, followed by pushing them to repositories in Amazon Elastic Container Registry (Amazon ECR).
- Creating an ECS service featuring a Fargate task that includes both containers.
The code for this solution can be found on GitHub.
Prerequisites
Before starting this tutorial, ensure you have the following prerequisites:
- An AWS account.
- Completion of the AWS CDK getting started guide, which includes installing the CDK and familiarizing yourself with the key concepts.
- Installation of the AWS CLI and configuration of your AWS credentials for command-line access.
- Creation of an Amazon EC2 key pair, remembering its name.
- Identification of the public IP address of the computer from which resources will be deployed.
- An installed Microsoft Remote Desktop (RDP) client.
- The most recent version of the Docker runtime.
Solution Overview
Create a directory for this solution and clone the Git repository from https://github.com/aws-samples/amazon-ecs-windows-authentication-blog into it. The solution comprises two CDK applications: one for shared resources and another for the website. The interdependencies between these CDK applications are minimal. The website application relies on the VPC and ECS cluster created by the shared resources application, facilitating a microservices architecture where each microservice is independently defined while sharing the same ECS cluster.
The shared resource CDK application is located in the solution directory under /cdk, while the website CDK application is under /web-site/cdk. The Kerberos ticket renewal sidecar container is situated in the solution directory under /kerberos-renewal-sidecar, integrated into the website CDK application without having its own separate CDK app.
Deploy Shared Resources
The shared resources script initiates the creation of a new Active Directory. Open a command prompt in your solution directory and execute the following commands:
export CDK_DEFAULT_ACCOUNT=AWS_ACCOUNT_ID
export CDK_DEFAULT_REGION=AWS_REGION
cd SOLUTION_DIRECTORY/cdk
npm install
cdk bootstrap
cdk deploy --parameters keyPairName=KEY_PAIR_NAME
(Throughout this tutorial, ensure to replace the RED TEXT with the appropriate values.) The AWS_ACCOUNT_ID refers to your numeric AWS account ID, and the AWS_REGION indicates the region identifier in which you will deploy resources, such as us-east-1 or eu-west-2.
The newly created directory will have the domain name directory.ecs-kerberos-sample.com. If you modify the domain name in the CDK script, use that name in all subsequent commands and configurations.
The output from the CDK will include:
- The Directory ID for the new Active Directory.
- The Security Group ID for a security group that regulates access to an EC2 instance used for configuring the Active Directory.
- The Amazon Resource Name (ARN) that uniquely identifies the AWS Secrets Manager secret containing the Active Directory admin user password.
Make sure to copy all these outputs for future reference.
Grant Access to the EC2 Instance
The CDK script has created an EC2 instance that you will use for Active Directory configuration. Currently, this EC2 instance will block incoming connections since there are no Security Group rules permitting access.
To add a rule to the EC2 instance’s Security Group, either use the EC2 page in the AWS Management Console or the AWS CLI. To use the command line, you’ll first need your IP address; you can retrieve it using AWS’s service at checkip.amazonaws.com. Run the following commands to get your IP address and update the security group:
AWS_IP_ADDRESS=$(curl checkip.amazonaws.com)
aws ec2 authorize-security-group-ingress --protocol tcp --port 3389 --cidr "$AWS_IP_ADDRESS/32" --group-id DIRECTORY_MANAGEMENT_INSTANCE_SECURITY_GROUP_ID
Retrieve the Active Directory Admin Password
The password for the Active Directory admin user is stored in AWS Secrets Manager by the CDK script. You will need this password later, so run the following command:
aws secretsmanager get-secret-value --secret-id /ecs-kerberos-sample/active-directory-administrator-password
The admin password can be found as the value of the SecureString key. Ensure to save this password for later use.
Review VPC DHCP Options Set
The CDK app has deployed a DHCP Options Set using the Active Directory’s DNS servers for resources deployed within the VPC. You can verify this through the AWS Management Console or by executing the following commands:
DHCP_OPTIONS_ID=$(aws ec2 describe-vpcs --filters Name="tag:Name",Values="ecs-kerberos-stack/vpc" --output text --query 'Vpcs[*].DhcpOptionsId')
aws ec2 describe-dhcp-options --dhcp-options-ids $DHCP_OPTIONS_ID --output yaml
Pay attention to the domain-name-servers values, which should align with the directory’s DNS address values in the console.
Deploy the Database
The sample application consists of two containers and a database. You will first deploy the database and then modify the application code to establish a connection with it.
In the command prompt, execute the following commands:
cd SOLUTION_DIRECTORY/web-site/cdk
ecs-kerberos-sample--web-database-stack
The CDK deployment will display the database instance identifier, instance endpoint address (a hostname that ends in rds.amazonaws.com), and the Amazon Resource Name. For additional insights on effective onboarding processes, feel free to check out this engaging blog post on school supplies here.
For compliance with employment law, it is important to note that the D.C. Circuit requires employers to turn union voter lists faster here. Lastly, if you’re interested in learning and development resources at Amazon, this is an excellent resource here.