Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pbWEU-0006lT-3K for pgsql-docs@arkaria.postgresql.org; Mon, 13 Mar 2023 00:40:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pbWET-0001SR-1d for pgsql-docs@arkaria.postgresql.org; Mon, 13 Mar 2023 00:40:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pbWBR-0005eY-6W for pgsql-docs@lists.postgresql.org; Mon, 13 Mar 2023 00:37:01 +0000 Received: from tamriel.snowman.net ([2001:470:e38f::11]) by magus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pbWBM-0008ML-AJ for pgsql-docs@lists.postgresql.org; Mon, 13 Mar 2023 00:37:00 +0000 Received: by tamriel.snowman.net (Postfix, from userid 1000) id 3A8295F7B7; Sun, 12 Mar 2023 20:36:53 -0400 (EDT) Date: Sun, 12 Mar 2023 20:36:53 -0400 From: Stephen Frost To: tpo_deb@sourcepole.ch, pgsql-docs@lists.postgresql.org Subject: Re: Make SSPI documentation clearer Message-ID: References: <167846222574.1803490.15815104179136215862@wrigleys.postgresql.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="s9Rp4lR3iXL6IPb8" Content-Disposition: inline In-Reply-To: <167846222574.1803490.15815104179136215862@wrigleys.postgresql.org> User-Agent: Mutt/2.1.4 (2021-12-11) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --s9Rp4lR3iXL6IPb8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Greetings, * PG Doc comments form (noreply@postgresql.org) wrote: > Page: https://www.postgresql.org/docs/15/sspi-auth.html > Description: >=20 > The [current SSPI > documentation](https://www.postgresql.org/docs/current/sspi-auth.html) > reads: >=20 > "SSPI authentication only works when both server and client are running > Windows, or, on non-Windows platforms, when GSSAPI is available." >=20 > I interpret that phrase like this: >=20 > * there's a case where both server and client are running Windows > * there's a case where both are running non-Windows Yeah, that phrasing isn't great. > What about mixed cases? When the client is non-Windows, then can it use > SSPI? No, AFAIK not. So I'd suggest to make that phrase above clearer and > completely explicit: SSPI is Windows-specific, yeah. > "SSPI authentication works when both server and client are running > Windows. >=20 > When the server is on a non-Windows platform then the server must use GSS= API > if it wants to authenticate the client either via Kerberos or via Active > Directory. A client on a Windows platform that connects to a non-Windows > Postgresql server can either use SSPI (strongly encouraged) or GSS (much > more difficult to set up) if it wants to authenticate via Kerberos or Act= ive > Directory. A client from a non-Windows platform must use GSS if it wants = to > authenticate via Kerberos or Active Directory." Rather than work in negative, I feel like it might make more sense to work in positives? That is, perhaps this instead: On Windows platforms, SSPI is the default and most commonly used mechanism. Note that an SSPI client can authenticate to a server which is using either SSPI or GSSAPI, and a GSSAPI client can authenticate to a server which is using either SSPI or GSSAPI. Generally speaking, clients and servers on Windows are recommended to use SSPI while clients and servers on Unix (non-Windows) platforms use GSSAPI. Stricltly speaking, this is all independent of if AD is being used as the KDC or not. Thanks, Stephen --s9Rp4lR3iXL6IPb8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEwf6gbxKhD863zrx/7WyKOINHZFUFAmQOcCAACgkQ7WyKOINH ZFV9EQ/7BHC1iQ5jNkORfREeuFeivLmsreRkP0Sc7/a5LfgTeaXaKINtEU9yKQ+B UEHDhNRRM1Ym6sGTUJ0WUUNYNDNuFX1lV0mX4OIhWR2I8jeJ2Rnam2sMMKwlaS5L xKEnRNhkQ6lz5WpV/Zq+oizKuAzPhpUasIxjk0jnr5MuCIlUnIL5MCr+0S1H1zLo UhH44NcPSypGzpEpe4MEVG0w+iNXQga2rey12FArT3l7MO4SeGU56+gBJCQHt0Ny gCSkrH2MSf0XutM58k4aSxuw01RoSntGSpyY6/D9NN9K6qH9RbuTBKVGTzkmbkco kEbS4BcnxkEGo0N/RhuA3dRHFu4KFnLWpgzgywpqbW3N2RUWNpyrwVoXIOyG/5is pLiwcPSylElprNV0Wvz3LmuUAWPCKJv2DxVw4YlPvfvISUSQ3vPGCRk6wZpncxUJ i2RbrxaAMlfsFHBAwkvicXS2oEE4TtXcFLPtevxth0Z29hlT5vX7ZCNLgIX1LKGW 2C6EZyWxsEzgRKrYKvjCRL9R7Z3f1FvzsOqGRZisjXtJo3mcclaA2l0GXqyFjgwB 2pEjg08rW4J/iLJC5Xe9qx7rUZQvxofjJ1MvAgxLhDoQRR8QPJxyPg+2o/QxhlDH epWGcf0sRle9OxvDwP0u8rccMwvR1UGAb3AzWW/2merc0KY2QLg= =9i1r -----END PGP SIGNATURE----- --s9Rp4lR3iXL6IPb8--