Preparing on-premises and AWS environments for external Kerberos authentication for Amazon RDS

As database security becomes more and more essential to the success of a business, managing user access to databases effectively has always been a challenge to database administrators (DBAs) and security officers. Traditional database authentication is based on a username-password mechanism. This method unfortunately requires effort from both DBAs and users to maintain the credentials; it also incurs extra work for security officers from an auditing perspective. Integrating relational database authentication with a centralized authentication service such as Microsoft Active Directory (AD) is a common and proven practice to address this challenge.

Kerberos is a network authentication protocol developed by the Massachusetts Institute of Technology (MIT). It uses tickets and symmetric-key cryptography to eliminate the need to transmit passwords over the network. The Kerberos ticket is a certificate issued by an authentication server, encrypted using the server key. Kerberos has been built into Microsoft AD and is designed to authenticate users to network resources, such as Amazon Relational Database Service (Amazon RDS) for PostgreSQL, Amazon Relational Database Service (Amazon RDS) for Oracle, Amazon Aurora PostgreSQL-Compatible Edition and Amazon Relational Database Service (Amazon RDS) for SQL Server.

Amazon RDS for PostgreSQL, Amazon RDS for Oracle, Aurora PostgreSQL and Amazon RDS for SQL Server support external authentication of database users using Kerberos and Microsoft AD, including those running on premises. This feature provides the benefits of single sign-on (SSO) and centralized authentication of database users. Keeping all your user credentials in the same AD saves you time and effort because you can have a centralized place for storing and managing them for multiple database instances.

In this series of posts, we demonstrate how to authenticate database users for Amazon RDS for PostgreSQL, Amazon RDS for Oracle, and Aurora PostgreSQL with Kerberos, your on-premises Microsoft AD, and AWS Managed Microsoft Active Directory provided by AWS Directory Service. For external Kerberos authentication for Amazon RDS for SQL Server, please refer to this blog post.

Trust between the on-premises AD domain and AWS Managed Microsoft AD domain

For the users in your on-premises AD domain to access the Amazon RDS resources in the AWS managed domain, we need to establish a trust relationship between the two domains. Trust relationships provide a mechanism for one domain to allow access to the resources based on the login authentications of another domain.

The flow of communication over trusts is determined by the direction of the trust:

• One-way trust – A unidirectional authentication path created between two domains. In a one-way trust between Domain A and Domain B, when Domain B has configured to trust Domain A, users in Domain A can access resources in Domain B; however, users in Domain B can’t access resources in Domain A.
• Two-way trust –Domain A trusts Domain B, and Domain B trusts Domain A. This configuration means that authentication requests can be passed between the two domains in both directions.

AWS Directory Service supports both one-way and two-way trust. Unless you have specific business requirements, one-way trust is recommended for better security. With one-way trust between your on-premises domain and AWS managed domain, you configure the trust in your on-premises domain as one-way: incoming, and configure the trust in your AWS managed domain as one-way: outgoing. With this configuration, the on-premises domain takes the role of the trusted domain, and the Directory Service managed domain takes the role of the trusting domain. Validated authentication requests travel between the domains in only one direction—allowing accounts in your on-premises domain to authenticate against resources in the AWS managed domain. In this case, users are authenticated by the on-premises domain, whereas Amazon RDS interact only with the AWS managed domain.

Directory Service supports two types of trusts:

• Forest trusts – When you configure a forest trust, you can allow any contiguous namespaced domain in the trusting forest to be accessible to any security principal in the trusted forest. You most likely configure forest trusts if your organization has two or more AD forests. Forest trust provides name suffix routing, which routes the Kerberos authentication requests to the correct domain.
• External trusts – External trusts enable you to configure one domain in one forest to trust a domain in another forest without enabling a transitive trust. With external trust, name suffix routing is not provided.

Microsoft recommends forest trusts where possible. Forest trusts ensure that Kerberos is used whenever possible.

Different database management applications running on different platforms (Windows or Linux) for different Amazon RDS engines require different trust types. 

Amazon RDS for PostgreSQL and Aurora PostgreSQL have the following requirements: 

