RE: Kerby client library refactoring
Ah, see your idea. Yes it looks nice and let consider it. Thanks!
Regards,
Kai
-Original Message-
From: Marc Boorshtein [mailto:mboorsht...@gmail.com]
Sent: Sunday, November 29, 2015 9:50 AM
To: kerby@directory.apache.org
Subject: Re: Kerby client library refactoring
Sorry, was working on some other projects. My thought was instead of code that
looks like this:
requestOptions = new KOptions();
requestOptions.add(KrbOption.USE_TGT, tgt);
//requestOptions.add(KrbOption.SERVER_PRINCIPAL,
"HTTP/freeipa.rhelent.lan");
requestOptions.add(KrbOption.SERVER_PRINCIPAL, new
PrincipalName("HTTP/freeipa.rhelent@rhelent.lan",NameType.NT_UNKNOWN));
requestOptions.add(KrbOption.FORWARDABLE,true);
requestOptions.add(KrbOption.PROXIABLE,false);
requestOptions.add(KrbOption.RENEWABLE_OK,false);
I would think this would be more OO:
requestOptions = new KOptions();
requestOptions.setTgt(tgt);
//requestOptions.setServerPrincipal("HTTP/freeipa.rhelent.lan");
requestOptions.setServerPrincipal(new
PrincipalName("HTTP/freeipa.rhelent@rhelent.lan",NameType.NT_UNKNOWN));
requestOptions.setForwardable(true);
requestOptions.setProxiable(false);
requestOptions.setRenewable(false);
Could keep it backed by a set of options
On Thu, Nov 26, 2015 at 7:54 PM, Zheng, Kai wrote:
> Thanks Marc.
>
> An KOption is an enum value, and KOptions is essentially a map that
> does optionName -> optionValue. You mean some getters/setters for
> KOptoins? For what? Now there're already some methods to operate a
> KOptions. Maybe a simple example code? Thanks.
>
> -Original Message-
> From: Marc Boorshtein [mailto:mboorsht...@gmail.com]
> Sent: Friday, November 27, 2015 8:43 AM
> To: kerby@directory.apache.org
> Subject: Re: Kerby client library refactoring
>
> One other thing I was thinking is if we could make the options more
> object oriented. Like instead of having name value pairs we have
> getters/setters.
> On Nov 24, 2015 12:59 AM, "Zheng, Kai" wrote:
>
> > There are good feedbacks from Steve recently. Based on discussions
> > with him and Emmanuel, I assembled below thoughts.
> >
> > KrbClient and its relatives like KrbOption would be broken down
> > according to supported mechanisms and functionalities.
> > Eventually we would have these client side APIs for applications to use.
> >
> > == KrbClient ==
> > Focus on classical Kerberos protocol, allowing to request/update
> > tickets to KDC using password, keytab, credential cache and etc.
> >
> > == KrbPkinitClient ==
> > Support PKINIT mechanism, allowing to request tickets to KDC using
> > anonymous and x509 certficate.
> >
> > == KrbTokenClient ==
> > Support standard JWT token, allowing to request tickets to KDC using
> > JWT token.
> >
> > == KrbPwChange ==
> > Change passwd client, interacting with KDC using the change password
> > protocol.
> >
> > == KrbAdmin ==
> > KDC admin utilities compatible with MIT kadmin tool in either local
> > or remote mode. In remote mode interacting with KDC, though no spec
> > standardizing that.
> >
> > Note there're already keytab and credential cache utilities.
> >
> > All these components will define their own options with good
> > specific descriptions; For the components that use configurations,
> > krb5.conf is default format; For the components that interacts with
> > KDC side servers, common network and message support will be used;
> > All will provide both intuitive functions and advanced function that
> > supports directly calling into the underlying layer.
> > These library APIs can be used to write tools like kinit, or
> > embedded in applications.
> >
> > It would be good to provide corresponding server side components or
> > supports, but not mandatory. Better to have at least for easier tests.
> >
> > When sounds good, we can break this down into smaller tasks and get
> > the major work done before the 1.0.0 formal release.
> >
> > Regards,
> > Kai
> >
>
RE: KDC is rejecting my TGS
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:mboorsht...@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@rhelent.lan
for HTTP/freeipa.rhelent@rhelent.lan,
Decrypt integrity check failed
Thanks
On Mon, Nov 23, 2015 at 3:50 PM, Marc Boorshtein
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
>
> wrote:
>
>> Interesting. I'll give that a try
>> On Nov 23, 2015 9:02 AM, "Zheng, Kai" 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@rhelent.lan");
>>> requestOptions.add(KrbOption.SERVER_PRINCIPAL, new
>>> PrincipalName("HTTP/freeipa.rhelent@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:mboorsht...@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 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:mboorsht...@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@rhelent.lan for
>>> > krbtgt/rhelent@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@rhelent.lan for
>>> > HTTP/freeipa.rhelent@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
>>> 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.zh...@intel.com]
>>> > >
Re: Kerby client library refactoring
Sorry, was working on some other projects. My thought was instead of code
that looks like this:
requestOptions = new KOptions();
requestOptions.add(KrbOption.USE_TGT, tgt);
//requestOptions.add(KrbOption.SERVER_PRINCIPAL,
"HTTP/freeipa.rhelent.lan");
requestOptions.add(KrbOption.SERVER_PRINCIPAL, new
PrincipalName("HTTP/freeipa.rhelent@rhelent.lan",NameType.NT_UNKNOWN));
requestOptions.add(KrbOption.FORWARDABLE,true);
requestOptions.add(KrbOption.PROXIABLE,false);
requestOptions.add(KrbOption.RENEWABLE_OK,false);
I would think this would be more OO:
requestOptions = new KOptions();
requestOptions.setTgt(tgt);
//requestOptions.setServerPrincipal("HTTP/freeipa.rhelent.lan");
requestOptions.setServerPrincipal(new
PrincipalName("HTTP/freeipa.rhelent@rhelent.lan",NameType.NT_UNKNOWN));
requestOptions.setForwardable(true);
requestOptions.setProxiable(false);
requestOptions.setRenewable(false);
Could keep it backed by a set of options
On Thu, Nov 26, 2015 at 7:54 PM, Zheng, Kai wrote:
> Thanks Marc.
>
> An KOption is an enum value, and KOptions is essentially a map that does
> optionName -> optionValue. You mean some getters/setters for KOptoins? For
> what? Now there're already some methods to operate a KOptions. Maybe a
> simple example code? Thanks.
>
> -Original Message-
> From: Marc Boorshtein [mailto:mboorsht...@gmail.com]
> Sent: Friday, November 27, 2015 8:43 AM
> To: kerby@directory.apache.org
> Subject: Re: Kerby client library refactoring
>
> One other thing I was thinking is if we could make the options more object
> oriented. Like instead of having name value pairs we have getters/setters.
> On Nov 24, 2015 12:59 AM, "Zheng, Kai" wrote:
>
> > There are good feedbacks from Steve recently. Based on discussions
> > with him and Emmanuel, I assembled below thoughts.
> >
> > KrbClient and its relatives like KrbOption would be broken down
> > according to supported mechanisms and functionalities.
> > Eventually we would have these client side APIs for applications to use.
> >
> > == KrbClient ==
> > Focus on classical Kerberos protocol, allowing to request/update
> > tickets to KDC using password, keytab, credential cache and etc.
> >
> > == KrbPkinitClient ==
> > Support PKINIT mechanism, allowing to request tickets to KDC using
> > anonymous and x509 certficate.
> >
> > == KrbTokenClient ==
> > Support standard JWT token, allowing to request tickets to KDC using
> > JWT token.
> >
> > == KrbPwChange ==
> > Change passwd client, interacting with KDC using the change password
> > protocol.
> >
> > == KrbAdmin ==
> > KDC admin utilities compatible with MIT kadmin tool in either local or
> > remote mode. In remote mode interacting with KDC, though no spec
> > standardizing that.
> >
> > Note there're already keytab and credential cache utilities.
> >
> > All these components will define their own options with good specific
> > descriptions; For the components that use configurations, krb5.conf is
> > default format; For the components that interacts with KDC side
> > servers, common network and message support will be used; All will
> > provide both intuitive functions and advanced function that supports
> > directly calling into the underlying layer.
> > These library APIs can be used to write tools like kinit, or embedded
> > in applications.
> >
> > It would be good to provide corresponding server side components or
> > supports, but not mandatory. Better to have at least for easier tests.
> >
> > When sounds good, we can break this down into smaller tasks and get
> > the major work done before the 1.0.0 formal release.
> >
> > Regards,
> > Kai
> >
>
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@rhelent.lan for HTTP/freeipa.rhelent@rhelent.lan,
Decrypt integrity check failed
Thanks
On Mon, Nov 23, 2015 at 3:50 PM, Marc Boorshtein
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
> wrote:
>
>> Interesting. I'll give that a try
>> On Nov 23, 2015 9:02 AM, "Zheng, Kai" 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@rhelent.lan");
>>> requestOptions.add(KrbOption.SERVER_PRINCIPAL, new
>>> PrincipalName("HTTP/freeipa.rhelent@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:mboorsht...@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 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:mboorsht...@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@rhelent.lan for
>>> > krbtgt/rhelent@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@rhelent.lan for
>>> > HTTP/freeipa.rhelent@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
>>> 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.zh...@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
>>> > >
Re: Kerby client library refactoring
Le 29/11/15 02:50, Marc Boorshtein a écrit :
> Sorry, was working on some other projects. My thought was instead of code
> that looks like this:
>
> requestOptions = new KOptions();
> requestOptions.add(KrbOption.USE_TGT, tgt);
> //requestOptions.add(KrbOption.SERVER_PRINCIPAL,
> "HTTP/freeipa.rhelent.lan");
> requestOptions.add(KrbOption.SERVER_PRINCIPAL, new
> PrincipalName("HTTP/freeipa.rhelent@rhelent.lan",NameType.NT_UNKNOWN));
> requestOptions.add(KrbOption.FORWARDABLE,true);
> requestOptions.add(KrbOption.PROXIABLE,false);
> requestOptions.add(KrbOption.RENEWABLE_OK,false);
>
> I would think this would be more OO:
>
> requestOptions = new KOptions();
> requestOptions.setTgt(tgt);
> //requestOptions.setServerPrincipal("HTTP/freeipa.rhelent.lan");
> requestOptions.setServerPrincipal(new
> PrincipalName("HTTP/freeipa.rhelent@rhelent.lan",NameType.NT_UNKNOWN));
> requestOptions.setForwardable(true);
> requestOptions.setProxiable(false);
> requestOptions.setRenewable(false);
>
> Could keep it backed by a set of options
Agreed. This is fully compatible with the definition of all the
KrbOptions enums, except thay will not be visible by the end user.
