On Sat, Jan 14, 2012 at 22:42, Kiran Ayyagari <[email protected]> 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 [email protected] 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.verifyEncryptedTimestamp(AuthenticationService.java:291) at org.apache.directory.server.kerberos.kdc.authentication.AuthenticationService.execute(AuthenticationService.java:118) at org.apache.directory.server.kerberos.protocol.KerberosProtocolHandler.messageReceived(KerberosProtocolHandler.java:159) at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:716) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796) at org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush(ProtocolCodecFilter.java:427) at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:245) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796) at org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:119) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434) at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:426) at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:715) at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:668) at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:657) at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:68) at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.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@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
