Join your Amazon RDS for Db2 instances across accounts to a single shared domain

Amazon RDS for Db2 is the latest addition to the Amazon RDS family of database engines. This service offers a fully managed solution on scalable hardware, designed to deliver optimal performance within minutes. It features an optional Multi-AZ deployment, which synchronously replicates data to a cold standby DB instance in a different Availability Zone in the same AWS Region, providing high availability and reliability. AWS takes care of provisioning, patching, backups, and monitoring of the RDS for Db2 instances, significantly reducing operational overhead. This allows database administrators to focus on enhancing application performance instead of handling routine maintenance tasks.

You can create an Amazon Relational Database Service (Amazon RDS) for Db2 instance by using the AWS Management Console, AWS Command Line Interface (AWS CLI), AWS CloudFormation, Terraform by Hashicorp, AWS Lambda functions, or other methods. You can authenticate to your Amazon RDS for Db2 instance either by using password-based authentications or AWS Microsoft AD directory-based authentication.

In this post, we use AWS Managed Microsoft AD from an AWS account to provide Microsoft AD authentication to Amazon RDS for Db2 in a different account.

To learn about a similar solution for Amazon RDS for SQL Server, see Joining your Amazon RDS DB instances across accounts to a single shared domain. If you want to use AWS Managed Microsoft AD in the same account for Amazon RDS for Db2, refer to Using Kerberos authentication for Amazon RDS for Db2.

Solution overview

The high-level steps to domain-join an RDS for Db2 instance across accounts are as follows:

Create and share an AWS Managed Microsoft AD directory.
Set up the networking environment
Create or modify an RDS for Db2 instance to domain-join the shared directory

The following diagram illustrates this architecture.

We use a requester Virtual Private Cloud (VPC) in AWS account A for AWS Managed Microsoft AD.
The accepter VPC in AWS Account B contains Amazon RDS for Db2.
The CIDR address of the VPCs of different accounts must have different address ranges. Our requester VPC CIDR is 10.1.0.0/16 and the accepter VPC CIDR is 10.0.0.1/16.

Prerequisites

AWS Managed Microsoft AD directory sharing between AWS accounts requires a proper network set up. You should have the following information:

The VPC ID and AWS account ID for the requester and accepter accounts.
The subnets associated with the requester and accepter VPCs to associate them with the route table when creating a peering connection between two VPC.

Create and share an AWS Microsoft AD directory

If you already have an existing AWS Microsoft AD directory, you can skip to the next section of sharing the directory with another AWS account.

Create an AWS Microsoft AD directory

If you’re using AWS Microsoft AD for the first time, refer to Getting started with AWS Managed Microsoft AD.

See Creating your AWS Managed Microsoft AD for more information on how to create an AWS Managed AD directory.

The key steps are as follows:

On the AWS Directory Service console, choose Directories in the navigation pane.
Choose Set up directory.
Select directory type, select AWS Managed Microsoft AD.
Choose Next.
For Edition, select your edition (for this post, we select Standard Edition).
For Directory DNS name, enter your domain name.
For Admin password, enter a password.
Choose Next.
Choose your VPC and appropriate subnets based on how you want to deploy your directory.
If you don’t want your directory service accessible through the internet, choose private subnets only. For this example, we use a VPC having a CIDR range of 10.1.0.1/16 and use two private subnets in us-east-1d and us-east-1f Availability Zones. You can from the Availability Zones in your region for your managed AD to create two domain controllers. Select subnets for the Availability Zones in such a way so that your databases, applications, and others are on the same Availability Zones to reduce latency.
Choose Next.
Choose Create directory.

Directory creation may take 20-45 minutes to complete.

Share the AWS Microsoft AD Directory

The owner of the AWS Microsoft AD directory initiates the sharing of the directory with another account that wants to use it for authentication purposes. Complete the following steps:

On the AWS Directory Service console, choose Directories in the navigation pane. Choose the directory you created (starts with d-).
Click the Directory ID
On the Scale & share tab, choose Create new shared directory.
For AWS account ID(s), enter your AWS account ID field and choose Add.
Choose Share.

