Conseils pour l'identification et la résolution des incidents liés à SPNEGO

Vous pouvez négocier et authentifier en toute sécurité les requêtes HTTP pour les ressources sécurisées dans WebSphere Application Server à l'aide de SPNEGO (Simple and Protected GSS-API Negotiation Mechanism). Des problèmes peuvent se produire quand vous utilisez SPNEGO comme méthode d'authentification Web pour WebSphere Application Server.

Incidents de SPNEGO et solutions possibles

Remarque : Cette rubrique fait référence à un ou plusieurs des fichiers journaux de serveur d'applications. Il est recommandé de configurer le serveur de telle sorte qu'il utilise l'infrastructure de journalisation et de trace HPEL (High Performance Extensible Logging) à la place des fichiers SystemOut.log, SystemErr.log, trace.log et activity.log sur les systèmes distribués et IBM® i. Vous pouvez également utiliser HPEL conjointement avec vos fonctions de journalisation z/OS natives. Si vous utilisez l'infrastructure HPEL, vous pouvez accéder à toutes les informations de journalisation et de trace en utilisant l'outil de ligne de commande LogViewer à partir de votre répertoire bin de profil de serveur. Pour plus d'informations sur l'utilisation de HPEL, voir les informations sur l'utilisation de HPEL en vue du traitement des incidents liés aux applications.
Vous pouvez être confronté aux problèmes suivants quand vous utilisez SPNEGO comme service d'authentification Web pour WebSphere Application Server. Des solutions solutions sont fournies.

Impossible de résoudre le nom du principal Kerberos

Si vous n'arrivez pas à résoudre le nom du principal Kerberos, comme dans l'exemple de trace suivant :

[11/11/03 1:42:29:795 EST] 1d01b21e GetKrbToken   > Negotiation (GSS): Begin handshake
[11/11/03 1:42:29:795 EST] 1d01b21e Context       > GSS Context init, servername:HTTP@johnwang5.jwcmd.com
[11/11/03 1:42:29:866 EST] 1d01b21e TraceNLS      u No message text associated with key Error.getting.the.Token,
.GSS.Exception:org.ietf.jgss.GSSException,.major.code:.13,.minor.code:.0
	major.string:.Invalid.credentials
	minor.string:.Cannot.get.credential.from.JAAS.Subject.for.principal:.HTTP/192.168.0.4@168.0.4 in bundle 
com.ibm.ejs.resources.security
[11/11/03 1:42:29:866 EST] 1d01b21e GetKrbToken   E Error getting the Token, GSS Exception:org.ietf.jgss.GSSException, 
major code: 13, minor code: 0
	major string: Invalid credentials
	minor string: Cannot get credential from JAAS Subject for principal: HTTP/192.168.0.4@168.0.4
[11/11/03 1:42:29:876 EST] 1d01b21e TraceNLS      u No message text associated with key SpnegoTAI.exits.due.to.an.exception. 
in bundle com.ibm.ejs.resources.security
[11/11/03 1:42:29:876 EST] 1d01b21e SpnegoTAI     E SpnegoTAI exits due to an exception. 

ajoutez l'adresse IP du serveur dans son fichier hôte. Vous devez également recycler le serveur d'applications pour charger le nouveau fichier hôte.

L'heure de WebSphere Application Server et celle du contrôleur de domaine Active Directory (AD) diffèrent de plus de 5 minutes.

