Kiran Ayyagari <kayyagari@...> writes: > > thanks Aleksander, yes we should ignore any unknown/unsupported PA-DATA > > On Sun, Jan 15, 2012 at 5:27 AM, Aleksander Adamowski > <aleksander.adamowski@...> wrote: > > On Sat, Jan 14, 2012 at 22:42, Kiran Ayyagari <kayyagari@...> wrote: > >> you can call kdcServer.setEncryptionTypes() (with an array or set of > >> EncryptionTypeS) > >> note that, this method should be called from a non-static method > >> (typically from the setup method or the one having @Before annotation) > >> calling it from static method might likely result in a null pointer exception. > >> > >> Let me know if you have any issues > > > > I've stumbled upon what I think is incorrect behaviour on the part of > > ApacheDS's KDC. > > > > I've already consulted this with guys on MIT Kerberos dev mailing list: > > http://mailman.mit.edu/pipermail/krbdev/2012-January/010640.html > > > > It seems that, if MIT libkrb5 (trunk version) and ApacheDS (version > > 2.0.0-M1) agree on a common enctype (in my case - > > aes256-cts-hmac-sha1-96) and proceed further, ApacheDS incorrectly > > rejects an experimental preauth added by libkrb5 to AS-REQ message. > > > > What's important, this happens even using plain krb5 (without my > > experimental KrbLDAP stuff). > > Here's the relevant fragment from ApacheDS logs: > > > > [2012-01-15 00:27:16] DEBUG > > [org.apache.directory.server.kerberos.kdc.authentication.AuthenticationService] > > - Session will use encryption type aes256-cts-hmac-sha1-96 (18). > > ... > > [2012-01-15 00:27:16] DEBUG > > [org.apache.directory.server.kerberos.kdc.authentication.AuthenticationService] > > - Entry for client principal alice@... has no SAM type. > > Proceeding with sta > > ndard pre-authentication. > > [2012-01-15 00:27:16] WARN > > [org.apache.directory.server.kerberos.protocol.KerberosProtocolHandler] > > - KDC has no support for padata type (16) > > org.apache.directory.shared.kerberos.exceptions.KerberosException: KDC > > has no support for padata type > > at org.apache.directory.server.kerberos.kdc.authentication.AuthenticationService.ve rifyEncryptedTimestamp(AuthenticationService.java:291) > > at org.apache.directory.server.kerberos.kdc.authentication.AuthenticationService.ex ecute(AuthenticationService.java:118) > > at org.apache.directory.server.kerberos.protocol.KerberosProtocolHandler.messageRec eived(KerberosProtocolHandler.java:159) > > at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived (DefaultIoFilterChain.java:716) > > at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(De faultIoFilterChain.java:434) > > at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilte rChain.java:46) > > at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceive d(DefaultIoFilterChain.java:796) > > at org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush (ProtocolCodecFilter.java:427) > > at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFi lter.java:245) > > at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(De faultIoFilterChain.java:434) > > at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilte rChain.java:46) > > at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceive d(DefaultIoFilterChain.java:796) > > at org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter .java:119) > > at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(De faultIoFilterChain.java:434) > > at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(Defaul tIoFilterChain.java:426) > > at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoPr ocessor.java:715) > > at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingI oProcessor.java:668) > > at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingI oProcessor.java:657) > > at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPolli ngIoProcessor.java:68) > > at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPo llingIoProcessor.java:1141) > > at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) > > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > > at java.lang.Thread.run(Thread.java:722) > > [2012-01-15 00:27:16] DEBUG > > [org.apache.directory.server.kerberos.protocol.KerberosProtocolHandler] > > - Responding to request with error: > > explanatory text: KDC has no support for padata type > > error code: KDC has no support for padata type > > clientPrincipal: null <at> null > > client time: null > > serverPrincipal: PrincipalName : { > > name-type: KRB_NT_PRINCIPAL > > name-string : <'krbtgt', 'EXAMPLE.COM'> > > }@EXAMPLE.COM > > server time: 20120114232716Z > > > > > > According to Greg Hudson from MIT, ApacheDS KDC should just ignore the > > presence of Kerberos preauth that it doesn't support. > > > > > > -- > > Best Regards, > > Aleksander Adamowski > > http://olo.org.pl >
Just a quick note -- I built ApacheDS from SVN trunk today and noticed it still has a problem with the padata sent by recent MIT kerberos' kinit (I tested the kinit from krb5-user-1.9.1+dfsg-1ubuntu2.2 on Ubuntu 11.10). It doesn't bug me too much as I just switched to the heimdal userspace utils, which appear to work just fine with ApacheDS. I just wanted to send the heads-up in case this bites anyone else.
