本页面介绍了 PostgreSQL 如何使用通用安全服务应用编程接口 (GSSAPI) 在 AlloyDB Omni 中与 Active Directory 集成,并介绍了关键的 Kerberos 概念。KerberosKerberos 是为 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"]],["最后更新时间 (UTC):2025-09-04。"],[],[],null,["# Active Directory overview\n\nSelect a documentation version: 16.8.0keyboard_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/16.8.0/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/16.8.0/docs/integrate-active-directory).\n- [Integrate Active Directory user support on Kubernetes](/alloydb/omni/16.8.0/docs/integrate-active-directory-kubernetes-operator).\n- [Integrate Active Directory group support with AlloyDB Omni](/alloydb/omni/16.8.0/docs/integrate-ad-group-support-alloydb-omni).\n- [Integrate Active Directory group support on Kubernetes](/alloydb/omni/16.8.0/docs/integrate-ad-group-support-kubernetes-operator).\n- [Troubleshoot Active Directory integration in AlloyDB Omni](/alloydb/omni/16.8.0/docs/troubleshoot-active-directory-integration)."]]