Problèmes connus de configuration Kerberos (SharePoint Server 2010)

  • Article

 

S’applique à : SharePoint Server 2010

Dernière rubrique modifiée : 2016-11-30

Authentification Kerberos et ports non standard

Il existe un problème connu avec certains clients Kerberos (.NET Framework, Internet Explorer 7 et 8) qui ne forment pas correctement les noms principaux de service lors de la tentative d’authentification auprès d’applications Web se servant de Kerberos qui sont configurées sur des ports non standard (ports autres que 80 et 443). La cause du problème est que le client ne forme pas correctement le nom principal de service (SPN) dans la demande TGS en le spécifiant sans le numéro du port (comme dans Sname de la demande TGS).

Exemple :

Si l’application Web s’exécute sur http://intranet.contoso.com:1234, le client va demander un ticket pour un service avec un SPN égal à http/intranet.contoso.com au lieu de http/intranet.contoso.com:1234.

Vous trouverez des détails sur ce problème dans les articles suivants :

Pour contourner ce problème, enregistrez les noms principaux de service avec et sans numéro de port. Exemple :

  • http/intranet

  • http/intranet.contoso.com

  • http/intranet:12345

  • http/intranet.contoso.com:12345

Il est recommandé d’enregistrer le port non standard de sorte que si le problème est résolu dans un futur Service Pack ou correctif, les applications utilisant la solution de contournement continueront à fonctionner.

Notez que cette solution de contournement ne fonctionnera que dans les conditions suivantes :

  • Il y a plus d’une application Web s’exécutant sur un port non standard

  • Les applications Web se lient au nom d’hôte du serveur or se lient au même en-tête d’hôte (sur différents ports)

  • Les pools d’applications Web IIS utilisent différents comptes de service

Si ces conditions sont vérifiées, l’application de cette solution de contournement produira des noms principaux de service dupliqués enregistrés sur différents comptes de service, ce qui rompra l’authentification Kerberos.

Si vous avez plusieurs sites Web partageant un nom d’hôte commun s’exécutant sur plusieurs ports, et que vous utilisez différentes entités de pools d’applications IIS pour les applications Web, vous ne pouvez pas utiliser l’authentification Kerberos sur tous les sites Web (une application peut utiliser Kerberos et les autres nécessiteront un autre protocole d’authentification). Pour utiliser Kerberos avec toutes les applications dans ce scénario, vous devez procéder de l’une des façons suivantes :

  1. Exécuter toutes les applications Web sous un seul compte de service partagé

  2. Exécuter chaque site avec son propre en-tête d’hôte

Authentification Kerberos et alias DNS CNAME

Il existe un problème connu avec certains clients Kerberos (Internet Explorer 7 et 8) essayant de s’authentifier auprès de services utilisant Kerberos qui sont configurés pour une résolution utilisant les alias DNS CNAME au lieu des enregistrements A. La cause du problème est que le client ne forme pas correctement le nom principal de service (SPN) dans la demande TGS en le spécifiant avec le nom d’hôte (enregistrement A) au lieu du nom d’alias (CNAME).

Exemple :

Enregistrement A : wfe01.contoso.com

CNAME : intranet.contoso.com (alias wfe01.contoso.com)

Si le client essaie de s’authentifier avec http://intranet.contoso.com, le client ne forme pas correctement le SPN et demande un ticket Kerberos pour http/wfe01.contoso.com au lieu de http/intranet.contoso.com.

Vous trouverez des détails sur ce problème dans les articles suivants :

https://support.microsoft.com/kb/911149/fr (éventuellement en anglais)

https://support.microsoft.com/kb/938305/fr (éventuellement en anglais)

Pour contourner ce problème, configurez les services utilisant Kerberos à se servir des enregistrements DNS A au lieu des alias CNAME. Le correctif mentionné dans l’article de la Base de connaissances corrige ce problème pour Internet Explorer mais ne le corrige pas pour .NET Framework (qui est utilisé par Microsoft Office SharePoint Server pour la communication avec les services Web).

Authentification Kerberos et authentification en mode Kernel

Notes

L’authentification en mode Kernel n’est pas prise en charge dans les produits SharePoint 2010. Ces informations sont fournies uniquement à titre informatif.

Depuis IIS version 7.0, il existe une nouvelle fonctionnalité d’authentification appelée Authentification en mode Kernel. Lorsqu’un site Web IIS est configuré pour utiliser l’authentification en mode Kernel, HTTP.sys authentifiera les demandes du client au lieu du processus de traitement du pool d’applications. Comme HTTP.sys s’exécute en mode kernel, cela améliore les performances mais introduit également une certaine complexité lors de la configuration Kerberos. En effet, HTTP.sys s’exécute sous l’identité de l’ordinateur et pas sous l’identité du processus de traitement. Lorsque HTTP.sys reçoit un ticket Kerberos, il va essayer par défaut de déchiffrer le ticket en utilisant la clé de chiffrement du serveur (aussi appelée secret) et pas la clé de l’identité sous laquelle le processus de traitement s’exécute.

