Module d'Authentification Windows - Waffle 2.1

1. Introduction

Prérequis :

• Le serveur d'application doit être installé sur un serveur Windows, rattaché au domaine
• Le serveur d'application doit être exécuté en tant que Local System account ou Network Service account
• Si vous utilisez Tomcat avec Apache/mod_jk ou IIS/isapi_redirect, assurez vous d'utiliser la dernière version des connecteurs mod_jk/isapi_redirect. Une version supérieure ou égale à la 1.2.32 est requise.
• Le Keep-Alive doit être activé sur les serveurs.

Principe

1. L'utilisateur ouvre une session Windows sur son PC.
   Son authentification est réalisée à l'aide d'un domaine Windows et d'un serveur Active Directory.
2. L'utilisateur se connecte à JCMS/JPlatform à l'aide de son navigateur, qui communique automatiquement ses informations d'identification (voir la configuration côté client pour plus de détails à ce sujet).
3. Le gestionnaire d'authentification interne fourni dans le plug-in Waffle reçoit les informations d'identification via le filtre Waffle et définit le membre authentifié (en le synchronisant à partir de LDAP / Active Directory si nécessaire).

2. Installation

2.1 Configuration serveur : LDAP / Active Directory

Assurez-vous que LDAP est activé et configuré pour vous connecter à votre serveur Active Directory.
Essayez de vous connecter à JCMS/JPlatform avec l'un de vos comptes utilisateurs ActiveDirectory pour vous assurer que la connexion et la synchronisation fonctionnent correctement.

2.2 Configuration serveur : WaffleHttpFilter

Configurez WaffleHttpFilter dans votre web.xml comme suit :

Important : Assurez-vous que les sections <filter> et <filter-mapping> sont ajoutées AVANT WaffleHttpFilter toutes les autres sections <filter> et <filter-mapping> déjà existantes dans web.xml.
En effet, l'authentification est récupérée par JCMS/JPlatform dans la InitFilter, donc WaffleHttpFilter doit avoir été invoqué avant InitFilter.

