2012-03-02 32 views
5

Przeprowadzam migrację z Java 6 do Java 7 i pojawia się problem z uwierzytelnianiem Kerberos. Wygląda mi na to, że podstawowa kolejność szyfrowania jest przełączana iw rezultacie używany jest inny typ szyfrowania. W tym przypadku część Aes128CtsHmacSha1EType jest używana podczas wykonywania Java 7. ArcFourHmacEType jest używany, gdy uruchomiona jest Java 6 i dla drugiej części uruchomienia Java 7.Problem 7 Java Kerberos - AES128 Sporna suma kontrolna

Inne informacje: uruchamianie w systemie Linux (Fedora 16) na serwerze Windows Active Directory.

Wiem, że mogę uzyskać uwierzytelnienie do pracy, jeśli ustawię parametry default_tkt_enctypes, default_tgs_enctypes, allowed_enctypes w pliku krb5.conf; jednak chciałbym, aby działał bez pliku, a najlepiej bez zmuszania jednego lub dwóch typów.

Oto komunikat błędu otrzymuję:

java.security.PrivilegedActionException: javax.naming.AuthenticationException: GSSAPI [Root exception is javax.security.sasl.SaslException: Final handshake failed [Caused by GSSException: Token had invalid integrity check (Mechanism level: Corrupt checksum in Wrap token)]] 
at java.security.AccessController.doPrivileged(Native Method) 
at javax.security.auth.Subject.doAs(Subject.java:415) 
at *internal.code*.LDAPAuthenticator.authenticate(LDAPAuthenticator.java:46) 
at *internal.code*.LDAPAuthenticatorTest.testUpdateUser(LDAPAuthenticatorTest.java:30) 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
at java.lang.reflect.Method.invoke(Method.java:601) 
at junit.framework.TestCase.runTest(TestCase.java:154) 
at junit.framework.TestCase.runBare(TestCase.java:127) 
at junit.framework.TestResult$1.protect(TestResult.java:106) 
at junit.framework.TestResult.runProtected(TestResult.java:124) 
at junit.framework.TestResult.run(TestResult.java:109) 
at junit.framework.TestCase.run(TestCase.java:118) 
at junit.framework.TestSuite.runTest(TestSuite.java:208) 
at junit.framework.TestSuite.run(TestSuite.java:203) 
at junit.textui.TestRunner.doRun(TestRunner.java:116) 
at com.intellij.junit3.JUnit3IdeaTestRunner.doRun(JUnit3IdeaTestRunner.java:139) 
at junit.textui.TestRunner.doRun(TestRunner.java:109) 
at com.intellij.junit3.JUnit3IdeaTestRunner.startRunnerWithArgs(JUnit3IdeaTestRunner.java:52) 
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:182) 
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:62) 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
at java.lang.reflect.Method.invoke(Method.java:601) 
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) 
Caused by: javax.naming.AuthenticationException: GSSAPI [Root exception is javax.security.sasl.SaslException: Final handshake failed [Caused by GSSException: Token had invalid integrity check (Mechanism level: Corrupt checksum in Wrap token)]] 
at com.sun.jndi.ldap.sasl.LdapSasl.saslBind(LdapSasl.java:168) 
at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:232) 
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2740) 
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) 
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) 
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) 
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) 
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) 
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) 
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) 
at javax.naming.InitialContext.init(InitialContext.java:242) 
at javax.naming.InitialContext.<init>(InitialContext.java:216) 
at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101) 
at *internal.code*.LDAPAuthenticator.getAttributeFor(LDAPAuthenticator.java:156) 
at *internal.code*.user.LDAPAuthenticator.access$000(LDAPAuthenticator.java:27) 
at *internal.code*.user.LDAPAuthenticator$1.run(LDAPAuthenticator.java:49) 
... 27 more 
Caused by: javax.security.sasl.SaslException: Final handshake failed [Caused by GSSException: Token had invalid integrity check (Mechanism level: Corrupt checksum in Wrap token)] 
at com.sun.security.sasl.gsskerb.GssKrb5Client.doFinalHandshake(GssKrb5Client.java:328) 
at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:187) 
at com.sun.jndi.ldap.sasl.LdapSasl.saslBind(LdapSasl.java:132) 
... 42 more 
Caused by: GSSException: Token had invalid integrity check (Mechanism level: Corrupt checksum in Wrap token) 
at sun.security.jgss.krb5.WrapToken_v2.getData(WrapToken_v2.java:151) 
at sun.security.jgss.krb5.WrapToken_v2.getData(WrapToken_v2.java:105) 
at sun.security.jgss.krb5.Krb5Context.unwrap(Krb5Context.java:983) 
at sun.security.jgss.GSSContextImpl.unwrap(GSSContextImpl.java:403) 
at com.sun.security.sasl.gsskerb.GssKrb5Client.doFinalHandshake(GssKrb5Client.java:234) 
... 44 more 

Czy jest możliwe aby użyć AES128 z tej konfiguracji?

Jeśli nie mogę uruchomić AES128, czy istnieje sposób ustawienia domyślnych enkryptów za pomocą parametru systemowego (zamiast użycia krb5.conf)?

+1

Czy zainstalowano JAR z nieograniczoną ochroną? –

+0

Nie myśl, że powinieneś potrzebować tego dla 128-bitowej AES, tylko dla 256-bitowej AES, jeśli dobrze pamiętam. – rra

+0

Java zgłasza niedozwolony wyjątek dla kluczy, gdy potrzebna jest JCE, ale nie jest zainstalowana poprawnie. –

Odpowiedz

0

Słuchaj James Cape, zainstaluj nieograniczony plik bezpieczeństwa. Ze względu na jurysdykcję w Stanach Zjednoczonych JRE nie może zostać dostarczony z tym JAR.

Powiązane problemy