directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <kai.zh...@intel.com>
Subject RE: KDC is rejecting my TGS
Date Mon, 23 Nov 2015 03:11:12 GMT
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:mboorshtein@gmail.com] 
Sent: Monday, November 23, 2015 11:00 AM
To: kerby@directory.apache.org
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/s4u.rhelent.lan@RHELENT.LAN
for krbtgt/RHELENT.LAN@RHELENT.LAN

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/s4u.rhelent.lan@RHELENT.LAN for HTTP/freeipa.rhelent.lan@RHELENT.LAN,
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 <kai.zheng@intel.com> 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:mboorshtein@gmail.com]
> Sent: Sunday, November 22, 2015 10:20 PM
> To: kerby@directory.apache.org
> 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/s4u.rhelent.lan@RHELENT.LAN");
>     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/freeipa.rhelent.lan@RHELENT.LAN
> ",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 <kai.zheng@intel.com> 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:mboorshtein@gmail.com]
> > Sent: Sunday, November 22, 2015 11:13 AM
> > To: kerby@directory.apache.org
> > 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/s4u.rhelent.lan@RHELENT.LAN for krbtgt/RHELENT.LAN@RHELENT.LAN, 
> > 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/s4u.rhelent.lan@RHELENT.LAN for 
> > krbtgt/RHELENT.LAN@RHELENT.LAN
> >
> > 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/s4u.rhelent.lan@RHELENT.LAN for 
> > HTTP/freeipa.rhelent.lan@RHELENT.LAN
> >
> > 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/s4u.rhelent.lan@RHELENT.LAN for 
> > krbtgt/RHELENT.LAN@RHELENT.LAN
> >
> > 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/freeipa.rhelent.lan@RHELENT.LAN, 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?
> >
>
Mime
View raw message