We are having trouble getting Kerberos/AD authentication to work with a Spring webapp, and I believe the problem has to do with encryption types for the Kerberos tickets and the Active Directory domain functional level.
我们很难让Kerberos/AD身份验证与Spring webapp一起工作，我认为这个问题与Kerberos tickets的加密类型和Active Directory域功能级别有关。
The basic setup is:
基本设置:
- Tomcat 7
- Tomcat 7
- Java 1.6 (29)
- Java 1.6(29)
- Windows Server 2008 R2
- Windows Server 2008 R2
- Spring 3.0
- Spring 3.0
- Spring Security Kerberos/Spnego extension M2 detailed here: http://blog.springsource.com/2009/09/28/spring-security-kerberos/
- 这里详细介绍了Spring Security Kerberos/Spnego扩展M2: http://blog.springsource.com/2009/09/28/spring-securityos/。
I have one environment where the Active Directory domain functional level is Windows Server 2003 and everything works fine, with clients authenticating as expected if they are logged on to the domain. Using kerbtray to examine the tickets in this environment I can see that they all have both ticket encryption type and key encryption type "RSADSI RC4-HMAC".
我有一个环境，其中Active Directory域的功能级别是Windows Server 2003，一切都很好，如果客户机登录到域，那么它们将按照预期进行身份验证。使用kerbtray在这个环境中检查机票，我可以看到他们都有机票加密类型和密钥加密类型“RSADSI RC4-HMAC”。
I have a new domain with functional level Windows Server 2008, and this is where the authentication does not work. The application error returned when attempting to validate the ticket is:
我有一个功能级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)
The stack trace shows "ArcfourCrypto.decrypt" so presumably is treating the Kerberos ticket as RC4-HMAC. Using kerbtray again to examine the tickets this time there are 2 tickets on the client for the domain: krbtgt/.COM. Both of tickets have key encryption type RSADS1 RC4-HMAC, one also has this for ticket encryption type, but the other has "Kerberos AES256-CTS-HMAC-SHA1-96".
堆栈跟踪显示“arcfourpassword .decrypt”，所以可能是将Kerberos凭证作为RC4-HMAC处理。再次使用kerbtray检查机票，这一次有两张客户的票:krbtgt/。com。这两张票都有密钥加密类型RSADS1 RC4-HMAC，还有一个用于票证加密类型，但另一个有“Kerberos AES256-CTS-HMAC-SHA1-96”。
I don't know for sure that this is the cause of the problem, but it is the only difference I've been able to find in the two environments that might explain the authentication exception. I've tried changing the AD encryption policy, tried IE and Firefox, and pretty much everything else I could think of, but nothing has worked.
我不确定这是否是问题的原因，但这是我能够在两个环境中找到的唯一的区别，这可能解释身份验证异常。我尝试过改变广告加密策略，尝试IE和Firefox，以及几乎所有我能想到的东西，但都没有成功。
Any help addressing this would be much appreciated. I'd prefer to fix it on the java end as I probably can't dictate too much about the production AD setup.
任何有助于解决这一问题的办法都将受到重视。我更倾向于在java端解决它，因为我可能不能过多地说明生产广告的设置。
2 个解决方案
#1
17
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.
问题似乎在关键环节。有一些操作序列导致一些特定的keytab文件状态:(A) keytab与Java一起工作，但不与k5start/kinit一起工作;(B) keytab不使用Java，但使用k5start/kinit;(C) keytab与它们一起工作。
The short Java code that allows to check if Java can authenticate using the keytab file:
允许检查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]);
}
}
, 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.)
(下面我们假设krb/kdc被正确安装和配置，数据库是用kdb5_util创建的。每个命令序列的起始状态是:keytab文件被删除，令牌缓存被删除，用户“foo”被从数据库中删除。
The following action sequence leads to the keytab state (A):
下面的操作序列导致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
$
The following action sequence leads to the keytab state (B):
下面的操作序列导致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
$
But the "k5start foo" is okay in this state, as well as "kinit foo".
但是“k5start foo”在这个状态下是可以的，以及“kinit foo”。
And the following action sequence leads to state (C):
下面的动作序列导致状态(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.
在这之后，k5start/kinit和java验证都给出了积极的结果。
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.
与Java 7相同的行为。同样的行为也在Ubuntu的精确(12.04.1 LTS)上被观察到，而MIT的kerberos 5-1.10.3是从源代码发行版编译的。
#2
0
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.
必须有一种方法在2008年禁用此功能，以忽略校验和检查。但打开另一扇门，你可能需要评估剩余风险。
#1
17
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.
问题似乎在关键环节。有一些操作序列导致一些特定的keytab文件状态:(A) keytab与Java一起工作，但不与k5start/kinit一起工作;(B) keytab不使用Java，但使用k5start/kinit;(C) keytab与它们一起工作。
The short Java code that allows to check if Java can authenticate using the keytab file:
允许检查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]);
}
}
, 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.)
(下面我们假设krb/kdc被正确安装和配置，数据库是用kdb5_util创建的。每个命令序列的起始状态是:keytab文件被删除，令牌缓存被删除，用户“foo”被从数据库中删除。
The following action sequence leads to the keytab state (A):
下面的操作序列导致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
$
The following action sequence leads to the keytab state (B):
下面的操作序列导致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
$
But the "k5start foo" is okay in this state, as well as "kinit foo".
但是“k5start foo”在这个状态下是可以的，以及“kinit foo”。
And the following action sequence leads to state (C):
下面的动作序列导致状态(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.
在这之后，k5start/kinit和java验证都给出了积极的结果。
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.
与Java 7相同的行为。同样的行为也在Ubuntu的精确(12.04.1 LTS)上被观察到，而MIT的kerberos 5-1.10.3是从源代码发行版编译的。
#2
0
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.
必须有一种方法在2008年禁用此功能，以忽略校验和检查。但打开另一扇门，你可能需要评估剩余风险。