Configure Kerberos authentication for Amazon RDS for PostgreSQL without joining an Active Directory domain

Organizations that adopt centralized authentication mechanisms gain the following benefits:

Enhanced security posture: Centralized authentication enables quick addition or removal of user access throughout the network, giving organizations improved security and the ability to respond quickly to security threats.
Scalability: By controlling access through a centralized database, organizations can scale their network and minimize performance issues.
Ease of administration: Centralized authentication simplifies the management of network resources, making it more efficient.

The practice of integrating relational database authentication with a centralized authentication service, such as Microsoft Active Directory (Microsoft AD), is a well-established and widely used strategy. Active Directory is a centralized authentication and authorization management service for users, computers and applications. It allows administrators to manage network resources and enforce security policies. Kerberos is a network authentication protocol integrated with Active Directory and allows offloading authentication from the database instance. The burden of account administration is significantly reduced as the database instance only has to handle authorization.

Amazon Relational Database Service (Amazon RDS) for PostgreSQL and Amazon Aurora PostgreSQL-Compatible Edition support external authentication of database users using Kerberos and Microsoft AD. This centralized management of database users and authentication saves you time and effort in managing multiple database instances.

The main reasons to join a client to an active directory domain include security policies, access control and centralized identity management. However, the process of joining a Linux client to active directory is highly technical and complex, making it more effortful compared to a seamless experience with Windows clients. Furthermore, there may be compatibility issues between different Linux distributions and active directory which bring in additional challenges.

However, it’s not a requirement to join the Linux client to an active directory domain to use Kerberos authentication. In this post, we demonstrate how to configure a Linux client outside of active directory domain to connect using Kerberos authentication to an Amazon RDS for PostgreSQL or Amazon Aurora PostgreSQL-Compatible Edition.

Solution overview

The solution uses Amazon RDS for PostgreSQL joined to AWS Managed Microsoft AD and a Linux client. You can apply the same approach to use Amazon Aurora PostgreSQL-Compatible Edition. To allow users in your on-premises AD domain to access Amazon RDS resources in the AWS managed domain, a forest trust relationship must be established between the two domains. This forest trust relationship provides a way for AWS managed domain to grant access to resources based on the authentication within the on-premises AD domain. In our solution, we establish a one-way forest trust between the on-premises domain and the AWS Managed Microsoft AD. A one-way forest trust only enables users from the on-premises AD to access resources in the AWS managed domain, but not vice versa.

For demonstration purposes, we have used an Amazon Elastic Compute Cloud (Amazon EC2) Linux client with psql installed. The EC2 Linux client is used to connect to Amazon RDS for PostgreSQL using Kerberos authentication. The AD domain details are as follows:

On-premises AD domain – ONPREM.LOCAL
AWS Managed AD domain – AWSPOSTGRESQL.KERBEROS.COM

In this case, users are authenticated by the on-premises domain, whereas Amazon RDS interacts only with the AWS Managed domain.

Prerequisites

Before we start, make sure that you have prepared your on-premises and AWS environments, as shown in the architectural diagram. You must have the following prerequisites:

An on-premises AD or Windows EC2 server promoted to be our on-premises AD. See Scenario 1: Deploy self-managed AD from the Active Directory Domain Services on AWS guide for an example of self-managed AD deployment.
An AWS Managed Microsoft AD.
A one-way or two-way forest trust between the on-premises domain and AWS Managed domain.
An Amazon RDS for PostgreSQL DB instance joined to the AWS Managed AD.
A user created in the on-premises AD.
Familiarity with the psql.

Trust between on-premises AD and AWS Managed Microsoft AD

To implement the solution in this post, you must establish a trust relationship between the on-premises AD domain and the AWS Managed domain to allow on-premises domain users access to Amazon RDS resources. This trust enables AWS Managed domain to grant access to its resources based on the authentication within on-premises domain. For improved security, a one-way trust is recommended unless you have specific business requirements. One-way trust is preferred as it provides better control over access to resources. In this setup, only the on-premises AD domain can access resources in the AWS Managed domain, while AWS managed domain has no access. Refer Preparing on-premises and AWS environments for external Kerberos authentication for Amazon RDS for guidance on how to setup a forest trust between the on-premises domain and AWS Managed domain.

Create Amazon RDS for PostgreSQL instance and join to an AWS Managed Microsoft AD

Refer Using external Kerberos authentication with Amazon RDS for PostgreSQL for guidance to create an Amazon RDS for PostgreSQL instance and joining to an AWS Managed Microsoft AD.

Create user in on-premises AD

Create a user sid@ONPREM.LOCAL on the on-premises Active Directory. We connect to Amazon RDS for PostgreSQL instance with this user using Kerberos authentication.

Logging in to Amazon RDS for PostgreSQL instances on a Linux platform

You can manage your databases by logging in to your Amazon RDS for PostgreSQL instances on a Linux platform. This section details the steps to configure a Linux client outside of an active directory domain to connect to an Amazon RDS for PostgreSQL using Kerberos authentication.

Launch an Amazon EC2 Linux 2 instance.
Connect to the EC2 Linux instance. The choice of connection method will depend on factors such as local computer operating system, security requirements, network infrastructure and user preferences.
Edit the resolver configuration file located at /etc/resolv.conf to include your AD domain to the search directive along with domain for the AWS Region. A search entry defines the list of domains to search when resolving a name. Moreover, include the DNS IP addresses of your AD to the nameserver directive.

[ec2-user@ip-172-31-80-54 ~]$ sudo vi /etc/resolv.conf 
generated by /usr/sbin/dhclient-script
search ec2.internal
options timeout:2 attempts:5
search awspostgresql.kerberos.com us-east-1.compute.internal
nameserver 172.31.0.74
nameserver 172.31.35.205
nameserver 172.31.0.2

