Thread: GSSAPI/KRB5 and JDBC (again)

Hello again, I've finally had time to test out Kris' patches for
GSSAPI support in the Postgres 8.3 JDBC
(http://ejurka.com/pgsql/jars/gss), but I'm not quite getting it
right, it seems. The JDBC built fine, and it connects properly via
MD5, but it can't get a GSSAPI connection, even with Kris' advice in
http://archives.postgresql.org/pgsql-jdbc/2008-01/msg00154.php

$ export CLASSPATH=/s/postgresql-8.3.3/src/postgresql-jdbc-8.3-603.src/jars/postgresql.jar:.
$ java -Djava.security.auth.login.config=login.conf Jdbc
Uncaught exception in main...
org.postgresql.util.PSQLException: GSS Authentication failed
        at org.postgresql.gss.MakeGSS.authenticate(MakeGSS.java:36)
        at org.postgresql.Driver.makeGSS(Driver.java:775)
        at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:373)
        at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:98)
        at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66)
        at org.postgresql.jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java:124)
        at org.postgresql.jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Connection.java:30)
        at org.postgresql.jdbc4.AbstractJdbc4Connection.<init>(AbstractJdbc4Connection.java:29)
        at org.postgresql.jdbc4.Jdbc4Connection.<init>(Jdbc4Connection.java:24)
        at org.postgresql.Driver.makeConnection(Driver.java:386)
        at org.postgresql.Driver.connect(Driver.java:260)
        at java.sql.DriverManager.getConnection(DriverManager.java:582)
        at java.sql.DriverManager.getConnection(DriverManager.java:154)
        at Jdbc.main(Jdbc.java:15)
Caused by: javax.security.auth.login.LoginException: Integrity check
on decrypted field failed (31)
        at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:696)
        at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:542)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
        at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
        at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
        at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
        at org.postgresql.gss.MakeGSS.authenticate(MakeGSS.java:30)
        ... 13 more
Caused by: KrbException: Integrity check on decrypted field failed (31)
        at sun.security.krb5.internal.crypto.DesCbcEType.decrypt(DesCbcEType.java:154)
        at sun.security.krb5.internal.crypto.DesCbcCrcEType.decrypt(DesCbcCrcEType.java:30)
        at sun.security.krb5.internal.crypto.DesCbcCrcEType.decrypt(DesCbcCrcEType.java:77)
        at sun.security.krb5.EncryptedData.decrypt(EncryptedData.java:168)
        at sun.security.krb5.KrbAsRep.<init>(KrbAsRep.java:87)
        at sun.security.krb5.KrbAsReq.getReply(KrbAsReq.java:449)
        at sun.security.krb5.Credentials.sendASRequest(Credentials.java:406)
        at sun.security.krb5.Credentials.acquireTGT(Credentials.java:355)
        at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:662)
        ... 25 more

login.conf simply contains:

pgjdbc {
   com.sun.security.auth.module.Krb5LoginModule required useTicketCache=true;
};

Jdbc.java is just

import java.sql.*; // import the JDBC
import java.util.*;