Dans ce cas de figure, le fichier trace.log contient les données qui suivent :
[11/11/03 1:44:09:499 EST] 1d01b21e GetKrbToken   > Negotiation (GSS): Begin handshake
[11/11/03 1:44:09:499 EST] 1d01b21e Context       > GSS Context init, servername:HTTP@backendrc4.ibm.net
[11/11/03 1:44:09:499 EST] 1d01b21e Context       > GSS Context init, done.
[11/11/03 1:44:09:679 EST] 1d01b21e SpnegoTAI     > Server response token as follows...
0000:  6082014f 06062b06 01050502 a1820143     `?.O..+.....¡?.C
0010:  3082013f a0030a01 01a10b06 092a8648     0?.? ....¡...*?H
0020:  82f71201 0202a282 01290482 01256082     ?÷....¢?.).?.%`?
0030:  01210609 2a864886 f7120102 0203007e     .!..*?H?÷......~
0040:  82011030 82010ca0 03020105 a1030201     ?..0?.. ....¡...
0050:  1ea41118 0f323030 33313131 31303634     .¤...20031111064
0060:  3430395a a5050203 0a3548a6 03020125     409Z¥....5H¦...%
0070:  a90b1b09 4a57434d 442e434f 4daa2630     ©.....IBM.NETª&0
0080:  24a00302 0100a11d 301b1b04 48545450     $ ....¡.0...HTTP
0090:  1b136a6f 686e7761 6e67352e 6a77636d     ..backendrc4.ibm
00a0:  642e636f 6dab81ab 1b81a86f 72672e69     .net.«?«.?¨org.i
00b0:  6574662e 6a677373 2e475353 45786365     etf.jgss.GSSExce
00c0:  7074696f 6e2c206d 616a6f72 20636f64     ption, major cod
00d0:  653a2031 302c206d 696e6f72 20636f64     e: 10, minor cod
00e0:  653a2033 370a096d 616a6f72 20737472     e: 37..major str
00f0:  696e673a 20446566 65637469 76652074     ing: Defective t
0100:  6f6b656e 0a096d69 6e6f7220 73747269     oken..minor stri
0110:  6e673a20 436c6965 6e742074 696d6520     ng: Client time 
0120:  54756573 6461792c 204e6f76 656d6265     Tuesday, Novembe
0130:  72203131 2c203230 30332061 7420313a     r 11, 2003 at 1:
0140:  33353a30 3120414d 20746f6f 20736b65     35:01 AM too ske
0150:  776564                                  wed

Ce problème peut être résolu de deux manières. Le meilleur moyen de résoudre cet incident est de synchroniser l'heure système de WebSphere Application Server avec celle du serveur Active Directory pour ramener l'écart à moins de 5 minutes. Une bonne pratique consiste à utiliser un serveur d'horloge pour maintenir tous les systèmes synchronisés. Vous pouvez également ajouter ou régler le paramètre clockskew dans le fichier de configuration de Kerberos. Notez que la valeur par défaut est de 300 secondes (5 minutes).

Aucune fabrique n'est disponible pour créer un nom pour le mécanisme 1.3.6.1.5.5.2.

Si le fichier systemout.log contient une exception semblable à la suivante :
[4/8/05 22:51:24:542 EDT] 5003e481 SystemOut     O [JGSS_DBG_PROV] Provider IBMJGSSProvider version 1.01 
does not support mech 1.3.6.1.5.5.2
[4/8/05 22:51:24:582 EDT] 5003e481 ServerCredent E com.ibm.issw.spnegoTAI.ServerCredential initialize() SPNEGO014: 
Kerberos initialization Failure: org.ietf.jgss.GSSException, major code: 2, minor code: 0
	major string: Mécanisme non pris en charge
	minor string: Aucune fabrique n'est disponible pour créer un nom pour le mécanisme 1.3.6.1.5.5.2
	at com.ibm.security.jgss.i18n.I18NException.throwGSSException(I18NException.java:30)
	at com.ibm.security.jgss.GSSManagerImpl.a(GSSManagerImpl.java:36)
	at com.ibm.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:217)
	at com.ibm.security.jgss.GSSCredentialImpl.<init>(GSSCredentialImpl.java:264) 
.
. 
Assurez-vous que le fichier java.security contient le fournisseur de sécurité IBMSPNEGO et qu'il est correctement défini. Il doit contenir une ligne similaire à la suivante :
security.provider.6=com.ibm.security.jgss.mech.spnego.IBMSPNEGO

Réception d'une erreur Kerberos pendant le décodage et la vérification du jeton SPNEGO

Vous risquez de recevoir l'exception suivante pendant que la bibliothèque JGSS (Java™ Generic Security Service) tente de traiter le jeton SPNEGO :
Erreur d'authentification de la requête. Génération de rapports au client
Major code = 11, Minor code = 31
org.ietf.jgss.GSSException, major code: 11, minor code: 31
	major string: Incident général, non défini au niveau GSSAPI
	minor string: Erreur Kerberos lors du décodage et de la vérification du jeton :  com.ibm.security.krb5.internal.KrbException, code d'état : 31
	message: Contrôle d'intégrité sur la zone déchiffrée ayant échoué
