You are viewing a plain text version of this content. The canonical link for it is here.
Posted to kerby@directory.apache.org by Marc Boorshtein <mb...@gmail.com> on 2015/11/20 17:59:56 UTC
KDC is rejecting my TGS
I've merged in all the new changes from Kai and Steve. I get a TGT without
issue, but now I'm getting the following error from freeipa (built on MIT
kerberos):
Nov 20 09:38:40 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1 etypes
{17}) 10.8.0.2: ISSUE: authtime 1448030320, etypes {rep=17 tkt=18 ses=17},
HTTP/s4u.rhelent.lan@RHELENT.LAN for krbtgt/RHELENT.LAN@RHELENT.LAN
Nov 20 09:38:40 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (1 etypes
{17}) 10.8.0.2: PROCESS_TGS: authtime 0, <unknown client> for
HTTP/ipa.rhelent.lan@RHELENT.LAN, ASN.1 structure is missing a required
field
Now unfortunately its not say WHAT the missing field is. I've got a
control setup to make the same request in java using the same keytab for
the same resources. Here's the TGS request that works using the standard
java kerberos libraries:
No. Time Source Destination Protocol
Length Info
84 4.103473000 10.8.0.2 192.168.2.166 KRB5
693 TGS-REQ
Frame 84: 693 bytes on wire (5544 bits), 693 bytes captured (5544 bits) on
interface 3
Interface id: 3 (utun0)
Encapsulation type: NULL (15)
Arrival Time: Nov 20, 2015 11:47:55.953694000 EST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1448038075.953694000 seconds
[Time delta from previous captured frame: 0.019420000 seconds]
[Time delta from previous displayed frame: 0.019361000 seconds]
[Time since reference or first frame: 4.103473000 seconds]
Frame Number: 84
Frame Length: 693 bytes (5544 bits)
Capture Length: 693 bytes (5544 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: null:ip:udp:kerberos]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Null/Loopback
Family: IP (2)
Internet Protocol Version 4, Src: 10.8.0.2 (10.8.0.2), Dst: 192.168.2.166
(192.168.2.166)
Version: 4
Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00:
Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not
ECN-Capable Transport) (0x00)
Total Length: 689
Identification: 0x175e (5982)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0x9386 [validation disabled]
[Good: False]
[Bad: False]
Source: 10.8.0.2 (10.8.0.2)
Destination: 192.168.2.166 (192.168.2.166)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 49177 (49177), Dst Port: 88 (88)
Source Port: 49177 (49177)
Destination Port: 88 (88)
Length: 669
Checksum: 0x8f4e [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
[Stream index: 8]
Kerberos
tgs-req
pvno: 5
msg-type: krb-tgs-req (12)
padata: 1 item
PA-DATA PA-TGS-REQ
padata-type: kRB5-PADATA-TGS-REQ (1)
padata-value:
6e8201fa308201f6a003020105a10302010ea20703050000...
ap-req
pvno: 5
msg-type: krb-ap-req (14)
Padding: 0
ap-options: 00000000
0... .... = reserved: False
.0.. .... = use-session-key: False
..0. .... = mutual-required: False
ticket
tkt-vno: 5
realm: RHELENT.LAN
sname
name-type: kRB5-NT-SRV-INST (2)
name-string: 2 items
KerberosString: krbtgt
KerberosString: RHELENT.LAN
enc-part
etype: eTYPE-AES256-CTS-HMAC-SHA1-96
(18)
kvno: 1
cipher:
28198273460862c515248752f713987ea6857b206fe8fe86...
authenticator
etype: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
cipher:
9101cb1fb3694bbc9cfb972c73711cb8e33d59e1de7fdb1a...
req-body
Padding: 0
kdc-options: 40000000 (forwardable)
0... .... = reserved: False
.1.. .... = forwardable: True
..0. .... = forwarded: False
...0 .... = proxiable: False
.... 0... = proxy: False
.... .0.. = allow-postdate: False
.... ..0. = postdated: False
.... ...0 = unused7: False
0... .... = renewable: False
.0.. .... = unused9: False
..0. .... = unused10: False
...0 .... = opt-hardware-auth: False
.... ..0. = request-anonymous: False
.... ...0 = canonicalize: False
0... .... = constrained-delegation: False
..0. .... = disable-transited-check: False
...0 .... = renewable-ok: False
.... 0... = enc-tkt-in-skey: False
.... ..0. = renew: False
.... ...0 = validate: False
realm: RHELENT.LAN
sname
name-type: kRB5-NT-UNKNOWN (0)
name-string: 2 items
KerberosString: HTTP
KerberosString: freeipa.rhelent.lan
till: 1970-01-01 00:00:00 (UTC)
nonce: 1040086776
etype: 3 items
ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)
ENCTYPE: eTYPE-DES3-CBC-SHA1 (16)
and from kerby:
No. Time Source Destination Protocol
Length Info
2888 255.037980000 10.8.0.2 192.168.2.166 KRB5
742 TGS-REQ
Frame 2888: 742 bytes on wire (5936 bits), 742 bytes captured (5936 bits)
on interface 3
Interface id: 3 (utun0)
Encapsulation type: NULL (15)
Arrival Time: Nov 20, 2015 11:52:06.888201000 EST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1448038326.888201000 seconds
[Time delta from previous captured frame: -0.000117000 seconds]
[Time delta from previous displayed frame: 0.010323000 seconds]
[Time since reference or first frame: 255.037980000 seconds]
Frame Number: 2888
Frame Length: 742 bytes (5936 bits)
Capture Length: 742 bytes (5936 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: null:ip:udp:kerberos]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Null/Loopback
Family: IP (2)
Internet Protocol Version 4, Src: 10.8.0.2 (10.8.0.2), Dst: 192.168.2.166
(192.168.2.166)
Version: 4
Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00:
Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not
ECN-Capable Transport) (0x00)
Total Length: 738
Identification: 0x226e (8814)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0x8845 [validation disabled]
[Good: False]
[Bad: False]
Source: 10.8.0.2 (10.8.0.2)
Destination: 192.168.2.166 (192.168.2.166)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 56122 (56122), Dst Port: 88 (88)
Source Port: 56122 (56122)
Destination Port: 88 (88)
Length: 718
Checksum: 0x461a [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
[Stream index: 30]
Kerberos
tgs-req
pvno: 5
msg-type: krb-tgs-req (12)
padata: 1 item
PA-DATA PA-TGS-REQ
padata-type: kRB5-PADATA-TGS-REQ (1)
padata-value:
6e8201f8308201f4a003020105a10302010ea20703050000...
ap-req
pvno: 5
msg-type: krb-ap-req (14)
Padding: 0
ap-options: 00000000
0... .... = reserved: False
.0.. .... = use-session-key: False
..0. .... = mutual-required: False
ticket
tkt-vno: 5
realm: RHELENT.LAN
sname
name-type: kRB5-NT-PRINCIPAL (1)
name-string: 2 items
KerberosString: krbtgt
KerberosString: RHELENT.LAN
enc-part
etype: eTYPE-AES256-CTS-HMAC-SHA1-96
(18)
kvno: 1
cipher:
1bea5e1ce7205e55dd088dc647222d5a20d62c41a172c0b4...
authenticator
etype: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
kvno: 255
cipher:
dd243f0d6aaa9c03a6e6737b18ca8510d4bfac33296a07d2...
req-body
Padding: 0
kdc-options: 40000000 (forwardable)
0... .... = reserved: False
.1.. .... = forwardable: True
..0. .... = forwarded: False
...0 .... = proxiable: False
.... 0... = proxy: False
.... .0.. = allow-postdate: False
.... ..0. = postdated: False
.... ...0 = unused7: False
0... .... = renewable: False
.0.. .... = unused9: False
..0. .... = unused10: False
...0 .... = opt-hardware-auth: False
.... ..0. = request-anonymous: False
.... ...0 = canonicalize: False
0... .... = constrained-delegation: False
..0. .... = disable-transited-check: False
...0 .... = renewable-ok: False
.... 0... = enc-tkt-in-skey: False
.... ..0. = renew: False
.... ...0 = validate: False
cname
name-type: kRB5-NT-PRINCIPAL (1)
name-string: 2 items
KerberosString: HTTP
KerberosString: s4u.rhelent.lan
realm: RHELENT.LAN
sname
name-type: kRB5-NT-PRINCIPAL (1)
name-string: 2 items
KerberosString: HTTP
KerberosString: freeipa.rhelent.lan
from: 2015-11-20 16:52:06 (UTC)
till: 2015-11-21 00:52:06 (UTC)
nonce: 984126497
etype: 1 item
ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
The differences I see are:
1. The authenticator from kerby PS-TGS-REQ has a kvno=255, java doesn't
have that attribute
2. Kerby has a cname section with the name of the client, java's
implementation does not
3. Kerby's SNAME has a name-type of KRB5-NT-Principal where as java's is
KRB5-NT-Unknown
4. Kerby has a "from", java does not
5. Kerby's from and till are real dates, Java's is expired
My guess is the issue is #3? I'm thinking I can set that in the options.
I already added a method that lets me get an SGT with options (like the
tgtWithOptions method). I'll see if there's a way to specify the principal
type from there. Anything else stand out?
Thanks
Marc
RE: KDC is rejecting my TGS
Posted by "Zheng, Kai" <ka...@intel.com>.
Yes Marc the fix is still pending there thinking you have a work around. It needs to take some time to sort it out. I'm currently focusing on ASN1/X509/CMS stuffs. Hopefully I could be back to it soon.
Regards,
Kai
-----Original Message-----
From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
Sent: Sunday, November 29, 2015 9:55 AM
To: kerby@directory.apache.org
Subject: Re: KDC is rejecting my TGS
Just a heads up, I've pulled in the latest commits and I'm still able to get a Tgt, and I I can get a server principal back with a Tgt but the Sgt request still gets an error back of "bad integrity" with the following in the logs:
Nov 28 20:45:57 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,
Decrypt integrity check failed
Thanks
On Mon, Nov 23, 2015 at 3:50 PM, Marc Boorshtein <mb...@gmail.com>
wrote:
> OK, so that DOES get me an SGT! now I just need to figure out how to
> convert that into a SPNEGO negotiate header. Any thoughts?
>
> On Mon, Nov 23, 2015 at 9:16 AM, Marc Boorshtein
> <mb...@gmail.com>
> wrote:
>
>> Interesting. I'll give that a try
>> On Nov 23, 2015 9:02 AM, "Zheng, Kai" <ka...@intel.com> wrote:
>>
>>> Maybe we can be back to this issue some time later after I fix the
>>> sessionkey/subkey issue.
>>> For now, we can try and also should the approach used by Steve
>>> (actually aligned with MIT kinit -S behavior): request the service
>>> ticket directly using the AS-REQ. So your codes may be as follows.
>>>
>>> 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.SERVER_PRINCIPAL, new
>>> PrincipalName("HTTP/freeipa.rhelent.lan@RHELENT.LAN
>>> ",NameType.NT_UNKNOWN));
>>> 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);
>>> Then the tgt should be actually the service ticket you desired.
>>>
>>> -----Original Message-----
>>> From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
>>> Sent: Monday, November 23, 2015 9:53 PM
>>> To: kerby@directory.apache.org
>>> Subject: Re: KDC is rejecting my TGS
>>>
>>> Yes, I did. I also have several minor changes to get it to line up
>>> with the way java's libraries are working so i wonder if the merge
>>> missed something. i'll try debugging it tonight.
>>>
>>> On Mon, Nov 23, 2015 at 8:19 AM, Zheng, Kai <ka...@intel.com> wrote:
>>>
>>> > OK. Did you make the following change as I told in my last email,
>>> > in addition to checking out the latest commits?
>>> > ====
>>> > if you'd just go on with your case, please make the following
>>> > change and try.
>>> > In client side TgsRequest.java: processResponse(), use
>>> > KeyUsage.TGS_REP_ENCPART_SUBKEY.
>>> > ====
>>> >
>>> > -----Original Message-----
>>> > From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
>>> > Sent: Monday, November 23, 2015 9:05 PM
>>> > To: kerby@directory.apache.org
>>> > Subject: Re: KDC is rejecting my TGS
>>> >
>>> > New error:
>>> >
>>> > Nov 23 07:57:34 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1
>>> > etypes
>>> > {17}) 192.168.2.129: ISSUE: authtime 1448283454, etypes {rep=17
>>> > tkt=18 ses=17}, HTTP/s4u.rhelent.lan@RHELENT.LAN for
>>> > krbtgt/RHELENT.LAN@RHELENT.LAN
>>> >
>>> > Nov 23 07:57:34 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,
>>> > Decrypt integrity check failed
>>> >
>>> > Here's the packet trace :
>>> >
>>> > https://s3.amazonaws.com/ts-public-downloads/captures/kerb-bad_int
>>> > egri
>>> > ty.pcapng
>>> >
>>> > On Mon, Nov 23, 2015 at 4:22 AM, Zheng, Kai <ka...@intel.com>
>>> wrote:
>>> >
>>> > > With above fixup, I hit another issue that Kerby client failed
>>> > > to decrypt the TGS-REP.
>>> > >
>>> > > I got it work in my setup but I can't commit the codes because
>>> > > there're more cases to be investigated. Ref. the issue
>>> > > https://issues.apache.org/jira/browse/DIRKRB-472
>>> > >
>>> > > Marc,
>>> > > if you'd just go on with your case, please make the following
>>> > > change and try.
>>> > > In client side TgsRequest.java: processResponse(), use
>>> > > KeyUsage.TGS_REP_ENCPART_SUBKEY.
>>> > >
>>> > > -----Original Message-----
>>> > > From: Zheng, Kai [mailto:kai.zheng@intel.com]
>>> > > Sent: Monday, November 23, 2015 2:21 PM
>>> > > To: kerby@directory.apache.org
>>> > > Subject: RE: KDC is rejecting my TGS
>>> > >
>>> > > Fired and resolved the following issue to track the
>>> > > authenticator issue we're handling.
>>> > > Will setup a box to test: Kerby client -> MIT KDC (in service
>>> > > ticket
>>> > > path)
>>> > >
>>> > > commit df6ba15d4f990b104efcf36ede913f4eeb09a872
>>> > > Author: Drankye <dr...@gmail.com>
>>> > > Date: Tue Nov 24 14:16:32 2015 +0800
>>> > >
>>> > > DIRKRB-469 & DIRKRB-470 setting vno & cksum fields when
>>> > > making authenticator
>>> > >
>>> > > -----Original Message-----
>>> > > From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
>>> > > Sent: Monday, November 23, 2015 11:30 AM
>>> > > To: kerby@directory.apache.org
>>> > > Subject: RE: KDC is rejecting my TGS
>>> > >
>>> > > ah. That would do it :) sounds like we are getting close!
>>> > >
>>> > > Thanks
>>> > > Marc
>>> > > On Nov 22, 2015 10:27 PM, "Zheng, Kai" <ka...@intel.com> wrote:
>>> > >
>>> > > > OK, forget it. I just checked the codes, and found the
>>> > > > checksum isn't done and filled in authenticator. I will get it fixed ASAP.
>>> > > >
>>> > > > Regards,
>>> > > > Kai
>>> > > >
>>> > > > -----Original Message-----
>>> > > > From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
>>> > > > Sent: Monday, November 23, 2015 11:24 AM
>>> > > > To: kerby@directory.apache.org
>>> > > > Subject: RE: KDC is rejecting my TGS
>>> > > >
>>> > > > >
>>> > > > > Cool!! Thanks a lot for getting the hard issue figured out.
>>> > > > >
>>> > > >
>>> > > > My pleasure. I'm glad I'm making progress.
>>> > > >
>>> > > > > 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.
>>> > > >
>>> > > > I haven't yet. I've shutdown for the night but the there
>>> > > > really isn't a stack trace because MIT is returning a kerberos
>>> > > > generic error (with the accompanying log messages I sent
>>> > > > over). I wanted to make sure I was reading the code properly
>>> > > > before I started trying things since MIT isn't giving me the best error messages.
>>> > > > I'll give
>>> > it a go tomorrow.
>>> > > >
>>> > > > Thanks
>>> > > > Marc
>>> > > >
>>> > >
>>> >
>>>
>>
>
Re: KDC is rejecting my TGS
Posted by Marc Boorshtein <mb...@gmail.com>.
Just a heads up, I've pulled in the latest commits and I'm still able to
get a Tgt, and I I can get a server principal back with a Tgt but the Sgt
request still gets an error back of "bad integrity" with the following in
the logs:
Nov 28 20:45:57 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,
Decrypt integrity check failed
Thanks
On Mon, Nov 23, 2015 at 3:50 PM, Marc Boorshtein <mb...@gmail.com>
wrote:
> OK, so that DOES get me an SGT! now I just need to figure out how to
> convert that into a SPNEGO negotiate header. Any thoughts?
>
> On Mon, Nov 23, 2015 at 9:16 AM, Marc Boorshtein <mb...@gmail.com>
> wrote:
>
>> Interesting. I'll give that a try
>> On Nov 23, 2015 9:02 AM, "Zheng, Kai" <ka...@intel.com> wrote:
>>
>>> Maybe we can be back to this issue some time later after I fix the
>>> sessionkey/subkey issue.
>>> For now, we can try and also should the approach used by Steve (actually
>>> aligned with MIT kinit -S behavior): request the service ticket directly
>>> using the AS-REQ. So your codes may be as follows.
>>>
>>> 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.SERVER_PRINCIPAL, new
>>> PrincipalName("HTTP/freeipa.rhelent.lan@RHELENT.LAN
>>> ",NameType.NT_UNKNOWN));
>>> 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);
>>> Then the tgt should be actually the service ticket you desired.
>>>
>>> -----Original Message-----
>>> From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
>>> Sent: Monday, November 23, 2015 9:53 PM
>>> To: kerby@directory.apache.org
>>> Subject: Re: KDC is rejecting my TGS
>>>
>>> Yes, I did. I also have several minor changes to get it to line up with
>>> the way java's libraries are working so i wonder if the merge missed
>>> something. i'll try debugging it tonight.
>>>
>>> On Mon, Nov 23, 2015 at 8:19 AM, Zheng, Kai <ka...@intel.com> wrote:
>>>
>>> > OK. Did you make the following change as I told in my last email, in
>>> > addition to checking out the latest commits?
>>> > ====
>>> > if you'd just go on with your case, please make the following change
>>> > and try.
>>> > In client side TgsRequest.java: processResponse(), use
>>> > KeyUsage.TGS_REP_ENCPART_SUBKEY.
>>> > ====
>>> >
>>> > -----Original Message-----
>>> > From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
>>> > Sent: Monday, November 23, 2015 9:05 PM
>>> > To: kerby@directory.apache.org
>>> > Subject: Re: KDC is rejecting my TGS
>>> >
>>> > New error:
>>> >
>>> > Nov 23 07:57:34 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1
>>> > etypes
>>> > {17}) 192.168.2.129: ISSUE: authtime 1448283454, etypes {rep=17 tkt=18
>>> > ses=17}, HTTP/s4u.rhelent.lan@RHELENT.LAN for
>>> > krbtgt/RHELENT.LAN@RHELENT.LAN
>>> >
>>> > Nov 23 07:57:34 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,
>>> > Decrypt integrity check failed
>>> >
>>> > Here's the packet trace :
>>> >
>>> > https://s3.amazonaws.com/ts-public-downloads/captures/kerb-bad_integri
>>> > ty.pcapng
>>> >
>>> > On Mon, Nov 23, 2015 at 4:22 AM, Zheng, Kai <ka...@intel.com>
>>> wrote:
>>> >
>>> > > With above fixup, I hit another issue that Kerby client failed to
>>> > > decrypt the TGS-REP.
>>> > >
>>> > > I got it work in my setup but I can't commit the codes because
>>> > > there're more cases to be investigated. Ref. the issue
>>> > > https://issues.apache.org/jira/browse/DIRKRB-472
>>> > >
>>> > > Marc,
>>> > > if you'd just go on with your case, please make the following change
>>> > > and try.
>>> > > In client side TgsRequest.java: processResponse(), use
>>> > > KeyUsage.TGS_REP_ENCPART_SUBKEY.
>>> > >
>>> > > -----Original Message-----
>>> > > From: Zheng, Kai [mailto:kai.zheng@intel.com]
>>> > > Sent: Monday, November 23, 2015 2:21 PM
>>> > > To: kerby@directory.apache.org
>>> > > Subject: RE: KDC is rejecting my TGS
>>> > >
>>> > > Fired and resolved the following issue to track the authenticator
>>> > > issue we're handling.
>>> > > Will setup a box to test: Kerby client -> MIT KDC (in service ticket
>>> > > path)
>>> > >
>>> > > commit df6ba15d4f990b104efcf36ede913f4eeb09a872
>>> > > Author: Drankye <dr...@gmail.com>
>>> > > Date: Tue Nov 24 14:16:32 2015 +0800
>>> > >
>>> > > DIRKRB-469 & DIRKRB-470 setting vno & cksum fields when making
>>> > > authenticator
>>> > >
>>> > > -----Original Message-----
>>> > > From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
>>> > > Sent: Monday, November 23, 2015 11:30 AM
>>> > > To: kerby@directory.apache.org
>>> > > Subject: RE: KDC is rejecting my TGS
>>> > >
>>> > > ah. That would do it :) sounds like we are getting close!
>>> > >
>>> > > Thanks
>>> > > Marc
>>> > > On Nov 22, 2015 10:27 PM, "Zheng, Kai" <ka...@intel.com> wrote:
>>> > >
>>> > > > OK, forget it. I just checked the codes, and found the checksum
>>> > > > isn't done and filled in authenticator. I will get it fixed ASAP.
>>> > > >
>>> > > > Regards,
>>> > > > Kai
>>> > > >
>>> > > > -----Original Message-----
>>> > > > From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
>>> > > > Sent: Monday, November 23, 2015 11:24 AM
>>> > > > To: kerby@directory.apache.org
>>> > > > Subject: RE: KDC is rejecting my TGS
>>> > > >
>>> > > > >
>>> > > > > Cool!! Thanks a lot for getting the hard issue figured out.
>>> > > > >
>>> > > >
>>> > > > My pleasure. I'm glad I'm making progress.
>>> > > >
>>> > > > > 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.
>>> > > >
>>> > > > I haven't yet. I've shutdown for the night but the there really
>>> > > > isn't a stack trace because MIT is returning a kerberos generic
>>> > > > error (with the accompanying log messages I sent over). I wanted
>>> > > > to make sure I was reading the code properly before I started
>>> > > > trying things since MIT isn't giving me the best error messages.
>>> > > > I'll give
>>> > it a go tomorrow.
>>> > > >
>>> > > > Thanks
>>> > > > Marc
>>> > > >
>>> > >
>>> >
>>>
>>
>
Re: KDC is rejecting my TGS
Posted by Marc Boorshtein <mb...@gmail.com>.
OK, so that DOES get me an SGT! now I just need to figure out how to
convert that into a SPNEGO negotiate header. Any thoughts?
On Mon, Nov 23, 2015 at 9:16 AM, Marc Boorshtein <mb...@gmail.com>
wrote:
> Interesting. I'll give that a try
> On Nov 23, 2015 9:02 AM, "Zheng, Kai" <ka...@intel.com> wrote:
>
>> Maybe we can be back to this issue some time later after I fix the
>> sessionkey/subkey issue.
>> For now, we can try and also should the approach used by Steve (actually
>> aligned with MIT kinit -S behavior): request the service ticket directly
>> using the AS-REQ. So your codes may be as follows.
>>
>> 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.SERVER_PRINCIPAL, new
>> PrincipalName("HTTP/freeipa.rhelent.lan@RHELENT.LAN
>> ",NameType.NT_UNKNOWN));
>> 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);
>> Then the tgt should be actually the service ticket you desired.
>>
>> -----Original Message-----
>> From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
>> Sent: Monday, November 23, 2015 9:53 PM
>> To: kerby@directory.apache.org
>> Subject: Re: KDC is rejecting my TGS
>>
>> Yes, I did. I also have several minor changes to get it to line up with
>> the way java's libraries are working so i wonder if the merge missed
>> something. i'll try debugging it tonight.
>>
>> On Mon, Nov 23, 2015 at 8:19 AM, Zheng, Kai <ka...@intel.com> wrote:
>>
>> > OK. Did you make the following change as I told in my last email, in
>> > addition to checking out the latest commits?
>> > ====
>> > if you'd just go on with your case, please make the following change
>> > and try.
>> > In client side TgsRequest.java: processResponse(), use
>> > KeyUsage.TGS_REP_ENCPART_SUBKEY.
>> > ====
>> >
>> > -----Original Message-----
>> > From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
>> > Sent: Monday, November 23, 2015 9:05 PM
>> > To: kerby@directory.apache.org
>> > Subject: Re: KDC is rejecting my TGS
>> >
>> > New error:
>> >
>> > Nov 23 07:57:34 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1
>> > etypes
>> > {17}) 192.168.2.129: ISSUE: authtime 1448283454, etypes {rep=17 tkt=18
>> > ses=17}, HTTP/s4u.rhelent.lan@RHELENT.LAN for
>> > krbtgt/RHELENT.LAN@RHELENT.LAN
>> >
>> > Nov 23 07:57:34 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,
>> > Decrypt integrity check failed
>> >
>> > Here's the packet trace :
>> >
>> > https://s3.amazonaws.com/ts-public-downloads/captures/kerb-bad_integri
>> > ty.pcapng
>> >
>> > On Mon, Nov 23, 2015 at 4:22 AM, Zheng, Kai <ka...@intel.com>
>> wrote:
>> >
>> > > With above fixup, I hit another issue that Kerby client failed to
>> > > decrypt the TGS-REP.
>> > >
>> > > I got it work in my setup but I can't commit the codes because
>> > > there're more cases to be investigated. Ref. the issue
>> > > https://issues.apache.org/jira/browse/DIRKRB-472
>> > >
>> > > Marc,
>> > > if you'd just go on with your case, please make the following change
>> > > and try.
>> > > In client side TgsRequest.java: processResponse(), use
>> > > KeyUsage.TGS_REP_ENCPART_SUBKEY.
>> > >
>> > > -----Original Message-----
>> > > From: Zheng, Kai [mailto:kai.zheng@intel.com]
>> > > Sent: Monday, November 23, 2015 2:21 PM
>> > > To: kerby@directory.apache.org
>> > > Subject: RE: KDC is rejecting my TGS
>> > >
>> > > Fired and resolved the following issue to track the authenticator
>> > > issue we're handling.
>> > > Will setup a box to test: Kerby client -> MIT KDC (in service ticket
>> > > path)
>> > >
>> > > commit df6ba15d4f990b104efcf36ede913f4eeb09a872
>> > > Author: Drankye <dr...@gmail.com>
>> > > Date: Tue Nov 24 14:16:32 2015 +0800
>> > >
>> > > DIRKRB-469 & DIRKRB-470 setting vno & cksum fields when making
>> > > authenticator
>> > >
>> > > -----Original Message-----
>> > > From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
>> > > Sent: Monday, November 23, 2015 11:30 AM
>> > > To: kerby@directory.apache.org
>> > > Subject: RE: KDC is rejecting my TGS
>> > >
>> > > ah. That would do it :) sounds like we are getting close!
>> > >
>> > > Thanks
>> > > Marc
>> > > On Nov 22, 2015 10:27 PM, "Zheng, Kai" <ka...@intel.com> wrote:
>> > >
>> > > > OK, forget it. I just checked the codes, and found the checksum
>> > > > isn't done and filled in authenticator. I will get it fixed ASAP.
>> > > >
>> > > > Regards,
>> > > > Kai
>> > > >
>> > > > -----Original Message-----
>> > > > From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
>> > > > Sent: Monday, November 23, 2015 11:24 AM
>> > > > To: kerby@directory.apache.org
>> > > > Subject: RE: KDC is rejecting my TGS
>> > > >
>> > > > >
>> > > > > Cool!! Thanks a lot for getting the hard issue figured out.
>> > > > >
>> > > >
>> > > > My pleasure. I'm glad I'm making progress.
>> > > >
>> > > > > 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.
>> > > >
>> > > > I haven't yet. I've shutdown for the night but the there really
>> > > > isn't a stack trace because MIT is returning a kerberos generic
>> > > > error (with the accompanying log messages I sent over). I wanted
>> > > > to make sure I was reading the code properly before I started
>> > > > trying things since MIT isn't giving me the best error messages.
>> > > > I'll give
>> > it a go tomorrow.
>> > > >
>> > > > Thanks
>> > > > Marc
>> > > >
>> > >
>> >
>>
>
RE: KDC is rejecting my TGS
Posted by Marc Boorshtein <mb...@gmail.com>.
Interesting. I'll give that a try
On Nov 23, 2015 9:02 AM, "Zheng, Kai" <ka...@intel.com> wrote:
> Maybe we can be back to this issue some time later after I fix the
> sessionkey/subkey issue.
> For now, we can try and also should the approach used by Steve (actually
> aligned with MIT kinit -S behavior): request the service ticket directly
> using the AS-REQ. So your codes may be as follows.
>
> 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.SERVER_PRINCIPAL, new
> PrincipalName("HTTP/freeipa.rhelent.lan@RHELENT.LAN
> ",NameType.NT_UNKNOWN));
> 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);
> Then the tgt should be actually the service ticket you desired.
>
> -----Original Message-----
> From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
> Sent: Monday, November 23, 2015 9:53 PM
> To: kerby@directory.apache.org
> Subject: Re: KDC is rejecting my TGS
>
> Yes, I did. I also have several minor changes to get it to line up with
> the way java's libraries are working so i wonder if the merge missed
> something. i'll try debugging it tonight.
>
> On Mon, Nov 23, 2015 at 8:19 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> > OK. Did you make the following change as I told in my last email, in
> > addition to checking out the latest commits?
> > ====
> > if you'd just go on with your case, please make the following change
> > and try.
> > In client side TgsRequest.java: processResponse(), use
> > KeyUsage.TGS_REP_ENCPART_SUBKEY.
> > ====
> >
> > -----Original Message-----
> > From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
> > Sent: Monday, November 23, 2015 9:05 PM
> > To: kerby@directory.apache.org
> > Subject: Re: KDC is rejecting my TGS
> >
> > New error:
> >
> > Nov 23 07:57:34 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1
> > etypes
> > {17}) 192.168.2.129: ISSUE: authtime 1448283454, etypes {rep=17 tkt=18
> > ses=17}, HTTP/s4u.rhelent.lan@RHELENT.LAN for
> > krbtgt/RHELENT.LAN@RHELENT.LAN
> >
> > Nov 23 07:57:34 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,
> > Decrypt integrity check failed
> >
> > Here's the packet trace :
> >
> > https://s3.amazonaws.com/ts-public-downloads/captures/kerb-bad_integri
> > ty.pcapng
> >
> > On Mon, Nov 23, 2015 at 4:22 AM, Zheng, Kai <ka...@intel.com> wrote:
> >
> > > With above fixup, I hit another issue that Kerby client failed to
> > > decrypt the TGS-REP.
> > >
> > > I got it work in my setup but I can't commit the codes because
> > > there're more cases to be investigated. Ref. the issue
> > > https://issues.apache.org/jira/browse/DIRKRB-472
> > >
> > > Marc,
> > > if you'd just go on with your case, please make the following change
> > > and try.
> > > In client side TgsRequest.java: processResponse(), use
> > > KeyUsage.TGS_REP_ENCPART_SUBKEY.
> > >
> > > -----Original Message-----
> > > From: Zheng, Kai [mailto:kai.zheng@intel.com]
> > > Sent: Monday, November 23, 2015 2:21 PM
> > > To: kerby@directory.apache.org
> > > Subject: RE: KDC is rejecting my TGS
> > >
> > > Fired and resolved the following issue to track the authenticator
> > > issue we're handling.
> > > Will setup a box to test: Kerby client -> MIT KDC (in service ticket
> > > path)
> > >
> > > commit df6ba15d4f990b104efcf36ede913f4eeb09a872
> > > Author: Drankye <dr...@gmail.com>
> > > Date: Tue Nov 24 14:16:32 2015 +0800
> > >
> > > DIRKRB-469 & DIRKRB-470 setting vno & cksum fields when making
> > > authenticator
> > >
> > > -----Original Message-----
> > > From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
> > > Sent: Monday, November 23, 2015 11:30 AM
> > > To: kerby@directory.apache.org
> > > Subject: RE: KDC is rejecting my TGS
> > >
> > > ah. That would do it :) sounds like we are getting close!
> > >
> > > Thanks
> > > Marc
> > > On Nov 22, 2015 10:27 PM, "Zheng, Kai" <ka...@intel.com> wrote:
> > >
> > > > OK, forget it. I just checked the codes, and found the checksum
> > > > isn't done and filled in authenticator. I will get it fixed ASAP.
> > > >
> > > > Regards,
> > > > Kai
> > > >
> > > > -----Original Message-----
> > > > From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
> > > > Sent: Monday, November 23, 2015 11:24 AM
> > > > To: kerby@directory.apache.org
> > > > Subject: RE: KDC is rejecting my TGS
> > > >
> > > > >
> > > > > Cool!! Thanks a lot for getting the hard issue figured out.
> > > > >
> > > >
> > > > My pleasure. I'm glad I'm making progress.
> > > >
> > > > > 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.
> > > >
> > > > I haven't yet. I've shutdown for the night but the there really
> > > > isn't a stack trace because MIT is returning a kerberos generic
> > > > error (with the accompanying log messages I sent over). I wanted
> > > > to make sure I was reading the code properly before I started
> > > > trying things since MIT isn't giving me the best error messages.
> > > > I'll give
> > it a go tomorrow.
> > > >
> > > > Thanks
> > > > Marc
> > > >
> > >
> >
>
RE: KDC is rejecting my TGS
Posted by "Zheng, Kai" <ka...@intel.com>.
Maybe we can be back to this issue some time later after I fix the sessionkey/subkey issue.
For now, we can try and also should the approach used by Steve (actually aligned with MIT kinit -S behavior): request the service ticket directly using the AS-REQ. So your codes may be as follows.
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.SERVER_PRINCIPAL, new PrincipalName("HTTP/freeipa.rhelent.lan@RHELENT.LAN",NameType.NT_UNKNOWN));
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);
Then the tgt should be actually the service ticket you desired.
-----Original Message-----
From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
Sent: Monday, November 23, 2015 9:53 PM
To: kerby@directory.apache.org
Subject: Re: KDC is rejecting my TGS
Yes, I did. I also have several minor changes to get it to line up with the way java's libraries are working so i wonder if the merge missed something. i'll try debugging it tonight.
On Mon, Nov 23, 2015 at 8:19 AM, Zheng, Kai <ka...@intel.com> wrote:
> OK. Did you make the following change as I told in my last email, in
> addition to checking out the latest commits?
> ====
> if you'd just go on with your case, please make the following change
> and try.
> In client side TgsRequest.java: processResponse(), use
> KeyUsage.TGS_REP_ENCPART_SUBKEY.
> ====
>
> -----Original Message-----
> From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
> Sent: Monday, November 23, 2015 9:05 PM
> To: kerby@directory.apache.org
> Subject: Re: KDC is rejecting my TGS
>
> New error:
>
> Nov 23 07:57:34 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1
> etypes
> {17}) 192.168.2.129: ISSUE: authtime 1448283454, etypes {rep=17 tkt=18
> ses=17}, HTTP/s4u.rhelent.lan@RHELENT.LAN for
> krbtgt/RHELENT.LAN@RHELENT.LAN
>
> Nov 23 07:57:34 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,
> Decrypt integrity check failed
>
> Here's the packet trace :
>
> https://s3.amazonaws.com/ts-public-downloads/captures/kerb-bad_integri
> ty.pcapng
>
> On Mon, Nov 23, 2015 at 4:22 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> > With above fixup, I hit another issue that Kerby client failed to
> > decrypt the TGS-REP.
> >
> > I got it work in my setup but I can't commit the codes because
> > there're more cases to be investigated. Ref. the issue
> > https://issues.apache.org/jira/browse/DIRKRB-472
> >
> > Marc,
> > if you'd just go on with your case, please make the following change
> > and try.
> > In client side TgsRequest.java: processResponse(), use
> > KeyUsage.TGS_REP_ENCPART_SUBKEY.
> >
> > -----Original Message-----
> > From: Zheng, Kai [mailto:kai.zheng@intel.com]
> > Sent: Monday, November 23, 2015 2:21 PM
> > To: kerby@directory.apache.org
> > Subject: RE: KDC is rejecting my TGS
> >
> > Fired and resolved the following issue to track the authenticator
> > issue we're handling.
> > Will setup a box to test: Kerby client -> MIT KDC (in service ticket
> > path)
> >
> > commit df6ba15d4f990b104efcf36ede913f4eeb09a872
> > Author: Drankye <dr...@gmail.com>
> > Date: Tue Nov 24 14:16:32 2015 +0800
> >
> > DIRKRB-469 & DIRKRB-470 setting vno & cksum fields when making
> > authenticator
> >
> > -----Original Message-----
> > From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
> > Sent: Monday, November 23, 2015 11:30 AM
> > To: kerby@directory.apache.org
> > Subject: RE: KDC is rejecting my TGS
> >
> > ah. That would do it :) sounds like we are getting close!
> >
> > Thanks
> > Marc
> > On Nov 22, 2015 10:27 PM, "Zheng, Kai" <ka...@intel.com> wrote:
> >
> > > OK, forget it. I just checked the codes, and found the checksum
> > > isn't done and filled in authenticator. I will get it fixed ASAP.
> > >
> > > Regards,
> > > Kai
> > >
> > > -----Original Message-----
> > > From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
> > > Sent: Monday, November 23, 2015 11:24 AM
> > > To: kerby@directory.apache.org
> > > Subject: RE: KDC is rejecting my TGS
> > >
> > > >
> > > > Cool!! Thanks a lot for getting the hard issue figured out.
> > > >
> > >
> > > My pleasure. I'm glad I'm making progress.
> > >
> > > > 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.
> > >
> > > I haven't yet. I've shutdown for the night but the there really
> > > isn't a stack trace because MIT is returning a kerberos generic
> > > error (with the accompanying log messages I sent over). I wanted
> > > to make sure I was reading the code properly before I started
> > > trying things since MIT isn't giving me the best error messages.
> > > I'll give
> it a go tomorrow.
> > >
> > > Thanks
> > > Marc
> > >
> >
>
Re: KDC is rejecting my TGS
Posted by Marc Boorshtein <mb...@gmail.com>.
Yes, I did. I also have several minor changes to get it to line up with
the way java's libraries are working so i wonder if the merge missed
something. i'll try debugging it tonight.
On Mon, Nov 23, 2015 at 8:19 AM, Zheng, Kai <ka...@intel.com> wrote:
> OK. Did you make the following change as I told in my last email, in
> addition to checking out the latest commits?
> ====
> if you'd just go on with your case, please make the following change and
> try.
> In client side TgsRequest.java: processResponse(), use
> KeyUsage.TGS_REP_ENCPART_SUBKEY.
> ====
>
> -----Original Message-----
> From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
> Sent: Monday, November 23, 2015 9:05 PM
> To: kerby@directory.apache.org
> Subject: Re: KDC is rejecting my TGS
>
> New error:
>
> Nov 23 07:57:34 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1 etypes
> {17}) 192.168.2.129: ISSUE: authtime 1448283454, etypes {rep=17 tkt=18
> ses=17}, HTTP/s4u.rhelent.lan@RHELENT.LAN for
> krbtgt/RHELENT.LAN@RHELENT.LAN
>
> Nov 23 07:57:34 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,
> Decrypt integrity check failed
>
> Here's the packet trace :
>
> https://s3.amazonaws.com/ts-public-downloads/captures/kerb-bad_integrity.pcapng
>
> On Mon, Nov 23, 2015 at 4:22 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> > With above fixup, I hit another issue that Kerby client failed to
> > decrypt the TGS-REP.
> >
> > I got it work in my setup but I can't commit the codes because
> > there're more cases to be investigated. Ref. the issue
> > https://issues.apache.org/jira/browse/DIRKRB-472
> >
> > Marc,
> > if you'd just go on with your case, please make the following change
> > and try.
> > In client side TgsRequest.java: processResponse(), use
> > KeyUsage.TGS_REP_ENCPART_SUBKEY.
> >
> > -----Original Message-----
> > From: Zheng, Kai [mailto:kai.zheng@intel.com]
> > Sent: Monday, November 23, 2015 2:21 PM
> > To: kerby@directory.apache.org
> > Subject: RE: KDC is rejecting my TGS
> >
> > Fired and resolved the following issue to track the authenticator
> > issue we're handling.
> > Will setup a box to test: Kerby client -> MIT KDC (in service ticket
> > path)
> >
> > commit df6ba15d4f990b104efcf36ede913f4eeb09a872
> > Author: Drankye <dr...@gmail.com>
> > Date: Tue Nov 24 14:16:32 2015 +0800
> >
> > DIRKRB-469 & DIRKRB-470 setting vno & cksum fields when making
> > authenticator
> >
> > -----Original Message-----
> > From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
> > Sent: Monday, November 23, 2015 11:30 AM
> > To: kerby@directory.apache.org
> > Subject: RE: KDC is rejecting my TGS
> >
> > ah. That would do it :) sounds like we are getting close!
> >
> > Thanks
> > Marc
> > On Nov 22, 2015 10:27 PM, "Zheng, Kai" <ka...@intel.com> wrote:
> >
> > > OK, forget it. I just checked the codes, and found the checksum
> > > isn't done and filled in authenticator. I will get it fixed ASAP.
> > >
> > > Regards,
> > > Kai
> > >
> > > -----Original Message-----
> > > From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
> > > Sent: Monday, November 23, 2015 11:24 AM
> > > To: kerby@directory.apache.org
> > > Subject: RE: KDC is rejecting my TGS
> > >
> > > >
> > > > Cool!! Thanks a lot for getting the hard issue figured out.
> > > >
> > >
> > > My pleasure. I'm glad I'm making progress.
> > >
> > > > 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.
> > >
> > > I haven't yet. I've shutdown for the night but the there really
> > > isn't a stack trace because MIT is returning a kerberos generic
> > > error (with the accompanying log messages I sent over). I wanted to
> > > make sure I was reading the code properly before I started trying
> > > things since MIT isn't giving me the best error messages. I'll give
> it a go tomorrow.
> > >
> > > Thanks
> > > Marc
> > >
> >
>
RE: KDC is rejecting my TGS
Posted by "Zheng, Kai" <ka...@intel.com>.
OK. Did you make the following change as I told in my last email, in addition to checking out the latest commits?
====
if you'd just go on with your case, please make the following change and try.
In client side TgsRequest.java: processResponse(), use KeyUsage.TGS_REP_ENCPART_SUBKEY.
====
-----Original Message-----
From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
Sent: Monday, November 23, 2015 9:05 PM
To: kerby@directory.apache.org
Subject: Re: KDC is rejecting my TGS
New error:
Nov 23 07:57:34 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1 etypes
{17}) 192.168.2.129: ISSUE: authtime 1448283454, etypes {rep=17 tkt=18 ses=17}, HTTP/s4u.rhelent.lan@RHELENT.LAN for krbtgt/RHELENT.LAN@RHELENT.LAN
Nov 23 07:57:34 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,
Decrypt integrity check failed
Here's the packet trace :
https://s3.amazonaws.com/ts-public-downloads/captures/kerb-bad_integrity.pcapng
On Mon, Nov 23, 2015 at 4:22 AM, Zheng, Kai <ka...@intel.com> wrote:
> With above fixup, I hit another issue that Kerby client failed to
> decrypt the TGS-REP.
>
> I got it work in my setup but I can't commit the codes because
> there're more cases to be investigated. Ref. the issue
> https://issues.apache.org/jira/browse/DIRKRB-472
>
> Marc,
> if you'd just go on with your case, please make the following change
> and try.
> In client side TgsRequest.java: processResponse(), use
> KeyUsage.TGS_REP_ENCPART_SUBKEY.
>
> -----Original Message-----
> From: Zheng, Kai [mailto:kai.zheng@intel.com]
> Sent: Monday, November 23, 2015 2:21 PM
> To: kerby@directory.apache.org
> Subject: RE: KDC is rejecting my TGS
>
> Fired and resolved the following issue to track the authenticator
> issue we're handling.
> Will setup a box to test: Kerby client -> MIT KDC (in service ticket
> path)
>
> commit df6ba15d4f990b104efcf36ede913f4eeb09a872
> Author: Drankye <dr...@gmail.com>
> Date: Tue Nov 24 14:16:32 2015 +0800
>
> DIRKRB-469 & DIRKRB-470 setting vno & cksum fields when making
> authenticator
>
> -----Original Message-----
> From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
> Sent: Monday, November 23, 2015 11:30 AM
> To: kerby@directory.apache.org
> Subject: RE: KDC is rejecting my TGS
>
> ah. That would do it :) sounds like we are getting close!
>
> Thanks
> Marc
> On Nov 22, 2015 10:27 PM, "Zheng, Kai" <ka...@intel.com> wrote:
>
> > OK, forget it. I just checked the codes, and found the checksum
> > isn't done and filled in authenticator. I will get it fixed ASAP.
> >
> > Regards,
> > Kai
> >
> > -----Original Message-----
> > From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
> > Sent: Monday, November 23, 2015 11:24 AM
> > To: kerby@directory.apache.org
> > Subject: RE: KDC is rejecting my TGS
> >
> > >
> > > Cool!! Thanks a lot for getting the hard issue figured out.
> > >
> >
> > My pleasure. I'm glad I'm making progress.
> >
> > > 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.
> >
> > I haven't yet. I've shutdown for the night but the there really
> > isn't a stack trace because MIT is returning a kerberos generic
> > error (with the accompanying log messages I sent over). I wanted to
> > make sure I was reading the code properly before I started trying
> > things since MIT isn't giving me the best error messages. I'll give it a go tomorrow.
> >
> > Thanks
> > Marc
> >
>
Re: KDC is rejecting my TGS
Posted by Marc Boorshtein <mb...@gmail.com>.
New error:
Nov 23 07:57:34 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1 etypes
{17}) 192.168.2.129: ISSUE: authtime 1448283454, etypes {rep=17 tkt=18
ses=17}, HTTP/s4u.rhelent.lan@RHELENT.LAN for krbtgt/RHELENT.LAN@RHELENT.LAN
Nov 23 07:57:34 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,
Decrypt integrity check failed
Here's the packet trace :
https://s3.amazonaws.com/ts-public-downloads/captures/kerb-bad_integrity.pcapng
On Mon, Nov 23, 2015 at 4:22 AM, Zheng, Kai <ka...@intel.com> wrote:
> With above fixup, I hit another issue that Kerby client failed to decrypt
> the TGS-REP.
>
> I got it work in my setup but I can't commit the codes because there're
> more cases to be investigated. Ref. the issue
> https://issues.apache.org/jira/browse/DIRKRB-472
>
> Marc,
> if you'd just go on with your case, please make the following change and
> try.
> In client side TgsRequest.java: processResponse(), use
> KeyUsage.TGS_REP_ENCPART_SUBKEY.
>
> -----Original Message-----
> From: Zheng, Kai [mailto:kai.zheng@intel.com]
> Sent: Monday, November 23, 2015 2:21 PM
> To: kerby@directory.apache.org
> Subject: RE: KDC is rejecting my TGS
>
> Fired and resolved the following issue to track the authenticator issue
> we're handling.
> Will setup a box to test: Kerby client -> MIT KDC (in service ticket path)
>
> commit df6ba15d4f990b104efcf36ede913f4eeb09a872
> Author: Drankye <dr...@gmail.com>
> Date: Tue Nov 24 14:16:32 2015 +0800
>
> DIRKRB-469 & DIRKRB-470 setting vno & cksum fields when making
> authenticator
>
> -----Original Message-----
> From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
> Sent: Monday, November 23, 2015 11:30 AM
> To: kerby@directory.apache.org
> Subject: RE: KDC is rejecting my TGS
>
> ah. That would do it :) sounds like we are getting close!
>
> Thanks
> Marc
> On Nov 22, 2015 10:27 PM, "Zheng, Kai" <ka...@intel.com> wrote:
>
> > OK, forget it. I just checked the codes, and found the checksum isn't
> > done and filled in authenticator. I will get it fixed ASAP.
> >
> > Regards,
> > Kai
> >
> > -----Original Message-----
> > From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
> > Sent: Monday, November 23, 2015 11:24 AM
> > To: kerby@directory.apache.org
> > Subject: RE: KDC is rejecting my TGS
> >
> > >
> > > Cool!! Thanks a lot for getting the hard issue figured out.
> > >
> >
> > My pleasure. I'm glad I'm making progress.
> >
> > > 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.
> >
> > I haven't yet. I've shutdown for the night but the there really isn't
> > a stack trace because MIT is returning a kerberos generic error (with
> > the accompanying log messages I sent over). I wanted to make sure I
> > was reading the code properly before I started trying things since MIT
> > isn't giving me the best error messages. I'll give it a go tomorrow.
> >
> > Thanks
> > Marc
> >
>
RE: KDC is rejecting my TGS
Posted by "Zheng, Kai" <ka...@intel.com>.
With above fixup, I hit another issue that Kerby client failed to decrypt the TGS-REP.
I got it work in my setup but I can't commit the codes because there're more cases to be investigated. Ref. the issue
https://issues.apache.org/jira/browse/DIRKRB-472
Marc,
if you'd just go on with your case, please make the following change and try.
In client side TgsRequest.java: processResponse(), use KeyUsage.TGS_REP_ENCPART_SUBKEY.
-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Monday, November 23, 2015 2:21 PM
To: kerby@directory.apache.org
Subject: RE: KDC is rejecting my TGS
Fired and resolved the following issue to track the authenticator issue we're handling.
Will setup a box to test: Kerby client -> MIT KDC (in service ticket path)
commit df6ba15d4f990b104efcf36ede913f4eeb09a872
Author: Drankye <dr...@gmail.com>
Date: Tue Nov 24 14:16:32 2015 +0800
DIRKRB-469 & DIRKRB-470 setting vno & cksum fields when making authenticator
-----Original Message-----
From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
Sent: Monday, November 23, 2015 11:30 AM
To: kerby@directory.apache.org
Subject: RE: KDC is rejecting my TGS
ah. That would do it :) sounds like we are getting close!
Thanks
Marc
On Nov 22, 2015 10:27 PM, "Zheng, Kai" <ka...@intel.com> wrote:
> OK, forget it. I just checked the codes, and found the checksum isn't
> done and filled in authenticator. I will get it fixed ASAP.
>
> Regards,
> Kai
>
> -----Original Message-----
> From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
> Sent: Monday, November 23, 2015 11:24 AM
> To: kerby@directory.apache.org
> Subject: RE: KDC is rejecting my TGS
>
> >
> > Cool!! Thanks a lot for getting the hard issue figured out.
> >
>
> My pleasure. I'm glad I'm making progress.
>
> > 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.
>
> I haven't yet. I've shutdown for the night but the there really isn't
> a stack trace because MIT is returning a kerberos generic error (with
> the accompanying log messages I sent over). I wanted to make sure I
> was reading the code properly before I started trying things since MIT
> isn't giving me the best error messages. I'll give it a go tomorrow.
>
> Thanks
> Marc
>
RE: KDC is rejecting my TGS
Posted by "Zheng, Kai" <ka...@intel.com>.
Fired and resolved the following issue to track the authenticator issue we're handling.
Will setup a box to test: Kerby client -> MIT KDC (in service ticket path)
commit df6ba15d4f990b104efcf36ede913f4eeb09a872
Author: Drankye <dr...@gmail.com>
Date: Tue Nov 24 14:16:32 2015 +0800
DIRKRB-469 & DIRKRB-470 setting vno & cksum fields when making authenticator
-----Original Message-----
From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
Sent: Monday, November 23, 2015 11:30 AM
To: kerby@directory.apache.org
Subject: RE: KDC is rejecting my TGS
ah. That would do it :) sounds like we are getting close!
Thanks
Marc
On Nov 22, 2015 10:27 PM, "Zheng, Kai" <ka...@intel.com> wrote:
> OK, forget it. I just checked the codes, and found the checksum isn't
> done and filled in authenticator. I will get it fixed ASAP.
>
> Regards,
> Kai
>
> -----Original Message-----
> From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
> Sent: Monday, November 23, 2015 11:24 AM
> To: kerby@directory.apache.org
> Subject: RE: KDC is rejecting my TGS
>
> >
> > Cool!! Thanks a lot for getting the hard issue figured out.
> >
>
> My pleasure. I'm glad I'm making progress.
>
> > 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.
>
> I haven't yet. I've shutdown for the night but the there really isn't
> a stack trace because MIT is returning a kerberos generic error (with
> the accompanying log messages I sent over). I wanted to make sure I
> was reading the code properly before I started trying things since MIT
> isn't giving me the best error messages. I'll give it a go tomorrow.
>
> Thanks
> Marc
>
RE: KDC is rejecting my TGS
Posted by Marc Boorshtein <mb...@gmail.com>.
ah. That would do it :) sounds like we are getting close!
Thanks
Marc
On Nov 22, 2015 10:27 PM, "Zheng, Kai" <ka...@intel.com> wrote:
> OK, forget it. I just checked the codes, and found the checksum isn't done
> and filled in authenticator. I will get it fixed ASAP.
>
> Regards,
> Kai
>
> -----Original Message-----
> From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
> Sent: Monday, November 23, 2015 11:24 AM
> To: kerby@directory.apache.org
> Subject: RE: KDC is rejecting my TGS
>
> >
> > Cool!! Thanks a lot for getting the hard issue figured out.
> >
>
> My pleasure. I'm glad I'm making progress.
>
> > 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.
>
> I haven't yet. I've shutdown for the night but the there really isn't a
> stack trace because MIT is returning a kerberos generic error (with the
> accompanying log messages I sent over). I wanted to make sure I was reading
> the code properly before I started trying things since MIT isn't giving me
> the best error messages. I'll give it a go tomorrow.
>
> Thanks
> Marc
>
RE: KDC is rejecting my TGS
Posted by "Zheng, Kai" <ka...@intel.com>.
OK, forget it. I just checked the codes, and found the checksum isn't done and filled in authenticator. I will get it fixed ASAP.
Regards,
Kai
-----Original Message-----
From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
Sent: Monday, November 23, 2015 11:24 AM
To: kerby@directory.apache.org
Subject: RE: KDC is rejecting my TGS
>
> Cool!! Thanks a lot for getting the hard issue figured out.
>
My pleasure. I'm glad I'm making progress.
> 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.
I haven't yet. I've shutdown for the night but the there really isn't a stack trace because MIT is returning a kerberos generic error (with the accompanying log messages I sent over). I wanted to make sure I was reading the code properly before I started trying things since MIT isn't giving me the best error messages. I'll give it a go tomorrow.
Thanks
Marc
RE: KDC is rejecting my TGS
Posted by Marc Boorshtein <mb...@gmail.com>.
>
> Cool!! Thanks a lot for getting the hard issue figured out.
>
My pleasure. I'm glad I'm making progress.
> 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.
I haven't yet. I've shutdown for the night but the there really isn't a
stack trace because MIT is returning a kerberos generic error (with the
accompanying log messages I sent over). I wanted to make sure I was reading
the code properly before I started trying things since MIT isn't giving me
the best error messages. I'll give it a go tomorrow.
Thanks
Marc
RE: KDC is rejecting my TGS
Posted by "Zheng, Kai" <ka...@intel.com>.
>> but it looks like the KeyUsage being passed into EncryptionUtil.seal is 7 (TGS_REQ).
I thought you meant CheckSumUtil and checksum instead of encryption?
-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Monday, November 23, 2015 11:11 AM
To: kerby@directory.apache.org
Subject: RE: KDC is rejecting my TGS
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 <ka...@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 <ka...@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?
> >
>
RE: KDC is rejecting my TGS
Posted by "Zheng, Kai" <ka...@intel.com>.
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 <ka...@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 <ka...@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?
> >
>
Re: KDC is rejecting my TGS
Posted by Marc Boorshtein <mb...@gmail.com>.
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 <ka...@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 <ka...@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?
> >
>
RE: KDC is rejecting my TGS
Posted by "Zheng, Kai" <ka...@intel.com>.
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 <ka...@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?
>
Re: KDC is rejecting my TGS
Posted by Marc Boorshtein <mb...@gmail.com>.
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 <ka...@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?
>
RE: KDC is rejecting my TGS
Posted by "Zheng, Kai" <ka...@intel.com>.
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?
Re: KDC is rejecting my TGS
Posted by Marc Boorshtein <mb...@gmail.com>.
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?
Re: KDC is rejecting my TGS
Posted by Marc Boorshtein <mb...@gmail.com>.
On Fri, Nov 20, 2015 at 11:05 PM, Zheng, Kai <ka...@intel.com> wrote:
> See your snapshots. In the two AS-REQes, a diff is the kdc-option flags.
> Kerby sets the following all by default, which may be incorrect.
> In the client side KdcRequest.java file:
> protected void processKdcOptions() {
> // By default enforce these flags
> kdcOptions.setFlag(KdcOption.FORWARDABLE);
> kdcOptions.setFlag(KdcOption.PROXIABLE);
> kdcOptions.setFlag(KdcOption.RENEWABLE_OK);
>
So I made these line up, I also added a flag to makeRequest to not include
the cname for TGS-REQ, removed the "from" for TGS and set until for TGS-REQ
to 0. These changes made the TGS-REQ the same, but the same error. Going
trough the MIT source code, the error is actually only generated by the
encoder, not the decoder. I don't think the issue was with the TGS-REQ,
but when the KDC is generating the TGS-REP. Looking at the AS-REQ, the
only difference I see is the kvno in the PA-ENC-TIMESTAMP. Looking through
the code now to figure out how to include the kvno.
Thanks
Marc
RE: KDC is rejecting my TGS
Posted by "Zheng, Kai" <ka...@intel.com>.
See your snapshots. In the two AS-REQes, a diff is the kdc-option flags. Kerby sets the following all by default, which may be incorrect.
In the client side KdcRequest.java file:
protected void processKdcOptions() {
// By default enforce these flags
kdcOptions.setFlag(KdcOption.FORWARDABLE);
kdcOptions.setFlag(KdcOption.PROXIABLE);
kdcOptions.setFlag(KdcOption.RENEWABLE_OK);
A try would be to remove above 3 lines. I haven't got these flags clear yet but guess they may need extra fields?
Regards,
Kai
-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Saturday, November 21, 2015 11:47 AM
To: kerby@directory.apache.org
Subject: RE: KDC is rejecting my TGS
OK, I will install the pcap stuff.
What I've fixed is the TGS principal type, not the server principal type. As I said in the JIRA, it may be not the cause for the problem here.
Another fix is the kvno. Still not the exact cause.
I thought we need to figure out what field is missing in the ASN1 structure. Would you dig into MIT KDC logs? Verbose?
-----Original Message-----
From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
Sent: Saturday, November 21, 2015 11:36 AM
To: kerby@directory.apache.org
Subject: Re: KDC is rejecting my TGS
I think I'll make this easier and just provide links to a pcap. I pulled your updates Kai but am getting the same error. Here's the control:
https://s3.amazonaws.com/ts-public-downloads/captures/kerberos-control.pcap.pcapng
Here's the kerby capture:
https://s3.amazonaws.com/ts-public-downloads/captures/kerby-capture.pcapng
The sname type is still NT-Principal. I added some code that let me specify the server principal as a PrincipalName instead of just a string.
When I do this though I get same error out of freeipa.
Anything else standout?
Thanks
On Fri, Nov 20, 2015 at 8:12 PM, Zheng, Kai <ka...@intel.com> wrote:
> The hex format may does the good letting us find the exact missing or
> different field, though. It's concise and exact.
>
> -----Original Message-----
> From: Zheng, Kai [mailto:kai.zheng@intel.com]
> Sent: Saturday, November 21, 2015 9:06 AM
> To: kerby@directory.apache.org
> Subject: RE: KDC is rejecting my TGS
>
> The text format might save us some time when just want to take a look
> from having a tool dump out from hex.
> I guess the text could be ok if it's made more compact?
>
> -----Original Message-----
> From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
> Sent: Saturday, November 21, 2015 7:04 AM
> To: kerby@directory.apache.org
> Subject: Re: KDC is rejecting my TGS
>
> Le 20/11/15 23:27, Zheng, Kai a écrit :
> > Marc,
> >
> > You detail looks pretty good. Thanks!
> >
> > From your observation I copied below, I thought all the differences
> should be checked. The kvno (255 too large, bet 1) and principal name
> types for client and server may be the causes that block you, but I'm
> not very sure.
> > For now, please set principal type manually, and would be good to
> provide the similar comparing for the AS-REQ because that's the starting.
> I'm looking into this. Thanks.
> >
> > The differences I see are:
> > 1. The authenticator from kerby PS-TGS-REQ has a kvno=255, java
> > doesn't have that attribute 2. Kerby has a cname section with the
> > name of the client, java's implementation does not 3. Kerby's SNAME
> > has a name-type of KRB5-NT-Principal where as java's is
> > KRB5-NT-Unknown 4. Kerby has a "from", java does not 5. Kerby's
> > from and till are real dates, Java's is expired
>
> What would be good is to provide the PDU as it's being transmitted, in
> Hex format. I must say it's easier for me to read such things than any
> other output.
>
>
RE: KDC is rejecting my TGS
Posted by "Zheng, Kai" <ka...@intel.com>.
OK, I will install the pcap stuff.
What I've fixed is the TGS principal type, not the server principal type. As I said in the JIRA, it may be not the cause for the problem here.
Another fix is the kvno. Still not the exact cause.
I thought we need to figure out what field is missing in the ASN1 structure. Would you dig into MIT KDC logs? Verbose?
-----Original Message-----
From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
Sent: Saturday, November 21, 2015 11:36 AM
To: kerby@directory.apache.org
Subject: Re: KDC is rejecting my TGS
I think I'll make this easier and just provide links to a pcap. I pulled your updates Kai but am getting the same error. Here's the control:
https://s3.amazonaws.com/ts-public-downloads/captures/kerberos-control.pcap.pcapng
Here's the kerby capture:
https://s3.amazonaws.com/ts-public-downloads/captures/kerby-capture.pcapng
The sname type is still NT-Principal. I added some code that let me specify the server principal as a PrincipalName instead of just a string.
When I do this though I get same error out of freeipa.
Anything else standout?
Thanks
On Fri, Nov 20, 2015 at 8:12 PM, Zheng, Kai <ka...@intel.com> wrote:
> The hex format may does the good letting us find the exact missing or
> different field, though. It's concise and exact.
>
> -----Original Message-----
> From: Zheng, Kai [mailto:kai.zheng@intel.com]
> Sent: Saturday, November 21, 2015 9:06 AM
> To: kerby@directory.apache.org
> Subject: RE: KDC is rejecting my TGS
>
> The text format might save us some time when just want to take a look
> from having a tool dump out from hex.
> I guess the text could be ok if it's made more compact?
>
> -----Original Message-----
> From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
> Sent: Saturday, November 21, 2015 7:04 AM
> To: kerby@directory.apache.org
> Subject: Re: KDC is rejecting my TGS
>
> Le 20/11/15 23:27, Zheng, Kai a écrit :
> > Marc,
> >
> > You detail looks pretty good. Thanks!
> >
> > From your observation I copied below, I thought all the differences
> should be checked. The kvno (255 too large, bet 1) and principal name
> types for client and server may be the causes that block you, but I'm
> not very sure.
> > For now, please set principal type manually, and would be good to
> provide the similar comparing for the AS-REQ because that's the starting.
> I'm looking into this. Thanks.
> >
> > The differences I see are:
> > 1. The authenticator from kerby PS-TGS-REQ has a kvno=255, java
> > doesn't have that attribute 2. Kerby has a cname section with the
> > name of the client, java's implementation does not 3. Kerby's SNAME
> > has a name-type of KRB5-NT-Principal where as java's is
> > KRB5-NT-Unknown 4. Kerby has a "from", java does not 5. Kerby's
> > from and till are real dates, Java's is expired
>
> What would be good is to provide the PDU as it's being transmitted, in
> Hex format. I must say it's easier for me to read such things than any
> other output.
>
>
Re: KDC is rejecting my TGS
Posted by Marc Boorshtein <mb...@gmail.com>.
I think I'll make this easier and just provide links to a pcap. I pulled
your updates Kai but am getting the same error. Here's the control:
https://s3.amazonaws.com/ts-public-downloads/captures/kerberos-control.pcap.pcapng
Here's the kerby capture:
https://s3.amazonaws.com/ts-public-downloads/captures/kerby-capture.pcapng
The sname type is still NT-Principal. I added some code that let me
specify the server principal as a PrincipalName instead of just a string.
When I do this though I get same error out of freeipa.
Anything else standout?
Thanks
On Fri, Nov 20, 2015 at 8:12 PM, Zheng, Kai <ka...@intel.com> wrote:
> The hex format may does the good letting us find the exact missing or
> different field, though. It's concise and exact.
>
> -----Original Message-----
> From: Zheng, Kai [mailto:kai.zheng@intel.com]
> Sent: Saturday, November 21, 2015 9:06 AM
> To: kerby@directory.apache.org
> Subject: RE: KDC is rejecting my TGS
>
> The text format might save us some time when just want to take a look from
> having a tool dump out from hex.
> I guess the text could be ok if it's made more compact?
>
> -----Original Message-----
> From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
> Sent: Saturday, November 21, 2015 7:04 AM
> To: kerby@directory.apache.org
> Subject: Re: KDC is rejecting my TGS
>
> Le 20/11/15 23:27, Zheng, Kai a écrit :
> > Marc,
> >
> > You detail looks pretty good. Thanks!
> >
> > From your observation I copied below, I thought all the differences
> should be checked. The kvno (255 too large, bet 1) and principal name types
> for client and server may be the causes that block you, but I'm not very
> sure.
> > For now, please set principal type manually, and would be good to
> provide the similar comparing for the AS-REQ because that's the starting.
> I'm looking into this. Thanks.
> >
> > The differences I see are:
> > 1. The authenticator from kerby PS-TGS-REQ has a kvno=255, java
> > doesn't have that attribute 2. Kerby has a cname section with the
> > name of the client, java's implementation does not 3. Kerby's SNAME
> > has a name-type of KRB5-NT-Principal where as java's is
> > KRB5-NT-Unknown 4. Kerby has a "from", java does not 5. Kerby's from
> > and till are real dates, Java's is expired
>
> What would be good is to provide the PDU as it's being transmitted, in Hex
> format. I must say it's easier for me to read such things than any other
> output.
>
>
RE: KDC is rejecting my TGS
Posted by "Zheng, Kai" <ka...@intel.com>.
The hex format may does the good letting us find the exact missing or different field, though. It's concise and exact.
-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Saturday, November 21, 2015 9:06 AM
To: kerby@directory.apache.org
Subject: RE: KDC is rejecting my TGS
The text format might save us some time when just want to take a look from having a tool dump out from hex.
I guess the text could be ok if it's made more compact?
-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
Sent: Saturday, November 21, 2015 7:04 AM
To: kerby@directory.apache.org
Subject: Re: KDC is rejecting my TGS
Le 20/11/15 23:27, Zheng, Kai a écrit :
> Marc,
>
> You detail looks pretty good. Thanks!
>
> From your observation I copied below, I thought all the differences should be checked. The kvno (255 too large, bet 1) and principal name types for client and server may be the causes that block you, but I'm not very sure.
> For now, please set principal type manually, and would be good to provide the similar comparing for the AS-REQ because that's the starting. I'm looking into this. Thanks.
>
> The differences I see are:
> 1. The authenticator from kerby PS-TGS-REQ has a kvno=255, java
> doesn't have that attribute 2. Kerby has a cname section with the
> name of the client, java's implementation does not 3. Kerby's SNAME
> has a name-type of KRB5-NT-Principal where as java's is
> KRB5-NT-Unknown 4. Kerby has a "from", java does not 5. Kerby's from
> and till are real dates, Java's is expired
What would be good is to provide the PDU as it's being transmitted, in Hex format. I must say it's easier for me to read such things than any other output.
RE: KDC is rejecting my TGS
Posted by "Zheng, Kai" <ka...@intel.com>.
The text format might save us some time when just want to take a look from having a tool dump out from hex.
I guess the text could be ok if it's made more compact?
-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
Sent: Saturday, November 21, 2015 7:04 AM
To: kerby@directory.apache.org
Subject: Re: KDC is rejecting my TGS
Le 20/11/15 23:27, Zheng, Kai a écrit :
> Marc,
>
> You detail looks pretty good. Thanks!
>
> From your observation I copied below, I thought all the differences should be checked. The kvno (255 too large, bet 1) and principal name types for client and server may be the causes that block you, but I'm not very sure.
> For now, please set principal type manually, and would be good to provide the similar comparing for the AS-REQ because that's the starting. I'm looking into this. Thanks.
>
> The differences I see are:
> 1. The authenticator from kerby PS-TGS-REQ has a kvno=255, java
> doesn't have that attribute 2. Kerby has a cname section with the
> name of the client, java's implementation does not 3. Kerby's SNAME
> has a name-type of KRB5-NT-Principal where as java's is
> KRB5-NT-Unknown 4. Kerby has a "from", java does not 5. Kerby's from
> and till are real dates, Java's is expired
What would be good is to provide the PDU as it's being transmitted, in Hex format. I must say it's easier for me to read such things than any other output.
Re: KDC is rejecting my TGS
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 20/11/15 23:27, Zheng, Kai a écrit :
> Marc,
>
> You detail looks pretty good. Thanks!
>
> From your observation I copied below, I thought all the differences should be checked. The kvno (255 too large, bet 1) and principal name types for client and server may be the causes that block you, but I'm not very sure.
> For now, please set principal type manually, and would be good to provide the similar comparing for the AS-REQ because that's the starting. I'm looking into this. Thanks.
>
> The differences I see are:
> 1. The authenticator from kerby PS-TGS-REQ has a kvno=255, java doesn't have that attribute
> 2. Kerby has a cname section with the name of the client, java's implementation does not
> 3. Kerby's SNAME has a name-type of KRB5-NT-Principal where as java's is KRB5-NT-Unknown
> 4. Kerby has a "from", java does not
> 5. Kerby's from and till are real dates, Java's is expired
What would be good is to provide the PDU as it's being transmitted, in
Hex format. I must say it's easier for me to read such things than any
other output.
RE: KDC is rejecting my TGS
Posted by "Zheng, Kai" <ka...@intel.com>.
Marc,
You detail looks pretty good. Thanks!
From your observation I copied below, I thought all the differences should be checked. The kvno (255 too large, bet 1) and principal name types for client and server may be the causes that block you, but I'm not very sure.
For now, please set principal type manually, and would be good to provide the similar comparing for the AS-REQ because that's the starting. I'm looking into this. Thanks.
The differences I see are:
1. The authenticator from kerby PS-TGS-REQ has a kvno=255, java doesn't have that attribute
2. Kerby has a cname section with the name of the client, java's implementation does not
3. Kerby's SNAME has a name-type of KRB5-NT-Principal where as java's is KRB5-NT-Unknown
4. Kerby has a "from", java does not
5. Kerby's from and till are real dates, Java's is expired
-----Original Message-----
From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
Sent: Saturday, November 21, 2015 1:00 AM
To: kerby@directory.apache.org
Subject: KDC is rejecting my TGS
I've merged in all the new changes from Kai and Steve. I get a TGT without issue, but now I'm getting the following error from freeipa (built on MIT
kerberos):
Nov 20 09:38:40 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1 etypes
{17}) 10.8.0.2: ISSUE: authtime 1448030320, etypes {rep=17 tkt=18 ses=17}, HTTP/s4u.rhelent.lan@RHELENT.LAN for krbtgt/RHELENT.LAN@RHELENT.LAN
Nov 20 09:38:40 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (1 etypes
{17}) 10.8.0.2: PROCESS_TGS: authtime 0, <unknown client> for HTTP/ipa.rhelent.lan@RHELENT.LAN, ASN.1 structure is missing a required field
Now unfortunately its not say WHAT the missing field is. I've got a control setup to make the same request in java using the same keytab for the same resources. Here's the TGS request that works using the standard java kerberos libraries:
No. Time Source Destination Protocol
Length Info
84 4.103473000 10.8.0.2 192.168.2.166 KRB5
693 TGS-REQ
Frame 84: 693 bytes on wire (5544 bits), 693 bytes captured (5544 bits) on interface 3
Interface id: 3 (utun0)
Encapsulation type: NULL (15)
Arrival Time: Nov 20, 2015 11:47:55.953694000 EST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1448038075.953694000 seconds
[Time delta from previous captured frame: 0.019420000 seconds]
[Time delta from previous displayed frame: 0.019361000 seconds]
[Time since reference or first frame: 4.103473000 seconds]
Frame Number: 84
Frame Length: 693 bytes (5544 bits)
Capture Length: 693 bytes (5544 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: null:ip:udp:kerberos]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Null/Loopback
Family: IP (2)
Internet Protocol Version 4, Src: 10.8.0.2 (10.8.0.2), Dst: 192.168.2.166
(192.168.2.166)
Version: 4
Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00:
Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: 689
Identification: 0x175e (5982)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0x9386 [validation disabled]
[Good: False]
[Bad: False]
Source: 10.8.0.2 (10.8.0.2)
Destination: 192.168.2.166 (192.168.2.166)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 49177 (49177), Dst Port: 88 (88)
Source Port: 49177 (49177)
Destination Port: 88 (88)
Length: 669
Checksum: 0x8f4e [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
[Stream index: 8]
Kerberos
tgs-req
pvno: 5
msg-type: krb-tgs-req (12)
padata: 1 item
PA-DATA PA-TGS-REQ
padata-type: kRB5-PADATA-TGS-REQ (1)
padata-value:
6e8201fa308201f6a003020105a10302010ea20703050000...
ap-req
pvno: 5
msg-type: krb-ap-req (14)
Padding: 0
ap-options: 00000000
0... .... = reserved: False
.0.. .... = use-session-key: False
..0. .... = mutual-required: False
ticket
tkt-vno: 5
realm: RHELENT.LAN
sname
name-type: kRB5-NT-SRV-INST (2)
name-string: 2 items
KerberosString: krbtgt
KerberosString: RHELENT.LAN
enc-part
etype: eTYPE-AES256-CTS-HMAC-SHA1-96
(18)
kvno: 1
cipher:
28198273460862c515248752f713987ea6857b206fe8fe86...
authenticator
etype: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
cipher:
9101cb1fb3694bbc9cfb972c73711cb8e33d59e1de7fdb1a...
req-body
Padding: 0
kdc-options: 40000000 (forwardable)
0... .... = reserved: False
.1.. .... = forwardable: True
..0. .... = forwarded: False
...0 .... = proxiable: False
.... 0... = proxy: False
.... .0.. = allow-postdate: False
.... ..0. = postdated: False
.... ...0 = unused7: False
0... .... = renewable: False
.0.. .... = unused9: False
..0. .... = unused10: False
...0 .... = opt-hardware-auth: False
.... ..0. = request-anonymous: False
.... ...0 = canonicalize: False
0... .... = constrained-delegation: False
..0. .... = disable-transited-check: False
...0 .... = renewable-ok: False
.... 0... = enc-tkt-in-skey: False
.... ..0. = renew: False
.... ...0 = validate: False
realm: RHELENT.LAN
sname
name-type: kRB5-NT-UNKNOWN (0)
name-string: 2 items
KerberosString: HTTP
KerberosString: freeipa.rhelent.lan
till: 1970-01-01 00:00:00 (UTC)
nonce: 1040086776
etype: 3 items
ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)
ENCTYPE: eTYPE-DES3-CBC-SHA1 (16)
and from kerby:
No. Time Source Destination Protocol
Length Info
2888 255.037980000 10.8.0.2 192.168.2.166 KRB5
742 TGS-REQ
Frame 2888: 742 bytes on wire (5936 bits), 742 bytes captured (5936 bits) on interface 3
Interface id: 3 (utun0)
Encapsulation type: NULL (15)
Arrival Time: Nov 20, 2015 11:52:06.888201000 EST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1448038326.888201000 seconds
[Time delta from previous captured frame: -0.000117000 seconds]
[Time delta from previous displayed frame: 0.010323000 seconds]
[Time since reference or first frame: 255.037980000 seconds]
Frame Number: 2888
Frame Length: 742 bytes (5936 bits)
Capture Length: 742 bytes (5936 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: null:ip:udp:kerberos]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Null/Loopback
Family: IP (2)
Internet Protocol Version 4, Src: 10.8.0.2 (10.8.0.2), Dst: 192.168.2.166
(192.168.2.166)
Version: 4
Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00:
Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: 738
Identification: 0x226e (8814)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0x8845 [validation disabled]
[Good: False]
[Bad: False]
Source: 10.8.0.2 (10.8.0.2)
Destination: 192.168.2.166 (192.168.2.166)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 56122 (56122), Dst Port: 88 (88)
Source Port: 56122 (56122)
Destination Port: 88 (88)
Length: 718
Checksum: 0x461a [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
[Stream index: 30]
Kerberos
tgs-req
pvno: 5
msg-type: krb-tgs-req (12)
padata: 1 item
PA-DATA PA-TGS-REQ
padata-type: kRB5-PADATA-TGS-REQ (1)
padata-value:
6e8201f8308201f4a003020105a10302010ea20703050000...
ap-req
pvno: 5
msg-type: krb-ap-req (14)
Padding: 0
ap-options: 00000000
0... .... = reserved: False
.0.. .... = use-session-key: False
..0. .... = mutual-required: False
ticket
tkt-vno: 5
realm: RHELENT.LAN
sname
name-type: kRB5-NT-PRINCIPAL (1)
name-string: 2 items
KerberosString: krbtgt
KerberosString: RHELENT.LAN
enc-part
etype: eTYPE-AES256-CTS-HMAC-SHA1-96
(18)
kvno: 1
cipher:
1bea5e1ce7205e55dd088dc647222d5a20d62c41a172c0b4...
authenticator
etype: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
kvno: 255
cipher:
dd243f0d6aaa9c03a6e6737b18ca8510d4bfac33296a07d2...
req-body
Padding: 0
kdc-options: 40000000 (forwardable)
0... .... = reserved: False
.1.. .... = forwardable: True
..0. .... = forwarded: False
...0 .... = proxiable: False
.... 0... = proxy: False
.... .0.. = allow-postdate: False
.... ..0. = postdated: False
.... ...0 = unused7: False
0... .... = renewable: False
.0.. .... = unused9: False
..0. .... = unused10: False
...0 .... = opt-hardware-auth: False
.... ..0. = request-anonymous: False
.... ...0 = canonicalize: False
0... .... = constrained-delegation: False
..0. .... = disable-transited-check: False
...0 .... = renewable-ok: False
.... 0... = enc-tkt-in-skey: False
.... ..0. = renew: False
.... ...0 = validate: False
cname
name-type: kRB5-NT-PRINCIPAL (1)
name-string: 2 items
KerberosString: HTTP
KerberosString: s4u.rhelent.lan
realm: RHELENT.LAN
sname
name-type: kRB5-NT-PRINCIPAL (1)
name-string: 2 items
KerberosString: HTTP
KerberosString: freeipa.rhelent.lan
from: 2015-11-20 16:52:06 (UTC)
till: 2015-11-21 00:52:06 (UTC)
nonce: 984126497
etype: 1 item
ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
The differences I see are:
1. The authenticator from kerby PS-TGS-REQ has a kvno=255, java doesn't have that attribute
2. Kerby has a cname section with the name of the client, java's implementation does not
3. Kerby's SNAME has a name-type of KRB5-NT-Principal where as java's is KRB5-NT-Unknown
4. Kerby has a "from", java does not
5. Kerby's from and till are real dates, Java's is expired
My guess is the issue is #3? I'm thinking I can set that in the options.
I already added a method that lets me get an SGT with options (like the tgtWithOptions method). I'll see if there's a way to specify the principal type from there. Anything else stand out?
Thanks
Marc
RE: KDC is rejecting my TGS
Posted by "Zheng, Kai" <ka...@intel.com>.
I have fixed the two mentioned issues and please check it out.
The JIRAs are linked here
https://issues.apache.org/jira/browse/DIRKRB-234
Will check other left things.
-----Original Message-----
From: Zheng, Kai
Sent: Saturday, November 21, 2015 6:28 AM
To: kerby@directory.apache.org
Subject: RE: KDC is rejecting my TGS
Marc,
You detail looks pretty good. Thanks!
From your observation I copied below, I thought all the differences should be checked. The kvno (255 too large, bet 1) and principal name types for client and server may be the causes that block you, but I'm not very sure.
For now, please set principal type manually, and would be good to provide the similar comparing for the AS-REQ because that's the starting. I'm looking into this. Thanks.
The differences I see are:
1. The authenticator from kerby PS-TGS-REQ has a kvno=255, java doesn't have that attribute 2. Kerby has a cname section with the name of the client, java's implementation does not 3. Kerby's SNAME has a name-type of KRB5-NT-Principal where as java's is KRB5-NT-Unknown 4. Kerby has a "from", java does not 5. Kerby's from and till are real dates, Java's is expired
-----Original Message-----
From: Marc Boorshtein [mailto:mboorshtein@gmail.com]
Sent: Saturday, November 21, 2015 1:00 AM
To: kerby@directory.apache.org
Subject: KDC is rejecting my TGS
I've merged in all the new changes from Kai and Steve. I get a TGT without issue, but now I'm getting the following error from freeipa (built on MIT
kerberos):
Nov 20 09:38:40 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (1 etypes
{17}) 10.8.0.2: ISSUE: authtime 1448030320, etypes {rep=17 tkt=18 ses=17}, HTTP/s4u.rhelent.lan@RHELENT.LAN for krbtgt/RHELENT.LAN@RHELENT.LAN
Nov 20 09:38:40 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (1 etypes
{17}) 10.8.0.2: PROCESS_TGS: authtime 0, <unknown client> for HTTP/ipa.rhelent.lan@RHELENT.LAN, ASN.1 structure is missing a required field
Now unfortunately its not say WHAT the missing field is. I've got a control setup to make the same request in java using the same keytab for the same resources. Here's the TGS request that works using the standard java kerberos libraries:
No. Time Source Destination Protocol
Length Info
84 4.103473000 10.8.0.2 192.168.2.166 KRB5
693 TGS-REQ
Frame 84: 693 bytes on wire (5544 bits), 693 bytes captured (5544 bits) on interface 3
Interface id: 3 (utun0)
Encapsulation type: NULL (15)
Arrival Time: Nov 20, 2015 11:47:55.953694000 EST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1448038075.953694000 seconds
[Time delta from previous captured frame: 0.019420000 seconds]
[Time delta from previous displayed frame: 0.019361000 seconds]
[Time since reference or first frame: 4.103473000 seconds]
Frame Number: 84
Frame Length: 693 bytes (5544 bits)
Capture Length: 693 bytes (5544 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: null:ip:udp:kerberos]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Null/Loopback
Family: IP (2)
Internet Protocol Version 4, Src: 10.8.0.2 (10.8.0.2), Dst: 192.168.2.166
(192.168.2.166)
Version: 4
Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00:
Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: 689
Identification: 0x175e (5982)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0x9386 [validation disabled]
[Good: False]
[Bad: False]
Source: 10.8.0.2 (10.8.0.2)
Destination: 192.168.2.166 (192.168.2.166)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 49177 (49177), Dst Port: 88 (88)
Source Port: 49177 (49177)
Destination Port: 88 (88)
Length: 669
Checksum: 0x8f4e [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
[Stream index: 8]
Kerberos
tgs-req
pvno: 5
msg-type: krb-tgs-req (12)
padata: 1 item
PA-DATA PA-TGS-REQ
padata-type: kRB5-PADATA-TGS-REQ (1)
padata-value:
6e8201fa308201f6a003020105a10302010ea20703050000...
ap-req
pvno: 5
msg-type: krb-ap-req (14)
Padding: 0
ap-options: 00000000
0... .... = reserved: False
.0.. .... = use-session-key: False
..0. .... = mutual-required: False
ticket
tkt-vno: 5
realm: RHELENT.LAN
sname
name-type: kRB5-NT-SRV-INST (2)
name-string: 2 items
KerberosString: krbtgt
KerberosString: RHELENT.LAN
enc-part
etype: eTYPE-AES256-CTS-HMAC-SHA1-96
(18)
kvno: 1
cipher:
28198273460862c515248752f713987ea6857b206fe8fe86...
authenticator
etype: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
cipher:
9101cb1fb3694bbc9cfb972c73711cb8e33d59e1de7fdb1a...
req-body
Padding: 0
kdc-options: 40000000 (forwardable)
0... .... = reserved: False
.1.. .... = forwardable: True
..0. .... = forwarded: False
...0 .... = proxiable: False
.... 0... = proxy: False
.... .0.. = allow-postdate: False
.... ..0. = postdated: False
.... ...0 = unused7: False
0... .... = renewable: False
.0.. .... = unused9: False
..0. .... = unused10: False
...0 .... = opt-hardware-auth: False
.... ..0. = request-anonymous: False
.... ...0 = canonicalize: False
0... .... = constrained-delegation: False
..0. .... = disable-transited-check: False
...0 .... = renewable-ok: False
.... 0... = enc-tkt-in-skey: False
.... ..0. = renew: False
.... ...0 = validate: False
realm: RHELENT.LAN
sname
name-type: kRB5-NT-UNKNOWN (0)
name-string: 2 items
KerberosString: HTTP
KerberosString: freeipa.rhelent.lan
till: 1970-01-01 00:00:00 (UTC)
nonce: 1040086776
etype: 3 items
ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)
ENCTYPE: eTYPE-DES3-CBC-SHA1 (16)
and from kerby:
No. Time Source Destination Protocol
Length Info
2888 255.037980000 10.8.0.2 192.168.2.166 KRB5
742 TGS-REQ
Frame 2888: 742 bytes on wire (5936 bits), 742 bytes captured (5936 bits) on interface 3
Interface id: 3 (utun0)
Encapsulation type: NULL (15)
Arrival Time: Nov 20, 2015 11:52:06.888201000 EST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1448038326.888201000 seconds
[Time delta from previous captured frame: -0.000117000 seconds]
[Time delta from previous displayed frame: 0.010323000 seconds]
[Time since reference or first frame: 255.037980000 seconds]
Frame Number: 2888
Frame Length: 742 bytes (5936 bits)
Capture Length: 742 bytes (5936 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: null:ip:udp:kerberos]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Null/Loopback
Family: IP (2)
Internet Protocol Version 4, Src: 10.8.0.2 (10.8.0.2), Dst: 192.168.2.166
(192.168.2.166)
Version: 4
Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00:
Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: 738
Identification: 0x226e (8814)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0x8845 [validation disabled]
[Good: False]
[Bad: False]
Source: 10.8.0.2 (10.8.0.2)
Destination: 192.168.2.166 (192.168.2.166)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 56122 (56122), Dst Port: 88 (88)
Source Port: 56122 (56122)
Destination Port: 88 (88)
Length: 718
Checksum: 0x461a [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
[Stream index: 30]
Kerberos
tgs-req
pvno: 5
msg-type: krb-tgs-req (12)
padata: 1 item
PA-DATA PA-TGS-REQ
padata-type: kRB5-PADATA-TGS-REQ (1)
padata-value:
6e8201f8308201f4a003020105a10302010ea20703050000...
ap-req
pvno: 5
msg-type: krb-ap-req (14)
Padding: 0
ap-options: 00000000
0... .... = reserved: False
.0.. .... = use-session-key: False
..0. .... = mutual-required: False
ticket
tkt-vno: 5
realm: RHELENT.LAN
sname
name-type: kRB5-NT-PRINCIPAL (1)
name-string: 2 items
KerberosString: krbtgt
KerberosString: RHELENT.LAN
enc-part
etype: eTYPE-AES256-CTS-HMAC-SHA1-96
(18)
kvno: 1
cipher:
1bea5e1ce7205e55dd088dc647222d5a20d62c41a172c0b4...
authenticator
etype: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
kvno: 255
cipher:
dd243f0d6aaa9c03a6e6737b18ca8510d4bfac33296a07d2...
req-body
Padding: 0
kdc-options: 40000000 (forwardable)
0... .... = reserved: False
.1.. .... = forwardable: True
..0. .... = forwarded: False
...0 .... = proxiable: False
.... 0... = proxy: False
.... .0.. = allow-postdate: False
.... ..0. = postdated: False
.... ...0 = unused7: False
0... .... = renewable: False
.0.. .... = unused9: False
..0. .... = unused10: False
...0 .... = opt-hardware-auth: False
.... ..0. = request-anonymous: False
.... ...0 = canonicalize: False
0... .... = constrained-delegation: False
..0. .... = disable-transited-check: False
...0 .... = renewable-ok: False
.... 0... = enc-tkt-in-skey: False
.... ..0. = renew: False
.... ...0 = validate: False
cname
name-type: kRB5-NT-PRINCIPAL (1)
name-string: 2 items
KerberosString: HTTP
KerberosString: s4u.rhelent.lan
realm: RHELENT.LAN
sname
name-type: kRB5-NT-PRINCIPAL (1)
name-string: 2 items
KerberosString: HTTP
KerberosString: freeipa.rhelent.lan
from: 2015-11-20 16:52:06 (UTC)
till: 2015-11-21 00:52:06 (UTC)
nonce: 984126497
etype: 1 item
ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
The differences I see are:
1. The authenticator from kerby PS-TGS-REQ has a kvno=255, java doesn't have that attribute
2. Kerby has a cname section with the name of the client, java's implementation does not
3. Kerby's SNAME has a name-type of KRB5-NT-Principal where as java's is KRB5-NT-Unknown
4. Kerby has a "from", java does not
5. Kerby's from and till are real dates, Java's is expired
My guess is the issue is #3? I'm thinking I can set that in the options.
I already added a method that lets me get an SGT with options (like the tgtWithOptions method). I'll see if there's a way to specify the principal type from there. Anything else stand out?
Thanks
Marc