public class Jdbc {
    public static void main (String[] args) {
      try {
        Class.forName("org.postgresql.Driver"); // Load the PostgreSQL
JDBC driver

        // Connect to the database

        Properties props = new Properties();
        props.setProperty("user", "koczan");
        props.setProperty("password", "fakepw");
//        props.setProperty("ssl", "true");
        Connection conn =
DriverManager.getConnection("jdbc:postgresql://mitchell.cs.wisc.edu:5432/postgres",
props);

        Statement st = conn.createStatement();
        ResultSet rs = st.executeQuery("select datname from
pg_database order by 1");
        while (rs.next()) {
            System.out.print("Database name returned: ");
            System.out.println(rs.getString(1));
        }
        rs.close();
        st.close();

      } catch (Throwable ex) {
        System.err.println("Uncaught exception in main...");
        ex.printStackTrace();
      }
    }
}

Am I forgetting to set something up? I know that GSSAPI in JDBC is
unsupported currently but it would be really nice to offer it even in
a beta capacity. Thanks.

Peter

* Peter Koczan (pjkoczan@gmail.com) wrote:
> Hello again, I've finally had time to test out Kris' patches for
> GSSAPI support in the Postgres 8.3 JDBC
> (http://ejurka.com/pgsql/jars/gss), but I'm not quite getting it
> right, it seems. The JDBC built fine, and it connects properly via
> MD5, but it can't get a GSSAPI connection, even with Kris' advice in
> http://archives.postgresql.org/pgsql-jdbc/2008-01/msg00154.php

I got it working under Linux based off of his comments..

> Caused by: javax.security.auth.login.LoginException: Integrity check
> on decrypted field failed (31)

So you know, that generally means "wrong password".  Have you tried
kinit'ing first?  Is it prompting you for a password?

> Am I forgetting to set something up? I know that GSSAPI in JDBC is
> unsupported currently but it would be really nice to offer it even in
> a beta capacity. Thanks.

I'm *really* anxious to have GSSAPI support in JDBC and fully
supported..  I've got it working in a test rig, but I need it working
under Linux and Windows for a number of clients and I havn't had time to
make sure all the issues are worked through. :/

    Thanks!

        Stephen

On Thu, Jul 24, 2008 at 7:50 PM, Stephen Frost <sfrost@snowman.net> wrote:
> So you know, that generally means "wrong password".  Have you tried
> kinit'ing first?  Is it prompting you for a password?

I tried kinit, and it didn't work, but putting my real Kerberos
password in the password field worked. It looks like it's trying to
get a new set of credentials/tickets when authenticating, instead of
using stashed or readily available credentials.

This is better than nothing, but it would be very nice to not force
users to specify a password when connecting. It kinda defeats the
purpose of a single-sign-on authentication system, and I'd really
prefer not having users put their password in plaintext files, as it
seems rather insecure. At the very least, the password should be able
to be obscured or encrypted somehow in the connection, but even this
is less than ideal.

Is there any way to tell JDBC to use available KRB5/GSSAPI credentials?

> I'm *really* anxious to have GSSAPI support in JDBC and fully
> supported..  I've got it working in a test rig, but I need it working
> under Linux and Windows for a number of clients and I havn't had time to
> make sure all the issues are worked through. :/

Me too. Now I just have to get SSL working, too.

Peter

* Peter Koczan (pjkoczan@gmail.com) wrote:
> On Thu, Jul 24, 2008 at 7:50 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > So you know, that generally means "wrong password".  Have you tried
> > kinit'ing first?  Is it prompting you for a password?
>
> I tried kinit, and it didn't work, but putting my real Kerberos
> password in the password field worked. It looks like it's trying to
> get a new set of credentials/tickets when authenticating, instead of
> using stashed or readily available credentials.

Ah, yes, I have some recollection of that.  I forget how, exactly, but I
thought that I found a way around that.

> This is better than nothing, but it would be very nice to not force
> users to specify a password when connecting. It kinda defeats the
> purpose of a single-sign-on authentication system, and I'd really
> prefer not having users put their password in plaintext files, as it
> seems rather insecure. At the very least, the password should be able
> to be obscured or encrypted somehow in the connection, but even this
> is less than ideal.

I agree 110%.  It really needs to use the existing credentials, though
it's nice that this shows the basic capability working.

> Is there any way to tell JDBC to use available KRB5/GSSAPI credentials?

I'll try to find some time to test my setup again and see if I can find
a way to do that.  Of course, part of the problem here will end up being
silly applications that insist on being given a username and password.
It'd be nice if those could be left blank, but even so, users will end
up being annoyed by it. :(  My primary JDBC app at the moment is uDig,
in case anyone's listening. ;)

> > I'm *really* anxious to have GSSAPI support in JDBC and fully
> > supported..  I've got it working in a test rig, but I need it working
> > under Linux and Windows for a number of clients and I havn't had time to
> > make sure all the issues are worked through. :/
>
> Me too. Now I just have to get SSL working, too.

Please update us on how that goes. :)

    Thanks,

        Stephen

On Fri, 25 Jul 2008, Peter Koczan wrote:

> I tried kinit, and it didn't work, but putting my real Kerberos
> password in the password field worked. It looks like it's trying to
> get a new set of credentials/tickets when authenticating, instead of
> using stashed or readily available credentials.

It tries to use the provided password only if it doesn't find an existing
set of credentials.  It definitely works for me without a password after
kinit(ing).  Perhaps your ticket cache or keytab is in a non-standard
place?  This is the first and only time I've setup a kerberos server, so I
may have done something unusual on my end too, but I basically just did a
stock Debian install.  Perhaps you need some additional options from here
in your login.conf to let it know things particular to your setup?

http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html

Kris Jurka

On Mon, Jul 28, 2008 at 11:35 PM, Kris Jurka <books@ejurka.com> wrote:
> It tries to use the provided password only if it doesn't find an existing
> set of credentials.  It definitely works for me without a password after
> kinit(ing).  Perhaps your ticket cache or keytab is in a non-standard place?
>  This is the first and only time I've setup a kerberos server, so I may have
> done something unusual on my end too, but I basically just did a stock
> Debian install.  Perhaps you need some additional options from here in your
> login.conf to let it know things particular to your setup?
>
> http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html

Our ticket cache location is somewhat random on each login, but it can
always be reliably found by looking at the environment variable
KRB5CCNAME. I can specify the temporary location, but it would be much
better to somehow be able to grab the auth info from that.

I got this working after a few attempts and reading up on Java auth
configs. It looks like I have to have the line which tells which user
to use, i.e.

        props.setProperty("user", "koczan");

...but it has to be the same as the user/principal in the ticket
cache. It would be nice in the case of web scripts or cron jobs (where
things may run as different or arbitrary users) if I could specify
that elsewhere without having to recompile. I tried specifying the
principal in the config file, and I tried specifying the user on the
command line with -D, but neither worked without the setProperty line
in the .java file.

org.postgresql.util.PSQLException: FATAL: no PostgreSQL user name
specified in startup packet

Still, this is a lot further along compared to where I was a week ago.
Thanks again.

Peter

On Tue, 29 Jul 2008, Peter Koczan wrote:

> Our ticket cache location is somewhat random on each login, but it can
> always be reliably found by looking at the environment variable
> KRB5CCNAME. I can specify the temporary location, but it would be much
> better to somehow be able to grab the auth info from that.

Yes, that would be good, but I'm not sure how to do it.  I'll make a note
to look at this when I take another pass at the code.

> I got this working after a few attempts and reading up on Java auth
> configs. It looks like I have to have the line which tells which user
> to use, i.e.
>
>        props.setProperty("user", "koczan");

Per discussion with Stephen I added some code to pickup the default user
from the environment instead of requiring it:

http://archives.postgresql.org/pgsql-jdbc/2008-05/msg00013.php

So you might need to get the newer code mentioned in that message.

Kris Jurka