Cette erreur se produit quand le ticket est codé avec une clé et que son décodage s'effectue avec une autre clé. Il existe de nombreuses causes possibles à cette situation :
  • Le fichier de clés n'a pas été copié sur la machine du serveur après sa régénération.
  • La configuration de Kerberos pointe vers un fichier de clés incorrect.
  • Le SPN a été défini plusieurs fois dans Active Directory. Ceci arrive quand un autre ID utilisateur est défini avec le même SPN (ou avec le même nom mais avec un port défini comme faisant partie du SPN).
  • Si le chiffrement utilisé est du type DES, le mot de passe associé à l'ID utilisateur du service peut être valable uniquement pour le chiffrement RC4-HMAC. Ceci arrive quand un nouvel ID utilisateur est créé, que le SPN est défini et que le fichier de clés est généré avec l'option +DesOnly. Le ticket de service généré pour ce SPN est chiffré avec un secret qui ne correspond pas à celui que contient le fichier de clés.
  • Une ancienne version de l'outil Microsoft ktpass a été utilisée. Les anciennes versions de cet outil créent des fichiers de clés incorrects qui peuvent causer cette erreur. Si vous utilisez Windows Server 2003 comme contrôleur de domaine, utilisez la version de ktpass.exe contenue dans Windows Server 2003 SP 2 (précisément la version 5.2.3790.2825).

Si le problème réside au niveau du fichier de clés, corrigez-le. Si le problème est lié à des définitions de SPN multiples, supprimez les SPN surnuméraires ou problématiques, vérifiez que le SPN n'est plus enregistré dans Active Directory puis enregistrez-le à nouveau. Pour plus d'informations, voir Création d'un nom de principal de service Kerberos et d'un fichier de clés. Vous pouvez avoir besoin d'utiliser un navigateur LDAP pour rechercher dans Active Directory d'autres entrées de SPN qui sont en conflit avec le SPN.

Pour confirmer que le SPN n'est pas enregistré, la commande :
setspn –l userid
doit renvoyer le message suivant :
Impossible de trouver l'ID utilisateur de compte

Si l'ID utilisateur et le fichier de clés sont définis pour le système DES-CBC-MD5, après avoir créé l'ID utilisateur, modifiez le mot de passe associé puis créez le fichier de clés. Si vous utilisez Windows Server 2003, installez la dernière version de ktpass.

SSO ne fonctionne pas

Quand la trace est activée, le message d'erreur suivant peut apparaître :
Le client a renvoyé un en-tête d'authentification étranger à SPNEGO. Fin de SpnegoTAI
L'une des causes possibles de cette erreur est que le client renvoie une réponse du gestionnaire de réseau local NT (NTLM) suite à la question d'autorisation, au lieu d'un jeton SPNEGO. Cet incident peut avoir plusieurs causes :
  • Le client n'est pas correctement configuré.
  • Le client n'utilise pas un navigateur pris en charge. Par exemple, les utilisateurs d'Internet Explorer 5.5 SP1 répondent avec un en-tête d'authentification étranger à SPNEGO.
  • L'utilisateur ne s'est pas connecté au domaine Active Directory ou à un domaine sécurisé, ou le client utilisé ne prend pas en charge l'authentification intégrée à Windows. Dans ce cas, l'intercepteur d'association de confiance (TAI) fonctionne correctement.
  • L'utilisateur accède à un service défini sur la machine sur laquelle le client est exécuté (l'hôte local). Internet Explorer résout le nom d'hôte de l'URL par http://localhost<URL> à la place du nom qualifié complet qui est fourni.
  • Il est impossible de trouve le SPN dans Active Directory. Le SPN doit respecter le format HTTP/server.realm.com. Pour ajouter le SPN, entrez la commande suivante :
    setspn –a HTTP/server.realm.com userid

    Si le SPN n'est pas correctement défini sous forme de HTTP/server.realm.com@REALM.COM avec l'ajout de @REALM.COM, supprimez l'utilisateur, redéfinissez l'utilisateur puis redéfinissez le SPN.

  • Le nom d'hôte est résolu par un alias de DNS au lieu d'un enregistrement HOST. Remplacez le nom d'hôte par un enregistrement HOST.
  • Le compte Active Directory qui contient le nom principal du service se trouve dans un domaine Active Directory distant de celui auquel l'utilisateur s'est connecté et ces domaines ne sont pas des domaines Windows 2003. Migrez ces domaines vers Windows 2003, ou limitez SSO aux utilisateurs d'un même domaine avec l'ID utilisateur correspondant au nom principal du service.

Impossible d'utiliser SSO avec la méthode de chiffrement RC4-HMAC