Si un seul serveur Web est configuré pour utiliser l’authentification en mode Kernel, Kerberos fonctionnera sans aucune configuration supplémentaire ni noms principaux de service supplémentaires (SPN) car le serveur enregistrera automatiquement un SPN d’hôte lorsqu’il est ajouté au domaine. Avec plusieurs serveurs Web équilibrés en charge, la configuration par défaut Authentification en mode Kernel ne fonctionnera pas, ou échouera par intermittence, car le client n’a aucun moyen de s’assurer que le ticket de service reçu dans la demande TGS fonctionnera avec le serveur qui authentifie la demande.

Pour contourner ce problème, procédez comme suit :

Authentification Kerberos et authentification basée sur la session

Vous pouvez constater une augmentation du trafic d’authentification si vous utilisez l’authentification Kerberos avec IIS 7.0 et ultérieur. Cela peut être dû aux paramètres d’authentification Windows dans IIS, en particulier :

AuthPersistNonNTLM

Attribut booléen facultatif.

Spécifie si IIS réauthentifie automatiquement chaque demande non-NTLM (par exemple, Kerberos), même celles de la même connexion. True autorise plusieurs authentifications sur les mêmes connexions.

La valeur par défaut est False.

Notes

Le paramètre False signifie que le client ne sera authentifié qu’une seule fois sur la même connexion. IIS mettra en cache un jeton ou ticket sur le serveur pour une session TCP qui demeure établie.

authPersistSingleRequest

Attribut booléen facultatif.

Le paramètre True spécifie que l’authentification ne persistera que pour une seule demande sur une connexion. IIS réinitialise l’authentification à la fin de chaque demande et force une nouvelle authentification à la demande suivante de la session.

La valeur par défaut est False.

Pour savoir comment configurer la persistance de l’authentification dans IIS 7.0, voir Vous pouvez rencontrer un ralentissement des performances lorsque vous utilisez l’authentification intégrée Windows avec le protocole d’authentification Kerberos dans IIS 7.0 (éventuellement en anglais) et Implémentation du contrôle d’accès (éventuellement en anglais).

Authentification Kerberos et problèmes de SPN dupliqués ou manquants

Lors de la configuration de l’authentification Kerberos, il arrive de configurer sans le vouloir des noms principaux de service (SPN) dupliqués, surtout si vous utilisez SetSPN -A ou l’outil Modification ADSI (adsiedit.msc) pour créer vos noms principaux de service. Il est recommandé d’utiliser SetSPN -S pour créer les SPN car le commutateur -S vérifie l’existence d’un SPN dupliqué avant de créer le SPN spécifié.

Si vous pensez que des noms principaux de service dupliqués existent dans votre environnement, utilisez la commande SetSPN -X pour demander tous les noms principaux de service dupliqués existants (Windows 2008 ou ultérieur uniquement). Si des SPN sont retournés, il vous faut rechercher pourquoi des SPN ont été enregistrés et supprimer ceux dupliqués qui sont inutiles. Si vous avez deux services s’exécutant avec deux identités différentes et que les deux utilisent le même SPN (problème de SPN dupliqué), vous devez reconfigurer l’un de ces services afin d’utiliser un SPN différent ou de partager une identité de service commune.

Si vous pensez qu’un SPN n’est pas enregistré, ou n’est pas enregistré dans le format requis, vous pouvez utiliser SetSPN -Q <insérer SPN> pour interroger l’existence d’un SPN particulier.

Taille maximum de jeton Kerberos

Dans certains environnements, les utilisateurs peuvent être membres de plusieurs groupes Active Directory, ce qui augmente la taille de leurs tickets Kerberos. Si les tickets deviennent trop volumineux, l’authentification Kerberos peut échouer. Pour savoir comment régler la taille maximum de jeton, voir Nouvelle résolution des problèmes avec l’authentification Kerberos lorsque les utilisateurs appartiennent à de nombreux groupes (éventuellement en anglais) (https://support.microsoft.com/kb/327825/fr) (éventuellement en anglais).

Notes

Lors du réglage de la taille maximum de jeton, sachez que si vous configurez ce maximum au delà de la valeur maximum du paramètre de Registre, vous risquez d’obtenir des erreurs d’authentification Kerberos. Il est recommandé de ne pas dépasser la valeur décimale 65535 ou hexadécimale FFFF pour la taille maximum de jeton.

Correctifs de l’authentification Kerberos pour Windows Server 2008 et Windows Vista

Une authentification Kerberos échoue avec le code d’erreur 0X80090302 ou 0x8009030f sur un ordinateur exécutant Windows Server 2008 ou Windows Vista lorsque l’algorithme AES est utilisé (https://support.microsoft.com/kb/969083/fr).

Vous devrez peut-être installer un correctif pour l’authentification Kerberos sur tous les ordinateurs exécutant Windows Server 2008 ou Windows Vista dans votre environnement. Cela inclut tous les ordinateurs exécutant SharePoint Server 2010, SQL Server ou Windows Server 2008 auprès desquels SharePoint Server essaie de s’authentifier via l’authentification Kerberos. Suivez les instructions de la page de support pour appliquer le correctif si vous rencontrez les symptômes documentés dans le cas présenté.