使用Spring Security Kerberos扩展/IE、Firefox/AD时，协商标头无效错误

Question

我们在JBoss AS 7.1.1上配置OWF7 (Ozone Widget Framework)中的Spring Security Kerberos扩展。我们看到以下错误：

23:01:44,172 WARN  [org.springframework.security.extensions.kerberos.web.SpnegoAuthenticationProcessingFilter] (http--10.200.69.103-8080-2) Negotiate Header was invalid: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==: org.springframework.security.authentication.BadCredentialsException: Kerberos validation not succesfull
    at org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator.validateTicket(SunJaasKerberosTicketValidator.java:69) [spring-security-kerberos-core-1.0.0.M2.jar:]
    at org.springframework.security.extensions.kerberos.KerberosServiceAuthenticationProvider.authenticate(KerberosServiceAuthenticationProvider.java:86) [spring-security-kerberos-core-1.0.0.M2.jar:]
    at org.springframework.security.authentication.ProviderManager.doAuthentication(ProviderManager.java:120) [spring-security-core-3.0.2.RELEASE.jar:]
    at org.springframework.security.authentication.AbstractAuthenticationManager.authenticate(AbstractAuthenticationManager.java:48) [spring-security-core-3.0.2.RELEASE.jar:]
    at org.springframework.security.extensions.kerberos.web.SpnegoAuthenticationProcessingFilter.doFilter(SpnegoAuthenticationProcessingFilter.java:131) [spring-security-kerberos-core-1.0.0.M2.jar:]
    at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355) [spring-security-web-3.0.2.RELEASE.jar:]
    at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:79) [spring-security-web-3.0.2.RELEASE.jar:]
    at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355) [spring-security-web-3.0.2.RELEASE.jar:]
    at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:149) [spring-security-web-3.0.2.RELEASE.jar:]
    at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237) [org.springframework.web-3.0.5.RELEASE.jar:3.0.5.RELEASE]
    at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167) [org.springframework.web-3.0.5.RELEASE.jar:3.0.5.RELEASE]
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.13.Final.jar:]
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.13.Final.jar:]
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.13.Final.jar:]
    at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
    at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
Caused by: java.security.PrivilegedActionException: GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
    at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.6.0_31]
    at javax.security.auth.Subject.doAs(Subject.java:396) [rt.jar:1.6.0_31]
    at org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator.validateTicket(SunJaasKerberosTicketValidator.java:67) [spring-security-kerberos-core-1.0.0.M2.jar:]
    ... 23 more
Caused by: GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
    at sun.security.jgss.GSSHeader.<init>(GSSHeader.java:80) [rt.jar:1.6.0_31]
    at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:287) [rt.jar:1.6.0_31]
    at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267) [rt.jar:1.6.0_31]
    at org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator$KerberosValidateAction.run(SunJaasKerberosTicketValidator.java:146) [spring-security-kerberos-core-1.0.0.M2.jar:]
    at org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator$KerberosValidateAction.run(SunJaasKerberosTicketValidator.java:136) [spring-security-kerberos-core-1.0.0.M2.jar:]
    ... 26 more

我在堆栈溢出("Defective token detected" error (NTLM not Kerberos) with Kerberos/Spring Security/IE/Active Directory)上看到了一篇文章，我想有人可以帮助我解决我们的问题。

我们的设置：

