带有Spring Security Kerberos扩展/IE,Firefox/AD的Negotiate Header无效错误 [英] Negotiate Header was invalid error with Spring Security Kerberos extension/IE, Firefox/AD

查看:131
本文介绍了带有Spring Security Kerberos扩展/IE,Firefox/AD的Negotiate Header无效错误的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们正在JBoss AS 7.1.1的OWF 7(臭氧小部件框架)中配置Spring Security Kerberos扩展.我们看到以下错误:

We are configuring Spring Security Kerberos extension in OWF 7 (Ozone Widget Framework) on JBoss AS 7.1.1. We see the following error:

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

我看到了有关堆栈溢出的帖子(使用Kerberos/Spring Security/IE/Active Directory的检测到有缺陷的令牌"错误(NTLM不是Kerberos)),并认为有人可以帮助我解决我们的情况.

I saw a post on stack overflow ("Defective token detected" error (NTLM not Kerberos) with Kerberos/Spring Security/IE/Active Directory) and thought someone can help me with our situation.

我们的设置:

JDK 1.6.0_31 在x86_64上的Red Hat Enterprise Linux Server 6.2(圣地亚哥)内核2.6.32-220.el6.x86_64上运行的JBoss AS 7.1.1.Final Windows Server 2008活动目录 Spring Security Kerberos Extension M2(根据其博客中提供的说明进行配置: http://blog.springsource.com/2009/09/28/spring-security-kerberos/) Firefox 21(在VM上运行) IE 10(在VM上运行)

JDK 1.6.0_31 JBoss AS 7.1.1.Final running on Red Hat Enterprise Linux Server release 6.2 (Santiago) Kernel 2.6.32-220.el6.x86_64 on an x86_64 Windows Server 2008 Active Directory Spring Security Kerberos Extension M2 (configured following the instructions provided in their blog: http://blog.springsource.com/2009/09/28/spring-security-kerberos/ ) Firefox 21 (runs on a VM) IE 10 (runs on a VM)

在上面列出的上一篇文章中,似乎AD服务器正在向IE发送NTLM令牌,而IE正在将其发送给应用程序.我们的应用程序服务器(JBoss),AD服务器和客户端(IE,Firefox)位于不同的计算机上 已加入同一域.以下是JBoss所在的linux框/etc文件夹中的krb5.conf文件:

From the previous post listed above it appears like AD server is sending an NTLM token to IE and IE is sending this to application. We have our Application Server (JBoss), AD Server and client (IE, Firefox) on different machines joined to the same domain. Below is the krb5.conf file from /etc folder of the linux box where JBoss is:

[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]块下,前2个条目中没有.mycompany.这有问题吗?

Under [domain_realm] block the first 2 entries won't have .mycompany in them. Is this a problem?

我们通过运行以下命令来生成keytab文件: ktpass/princ HTTP/jaguar.enterpriselabs.mycompany.com@ENTERPRISELABS.MYCOMPANY.COM/mapuser jaguar@ENTERPRISELABS.MYCOMPANY.COM-全部加密-通过密码-ptype KRB5_NT_PRINCIPAL-输出c:\ jaguar-host.keytab

We generated the keytab file by running the following command: 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进行身份验证的(我不知道它是否正确).但是,这并没有帮助我们摆脱上述问题. 我使用提琴手,在其中一个屏幕中看到了"NTLM身份验证".请帮助我们调试此问题.我认为问题出在AD某处,不知道在哪里寻找答案.我们是否必须遵循任何特定的 步骤来确保我们的广告配置正确?有没有一种方法可以配置AD服务器发送Kerberos令牌?

We copied the keytab file generated to the WEB-INF/classes folder of our application on JBoss. When we contacted our tech support they also mentioned that test user accounts created have 'Kerberos Authentication' checkbox checked. I think when we login to the domain we are authenticated using kerberos not NTLM (I don't know whether it is correct or not). But, this didn't help us getting rid of the above problem. I used fiddler and saw 'NTLM Authentication' in one of the screens. Please help us in debugging this problem. I think the problem is in AD somewhere and don't know where to look for answers. Do we have to follow any specific steps to make sure our AD is configured right? Is there a way to configure AD server to send Kerberos token?

推荐答案

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

Are you sure that jaguar.enterpriselabs.mycompany.com is DNS A record hostname instead of CNAME alias?

使用DNS别名主机名(CNAME)创建密钥表时,我认为我也遇到类似的错误消息.

I think I had a similar error message when I created the keytab using a DNS alias hostname (CNAME).

当浏览器向KDC索要票证时,它将始终使用DNS A记录主机名,而不管浏览器地址栏中的主机名如何.用户仍然可以使用CNAME别名主机名来访问站点,但是必须使用A记录主机名来创建密钥表.

When browser asks KDC for the ticket, it always uses the DNS A record hostname, regardless of the hostname you have in browser address bar. Users can still use CNAME alias hostnames to access the site, but the keytab must be created using A record hostname.

这篇关于带有Spring Security Kerberos扩展/IE,Firefox/AD的Negotiate Header无效错误的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