Quand la trace est activée, le message d'erreur suivant peut apparaître :
com.ibm.security.krb5.internal.crypto.KrbCryptoException, status code: 0
message: Erreur d'intégrité ; la somme de contrôle reçue ne correspond pas à la somme de contrôle calculée
Les causes possibles de cet incident sont les suivantes :
  • La méthode de chiffrement RC4-HMAC n'est pas prise en charge par les centres de distribution de clés (KDC) Windows d'une version antérieure à 2003. Dans ce cas de figure, examinez la trace précédente et recherchez où l'exception a été consignée. Le contenu du ticket entrant doit être visible dans la trace. Bien qu'il soit chiffré, le nom SPN du service est lisible. Si vous utilisez un KDC Windows dont la version est antérieure à 2003 et que le système est configuré pour utiliser RC4-HMAC, la chaîne qui représente le ticket pour userid@REALM à la place du code HTTP/hostname.realm@REALM attendu s'affiche. Par exemple, voici le début du ticket reçu d'un KDC Windows d'une version antérieure à 2003 :
    0000: 01 00 6e 82 04 7f 30 82  04 7b a0 03 02 01 05 a1  ..n...0.........
    0010: 03 02 01 0e a2 07 03 05  00 20 00 00 00 a3 82 03  ................
    0020: a5 61 82 03 a1 30 82 03  9d a0 03 02 01 05 a1 0a  .a...0..........
    0030: 1b 08 45 50 46 44 2e 4e  45 54 a2 18 30 16 a0 03  ...REALM.COM.0..
    0040: 02 01 01 a1 0f 30 0d 1b  0b 65 70 66 64 77 61 73  .....0...userid
    0050: 75 6e 69 74 a3 82 03 6e  30 82 03 6a a0 03 02 01  .a.f...n0..j....
    Le domaine est REALM.COM. Le nom de service est userid. Un ticket correctement formé pour le même SPN est :
    0000: 01 00 6e 82 04 56 30 82  04 52 a0 03 02 01 05 a1  ..n..V0..R......
    0010: 03 02 01 0e a2 07 03 05  00 20 00 00 00 a3 82 03  ................
    0020: 82 61 82 03 7e 30 82 03  7a a0 03 02 01 05 a1 0a  .a...0..z.......
    0030: 1b 08 45 50 46 44 2e 4e  45 54 a2 2a 30 28 a0 03  ..REALM.COM.0...
    0040: 02 01 02 a1 21 30 1f 1b  04 48 54 54 50 1b 17 75  .....0...HTTP..u
    0050: 73 31 30 6b 65 70 66 77  61 73 73 30 31 2e 65 70  serid.realm.com.
    0060: 66 64 2e 6e 65 74 a3 82  03 39 30 82 03 35 a0 03  ...n.....90..5..

    Pour corriger le problème, utilisez la méthode de chiffrement SDES ou utilisez un KDC Windows Server 2003. Pensez à régénérer le SPN et le fichier de clés.

  • La méthode de chiffrement RC-HMAC ne fonctionne pas quand vous utilisez la délégation de droit d'accès. Pour savoir si vous avez ce problème, activez la trace Krb5 et JGSS. Si le nom du SPN est correct, des messages du type suivant peuvent apparaître :
    [JGSS_DBG_CTX] Le ticket a été déchiffré.
    [JGSS_DBG_CTX] Données d'autorisation mises en cache
    [JGSS_DBG_CTX] Type de clé de session = rc4-hmac
    …
    [JGSS_DBG_CTX] L'authentificateur a été déchiffré.
    [JGSS_DBG_CTX] Erreur d'authentification de la requête. Génération de rapports au client
    …
    Major code = 11, Minor code = 0
    org.ietf.jgss.GSSException, major code: 11, minor code: 0
    	major string: Incident général, non défini au niveau GSSAPI
    	minor string: Erreur de Kerberos pendant la conversion de KRBCred : com.ibm.security.krb5.internal.crypto.KrbCryptoException, code d'état : 0
    	message: Erreur d'intégrité ; la somme de contrôle reçue ne correspond pas à la somme de contrôle calculée

    Ceci indique que les données d'identification déléguées contenues dans le jeton SPNEGO n'étaient pas chiffrées avec la clé appropriée.

    Téléchargez et installez l'APAR IY76826. Ce programme va remplacer ibmjgssprovider.jar par une version qui peut accepter les données d'identification déléguées chiffrées par RC4 et définies par Microsoft.

  • Le mot de passe utilisé pour régénérer le fichier de clés avec ktpass est différent du mot de passe affecté au compte du service. Quand le mot de passe est modifié, vous devez régénérer et redistribuer les clés, même en cas de réinitialisation avec le même mot de passe.
    De plus, l'utilitaire ktpass peut générer un fichier de clés avec un autre mot de passe, comme dans les cas suivants :
    • Si le mot de passe indiqué à ktpass est identique à celui du compte du service, le fichier de clés généré ne fonctionne pas.
    • Si le mot de passe indiqué à ktpass est différent de celui du compte du service et qu'il contient moins de 7 caractères, ktpass s'arrête et ne génère pas le fichier de clés.
    • Si le mot de passe indiqué à ktpass est différent de celui du compte du service et qu'il contient plus de 6 caractères, ktpass ne s'arrête pas. Il génère un fichier de clés qui contient une clé incorrecte. Si vous utilisez cette clé pour déchiffrer un jeton SPNEGO, l'erreur d'intégrité indiquée précédemment se produit.

    Indiquez un mot de passe non nul pour le compte du service puis utilisez ce mot de passe pour appeler l'outil ktpass.

  • L'outil ktpass version 1830 (dans Support Tools SP1) peut produire cette erreur dans certains environnements de serveur Windows 2003. Utilisez la version de ktpass fournie dans le Service Pack 2 pour éviter cette erreur.

    Utilisez la version de ktpass fournie dans Support Tools SP2 pour créer le fichier de clés.

