directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Boorshtein <mboorsht...@gmail.com>
Subject Re: Getting started with the client API
Date Mon, 16 Nov 2015 13:35:08 GMT
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 <kai.zheng@intel.com> wrote:

> The issue was just solved. Now default_realm will be respected and used.
>
> commit cf6e39b6d4be9681dbf513a0c1417e5cf6ad839f
> Author: Kai Zheng <kai.zheng@intel.com>
> 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:mboorshtein@gmail.com]
> Sent: Saturday, November 14, 2015 11:57 PM
> To: kerby@directory.apache.org
> 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/s4u.rhelent.lan@RHELENT.LAN
> ",
> 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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message