【问题标题】:checksum failed: Kerberos / Spring / Active Directory (2008)校验和失败:Kerberos / Spring / Active Directory (2008)
【发布时间】:2011-12-14 17:39:34
【问题描述】:

我们无法让 Kerberos/AD 身份验证与 Spring webapp 一起使用,我认为问题与 Kerberos 票证和 Active Directory 域功能级别的加密类型有关。

基本设置是:

我有一个环境,其中 Active Directory 域功能级别是 Windows Server 2003,并且一切正常,如果客户端登录到域,客户端将按预期进行身份验证。使用 kerbtray 在这个环境中检查票证,我可以看到他们都有票证加密类型和密钥加密类型“RSADSI RC4-HMAC”。

我有一个功能级别为 Windows Server 2008 的新域,这就是身份验证不起作用的地方。尝试验证票证时返回的应用程序错误是:

Kerberos validation not successful...

Caused by: GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)
    at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Unknown Source)
    at sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source)
    at sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source)
    at sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(Unknown Source)
    at sun.security.jgss.spnego.SpNegoContext.acceptSecContext(Unknown Source)
    at sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source)
    at sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source)
    at org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator$KerberosValidateAction.run(SunJaasKerberosTicketValidator.java:146)
    at org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator$KerberosValidateAction.run(SunJaasKerberosTicketValidator.java:136)
    ... 34 more
Caused by: KrbException: Checksum failed
    at sun.security.krb5.internal.crypto.ArcFourHmacEType.decrypt(Unknown Source)
    at sun.security.krb5.internal.crypto.ArcFourHmacEType.decrypt(Unknown Source)
    at sun.security.krb5.EncryptedData.decrypt(Unknown Source)
    at sun.security.krb5.KrbApReq.authenticate(Unknown Source)
    at sun.security.krb5.KrbApReq.<init>(Unknown Source)
    at sun.security.jgss.krb5.InitSecContextToken.<init>(Unknown Source)
    ... 43 more
Caused by: java.security.GeneralSecurityException: Checksum failed
    at sun.security.krb5.internal.crypto.dk.ArcFourCrypto.decrypt(Unknown Source)
    at sun.security.krb5.internal.crypto.ArcFourHmac.decrypt(Unknown Source)

堆栈跟踪显示“ArcfourCrypto.decrypt”,因此可能将 Kerberos 票证视为 RC4-HMAC。再次使用 kerbtray 检查票证,这次在客户端上有 2 个域票证:krbtgt/.COM。两张票证的密钥加密类型为 RSADS1 RC4-HMAC,一张票证的加密类型也有此,但另一张票证的加密类型为“Kerberos AES256-CTS-HMAC-SHA1-96”。

我不确定这是否是问题的原因,但这是我在两种环境中发现的唯一可能解释身份验证异常的差异。我尝试过更改 AD 加密策略,尝试过 IE 和 Firefox,以及我能想到的几乎所有其他方法,但没有任何效果。

任何解决此问题的帮助将不胜感激。我更愿意在 java 端修复它,因为我可能无法对生产 AD 设置做出太多规定。

【问题讨论】:

  • 您检查过 Wireshark 中的通信并检查过票证吗?
  • 谢谢@Michael-O - 我之前在处理这个问题时确实使用过 Wireshark,但没有可用的输出。我根本无法让它工作 - 我恢复了测试域到 Windows Server 2003 功能级别,然后它正常工作。现在我需要设置一个新的 2008 测试域来尝试找到可行的解决方案....

标签: java active-directory kerberos spnego


【解决方案1】:

问题似乎出在密钥表中。有一些动作序列会导致一些特定的 keytab 文件状态: (A) keytab 适用于 Java,但不适用于 k5start/kinit; (B) keytab 不适用于 Java,但适用于 k5start/kinit; (C) keytab 对它们都有效。

允许检查 Java 是否可以使用 keytab 文件进行身份验证的简短 Java 代码:

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]);
  }
}

,以及要使用的属性文件:

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

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

(下面我们假设krb/kdc已经正确安装和配置,数据库是用kdb5_util创建的。每个命令序列的起始状态是:keytab文件被删除,token缓存被删除,用户“foo”被删除数据库。)


以下动作序列导致keytab状态(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
$

以下动作序列导致keytab状态(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
$

但是“k5start foo”在这种状态下是可以的,“kinit foo”也是如此。


以下动作序列导致状态(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

之后 k5start/kinit 和 java 验证都给出了肯定的结果。


环境:

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)

在 Java 7 中观察到的行为也相同。 在使用 MIT 的 kerberos 5-1.10.3 从源代码分发版编译的 Ubuntu 精确版(12.04.1 LTS)上也观察到了相同的行为。

【讨论】:

  • @Ivan - 我可以从 keytab 中检索票证。但是,对于 Java 7 代码,这突然失败,并出现 Checksum failed 错误。重新创建 keytab 是唯一的选择吗?
  • 6 年后,经过数小时的努力,您的帖子对我帮助很大。比你!
【解决方案2】:

问题在于令牌的生成方式与服务器端的验证方式。从异常跟踪中可以看出,问题是客户端没有设置校验和,而服务器端正在寻找验证校验和。校验和是令牌中设置的参数值之一,具有明显的含义。

2008 年必须有办法禁用此功能以忽略校验和检查。但是打开另一扇门,您可能需要评估剩余风险。

【讨论】:

    猜你喜欢
    • 2020-01-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2023-03-27
    相关资源
    最近更新 更多