Authentification Tomcat 8 et Windows NTLM pour utilisateur non-domaine

Question

Nous avons l'application Tomcat 8 avec authentification Windows configurée (IWA) avec l'authentificateur SPNEGO, keytab et SPN. Cela fonctionne très bien pour les utilisateurs de domaine: ils sont authentifiés sans demander d'utilisateur ni de mot de passe à l'aide de Kerberos. Pour les utilisateurs n'appartenant pas au domaine, nous souhaitons autoriser l'authentification en entrant le nom d'utilisateur et le mot de passe à l'aide de la fenêtre contextuelle native du navigateur. Il semble que Tomcat devrait utiliser NTLM dans ce cas. hovewer, lorsque l'utilisateur non-domaine entre login et mot de passe pour pop-up du navigateur - il réapparaît et il y a exception dans le journal 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 

Il y a pièce ofcode de GSSHeader:

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

dans mon cas var2 est 78 (char 'N') decodedHeader- est un premier message NTLM standart, qui est envoyé à partir du navigateur dans l'en-tête Authorization. Dans mon cas, il est:

Autorisation: Négociez TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAKADk4AAAADw ==

après décodage, il sera quelque chose comme 'NTLMSSP ... données binaires ...'. Donc, le premier octet de ce message est toujours 'N' (78) mais pas 96, comme attendu par le code de Tomcat.

Tomcat prend-il en charge l'authentification NTLM? C'est très étrange, puisque les utilisateurs du domaine peuvent être authentifiés (cela signifie que Tomcat pourrait déchiffrer le défi de l'utilisateur en utilisant keytab fourni)

Answer 1

Donateur du code SPNEGO ici. Signifie qu'aucun jeton SPNEGO n'a été envoyé par le client, you receive a pure NTLM token. Cela se produit lorsque Kerberos échoue pour une raison quelconque, ce qui est votre cas.

NTLM est très différent et très propriétaire. Dans ce cas, le serveur agit comme un intermédiaire pour transmettre les hachages du client à un contrôleur de domaine. Le serveur ne peut rien lui-même. Il n'y a aucun moyen que Tomcat puisse décrypter quoi que ce soit without the help of a domain controller. De plus, il n'existe aucune implémentation NTLM côté serveur disponible en open source (surtout en Java), à l'exception du code interne de Samba.

Surlignée: forget about NTLM et faites ce que je recommande here.

Remarque: il existe IAKERB pour un tel scénario, mais seuls MIT Kerberos et au mieux Heimdal le prennent en charge.