Message-ID: From: "nrhall (@nrhall)" To: "pgjdbc/pgjdbc" Date: Fri, 24 Jan 2025 10:59:48 +0000 Subject: Re: [pgjdbc/pgjdbc] PR #3451: Support default GSS credentials in the Java Postgres client In-Reply-To: References: List-Id: X-GitHub-Author-Login: nrhall X-GitHub-Comment-Id: 2612247756 X-GitHub-Comment-Type: issue_comment X-GitHub-Issue: 3451 X-GitHub-Repo: pgjdbc/pgjdbc X-GitHub-Type: comment X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/pull/3451#issuecomment-2612247756 Content-Type: text/plain; charset=utf-8 Some testing this morning on Windows suggests that this isn't needed - it just works as it should - you need "jaasLogin=false", and it'll skip trying to use JAAS and just use native Windows auth - `GSS_LIB` defaults to `auto`, so it'll try and use SSPI automatically and succeed. Windows/Kerberos "just works" very well in general. This doesn't work in the same way on Linux, where you could have a variety of different kerberos configurations - e.g. if you have a setup where username@DEFAULT_REALM isn't your default principal name, or you need to use something like KCM as opposed to just a ccache on disk (JAAS/JGSS don't support KCM using the pure Java code, you need it to drop to using the system libs with `com.sun.security.gss.native`, which the JAAS Krb5LoginModule will never do - but the GSSAPI primitives do). In our corp environment, if I just set `jaasLogin=false`, it fails to find a TGT (gets both the realm and my default principal name wrong, and even if it had, it would fail to find an on-disk ccache); adding `gssUseDefaultCreds=true` just says "make no assumptions, just get the TGT that the running user has using the system libraries/configuration". One could argue this is actually the most sensible default (very much in-line with the way SSPI works on Windows), but it's not the way the library has worked historically, so this PR didn't make that be the case.