Non-fonctionnement de la délégation de droits d'accès causé par une option incorrecte dans la demande de ticket

Quand la trace est activée, si le message d'erreur suivant apparaît :
com.ibm.security.krb5.KrbException, code d'état : 101, message : option incorrecte dans la demande de ticket

cela signifie que le fichier de configuration de Kerberos est mal défini. Vérifiez que les paramètres "renewable" et "proxiable" n'ont pas la valeur true.

Incidents en cas d'accès à une URL protégée via une connexion SSO SPNEGO

Vous risquez de recevoir le message d'erreur suivant lorsque vous tentez d'accéder à une URL protégée via une connexion SSO SPNEGO :
Mauvaise requête

Votre navigateur a envoyé une requête que ce serveur ne peut pas comprendre.
La taille de la zone d'en-tête de requête dépasse la limite du serveur.

Authorization: Negotiate YII……

Ce message est généré par le serveur HTTP Apache/IBM. Il indique que l'en-tête d'autorisation renvoyé par votre navigateur est trop long. La chaîne qui suit le mot "Negotiate" correspond au jeton SPNEGO. Ce jeton SPNEGO est un encapsuleur du jeton Kerberos de Windows. Windows encapsule les données du certificat d'attribut de privilège (PAC) de l'utilisateur dans le jeton Kerberos. Plus l'utilisateur est affilié à des groupes de sécurité, plus il existe de données de PAC dans le jeton Kerberos et plus le jeton SPNEGO devient volumineux. IBM HTTP Server 2.0 (ainsi que Apache 2.0 et IBM HTTP Server 6.0) limite la taille des en-têtes HTTP à 8 Ko. Dans les domaines Windows contenant de nombreux groupes, et quand 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 12 Ko.

Après avoir installé le correctif, vous devez spécifier le paramètre LimitRequestFieldSize dans le fichier httpd.conf afin d'augmenter la taille admise pour les en-têtes par rapport à la valeur par défaut de 8192 octets.

Apparition de messages KRB_DBG_KDC dans SystemOut.log alors que la trace JGSS est désactivée

Bien que la fonction de trace de JGSS soit majoritairement contrôlée par la propriété com.ibm.security.jgss.debug, un petit nombre de messages sont contrôlés par la propriété com.ibm.security.krb5.Krb5Debug. Par défaut, la propriété krb5 enregistre des messages dans le fichier SystemOut.log.

Pour supprimer tous les messages KRB_DBG_KDC du fichier SystemOut.log, affectez à la propriété de la machine virtuelle Java la valeur -Dcom.ibm.security.krb5.Krb5Debug=none.

ktpass ne trouve pas l'ID utilisateur

Quand vous utilisez ktpass, vous risquez de recevoir un message d'erreur comme le suivant :
DsCrackNames a renvoyé 0x2 dans l'entrée de nom pour server3
Impossible d'obtenir le domaine cible pour l'utilisateur indiqué.