• Forest trust is required by psql and pgAdmin running on a Windows client. These tools rely on name suffix routing, which is only provided by forest trusts to forward Kerberos authentication requests from an on-premises AD domain to an AWS Managed Microsoft AD domain.
• Both forest trusts and external trusts work for Java-based software on Windows (such as DBeaver) and for applications running on a Linux client (such as psql). For Linux and Java-based software, Kerberos can forward the authentication requests to the AWS Managed Microsoft AD domain based on the [domain_realm] section in the Kerberos configuration file (commonly known as krb5.conf). 

For Amazon RDS for Oracle, the trust type can be either forest trust or external trust, because the Kerberos configuration file (commonly known as krb5.conf) is required by SQL Developer and SQL*Plus (on both Windows and Linux) for cross-domain Kerberos authentication. 

In this post, we use one-way (on-premises domain: incoming and AWS managed domain: outgoing) forest trust between the on-premises domain and AWS managed domain, as shown in following architectural diagram.

Initial infrastructure configurations

For demonstration purposes, we created three AWS accounts. The account on-prem-account simulates your on-premises environment. Accounts aws-acc-1 and aws-acc-2 simulate your AWS environment: AWS Managed Microsoft AD is created in aws-acc-1 and is shared with aws-acc-2; Amazon RDS resources are created in both aws-acc-1 and aws-acc-2. AD users in on-prem-account log in to the Amazon RDS resources in aws-acc-1 and aws-acc-2 via Kerberos and Microsoft AD authentication from the Windows and Linux client joined the on-premises domain.

Important Note: To follow this tutorial you’ll need 3 AWS Accounts. This tutorial will also incur costs of services involved in this demo including following services:

• Amazon Amazon Elastic Compute Cloud (EC2)
• AWS Transit Gateway
• AWS Managed Active Directory
• Amazon RDS

You are responsible for the costs related to your use of any AWS services used while running this Quick Start reference deployment. Prices are subject to change. For more information, see the Cost and Licenses section.

The following are the details about the three accounts:

• on-prem-account – This account has two VPCs: one for the on-premises AD domain onprem.local and one for the on-premises Windows and Linux clients where the on-premises users log in to. The following table summarizes these details.

• aws-acc-1: We create Directory Service in this account. It has two VPCs. The first is for AWS Managed Microsoft AD ad.myaws.com; this directory service is shared with aws-acc-2. The other VPC is for Amazon RDS resources. The following table summarizes these details.

• aws-acc-2: This account has one VPC for Amazon RDS resources; details shown in following table.

We build our environment for external Kerberos and Microsoft AD authentication for Amazon RDS resources based on the preceding environments.

Creating network connections between VPCs

To allow on-premises users to access the Amazon RDS resources, network connections need to be in place among on-prem-account, aws-acc-1, and aws-acc-2. There are different options to build network connections between your on-premises infrastructure and the VPC, and network connections between VPCs. AWS Transit Gateway is one of the options and is recommended.

AWS Transit Gateway connects on-premises networks and VPCs through a central hub. This simplifies your network and puts an end to complex peering relationships. It acts as a cloud router—each new connection is only made one time. We use AWS Transit Gateway to link VPCs when the VPC connection is required.

The solid blue lines in the following diagram indicate the required network connections between VPCs.

On-premises AD and AWS Managed Microsoft AD

After you create the network connections between VPCs, complete the following steps:

1. In the on-prem-account, we create a Windows EC2 server and promote it to be our on-premises AD and domain controller server with following details:

• VPC – on-prem-ad-vpc
• Subnet – on-prem-ad-vpc-sn
• IP – 10.10.0.192
• Domain – onprem.local

For instructions, see Set Up Your Environment for Trusts.

2. In the aws-acc-1 account, we create an AWS Managed Microsoft AD with the following details:

• Edition – Standard
• Directory DNS name – ad.myaws.com
• Directory NetBIOS name – ad
• VPC – aws-acc-1-mad-vpc
• Subnet – aws-acc-1-mad-sn-1, aws-acc-1-mad-sn-2
• IP – 10.20.0.59, 10.20.1.188
• Directory ID – d-97671c6bae

3. After creating the AWS Managed Microsoft AD, share it with aws-acc-2.

The Amazon RDS resources in aws-acc-2 join this shared AWS Managed Microsoft AD.

4. From aws-acc-1, sign in to the Directory Service console.
5. On the Directories page, select myaws.com.
6. On the Actions drop-down menu, choose Share directory.

