我们很难让Security/Kerberos/AD为我们的web应用程序工作。我们的诊断是我们的AD服务器发送NTLM令牌(我们可以从“TlRMTVNT.”开始判断)然后,IE和IE将其发送到我们的应用程序,并且失败了。我们的AD服务器应该向IE发送Kerberos/SPNEGO令牌。
“移动部件”如下:
(patched)
F 211
我们已经按照下面的说明详细设置了所有内容:
https://spring.io/blog/2009/09/28/spring-security-kerberos-spnego-extension
这包括:
当我们启动TC服务器时,我们可以看到一些东西正在很好地初始化(即没有错误-“从keytab获得的原则键”):
Creating instance of bean 'org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator#10fa4b8'
Invoking afterPropertiesSet() on bean with name 'org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator#10fa4b8'
Config name: C:\WINDOWS\krb5.ini
Debug is true storeKey true useTicketCache false useKeyTab true doNotPrompt true ticketCache is null isInitiator false KeyTab is C:\se-security\spring-security-kerberos\spring-security-kerberos-sample\src\main\webapp\WEB-INF\etc\ourwebapp4.keytab refreshKrb5Config is false principal is HTTP/ourwebappweb4.testdomain.ourcompany.co.uk tryFirstPass is false useFirstPass is false storePass is false clearPass is false
>>> KeyTabInputStream, readName(): TESTDOMAIN.OURCOMPANY.CO.UK
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): ourweb
>>> KeyTab: load() entry length: 78; type: 1
>>> KeyTabInputStream, readName(): TESTDOMAIN.OURCOMPANY.CO.UK
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): ourweb.testdomain.ourcompany.co.uk
>>> KeyTab: load() entry length: 113; type: 1
Added key: 1version: 2
Ordering keys wrt default_tkt_enctypes list
default etypes for default_tkt_enctypes: 1.
0: EncryptionKey: keyType=1 kvno=2 keyValue (hex dump)=
0000: 91 01 43 E3 02 A8 B9 83
principal's key obtained from the keytab
principal is HTTP/ourweb.testdomain.ourcompany.co.uk@TESTDOMAIN.OURCOMPANY.CO.UK
EncryptionKey: keyType=1 keyBytes (hex dump)=0000: 91 01 43 E3 02 A8 B9 83
Added server's keyKerberos Principal HTTP/ourweb.testdomain.ourcompany.co.uk@TESTDOMAIN.OURCOMPANY.CO.UKKey Version 2key EncryptionKey: keyType=1 keyBytes (hex dump)=
0000: 91 01 43 E3 02 A8 B9 83
[Krb5LoginModule] added Krb5Principal HTTP/ourweb.testdomain.ourcompany.co.uk@TESTDOMAIN.OURCOMPANY.CO.UK to Subject Commit Succeeded
Finished creating instance of bean 'org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator#10fa4b8' 准备测试时,我们在IE中启用了"Windows集成身份验证“,并确保在IE的本地intranet站点部分列出了域。然后,我们使用完全限定的域名连接到我们的web应用程序。
当我们这样做时,我们在浏览器中得到了以下错误:
500 Internal server error.在TC Server日志文件中:
Negotiate Header was invalid: Negotiate TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw==
org.springframework.security.authentication.BadCredentialsException: Kerberos validation not succesfull
at org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator.validateTicket(SunJaasKerberosTicketValidator.java:74)
at org.springframework.security.extensions.kerberos.KerberosServiceAuthenticationProvider.authenticate(KerberosServiceAuthenticationProvider.java:92)
at org.springframework.security.authentication.ProviderManager.doAuthentication(ProviderManager.java:120)
at org.springframework.security.authentication.AbstractAuthenticationManager.authenticate(AbstractAuthenticationManager.java:48)
at org.springframework.security.extensions.kerberos.web.SpnegoAuthenticationProcessingFilter.doFilter(SpnegoAuthenticationProcessingFilter.java:132)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:79)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:149)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at com.springsource.metrics.collection.web.HttpRequestMetricCollectionValve.invoke(HttpRequestMetricCollectionValve.java:44)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:379)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
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)
at javax.security.auth.Subject.doAs(Subject.java:396)
at org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator.validateTicket(SunJaasKerberosTicketValidator.java:72)
... 25 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)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:287)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
at org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator$KerberosValidateAction.run(SunJaasKerberosTicketValidator.java:161)
at org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator$KerberosValidateAction.run(SunJaasKerberosTicketValidator.java:1)
... 28 more
SecurityContextHolder now cleared, as request processing completed似乎(从我们所能看到的) AD服务器发送NTLM令牌(当它以“TlRMTVNT.”开头时,我们可以知道)然后,IE和IE将其发送到我们的应用程序,并且失败了。
我们的AD服务器应该向IE发送Kerberos/SPNEGO令牌。
其他说明:
发布于 2010-08-04 22:10:12
当您在同一台计算机上运行客户端和服务器时,可能会发生这种情况。当您使用IE与正在运行的机器对话时,请确保这些是不同的机器。
此外,您需要确保服务器机器连接到keytab (testdomain.ourcompany.co.uk)中指定的域,否则可能会回到NTLM。您的keytab仍然可以工作,即使您的服务器在一台没有加入域的机器上(您将看到您显示的漂亮的keytab解密),但是IE可能会感到困惑而不做正确的事情。
AD只喜欢使用ARCA4-HMAC for Server 2003,所以您需要确保在krb5.ini文件中正确设置。
您可以像这样正确地创建keytab:
C:\>ktpass -princ HTTP/ourweb.testdomain.ourcompany.co.uk@TESTDOMAIN.OURCOMPANY.CO.UK -mapuser ourweb.testdomain.ourcompany.co.uk@TESTDOMAIN.OURCOMPANY.CO.UK -crypto RC4-HMAC-NT -ptype K
RB5_NT_PRINCIPAL -pass * -out ourweb.keytab
Targeting domain controller: test-dc.ourcompany.co.uk
Using legacy password setting method
Successfully mapped HTTP/ourweb.testdomain.ourcompany.co.uk@TESTDOMAIN.OURCOMPANY.CO.UK to ourweb.testdomain.ourcompany.co.uk.
Key created.
Output keytab to ourweb.keytab:
Keytab version: 0x502
keysize 75 HTTP/ourweb.testdomain.ourcompany.co.uk@TESTDOMAIN.OURCOMPANY.CO.UK ptype 1 (KRB5_NT_PRINCIPAL)
vno 3 etype 0x17 (RC4-HMAC) keylength 16 (0x0fd0e500225c4fca9a63a9998b17ca32)我没有看到你设置了一个krb5.ini文件。您需要在服务器机器上正确设置该设置(默认位置C:\WINDOWS\krb5.ini):
[domain_realm]
.testdomain.ourcompany.co.uk = TESTDOMAIN.OURCOMPANY.CO.UK
testdomain.ourcompany.co.uk = TESTDOMAIN.OURCOMPANY.CO.UK
[libdefaults]
default_realm = TESTDOMAIN.OURCOMPANY.CO.UK
permitted_enctypes = aes128-cts aes256-cts arcfour-hmac-md5
default_tgs_enctypes = aes128-cts aes256-cts arcfour-hmac-md5
default_tkt_enctypes = aes128-cts aes256-cts arcfour-hmac-md5
[realms]
VERDAD.LOCAL = {
kdc = test-dc.ourcompany.co.uk
admin_server = test-dc.ourcompany.co.uk
default_domain = TESTDOMAIN.OURCOMPANY.CO.UK
}您还可能需要设置以下属性(如果您试图从IDE运行此属性):
<systemProperties>
<java.security.krb5.kdc>test-dc.ourcompany.co.uk</java.security.krb5.kdc>
<java.security.krb5.realm>TESTDOMAIN.OURCOMPANY.CO.UK</java.security.krb5.realm>
</systemProperties>我在maven中使用了org.codehaus.mojo插件,它在pom文件中设置了这些插件,如下所示:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>tomcat-maven-plugin</artifactId>
<configuration>
<server>tomcat-development-server</server>
<port>8080</port>
<path>/SecurityTest</path>
<systemProperties>
<java.security.krb5.kdc>test-dc.ourcompany.co.uk</java.security.krb5.kdc
<java.security.krb5.realm>TESTDOMAIN.OURCOMPANY.CO.UK</java.security.krb5.realm>
</systemProperties>
</configuration>
</plugin>
</plugins>
</build>发布于 2014-05-20 13:15:06
我也遇到了这个问题。对于那些将来会有这个问题的不幸的人来说,造成这个问题的另一个原因是通过ip访问服务器,而不是通过一个记录(主机名)
发布于 2015-04-11 14:06:28
我也有同样的问题,花了很长时间才找到罪魁祸首。因此,如果您已经完成了上述所有操作,并且仍然使用NTLM令牌而不是kerberos。确保你没有重复的SPN。在我的例子中,我有两个帐户映射到同一个SPN,原因是我以前在同一服务器上运行了一个单独的web应用程序,该应用程序使用不同的服务帐户,但映射到相同的SPN,即HTTP/
希望它能帮上忙
https://stackoverflow.com/questions/2973355
复制相似问题