Active Directory overview

This page describes how PostgreSQL integrates with Active Directory in AlloyDB Omni using the Generic Security Services Application Programming Interface (GSSAPI), and it introduces key Kerberos concepts. Kerberos is the authentication protocol that powers Active Directory.

Active Directory is a directory service developed by Microsoft for Windows domain networks. Active Directory is a centralized, standardized system that automates network management of user data, security, and distributed resources. This directory service provides a single point of administration for user accounts, groups, and other network objects. A key function of Active Directory is authentication, which confirms a user's identity and authorization, and grants the user access to specific resources on the network.

Active Directory components

A realm is the administrative domain for Kerberos authentication. In the context of Active Directory, a realm is equivalent to an Active Directory domain. Realms represent a logical group of users, computers, and services that share a common authentication database. When you configure Kerberos, you must specify the realm that your clients and services belong to. A realm is an uppercase version of the domain name—for example, if the domain is ad.example.com, then the realm is AD.EXAMPLE.COM.

The Key Distribution Center (KDC) is a core Kerberos service that runs on every domain controller in Active Directory. The KDC has the following primary functions:

  • Authentication Service (AS): verifies a user's identity at the initial sign-in, for example, when you sign into Windows, and issues a Ticket-Granting Ticket (TGT).
  • Ticket-Granting Service (TGS): issues service tickets to authenticated users who present a valid TGT. These service tickets grant access to specific services, like a PostgreSQL database.

A principal is a unique identity in a Kerberos realm to which tickets can be assigned. The following are the main types of principals:

  • User principals: represent human users—for example, username@REALM.
  • Service principals (SPN): represent a specific service on a specific host—for example, postgres/db-server.ad.example.com@REALM. For a client to request a service ticket for your database, the database service must have a registered SPN.

A keytab or key table file contains a list of principals and their corresponding secret keys, which are derived from the principals' passwords. Services use a keytab file to prove their identity to the KDC and to decrypt service tickets presented by clients.

This approach allows a service like PostgreSQL to authenticate itself to the Kerberos system without requiring human interaction or storing a plain text password on the server. The keytab file is highly sensitive and must be securely stored and protected.

PostgreSQL integration with Active Directory

Integrating PostgreSQL with Active Directory gives you centralized user management based on corporate identities, which enhances your database security.

To support authentication, PostgreSQL offers the following methods for integrating with Active Directory:

  • Lightweight Directory Access Protocol (LDAP): you can configure PostgreSQL to authenticate users against an Active Directory server using the LDAP protocol. When a user tries to connect to the database, PostgreSQL communicates with the Active Directory server over LDAP to verify the user's credentials, which are typically a username and password. This method uses Active Directory as an external authentication provider.

  • Generic Security Services Application Program Interface (GSSAPI) with Kerberos: this is a more secure and complex method that uses the Kerberos protocol, which is the default authentication mechanism in Active Directory. GSSAPI provides a standard interface for applications to access security services.

While both LDAP and GSSAPI achieve the goal of Active Directory integration, GSSAPI with Kerberos is the more secure and robust approach for enterprise environments due to its strong, ticket-based cryptographic authentication. This page addresses implementing Active Directory integration for AlloyDB Omni using the GSSAPI method.

Active Directory authentication with GSSAPI

AlloyDB Omni lets you authenticate over Kerberos using Active Directory as an authentication backend. The steps to achieve authentication are shown in the following diagram.

image

  1. The client psql initiates an authentication request using the Authentication Service (AS) in the Key Distribution Center (KDC).
  2. The AS authenticates the client and issues a Ticket Granting Ticket (TGT) (T1) to the client. The TGT is then used to request service tickets.
  3. The client uses the TGT to request a service ticket from the Ticket Granting Service (TGS) in the KDC for the PostgreSQL service. The client is now requesting access to the specific PostgreSQL server.
  4. The TGS validates the TGT and issues a service ticket (T2) to the client. This ticket contains a session key (T3) and is encrypted using the PostgreSQL server's secret key.
  5. The client sends the encrypted service ticket (T2) to the PostgreSQL server.
  6. The PostgreSQL server uses its key (from its keytab file) to decrypt the service ticket (T2), and then the server retrieves the session key (T3) and verifies the ticket's authenticity. If this operation is successful, the server grants access and establishes a secure communication channel with the client using the session key.

What's next