Заголовок согласования был недопустимой ошибкой с расширением Spring Security Kerberos /IE, Firefox/AD
Мы настраиваем расширение Spring Security Kerberos в OWF 7 (Ozone Widget Framework) на JBoss AS 7.1.1. Мы видим следующую ошибку:
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
Я увидел сообщение о переполнении стека ( ошибка "Обнаружен дефектный токен" (NTLM не Kerberos) с Kerberos / Spring Security / IE / Active Directory) и подумал, что кто-то может помочь мне в нашей ситуации.
Наша установка:
JDK 1.6.0_31 JBoss AS 7.1.1. Наконец-то работает на Red Hat Enterprise Linux Server версии 6.2 (Сантьяго) Ядро 2.6.32-220.el6.x86_64 на x86_64 Windows Server 2008 Active Directory Spring Security Kerberos Extension M2 (настраивается после инструкции, приведенные в их блоге: http://blog.springsource.com/2009/09/28/spring-security-kerberos/) Firefox 21 (работает на виртуальной машине) IE 10 (работает на виртуальной машине)
Из предыдущего поста, указанного выше, похоже, что сервер AD отправляет токен NTLM в IE, а IE отправляет его в приложение. У нас есть сервер приложений (JBoss), сервер AD и клиент (IE, Firefox) на разных компьютерах, подключенных к одному домену. Ниже приведен файл krb5.conf из папки /etc окна linux, где находится JBoss:
[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. Это проблема?
Мы сгенерировали файл keytab, выполнив следующую команду: ktpass /princ HTTP/jaguar.enterpriselabs.mycompany.com@ENTERPRISELABS.MYCOMPANY.COM /mapuser jaguar@ENTERPRISELABS.MYCOMPANY.COM -crypto all -pass password -ptype KRPR5NRT:\ ягуара host.keytab
Мы скопировали сгенерированный файл keytab в папку WEB-INF/classes нашего приложения на JBoss. Когда мы связались с нашей службой технической поддержки, они также отметили, что для созданных тестовых учетных записей установлен флажок "Аутентификация Kerberos". Я думаю, что когда мы входим в домен, мы аутентифицируемся, используя Kerberos, а не NTLM (я не знаю, правильно ли это или нет). Но это не помогло нам избавиться от вышеуказанной проблемы. Я использовал fiddler и увидел "Аутентификацию NTLM" на одном из экранов. Пожалуйста, помогите нам в устранении этой проблемы. Я думаю, что проблема в AD где-то и не знаю, где искать ответы. Нужно ли нам выполнять какие-то конкретные шаги, чтобы убедиться, что наша AD настроена правильно? Есть ли способ настроить сервер AD для отправки токена Kerberos?
1 ответ
Вы уверены, что jaguar.enterpriselabs.mycompany.com является DNS-именем узла записи вместо псевдонима CNAME?
Я думаю, что у меня было похожее сообщение об ошибке при создании таблицы ключей с использованием псевдонима хоста DNS (CNAME).
Когда браузер запрашивает билет у KDC, он всегда использует имя хоста записи DNS A, независимо от имени хоста, которое есть в адресной строке браузера. Пользователи по-прежнему могут использовать псевдонимы хостов CNAME для доступа к сайту, но таблица ключей должна быть создана с использованием имени хоста записи.