7. Select Share this directory with other AWS accounts.
8. For AWS account IDs, enter the ID for aws-acc-2.
9. Choose Add.

The share status shows as Pending acceptance.

10. From aws-acc-2, sign in to the Directory Service console.
11. Under Active Directory, choose Directories shared with me.
12. Select the directory ad.myaws.com shared by aws-acc-1 and choose Review.

13. Review the directory sharing invitation, acknowledge the cost, and choose Accept.

The directory share status in aws-acc-1 changes from Pending acceptance to Shared.

Establishing a one-way forest trust

Amazon RDS for PostgreSQL and Aurora PostgreSQL require a forest trust to enable name suffix routing. Name suffix routing allows us to configure how Kerberos authentication requests are routed when we configure a forest trust between two AD forests.

Kerberos authentication for Amazon RDS for Oracle works with forest trusts and external trusts because the domain-to-realm mapping is provided by the Kerberos configuration file (krb5.conf).

We use a one-way (on-premises domain: incoming, AWS managed domain: outgoing) forest trust in this series of posts because a forest trust is recommended and works for Amazon RDS for PostgreSQL, Amazon RDS for Oracle, and Aurora PostgreSQL.

1. In on-prem-account, create a security group to have the following ports open between the onprem.local server and the VPC and subnets of the AWS Managed Microsoft AD:

• • TCP/UDP 53 – DNS
  • TCP/UDP 88 – Kerberos authentication
  • TCP/UDP 389 – LDAP
  • TCP 445 – SMB 

The following screenshot is an example of the inbound rules of a security group associated with the onprem.local server.

2. For an on-premises corporate network, the firewall must have the following ports open between your on-premises clients and the VPC and subnets of the AWS Managed Microsoft AD:

• • TCP/UDP 53 – DNS
  • TCP/UDP 88 – Kerberos authentication
  • TCP/UDP 389 – LDAP
  • TCP/UDP 445 – SMB
  • TCP/UDP 464 – Kerberos authentication
  • UDP 123 – NTP
  • UDP 137-138 – Netlogon
  • TCP 135 – RPC
  • TCP 139 – Netlogon
  • TCP 636 – LDAPS (LDAP over TLS/SSL)
  • TCP 3268-3269 – Global Catalog
  • TCP 1024-65535 – Ephemeral ports for RPC
  • ICMP – All

3. In aws-acc-1, open the Amazon VPC console.
4. Choose Security groups.
5. Search for your AWS Managed AD directory ID.
6. In the search results, select the item with the description “AWS created security group for directory ID directory controllers.”
7. On the Outbound rules tab of that security group, choose Edit.
8. Choose Add another rule.
9. For the new rule, enter the following values:

• • Type – All traffic
  • Protocol – All
  • Destination – The traffic that can leave your AWS managed domain controllers and where it can go in your on-premises network. Specify a single IP address or an IP address range in CIDR.

10. Log in to the onprem.local domain controller server.
11. In DNS, choose New Conditional Forwarder.

12. For DNS Domain, enter the domain name of the AWS Managed Microsoft AD.
13. For IP addresses of the master servers, provide the two IPs of the AD.

You can ignore the red icon that appears next to the IPs.

14. Choose OK.

Creating an incoming forest trust

You now create a one-way: incoming forest trust with AWS Managed Microsoft AD ad.myaws.com.

1. On the onprem.local domain controller server, in Active Directory Domains and Trusts, choose Properties.

2. On the Trusts tab, choose New Trust.

3. Choose Next.

4. For Name, enter the name of AWS Managed Microsoft AD (ad.myaws.com).
5. Choose Next.

6. For Trust Type, select Forest trust.
7. Choose Next.

8. For Direction of Trust, select One-way: incoming.
9. Choose Next.

10. For Sides of Trust, select This domain only.
11. Choose Next.

12. For Trust password, enter a password to use when we create the trust relationship in AWS Managed Microsoft AD in aws-acc-1.
13. Choose Next.

14. In the Trust Selections Complete section, review your settings and choose Next.

15. In the Trust Creation Complete section, review your settings and choose Next.

16. For Confirm Incoming Trust, select No, do not confirm the incoming trust.
17. Choose Next.

18. In the final section, choose Finish.