Dans une forêt Active Directory, la recherche d'ID utilisateur utilisée par le fichier ktpass.exe ne connaît pas le nom de domaine par défaut à utiliser. Ceci arrive uniquement quand le contrôleur de domaine est dans une forêt.

Pour corriger ce problème, au lieu d'indiquer l'option -mapUser userid, utilisez plutôt l'option -mapUser userid@domain. Par exemple, indiquez –mapUser server3@WIBM.NET.

La délégation de droit d'accès ne fonctionne avec aucun ID utilisateur

Si vous voyez dans le fichier trace.log une exception comme la suivante :
> com.ibm.issw.spnegoTAI.Context getDelegateCred() Entry
d com.ibm.issw.spnegoTAI.Context getDelegateCred() impossible d'obtenir les données d'identification déléguées
< com.ibm.issw.spnegoTAI.Context getDelegateCred() Exit
W com.ibm.issw.spnegoTAI.SpnegoHandler handleRequest() SPNEGO021: Pas de données d'identification déléguées pour l'utilisateur nauser@NA.IBM.NET

cela signifie que la propriété "Le compte est sécurisé pour la délégation" n'est pas activée pour le compte de domaine auquel le SPN est attaché.

Pour corriger ce problème, activez cette propriété pour le compte de domaine.

Une question d'authentification est posée à un utilisateur alors que le navigateur est bien configuré

Une question d'authentification peut être posée à un utilisateur même lorsque le navigateur est configuré pour l'éviter. L'intercepteur d'association de confiance peut avoir obtenu les données d'identification de l'utilisateur à partir du jeton SPNEGO et l'utilisateur n'a pas réussi à se connecter. Dans le fichier trace.log, une exception comme la suivante peut apparaître alors :
< com.ibm.issw.spnegoTAI.SpnegoTAI getAuthenticatedUsername(): lansche Exit
d com.ibm.issw.spnegoTAI.SpnegoTAI negotiateValidateandEstablishTrust(): Fin de l'échange de protocoles, envoi de 200 :SC_OK
< com.ibm.issw.spnegoTAI.SpnegoTAI negotiateAndValidateEstablishedTrust Exit
A SECJ0222E: Une exception inattendue s'est produite lors de la création du contexte de connexion. L'alias du module de connexion est system.WEB_INBOUND 
et l'exception est...
L'ID utilisateur (lansche dans l'exemple précédent) n'existe pas dans le registre utilisé par WebSphere. Cet incident se produit quand :
  • Le registre utilisé par WebSphere n'est pas l'annuaire LDAP du domaine Active Directory ou le catalogue global mais un registre virtuel (par exemple un registre d'utilisateurs personnalisé basé sur un fichier).
  • Une implémentation personnalisée de IClientToServerUseridMapper modifie le nom d'utilisateur de telle manière que le nom auquel il est mappé n'existe pas dans le registre.
  • L'attribut mappé par la propriété de filtre utilisateur LDAP de WebSphere est incorrect.

Pour corriger ce problème, vérifiez que l'utilisateur qui est vérifié dans WebSphere Application Server par le TAI correspond au registre configuré de WebSphere.

Un utilisateur du client Novell ne parvient pas à s'authentifier avec SPNEGO

Si un utilisateur du client Novell ne parvient pas à s'authentifier avec SPNEGO, il peut recevoir un message "Un jeton NTLM a été reçu" .

L'utilisateur s'est connecté au client Novell mais n'a pas effectué de connexion Kerberos pour Windows (ceci peut se vérifier avec l'utilitaire Kerbtray). Si un utilisateur s'est connecté au domaine Windows et qu'il possède un ticket Kerberos, il ne peut pas utiliser l'authentification SPNEGO.

Pour corriger ce problème, supprimez le client Novell et utilisez la méthode de connexion au domaine Windows par défaut.

Des problèmes d'authentification SPNEGO se produisent en cas d'accès à des sites SPNEGO via des serveurs proxy avec mémoire cache

Si vous tentez d'accéder à des sites SPNEGO via des serveurs proxy avec mémoire cache, l'authentification SPNEGO risque d'échouer. Le message suivant s'affiche alors : "L'authentification SPNEGO n'est pas prise en charge sur ce client".

Il est possible que le serveur relais avec antémémoire change le nom d'hôte renvoyé dans la réponse HTTP 401 de négociation de l'authentification.

Si vous rencontrez ce problème, prenez contact avec le fournisseur du serveur relais pour rechercher une solution.