A notification will be sent to the administrator of the account ID that you shared. Until they accept the request, the Share status will be Pending acceptance.
As the administrator of the other account, choose Directory shared with me in the navigation pane, select the shared directory ID and choose Review.
Select I agree to pay an additional hourly fee and choose Accept.

The Share status on both accounts should show as Shared.

The shared directory name will be different from the owner directory. You have to use the shared directory name for domain joining the RDS for Db2 instance in its AWS ID account.
In the owner’s account, open the Amazon VPC console.
Choose Security groups in the navigation pane
Confirm the security group Managed AD created (starts with d-)

Set up the networking environment

There are various methods to share two or more VPCs such as VPC peering, AWS Transit Gateway, AWS Private Link, a VPN connection, AWS Direct Connect, a Load Balancer and a Shared VPC. The following table compares these options. You can choose a method appropriate for your requirements.

Method	Latency	Cost	Scalability	Use Case
VPC Peering	Low	Low	Limited (1:1)	Simple, direct VPC connection
Transit Gateway	Medium	Moderate	High	Multiple-VPC, multi-account
Private Link	Low	Moderate	Limited	Exposing service privately
VPN connection	High	Low	Moderate	Secure connection, hybrid setups
Direct Connect	Low	High	High	High speed hybrid connectivity
Load Balancer	Low	Moderate	Limited	Sharing service across VPCs
Shared VPC	Low	Low	High	Multi-account setups in same org

You can chain VPC peering to add more accounts. If you have many accounts, consider Transit Gateway instead. For this post, we use VPC peering.

Note down the VPC ID for the source (AWS Managed Microsoft AD) and target (Amazon RDS for Db2) to use in later steps.

Create a peering connection

Complete the following steps to create a peering connection:

On the Amazon VPC console (in the AWS Managed Microsoft AD account), choose Peering connections in the navigation pane.

Choose Create peering connection.
For VPC ID (Requester), choose the VPC of the requester account.
For Select another VPC to peer with, select Another account enter the account ID.
For Region, specify the Region of the account.
For VPC ID (Accepter), choose the VPC of the accepter account.
Pay close attention in choosing the VPC ID of the requester and accepter accounts.
Choose Create peering connection.

Accept the request in the other VPC

The owner of the accepter VPC must accept the peering connection.

Switch to the accepter account.
On the Amazon VPC console, choose Peering connections in the navigation pane.
Choose the peering connection ID that shows the status as Pending acceptance.
On the Actions menu, choose Accept request.

Edit DNS settings

Complete the following steps to edit DNS settings:

Switch to the requester account.
On the Amazon VPC console, choose Peering connections in the navigation pane.
Choose the newly created peering connection and refresh the page to validate the status change from Pending to Active.
On the DNS tab, choose Edit DNS settings.
Select Allow accepter VPC to resolve DNS of the requester VPC hosts to private IP and choose Save change
Repeat the same steps in the accepter account to allow the requester VPC to resolve DNS of hosts in the accepter VPC to private IP addresses.

Edit the route table in the requester VPC

The requester VPC is the one used for AWS Microsoft AD. We used two private subnets while creating the AWS Microsoft AD directory service. The next important step is to find out the route table associated with these two subnets.

Switch to the requester account.
On the Amazon VPC console, choose Route tables in the navigation pane.
Choose each route table and navigate to the Subnet associations to match the subnets that you used for AWS Managed Microsoft AD.
When you identify the matching route table, on the Action menu, choose Edit routes.
Choose Add route.
Enter the CIDR range of the accepter VPC (10.0.0.0/16 in our case).
On the drop-down menu for Target, choose Peering Connection and then choose the matching peering connection ID starting with pcx-.
Choose Save changes.

Edit the route table in the accepter VPC

The accepter VPC (ending with 485e in our case) is the one that we use for Amazon RDS for Db2. had used a subnet group while creating the RDS for Db2 instance. The next important step is to find the route table associated with subnets in the subnet group.

Switch to the accepter account.
On the Amazon VPC console, choose Route tables in the navigation pane.
Choose each route table and navigate to the Subnet associations tab and check which subnets you are going to use for RDS for Db2 instance.
When you identify the matching route table, on Actions menu, choose Edit routes.
Choose Add route.
Enter the CIDR range of the requester VPC (10.1.0.0/16 in our case).
On the drop-down menu for Target, choose Peering Connection and then select the matching peering connection ID starting with pcx-.
Choose Save changes.
On the Peering connections page, choose the peering connection
On the Route tables tab, confirm that the route table associated with the peering connection.
Check the same for the accepter VPC in the account for Amazon RDS for Db2.

