{"Entry":{"collection":"auth","key":"gss","name":"gss","aliases":[],"metadata":{"aliases":[],"category":"Authentication and access control","content_hash":"c005cdef9009c12c405513d4e8fe56d43322f357f5aba2bbe58cc441f5ada3b4","derived_content_hash":"a06aba6e5ba89425c897a4decd79ef56e3d1b7df6fe6dd76e63bbe076727a587","imported_at":"2026-09-30T00:40:33.278921+08:00","name":"gss","name_zh":"","slug":"gss","summary":"Use GSSAPI to authenticate the user. This is only available for TCP/IP connections. See Section 20.6 for details. It can be used in conjunction with GSSAPI encryption."}},"Definition":{"Collection":"auth","Key":"gss","SourceDatabase":"center","Version":"18","SourceTable":"authentication_method","SourceKey":"gss","SourceRevision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","Facts":{"aliases":[],"attributes":{"configuration":"pg_hba.conf","inventory":"User-visible source authentication method","method":"gss"},"comparison_data":{"documented_option_names":["include_realm","krb_realm","map"],"method":"gss"},"comparison_hash":"c58b84e18bba9d75d595bab34b326eb6a8580a80636f79642c4af8843e7123cf","description":["Use GSSAPI to authenticate the user. This is only available for TCP/IP connections. See Section 20.6 for details. It can be used in conjunction with GSSAPI encryption."],"description_zh":"认证方法 gss。","description_zh_html":"\u003cp\u003e认证方法 gss。\u003c/p\u003e\u003cdl\u003e\u003cdt\u003e索引访问方法\u003c/dt\u003e\u003cdd\u003e\u003ccode\u003egss\u003c/code\u003e\u003c/dd\u003e\u003cdt\u003e配置\u003c/dt\u003e\u003cdd\u003e\u003ccode\u003epg_hba.conf\u003c/code\u003e\u003c/dd\u003e\u003c/dl\u003e\u003ch3\u003e同版本中文手册节选\u003c/h3\u003e\u003cp\u003e\n\u003cspan class=\"productname\"\u003eGSSAPI\u003c/span\u003e 是一种在\n    \u003ca class=\"ulink\" href=\"https://datatracker.ietf.org/doc/html/rfc2743\"\u003eRFC 2743\u003c/a\u003e\n    中定义的安全认证行业标准协议。\u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e 支持 \u003cspan class=\"productname\"\u003eGSSAPI\u003c/span\u003e 用于认证、通信加密，或两者兼而有之。\u003cspan class=\"productname\"\u003eGSSAPI\u003c/span\u003e 为支持它的系统提供自动认证（单点登录）。认证本身是安全的。如果使用 \u003cspan class=\"productname\"\u003eGSSAPI\u003c/span\u003e 加密或 \u003cacronym class=\"acronym\"\u003eSSL\u003c/acronym\u003e 加密，沿数据库连接发送的数据将被加密；否则，将不会被加密。\n\u003c/p\u003e\u003cp\u003e\n    当编译 \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e 时，GSSAPI 支持必须被启用，详见\u003ca class=\"xref\" href=\"/zh/docs/18/installation.html\"\u003e第 17 章\u003c/a\u003e。\n   \u003c/p\u003e\u003cp\u003e\n    当 \u003cspan class=\"productname\"\u003eGSSAPI\u003c/span\u003e 使用 \u003cspan class=\"productname\"\u003eKerberos\u003c/span\u003e 时，它会使用一个标准的服务主体（认证身份）名称，其格式为 \u003ccode class=\"literal\"\u003e\u003cem class=\"replaceable\"\u003e\u003ccode\u003eservicename\u003c/code\u003e\u003c/em\u003e/\u003cem class=\"replaceable\"\u003e\u003ccode\u003ehostname\u003c/code\u003e\u003c/em\u003e@\u003cem class=\"replaceable\"\u003e\u003ccode\u003erealm\u003c/code\u003e\u003c/em\u003e\u003c/code\u003e。某个安装实际使用的主体名（principal name）不会以任何方式硬编码在 \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e 服务器中；相反，它是在服务器读取的 \u003cem class=\"firstterm\"\u003ekeytab\u003c/em\u003e 文件中指定的，服务器据此确定自己的身份。如果 keytab 文件中列出了多个主体，服务器会接受其中任意一个。服务器的 realm 名称是服务器可访问的 Kerberos 配置文件中指定的首选 realm。\n   \u003c/p\u003e\u003cp\u003e\n    连接时，客户端必须知道它打算连接的服务器主体名。该主体名中的 \u003cem class=\"replaceable\"\u003e\u003ccode\u003eservicename\u003c/code\u003e\u003c/em\u003e 部分通常是 \u003ccode class=\"literal\"\u003epostgres\u003c/code\u003e，但也可以通过 \u003cspan class=\"application\"\u003elibpq\u003c/span\u003e 的连接参数 \u003ca class=\"xref\" href=\"/zh/docs/18/libpq-connect.html#LIBPQ-CONNECT-KRBSRVNAME\"\u003ekrbsrvname\u003c/a\u003e 选择其他值。\u003cem class=\"replaceable\"\u003e\u003ccode\u003ehostname\u003c/code\u003e\u003c/em\u003e 部分则是 \u003cspan class=\"application\"\u003elibpq\u003c/span\u003e 被告知要连接的完全限定主机名。realm 名称是客户端可访问的 Kerberos 配置文件中指定的首选 realm。\n   \u003c/p\u003e\u003cp\u003e\u003ca href=\"/zh/docs/18/gssapi-auth.html\"\u003e查看完整中文手册与上下文\u003c/a\u003e。\u003c/p\u003e","facts":[{"label":"Method","value":"gss"},{"label":"Configuration","value":"pg_hba.conf"},{"label":"Inventory","value":"User-visible source authentication method"}],"facts_zh":[{"label":"方法","value":"gss"},{"label":"配置","value":"pg_hba.conf"},{"label":"清单","value":"用户可见的源码认证方法"}],"manual_html":"\u003cdiv class=\"sect1\" id=\"GSSAPI-AUTH\"\u003e\n\u003cdiv class=\"titlepage\"\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003ch2 class=\"title\"\u003e20.6. GSSAPI Authentication \u003c/h2\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cp\u003e\u003cspan class=\"productname\"\u003eGSSAPI\u003c/span\u003e is an industry-standard protocol for secure authentication defined in \u003ca class=\"ulink\" href=\"https://datatracker.ietf.org/doc/html/rfc2743\"\u003eRFC 2743\u003c/a\u003e. \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e supports \u003cspan class=\"productname\"\u003eGSSAPI\u003c/span\u003e for authentication, communications encryption, or both. \u003cspan class=\"productname\"\u003eGSSAPI\u003c/span\u003e provides automatic authentication (single sign-on) for systems that support it. The authentication itself is secure. If \u003cspan class=\"productname\"\u003eGSSAPI\u003c/span\u003e encryption or SSL encryption is used, the data sent along the database connection will be encrypted; otherwise, it will not.\u003c/p\u003e\n\u003cp\u003eGSSAPI support has to be enabled when \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e is built; see \u003ca class=\"xref\" href=\"/docs/18/installation.html\" title=\"Chapter 17. Installation from Source Code\"\u003eChapter 17\u003c/a\u003e for more information.\u003c/p\u003e\n\u003cp\u003eWhen \u003cspan class=\"productname\"\u003eGSSAPI\u003c/span\u003e uses \u003cspan class=\"productname\"\u003eKerberos\u003c/span\u003e, it uses a standard service principal (authentication identity) name in the format \u003ccode class=\"literal\"\u003e\u003cem class=\"replaceable\"\u003e\u003ccode\u003eservicename\u003c/code\u003e\u003c/em\u003e/\u003cem class=\"replaceable\"\u003e\u003ccode\u003ehostname\u003c/code\u003e\u003c/em\u003e@\u003cem class=\"replaceable\"\u003e\u003ccode\u003erealm\u003c/code\u003e\u003c/em\u003e\u003c/code\u003e. The principal name used by a particular installation is not encoded in the \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e server in any way; rather it is specified in the \u003cem class=\"firstterm\"\u003ekeytab\u003c/em\u003e file that the server reads to determine its identity. If multiple principals are listed in the keytab file, the server will accept any one of them. The server's realm name is the preferred realm specified in the Kerberos configuration file(s) accessible to the server.\u003c/p\u003e\n\u003cp\u003eWhen connecting, the client must know the principal name of the server it intends to connect to. The \u003cem class=\"replaceable\"\u003e\u003ccode\u003eservicename\u003c/code\u003e\u003c/em\u003e part of the principal is ordinarily \u003ccode class=\"literal\"\u003epostgres\u003c/code\u003e, but another value can be selected via \u003cspan class=\"application\"\u003elibpq\u003c/span\u003e's \u003ca class=\"xref\" href=\"/docs/18/libpq-connect.html#LIBPQ-CONNECT-KRBSRVNAME\"\u003ekrbsrvname\u003c/a\u003e connection parameter. The \u003cem class=\"replaceable\"\u003e\u003ccode\u003ehostname\u003c/code\u003e\u003c/em\u003e part is the fully qualified host name that \u003cspan class=\"application\"\u003elibpq\u003c/span\u003e is told to connect to. The realm name is the preferred realm specified in the Kerberos configuration file(s) accessible to the client.\u003c/p\u003e\n\u003cp\u003eThe client will also have a principal name for its own identity (and it must have a valid ticket for this principal). To use \u003cspan class=\"productname\"\u003eGSSAPI\u003c/span\u003e for authentication, the client principal must be associated with a \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e database user name. The \u003ccode class=\"filename\"\u003epg_ident.conf\u003c/code\u003e configuration file can be used to map principals to user names; for example, \u003ccode class=\"literal\"\u003epgusername@realm\u003c/code\u003e could be mapped to just \u003ccode class=\"literal\"\u003epgusername\u003c/code\u003e. Alternatively, you can use the full \u003ccode class=\"literal\"\u003eusername@realm\u003c/code\u003e principal as the role name in \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e without any mapping.\u003c/p\u003e\n\u003cp\u003e\u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e also supports mapping client principals to user names by just stripping the realm from the principal. This method is supported for backwards compatibility and is strongly discouraged as it is then impossible to distinguish different users with the same user name but coming from different realms. To enable this, set \u003ccode class=\"literal\"\u003einclude_realm\u003c/code\u003e to 0. For simple single-realm installations, doing that combined with setting the \u003ccode class=\"literal\"\u003ekrb_realm\u003c/code\u003e parameter (which checks that the principal's realm matches exactly what is in the \u003ccode class=\"literal\"\u003ekrb_realm\u003c/code\u003e parameter) is still secure; but this is a less capable approach compared to specifying an explicit mapping in \u003ccode class=\"filename\"\u003epg_ident.conf\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eThe location of the server's keytab file is specified by the \u003ca class=\"xref\" href=\"/docs/18/runtime-config-connection.html#GUC-KRB-SERVER-KEYFILE\"\u003ekrb_server_keyfile\u003c/a\u003e configuration parameter. For security reasons, it is recommended to use a separate keytab just for the \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e server rather than allowing the server to read the system keytab file. Make sure that your server keytab file is readable (and preferably only readable, not writable) by the \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e server account. (See also \u003ca class=\"xref\" href=\"/docs/18/postgres-user.html\" title=\"18.1. The PostgreSQL User Account\"\u003eSection 18.1\u003c/a\u003e.)\u003c/p\u003e\n\u003cp\u003eThe keytab file is generated using the Kerberos software; see the Kerberos documentation for details. The following example shows doing this using the \u003cspan class=\"application\"\u003ekadmin\u003c/span\u003e tool of MIT Kerberos:\u003c/p\u003e\n\u003cpre class=\"screen\"\u003e\u003ccode class=\"prompt\"\u003ekadmin% \u003c/code\u003e\u003cstrong class=\"userinput\"\u003e\u003ccode\u003eaddprinc -randkey postgres/server.my.domain.org\u003c/code\u003e\u003c/strong\u003e\n\u003ccode class=\"prompt\"\u003ekadmin% \u003c/code\u003e\u003cstrong class=\"userinput\"\u003e\u003ccode\u003ektadd -k krb5.keytab postgres/server.my.domain.org\u003c/code\u003e\u003c/strong\u003e\n\u003c/pre\u003e\n\u003cp\u003eThe following authentication options are supported for the \u003cspan class=\"productname\"\u003eGSSAPI\u003c/span\u003e authentication method:\u003c/p\u003e\n\u003cdiv class=\"variablelist\"\u003e\n\u003cdl class=\"variablelist\"\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003e\u003ccode class=\"literal\"\u003einclude_realm\u003c/code\u003e\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eIf set to 0, the realm name from the authenticated user principal is stripped off before being passed through the user name mapping (\u003ca class=\"xref\" href=\"/docs/18/auth-username-maps.html\" title=\"20.2. User Name Maps\"\u003eSection 20.2\u003c/a\u003e). This is discouraged and is primarily available for backwards compatibility, as it is not secure in multi-realm environments unless \u003ccode class=\"literal\"\u003ekrb_realm\u003c/code\u003e is also used. It is recommended to leave \u003ccode class=\"literal\"\u003einclude_realm\u003c/code\u003e set to the default (1) and to provide an explicit mapping in \u003ccode class=\"filename\"\u003epg_ident.conf\u003c/code\u003e to convert principal names to \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e user names.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003e\u003ccode class=\"literal\"\u003emap\u003c/code\u003e\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eAllows mapping from client principals to database user names. See \u003ca class=\"xref\" href=\"/docs/18/auth-username-maps.html\" title=\"20.2. User Name Maps\"\u003eSection 20.2\u003c/a\u003e for details. For a GSSAPI/Kerberos principal, such as \u003ccode class=\"literal\"\u003eusername@EXAMPLE.COM\u003c/code\u003e (or, less commonly, \u003ccode class=\"literal\"\u003eusername/hostbased@EXAMPLE.COM\u003c/code\u003e), the user name used for mapping is \u003ccode class=\"literal\"\u003eusername@EXAMPLE.COM\u003c/code\u003e (or \u003ccode class=\"literal\"\u003eusername/hostbased@EXAMPLE.COM\u003c/code\u003e, respectively), unless \u003ccode class=\"literal\"\u003einclude_realm\u003c/code\u003e has been set to 0, in which case \u003ccode class=\"literal\"\u003eusername\u003c/code\u003e (or \u003ccode class=\"literal\"\u003eusername/hostbased\u003c/code\u003e) is what is seen as the system user name when mapping.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003e\u003ccode class=\"literal\"\u003ekrb_realm\u003c/code\u003e\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eSets the realm to match user principal names against. If this parameter is set, only users of that realm will be accepted. If it is not set, users of any realm can connect, subject to whatever user name mapping is done.\u003c/p\u003e\n\u003c/dd\u003e\n\u003c/dl\u003e\n\u003c/div\u003e\n\u003cp\u003eIn addition to these settings, which can be different for different \u003ccode class=\"filename\"\u003epg_hba.conf\u003c/code\u003e entries, there is the server-wide \u003ca class=\"xref\" href=\"/docs/18/runtime-config-connection.html#GUC-KRB-CASEINS-USERS\"\u003ekrb_caseins_users\u003c/a\u003e configuration parameter. If that is set to true, client principals are matched to user map entries case-insensitively. \u003ccode class=\"literal\"\u003ekrb_realm\u003c/code\u003e, if set, is also matched case-insensitively.\u003c/p\u003e\n\u003c/div\u003e","manual_path":"/docs/18/gssapi-auth.html","related":[],"release":{"catalog_fingerprint":"65c93d6048ef30e61023a84f9680fa6a92b1c383b7eb226741170077eb078502","channel":"stable","label":"18.6","major":"18","ref":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2","revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","source_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"},"sections":[],"sections_zh":[],"signature":"","sources":[{"label":"Matching PostgreSQL source archive","sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"label":"PostgreSQL 18 English manual","path":"gssapi-auth.html","sha256":"00da5d918d0d4f101749a389bcef7ae273436d43ddf22dcb5d38d2ec1d7c8735","url":"/docs/18/gssapi-auth.html"},{"label":"PostgreSQL 18 English manual","path":"auth-pg-hba-conf.html","sha256":"6340d4abea2e0a3482afc31bcd1599a0fa10dc28a6f1e05d79ba831e2dd0b4c9","url":"/docs/18/auth-pg-hba-conf.html"}],"tables":[{"columns":[{"key":"name","label":"Option or term"},{"key":"description","label":"Meaning"}],"key":"method-options","rows":[{"description":"If set to 0, the realm name from the authenticated user principal is stripped off before being passed through the user name mapping ( Section 20.2 ). This is discouraged and is primarily available for backwards compatibility, as it is not secure in multi-realm environments unless krb_realm is also used. It is recommended to leave include_realm set to the default (1) and to provide an explicit mapping in pg_ident.conf to convert principal names to PostgreSQL user names.","name":"include_realm"},{"description":"Allows mapping from client principals to database user names. See Section 20.2 for details. For a GSSAPI/Kerberos principal, such as username@EXAMPLE.COM (or, less commonly, username/hostbased@EXAMPLE.COM ), the user name used for mapping is username@EXAMPLE.COM (or username/hostbased@EXAMPLE.COM , respectively), unless include_realm has been set to 0, in which case username (or username/hostbased ) is what is seen as the system user name when mapping.","name":"map"},{"description":"Sets the realm to match user principal names against. If this parameter is set, only users of that realm will be accepted. If it is not set, users of any realm can connect, subject to whatever user name mapping is done.","name":"krb_realm"}],"title":"Documented method options and alternatives"}],"tables_zh":[{"columns":[{"key":"name","label":"选项或术语"},{"key":"description","label":"含义"}],"key":"method-options","rows":[{"description":"如果设为 0，则在通过用户名映射（ 第 20.2 节 ）之前，会先从已认证用户的主体名中去掉 realm 名称。不建议这样做；它主要是为了向后兼容而保留的，因为在多 realm 环境中这并不安全，除非同时使用了 krb_realm 。建议将 include_realm 保持为默认值（1），并在 pg_ident.conf 中提供显式映射，把主体名转换成 PostgreSQL 用户名。","name":"include_realm"},{"description":"允许把客户端主体映射为数据库用户名。详见 第 20.2 节 。对于 GSSAPI/Kerberos 主体，例如 username@EXAMPLE.COM （或者较少见的 username/hostbased@EXAMPLE.COM ），用于映射的用户名分别是 username@EXAMPLE.COM （或 username/hostbased@EXAMPLE.COM ），除非已经将 include_realm 设为 0；在那种情况下，映射时视为系统用户名的是 username （或 username/hostbased ）。","name":"map"},{"description":"设置用于匹配用户主体名的 realm。如果设置了该参数，则只接受来自该 realm 的用户；如果未设置，则允许来自任意 realm 的用户连接，但仍受已执行的用户名映射约束。","name":"krb_realm"}],"title":"手册中的方法选项与替代方式"}],"zh_from":{"authored_translation":"source-derived-structured-summary","body_sha256":"53397a0b0f542fd9a7c78ab8a92b46bd33497ce0098297777362f40ad8560af9","kind":"same-version-chinese-manual-with-source-derived-structured-summary","manual":{"anchor":"","build_id":107,"extraction":"concept-introduction","fragment_sha256":"837f1955a46b92d79a860b6dde25c12b6308d57353bf40fd2a60a19bdca559b7","locale":"zh-Hans","page_key":"gssapi-auth.html","source_hash":"b5d45f5fade99900e7f79412d8e414b51ac64177a6cf3cd5fee23f86556aa750","source_revision":"unknown:rendered-translation-baseline","translated_from_revision":null,"translation_revision":"git:b1b500221dbe5437cfca004d6b04d3f6e422765d;html-sha256:08e987a66af27b98444a8057c256314eafa13611a3fb9e888214fc436824244b","url":"/zh/docs/18/gssapi-auth.html","version":"18"},"runtime_rerun":false,"source_facts_revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}},"ManualEvidence":{"manual_path":"/docs/18/gssapi-auth.html","release":{"catalog_fingerprint":"65c93d6048ef30e61023a84f9680fa6a92b1c383b7eb226741170077eb078502","channel":"stable","label":"18.6","major":"18","ref":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2","revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","source_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"},"sources":[{"label":"Matching PostgreSQL source archive","sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"label":"PostgreSQL 18 English manual","path":"gssapi-auth.html","sha256":"00da5d918d0d4f101749a389bcef7ae273436d43ddf22dcb5d38d2ec1d7c8735","url":"/docs/18/gssapi-auth.html"},{"label":"PostgreSQL 18 English manual","path":"auth-pg-hba-conf.html","sha256":"6340d4abea2e0a3482afc31bcd1599a0fa10dc28a6f1e05d79ba831e2dd0b4c9","url":"/docs/18/auth-pg-hba-conf.html"}]},"MeasuredEvidence":{}},"Text":{"Collection":"auth","Key":"gss","SourceDatabase":"center","Version":"18","Locale":"en","Title":"gss","Summary":"Use GSSAPI to authenticate the user. This is only available for TCP/IP connections. See Section 20.6 for details. It can be used in conjunction with GSSAPI encryption.","BodyHTML":"\u003cdiv id=\"GSSAPI-AUTH\"\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003ch2\u003e20.6. GSSAPI Authentication \u003c/h2\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cp\u003e\u003cspan\u003eGSSAPI\u003c/span\u003e is an industry-standard protocol for secure authentication defined in \u003ca href=\"https://datatracker.ietf.org/doc/html/rfc2743\" rel=\"nofollow\"\u003eRFC 2743\u003c/a\u003e. \u003cspan\u003ePostgreSQL\u003c/span\u003e supports \u003cspan\u003eGSSAPI\u003c/span\u003e for authentication, communications encryption, or both. \u003cspan\u003eGSSAPI\u003c/span\u003e provides automatic authentication (single sign-on) for systems that support it. The authentication itself is secure. If \u003cspan\u003eGSSAPI\u003c/span\u003e encryption or SSL encryption is used, the data sent along the database connection will be encrypted; otherwise, it will not.\u003c/p\u003e\n\u003cp\u003eGSSAPI support has to be enabled when \u003cspan\u003ePostgreSQL\u003c/span\u003e is built; see \u003ca href=\"/docs/18/installation.html\" rel=\"nofollow\"\u003eChapter 17\u003c/a\u003e for more information.\u003c/p\u003e\n\u003cp\u003eWhen \u003cspan\u003eGSSAPI\u003c/span\u003e uses \u003cspan\u003eKerberos\u003c/span\u003e, it uses a standard service principal (authentication identity) name in the format \u003ccode\u003e\u003cem\u003e\u003ccode\u003eservicename\u003c/code\u003e\u003c/em\u003e/\u003cem\u003e\u003ccode\u003ehostname\u003c/code\u003e\u003c/em\u003e@\u003cem\u003e\u003ccode\u003erealm\u003c/code\u003e\u003c/em\u003e\u003c/code\u003e. The principal name used by a particular installation is not encoded in the \u003cspan\u003ePostgreSQL\u003c/span\u003e server in any way; rather it is specified in the \u003cem\u003ekeytab\u003c/em\u003e file that the server reads to determine its identity. If multiple principals are listed in the keytab file, the server will accept any one of them. The server\u0026#39;s realm name is the preferred realm specified in the Kerberos configuration file(s) accessible to the server.\u003c/p\u003e\n\u003cp\u003eWhen connecting, the client must know the principal name of the server it intends to connect to. The \u003cem\u003e\u003ccode\u003eservicename\u003c/code\u003e\u003c/em\u003e part of the principal is ordinarily \u003ccode\u003epostgres\u003c/code\u003e, but another value can be selected via \u003cspan\u003elibpq\u003c/span\u003e\u0026#39;s \u003ca href=\"/docs/18/libpq-connect.html#LIBPQ-CONNECT-KRBSRVNAME\" rel=\"nofollow\"\u003ekrbsrvname\u003c/a\u003e connection parameter. The \u003cem\u003e\u003ccode\u003ehostname\u003c/code\u003e\u003c/em\u003e part is the fully qualified host name that \u003cspan\u003elibpq\u003c/span\u003e is told to connect to. The realm name is the preferred realm specified in the Kerberos configuration file(s) accessible to the client.\u003c/p\u003e\n\u003cp\u003eThe client will also have a principal name for its own identity (and it must have a valid ticket for this principal). To use \u003cspan\u003eGSSAPI\u003c/span\u003e for authentication, the client principal must be associated with a \u003cspan\u003ePostgreSQL\u003c/span\u003e database user name. The \u003ccode\u003epg_ident.conf\u003c/code\u003e configuration file can be used to map principals to user names; for example, \u003ccode\u003epgusername@realm\u003c/code\u003e could be mapped to just \u003ccode\u003epgusername\u003c/code\u003e. Alternatively, you can use the full \u003ccode\u003eusername@realm\u003c/code\u003e principal as the role name in \u003cspan\u003ePostgreSQL\u003c/span\u003e without any mapping.\u003c/p\u003e\n\u003cp\u003e\u003cspan\u003ePostgreSQL\u003c/span\u003e also supports mapping client principals to user names by just stripping the realm from the principal. This method is supported for backwards compatibility and is strongly discouraged as it is then impossible to distinguish different users with the same user name but coming from different realms. To enable this, set \u003ccode\u003einclude_realm\u003c/code\u003e to 0. For simple single-realm installations, doing that combined with setting the \u003ccode\u003ekrb_realm\u003c/code\u003e parameter (which checks that the principal\u0026#39;s realm matches exactly what is in the \u003ccode\u003ekrb_realm\u003c/code\u003e parameter) is still secure; but this is a less capable approach compared to specifying an explicit mapping in \u003ccode\u003epg_ident.conf\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eThe location of the server\u0026#39;s keytab file is specified by the \u003ca href=\"/docs/18/runtime-config-connection.html#GUC-KRB-SERVER-KEYFILE\" rel=\"nofollow\"\u003ekrb_server_keyfile\u003c/a\u003e configuration parameter. For security reasons, it is recommended to use a separate keytab just for the \u003cspan\u003ePostgreSQL\u003c/span\u003e server rather than allowing the server to read the system keytab file. Make sure that your server keytab file is readable (and preferably only readable, not writable) by the \u003cspan\u003ePostgreSQL\u003c/span\u003e server account. (See also \u003ca href=\"/docs/18/postgres-user.html\" rel=\"nofollow\"\u003eSection 18.1\u003c/a\u003e.)\u003c/p\u003e\n\u003cp\u003eThe keytab file is generated using the Kerberos software; see the Kerberos documentation for details. The following example shows doing this using the \u003cspan\u003ekadmin\u003c/span\u003e tool of MIT Kerberos:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003ekadmin% \u003c/code\u003e\u003cstrong\u003e\u003ccode\u003eaddprinc -randkey postgres/server.my.domain.org\u003c/code\u003e\u003c/strong\u003e\n\u003ccode\u003ekadmin% \u003c/code\u003e\u003cstrong\u003e\u003ccode\u003ektadd -k krb5.keytab postgres/server.my.domain.org\u003c/code\u003e\u003c/strong\u003e\n\u003c/pre\u003e\n\u003cp\u003eThe following authentication options are supported for the \u003cspan\u003eGSSAPI\u003c/span\u003e authentication method:\u003c/p\u003e\n\u003cdiv\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cspan\u003e\u003ccode\u003einclude_realm\u003c/code\u003e\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eIf set to 0, the realm name from the authenticated user principal is stripped off before being passed through the user name mapping (\u003ca href=\"/docs/18/auth-username-maps.html\" rel=\"nofollow\"\u003eSection 20.2\u003c/a\u003e). This is discouraged and is primarily available for backwards compatibility, as it is not secure in multi-realm environments unless \u003ccode\u003ekrb_realm\u003c/code\u003e is also used. It is recommended to leave \u003ccode\u003einclude_realm\u003c/code\u003e set to the default (1) and to provide an explicit mapping in \u003ccode\u003epg_ident.conf\u003c/code\u003e to convert principal names to \u003cspan\u003ePostgreSQL\u003c/span\u003e user names.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan\u003e\u003ccode\u003emap\u003c/code\u003e\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eAllows mapping from client principals to database user names. See \u003ca href=\"/docs/18/auth-username-maps.html\" rel=\"nofollow\"\u003eSection 20.2\u003c/a\u003e for details. For a GSSAPI/Kerberos principal, such as \u003ccode\u003eusername@EXAMPLE.COM\u003c/code\u003e (or, less commonly, \u003ccode\u003eusername/hostbased@EXAMPLE.COM\u003c/code\u003e), the user name used for mapping is \u003ccode\u003eusername@EXAMPLE.COM\u003c/code\u003e (or \u003ccode\u003eusername/hostbased@EXAMPLE.COM\u003c/code\u003e, respectively), unless \u003ccode\u003einclude_realm\u003c/code\u003e has been set to 0, in which case \u003ccode\u003eusername\u003c/code\u003e (or \u003ccode\u003eusername/hostbased\u003c/code\u003e) is what is seen as the system user name when mapping.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan\u003e\u003ccode\u003ekrb_realm\u003c/code\u003e\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eSets the realm to match user principal names against. If this parameter is set, only users of that realm will be accepted. If it is not set, users of any realm can connect, subject to whatever user name mapping is done.\u003c/p\u003e\n\u003c/dd\u003e\n\u003c/dl\u003e\n\u003c/div\u003e\n\u003cp\u003eIn addition to these settings, which can be different for different \u003ccode\u003epg_hba.conf\u003c/code\u003e entries, there is the server-wide \u003ca href=\"/docs/18/runtime-config-connection.html#GUC-KRB-CASEINS-USERS\" rel=\"nofollow\"\u003ekrb_caseins_users\u003c/a\u003e configuration parameter. If that is set to true, client principals are matched to user map entries case-insensitively. \u003ccode\u003ekrb_realm\u003c/code\u003e, if set, is also matched case-insensitively.\u003c/p\u003e\n\u003c/div\u003e","SourceRevision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","ContentHash":"85e73c93ece51141cad2f9f0af0b65a9fc2a9ef44b50cd5a43ecf77ca29c690b","Payload":{"description":["Use GSSAPI to authenticate the user. This is only available for TCP/IP connections. See Section 20.6 for details. It can be used in conjunction with GSSAPI encryption."],"manual_html":"\u003cdiv class=\"sect1\" id=\"GSSAPI-AUTH\"\u003e\n\u003cdiv class=\"titlepage\"\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003ch2 class=\"title\"\u003e20.6. GSSAPI Authentication \u003c/h2\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cp\u003e\u003cspan class=\"productname\"\u003eGSSAPI\u003c/span\u003e is an industry-standard protocol for secure authentication defined in \u003ca class=\"ulink\" href=\"https://datatracker.ietf.org/doc/html/rfc2743\"\u003eRFC 2743\u003c/a\u003e. \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e supports \u003cspan class=\"productname\"\u003eGSSAPI\u003c/span\u003e for authentication, communications encryption, or both. \u003cspan class=\"productname\"\u003eGSSAPI\u003c/span\u003e provides automatic authentication (single sign-on) for systems that support it. The authentication itself is secure. If \u003cspan class=\"productname\"\u003eGSSAPI\u003c/span\u003e encryption or SSL encryption is used, the data sent along the database connection will be encrypted; otherwise, it will not.\u003c/p\u003e\n\u003cp\u003eGSSAPI support has to be enabled when \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e is built; see \u003ca class=\"xref\" href=\"/docs/18/installation.html\" title=\"Chapter 17. Installation from Source Code\"\u003eChapter 17\u003c/a\u003e for more information.\u003c/p\u003e\n\u003cp\u003eWhen \u003cspan class=\"productname\"\u003eGSSAPI\u003c/span\u003e uses \u003cspan class=\"productname\"\u003eKerberos\u003c/span\u003e, it uses a standard service principal (authentication identity) name in the format \u003ccode class=\"literal\"\u003e\u003cem class=\"replaceable\"\u003e\u003ccode\u003eservicename\u003c/code\u003e\u003c/em\u003e/\u003cem class=\"replaceable\"\u003e\u003ccode\u003ehostname\u003c/code\u003e\u003c/em\u003e@\u003cem class=\"replaceable\"\u003e\u003ccode\u003erealm\u003c/code\u003e\u003c/em\u003e\u003c/code\u003e. The principal name used by a particular installation is not encoded in the \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e server in any way; rather it is specified in the \u003cem class=\"firstterm\"\u003ekeytab\u003c/em\u003e file that the server reads to determine its identity. If multiple principals are listed in the keytab file, the server will accept any one of them. The server's realm name is the preferred realm specified in the Kerberos configuration file(s) accessible to the server.\u003c/p\u003e\n\u003cp\u003eWhen connecting, the client must know the principal name of the server it intends to connect to. The \u003cem class=\"replaceable\"\u003e\u003ccode\u003eservicename\u003c/code\u003e\u003c/em\u003e part of the principal is ordinarily \u003ccode class=\"literal\"\u003epostgres\u003c/code\u003e, but another value can be selected via \u003cspan class=\"application\"\u003elibpq\u003c/span\u003e's \u003ca class=\"xref\" href=\"/docs/18/libpq-connect.html#LIBPQ-CONNECT-KRBSRVNAME\"\u003ekrbsrvname\u003c/a\u003e connection parameter. The \u003cem class=\"replaceable\"\u003e\u003ccode\u003ehostname\u003c/code\u003e\u003c/em\u003e part is the fully qualified host name that \u003cspan class=\"application\"\u003elibpq\u003c/span\u003e is told to connect to. The realm name is the preferred realm specified in the Kerberos configuration file(s) accessible to the client.\u003c/p\u003e\n\u003cp\u003eThe client will also have a principal name for its own identity (and it must have a valid ticket for this principal). To use \u003cspan class=\"productname\"\u003eGSSAPI\u003c/span\u003e for authentication, the client principal must be associated with a \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e database user name. The \u003ccode class=\"filename\"\u003epg_ident.conf\u003c/code\u003e configuration file can be used to map principals to user names; for example, \u003ccode class=\"literal\"\u003epgusername@realm\u003c/code\u003e could be mapped to just \u003ccode class=\"literal\"\u003epgusername\u003c/code\u003e. Alternatively, you can use the full \u003ccode class=\"literal\"\u003eusername@realm\u003c/code\u003e principal as the role name in \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e without any mapping.\u003c/p\u003e\n\u003cp\u003e\u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e also supports mapping client principals to user names by just stripping the realm from the principal. This method is supported for backwards compatibility and is strongly discouraged as it is then impossible to distinguish different users with the same user name but coming from different realms. To enable this, set \u003ccode class=\"literal\"\u003einclude_realm\u003c/code\u003e to 0. For simple single-realm installations, doing that combined with setting the \u003ccode class=\"literal\"\u003ekrb_realm\u003c/code\u003e parameter (which checks that the principal's realm matches exactly what is in the \u003ccode class=\"literal\"\u003ekrb_realm\u003c/code\u003e parameter) is still secure; but this is a less capable approach compared to specifying an explicit mapping in \u003ccode class=\"filename\"\u003epg_ident.conf\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eThe location of the server's keytab file is specified by the \u003ca class=\"xref\" href=\"/docs/18/runtime-config-connection.html#GUC-KRB-SERVER-KEYFILE\"\u003ekrb_server_keyfile\u003c/a\u003e configuration parameter. For security reasons, it is recommended to use a separate keytab just for the \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e server rather than allowing the server to read the system keytab file. Make sure that your server keytab file is readable (and preferably only readable, not writable) by the \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e server account. (See also \u003ca class=\"xref\" href=\"/docs/18/postgres-user.html\" title=\"18.1. The PostgreSQL User Account\"\u003eSection 18.1\u003c/a\u003e.)\u003c/p\u003e\n\u003cp\u003eThe keytab file is generated using the Kerberos software; see the Kerberos documentation for details. The following example shows doing this using the \u003cspan class=\"application\"\u003ekadmin\u003c/span\u003e tool of MIT Kerberos:\u003c/p\u003e\n\u003cpre class=\"screen\"\u003e\u003ccode class=\"prompt\"\u003ekadmin% \u003c/code\u003e\u003cstrong class=\"userinput\"\u003e\u003ccode\u003eaddprinc -randkey postgres/server.my.domain.org\u003c/code\u003e\u003c/strong\u003e\n\u003ccode class=\"prompt\"\u003ekadmin% \u003c/code\u003e\u003cstrong class=\"userinput\"\u003e\u003ccode\u003ektadd -k krb5.keytab postgres/server.my.domain.org\u003c/code\u003e\u003c/strong\u003e\n\u003c/pre\u003e\n\u003cp\u003eThe following authentication options are supported for the \u003cspan class=\"productname\"\u003eGSSAPI\u003c/span\u003e authentication method:\u003c/p\u003e\n\u003cdiv class=\"variablelist\"\u003e\n\u003cdl class=\"variablelist\"\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003e\u003ccode class=\"literal\"\u003einclude_realm\u003c/code\u003e\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eIf set to 0, the realm name from the authenticated user principal is stripped off before being passed through the user name mapping (\u003ca class=\"xref\" href=\"/docs/18/auth-username-maps.html\" title=\"20.2. User Name Maps\"\u003eSection 20.2\u003c/a\u003e). This is discouraged and is primarily available for backwards compatibility, as it is not secure in multi-realm environments unless \u003ccode class=\"literal\"\u003ekrb_realm\u003c/code\u003e is also used. It is recommended to leave \u003ccode class=\"literal\"\u003einclude_realm\u003c/code\u003e set to the default (1) and to provide an explicit mapping in \u003ccode class=\"filename\"\u003epg_ident.conf\u003c/code\u003e to convert principal names to \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e user names.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003e\u003ccode class=\"literal\"\u003emap\u003c/code\u003e\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eAllows mapping from client principals to database user names. See \u003ca class=\"xref\" href=\"/docs/18/auth-username-maps.html\" title=\"20.2. User Name Maps\"\u003eSection 20.2\u003c/a\u003e for details. For a GSSAPI/Kerberos principal, such as \u003ccode class=\"literal\"\u003eusername@EXAMPLE.COM\u003c/code\u003e (or, less commonly, \u003ccode class=\"literal\"\u003eusername/hostbased@EXAMPLE.COM\u003c/code\u003e), the user name used for mapping is \u003ccode class=\"literal\"\u003eusername@EXAMPLE.COM\u003c/code\u003e (or \u003ccode class=\"literal\"\u003eusername/hostbased@EXAMPLE.COM\u003c/code\u003e, respectively), unless \u003ccode class=\"literal\"\u003einclude_realm\u003c/code\u003e has been set to 0, in which case \u003ccode class=\"literal\"\u003eusername\u003c/code\u003e (or \u003ccode class=\"literal\"\u003eusername/hostbased\u003c/code\u003e) is what is seen as the system user name when mapping.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003e\u003ccode class=\"literal\"\u003ekrb_realm\u003c/code\u003e\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eSets the realm to match user principal names against. If this parameter is set, only users of that realm will be accepted. If it is not set, users of any realm can connect, subject to whatever user name mapping is done.\u003c/p\u003e\n\u003c/dd\u003e\n\u003c/dl\u003e\n\u003c/div\u003e\n\u003cp\u003eIn addition to these settings, which can be different for different \u003ccode class=\"filename\"\u003epg_hba.conf\u003c/code\u003e entries, there is the server-wide \u003ca class=\"xref\" href=\"/docs/18/runtime-config-connection.html#GUC-KRB-CASEINS-USERS\"\u003ekrb_caseins_users\u003c/a\u003e configuration parameter. If that is set to true, client principals are matched to user map entries case-insensitively. \u003ccode class=\"literal\"\u003ekrb_realm\u003c/code\u003e, if set, is also matched case-insensitively.\u003c/p\u003e\n\u003c/div\u003e","related":[],"sections":[],"tables":[{"columns":[{"key":"name","label":"Option or term"},{"key":"description","label":"Meaning"}],"key":"method-options","rows":[{"description":"If set to 0, the realm name from the authenticated user principal is stripped off before being passed through the user name mapping ( Section 20.2 ). This is discouraged and is primarily available for backwards compatibility, as it is not secure in multi-realm environments unless krb_realm is also used. It is recommended to leave include_realm set to the default (1) and to provide an explicit mapping in pg_ident.conf to convert principal names to PostgreSQL user names.","name":"include_realm"},{"description":"Allows mapping from client principals to database user names. See Section 20.2 for details. For a GSSAPI/Kerberos principal, such as username@EXAMPLE.COM (or, less commonly, username/hostbased@EXAMPLE.COM ), the user name used for mapping is username@EXAMPLE.COM (or username/hostbased@EXAMPLE.COM , respectively), unless include_realm has been set to 0, in which case username (or username/hostbased ) is what is seen as the system user name when mapping.","name":"map"},{"description":"Sets the realm to match user principal names against. If this parameter is set, only users of that realm will be accepted. If it is not set, users of any realm can connect, subject to whatever user name mapping is done.","name":"krb_realm"}],"title":"Documented method options and alternatives"}]}},"RequestedLocale":"en","Fallback":false,"Versions":["10","11","12","13","14","15","16","17","18","19","20"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}