To make the changes in resolv.conf persistent on a reboot, run the following command.

sudo chattr +i /etc/resolv.conf

Verify connectivity. If your DNS servers are configured correctly, the ping command resolves the AD domain to an IP address and runs successfully.

[ec2-user@ip-172-31-80-54 ~]$ ping onprem.local
PING onprem.local (172.31.22.117) 56(84) bytes of data. 
64 bytes from 172.31.22.117 (172.31.22.117): icmp_seq=1 ttl=128 time=1.61 ms 
64 bytes from 172.31.22.117 (172.31.22.117): icmp_seq=2 ttl=128 time=0.965 ms 
64 bytes from 172.31.22.117 (172.31.22.117): icmp_seq=3 ttl=128 time=0.734 ms

The Kerberos client utility kinit is required on the client machine to obtain or renew the Kerberos ticket. The kinit utility is available when you install the krb5-libs and krb5-workstation packages.

[ec2-user@ip-172-31-80-54 ~]$ sudo yum install -y krb5-libs krb5-workstation

Create a krb5.conf file with the following content for an on-premises Microsoft AD. This file contains configuration parameters for the Kerberos 5 library.

[ec2-user@ip-172-31-80-54 ~]$ sudo vi /etc/krb5.conf
# Configuration snippets may be placed in this directory as well
includedir /etc/krb5.conf.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
pkinit_anchors = /etc/pki/tls/certs/ca-bundle.crt
default_realm = ONPREM.LOCAL
default_ccache_name = /tmp/kerbcache
[realms]
ONPREM.LOCAL = {
kdc = onprem.local
admin_server = onprem.local
}
AWSPOSTGRESQL.KERBEROS.COM = {
kdc = awspostgresql.kerberos.com
admin_server = awspostgresql.kerberos.com
}
[domain_realm]
.onprem.local = ONPREM.LOCAL
onprem.local = ONPREM.LOCAL
.awspostgresql.kerberos.com = AWSPOSTGRESQL.KERBEROS.COM
awspostgresql.kerberos.com = AWSPOSTGRESQL.KERBEROS.COM
.rds.amazonaws.com = ONPREM.LOCAL
.amazonaws.com.cn = ONPREM.LOCAL
.amazon.com = ONPREM.LOCAL

Install the psql client tool to connect to Amazon RDS for PostgreSQL. For compatibility, it’s recommended to keep the psql client version same or higher than the PostgreSQL server version. For this use case, we install psql client version 14.

[ec2-user@ip-172-31-80-54 ~]$ sudo amazon-linux-extras install -y postgresql14

[ec2-user@ip-172-31-80-54 ~]$ psql -h postgres.cy3kacpocygw.us-east-1.rds.amazonaws.com -U postgres
Password for user postgres:
psql (14.3)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

Create the database user sid@ONPREM.LOCAL and grant the rds_ad role to this user. The rds_ad role enables the database user to use Kerberos authentication.

postgres=> create user "sid@ONPREM.LOCAL" with login;
CREATE ROLE
postgres=> grant rds_ad to "sid@ONPREM.LOCAL";
GRANT ROLE

Create a Kerberos ticket using command kinit and provide the password for the AD user.

[ec2-user@ip-172-31-80-54 ~]$ kinit sid@ONPREM.LOCAL
Password for sid@ONPREM.LOCAL:

You can list the Kerberos tickets in the cache using the command klist. The default validity for the Kerberos ticket is 10 hours and you can renew the ticket for 7 days. When the ticket validity period expires, you’ll need to request a new Kerberos ticket.

[ec2-user@ip-172-31-80-54 ~]$ klist
Ticket cache: FILE:/tmp/kerbcache
Default principal: sid@ONPREM.LOCAL
Valid starting Expires Service principal
11/17/2022 00:43:00 11/17/2022 10:43:00 krbtgt/ONPREM.LOCAL@ONPREM.LOCAL
renew until 11/24/2022 00:42:56

Connect to the Amazon RDS for PostgreSQL instance using the Kerberos ticket without specifying a password. We’re using the special endpoint when connecting to an on-premises AD. Instead of using the Amazon domain rds.amazonaws.com in the endpoint, use the domain name of the AWS Managed Microsoft AD. You can apply the same approach when connecting to an Amazon Aurora PostgreSQL-Compatible cluster endpoint.

[ec2-user@ip-172-31-80-54 ~]$ psql -h postgres.cy3kacpocygw.us-east-1.awspostgresql.kerberos.com -U sid@ONPREM.LOCAL postgres
psql (14.3)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=> select current_user;
current_user
------------------
sid@ONPREM.LOCAL
(1 row)

Clean up

If you are testing this solution, complete the following steps to remove resources and avoid charges

On the Amazon EC2 console, select the Linux EC2 instance, and on the Instance state menu, choose Terminate instance.
On the Amazon RDS console, select the RDS Postgres instance, and on the Actions menu, choose Delete.
On the AWS Directory Service console, select the directory, and on the Actions menu, choose Delete directory.

Summary

In this post, we guided you through the process of authenticating database users in Amazon RDS for PostgreSQL using Kerberos authentication with a Linux client outside of an active directory domain. You can apply the same approach to Amazon Aurora PostgreSQL-Compatible Edition. This configuration increases flexibility and reduces complexity for users adopting Kerberos for database authentication.

If you have any comments or questions, share them in the comments section.

About the Author

Sid Vantair is a Solutions Architect with AWS covering Strategic accounts. With over a decade of experience in working with relational databases, he thrives on resolving complex technical issues to overcome customer hurdles. Outside of work, he cherishes spending time with his family and fostering inquisitiveness in his children.