Les logiciels de réseau privé virtuel et les pare-feux interfèrent avec les opérations de SPNEGO

Dans certaines situations, les logiciels de réseau privé virtuel et les pare-feux interfèrent avec les opérations de SPNEGO.

Pour corriger ces problèmes, prenez contact avec les fournisseurs de ces produits pour modifier leur configuration de manière appropriée.

Incident avec le navigateur en cas d'accès à une application protégée par SPNEGO

Un incident peut se produire dans votre navigateur quand vous vous connectez à une machine d'un domaine avec un mot de passe donné (par exemple, passwordA), et que vous vous connectez ensuite à une autre machine du même domaine avec un autre mot de passe (par exemple, passwordB).

Quand vous revenez à la première machine, vous n'obtenez pas de réponse de SPNEGO/Kerberos ou de NTLM suite à la question d'authentification. Après deux tentatives, le navigateur affiche un message d'erreur HTTP 404.

Pour corriger ce problème, déconnectez-vous de la première machine du domaine puis reconnectez-vous en utilisant le mot de passe modifié (passwordB).

Incident avec le navigateur Internet Explorer 6.0

Quand WebSphere Application Server est configuré avec SPNEGO et que le basculement est activé pour les requêtes, Internet Explorer 6.0 n'arrive pas à se connecter aux page de connexion par formulaire.

Pour éviter cette situation, effectuez l'une des opérations suivantes :
  • A partir du panneau Sécurité globale > Authentification Web SPNEGO, désélectionnez l'option Autoriser l'utilisation du mécanisme d'authentification de l'application si ell est sélectionnée.
  • Effectuez une mise à niveau vers Internet Explorer version 7.0
  • Configurez Internet Explorer version 6.0 pour l'utilisation d'une page d'authentification différente. Le problème est lié à l'authentification de base et aux préférences d'authentification de connexion du formulaire.

Les pages d'erreur définies pour les propriétés NTLMTokenReceivedPage ou SpnegoNotSupportedPage se chargent à partir d'une URL de type http://

Les pages d'erreur définies pour les propriétés NTLMTokenReceivedPage ou SpnegoNotSupportedPage se chargent à partir d'une URL de type http://. Le message de trace suivant peut apparaître dans ce cas :
Impossible de charger le contenu SPNEGO non pris en charge. Le contenu par défaut sera affiché. 
Exception reçue : java.net.ProtocolException: Le serveur a été redirigé de manière excessive (20 fois).

Ce problème survient quand le fichier chargé exécute une redirection automatique. Il est impossible de charger un fichier à partir d'un serveur Web et d'utiliser simultanément une redirection automatique.

Pour corriger ce problème, chargez le contenu à partir d'une URL de type "file:///" et non pas d'une URL de type "http://".

La tentative de connexion unique (SSO) d'un navigateur client ne peut pas être authentifié

L'authentification d'une tentative de connexion unique de navigateur (SSO) échoue avec WebSphere Application Server lorsque vous utilisez un jeton SPNEGO avec Microsoft Internet Security Acceleration Server

Lorsque la fonction de trace est activée, les messages suivants s'affichent :
com.ibm.ws.security.spnego.SpnegoHandler isAuthHeaderNotSPNEGO 
ENTRY Negotiate                                                  
com.ibm.ws.security.spnego.SpnegoHandler isAuthHeaderNotSPNEGO 
Le client a renvoyé un en-tête d'authentification étranger à SPNEGO

S'il existe un Microsoft Internet Security Acceleration Server (ISA) entre un navigateur client et WebSphere Application Server, ISA peut intercepter l'en-tête d'authentification SPNEGO provenant de la requête du navigateur client. ISA convertit l'ID objet SPNEGO (OID) en OID Kerberos. La tentative d'authentification avec WebSphere Application Server échoue car l'OID SPNEGO a été converti et est désormais manquant.

Pour plus d'informations sur le mode de résolution de ce problème, voir la rubrique "Les utilisateurs ne peuvent pas accéder à un site Web publié sur ISA Server 2006 si le site Web accepte uniquement le module d'authentification SPNEGO" du site Microsoft Corporation Support.

Microsoft Windows version 7 et Internet Explorer version 8 désactivent le type de chiffrement DES par défaut.