Add a route in the security group for the managed directory

Complete the following steps to add a route in the security group for the managed directory:

Switch to the requester account.
On the Amazon VPC console, choose Security Groups in the navigation pane.
Choose your security group (starts with d-).

You will see the open ports for the directory service. We need to add a route to the accepter VPC (Amazon RDS for Db2 account).
Choose Add rule.
Choose All traffic and add the CIDR range of the accepter VPC (Amazon RDS for Db2 account). For this post, CIDR for the accepter VPC is 10.0.0.0/16.
Choose Save rules.

Test connectivity between the two accounts

Before you add your RDS for Db2 instance using the shared AWS Microsoft AD directory Service, you should test the connectivity between two accounts. Complete the following steps:

Switch to the requester AWS account.
On the AWS Directory Service console, choose Directories in the navigation pane.
Choose the directory you created.
On the Networking & security tab, note the DNS address of both Directory controllers.
In your AWS ID account that has Amazon RDS for Db2, create an Amazon Elastic Compute Cloud (Amazon EC2) instance in the accepter VPC. Use the same VPC that you will use for creating your RDS for Db2 instance.
Connect to the EC2 instance and ping the DNS address of the AWS Microsoft AD directory service (in the requester account).
It should return a response as shown in the following screenshot.
If ICMP is disabled in your security group, you can install the netcat tool in your EC2 instance and run the following code:
```
nc -zv <DNS IP of directory> 53
```
If the ping or nc commands aren’t successful, troubleshoot your VPC peering connections. The followings are some common mistakes:
- Associating the wrong CIDR range while creating the peering connection
- Associating the wrong subnets to the VPC peering routing table
- The directory name used in joining the AD domain from the accepter account is the name of the main directory (in the requester account) and is not the name of the shared directory (in the accepter account)
- The security group of the AWS Managed AD directory doesn’t have a route to the CIDR of the accepter VPC CIDR range
- VPC peering connection settings don’t enable DNS resolution

Create or modify an RDS for Db2 instance to domain-join the shared directory

After successfully configuring and testing the network configuration across accounts, you can either create a new RDS for Db2 instance or modify an existing instance to domain-join the shared directory. For instructions to create an instance, see Creating an Amazon RDS DB instance.

In this section, we show how to domain-join a new instance using both the AWS Management Console and the AWS Command Line Interface (CLI).

Domain-join a new RDS for Db2 instance using the console

On the Amazon RDS console, choose instances in the navigation pane.
Choose Create Instance.
For Engine type select IBM Db2.
Specify your edition and engine version.
Provide information for Credential Settings, Instance configuration, Storage and Availability & durability.
Pay close attention in Connectivity and choose the VPC used in the peering connection.
Make sure that the DB subnet group is the one that belongs to the VPC chosen in the previous step.
Choose your VPC security group.
For Database authentication, select Password and Kerberos authentication.
Choose Browse Directory.
Select the shared directory and choose Choose.
Select the correct DB parameter group that has the IBM customer ID and site ID.
Choose other parameters as appropriate and choose Create database.
After the instance creation is successful, you can choose the instance and check the Connectivity & security The directory used is the shared directory and Kerberos is enabled.

Domain-join a new Amazon RDS for Db2 instance using the AWS CLI

If you’re using the AWS CLI, you need to create a directory access AWS Identity and Access Management (IAM) role that will be attached to the RDS for Db2 instance. This step is not required when using the console because the role is created automatically.

Create a trust policy

echo '{ 
  "Version": "2012-10-17", 
  "Statement": [ 
     { 
       "Effect": "Allow", 
       "Principal": { 
          "Service": [
             "rds.amazonaws.com",
             "directoryservice.rds.amazonaws.com"
          ]
        }, 
        "Action": "sts:AssumeRole" 
     } 
  ] 
}' > trust-policy.json

Create an IAM role

aws iam create-role --role-name AmazonRDSDirectoryServiceRole --assume-role-policy-document file://trust-policy.json

