This discussion is archived
1 2 Previous Next 28 Replies Latest reply: Sep 18, 2009 2:58 AM by 843810 Go to original post RSS
  • 15. Re: Program fails in Krb5LoginModule on Snow Leopard (Mac OS X 10.6)
    843810 Newbie
    Currently Being Moderated
    Good guess, but we don't load anything specifically. There is a routine that dumps the SecurityProviders if there's an error. Here's its output:

    16:34:52,354 INFO SystemService:101 - Security.provider.0=SUN version 1.6
    16:34:52,355 INFO SystemService:101 - Security.provider.1=Apple version 1.0
    16:34:52,355 INFO SystemService:101 - Security.provider.2=SunRsaSign version 1.5
    16:34:52,355 INFO SystemService:101 - Security.provider.3=SunJSSE version 1.6
    16:34:52,356 INFO SystemService:101 - Security.provider.4=SunJCE version 1.6
    16:34:52,356 INFO SystemService:101 - Security.provider.5=SunJGSS version 1.0
    16:34:52,356 INFO SystemService:101 - Security.provider.6=SunSASL version 1.5
    16:34:52,357 INFO SystemService:101 - Security.provider.7=XMLDSig version 1.0
    16:34:52,357 INFO SystemService:101 - Security.provider.8=SunPCSC version 1.6
    16:34:52,358 INFO SystemService:105 - Loaded provider:SunJCE version 1.6 info:SunJCE Provider (implements RSA, DES, Triple DES, AES, Blowfish, ARCFOUR, RC2, PBE, Diffie-Hellman, HMAC)

    The last line is caused by this part:
    try {
                   Cipher cipher = Cipher.getInstance("DES/CBC/NoPadding");
                   logger.info("Loaded provider:"+cipher.getProvider()+" info:"+
                             cipher.getProvider().getInfo());
              } catch (Exception e) {
                   logger.info("Error loading provider for cipher DES/CBC/NoPadding", e);
    }
    I did not write that part, but I assume that it was determined that we need a provide that supports that cipher. But that's really only after the fact, i.e. after authentication has failed.

    I checked the second salt under Leopard (Mac OS X 10.5), and there it appears to be the same as before. But if that's the root of the problem, why don't I get a stack trace with A.java?
  • 16. Re: Program fails in Krb5LoginModule on Snow Leopard (Mac OS X 10.6)
    843810 Newbie
    Currently Being Moderated
    So maybe the Apple JDK thought it's safe to wipe out sensitive info after the login finishes. So it clean salt and password.

    Have you looked at what the password is at the 2nd call?
  • 17. Re: Program fails in Krb5LoginModule on Snow Leopard (Mac OS X 10.6)
    843810 Newbie
    Currently Being Moderated
    Yes, I did. The password is still there. I wrote the exact call in A.java:

    sun.security.krb5.EncryptionKey.acquireSecretKeys("mypass".toCharArray(), "");

    (Obviously with my real password)

    I can see in Eclipse that that call causes a stack trace in the big program, but not in A.java.

    Wait! I just realised that I had modified edu.mit.Kerberos! I can now say that java on the CLI honors the settings there, whereas running from Eclipse doesn't. When I remove my edu.mit.Kerberos file, I do get the crash with A.java. I guess that's progress ;-)

    I verified that making the call above does give the same result on Leopard. So the difference between the two is that calling Credentials.acquireTGT() removes the salt.
  • 18. Re: Program fails in Krb5LoginModule on Snow Leopard (Mac OS X 10.6)
    843810 Newbie
    Currently Being Moderated
    Now by putting back edu.mit.Kerberos and tweak with the etype settings there, you'll be able to tell which one goes bad.

    Go sleep now, too late in the evening.
  • 19. Re: Program fails in Krb5LoginModule on Snow Leopard (Mac OS X 10.6)
    843810 Newbie
    Currently Being Moderated
    It's not so late here :) And so close to the finish! As you guessed earlier, it's the AES ciphers that complain. But it seems they're right to do so, at least the same stack trace appears when I run the modified A.java under Linux. The actual problem really seems to be that Credentials.acquireTGT removes the salt value. I will update by bug report with Apple with that piece of information and will mail it to java-dev@apple.com.

    Thank you very much for your help!
  • 20. Re: Program fails in Krb5LoginModule on Snow Leopard (Mac OS X 10.6)
    843810 Newbie
    Currently Being Moderated
    One more follow-up: I have found out that one of our 6 AD KDCs does work. It's the one running W2K8. The others have W2K3. In Wireshark I can see that there's one small difference in their KRB5KDC_ERR_PREAUTH-REQUIRED response: the W2K8 sends no salt for rc4-hmac, whereas Wireshark shows <MISSING> for the W2K3 rc4-hmac salt. My guess is that Apple's salt verification code in sun.security.krb5.Credentials.acquireTGT is broken. In OpenJDK there's this part:
      360                   // update salt in PrincipalName
      361                   byte[] newSalt = error.getSalt();
      362                   if (newSalt != null && newSalt.length > 0) {
      363                       princ.setSalt(new String(newSalt));
      364                   }
    If Apple messed up that test, it would explain why the empty string is used as salt ...
  • 21. Re: Program fails in Krb5LoginModule on Snow Leopard (Mac OS X 10.6)
    843810 Newbie
    Currently Being Moderated
    That's a big discovery.

    What's the difference between no salt and missing salt?

    BTW, what's the JDK version on Leopard? Not 1.6.0_15?
  • 22. Re: Program fails in Krb5LoginModule on Snow Leopard (Mac OS X 10.6)
    843810 Newbie
    Currently Being Moderated
    No salt means that the server response doesn't even a salt field for rc4-hmac at all. It looks like this:

    Encryption type: rc4-hmac (23)
    Encryption type: des-cbc-md5 (3)
    Salt: ...

    In W2K3 it looks like this:

    Encryption type: rc4-hmac (23)
    Salt: <MISSING>
    Encryption type: des-cbc-md5 (3)
    Salt: ...

    Leopard has different Java versions for different architectures. I only have access to PPC Macs running Leopard right now, and they only have 1.5.0_20.

    I have written a small test program (based on one of yours) that should help Apple engineers in finding the error:
    import java.util.HashMap;
    import java.util.Map;
    
    import javax.security.auth.Subject;
    import javax.security.auth.login.LoginException;
    
    import com.sun.security.auth.module.Krb5LoginModule;
    
    
    public class Krb5Tester {
    
         /**
          * @param args
          */
         public static void main(String[] args) throws LoginException {
              System.setProperty("java.security.krb5.realm", "AD.UNI-KOELN.DE"); // Set to the appropriate realm
              System.setProperty("java.security.krb5.kdc", "ads4.ad.uni-koeln.de"); // Set to a KDC with Windows Server 2003 for error, with Windows Server 2008 for success
              String username = new String("user"); // Must be a valid username
              String password = new String("pass"); // Must be a valid password
              
              Subject subject = new Subject();
              Krb5LoginModule krb5 = new Krb5LoginModule();
              Map<String, String> map = new HashMap<String, String>();
              Map<String, Object> shared = new HashMap<String, Object>();
              map.put("doNotPrompt", "true");
              map.put("useTicketCache", "true");
              map.put("useFirstPass", "true");
              map.put("debug", "true");
              shared.put("javax.security.auth.login.name", username);
              shared.put("javax.security.auth.login.password", password.toCharArray());
              krb5.initialize(subject, null, shared, map);
              krb5.login();
              krb5.commit();
         }
    
    }
  • 23. Re: Program fails in Krb5LoginModule on Snow Leopard (Mac OS X 10.6)
    843810 Newbie
    Currently Being Moderated
    I find this bug: http://bugs.sun.com/view_bug.do?bug_id=6388659. However, the bug was marked as fixed in the initial version of JDK 6, and it's about unsupported etype.

    I read the output of "javap -v sun.security.krb5.Credentials" on my MacBook with JDK 5:

    85: invokevirtual #77 // Method sun/security/krb5/internal/KRBError.getSalt:()[B
    88: astore 6
    90: aload 6
    92: ifnull 114
    95: aload 6
    97: arraylength
    98: ifle 114
    101: aload_0
    102: new #44 // class java/lang/String
    105: dup
    106: aload 6
    108: invokespecial #78 // Method java/lang/String."<init>":([B)V
    111: invokevirtual #79 // Method sun/security/krb5/PrincipalName.setSalt:(Ljava/lang/String;)V

    Here, in 92 and 98, two checks are made, one for null, one for <= 0, each match goes to 114, which is after the setSalt() call.

    What's on your system, it sounds like the ifle check on 98 might be missing.

    Why doesn't Apple open source its JDK also?
  • 24. Re: Program fails in Krb5LoginModule on Snow Leopard (Mac OS X 10.6)
    843810 Newbie
    Currently Being Moderated
    Cool, I didn't know that command! It's as you guessed:

    85:     invokevirtual     #81; //Method sun/security/krb5/internal/KRBError.getSalt:()[B
    88:     ifnull     107
    91:     aload_0
    92:     new     #51; //class java/lang/String
    95:     dup
    96:     aload     5
    98:     invokevirtual     #81; //Method sun/security/krb5/internal/KRBError.getSalt:()[B
    101:     invokespecial     #82; //Method java/lang/String."<init>":([B)V
    104:     invokevirtual     #83; //Method sun/security/krb5/PrincipalName.setSalt:(Ljava/lang/String;)V
    107:     aload_2
    108:     ifnull     131
    111:     aload_2
    112:     aload_0
    113:     invokevirtual     #84; //Method sun/security/krb5/PrincipalName.getSalt:()Ljava/lang/String;

    There's no ifle! BTW, I just got access to an Intel-Mac with Leopard and found that the problem also exists under Leopard if you enable Java 6. Per default Java 5 is prefered. That's why it never caused problems up to now. The version there is 1.6.0_13.

    As to why Apple doesn't open-source it: I don't know ...
  • 25. Re: Program fails in Krb5LoginModule on Snow Leopard (Mac OS X 10.6)
    843810 Newbie
    Currently Being Moderated
    I guess we can close this thread. Everything is clear.

    Happy hacking!
  • 26. Re: Program fails in Krb5LoginModule on Snow Leopard (Mac OS X 10.6)
    843810 Newbie
    Currently Being Moderated
    This is all new to me, so sorry if this is a silly question.

    If I know I want to force the login to use a particular encryption type, is there an easy way to do something like this?

    map.put("default_tkt_enctypes", "rc4-hmac");
    map.put("default_tgs_enctypes", "rc4-hmac");
    map.put("supported_encytypes", "rc4-hmac");

    krb5.initialize(subject, null, shared, map);
    krb5.login();

    I'm trying to authenticate against a Windows 2008 AD server, and the only way I can get it to work is to select the "Use DES" checkbox for the users on the AD server. If that is not checked, I get the "KDC has no support for encryption type (14)" error.

    TIA,
    John
  • 27. Re: Program fails in Krb5LoginModule on Snow Leopard (Mac OS X 10.6)
    843810 Newbie
    Currently Being Moderated
    The problem is that the Sun Kerberos login module is attempting to use AES encryption but your domain controller will not support it unless it is running at the "windows server 2008 forest functional level".

    As far as I know, there is no way to control the offered encryption type except by configuring a krb5.ini file on the client.
  • 28. Re: Program fails in Krb5LoginModule on Snow Leopard (Mac OS X 10.6)
    843810 Newbie
    Currently Being Moderated
    Thanks for the response Joe. If the Sun Kerberos login module is attempting to use AES, then why does it work when I select to use DES on the server? Is it that 2008 AD is 'trying' to use AES and without being in "windows server 2008 forest functional level" it is just not compatible in some way? The 2008 AD server is running in mixed mode currently, but I think the client is planning on raising this to 2008 native mode when they eliminate their 2003 AD server in a few weeks. Will that be sufficient, or does the forest functional level have to be raised as well?

    Thanks again for your help!
    John
1 2 Previous Next