Ok with the current code I've made some progress - I can now successfully get a TGT from Kerby. However, I'm running into a puzzling issue when trying to get a service key. Essentially, the clientPrincipal in KdcRequest.checkClient() is an empty String (and has a "null" NameType). This means that it just tries to retrieve the client Principal using @realm, and this fails.
On the first TGT pass, the client + server principals in checkClient look like: Client PRINC: [email protected] Client PRINC type: NT_PRINCIPAL Server PRINC: krbtgt/[email protected] Server PRINC type: NT_SRV_INST On the second call: Client PRINC: @service.ws.apache.org Client PRINC type: NT_UNKNOWN Server PRINC: bob/[email protected] Server PRINC type: NT_UNKNOWN The SName looks find. But the CName is missing. I know this code works fine with the KDC in Apache Directory, so we must be doing something odd with the parsing in Kerby. Colm. On Tue, Apr 21, 2015 at 2:07 PM, Zheng, Kai <[email protected]> wrote: > Hi Colm, > > > > I thought it’s good to have the following fix for now, as it processes the > enctypes list from client from first to end. I just fired a follow-on issue > to double check this. > > https://issues.apache.org/jira/browse/DIRKRB-236 > > > > + for (EncryptionType encType : request.getReqBody().getEtypes()) { > + if (clientEntry.getKeys().containsKey(encType)) { > + EncryptionKey clientKey = > clientEntry.getKeys().get(encType); > + setClientKey(clientKey); > + break; > + } > + } > > > > Regards, > > Kai > > > > *From:* Colm O hEigeartaigh [mailto:[email protected]] > *Sent:* Tuesday, April 21, 2015 8:53 PM > > *To:* Apache Directory Developers List > *Subject:* Re: Kerby GSS tests? > > > > Hi Kiran, > > > The enctypes should always be sorted from the most to least > strong/preferred on the server side > > Is there any existing code in Apache Directory along these lines? > > Colm. > > > > On Tue, Apr 21, 2015 at 12:52 PM, Kiran Ayyagari <[email protected]> > wrote: > > > > > > On Tue, Apr 21, 2015 at 7:47 PM, Zheng, Kai <[email protected]> wrote: > > Hi Colm, > > > > Yes it’s a great fix! May be we could also update our related kdc test to > repeat the issue and guard the fix? In our existing tests, the enctypes > used in KrbClient are the same with the ones in KdcServer side, so we don’t > find the issue until now. Yes, client may very likely request different > enctypes that the KdcServer doesn’t support/enable yet. > > > > yes, clients can send different enctypes depending the platform they are > running on. > > > The enctypes should always be sorted from the most to least > strong/preferred on the server side > > and then pick the best from the ones requested by the client. > > Thanks again. > > > > Regards, > > Kai > > > > *From:* Colm O hEigeartaigh [mailto:[email protected]] > *Sent:* Tuesday, April 21, 2015 7:33 PM > > > *To:* Apache Directory Developers List > *Subject:* Re: Kerby GSS tests? > > > > Hi Kai, > > I've found another bug. We are just picking the first desired encryption > type in KdcRequest.checkClient(). However, we may not actually have this > key. This leads to an NPE. Example: > > We are requesting: > > aes256-cts-hmac-sha1-96 18 > aes128-cts-hmac-sha1-96 17 > des3-cbc-sha1 16 > arcfour-hmac 23 > des-cbc-crc 1 > des-cbc-md5 3 > > We pick the first one...however we only have the following keys stored: > > des3-cbc-sha1 16 > aes128-cts-hmac-sha1-96 17 > > What do you think of this patch? > > diff --git > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb > index 2165e17..e6bcef0 100644 > --- > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server > +++ > b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server > @@ -239,9 +239,13 @@ public abstract class KdcRequest { > KrbIdentity clientEntry = getEntry(clientPrincipal.getName()); > setClientEntry(clientEntry); > > - EncryptionType encType = > request.getReqBody().getEtypes().listIterator( > - EncryptionKey clientKey = clientEntry.getKeys().get(encType); > - setClientKey(clientKey); > + for (EncryptionType encType : request.getReqBody().getEtypes()) { > + if (clientEntry.getKeys().containsKey(encType)) { > + EncryptionKey clientKey = > clientEntry.getKeys().get(encType); > + setClientKey(clientKey); > + break; > + } > + } > } > > protected void preauth() throws KrbException { > > Colm. > > > > > > On Tue, Apr 21, 2015 at 12:18 PM, Colm O hEigeartaigh <[email protected]> > wrote: > > > > Yep I will do! > > Colm. > > > > On Tue, Apr 21, 2015 at 12:16 PM, Zheng, Kai <[email protected]> wrote: > > Yes, it looks like a good fix, 0 is there instead of null, for time fields > in kdc request. Would you double check other time values by the way? Thanks! > > > > Regards, > > Kai > > > > *From:* Colm O hEigeartaigh [mailto:[email protected]] > *Sent:* Tuesday, April 21, 2015 7:11 PM > > > *To:* Apache Directory Developers List > *Subject:* Re: Kerby GSS tests? > > > > > > The problem above is that the "end time" is 0 instead of "null". What do > you think of this patch? > > diff --git > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb > index 3d49af3..23275fc 100644 > --- > a/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server > +++ > b/kerby-kerb/kerb-server/src/main/java/org/apache/kerby/kerberos/kerb/server > @@ -370,7 +370,7 @@ public abstract class KdcRequest { > } > > KerberosTime krbEndTime = request.getReqBody().getTill(); > - if (krbEndTime == null) { > + if (krbEndTime == null || krbEndTime.getTime() == 0) { > krbEndTime = > krbStartTime.extend(config.getMaximumTicketLifetime() > } else if (krbStartTime.greaterThan(krbEndTime)) { > throw new KrbException(KrbErrorCode.KDC_ERR_NEVER_VALID); > > Colm. > > > > On Tue, Apr 21, 2015 at 12:00 PM, Colm O hEigeartaigh <[email protected]> > wrote: > > Hi Kai, > > 2. Please disable preauth in KDC side or require preauth in client > side. Looks like client didn’t send preauth data but KDC required it. > > > > Ok I got a bit further by doing this. However, from what I can find out, > the GSS client code should be sending the Pre authentication data (and > there appears to be no option to disable it). So I think there may be a bug > in how Kerby is processing the header? Should we log a JIRA to track this? > > The error I now get (when disabling pre auth in Kerby) is: > > org.apache.kerby.kerberos.kerb.KrbException: Requested start time is later > than end time > at > org.apache.kerby.kerberos.kerb.server.request.KdcRequest.issueTicket(KdcRequest.java:376) > at > org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:96) > at > org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77) > at > org.apache.kerby.kerberos.kdc.impl.NettyKdcHandler.channelRead(NettyKdcHandler.java:51) > > Any ideas? The Kerby server + CXF client are both on the same machine... > > Colm. > > > > > > If you don’t want to trouble with the config stuff, please just change the > default value of PREAUTH_REQUIRED in krb/kdc config key enumeration. > > > > Regards, > > Kai > > > > *From:* Colm O hEigeartaigh [mailto:[email protected]] > *Sent:* Tuesday, April 21, 2015 6:34 PM > *To:* Apache Directory Developers List > *Subject:* Re: Kerby GSS tests? > > > > Actually I spoke too soon, I do know how to reproduce the > "pre-authentication" error. Simply uncomment the line > "kerbyServer.setInnerKdcImpl(new NettyKdcServerImpl());" in the test. If I > put a printStackTrace in the NettyKdcServerImpl, I see: > > Error occured while processing request:Generic error (description in > e-text) > SocketTimeOutException with attempt: 2 > >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =3, > #bytes=169 > Apr 21, 2015 11:33:05 AM io.netty.util.internal.logging.Slf4JLogger info > INFO: [id: 0xea7673e9, /0:0:0:0:0:0:0:0:9002] RECEIVED: [id: 0xbfe95a70, / > 127.0.0.1:43973 => /127.0.0.1:9002] > org.apache.kerby.kerberos.kerb.KrbErrorException: Generic error > (description in e-text) > at > org.apache.kerby.kerberos.kerb.server.request.KdcRequest.preauth(KdcRequest.java:255) > at > org.apache.kerby.kerberos.kerb.server.request.KdcRequest.process(KdcRequest.java:94) > at > org.apache.kerby.kerberos.kerb.server.KdcHandler.handleMessage(KdcHandler.java:77) > > Colm. > > > > On Tue, Apr 21, 2015 at 11:29 AM, Colm O hEigeartaigh <[email protected]> > wrote: > > Hi Kai, > > Thanks for your response. I have a test-case of sorts that shows the > interop failure (although I can't reproduce the issue I reported yesterday > about the preauthentication data). > > > https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-kerberos-kerby > > Run it with "mvn clean install". You may need the install the parent > module as well before running this, which is one level up. > > The test sets up a Kerby server, and I have a @Ignore'd test using Kerby > client API to successfully communicate with it. Then I have a Apache > CXF-based test which uses the Kerberos functionality here (based on GSS) to > get a service ticket. If I put printStackTrace in the DefaultKdcHandler the > output looks like: > > Loaded from Java config > >>> KdcAccessibility: reset > >>> KdcAccessibility: reset > Using builtin default etypes for default_tkt_enctypes > default etypes for default_tkt_enctypes: 18 17 16 23 1 3. > >>> KrbAsReq creating message > >>> KrbKdcReq send: kdc=127.0.0.1 TCP:9002, timeout=30000, number of > retries =3, #bytes=169 > >>> KDCCommunication: kdc=127.0.0.1 TCP:9002, timeout=30000,Attempt =1, > #bytes=169 > java.net.SocketTimeoutException: Read timed out > at java.net.SocketInputStream.socketRead0(Native Method) > at java.net.SocketInputStream.read(SocketInputStream.java:152) > at java.net.SocketInputStream.read(SocketInputStream.java:122) > at java.net.SocketInputStream.read(SocketInputStream.java:210) > at java.io.DataInputStream.readInt(DataInputStream.java:387) > at > org.apache.kerby.kerberos.kerb.transport.KrbTcpTransport.receiveMessage(KrbTcpTransport.java:54) > at > org.apache.kerby.kerberos.kerb.server.impl.DefaultKdcHandler.run(DefaultKdcHandler.java:46) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > >>>DEBUG: TCPClient could not read length field > >>> KrbKdcReq send: #bytes read=0 > > Any ideas? > > Colm. > > > > On Tue, Apr 21, 2015 at 12:09 AM, Zheng, Kai <[email protected]> wrote: > > Hi Colm, > > > > We haven’t any test for GSS client against Kerby yet, though we do have > tests in protocol level for ApReq (in kerb-core-test module). We might look > at existing ApacheDS Kerberos codes to see if any such end to end tests to > port. > > > > You’re right, current UDP support for KdcNetwork and NettyKdcNetwork are > to be done yet. I originally got them done some days ago, but recently I > was extremely busy with other projects, so kinds of delayed. Sure JIRAs > would be good to record them. > > > > For the issue you ran into, do you have test codes to repeat it, so we may > have the chance to look at it? Thanks. > > > > Regards, > > Kai > > > > *From:* Colm O hEigeartaigh [mailto:[email protected]] > *Sent:* Monday, April 20, 2015 10:40 PM > *To:* Apache Directory Developers List > *Subject:* Kerby GSS tests? > > > > Hi all, > > > > Are there any tests in the source (or has anyone successfully tested) a > Java GSS client -> Apache Kerby? > > The first issue I ran into was that neither the KdcNetwork nor the > NettyKdcNetwork work with UDP. Is there a JIRA for this (or any plans to > fix it)? > > I could work around the above by setting "udp_preference_limit = 1". > However, I then run into an issue where it fails due to no > pre-authentication data in the request. Are we sure that this parsing is > working correctly? > > Colm. > > > > -- > > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com > > > > > -- > > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com > > > > > -- > > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com > > > > > -- > > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com > > > > > -- > > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com > > > > > -- > > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com > > > > > -- > > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com > > > > > -- > > Kiran Ayyagari > http://keydap.com > > > > > > -- > > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
