Sounds good Marc. It looks interesting. Please feel free to fire issues or questions when you meet with more problems.
Regards, Kai -----Original Message----- From: Marc Boorshtein [mailto:[email protected]] Sent: Monday, November 16, 2015 9:38 PM To: [email protected] Subject: Re: Getting started with the client API Bah! disregard. I hadn't looked closely enough at the datatype! nm, looks like I just need to create the PA-FOR-USER and we'll be in good shape On Mon, Nov 16, 2015 at 8:35 AM, Marc Boorshtein <[email protected]> wrote: > 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.AbstractInternalKrbClien >> > t.r >> > equestTgtTicket( >> > AbstractInternalKrbClient.java:105) >> > >> > at >> > org.apache.kerby.kerberos.kerb.client.KrbClient.requestTgtWithOptio >> > ns( >> > KrbClient.java:252) >> > >> > at >> > org.apache.kerby.kerberos.kerb.client.KrbClient.requestTgtWithKeyta >> > b( >> > 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. >> > >
