Organizations that implement centralized authentication systems experience several advantages:
- Improved Security: Centralized authentication allows for rapid adjustment of user access, enhancing security and facilitating swift responses to potential threats.
- Scalability: Managing access through a centralized database helps organizations grow their networks efficiently while minimizing performance issues.
- Simplified Administration: Centralized authentication streamlines the management of network resources, optimizing operational efficiency.
Integrating relational database authentication with a centralized service like Microsoft Active Directory (AD) is a common approach. Active Directory manages authentication and authorization for users, machines, and applications, enabling administrators to control network resources and enforce security protocols. Kerberos, a network authentication protocol linked with Active Directory, alleviates the authentication load on database instances, allowing them to focus solely on authorization.
Amazon Relational Database Service (RDS) for PostgreSQL and Amazon Aurora PostgreSQL-Compatible Edition support external authentication via Kerberos and Microsoft AD. This centralized management of database user credentials saves time and resources across multiple database instances.
Typically, joining a client to an Active Directory domain is essential for enforcing security policies, access control, and identity management. Yet, the process of linking a Linux client to Active Directory can be complicated and technical, often leading to a frustrating experience compared to Windows clients. Additionally, discrepancies among different Linux distributions and Active Directory can present further challenges.
However, joining a Linux client to an Active Directory domain isn’t a prerequisite to utilizing Kerberos authentication. In this article, we illustrate how to configure a Linux client, operating outside an Active Directory domain, to connect to Amazon RDS for PostgreSQL or Amazon Aurora PostgreSQL-Compatible Edition using Kerberos authentication.
Solution Overview
This solution utilizes Amazon RDS for PostgreSQL linked to AWS Managed Microsoft AD alongside a Linux client. The same methodology can be applied to Amazon Aurora PostgreSQL-Compatible Edition. To facilitate access for users in your on-premises AD domain to Amazon RDS resources within the AWS managed domain, a forest trust relationship must be established between the two domains. This trust allows the AWS managed domain to grant access to resources based on authentication from the on-premises AD domain. In our scenario, we create a one-way forest trust from the on-premises domain to AWS Managed Microsoft AD. This one-way trust enables users from the on-premises AD to access resources in the AWS managed domain, but not the other way around.
For the purposes of demonstration, we employed an Amazon Elastic Compute Cloud (Amazon EC2) Linux client with psql installed. This EC2 Linux client connects to Amazon RDS for PostgreSQL using Kerberos authentication. The specifics of the AD domain are as follows:
- On-premises AD domain – ONPREM.LOCAL
- AWS Managed AD domain – AWSPOSTGRESQL.KERBEROS.COM
Here, users are authenticated by the on-premises domain, while Amazon RDS interacts solely with the AWS Managed domain.
Prerequisites
Before proceeding, ensure that your on-premises and AWS environments are set up as depicted in the architectural diagram. The following prerequisites must be met:
- An on-premises AD or Windows EC2 server configured as your on-premises AD. Refer to Scenario 1: Deploy self-managed AD from the Active Directory Domain Services on AWS for an example of deploying self-managed AD.
- An AWS Managed Microsoft AD.
- A one-way or two-way forest trust established 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 psql.
Trust Between On-Premises AD and AWS Managed Microsoft AD
To execute the solution outlined in this article, a trust relationship between the on-premises AD domain and the AWS Managed domain must be established. This trust allows users from the on-premises domain to access Amazon RDS resources. For heightened security, a one-way trust is advisable unless specific business needs dictate otherwise. A one-way trust is preferable as it grants better control over resource access. In this configuration, only the on-premises AD domain can access resources within the AWS Managed domain while the reverse is not permitted. For guidance on setting up a forest trust between the on-premises domain and AWS Managed domain, refer to Preparing on-premises and AWS environments for external Kerberos authentication for Amazon RDS.
Create Amazon RDS for PostgreSQL Instance and Join to AWS Managed Microsoft AD
For instructions on creating an Amazon RDS for PostgreSQL instance and connecting it to an AWS Managed Microsoft AD, see Using external Kerberos authentication with Amazon RDS for PostgreSQL.
Create User in On-Premises AD
Establish a user named sid@ONPREM.LOCAL in the on-premises Active Directory. This user will be utilized for logging into the Amazon RDS for PostgreSQL instance using Kerberos authentication.
Logging Into Amazon RDS for PostgreSQL Instances on a Linux Platform
You can manage your databases by logging into your Amazon RDS for PostgreSQL instances on a Linux platform. This section outlines the steps needed to configure a Linux client outside an Active Directory domain to connect to Amazon RDS for PostgreSQL using Kerberos authentication.
- Launch an Amazon EC2 Linux 2 instance.
- Connect to the EC2 Linux instance. The connection method will depend on your local operating system, security requirements, network setup, and personal preferences.
- Modify the resolver configuration file located at
/etc/resolv.confto include your AD domain in the search directive along with the domain for the AWS Region. A search entry specifies the domains to query when resolving a name. Additionally, include the DNS IP addresses of your AD in 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 ensure that the changes in resolv.conf persist after a reboot, execute the following command:
sudo chattr +i /etc/resolv.conf
Verify connectivity. If your DNS servers are correctly configured, the ping command should resolve the AD domain to an IP address and execute 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
For further insights, check out this blog post that provides additional context. If you’re looking for authoritative information on this topic, visit this source. Moreover, for an excellent resource on your first day, explore this Reddit discussion.
Location: Amazon IXD – VGT2, 6401 E Howdy Wells Ave, Las Vegas, NV 89115