Проверка подлинности Tomcat 8 и Windows NTLM для пользователя, не являющегося доменом

Question

У нас есть приложение Tomcat 8 с настроенной аутентификацией Windows (IWA) с аутентификатором SPNEGO, keytab и SPN. Он отлично работает для пользователей домена - они аутентифицируются без запроса пользователя и пароля с помощью Kerberos. Для пользователей, не являющихся пользователями домена, мы хотели бы разрешить аутентификацию, введя имя пользователя и пароль, используя собственное всплывающее окно браузера. Кажется, что tomcat должен использовать NTLM для этого случая. Hovewer, когда пользователь без домена входит логин и пароль для браузера всплывающих окон - это сново и есть исключение в TOMCAT журнала:

2017-01-24 05:15:46,910 [http-nio-127.0.0.1-8455-exec-9] DEBUG org.apache.catalina.authenticator.SpnegoAuthenticator- Unable to login as the service principal 
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:422) 
       at org.apache.catalina.authenticator.SpnegoAuthenticator.authenticate(SpnegoAuthenticator.java:230) 
       at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:577) 
       at com.avaya.cas.auth.authenticator.IViewTokenAuthenticator.invoke(IViewTokenAuthenticator.java:212) 
       at com.avaya.cas.ssl.valves.SSLValve.invoke(SSLValve.java:84) 
       at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142) 
       at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) 
       at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:240) 
       at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:676) 
       at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) 
       at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518) 
       at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1091) 
       at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:668) 
       at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1527) 
       at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1484) 
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
       at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) 
       at java.lang.Thread.run(Thread.java:745) 
Caused by: GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag) 
       at sun.security.jgss.GSSHeader.<init>(GSSHeader.java:97) 
       at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:306) 
       at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285) 
       at org.apache.catalina.authenticator.SpnegoAuthenticator$AcceptAction.run(SpnegoAuthenticator.java:323) 
       at org.apache.catalina.authenticator.SpnegoAuthenticator$AcceptAction.run(SpnegoAuthenticator.java:310) 
       ... 20 more 

Существует кусок ofcode из GSSHeader:

int var2 = decodedHeader.read(); 
     if(var2 != 96) { 
      throw new GSSException(10, -1, "GSSHeader did not find the right tag"); 

в моем случае var2 is 78 ('N' char) decodedHeader - это стандартное первое сообщение NTLM, которое отправляется из браузера в заголовке авторизации. В моем случае это:

Авторизация: Обсуди TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAKADk4AAAADw ==

После декодирования будет что-то вроде 'NtlmSsp ... двоичные данные ...'. Итак, первый байт этого сообщения всегда «N» (78), но не 96, как ожидал код Tomcat.

Поддерживает ли Tomcat аутентификацию NTLM? Это очень странно, так как пользователи домена могут быть аутентифицированы (это означает, что Tomcat может расшифровать вызов от пользователя, используя предоставленный keytab)

Answer 1

Donator кода SPNEGO здесь.

GSSHeader did not find the right tag означает, что клиенту SPNEGO не был отправлен клиент, you receive a pure NTLM token. Это происходит, когда Kerberos по какой-то причине не работает, и это ваш случай.

NTLM очень отличается и очень проприетарен. В этом случае сервер выступает в качестве среднего человека для передачи хэшей с клиента на контроллер домена. Сервер сам не может ничего. Нет никакого способа, чтобы Tomcat мог расшифровать что-либо without the help of a domain controller. Кроме того, не существует известной версии серверной версии NTLM, доступной как открытый источник (особенно не на Java), кроме внутреннего кода Samba.

Результат: forget about NTLM и делать то, что я рекомендую here.

Примечание: для такого сценария существует IAKERB, но только MIT Kerberos и не более Хеймдал поддерживают его.