…is slightly less straightforward than you might hope, but helpfully more flexible. For MS SQL Server, integrated security implies that windows user are magically also SQL users and that no password or username is needed to login. But also, that you can no longer choose which user you login as. Postgres is more configurable and more complex. You can specify which users use SSPI and which postgres user(s) each windows user can login as. You can specify, for instance, that you are allowed to use SSPI to login as the postgres
superuser.
Here is how you can login with integrated security, as the user postgres
, whilst still being able to login as a different user with a password.
- Locate and open for editing two files: your
pg_hba.conf
andpg_ident.conf
files. Find them both in the same directory in e.g.C:\Program Files\PostgreSQL\data\pg96
orC:\Program Files\PostgreSQL\10\data\
- In
pg_ident.conf
add a line to map your windows login, inuser@machinename
format, to the postgres user namedpostgres
. You can also add other users. Here's what my lines look like:# MAPNAME SYSTEM-USERNAME PG-USERNAME MapForSSPI chris@YOURMACHINENAMEHERE chris MapForSSPI chris@YOURMACHINENAMEHERE postgres
(In normal unix style, the columns are separated by any amount of space or tab).
- In
pg_hba.conf
, add lines that allow userpostgres
to login with integrated security, whilst still allowing all other users to login with passwords. Again, you can add lines for other users too. Don't forget to put lines targetting specific users above the catchall lines otherwise they will never be reached.# TYPE DATABASE USER ADDRESS METHOD #== lines for specific users for SSPI (or anything else) BEFORE the catchall lines == # IPv4 local connections for SSPI: host all postgres 127.0.0.1/32 sspi map=MapForSSPI host all chris 127.0.0.1/32 sspi map=MapForSSPI # IPv6 local connections for SSPI: host all postgres ::1/128 sspi map=MapForSSPI host all chris ::1/128 sspi map=MapForSSPI #=================================================================================== # IPv4 local connections: host all all 127.0.0.1/32 scram-sha-256 # IPv6 local connections: host all all ::1/128 scram-sha-256
- Restart the Postgres service, for instance with a powershell command
Restart-Service 'PostgreSQL 9.6 Server'
- Trying logging in as user
postgres
:psql -h localhost -U postgres
- Trying logging in as some other user:
psql -h localhost -U someotherusercreatedwithcreaterole
and you should be prompted for a password (unless you already mastered thepgpass.conf
file)
Logging in without specifying a user name
You might expect that SSPI implies not having to specify a username. You would be wrong. Postgres still requires you specify a username when using SSPI, and, as above, allows you to choose which username.
You can however login without a username—with or without SSPI—if there is a postgres user
(i.e., a role
with LOGIN
privilege) with your Windows username (just the name, without the @machinename).
By combining this with the SSPI map above you can then login without typing username or password.
Integrated Security in .Net connection strings
Having done the above I can now use either of
"Host=localhost;Database=MyDb;Integrated Security=True;Username=postgres"
"Host=localhost;Database=MyDb;Integrated Security=True;Username=chris"
as a connection string for the npgsql Ado.Net driver
Reference
https://www.postgresql.org/docs/9.4/static/auth-pg-hba-conf.html and subsequent pages on Authentication methods and the pg_ident.conf file.
Caveats
Why does the title of this post say 'localhost or AD domains'? Because SSPI only works on Windows; and only on either localhost, or a Windows Domain environment as per https://wiki.postgresql.org/wiki/Configuring_for_single_sign-on_using_SSPI_on_Windows
Which brings us to the alternative that does work remotely without Domain servers: putting passwords in the pgpass.conf
file.
Postgres ‘Passwordless’ Login
Storing passwords in plaintext on a windows machine is largely a no-no in most peoples eyes. Unixland is more accepting of it, perhaps because they habitually expect file permissions to deny access to unauthorised users. And don't expect to have virusses scanning their machines.
psql.exe
on Windows will look for a %appdata%\PostGres\pgpass.conf
file (or $env:AppData\PostGres\pgpass.conf
for PowerShellers) and will parse lines in this format:
hostname:port:database:username:password
See https://www.postgresql.org/docs/9.1/static/libpq-pgpass.html for some wildcard options such as
localhost:*:*:chris:mydevpassword
Your plaintext password is then protected by Windows file permissions. Which should be fine for passwords to non-production servers.