I should clarify something I mentioned earlier. You can connect to the server with user/postgres@REALM. That's a good way to distinguish between a user's general privileges and his postgresql-specific privileges. (You can easily map user/postgres@REALM to database user 'user'.)
The problem is connecting to the server using the JDBC driver. It currently uses the connection username and password to log into the KDC and also provides the username to the database. That works fine with a simple username but gets confused with principal names like above. What I plan to add is the ability to specify a keytab instead of the username and password for the JDBC driver. I banged my head against the wall for awhile before downloading the code and single-stepping through the login process. :-)
On Thu, Jun 2, 2016 at 6:18 PM, Stephen Frost <sfrost@xxxxxxxxxxx> wrote:
All,
* Bear Giles (bgiles@xxxxxxxxxxxxxx) wrote:
> I remember reading comments in the code that case matters - postgres and
> POSTGRES are not the same - but I'm drawing a blank on the rest. I just
> started looking at the code myself though - others probably have more
> experience.
That's correct, case absolutely matters and it needs to match.
There are options in postgresql.conf to control what's expected. This
is a source of common issue when coming from Windows clients to Linux
servers (or the other way around).
In particular, review section 19.3.3 of the 9.5 docs:
https://www.postgresql.org/docs/9.5/static/auth-methods.html#GSSAPI-AUTH
For the client side, review krbsrvname:
https://www.postgresql.org/docs/9.5/static/libpq-connect.html#LIBPQ-PARAMKEYWORDS
Check the klist from the client side and also look at the keytab that's
on the server and what's in the KDC database and make sure they all
match. What the client asks for from the KDC needs to be what the KDC
has and what is installed in the keytab on the server for it all to
work.
Thanks!
Stephen