Si vous utilisez Microsoft Windows version 7 avec Internet Explorer version 8 et que vous n'arrivez pas à faire fonctionner la connexion unique (SSO) SPNEGO, cela vient peut-être du fait que Windows version 7 a désactivé le type de chiffrement DES pour Kerberos par défaut. Quand la trace est activée, le message suivant s'affiche :
Le client a renvoyé un en-tête d'authentification étranger à SPNEGO....

Il est conseillé de modifier le type de chiffrement RC4-HMAC en AES. Toutefois, si vous souhaitez toujours utiliser le type de chiffrement DES, vous devez consulter la documentation Windows 7 pour obtenir de l'aide sur l'activation du type de chiffrement DES.

L'exemple suivant montre comment modifier le type de chiffrement DES en RC4 :

  1. Vérifiez que la case Utiliser le type de chiffrement DES pour ce compte n'est pas cochée pour le compte Microsoft Active Directory que vous utilisez pour la mise en correspondance vers le SPN. Sur le poste Microsoft Active Directory :
    1. Cliquez sur Démarrer- > Programmes->Outils d'administration > Utilisateurs et ordinateurs Active Directory > Utilisateurs.
    2. Cliquez sur le compte Microsoft Active Directory que vous utilisez pour la mise en correspondance avec le SPN.
    3. Sélectionnez le compte, puis vérifiez que la case Utiliser le type de chiffrement DES pour ce compte n'est pas cochée.
  2. Réinitialisez le mot de passe du compte Microsoft Active Directory que vous utilisez pour la mise en correspondance avec le SPN. Vous pouvez redéfinir le même mot de passe.
  3. Regénérez le fichier de clés avec le type de chiffrement RC4.
  4. Copiez le nouveau fichier de clés sur les serveurs WebSphere Application Server.
  5. Mettez à jour les fichiers de configuration Kerberos (krb5.ini/krb5.conf) pour que RC4 soit répertorié en premier pour les attributs default_tkt_enctypes et default_tgs_enctypes.
    Par exemple :
    default_tkt_enctypes = rc4-hmac des-cbc-md5
    default_tgs_enctypes = rc4-hmac des-cbc-md5
    .
  6. Arrêtez et redémarrez tous les serveurs WebSphere Application Server.
Remarque : Si vous utilisez plusieurs comptes Microsoft Active Directory pour la mise en correspondance avec différents SPN, vous devez répéter les étapes 1 à 3 pour chaque SPN et la fusion de tous les fichiers de clés.

Etablissement d'une règle sans restriction, puis utilisation du chiffrement AES256

Vous pouvez utiliser le chiffrement AES256 après avoir établi une règle sans restriction. Effectuez les étapes suivantes :
  1. Arrêtez le serveur d'applications.
  2. Téléchargez et installez les nouveaux fichiers de règles.
    Important : Votre pays d'origine peut imposer des restrictions en matière d'importation, de possession, d'utilisation ou de réexportation du logiciel de chiffrement. Avant de télécharger ou d'utiliser les fichiers de règles sans restriction, vous devez vérifier les lois en vigueur dans votre pays, sa réglementation et ses règles concernant l'importation, la possession, l'utilisation et la réexportation du logiciel de chiffrement afin de garantir leur respect.
    1. Cliquez sur le niveau de kit de développement de logiciels (SDK) approprié.
    2. Faites défiler la page, puis cliquez sur IBM SDK policy files. Le site Web des fichiers de règles JCE sans restriction pour SDK s'affiche.
    3. Cliquez sur Sign in et entrez votre ID IBM.com et votre mot de passe.
    4. Sélectionnez unrestricted JCE policy files for SDK et cliquez sur Continue.
    5. Lisez l'accord de licence, puis cliquez sur I Agree pour continuer.
    6. Extrayez les fichiers de règles sans restriction stockés dans le fichier ZIP. Ce fichier ZIP contient deux fichiers : US_export_policy.jar et local_policy.jar.
    7. Dans votre installation WebSphere Application Server, accédez au répertoire $JAVA_HOME/lib/security et sauvegardez les fichiers US_export_policy.jar et local_policy.jar existants.
    8. Remplacez les fichiers US_export_policy.jar et local_policy.jar par les deux fichiers que vous avez téléchargés sur le site Web IBM.com.
    Remarque : Effectuez une sauvegarde avant de remplacer ces fichiers. Exemple de chemin : WAS_Install/java/jre/lib/security.
  3. Démarrez le serveur d'applications.

Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rsec_SPNEGO_troubles
Nom du fichier : rsec_SPNEGO_troubles.html