Re: Use AD-account as login into Postgres.

From: Gabriel Guillem Barceló Soteras <gbarcelo(at)parlamentib(dot)es>
To: Stephen Frost <sfrost(at)snowman(dot)net>, Holger Jakobs <holger(at)jakobs(dot)com>
Cc: "pgsql-admin(at)lists(dot)postgresql(dot)org" <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Re: Use AD-account as login into Postgres.
Date: 2024-02-23 08:02:45
Message-ID: DU0PR08MB7921207CB5A0CF43B81145A1A6552@DU0PR08MB7921.eurprd08.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Still, in Windows environments, PostgreSQL uses a separated keytab in filesystem.
This is *nix-fashioned way to give an identity to the process.

Windows native way would be service with MSA/gMSA identoty configured (or computter account i.e. NETWORK SERVICE) , but I think that is not possible...

Create dedicated account (POWERSHELL)

New-ADUser -Name 'postgresqlsa' -GivenName PostgreSQLSA -SamAccountName 'postgresqlsa' -DisplayName ‘SA PostgreSQL' -UserPrincipalName 'postgresqlsa(at)dom(dot)internal' -AccountPassword (ConvertTo-SecureString $(new-guid).Guid -AsPlainText -Force) -PasswordNeverExpires $true -Enabled $true -ChangePasswordAtLogon $false

Set SPN to Postgres service account (windows commands)

setspn -S postgres/postgres.dom.internal postgresqlsa

Note: recommend to put spn as postgres/… (downcase) libpq has a default service account keyword as ‘postgres’. If you SPN starts with POSTGRES, all your clients will have to put an extra parameter :) (i.e. krbsrvname=POSTGRES)
Dump servcie account keytab, this will invalidate current servcie account credentials. CAUTION: Further executions of this command with same SA as target will invalidate previous keytab files.

# Powershell

ktpass -out postgresqlsa.dom.int.keytab -princ postgres/postgres(dot)dom(dot)internal(at)DOM(dot)INTERNAL /pass $(new-guid).Guid /mapuser POSTGRESQLSA(at)DOM(dot)INTERNAL<mailto:POSTGRESQLSA(at)DOM(dot)INTERNAL> /mapop set /crypto all /ptype KRB5_NT_PRINCIPAL /DumpSalt
Password does not matter, it will reset a password with random key.
pg_hba.conf
hostgssenc all pg_user(at)dom(dot)internal<mailto:pg_user(at)dom(dot)internal> 10.20.200.0/16 gss include_realm=1 krb_realm=DOM.INTERNAL
Then, on postgres.conf (*NIX or Windows)

# GSSAPI using Kerberos

krb_server_keyfile = '/etc/postgressqlsa.dev.int.keytab'

krb_caseins_users = on

There is no need for POSTGRESQL server to be ‘domain-joined’
Restart postgresql server, add desired user login, and authenticate with your client:
(you need Bash/Powershell with GSSAPI/Kerberos context, i.e. use kinit if neeeded on *NIX systems or be logged with domain account in windows)
# krbsrvname=postgres is optional, because we set up SPN lower case!

[pg_user(at)postgres-client ~]$ psql "user=pg_user(at)dom(dot)internal host=postgres.dom.internal krbsrvname=postgres dbname=postgres

Note that I have not touched pg_ident.conf, and created a login instead...

Best,

Gabriel Barceló
gbarcelo(at)parlamentib(dot)es<mailto:gbarcelo(at)parlamentib(dot)es>

On 22/2/24, 18:49, "Stephen Frost" <sfrost(at)snowman(dot)net> wrote:
Greetings,

* Holger Jakobs (holger(at)jakobs(dot)com<mailto:holger(at)jakobs(dot)com>) wrote:
> SSPI using AD accounts for authentication works only in a complete Windows
> environment. The client and the server machine have to be member of the same
> AD environment, which isn't possible for non-Windows machines. Otherwise,
> there is no trust between the machines.

This isn't accurate- you can certainly have cross-realm trust between
Windows and non-Windows realms and you can also have non-Windows systems
joined to a Windows realm. On the Windows systems, this uses SSPI, and
on the non-Windows systems it uses GSSAPI, but the two are compatible
and will work with each other just fine for authentication.

> An automatic creation of PostgreSQL roles from AD accounts has to be done
> outside PostgreSQL, i. e. by a script running regularly.

This is accurate, thoguh there are tools out there to do this for you,
such as: https://github.com/larskanis/pg-ldap-sync

Thanks,

Stephen

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Laurenz Albe 2024-02-23 09:08:14 Re: Would you ever recommend Shared Disk Failover for HA?
Previous Message vignesh kumar 2024-02-23 07:38:33 Re: Would you ever recommend Shared Disk Failover for HA?