Hi Marc, Cool!! Thanks a lot for getting the hard issue figured out.
I'm looking at the checksum issue, and trying to go into the context. Did you try the usage value of 10 or 6? Could you give me a snapshot of the stacktrace (or call stack) so I can know sooner about the context? Thanks. Regards, Kai -----Original Message----- From: Marc Boorshtein [mailto:[email protected]] Sent: Monday, November 23, 2015 11:00 AM To: [email protected] Subject: Re: KDC is rejecting my TGS Thanks Kai, I'm making some progress. The first thing I noticed was that we're not setting the authenticatorvno, per the RFC it should be 5. I added that and now I'm getting a new error: Nov 22 21:35:11 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1 etypes {17}) 192.168.2.129: ISSUE: authtime 1448246111, etypes {rep=17 tkt=18 ses=17}, HTTP/[email protected] for krbtgt/[email protected] Nov 22 21:35:11 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (1 etypes {17}) 192.168.2.129: PROCESS_TGS: authtime 0, HTTP/[email protected] for HTTP/[email protected], Inappropriate type of checksum in message Notice that it has the client name so its at least getting decrypted. That probably explains the part of the ASN.1 message that was missing. For the checksum, looking at the rfc: This field contains a checksum of the application data that accompanies the KRB_AP_REQ, computed using a key usage value of 10 in normal application exchanges, or 6 when used in the TGS-REQ PA-TGS-REQ AP-DATA field. Not sure if I'm reading this correctly, but it looks like the KeyUsage being passed into EncryptionUtil.seal is 7 (TGS_REQ). Am I reading the code properly? Does the KeyUsage parameter to seal line up with key usage described in the RFC? Thanks On Sun, Nov 22, 2015 at 5:54 PM, Zheng, Kai <[email protected]> wrote: > Hi Steve, > > Marc is basically calling requestServiceTicketWithTgt. I thought you > had got it work in your side to fix and call > requestServiceTicketWithTgt. If so could you help take a look, and let > know how you did it? Thanks. By the way, could we resolve this issue now? > https://issues.apache.org/jira/browse/DIRKRB-440 > > >> Out of curiosity has this api been tested with active directory at all? > Marc, we considered this in the following issue, but don't have any > progress yet. > https://issues.apache.org/jira/browse/DIRKRB-233 > > What we have tested, AFAIK: > 1. Kerby client -> MIT KDC (mainly TGT); 2. MIT client -> Kerby KDC; > 3. Java client -> Kerby KDC (look at the unit tests, in JAAS, GSSAPI, > and SASL). > > Regards, > Kai > > -----Original Message----- > From: Marc Boorshtein [mailto:[email protected]] > Sent: Sunday, November 22, 2015 10:20 PM > To: [email protected] > Subject: Re: KDC is rejecting my TGS > > Kai, > > I'm setup with FreeIPA on CentOS7 (it gets everything setup very quickly). > Here's my code for generating the tickets: > > KrbClient kerb = new KrbClient(new > File("/Users/mlb/Documents/testkerb")); > > kerb.init(); > kerb.setKdcRealm("RHELENT.LAN"); > > KOptions requestOptions = new KOptions(); > requestOptions.add(KrbOption.CLIENT_PRINCIPAL, > "HTTP/[email protected]"); > requestOptions.add(KrbOption.USE_KEYTAB, true); > requestOptions.add(KrbOption.KEYTAB_FILE, new > File("/Users/mlb/Documents/localdev.keytab")); > requestOptions.add(KrbOption.FORWARDABLE,true); > requestOptions.add(KrbOption.PROXIABLE,false); > requestOptions.add(KrbOption.RENEWABLE_OK,false); > > TgtTicket tgt = kerb.requestTgtWithOptions(requestOptions); > > requestOptions = new KOptions(); > requestOptions.add(KrbOption.USE_TGT, tgt); > requestOptions.add(KrbOption.SERVER_PRINCIPAL, new > PrincipalName("HTTP/[email protected] > ",NameType.NT_UNKNOWN)); > requestOptions.add(KrbOption.FORWARDABLE,true); > requestOptions.add(KrbOption.PROXIABLE,false); > requestOptions.add(KrbOption.RENEWABLE_OK,false); > > kerb.requestServiceTicketWithTgt(requestOptions); > > Out of curiosity has this api been tested with active directory at all? > > I've got to get back to getting MyVD integrated with M20 but I'll be > hopping back into this probably tomorrow or tuesday. > > Thanks > > > On Sun, Nov 22, 2015 at 7:38 AM, Zheng, Kai <[email protected]> wrote: > > > Marc, glad we made some thing clear. I also noted the unknown client > > issue (authtime = 0) and had already checked the MIT codes, but had > > no idea where exactly it is emitted. We need to debug to figure it > > out. I have a MIT KDC installation. May be you could let know how to > > repeat this in my side? In the process, is the TGS-REQ separated from > > AS-REQ? > > If so, you might try use the TGT generated by MIT client -> MIT KDC, > > and then use the TGT for Kerby client -> MIT KDC. I'm working on > > Kerby > > CMS/X509 things, but surely would have some time on this given more > inputs. Thanks. > > > > Regards, > > Kai > > > > -----Original Message----- > > From: Marc Boorshtein [mailto:[email protected]] > > Sent: Sunday, November 22, 2015 11:13 AM > > To: [email protected] > > Subject: Re: KDC is rejecting my TGS > > > > OK, so I fixed the kvno and its still not working. Looking at the > > mit kerberos log I see the following for the control: > > > > Nov 21 21:47:55 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (3 > > etypes > > {17 23 16}) 192.168.2.102: NEEDED_PREAUTH: > > HTTP/[email protected] for krbtgt/[email protected], > > Additional pre-authentication required > > > > Nov 21 21:47:55 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (3 > > etypes > > {17 23 16}) 192.168.2.102: ISSUE: authtime 1448160475, etypes > > {rep=17 > > tkt=18 ses=17}, HTTP/[email protected] for > > krbtgt/[email protected] > > > > Nov 21 21:47:55 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (3 > > etypes > > {17 23 16}) 192.168.2.102: ISSUE: authtime 1448160475, etypes > > {rep=17 > > tkt=18 ses=17}, HTTP/[email protected] for > > HTTP/[email protected] > > > > here's for kerby > > > > Nov 21 21:47:11 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1 > > etypes > > {17}) 192.168.2.102: ISSUE: authtime 1448160431, etypes {rep=17 > > tkt=18 ses=17}, HTTP/[email protected] for > > krbtgt/[email protected] > > > > Nov 21 21:47:11 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (1 > > etypes > > {17}) 192.168.2.102: PROCESS_TGS: authtime 0, <unknown client> for > > HTTP/[email protected], ASN.1 structure is missing a > > required field > > > > The TGS_REQ line shows that the client is unknown...so maybe there's > > an issue with how the TGT is being used to create SGT in Kerby? > > >