Attach the AmazonRDSDirectoryServiceAccess policy

aws iam attach-role-policy --role-name AmazonRDSDirectoryServiceRole --policy-arn arn:aws:iam::aws:policy/service-role/AmazonRDSDirectoryServiceAccess

Create the subnet group

VPC_ID=<accepter VPC ID>
PROFILE=<your profile>
REGION=<your Region>
SUBNET_IDS=$(aws ec2 describe-subnets \
  --filters "Name=vpc-id,Values=$VPC_ID" \
  --query "Subnets[].SubnetId" \
  --region $REGION --profile $PROFILE \
  --output text)
aws rds create-db-subnet-group \
  --db-subnet-group-name my-subnet-group \
  --db-subnet-group-description "DB subnet group for VPC $VPC_ID" \
    --subnet-ids $SUBNET_IDS

Get the shared directory name:

aws ds describe-directories --query "DirectoryDescriptions[*].[Name,DirectoryId]" --output table

Create the RDS for Db2 instance:

aws rds create-db-instance \
--region us-east-1 \
--db-instance-identifier database-1 \
--allocated-storage 20 \
--db-instance-class db.m6i.xlarge \
--engine db2-se \
--master-username admin \
--master-user-password Passw0rd \
--availability-zone us-east-1d \
--db-parameter-group-name my-db2-se-pg \
--port 8392 \
--no-multi-az \
--engine-version 11.5.9.0.sb00042449.r1 \
--license-model bring-your-own-license \
--no-publicly-accessible \
--storage-type gp3 \
--storage-encrypted \
--no-deletion-protection \
--monitoring-interval 0 \
--vpc-security-group-ids sg-05b6be0a0585113a6 \
--db-subnet-group-name my-subnet-group \
--domain d-9067ddc4f4 \
--domain-iam-role-name AmazonRDSDirectoryServiceRole

Make sure that the security group ID is of the accepter VPC ID.

After the instance is created, check the domain membership:

aws rds describe-db-instances --db-instance-identifier database-1 --query 'DBInstances[].DomainMemberships'

Output:
[
    [
        {
            "Domain": "d-9067ddc4f4",
            "Status": "kerberos-enabled",
            "FQDN": "ad.example.com",
            "IAMRoleName": "AmazonRDSDirectoryServiceRole"
        }
    ]
]

If you already have an existing RDS for Db2 instance, you can either use the console or use the aws rds modify-db-instance command to attach the directory name to the instance.

Clean-up

If you no longer need the shared directory in the Amazon RDS for Db2 account, you can delete or modify the RDS for Db2 instance to switch to the password authentication to remove it from the directory domain. After removing the directory service from all DB instances, you can delete the shared directory from your account. Deleting the shared directory doesn’t delete the main directory service in the other account; it only deletes its proxy in the current account. You can also delete the main directory when not required.

Conclusion

With Amazon RDS for Db2, you can seamlessly authenticate your users and groups with or without Kerberos authentication using a single AWS Microsoft AD directory that can serve multiple accounts. In this post, we showed you the steps to properly configure the network between accounts. For a few accounts, you can chain VPC peering, but if you have large number of AWS accounts, we suggest using Transit Gateway. To learn more joining your RDS for Db2 instances to AWS Managed Microsoft AD for Kerberos authentication, refer to the Using Kerberos authentication for Amazon RDS for Db2.

About the authors

Vikram S Khatri is a Sr. DBE for Amazon RDS for Db2. Vikram has over 20 years of experience in Db2. He enjoys developing new products from the ground up. In his spare time, he practices meditation and enjoys listening to podcasts.

Kanda Zhang is a Sr. Software Developer Engineer for Amazon RDS for Db2. He enjoys coding in Java and Go and over 10+ years of software development experience.

Sumit Kumar is a Senior Solutions Architect at AWS, and enjoys solving complex problems. He has been helping customers across various industries to build and design their workloads on the AWS Cloud. He enjoys cooking, playing chess, and spending time with his family.

Vikrant Dhir is an AWS Solutions Architect, helping systemically important financial services institutions innovate on AWS. He specializes in containers and container security using Amazon EKS. He is an avid programmer proficient in a number of languages such as Java, NodeJS and Terraform.

AWS Database Blog