Kerberos złamane po uaktualnieniu z java6 do Java7

Question

Mam aplikacji pracujących z wykorzystaniem rozszerzenia kerberos sprężyną bezpieczeństwa, uruchomionych na JBoss, bieganie java 6.

Jestem w procesie modernizacji mojego JVM z Java 6 do Java 7. kiedy to zrobić, używając tej samej codebase i taką samą keytab który pracował na Java 6, teraz pojawia się błąd przy użyciu języka Java 7.

konsekwentnie otrzymują: java.security.PrivilegedActionException: GSSException: Awaria nieokreślony na poziomie GSS-API (Poziom mechanizmu: Niepoprawny argument (400) - Nie można znaleźć klucza odpowiedniego typu do odszyfrowania punktu AP REP - RC4 z HMAC)

Próbowałem zregenerować keytab z różnymi opcjami/crypto, które zostały opisane na innych forach bezskutecznie.

Mam debugowany kod języka Java 7 i rzeczywiście, klasy, które zajmują się odczytywaniem tablicy kluczy przy starcie zmieniły się z 6 na 7. Czy to możliwe, że mój keytab nie jest już poprawnie odczytywany w aplikacji? Niektóre komunikaty debugowania, które widzę przy uruchomieniu przy użyciu Java6, nie pojawiają się już w wersji 7, ale nie mogę stwierdzić, czy jest to zgodne z projektem, czy też wskazuje, że coś innego jest w grze? Czy ktokolwiek inny miał problemy z aktualizacją od 6 do 7 i czy ich integracja z Kerberosami ich przerwała? Jakakolwiek rada?

Z SPNEGO i Kerberos debug zalogowaniu się na starcie, mój dziennik pokazuje:

2012-12-10 10:29:30,886 Debug is true storeKey true useTicketCache false useKeyTab true doNotPrompt true ticketCache is null isInitiator false KeyTab is jndi:/localhost/docfinity/WEB-INF/classes/config/common/security/http-docfinity.keytab refreshKrb5Config is false principal is HTTP/VMMSSDEV.TESTING.LOCAL@TESTING.LOCAL tryFirstPass is false useFirstPass is false storePass is false clearPass is false 
2012-12-10 10:30:26,322 principal is HTTP/VMMSSDEV.TESTING.LOCAL@TESTING.LOCAL 
2012-12-10 10:30:29,794 Will use keytab 
2012-12-10 10:30:29,807 Ordering keys wrt default_tkt_enctypes list 
2012-12-10 10:30:29,821 Config name: C:\Windows\krb5.ini 
2012-12-10 10:30:29,827 Using builtin default etypes for default_tkt_enctypes 
2012-12-10 10:30:29,832 default etypes for default_tkt_enctypes: 
2012-12-10 10:30:29,837 17 aes128-cts-hmac-sha1-96 
2012-12-10 10:30:29,839 16 des3-cbc-sha1-kd 
2012-12-10 10:30:29,842 23 rc4-hmac 
2012-12-10 10:30:29,846 1  des-cbc-crc 
2012-12-10 10:30:29,849 3  des-cbc-md5 
2012-12-10 10:30:29,851 . 
2012-12-10 10:30:29,855 Commit Succeeded 

jedno pytanie - zobaczysz to próbuje odczytać C: \ Windows \ krb5.ini. Nie mam takiego pliku na moim serwerze. Czy ja potrzebuję? Nie miałem też tego z Javą 6 i to zadziałało.

Aaron

Answer 1

Oto dwa potencjalne problemy, które mogąbyć wpływające na was:

1. Java 7 wydaje się zmienić kolejność domyślna typ szyfrowania. Szczegóły:

   • Java 7 Kerberos Issue - AES128 Corrupt checksum
     
     

2. Ty did't powiedzieć, jakie konkretnie wersja JDK 7, którego używasz, ale nie było błędów we wcześniejszych wersjach JDK 7, które uniemożliwiły pliki ładowanie keytab poprzez "plik:" URL:

   • http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2221392

Inny użytkownik na SO obejść ostatnim numerze modyfikując źródło wiosny:

• BadCredentialsException: Kerberos validation not succesfull

Answer 2

zmienić obiekt keyTabLocation na sznurku.

So private String keyTabLocaiton. 

     @Override 
     public void afterPropertiesSet() throws Exception { 
      Assert.notNull(this.servicePrincipal, "servicePrincipal must be specified"); 
      Assert.notNull(this.keyTabLocation, "keyTab must be specified"); 
      // if (keyTabLocation instanceof ClassPathResource) { 
      // LOG.warn("Your keytab is in the classpath. This file needs special protection and shouldn't be in the classpath. JAAS may also not be able to load this file from classpath."); 
      // } 
      LoginConfig loginConfig = new LoginConfig(this.keyTabLocation, this.servicePrincipal, 
        this.debug); 
      Set<Principal> princ = new HashSet<Principal>(1); 
      princ.add(new KerberosPrincipal(this.servicePrincipal)); 
      Subject sub = new Subject(false, princ, new HashSet<Object>(), new HashSet<Object>()); 
      LoginContext lc = new LoginContext("", sub, null, loginConfig); 
      lc.login(); 
      this.serviceSubject = lc.getSubject(); 
     } 

także gdzie facet LoginConfig ustaw flagę isInitiator true.

public AppConfigurationEntry[] getAppConfigurationEntry(String name) { 
      HashMap<String, String> options = new HashMap<String, String>(); 
      options.put("useKeyTab", "true"); 
      options.put("keyTab", this.keyTabLocation); 
      options.put("principal", this.servicePrincipalName); 
      options.put("storeKey", "true"); 
      options.put("doNotPrompt", "true"); 
      if (this.debug) { 
       options.put("debug", "true"); 
      } 
      options.put("isInitiator", "true"); 
      //options.put("isInitiator", "false"); 

      return new AppConfigurationEntry[] { new AppConfigurationEntry("com.sun.security.auth.module.Krb5LoginModule", 
        AppConfigurationEntry.LoginModuleControlFlag.REQUIRED, options), }; 
     } 

Mamy nadzieję, że pomoże to w rozwiązaniu problemu.

Answer 3

Tak! Poprawiliśmy SunJaasKerberosTicketValidator tak, aby wyglądało tak: zadziałało:

String keyTabPath = this.keyTabLocation.getURL().toExternalForm(); 
String runtimeVersion = System.getProperty("java.version"); 
if (runtimeVersion.startsWith("1.7")) 
{ 
     LOG.info("Detected jdk 7. Modifying keytabpath"); 
     if (keyTabPath != null) 
     { 
     if (keyTabPath.startsWith("file:")) 
     { 
      keyTabPath = keyTabPath.substring(5); 
     } 
     } 
} 
LOG.info("KeyTabPath: " + keyTabPath); 
LoginConfig loginConfig = new LoginConfig(keyTabPath, this.servicePrincipal, 
       this.debug);