Thanks Kai! I'm starting to walk through the code now to figure out where
changes need to be made to support s4u2self/proxy. It looks like the
KdcReq class hard codes one and only one PA-DATA field. S4U2Self requires
2 PA-DATA fields (1 for the PA-FOR-USER, 1 for the PA-TGS-REQ). So it
looks like the first place will be to add support for multiple PA-DATA
fields in a TGT request. Here's an example request generated by Java's
implementation:
Kerberos
tgs-req
pvno: 5
msg-type: krb-tgs-req (12)
padata: 2 items
PA-DATA PA-FOR-USER
padata-type: kRB5-PADATA-S4U2SELF (129)
padata-value:
304fa0143012a003020101a10b30091b076d6d6f736c6579...
name
name-type: kRB5-NT-PRINCIPAL (1)
name-string: 1 item
KerberosString: mmosley
realm: RHELENT.LAN
cksum
cksumtype: cKSUMTYPE-HMAC-MD5 (-138)
checksum: fdd3addace7f48fe263bfcc1a4dbec72
auth: Kerberos
PA-DATA PA-TGS-REQ
padata-type: kRB5-PADATA-TGS-REQ (1)
padata-value:
6e82023730820233a003020105a10302010ea20703050000...
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:
a07df35b253755d20a234bb8f5ce573e06e27d95f9e4c996...
authenticator
etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
cipher:
fe25dc900c05901a5b1c778f0d0410fd245e58507dc4ac40...
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-PRINCIPAL (1)
name-string: 2 items
KerberosString: HTTP
KerberosString: unison-freeipa.rhelent.lan
till: 1970-01-01 00:00:00 (UTC)
nonce: 1950860413
etype: 4 items
ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
ENCTYPE: eTYPE-DES3-CBC-SHA1 (16)
ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)
This did generate an s4u2self response form IPA:
tgs-rep
pvno: 5
msg-type: krb-tgs-rep (13)
crealm: RHELENT.LAN
cname
name-type: kRB5-NT-PRINCIPAL (1)
name-string: 1 item
KerberosString: mmosley
ticket
tkt-vno: 5
realm: RHELENT.LAN
sname
name-type: kRB5-NT-PRINCIPAL (1)
name-string: 2 items
KerberosString: HTTP
KerberosString: unison-freeipa.rhelent.lan
enc-part
etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
kvno: 1
cipher: d5ba7253ac30a63034ac5985fa0c782dc86cb0a9dd859127...
enc-part
etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
cipher: 7c6f2034caddf129d1550b91f4ef0157b2f9ac4c351023d3...
On Mon, Nov 16, 2015 at 8:11 AM, Zheng, Kai <[email protected]> wrote:
> The issue was just solved. Now default_realm will be respected and used.
>
> commit cf6e39b6d4be9681dbf513a0c1417e5cf6ad839f
> Author: Kai Zheng <[email protected]>
> Date: Mon Nov 16 21:09:09 2015 +0800
>
> Handling default config value in better way and solved DIRKRB-457
>
> -----Original Message-----
> From: Marc Boorshtein [mailto:[email protected]]
> Sent: Saturday, November 14, 2015 11:57 PM
> To: [email protected]
> Subject: Re: Getting started with the client API
>
> > Thanks Kai! We're making progress. Here's the current stack trace:
> >
> > Exception in thread "main" java.lang.NullPointerException
> >
> > at org.apache.kerby.kerberos.kerb.client.request.AsRequest.getTicket(
> > AsRequest.java:135)
> >
> > at
> > org.apache.kerby.kerberos.kerb.client.impl.DefaultInternalKrbClient.do
> > RequestTgtTicket(
> > DefaultInternalKrbClient.java:76)
> >
> > at
> > org.apache.kerby.kerberos.kerb.client.impl.AbstractInternalKrbClient.r
> > equestTgtTicket(
> > AbstractInternalKrbClient.java:105)
> >
> > at
> > org.apache.kerby.kerberos.kerb.client.KrbClient.requestTgtWithOptions(
> > KrbClient.java:252)
> >
> > at
> > org.apache.kerby.kerberos.kerb.client.KrbClient.requestTgtWithKeytab(
> > KrbClient.java:194)
> >
> > at TestKerb.main(TestKerb.java:12)
> >
> > Looking at the kerberos messages over the wire it looks like its
> > setting the realm to EXAMPLE.COM even though the krb5.conf file has
> > "default_realm = RHELENT.LAN" which is causing the KDC to fail.
> > Trying to see if I can make that setting in the code instead of the
> krb5.conf file.
> >
> > Thanks
> >
> >
> > I got a ticket! Here's the code that worked:
>
> KrbClient kerb = new KrbClient(new File("/Users/mlb/Documents/testkerb"));
>
> kerb.init();
>
> kerb.setKdcRealm("RHELENT.LAN");
> TgtTicket tgt = kerb.requestTgtWithKeytab("HTTP/[email protected]
> ",
> new File("/Users/mlb/Documents/localdev.keytab"));
>
> I'll open a jira ticket for the bug with the config so we can track it.
>
> Thanks again! now for the fun part.
>