Une configuration typique sera la suivante

       
       <filter>
         <filter-name>WaffleHttpFilter</filter-name>
         <filter-class>com.jalios.jcmsplugin.waffle.WaffleHttpFilter</filter-class>
         <init-param>
             <param-name>principalFormat</param-name>
             <param-value>fqn</param-value>
         </init-param>
         <init-param>
             <param-name>roleFormat</param-name>
             <param-value>both</param-value>
         </init-param>
         <init-param>
             <param-name>allowGuestLogin</param-name>
             <param-value>false</param-value>
         </init-param>
         <init-param>
             <param-name>impersonate</param-name>
             <param-value>false</param-value>
         </init-param>
         <init-param>
             <param-name>securityFilterProviders</param-name>
             <param-value>
              waffle.servlet.spi.NegotiateSecurityFilterProvider
             </param-value>
         </init-param>
         <init-param>
             <param-name>waffle.servlet.spi.NegotiateSecurityFilterProvider/protocols</param-name>
             <param-value>
              Negotiate
              NTLM
             </param-value>
         </init-param>
       </filter>
       
       [...]
       
       <filter-mapping>
         <filter-name>WaffleHttpFilter</filter-name>
         <url-pattern>/*</url-pattern>
       </filter-mapping>
       
     

Sachez qu'une fois ce filtre configuré, une authentification Windows sera demandée et requise, aucune autre authentification ne sera possible, à moins que vous ne configuriez le module comme expliqué dans la section 3.1 Utiliser l'authentification Windows et les autres authentifications JCMS/JPlatform

2.3 Configuration côté serveur : Serveur d'application Java et Serveur frontaux

SPNego et Kerberos nécessitent de très grandes valeurs d'en-tête HTTP.
Pour que ces en-têtes HTTP soient reçus correctement depuis le navigateur, il est nécessaire d'augmenter la limite par défaut de la plupart des serveurs d'application.
Si cette configuration n'est pas correctement faite, certains clients verront les erreurs HTTP "400 bad request" et "413 Request entity too large" comme expliqué en détail dans le post du blog Microsoft : Microsoft Technology - Kerberos Authentication Problem with Active Directory

La configuration suivante s'applique à Apache HTTPD, avec mod_jk, et le connecteur AJP ou HTTP sur Apache Tomcat. Si vous utilisez un autre serveur d'application et un autre connecteur de serveur HTTP, vérifiez sa documentation pour vous assurer que les limites des en-têtes HTTP sont correctement configurées.

La valeur de 15360 octets est utilisée arbitrairement dans tous les exemples ci-dessous car elle dépasse la taille maximale de l'en-tête HTTP utilisée pendant le protocole SP Nego (comme indiqué dans la documentation Apache HTTPD).
Vous voudrez peut-être affiner cette valeur en fonction de votre architecture.

2.3.1. Apache Tomcat : maxHttpHeaderSize

Ajouter l'attribut maxHttpHeaderSize sur le connecteur HTTP dans le fichier server.xml d'Apache Tomcat

  maxHttpHeaderSize="15360"

Cf http://tomcat.apache.org/tomcat-6.0-doc/config/http.html

2.3.2. mod_jk / AJP : max_packet_size/packetSize

Lors de l'utilisation de mod_jk et du protocole AJP entre Apache HTTPD et Apache Tomcat, la taille des paquets utilisés par le protocole AJP entre les deux parties doit être modifiée en utilisant une valeur plus grande, identique des deux côtés !

a) Apache HTTPD : ajouter l'attribut max_packet_size dans le fichier workers.properties 

  worker.myworker.max_packet_size=15360

Cf http://tomcat.apache.org/connectors-doc/reference/workers.html

b) Apache Tomcat : ajouter l'attribut packetSize sur le connecteur AJP dans le fichier server.xml 

  packetSize="15360"

Cf http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html

2.3.3. Apache HTTPD : LimitRequestFieldSize and Keep-Alive

Ajouter la configuration LimitRequestFieldSize sur tous les hotes virtuels (HTTP and HTTPS)

  LimitRequestFieldSize 15360

Cf http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize

Assurez-vous également que la fonction Keep-Alive est activée (c'est la configuration par défaut)

  KeepAlive On

http://httpd.apache.org/docs/2.2/mod/core.html#keepalive 

2.4 Configuration côté client

La plupart des navigateurs internet requiert une configuration personnalisée afin que l’authentification Windows puisse être envoyé à un serveur HTTP distant.

2.4.1 Microsoft Internet Explorer

Le domaine du serveur HTTP doit être ajouté à la zone de sécurité intranet local, et l’option « Connexion automatique uniquement dans la zone Intranet » doit être activée.

Vous pouvez configurer Internet Explorer en effectuant la procédure suivante sur chaque ordinateur client.
Vous pouvez également configurer ces paramètres à l’aide de stratégie de groupe. À l’aide de stratégie de groupe, vous pouvez configurer des ordinateurs clients sans avoir à ouvrir une session chaque ordinateur.

Pour configurer Internet Explorer pour l’ouverture de session automatique

1. En choisissant les Options Internet du panneau de configuration ou dans le menu outils dans Internet Explorer, ouvrez la boîte de dialogue Options Internet .
2. Dans la boîte de dialogue Options Internet , sous l’onglet sécurité , sélectionnez intranet Local puis cliquez sur Personnaliser le niveau.
3. Dans la boîte de dialogue Paramètres de sécurité , sous connexion, sélectionnez connexion automatique uniquement dans la zone Intranetet puis cliquez sur OK.
4. Dans la boîte de dialogue Options Internet sous l’onglet Paramètres de sécurité avec intranet Local toujours sélectionné, cliquez sur Sites.
5. Dans la boîte de dialogue intranet Local , cliquez sur avancé.
6. Dans la boîte de dialogue suivante (également intitulé intranet Local), tapez l’URL de votre site web JCMS/JPlatform (par exemple, https://intranet.mycompany.com) dans la zone ajouter ce site Web à la zone et puis cliquez sur ajouter.
7. Dans la boîte de dialogue intranet Local , boîte, cliquez sur OK.
8. Dans la boîte de dialogue intranet Local originale, cliquez sur OK.
9. Dans la boîte de dialogue Options Internet , cliquez sur OK.

Pour configurer Internet Explorer pour l’ouverture de session automatique à l’aide de stratégie de groupe

1. Ouvrez la Console de gestion de stratégie de groupe, puis créez un nouvel objet de stratégie de groupe (GPO) ou modifier un GPO existant.
2. Développez Configuration ordinateur, Développez stratégies, Développez Modèles d’administration, Développez Composants Windows, Développez Internet Explorer, développez le Panneau de configuration Internetet puis cliquez sur Page de sécurité.
3. Dans le volet détails, double-cliquez sur Site à la Zone liste de cession.
4. Dans la boîte de dialogue Site de Zone affectation de propriétés de la liste , cliquez sur activé.
5. Dans la boîte de dialogue Site de Zone affectation de propriétés de la liste , cliquez sur Afficher.
6. Dans la boîte de dialogue Afficher le contenu , cliquez sur ajouter.
7. Dans la boîte de dialogue Ajouter un élément , tapez l’URL de votre site web JCMS/JPlatform (par exemple, https://intranet.mycompany.com) dans la zone Entrez le nom de l’élément à ajouter .
8. Tapez 1 (indiquant la zone intranet local) dans la zone Entrez la valeur de l’élément à ajouter et puis cliquez sur OK.
9. Dans la boîte de dialogue Afficher le contenu , cliquez sur OK.
10. Dans la boîte de dialogue de Site à la liste d’affectation Zone , cliquez sur OK.
11. Dans l’éditeur de gestion de stratégie de groupe, cliquez sur Zone Intranet.
12. Dans le volet détails, double-cliquez sur options de connexion.
13. Dans la boîte de dialogue options de connexion propriétés , cliquez sur activé.
14. Dans la liste des options de connexion , cliquez sur connexion automatique uniquement dans la zone Intranetet puis cliquez sur OK.
15. Fermez l’éditeur de gestion de stratégie de groupe.

Pour plus d’informations, lire :

• Configuration côté client dans Microsoft.com - HTTP-Based Cross-Platform Authentication by Using the Negotiate Protocol
• Microsoft.com - Configuring Internet Explorer for Automatic Logon

2.4.2 Google Chrome

Google chrome utilise la configuration d’Internet Explorer et est automatiquement configuré pour envoyer les informations d’identification appropriées si Internet Explorer est configuré correctement.
Lire Chromium.org - HTTP authentication pour plus d’informations.

2.4.3 Mozilla Firefox

Le domaine du serveur HTTP doit être ajouté sur le domaine approuvé pour l’authentification Negotiate, à l’aide de préférence network.negotiate-auth.trusted-uris, soit par le biais about:config (dans la barre d’adresse) ou en prefs.js (dans le répertoire de profil utilisateur).
Lire Mozilla.org - Integrated Authentication pour plus d’informations.

2.5 migration à partir du « Module NTLM »

Si vous utilisiez le « Module NTLM », suivez ces étapes pour migrer votre installation vers ce module :

1. Vérifiez que votre architecture répond aux prérequis
2. Configurer web.xml
   • Configurer la servlet filter Waffle, comme expliqué dans section 2.2 configuration serveur : WaffleHttpFilter,
   • Migrer la configuration de servlet pour JSync :
     Contrairement au module NTLM, le WaffleHttpFilter est entièrement compatible avec JSync en utilisant uniquement le mappage générique simple /*, aucune autre configuration n’est requise. Par conséquent, si vous aviez effectué une configuration avancée du filtre de servlet NTLM pour la compatibilité JSync, nous vous conseillons d’utiliser le mappage générique plus simple et plus sûr.
   • Migration des règles d’accès personnalisées le cas échéant :
     Si vous aviez des règles d’accès configurées pour le NtlmHttpFilter dans web.xml, recopiez la configuration tel quel dans le nouveau WaffleHttpFilter. Puis remplacez l'ancien nom de package com.jalios.jcmsplugin.ntlm.rules avec com.jalios.jcms.authentication.rules.
3. Nettoyage
   • Supprimer toute référence au filtre de servlet NTLM et JCIFS de votre web.xml,
   • Désinstaller le module NTLM de JCMS/JPlatform,
4. Courir
   Assurez-vous que le serveur d’applications hébergement JCMS/JPlatform est en cours d’exécution à l’aide du Compte système Local ou le compte Service réseau de préférence.

2.6 Mise à jour depuis la version 1.1

 Si vous utilisiez la version 1.1 du module, désinstallez au préalable le module existant depuis l'interface d'administration des modules JCMS/JPlatform. Déployez ensuite la nouvelle version du module. Sans cette opération, des versions conflictuelles de librairies Java seront installées simultanément. 
Si vous avez installé une version plus récente du module sans effectuer cette étape, supprimez manuellement les fichiers suivants de votre webapp JCMS/JPlatform : 

• WEB-INF/lib/guava-r07.jar
• WEB-INF/lib/jna.jar
• WEB-INF/lib/platform.jar

3. Configuration avancée

3.1 Utilisation simultanée de l'authentification Windows et d'autre methodes d'authentification

Si vous souhaitez fournir à la fois l'authentification Windows et d'autres méthodes d'authentification JCMS/JPlatform, le module waffle offre deux possibilités pour vous cela :

1. Authentification entièrement automatique : En utilisant des règles d'accès personnalisées avancées pour déterminer quand l'authentification Windows doit être déclenchée ou non.
2. Authentification semi-automatique : En utilisant la propriété jcmsplugin.waffle.windows-auth-required pour permettre l'accès au site sans authentification Windows

3.1.1 Authentification automatique : Utilisation de règles personnalisées avancées (IP, User-Agent, URI, HostName, ....)

Vous pouvez spécifier une règle d'accès personnalisée pour définir quand le filtre d'authentification Waffle sera déclenché ou non.
Cette approche offre la meilleure expérience utilisateur car elle effectue l'authentification automatiquement lorsque vous savez que c'est possible.
Par exemple, vous pouvez utiliser automatiquement l'authentification Windows pour les utilisateurs de l'intranet (ayant une adresse IP interne) mais d'autres méthodes d'authentification pour les utilisateurs venant d'Internet.

Pour cela, le WaffleHttpFilter permet de définir des règles d'accès personnalisées.
Une règle d'accès permet de déclencher l'authentification Waffle uniquement lorsque certaines conditions sont remplies, telles que définies par la classe WaffleAccessRule spécifiée dans le paramètre d'initialisation du filtre de servlet.

Quelques règles d'accès de base sont fournies dans le paquet com.jalios.jcms.authentication.rules. Vous pouvez implémenter votre propre règle d'accès en étendant l'interface AccessRule .
Pour plus d'informations sur les règles existantes et le développement de vos propres règles, consultez la documentation  Règles d'accès des modules de SSO (aka AccessRules) .(vous pouvez également consulter la Javadoc, qui est incluse dans le répertoire PluginWaffle/plugins/WafflePlugin/docs/javadoc/access-rules/index.html du module)

Exemple #1 : Règle d'accès par IP

L'exemple suivant déclare une règle d'accès basée sur l'adresse IP du client. Dans cet exemple, Waffle sera utilisé uniquement pour les clients du réseau 192.168.0.0/24 :

     <filter>
      <filter-name>WaffleHttpFilter</filter-name>
      <filter-class>com.jalios.jcmsplugin.waffle.WaffleHttpFilter</filter-class>
      [...]
      <init-param>
          <param-name>access-rule.class</param-name>
          <param-value>com.jalios.jcms.authentication.rules.IpAccessRule</param-value>
      </init-param>
      <init-param>
          <param-name>ip-access-rule.regex</param-name>
          <param-value>^192\.168\.0\..*$</param-value>
      </init-param>
     </filter>

Exemple #2 : Régle d'accès par User Agent

L'exemple suivant déclare une règle d'accès basée sur le User Agent du navigateur (client >eb). 
L'authentification sera demandée pour les clients Web qui correspondent à l'User-Agent spécifié. Les autres clients Web n'utiliseront pas l'authentification Waffle. 
Cette règle peut être utilisée avec Stratégie de groupe (aka Group Policy) d'Internet Explorer qui permet de spécifier un User-Agent personnalisé.
Voir Internet Explorer Maintenance : Customize the User Agent String 
Pour cet exemple, nous supposons que la chaîne personnalisée "MyCompagny Custom UserAgent" a été configurée dans Internet Explorer (cette chaîne est ajoutée à l'User-Agent Internet Explorer original) :

     <filter>
      <filter-name>WaffleHttpFilter</filter-name>
      <filter-class>com.jalios.jcmsplugin.waffle.WaffleHttpFilter</filter-class>
      [...]
      <init-param>
          <param-name>access-rule.class</param-name>
          <param-value>com.jalios.jcms.authentication.rules.UserAgentAccessRule</param-value>
      </init-param>
      <init-param>
          <param-name>user-agent-access-rule.regex</param-name>
          <param-value>.*MyCompagny Custom UserAgent.*</param-value>
      </init-param>
     </filter>

Si aucun paramètre de règle d'accès n'est spécifié dans la configuration du ServletFilter, le comportement par défaut de NegotiateSecurityFilter est appliqué (i.e. l'authentification est demandé systématiquement).

3.1.2 Authentification semi-automatique : propriété "jcmsplugin.waffle.windows-auth-required"

Définiri cette propriété à false autorise l'accès au site sans authentification Windows : 

• les utilisateurs sans compte Windows pourront entrer leur login / mot de passe comme d'habitude (ou utiliser toute autre méthode de connexion disponible sur le site), 
• les utilisateurs avec un compte Active Directory devront cliquer sur le bouton "Authentifier avec mon compte Windows" (par opposition au comportement automatique d'authentification ayant lieu si la valeur de la propriété est  true )

Cette option ne change pas la configuration privée du site, telle que définie dans la zone d'administration, si le site est configuré comme privé, une authentification sera requise, qu'il s'agisse d'une authentification Windows ou d'une autre.

3.2 Logging

Si vous avez besoin d'obtenir des logs sur le processus d'authentification (par exemple pour diagnostiquer un problème d'authentification), modifiez le fichier log4j.xml et ajoutez les lignes suivantes à la fin.

<logger name="com.jalios.jcmsplugin.waffle"> <level value="DEBUG" /> </logger>
<logger name="waffle.servlet"> <level value="INFO" /> </logger>

La bibliothèque Waffle est très verbeuse en mode INFO. Pour éviter de polluer les logs avec ces informations, la configuration par défaut du module est d'activer uniquement les logs en mode WARNING pour cette bibliothèque.

3.3 OpenAPI (REST)

La servlet Open API utilisé par JCMS/JPlatform (correspondant au mappage de servlet /rest/*) ne nécessite pas d'authentification Windows pour être correctement accédée.
Si vous souhaitez bénéficier de l'authentification Windows lorsque vous accédez à OpenAPI, ajoutez simplement le paramètre authenticateWithWindows défini sur true (constantesWaffleHttpFilter.REQUEST_WINDOWS_AUTHENTIFICATION) au paramètre de la requête et l'authentification Windows actuelle sera vérifiée, si cela est possible.

3.4 JSync

Le mappage de servlet/* peut être utilisé pour la servlet WaffleHttpFilter, cette configuration est compatible avec le protocole JCMS JSync.

Le chemin "JSyncServlet" utilisé par JSync est toujours omis de l'authentification Windows, quel que soit le mapping spécifié.
En effet, la servlet de JSync utilise son propre mécanisme de sécurité et ne doit pas être filtrée par l'authentification Windows afin être accessible par les autres nœuds JCMS/JPlatform du cluster JSync

3.5 Configuration d'annuaire LDAP multiple (aka Multi-LDAP)

Lorsque ce module est utilisé sur un JCMS/JPlatform dans lequel plusieurs LDAP ont été configurés (comme expliqué dans la section Multi-LDAP de Configuration et fonctionnement du ldap dans jcms), la propriété suivante doit être modifiée dans votre fichier propriétés :

# The LDAP and JCMS login to use based on WindowsPrincipal information
# {0} : fqn aka Fully Qualified Name, eg : "JALIOS\jaquemet" see WindowsPrincipal.getName()
# {1} : domain, eg "JALIOS" (first part of fqn)
# {2} : name, eg "jaquemet" (second part of fqn)
jcmsplugin.waffle.login-format: {2}

Cette propriété définit quel login est utilisé pour la synchronisation LDAP une fois que l'utilisateur a été authentifié par le module Windows Waffle. La valeur par défaut permet d'utiliser le nom de l'utilisateur, ce qui n'est pas suffisant dans la configuration multi-LDAP.
Définissez cette propriété (soit dans custom.prop ou dans votre module principal plugin.prop) pour utiliser le FQN (Fully Qualified Name) de l'utilisateur :

jcmsplugin.waffle.login-format: {0}

4. Problèmes fréquents et solutions - FAQ

4.1Erreur ClassNotFoundException ou erreur de compilation des JSP

Assurez-vous que le paramètre d'initialisation impersonate du filtre de servlet Waffle est défini sur false

4.2 Firefox : authentification accordée en deux étapes après annulation

Problème : Lorsque vous utilisez firefox, l'authentification est accordée seulement après avoir appuyé sur le bouton annuler dans une fenêtre de demande de connexion / passe.

Explication : L'authentification "Basic" a été activée dans la configuration du filtre de servlet Waffle et est demandée avant l'authentification "Negotiate".

Correction 1 : Suppression de l'authentification "Basic" de la configuration du filtre de servlet Waffle dans le paramètre securityFilterProviders.

Correction 2 : S'assurer que "Basic" apparaît en seconde, après l'authentification Negotiate dans la configuration du filtre de servlet Waffle dans le paramètre isecurityFilterProviders 

 waffle.servlet.spi.NegotiateSecurityFilterProvider
 waffle.servlet.spi.BasicSecurityFilterProvider 

4.3 Comment déterminer si NTLM ou Kerberos est utilisé ?

Effectuez une capture Wireshark sur le PC client Windows.
Observer la valeur du champ En-tête Authorization: Negotiate... HTTP.

4.3.1 Kerberos

• L'utilisation du filtre kerberos dans wireshark affiche toutes les requêtes HTTP.
• L'en-tête HTTP Authorization: Negotiate... affiche les informations "krb5" dans les informations détaillées de SPNEGO "Simple Protected Negotiation".

4.3.2 NTLM

• L'utilisation du filtre ntlmssp dans wireshark affiche les premières requêtes HTTP.
• 3 requêtes HTTP d'affilée apparaissent au début de l'authentification, chacune avec une information différente dans l'en-tête HTTP
  1. NTLMSSP_NEGOTIATE
  2. NTLMSSP_CHALLENGE
  3. NTLMSSP_AUTH

4.4 L'authentification échoue et l'erreur "KRB Error : KRB5KRB_AP_ERR_MODIFIED" est visible dans les en-têtes HTTP

Problème : L'authentification échoue et une fenêtre de login/mot de passe est demandée par le navigateur et l'erreur.
La valeur KRB5KRB_AP_ERR_MODIFIED est visible dans les entêtes HTTP lorsque vous utilisez Wireshark.

Explication : Le serveur d'application exécutant JCMS/JPlatform & Waffle n'a pas été lancé avec Windows SystemAccount et le ticket kerberos reçu ne peut pas être validé.

Correction : Exécuter le serveur d'application en utilisant le compte système approprié

4.5 L'authentification réussit, mais l'erreur "KRB Error : KRB5KRB_ERR_BADOPTION" est visible dans les en-têtes HTTP

Problème : Tout fonctionne comme prévu, mais l'erreur KRB5KRB_ERR_ERR_BADOPTION est visible dans les en-têtes HTTP en utilisant Wireshark.

Explication : Le compte utilisé pour exécuter le serveur d'application n'a pas les privilèges de délégation appropriés sur l'Active Directory.

Correction : Exécuter le serveur d'application en utilisant le compte système approprié ou accorder le privilège de délégation au compte utilisé

4.6 L'authentification NTLM est utilisée à la place de Kerberos, et l'erreur "KRB Error : KRB5KRB_ERR_S_PRINCIPAL_UNKNOWN" est visible dans les en-têtes HTTP

Problème : L'authentification est réussie, mais l'authentification NTLM est utilisée au lieu de l'authentification Kerberos attendue, et l'erreur "KRB Error : KRB5KRB_ERR_ERR_S_PRINCIPAL_UNKNOWN" est visible dans les en-têtes HTTP en utilisant Wireshark.

Explication : Le nom de domaine du serveur HTTP n'a pas été enregistré dans les hôtes Windows.

Réparer : Exécutez la commande suivante sur la machine Windows hébergeant JCMS/JPlatform :

Setspn -A HTTP/mydomainname.com NetbiosNameOfWindowsServer

Par exemple, si JCMS/JPlatform est hébergé sur une machine Windows dont le nom netbios est COMPANY-WINSERVER123, et est accessible via le nom de domaine intranet.mycompany.com, exécutez cette commande :

Setspn -A HTTP/intranet.mycompany.com COMPANY-WINSERVER123

• Pour la valeur du "service class" :
  Utilisez toujours "HTTP/..." lorsque vous invoquez Setspn, le protocole HTTP et le protocole HTTPS utilisent la classe HTTP service.
• Nom d'hôte :
  Si vous accédez au site Web à l'aide d'un alias (enregistrement ALIAS ou CNAME), assurez-vous d'utiliser le nom principal (enregistrement A) de l'hôte consulté. Plus d'informations sur ce comportement dans Microsoft Knowledge Base article 911149  : http://support.microsoft.com/kb/911149/en-us 

Vous trouverez également des informations utiles dans les articles suivants

• How to use SPNs when you configure Web applications that are hosted on Internet Information Services
• Kerberos Authentication problems - Service Principal Name (SPN) issues - part #1
• Kerberos Authentication problems - Service Principal Name (SPN) issues - part #2
• Kerberos Authentication problems - Service Principal Name (SPN) issues - part #3

4.7 Erreur HTTP "400 bad request" ou "413 request entity too large"

Assurez-vous d'avoir correctement configuré la taille maximale des en-têtes et la taille des paquets de votre serveur d'application et des connecteurs du serveur HTTP, comme expliqué dans la section Installation Configuration côté serveur : Serveur d'application Java et serveur HTTP.

4.8 Comment résoudre les problèmes liés à Kerberos

Lisez les guides suivants et l'article de la base de connaissances Microsoft pour obtenir plus d'informations sur les problèmes liés à Kerberos qui s'appliquent également à l'architecture utilisée par le module Waffle avec un serveur d'application Java : 

• How to troubleshoot Kerberos-related issues on IIS   
• Troubleshooting Kerberos
  
• Troubleshooting Kerberos Delegation

5. Documentation

• Règles d'accès des modules de SSO (aka AccessRules) 
• Waffle library home on GitHub
• La JavaDoc du module Waffle est fourni avec le module, dans le répertoire
• PluginWaffle/plugins/WafflePlugin/docs/javadoc/index.html
• La Javadoc des Access Rule est fourni avec le module, dans le répertoire
  PluginWaffle/plugins/WafflePlugin/docs/javadoc/access-rules/index.html

6. Auteur & Copyright

Ce module a été développé par Jalios en utilisant la librairie Waffle de Daniel Doubrovkine (Eclipse Public License)