本頁面說明如何使用通用安全服務應用程式設計介面 (GSSAPI),在 AlloyDB Omni 中將 PostgreSQL 與 Active Directory 整合,並介紹重要的 Kerberos 概念。Kerberos 是 Active Directory 採用的驗證通訊協定。
Active Directory 是 Microsoft 為 Windows 網域網路開發的目錄服務。Active Directory 是一種集中式標準系統,可自動管理使用者資料、安全性和分散式資源的網路。這個目錄服務提供單一管理點,可集中管理使用者帳戶、群組和其他網路物件。Active Directory 的主要功能是驗證,可確認使用者身分和授權,並授予使用者存取網路中特定資源的權限。
Active Directory 元件
領域是 Kerberos 驗證的管理網域。就 Active Directory 而言,領域等同於 Active Directory 網域。領域代表使用者、電腦和服務的邏輯群組,這些群組共用相同的驗證資料庫。設定 Kerberos 時,您必須指定用戶端和服務所屬的領域。領域是網域名稱的大寫版本,舉例來說,如果網域是 ad.example.com,則領域為 AD.EXAMPLE.COM。
金鑰發布中心 (KDC) 是核心 Kerberos 服務,會在 Active Directory 中的每個網域控制器上執行。KDC 的主要功能如下:
驗證服務 (AS):在初始登入時驗證使用者身分,例如登入 Windows 時,並發出票證授權票證 (TGT)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-04 (世界標準時間)。"],[],[],null,["# Active Directory overview\n\nSelect a documentation version: Current (16.8.0)keyboard_arrow_down\n\n- [Current (16.8.0)](/alloydb/omni/current/docs/active-directory-overview)\n- [16.8.0](/alloydb/omni/16.8.0/docs/active-directory-overview)\n\n\u003cbr /\u003e\n\n|\n| **Preview\n| --- [AlloyDB Omni](/alloydb/omni/current/docs/overview)**\n|\n|\n| This feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| You can process personal data for this feature as outlined in the\n| [Cloud Data Processing\n| Addendum](/terms/data-processing-addendum), subject to the obligations and restrictions described in the agreement under\n| which you access Google Cloud.\n|\n| Pre-GA features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n\nThis page describes how PostgreSQL integrates with Active Directory in\nAlloyDB Omni using the Generic Security Services Application Programming\nInterface (GSSAPI), and it introduces key Kerberos concepts.\n[*Kerberos*](https://en.wikipedia.org/wiki/Kerberos_(protocol)) is the\nauthentication protocol that powers Active Directory.\n\n[Active Directory](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview)\nis a directory service developed by Microsoft for Windows domain networks.\nActive Directory is a centralized, standardized system that automates network\nmanagement of user data, security, and distributed resources. This directory\nservice provides a single point of administration for user accounts, groups, and\nother network objects. A key function of Active Directory is authentication,\nwhich confirms a user's identity and authorization, and grants the user access\nto specific resources on the network.\n\nActive Directory components\n---------------------------\n\nA [*realm*](https://web.mit.edu/kerberos/kfw-4.1/kfw-4.1/kfw-4.1-help/html/kerberos_terminology.htm#:%7E:text=Kerberos%20realms%20are%20a%20way,Windows%2C%20realms%20are%20called%20domains.)\nis the administrative domain for Kerberos authentication. In the context of\nActive Directory, a realm is equivalent to an Active Directory domain. Realms\nrepresent a logical group of users, computers, and services that share a common\nauthentication database. When you configure Kerberos, you must specify the realm\nthat your clients and services belong to. A realm is an uppercase version of the\ndomain name---for example, if the domain is `ad.example.com`, then the realm is\n`AD.EXAMPLE.COM`.\n\nThe\n[*Key Distribution Center*](https://web.mit.edu/kerberos/krb5-1.3/krb5-1.3.3/doc/krb5-install.html#:%7E:text=Introduction%2C%20Up:Introduction-,What%20is%20Kerberos%20and%20How%20Does%20it%20Work?,additional%20tickets%20is%20user%2Dtransparent.)\n(KDC) is a core Kerberos service that runs on every domain controller in\nActive Directory. The KDC has the following primary functions:\n\n- 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).\n- 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.\n\nA\n[*principal*](https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-user/What-is-a-Kerberos-Principal_003f.html)\nis a unique identity in a Kerberos realm to which tickets can be assigned. The\nfollowing are the main types of principals:\n\n- User principals: represent human users---for example, `username@REALM`.\n- 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.\n\nA\n[*keytab*](https://web.mit.edu/kerberos/krb5-devel/doc/basic/keytab_def.html)\nor key table file contains a list of principals and their corresponding secret\nkeys, which are derived from the principals' passwords. Services use a keytab\nfile to prove their identity to the KDC and to decrypt service tickets presented\nby clients.\n\nThis approach allows a service like PostgreSQL to authenticate\nitself to the Kerberos system without requiring human interaction or storing a\nplain text password on the server. The keytab file is highly sensitive and must\nbe securely stored and protected.\n\nPostgreSQL integration with Active Directory\n--------------------------------------------\n\nIntegrating PostgreSQL with Active Directory gives you centralized\nuser management based on corporate identities, which enhances your database security.\n\nTo support authentication, PostgreSQL offers\nthe following methods for integrating with Active Directory:\n\n- Lightweight Directory Access Protocol (LDAP): you can configure\n PostgreSQL to authenticate users against an Active Directory server using\n the LDAP protocol. When a user tries to connect to the\n database, PostgreSQL communicates with the Active Directory server over\n LDAP to verify the user's credentials, which are typically a username and password.\n This method uses Active Directory as an external authentication\n provider.\n\n- Generic Security Services Application Program Interface (GSSAPI) with\n Kerberos: this is a more secure and complex method that uses the\n Kerberos protocol, which is the default authentication mechanism in Active\n Directory. GSSAPI provides a standard interface for applications to access\n security services.\n\nWhile both LDAP and GSSAPI achieve the goal of Active Directory integration, GSSAPI\nwith Kerberos is the more secure and robust approach for\nenterprise environments due to its strong, ticket-based cryptographic\nauthentication. This page addresses implementing Active Directory integration\nfor AlloyDB Omni using the GSSAPI method.\n\nActive Directory authentication with GSSAPI\n-------------------------------------------\n\nAlloyDB Omni lets you authenticate over Kerberos using Active\nDirectory as an authentication backend. The steps to achieve authentication are\nshown in the following diagram.\n\n1. The client `psql` initiates an authentication request using the Authentication Service (AS) in the Key Distribution Center (KDC).\n2. 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.\n3. 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.\n4. 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.\n5. The client sends the encrypted service ticket (T2) to the PostgreSQL server.\n6. 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.\n\nWhat's next\n-----------\n\n- [Integrate Active Directory user support with AlloyDB Omni](/alloydb/omni/current/docs/integrate-active-directory).\n- [Integrate Active Directory user support on Kubernetes](/alloydb/omni/current/docs/integrate-active-directory-kubernetes-operator).\n- [Integrate Active Directory group support with AlloyDB Omni](/alloydb/omni/current/docs/integrate-ad-group-support-alloydb-omni).\n- [Integrate Active Directory group support on Kubernetes](/alloydb/omni/current/docs/integrate-ad-group-support-kubernetes-operator).\n- [Troubleshoot Active Directory integration in AlloyDB Omni](/alloydb/omni/current/docs/troubleshoot-active-directory-integration)."]]