Conseils d'identification des incidents de l'intercepteur de relations de confiance SPNEGO (TAI) (déprécié)
Cette liste présente des conseils d'identification et de résolution des problèmes utiles pour diagnostiquer des problèmes et des exceptions survenant dans l'intercepteur de relations de confiance SPNEGO (Simple and Protected GSS-API Negotiation) .

Dans WebSphere Application Server Version 6.1, un TAI (trust association interceptor) qui utilise le mécanisme SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) pour négocier et authentifier en toute sécurité les requêtes HTTP des ressources sécurisées a été ajouté. Dans WebSphere Application Server 7.0, cette fonction est maintenant obsolète. L'authentification Web SPNEGO fournit un rechargement dynamique des filtres SPNEGO et active la rétromigration sur la méthode de connexion d'application.
depfeatTrace | Use |
---|---|
com.ibm.security.jgss.debug | Associez cette propriété personnalisée JVM à la valeur all pour exécuter la fonction de trace via un code JGSS. Des messages apparaissent dans les fichiers trace.log et SystemOut.log. |
com.ibm.security.krb5.Krb5Debug | Associez cette propriété personnalisée JVM à la valeur all pour exécuter la fonction de trace via le code JGSS propre à Kerberos5. Des messages apparaissent dans les fichiers trace.log et SystemOut.log. |
com.ibm.ws.security.spnego.* | Définissez cette trace en utilisant la trace.log. | . Des messages apparaissent dans le fichier
Incident : Les heures affichées par WebSphere Application Server et par le contrôleur de domaine Active Directory ne sont pas synchronisées en 5 minutes.
Symptôme | Action de l'utilisateur |
---|---|
|
Le meilleur moyen de résoudre cet incident consiste à synchroniser l'horloge système de WebSphere Application
Server afin que son décalage de l'horloge système su serveur ne dépasse pas 5 minutes.
Une bonne pratique consiste
à utiliser un serveur d'horloge pour maintenir les systèmes synchronisés.
Vous pouvez également ajouter ou ajuster le paramètre clockskew dans le fichier de configuration Kerberos. Remarque : La valeur par défaut du paramètre clockskew est 300 secondes (ou 5 minutes).
|
Incident : aucune fabrique n'est disponible pour créer un nom pour le mécanisme 1.3.6.1.5.5.2.
Incident | Symptôme | Action de l'utilisateur |
---|---|---|
Obtention d'une exception : aucune fabrique n'est disponible pour créer un nom pour le mécanisme 1.3.6.1.5.5.2. Aucune fabrique n'est disponible pour procéder à la création d'un nom pour le mécanisme spécifique. |
|
Vérifiez que le fichier java.security contient le fournisseur de sécurité
IBMSPNEGO et que celui-ci a été correctement configuré. Le fichier java.security
doit contenir une ligne similaires à :
|
Incident : obtention d'une exception alors que la bibliothèque JGSS tente de traiter le jeton SPNEGO.
Symptôme | Description | Action de l'utilisateur |
---|---|---|
L'erreur suivante s'affiche alors que la bibliothèque JGSS tente
de traiter le jeton SPNEGO.
|
Cette exception est le résultat du codage du ticket au moyen d'une clé
et de la tentative de décodage au moyen d'une autre clé. Cette situation peut être due à plusieurs causes :
|
Si le problème vient du fichier de clés Kerberos, régénérez ce dernier. Si
le problème vient de définitions SPN multiples, supprimez le SPN supplémentaire ou incompatible,
confirmez que le SPN n'est plus connecté à Active Directory,
puis ajoutez le SPN.
Vous pouvez avoir besoin de rechercher dans Active Directory
des entrées avec des SPN définis qui sont en conflit avec le SPN. Pour confirmer que le SPN
n'est pas connecté, la commande :
doit renvoyer la réponse suivante :
|
Incident : absence de connexion unique.
Symptôme | Description | Action de l'utilisateur |
---|---|---|
Lorsque la fonction de trace est activée, le message suivant s'affiche :
|
Le client renvoie une réponse de gestionnaire de réseau local NT (NTLM) à la demande d'authentification
autorisée et non un jeton SPNEGO. Cette situation peut survenir pour l'une des raisons suivantes :
|
Si le SPN n'est pas correctement défini comme HTTP/server.realm.com@REALM.COM avec l'ajout de @REALM.COM, supprimez l'utilisateur, redéfinissez l'utilisateur et redéfinissez le SPN. Si le problème vient du fichier de clés Kerberos, régénérez ce dernier. Si
le problème vient d'une catégorie de plusieurs définitions SPN, supprimez le SPN supplémentaire ou incompatible,
confirmez que le SPN n'est plus connecté à Active Directory,
puis ajoutez le SPN. Dans Active Directory, vous pouvez rechercher d'autres entrées SPN à l'origine
de plusieurs définitions SPN. Les commandes suivantes permettent de déterminer plusieurs
définitions SPN :
|
Incident : la délégation d'accréditation de ne fonctionne pas.
Symptôme | Description | Action de l'utilisateur |
---|---|---|
Une option non valide est détectée. Lorsque la fonction de trace est activée, le message suivant s'affiche :
|
Le fichier de configuration Kerberos n'est pas correctement configuré. | Vérifiez que le paramètre "renewable" ou "proxiable" a été défini à true. |
Incident : impossible de faire fonctionner SSO au moyen du chiffrement RC4-HMAC.
Symptôme | Description | Action de l'utilisateur |
---|---|---|
Examinez le message suivant dans la trace que vous recevez lorsque la
trace est activée :
|
Le chiffrement RC4-HMAC n'est pas pris en charge par une version Microsoft Windows avec un centre
de distribution de clés Kerberos (KDC) antérieur à la version 2003. Pour confirmer cette condition, examinez la trace et identifiez où l'exception est émise. Le contenu du
ticket entrant doit être visible dans la trace. Bien que le ticket entrant soit chiffré,
le SPN de ce service est lisible.
Si une version Microsoft Windows antérieure au KDC 2003 est utilisée et que le système est configuré pour utiliser RC4-HMAC, la chaîne représentant le ticket pour userid@REALM est affichée (au lieu du HTTP/hostname.realm@REALM attendu).
Par exemple, voici le début d'un ticket reçu d'une version Microsoft Windows antérieure au KDC 2003 :
Le domaine est REALM.COM. Le nom de service est userid. Un ticket
correctement formé pour le même SPN est :
|
Pour corriger l'incident, utilisez la norme de chiffrement de données unique (DES) ou Microsoft Windows 2003 Server comme KDC. Pensez à régénérer le SPN et le fichier de clés Kerberos. |
Incident : l'utilisateur reçoit le message suivant lorsqu'il accède à un URL protégé via le SSO SPNEGO.
Symptôme | Description | Action de l'utilisateur |
---|---|---|
Examinez le message suivant :
|
Ce message est généré par le serveur HTTP Apache/IBM. Ce serveur indique que l'en-tête d'autorisation renvoyé par le navigateur de l'utilisateur est trop grand. La chaîne longue qui suit le mot Negotiate (dans le message d'erreur précédent) est le jeton SPNEGO. Le jeton SPNEGO est un encapsuleur du jeton Kerberos Microsoft Windows. Microsoft Windows inclut les informations de certificat d'attribut de privilège de l'utilisateur dans le jeton kerberos. Plus le nombre de groupes de sécurité auxquels l'utilisateur appartient est élevé, plus il y a d'informations de certificat d'attribut de privilège insérées dans les jetons Kerberos et plus le SPNEGO devient grand. IBM HTTP Server 2.0 (ainsi qu'Apache 2.0 et IBM HTTP Server 6.0) limite la taille des en-têtes HTTP acceptables à 8 Ko. Dans les domaines Microsoft Windows contenant de nombreux groupes, et lorsque ces groupes contiennent beaucoup de membres, la taille du jeton SPNEGO d'un utilisateur peut dépasser cette limite de 8 Ko. | Si possible, réduisez le nombre de groupes de sécurité dont l'utilisateur est
membre. Le groupe de correctifs IBM HTTP Server
2.0.47 PK01070 autorise des tailles d'en-tête HTTP supérieures ou égales à la limite
Microsoft de 12K. Les utilisateurs de WebSphere Application Server version 6.0 peuvent obtenir ce correctif dans le groupe de correctifs 6.0.0.2. Remarque : Les serveurs Web non Apache peuvent nécessiter des solutions différentes.
|
Incident : même lorsque la fonction de trace JGSS est désactivée, des messages KRB_DBG_KDC s'affichent dans SystemOut.log.
Symptôme | Description | Action de l'utilisateur |
---|---|---|
Examinez le fichier SystemOut.log et notez que certains messages KRB_DBG_KDC y apparaissent même lorsque la fonction de trace JGSS est désactivée. | Alors que la majorité de la fonction de trace JGSS est contrôlée par la propriété com.ibm.security.jgss.debug, un petit nombre de messages est contrôlé par la propriété com.ibm.security.krb5.Krb5Debug. La propriété com.ibm.security.krb5.Krb5Debug a une valeur par défaut qui place certains messages dans le fichier SystemOut.log. | Pour supprimer tous les messages KRB_DBG_KDC de SystemOut.log,
définissez la propriété JVM comme suit :
|
Incident : une application contient une page d'erreur HTTP 401 personnalisée, la page de réponse HTTP générée par le TAI SPNEGO ne s'affiche pas dans un navigateur.
Symptôme | Description | Action de l'utilisateur |
---|---|---|
Lorsqu'une application contient une page d'erreur HTTP 401 personnalisée, la page de réponse HTTP générée par le TAI (Trust Association Interceptor) SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) ne s'affiche pas dans un navigateur. | Lorsqu'une application contient une page d'erreur HTTP 401 personnalisée, la page de réponse HTTP générée par le TAI SPNEGO ne s'affiche pas dans un navigateur. A la place, la page d'erreur HTTP 401 s'affiche. | Vous pouvez personnaliser votre page HTTP 401 afin d'inclure les informations concernant la façon de configurer votre navigateur pour l'utilisation de SPNEGO. Pour plus d'informations, voir Configuration du navigateur client pour utiliser l'intercepteur TAI SPNEGO (déprécié) et Configuration des propriétés personnalisées TAI SPNEGO (déprécié). |
Incident : les paramètres Post HTTP sont perdus lors de l'interaction avec le TAI SPNEGO au moment du passage de la connexion ID utilisateur/mot de passe.
Symptôme | Description | Action de l'utilisateur |
---|---|---|
Les paramètres HTTP Post sont perdus lors de l'interaction avec le TAI
SPNEGO, lors du passage à la connexion ID_utilisateur/mot de passe. "Passage de la connexion ID utilisateur/mot de passe" signifie que Microsoft Internet Explorer tente de répondre initialement avec un jeton SPNEGO. Si cette réponse échoue, Microsoft Internet Explorer tente de répondre avec un jeton NTLM obtenu via une requête d'authentification ID utilisateur/mot de passe. |
Microsoft Internet Explorer conserve l'état lors de la requête de l'utilisateur. Si une requête a reçu comme réponse "HTTP 401 Authenticate Negotiate",
et que le navigateur répond avec un jeton NTLM obtenu via une demande d'authentification ID utilisateur/mot de passe,
le navigateur soumet à nouveau la requête. Si cette seconde demande reçoit en réponse une page HTML contenant une redirection vers la même URL, mais avec de nouveaux arguments (via Javascript), le navigateur ne soumet pas à nouveau les paramètres POST. Remarque : Pour éviter cet incident, il est essentiel de NE PAS effectuer de réacheminement automatique. Si l'utilisateur clique sur un lien, le problème ne se produit pas.
|
Le navigateur répond à la demande d'authentification Authenticate/Negotiate par un jeton NTLM et non un jeton SPNEGO. Le TAI SPNEGO voit le NTLM et renvoie une réponse HTTP 403 accompagnée de la page HTML. Lorsque le navigateur exécute la fonction JavaScript redirTimer, les éventuels paramètres POST ou GET qui étaient présents dans la demande originale sont perdus. Lorsque la propriété SPN<id>.NTLMTokenReceivedPage est utilisée, une page de message appropriée peut être renvoyée à l'utilisateur. Le message par défaut
renvoyé (en l'absence de propriété d'utilisateur définie) est le suivant :
Grâce à la propriété SPN<id>.NTLMTokenReceivedPage, vous pouvez personnaliser la réponse. Il est essentiel que le HTML renvoyé n'effectue pas de réacheminement. Lorsque le TAI SPNEGO a été configuré pour utiliser la classe HTTPHeaderFilter transmise par défaut comme SPN<id>.filterClass, le SPN<id>.filter peut être utilisé pour permettre à la deuxième requête d'être transmise directement au mécanisme de sécurité WebSphere Application Server normal. De cette façon, l'utilisateur est confronté au mécanisme d'authentification normal. Voici
l'exemple d'une telle configuration : Les propriétés TAI SPNEGO nécessaires
et le contenu du fichier HTML sont présentés.
Remarque : Notez que la propriété de filtre ordonne au TAI SPNEGO de
NE PAS intercepter les demandes HTTP contenant la chaîne "noSPNEGO".
Voici
un exemple de génération de réponse utile.
|
Problème : l'intercepteur d'association de confiance (TAI) n'appelle pas la méthode initialize(Properties).
La trace peut indiquer que le TAI est chargé mais que la méthode initialize(Properties) n'est pas appelée. Seule la méthode getVersion() semble être appelée au démarrage.
Le processus de l'intercepteur d'association de confiance de WebSphere appelle uniquement initialize(Properties) lorsque des propriétés personnalisées sont définies pour l'intercepteur d'association de confiance.
Pour corriger ce problème, définissez une propriété personnalisée inutilisée du TAI, par exemple com.ibm.issw.spnegoTAI.NumberOfServers=0.
Problème : l'intercepteur d'association de confiance (TAI) ne se charge pas correctement.
SPNEGO014: Kerberos initialization Failure: org.ietf.jgss.GSSException, major code: 13, minor code: 0
major string: Invalid credentials
minor string: SubjectKeyFinder: no JAAS Subject
at com.ibm.security.jgss.i18n.I18NException.throwGSSException(I18NException.java:12)
…
Il est possible que la propriété personnalisée JVM javax.security.auth.useSubjectCredsOnly n'ait pas pour valeur false.
Pour remédier à ce problème, définissez une propriété personnalisée JVM sur chaque JVM qui est activée pour l'intercepteur de relations de confiance, javax.security.auth.useSubjectCredsOnly=false.
Problème: les caractères par défaut des scripts JACL permettant d'ajouter les paramètres de l'intercepteur d'association de confiance (TAI) peuvent causer des incidents.
Les scripts JACL servant à ajouter les paramètres du TAI acceptent les paramètres positionnels. Pour accepter les valeurs par défaut, un "." doit être spécifié. L'ajout d'un point (".") sur certaines plateformes WebSphere peut entraîner l'ajout de la propriété avec la valeur ".".
Vérifiez toujours à l'aide de la console d'administration (quelque soit la plateforme) que les propriétés ajoutées sont conformes aux attentes. Si tel n'est pas le cas, corrigez-les manuellement.