1. 技术文章
  2. checksum failed: Kerberos / Spring / Active Directory (2008)

checksum failed: Kerberos / Spring / Active Directory (2008)

由 两盒软妹~` 提交于 2019-11-28 07:46:11

The problem seems to be in the keytab. There are some action sequences leading to some specific keytab file states: (A) keytab works with Java but does not work with k5start/kinit; (B) keytab does not work with Java, but works with k5start/kinit; (C) keytab works with both them.

The short Java code that allows to check if Java can authenticate using the keytab file: 

import java.io.File;
import java.io.FileInputStream;
import java.io.InputStream;
import java.util.HashMap;
import java.util.Map;
import java.util.Properties;

import javax.security.auth.Subject;

import com.sun.security.auth.module.Krb5LoginModule;

/**
 * This is simple Java program that tests ability to authenticate 
 * with Kerberos using the JDK implementation.
 * 
 * The program uses no libraries but JDK itself.
 */
public class Krb {

  private void loginImpl(final String propertiesFileName) throws Exception {
    System.out.println("NB: system property to specify the krb5 config: [java.security.krb5.conf]");
    //System.setProperty("java.security.krb5.conf", "/etc/krb5.conf");

    System.out.println(System.getProperty("java.version"));

    System.setProperty("sun.security.krb5.debug", "true");

    final Subject subject = new Subject();

    final Krb5LoginModule krb5LoginModule = new Krb5LoginModule();
    final Map<String,String> optionMap = new HashMap<String,String>();

    if (propertiesFileName == null) {
      //optionMap.put("ticketCache", "/tmp/krb5cc_1000");
      optionMap.put("keyTab", "/etc/krb5.keytab");
      optionMap.put("principal", "foo"); // default realm

      optionMap.put("doNotPrompt", "true");
      optionMap.put("refreshKrb5Config", "true");
      optionMap.put("useTicketCache", "true");
      optionMap.put("renewTGT", "true");
      optionMap.put("useKeyTab", "true");
      optionMap.put("storeKey", "true");
      optionMap.put("isInitiator", "true");
    } else {
      File f = new File(propertiesFileName);
      System.out.println("======= loading property file ["+f.getAbsolutePath()+"]");
      Properties p = new Properties();
      InputStream is = new FileInputStream(f);
      try {
        p.load(is);
      } finally {
        is.close();
      }
      optionMap.putAll((Map)p);
    }
    optionMap.put("debug", "true"); // switch on debug of the Java implementation

    krb5LoginModule.initialize(subject, null, new HashMap<String,String>(), optionMap);

    boolean loginOk = krb5LoginModule.login();
    System.out.println("======= login:  " + loginOk);

    boolean commitOk = krb5LoginModule.commit();
    System.out.println("======= commit: " + commitOk);

    System.out.println("======= Subject: " + subject);
  }

  public static void main(String[] args) throws Exception {
    System.out.println("A property file with the login context can be specified as the 1st and the only paramater.");
    final Krb krb = new Krb();
    krb.loginImpl(args.length == 0 ? null : args[0]);
  }
}

, and the property file to use: 

#ticketCache=/tmp/krb5cc_1000
keyTab=/etc/krb5.keytab
principal=foo

doNotPrompt=true
refreshKrb5Config=true
useTicketCache=true
renewTGT=true
useKeyTab=true
storeKey=true
isInitiator=true

(Below we assume that krb/kdc is correctly installed and configured, the database is created with kdb5_util. The starting state of each command sequence is: the keytab file deleted, token cache is deleted, user "foo" is deleted from the database.)

The following action sequence leads to the keytab state (A):

$ echo -e "foo\nfoo" | kadmin.local -q "addprinc foo"
$ echo -e "foo\nfoo" | kadmin.local -q "ktadd foo"
$ java -cp . Krb ./krb5.properties 
# Now java auth okay, but the following command fails:
$ k5start foo
Kerberos initialization for foo@EXAMPLE.COM
Password for foo@EXAMPLE.COM: 
k5start: error getting credentials: Decrypt integrity check failed
$

The following action sequence leads to the keytab state (B):

$ echo -e "foo\nfoo" | kadmin.local -q "addprinc foo"
$ echo -e "foo\nfoo" | kadmin.local -q "ktadd foo"
$ echo -e "foo\nfoo" | kadmin.local -q "cpw foo"
$ java -cp . Krb ./krb5.properties 
A property file with the login context can be specified as the 1st and the only paramater.
NB: system property to specify the krb5 config: [java.security.krb5.conf]
1.6.0_33
======= loading property file [/tmp/krb-test/yhadoop-common/./krb5.properties]
Debug is  true storeKey true useTicketCache true useKeyTab true doNotPrompt true ticketCache is null isInitiator true KeyTab is /etc/krb5.keytab refreshKrb5Config is true principal is foo tryFirstPass is false useFirstPass is false storePass is false clearPass is false
Refreshing Kerberos configuration
Config name: /etc/krb5.conf
>>> KdcAccessibility: reset
>>> KdcAccessibility: reset
Acquire TGT from Cache
>>>KinitOptions cache name is /tmp/krb5cc_0
Principal is foo@EXAMPLE.COM
null credentials from Ticket Cache
>>> KeyTabInputStream, readName(): EXAMPLE.COM
>>> KeyTabInputStream, readName(): foo
>>> KeyTab: load() entry length: 49; type: 23
Added key: 23version: 3
Ordering keys wrt default_tkt_enctypes list
default etypes for default_tkt_enctypes: 23.
0: EncryptionKey: keyType=23 kvno=3 keyValue (hex dump)=
0000: 5F 7F 9B 42 BB 02 51 81   32 05 1D 7B C0 9F 19 C0  _..B..Q.2.......


principal's key obtained from the keytab
Acquire TGT using AS Exchange
default etypes for default_tkt_enctypes: 23.
>>> KrbAsReq calling createMessage
>>> KrbAsReq in createMessage
>>> KrbKdcReq send: kdc=localhost UDP:88, timeout=30000, number of retries =3, #bytes=128
>>> KDCCommunication: kdc=localhost UDP:88, timeout=30000,Attempt =1, #bytes=128
>>> KrbKdcReq send: #bytes read=611
>>> KrbKdcReq send: #bytes read=611
>>> KdcAccessibility: remove localhost:88
>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
Checksum failed !
                [Krb5LoginModule] authentication failed 
Checksum failed
Exception in thread "main" javax.security.auth.login.LoginException: Checksum failed
        at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:696)
        at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:542)
        at Krb.loginImpl(Krb.java:65)
        at Krb.main(Krb.java:77)
Caused by: KrbException: Checksum failed
        at sun.security.krb5.internal.crypto.ArcFourHmacEType.decrypt(ArcFourHmacEType.java:85)
        at sun.security.krb5.internal.crypto.ArcFourHmacEType.decrypt(ArcFourHmacEType.java:77)
        at sun.security.krb5.EncryptedData.decrypt(EncryptedData.java:168)
        at sun.security.krb5.KrbAsRep.<init>(KrbAsRep.java:87)
        at sun.security.krb5.KrbAsReq.getReply(KrbAsReq.java:446)
        at sun.security.krb5.Credentials.sendASRequest(Credentials.java:401)
        at sun.security.krb5.Credentials.acquireTGT(Credentials.java:350)
        at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:672)
        ... 3 more
Caused by: java.security.GeneralSecurityException: Checksum failed
        at sun.security.krb5.internal.crypto.dk.ArcFourCrypto.decrypt(ArcFourCrypto.java:388)
        at sun.security.krb5.internal.crypto.ArcFourHmac.decrypt(ArcFourHmac.java:74)
        at sun.security.krb5.internal.crypto.ArcFourHmacEType.decrypt(ArcFourHmacEType.java:83)
        ... 10 more
$

But the "k5start foo" is okay in this state, as well as "kinit foo".

And the following action sequence leads to state (C):

$ echo -e "foo\nfoo" | kadmin.local -q "addprinc foo"
$ ktutil 
ktutil:  addent -password -p foo -k 1 -e rc4-hmac
Password for foo@EXAMPLE.COM: 
ktutil:  wkt /etc/krb5.keytab
ktutil:  q

after that both k5start/kinit and the java verification give positive result.

Environment:

yum list krb5-appl-servers krb5-libs krb5-server krb5-workstation kstart pam_krb5 
...
Installed Packages
krb5-libs.x86_64                                                                            1.9-33.el6_3.3                                                                      @updates
krb5-server.x86_64                                                                          1.9-33.el6_3.3                                                                      @updates
krb5-workstation.x86_64                                                                     1.9-33.el6_3.3                                                                      @updates
kstart.x86_64                                                                               4.1-2.el6                                                                           @epel   
...
$ cat /etc/redhat-release 
CentOS release 6.3 (Final)
$ java -version
java version "1.6.0_33"
Java(TM) SE Runtime Environment (build 1.6.0_33-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode)

Also the same behavior observed with Java 7. Also the same behavior was observed on Ubuntu precise (12.04.1 LTS) with MIT's kerberos 5-1.10.3 compiled from the source distribution.

The problem is with how token is generated vs how it is validated on server side. From the exception trace, it shows the issue is, client side is not setting checksum and server side is looking to validate the checksum. Checksum is one of the params value set in the token which has it obvious meaning.

There must be a way in 2008 to disable this feature to ignore checksum check. But opens another door and you may need to evaluate residual risk.

标签
java
active-directory
kerberos
spnego
易学教程内所有资源均来自网络或用户发布的内容，如有违反法律规定的内容欢迎反馈！
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!