I will add a follow-up question...
Putting aside any of the JDK KerberosTicket stuff, is there a way in
Kerby to perform a renewal for a TGT?
All calls for requestTgt go through a code path that expects to create
one of the following:
if (requestOptions.contains(KrbOption.USE_PASSWD)) {
asRequest = new AsRequestWithPasswd(context);
} else if (requestOptions.contains(KrbOption.USE_KEYTAB)) {
asRequest = new AsRequestWithKeytab(context);
} else if (requestOptions.contains(PkinitOption.USE_ANONYMOUS)) {
asRequest = new AsRequestWithCert(context);
} else if (requestOptions.contains(PkinitOption.USE_PKINIT)) {
asRequest = new AsRequestWithCert(context);
} else if (requestOptions.contains(TokenOption.USE_TOKEN)) {
asRequest = new AsRequestWithToken(context);
} else if (requestOptions.contains(TokenOption.USER_ID_TOKEN)) {
asRequest = new AsRequestWithToken(context);
}
But shouldn't there be a request where you could send a TGT with RENEW
without having the original keytab/password/etc?
Otherwise if you are sending the password or keytab again then it is
really just a new ticket.
On Wed, May 24, 2023 at 2:37 PM Bryan Bende <[email protected]> wrote:
>
> Hello,
>
> I've been using Kerby to integrate with some existing JAAS based code
> that expects to end up with a Subject having a KerberosTicket, and
> I've been basing the work off this example from the Kerby code base
> [1].
>
> Everything works correctly for the initial login, but now I want to be
> able to issue a renewal. Currently we do this by finding the
> KerberosTicket inside the Subject and calling the ticket's refresh()
> method. This creates an instance of sun.security.krb5.Credentials
> using all of the available fields from the KerberosTicket and then
> calls renew() on the credentials instance, which then does the
> following:
>
> return new KrbTgsReq(options,
> this,
> server,
> serverAlias,
> null, // from
> null, // till
> null, // rtime
> null, // eTypes
> cAddr,
> null,
> null,
> null).sendAndGetCreds();
>
> The issue here is that passing in null for rtime (which it could have
> passed in the existing value for), causes a code path to go into some
> static JAAS stuff in Config and read a renew time from /etc/krb5.conf,
> which is not the krb5.conf that was originally used to create this
> ticket, so it can cause an error depending on the differences in the
> renew lifetime between the two configs.
>
> I realize the above is JDK code and can't be controlled by anyone
> here, but I wanted to see if anyone that has worked with Kerby knows
> of another way to do this, or in general how to refresh a
> KerberosTicket that was created from a KerbyClient.
>
> My first attempt was to create a sub-class of KerberosTicket and
> override the refresh method, however it relies on calling an init
> method that is private so there is no way for a sub-class to modify
> the state after creation.
>
> My second attempt was to allow for using a different type of ticket
> interface, instead of KerberosTicket, but then other code that uses
> the Subject like SASL stuff will expect to look for KerberosTicket in
> the Subject. So it seems like it has to produce KerberosTicket.
>
> Thanks for any ideas.
>
> - Bryan
>
> [1]
> https://github.com/apache/directory-kerby/blob/trunk/kerby-kerb/kerb-client/src/main/java/org/apache/kerby/kerberos/kerb/client/jaas/TokenAuthLoginModule.java#L154
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