Creating an outgoing forest trust

Now you can create a one-way: outgoing forest trust in AWS Managed Microsoft AD ad.myaws.com on the Directory Service console in account aws-acc-1.

1. On the Networking & security tab, choose Add trust relationship.

2. For Trust type, select Forest trust.
3. For Existing or new remote domain, enter onprem.local.
4. For Trust password, enter your password.
5. For Trust direction, select One-way: outgoing.
6. For Conditional forwarder, enter 10.10.0.192.
7. Choose Add.

The one-way forest trust is established and verified successfully.

8. After the trust is created, log in to the onprem.local domain controller server.
9. On the Trusts tab, choose your domain (ad.myaws.com) and choose Properties.
10. Make sure that the on-premises Microsoft AD domain name includes a name suffix routing that corresponds to the newly created trust relationship.

Joining Windows and Linux clients to an on-premises domain

Now we create an AD user joedoe@onprem in on-premises AD, and join one Windows client and one Linux client to the on-premises domain onprem.local. Later on, we log in to the Windows and Linux client as joedoe@onprem and connect to Amazon RDS resources with Kerberos and Microsoft AD authentication.

1. Create an AD user joedoe in onprem.local, and make sure that Do not require Kerberos preauthentication is deselected.

2. Create one Windows EC2 server and one Linux EC2 server in on-prem-client-vpc, and join the Windows and Linux server to the on-premises local domain. For the Linux client, configure the /etc/krb5.conf file as the following:

   [joedoe@ip-10-11-1-23 ~]$ cat /etc/krb5.conf
   # Configuration snippets may be placed in this directory as well
   includedir /etc/krb5.conf.d/
   includedir /var/lib/sss/pubconf/krb5.include.d/
   [logging]
    default = FILE:/var/log/krb5libs.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log
   [libdefaults]
    dns_lookup_realm = false
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true
    rdns = false
   default_realm = ONPREM.LOCAL
    default_ccache_name = /tmp/kerbcache
   [realms]
    AD.MYAWS.COM = {
     kdc = ad.myaws.com
     admin_server = ad.myaws.com
    }
    ONPREM.LOCAL = {
     kdc = onprem.local
     admin_server = onprem.local
    }
   [domain_realm]
    .ad.myaws.com = AD.MYAWS.COM
    ad.myaws.com = AD.MYAWS.COM
    .onprem.local = ONPREM.LOCAL
    onprem.local = ONPREM.LOCAL
    .rds.amazonaws.com = AD.MYAWS.COM
    .amazonaws.com.cn = AD.MYAWS.COM
    .amazon.com = AD.MYAWS.COM

Summary

In this post, we talked about the difference between two domain-trust directions, one-way and two-way trust, and the difference between two trust types: forest trust and external trust. To enable external Kerberos authentication for Amazon RDS, a one-way (on-premises domain: incoming, AWS managed domain: outgoing) forest trust is recommended between the on-premises domain and AWS managed domain. We then created the infrastructure and resources for the external Kerberos authentication for Amazon RDS based on three AWS accounts.

Now we have achieved the following:

• Network connections on the on-premises account, aws-acc-1, and aws-acc-2 via AWS Transit Gateway.
• An AWS Managed Microsoft AD ad.myaws.com in aws-acc-1 and shared with aws-acc-2.
• A one-way (on-premises domain: incoming, AWS managed domain: outgoing) forest trust between the on-premises AD domain onprem.local and AWS Managed Microsoft AD domain ad.myaws.com.
• A Windows client and Linux client joined to the on-premises AD domain.
• An on-premises AD user joedoe@onprem, who can log in to the Windows and Linux client with AD authentication.

With this infrastructure in place, we’re now ready for the forthcoming series of posts: Using external Kerberos authentication with Amazon RDS for PostgreSQL, in which you create Amazon RDS for PostgreSQL instances in aws-acc-1 and aws-acc-2 and enable Kerberos and Microsoft AD authentication for database users; Using external Kerberos authentication with Amazon RDS for Oracle; and Using external Kerberos authentication with Amazon Aurora PostgreSQL.

About the Authors

Zhen Wang is an RDS Cloud Support Engineer at Amazon Web Services.

Sundar Raghavan is a Senior Specialist Solutions Architect at Amazon Web Services.