JDK 1.6.0_31 JBoss AS 7.1.1最终运行于Red Hat Enterprise Linux Server release 6.2 (圣地亚哥) Kernel 2.6.32-220.el6.x86_64 on a x86_64 Windows Server2008 Active Directory Spring Security Kerberos Extension M2 (按照其博客中提供的说明进行配置：http://blog.springsource.com/2009/09/28/spring-security-kerberos/ ) Firefox 21 (在VM上运行) IE 10 (在VM上运行)

从上面列出的上一篇文章中，看起来AD服务器正在向IE发送NTLM令牌，而IE正在将该令牌发送到应用程序。我们将位于不同机器上的应用服务器(JBoss)、AD服务器和客户端(IE、火狐)加入到同一个域中。下面是JBoss所在的linux机器的/etc文件夹中的krb5.conf文件：

[libdefaults]
 default_realm = ENTERPRISELABS.MYCOMPANY.COM
 default_tgs_enctypes = aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
 default_tkt_enctypes = aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
 permitted_enctypes = aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
 dns_lookup_realm = true
 dns_lookup_kdc = true
 passwd_check_s_address = false
 noaddresses = true
udp_preference_limit = 1
 ccache_type = 3
 kdc_timesync = 0
 kdc_timesync = 0
[domain_realm]
 .enterpriselabs.com = ENTERPRISELABS.MYCOMPANY.COM
 enterpriselabs.com = ENTERPRISELABS.MYCOMPANY.COM
 .cdc.lab = ENTERPRISELABS.MYCOMPANY.COM
 cdc.lab = ENTERPRISELABS.MYCOMPANY.COM
 .dcas-i-2-069103 = ENTERPRISELABS.MYCOMPANY.COM
 .enterpriselabs.mycompany.com = ENTERPRISELABS.MYCOMPANY.COM
 dcas-i-2-069103 = ENTERPRISELABS.MYCOMPANY.COM
 enterpriselabs.mycompany.com = ENTERPRISELABS.MYCOMPANY.COM
 mcc-ad01.enterpriselabs.mycompany.com = ENTERPRISELABS.MYCOMPANY.COM
 mcc-ad03.enterpriselabs.mycompany.com = ENTERPRISELABS.MYCOMPANY.COM
 scr0-i-1-069137.scr0.enterpriselabs.mycompany.com = SCR0.ENTERPRISELABS.MYCOMPANY.COM
 ssbox8.cdc.lab = ENTERPRISELABS.MYCOMPANY.COM
[realms]
ENTERPRISELABS.MYCOMPANY.COM = {
 kdc = mcc-ad01.enterpriselabs.mycompany.com:88
 master_kdc = mcc-ad01.enterpriselabs.mycompany.com:88
 kpasswd = mcc-ad01.enterpriselabs.mycompany.com:464
 kpasswd_server = mcc-ad01.enterpriselabs.mycompany.com:464
 kdc = mcc-ad03.enterpriselabs.mycompany.com:88
 master_kdc = mcc-ad03.enterpriselabs.mycompany.com:88
 kpasswd = mcc-ad03.enterpriselabs.mycompany.com:464
 kpasswd_server = mcc-ad03.enterpriselabs.mycompany.com:464
}
SCR0.ENTERPRISELABS.mycompany.COM = {
 kdc = scr0-i-1-069137.scr0.enterpriselabs.mycompany.com:88
 master_kdc = scr0-i-1-069137.scr0.enterpriselabs.mycompany.com:88
 kpasswd = scr0-i-1-069137.scr0.enterpriselabs.mycompany.com:464
 kpasswd_server = scr0-i-1-069137.scr0.enterpriselabs.mycompany.com:464
}

在domain_realm块下，前两个条目中不会有.mycompany。这是一个问题吗？

我们通过运行以下命令生成密钥表文件: ktpass /princ HTTP/jaguar.enterpriselabs.mycompany.com@ENTERPRISELABS.MYCOMPANY.COM /mapuser jaguar@ENTERPRISELABS.MYCOMPANY.COM -crypto all -pass password -ptype KRB5_NT_PRINCIPAL -out c：\jaguar host.keytab

我们将生成的密钥表文件复制到JBoss上应用程序的WEB-INF/classes文件夹中。当我们联系我们的技术支持时，他们还提到创建的测试用户帐户选中了“Kerberos身份验证”复选框。我认为当我们登录到域时，我们是使用kerberos而不是NTLM进行身份验证的(我不知道它是否正确)。但是，这并不能帮助我们摆脱上述问题。我使用了fiddler，在其中一个屏幕上看到了“NTLM身份验证”。请帮助我们调试这个问题。我认为问题出在AD的某个地方，不知道去哪里寻找答案。我们是否必须遵循任何特定的步骤来确保我们的AD配置正确？有没有办法配置AD服务器发送Kerberos令牌？

Answer 1

您确定jaguar.enterpriselabs.mycompany.com是DNS A记录主机名而不是别名吗？

我想我在使用DNS别名主机名(CNAME)创建keytab时遇到了类似的错误消息。

当浏览器向KDC请求票证时，它始终使用DNS A记录主机名，而不管您在浏览器地址栏中拥有的主机名是什么。用户仍然可以使用CNAME别名主机名访问站点，但必须使用A记录主机名创建密钥表。