Configuration de l’authentification Kerberos : configuration de base (SharePoint Server 2010)

 

S’applique à : SharePoint Server 2010

Dernière rubrique modifiée : 2017-01-18

Dans le premier scénario, vous allez configurer deux applications Web SharePoint Server 2010 de façon à utiliser le protocole Kerberos pour l’authentification des demandes de client entrantes. À des fins de démonstration, une application Web sera configurée de façon à utiliser les ports standard (80/443) et l’autre application, de façon à utiliser un port non standard (5555). Ce scénario constituera la base de tous les scénarios suivants qui supposent que les activités ci-après auront été effectuées.

Dans ce scénario, vous effectuez les opérations suivantes :

• Configurer deux applications Web avec des zones par défaut utilisant le protocole Kerberos pour l’authentification

• Créer deux collections de sites de test, une dans chaque application Web

• Vérifier la configuration IIS de l’application Web

• Vérifier que les clients peuvent s’authentifier avec l’application Web et que le protocole Kerberos est utilisé pour l’authentification

• Configurer le composant WebPart Visionneuse RSS pour afficher des flux RSS dans une application Web locale ou distante

• Analyser chaque application Web et tester le contenu de recherche dans chaque collection de sites de test

Liste de contrôle de configuration

Zone de configuration	Description
DNS	Enregistrer un enregistrement DNS A pour l’adresse IP virtuelle (VIP) d’équilibrage de la charge réseau (NLB) des applications Web
Active Directory	Créer un compte de service pour le pool d’applications IIS de l’application Web Enregistrer les noms principaux de service (SPN) pour les applications Web sur le compte de service créé pour le pool d’applications IIS de l’application Web Configurer la délégation contrainte Kerberos pour les comptes de service
Application Web SharePoint	Créer des comptes gérés SharePoint Server Créer l’application de service SharePoint Search Créer les applications Web SharePoint
IIS	Vérifier que l’authentification Kerberos est activée Vérifier que l’authentification en mode Kernel est désactivée Installer les certificats pour SSL
Client Windows 7	Vérifier que les URL de l’application Web sont dans la zone intranet, ou une zone configurée pour s’authentifier automatiquement avec l’authentification Windows intégrée
Configuration du pare-feu	Ouvrir les ports du pare-feu pour permettre le trafic HTTP sur les ports standard ou non standard Vérifier que les clients peuvent se connecter aux ports Kerberos sur Active Directory
Tester l’authentification du navigateur	Vérifier que l’authentification fonctionne correctement dans le navigateur Vérifier les informations d’ouverture de session dans le journal des événements de sécurité du serveur Web Utiliser des outils de fournisseur tiers pour vérifier que l’authentification Kerberos est configurée correctement
Tester l’index de recherche et la requête SharePoint Server	Vérifier l’accès navigateur depuis le(s) serveur(s) d’index Charger un échantillon de contenu et effectuer une analyse Tester la recherche
Tester la délégation WFE	Configurer des sources de flux RSS sur chaque collection de sites Ajouter des composants WebPart d’affichage RSS à la page d’accueil de chaque collection de sites

Instructions de configuration pas à pas

Configurer DNS

Configurez DNS pour les applications Web dans votre environnement. Dans cet exemple, nous avons 2 applications Web, http://portal et http://teams:5555, qui toutes deux résolvent vers la même adresse IP virtuelle d’équilibrage de la charge réseau (192.168.24.140/24).

Pour des informations générales sur la façon de configurer DNS, voir Gestion des enregistrements DNS (éventuellement en anglais).

Applications Web SharePoint Server

http://portal — Configurez un nouvel enregistrement DNS A pour l’application Web de portail. Dans cet exemple, un hôte « portal » est configuré pour résoudre l’adresse IP virtuelle d’équilibrage de la charge.

http://teams:5555 — Configurez un nouvel enregistrement DNS A pour l’application Web de l’équipe

Configurer Active Directory

Ensuite, vous allez configurer les comptes Active Directory pour les applications Web de votre environnement. Il est recommandé de configurer chaque application Web pour qu’elle s’exécute dans son propre pool d’applications IIS avec son propre contexte de sécurité (identité du pool d’applications).

Comptes de service d’applications de service SharePoint

Dans notre exemple, deux applications Web SharePoint s’exécutent dans deux pools d’applications IIS distincts avec leur propre identité de pool d’applications.

Application Web (zone par défaut)	Identité de pool d’applications IIS
http://portal	vmlab\svcPortal10App
http://teams:5555	vmlab\ svcTeams10App

Noms principaux de service (SPN)

Pour chaque compte de service, configurez un jeu de noms principaux de service mappés aux noms d’hôte DNS attribués à chaque application Web.

Utilisez SetSPN, un outil en ligne de commande de Windows Server 2008, pour configurer un nouveau nom principal de service. Pour savoir comment utiliser SetSPN, voir Setspn (éventuellement en anglais). Pour découvrir les améliorations de SetSPN dans Windows Server 2008, voir Nouvelles fonctionnalités de SETSPN.EXE dans Windows Server 2008 (éventuellement en anglais).

Toutes les applications Web SharePoint Server, indépendamment du numéro de port, utilisent le format SPN suivant :

• HTTP/<nom d’hôte DNS>

• HTTP/<nom de domaine complet DNS>

Exemple :

• HTTP/portal

• HTTP/portal.vmlab.local

Pour les applications Web s’exécutant sur des ports non standard (ports autres que 80/443), enregistrez des noms principaux de service supplémentaires avec le numéro de port :

• HTTP/<nom d’hôte DNS>:<port>

• HTTP/<nom de domaine complet DNS>:<port>

Exemple :

• HTTP/teams:5555

• HTTP/teams.vmlab.local:5555

Dans notre exemple, nous avons configuré les noms principaux de service suivants pour les deux comptes créés à l’étape précédente :

Hôte DNS	Identité de pool d’applications IIS	Noms principaux de service
Portal.vmlab.local	vmlab\svcPortal10App	HTTP/portal HTTP/portal.vmlab.local
Teams.vmlab.local	vmlab\ svcTeams10App	HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555

Pour créer les noms principaux de service, les commandes suivantes ont été utilisées :

SetSPN -S HTTP/Portal vmlab\svcportal10App

SetSPN -S HTTP/Portal.vmlab.local vmlab\svcportal10App

SetSPN -S HTTP/Teams vmlab\svcTeams10App

SetSPN -S HTTP/Teams.vmlab.local vmlab\ svcTeams10App

SetSPN -S HTTP/Teams:5555 vmlab\ svcTeams10App

SetSPN -S HTTP/Teams.vmlab.local:5555 vmlab\ svcTeams10App

Dans notre exemple, nous avons utilisé un nouveau commutateur de ligne de commande -S introduit dans Windows Server 2008, qui contrôle l’existence du SPN avant de créer le SPN sur le compte. Si le SPN existe déjà, le nouveau SPN n’est pas créé et vous obtenez un message d’erreur.

Si des SPN dupliqués sont détectés, vous devez résoudre le problème en utilisant un nom DNS différent pour l’application Web, changeant de ce fait le SPN, ou en supprimant le SPN existant du compte sur lequel il a été détecté.

Noms principaux de service et SSL

Il est courant de confondre les noms principaux de service Kerberos avec les URL des applications Web HTTP car les formats SPN et URI sont très similaires dans la syntaxe, mais il est important de comprendre deux choses. Les noms principaux de service Kerberos sont utilisés pour identifier un service, et lorsque ce service est une application HTTP, le schéma du service est HTTP que l’accès au service soit SSL ou non. Cela signifie que même si vous accédez à l’application Web en utilisant https://someapp, vous n’avez pas à (et ne devez pas) configurer un nom principal de service avec HTTPS, par exemple HTTPS/someapp.

Configurer la délégation contrainte Kerberos pour des ordinateurs et des comptes de service

Selon le scénario, certaines fonctionnalités de SharePoint Server 2010 peuvent requérir la délégation contrainte pour fonctionner correctement. Par exemple, si le composant WebPart Visionneuse RSS est configuré pour afficher un flux RSS à partir d’une source authentifiée, il nécessitera la délégation pour consommer le flux de la source. Dans d’autres cas, il faudra peut-être configurer la délégation contrainte pour permettre aux applications de service (comme Excel Services) de déléguer l’identité du client aux systèmes dorsaux.

Dans ce scénario, nous allons configurer la délégation contrainte Kerberos pour permettre au composant WebPart Visionneuse RSS de lire un flux RSS local sécurisé et un flux RSS distant sécurisé à partir d’une application Web distante. Dans des scénarios ultérieurs, nous configurerons la délégation contrainte Kerberos pour d’autres applications de service SharePoint Server 2010.

Le diagramme suivant décrit de façon conceptuelle les composants qui vont être configurés dans ce scénario :

Nous avons deux applications Web, chacune disposant de sa propre collection de sites avec une page de site hébergeant deux composants WebPart Visionneuse RSS. Les applications Web ont chacune une seule zone par défaut configurée pour utiliser l’authentification Kerberos de sorte que tous les flux provenant de ces sites Web nécessiteront l’authentification. Sur chaque site, une visionneuse RSS sera configurée pour lire un flux RSS local à partir d’une liste et l’autre sera configurée pour lire un flux avec authentification sur le site distant.

Pour réaliser cela, la délégation Kerberos contrainte sera configurée pour permettre la délégation entre les comptes de service du pool d’applications IIS. Le diagramme suivant décrit de façon conceptuelle les chemins de délégation contrainte nécessaires :

Souvenez-vous que nous identifions l’application Web par le nom du service en utilisant le nom principal de service (SPN) attribué à l’identité du pool d’applications IIS. Les comptes de service traitant les demandes doivent être autorisés à déléguer l’identité du client aux services désignés. Il nous faut donc configurer les chemins de délégation contrainte suivants :

Type principal	Nom principal	Délègue au service
Utilisateur	svcPortal10App	HTTP/Portal HTTP/Portal.vmlab.local HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555
Utilisateur	svcTeams10App	HTTP/Portal HTTP/Portal.vmlab.local HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555

Pour configurer la délégation, vous pouvez utiliser le composant logiciel enfichable Utilisateurs et ordinateurs Active Directory. Cliquez avec le bouton droit sur chaque compte de service et ouvrez la boîte de dialogue Propriétés. Cette boîte de dialogue contient un onglet Délégation (notez que cet onglet apparaît seulement si un SPN est attribué à l’objet ; les ordinateurs ont un SPN par défaut). Sur l’onglet Délégation, sélectionnez N’approuver cet utilisateur que pour la délégation aux services spécifiés, puis Utiliser tout protocole d’authentification.

Cliquez sur le bouton Ajouter pour ajouter les services auxquels l’utilisateur (compte de service) sera autorisé à déléguer. Pour sélectionner un SPN, vous rechercherez l’objet auquel le SPN s’applique. Dans notre exemple, nous essayons de déléguer à un service HTTP, ce qui signifie que nous recherchons le compte de service du pool d’applications IIS auquel le SPN a été attribué à l’étape précédente.

Dans la boîte de dialogue Sélectionner des utilisateurs ou des ordinateurs, cliquez sur Utilisateurs et ordinateurs, recherchez les comptes de service du pool d’applications IIS (dans notre exemple, vmlab\svcPortal10App et vmlab\svcTeams10App), puis cliquez sur OK.

Vous serez invité à sélectionner les services attribués aux objets par nom principal de service.

Dans la boîte de dialogue Ajouter des services, cliquez sur Sélectionner tout, puis cliquez sur OK. Notez que lorsque vous retournez à la boîte de dialogue de délégation, les SPN sélectionnés n’apparaissent pas tous. Pour les afficher tous, activez la case à cocher Développé dans le coin inférieur gauche.

Effectuez ces étapes pour chaque compte de service de votre environnement qui requiert la délégation. Dans notre exemple, il s’agit de la liste des comptes de service.

Configurer SharePoint Server

Une fois Active Directory et DNS configurés, il est temps de créer l’application Web sur votre batterie de serveurs SharePoint Server 2010. Cet article suppose qu’à ce stade l’installation de SharePoint Server est terminée et que la topologie et l’infrastructure de prise en charge de la batterie de serveurs, par exemple l’équilibrage de charge, sont configurées. Pour plus d’informations sur la façon d’installer et de configurer votre batterie de serveurs SharePoint, voir : Déploiement pour SharePoint Server 2010.

Configurer les comptes de service gérés

Avant de créer vos applications Web, configurez les comptes de services créés aux étapes précédentes en tant que comptes gérés dans SharePoint Server. En procédant à cette opération à l’avance, vous pourrez sauter cette étape au moment de la création des applications Web.

Pour configurer un compte géré

1. Dans Administration centrale de SharePoint, cliquez sur Sécurité.

2. Sous Sécurité générale, cliquez sur Configurer les comptes gérés.

3. Cliquez sur Enregistrer le compte géré et créez un compte géré pour chaque compte de service. Dans cet exemple, nous avons créé 5 comptes de service gérés :

   Compte	Fonction
   VMLAB\svcSP10Search	Compte de service de recherche SharePoint
   VMLAB\svcSearchAdmin	Compte de service d’administration de recherche SharePoint
   VMLAB\svcSearchQuery	Compte de service de requête de recherche SharePoint
   VMLAB\svcPortal10App	Compte du pool d’applications IIS de l’application Web Portal
   VMLAB\svcTeams10App	Compte du pool d’applications IIS de l’application Web Teams

   Notes

   Les comptes gérés dans SharePoint Server 2010 sont différents des comptes de service gérés dans Active Directory Windows Server 2008 R2.

Créer l’application de service de recherche SharePoint Server

Dans cet exemple, nous allons configurer l’application de service de recherche SharePoint Server pour s’assurer que l’application Web nouvellement créée est accessible en analyse et recherche correctement. Créez une application Web de recherche SharePoint Server et placez les services d’administration, de recherche et de requête sur le serveur d’applications, dans notre exemple vmSP10App01. Pour savoir comment configurer l’application de service de recherche, voir Procédure pas à pas : mise en service de l’application de service de recherche (éventuellement en anglais).

Créer l’application Web

Accédez à l’Administration centrale et naviguez jusqu’à Gérer les applications Web dans la section Gestion des applications. Dans la barre d’outils, sélectionnez Nouveau et créez votre application Web. Veillez à utiliser la configuration suivante :

• Sélectionnez Authentification en mode classique.

• Configurez le port et l’en-tête d’hôte de chaque application Web.

• Sélectionnez Négocier comme Fournisseur d’authentification.

• Sous Pool d’applications, sélectionnez Créer un nouveau pool d’applications et sélectionnez le compte géré créé à l’étape précédente.

Dans cet exemple, deux applications Web ont été créées avec les paramètres suivants :

Paramètre	Application Web http://Portal	Application Web http://Teams
Authentification	Mode classique	Mode classique
Site Web IIS	Nom : SharePoint – Portal – 80 Port : 80 En-tête d’hôte : Portal	Nom : SharePoint – Teams – 5555 Port : 80 En-tête d’hôte : Teams
Configuration de la sécurité	Fournisseur d’authentification : Négocier Autoriser l’accès anonyme : Non Utiliser SSL (Secure Sockets Layer) : Non	Fournisseur d’authentification : Négocier Autoriser l’accès anonyme : Non Utiliser SSL (Secure Sockets Layer) : Non
URL publique	http://Portal:80	http://Teams:5555
Pool d’applications	Nom : SharePoint – Portal80 Compte de sécurité : vmlab\svcPortal10App	Nom : SharePoint – Teams5555 Compte de sécurité : vmlab\svcTeams10App

Lorsque vous créez la nouvelle application Web, vous créez également une nouvelle zone, la zone par défaut, configurée pour utiliser le fournisseur d’authentification Windows. Vous pouvez consulter le fournisseur et ses paramètres pour la zone dans la Gestion des applications Web en sélectionnant d’abord l’application Web, puis en cliquant sur Fournisseurs d’authentification dans la barre d’outils. La boîte de dialogue Fournisseurs d’authentification liste toutes les zones pour l’application Web sélectionnée avec le fournisseur d’authentification de chacune. En sélectionnant la zone, vous verrez les options d’authentification pour cette zone.

Si vous avez mal configuré les paramètres Windows et sélectionné NTLM au moment de la création de l’application Web, vous pouvez utiliser la boîte de dialogue Modifier l’authentification pour la zone afin de basculer celle-ci de NTLM à Négocier. Si Mode classique n’a pas été sélectionné comme mode d’authentification, vous devez soit créer une nouvelle zone en étendant l’application Web à un nouveau site Web IIS, soit supprimer puis recréer l’application Web.

Créer des collections de sites

Pour tester si l’authentification fonctionne correctement, vous devez créer au moins une collection de sites dans chaque application Web. La création et la configuration de la collection de sites n’affectera pas la fonctionnalité Kerberos, vous pouvez donc suivre les instructions pour créer une collection de sites de l’article Créer une collection de sites (SharePoint Foundation 2010).

Pour cet exemple, deux collections de sites ont été configurées :

Application Web	Chemin de la collection de sites	Modèle de la collection de sites
http://portal	/	Portail de publication
http://teams:5555	/	Site d’équipe

Créer les mappages d’accès de substitution

L’application Web de portail sera configurée de façon à utiliser HTTPS ainsi que HTTP pour montrer comment fonctionne la délégation avec les services protégés SSL. Pour configurer SSL, l’application Web de portail nécessitera un second mappage d’accès de substitution (AAM) SharePoint Server pour le point de terminaison HTTPS.

Pour configurer les mappages d’accès de substitution

1. Dans l’Administration centrale, cliquez sur Gestion des applications.

2. Sous Applications Web, cliquez sur Configurer les mappages d’accès de substitution.

3. Dans la liste déroulante Sélectionner la collection de mappages des accès de substitution, sélectionnez Changer la collection de mappages des accès de substitution.

4. Sélectionnez l’application Web de portail.

5. Cliquez sur Modifier les URL publiques dans la barre d’outils supérieure.

6. Dans une zone libre, ajoutez l’URL HTTPS de l’application Web. Cette URL sera le nom indiqué sur le certificat SSL que vous créerez dans les étapes suivantes.

7. Cliquez sur Enregistrer.

   L’URL HTTPS doit maintenant figurer dans la liste de zones de l’application Web.

Configuration IIS

Installer les certificats SSL

Vous devrez configurer un certificat SSL sur chaque serveur SharePoint hébergeant le service d’application de chaque application Web qui utilise SSL. La méthode de configuration d’un certificat SSL et l’approbation de certificat ne sont pas traitées dans ce document. Voir la section Configuration SSL de ce document pour les références à la documentation sur la configuration des certificats SSL dans IIS.

Vérifier que l’authentification Kerberos est activée

Pour vérifier que l’authentification Kerberos est activée sur le site Web

1. Ouvrez le Gestionnaire IIS.

2. Sélectionnez le site Web IIS à vérifier.

3. Dans l’Affichage des fonctionnalités, sous IIS, double-cliquez sur Authentification.

4. Sélectionnez Authentification Windows qui doit être activé.

5. À droite, sous Actions, sélectionnez Fournisseurs. Vérifiez que Négocier est en haut de la liste.

Vérifier que l’authentification en mode Kernel est désactivée

L’authentification en mode Kernel n’est pas prise en charge dans SharePoint Server 2010. Par défaut, pour toutes les applications Web SharePoint Server l’authentification en mode Kernel doit être désactivée sur les sites Web IIS correspondants. Même dans les cas où l’application Web a été configurée sur un site Web IIS existant, SharePoint Server désactive l’authentification en mode Kernel lorsqu’il met en service une nouvelle application Web sur le site IIS existant.

Pour vérifier que l’authentification en mode Kernel est désactivée

1. Ouvrez le Gestionnaire IIS.

2. Sélectionnez le site Web IIS à vérifier.

3. Dans l’Affichage des fonctionnalités, sous IIS, double-cliquez sur Authentification.

4. Sélectionnez Authentification Windows, qui doit être activé.

5. Cliquez sur Paramètres avancés.

6. Vérifiez que l’authentification en mode Kernel et EAP sont désactivés.

Configurer le pare-feu

Avant de tester l’authentification, assurez-vous que les clients peuvent accéder aux applications Web SharePoint Server sur les ports HTTP configurés. De plus, assurez-vous que les clients peuvent procéder à l’authentification avec Active Directory et demander des tickets Kerberos au centre de distribution de clés du domaine (KDC) via les ports Kerberos standard.

Ouvrir les ports du pare-feu pour permettre le trafic HTTP sur les ports standard ou non standard

Généralement, vous devez configurer le pare-feu sur chaque serveur Web frontal pour permettre les demandes entrantes via les ports TCP 80 et TCP 443. Ouvrez Pare-feu Windows avec fonctions avancées de sécurité et accédez aux règles de trafic entrant suivantes :

• Services World Wide Web (Trafic HTTP)

• Services World Wide Web (Trafic HTTPS)

Assurez-vous que les ports adéquats sont ouverts dans votre environnement. Dans notre exemple, nous accédons à SharePoint Server via HTTP (port 80), donc cette règle a été activée.

De plus, nous devons ouvrir le port non standard utilisé dans notre exemple (TCP 5555). Si vous avez des sites Web s’exécutant sur des ports autres que les ports par défaut, vous devez également configurer des règles personnalisées pour permettre le trafic HTTP sur ces ports.

Vérifier que les clients peuvent se connecter aux ports Kerberos sur le rôle Active Directory

Pour utiliser l’authentification Kerberos, les clients devront demander les tickets TGT (Ticket Granting Tickets) et ST (Service Tickets) auprès du centre de distribution de clés (KDC) via le port UDP ou TCP 88. Par défaut, lorsque vous installez le rôle Active Directory dans Windows Server 2008 et ultérieur, le rôle configurera les règles entrantes suivantes pour permettre cette communication par défaut :

• Centre de distribution de clés Kerberos – PCR (TCP entrant)

• Centre de distribution de clés Kerberos – PCR (UDP entrant)

• Centre de distribution de clés Kerberos (TCP entrant)

• Centre de distribution de clés Kerberos (UDP entrant)

Dans votre environnement, assurez-vous que ces règles sont activées et que les clients peuvent se connecter au centre de distribution de clés (contrôleur de domaine) via le port 88.

Tester l’authentification du navigateur

Après avoir configuré Active Directory, DNS et SharePoint Server, vous pouvez maintenant tester si l’authentification Kerberos est configurée correctement en accédant à vos applications Web. Lors du test dans le navigateur, assurez-vous que les conditions suivantes sont remplies :

1. L’utilisateur de test a ouvert une session sur un ordinateur Windows XP, Vista ou Windows 7 connecté au domaine sur lequel SharePoint Server est installé, ou a ouvert une session sur un domaine approuvé par le domaine SharePoint Server.

2. L’utilisateur de test utilise Internet Explorer 7.0 ou ultérieur (Internet Explorer 6.0 n’est plus pris en charge par SharePoint Server 2010 ; voir Planifier la prise en charge du navigateur (SharePoint Server 2010)).

3. L’authentification Windows intégrée est activée dans le navigateur. Sous Options Internet dans l’onglet Avancées, assurez-vous que Activer l’authentification Windows intégrée* est activé dans la section Sécurité :

4. L’intranet local est configuré de façon à connecter automatiquement les clients. Sous Options Internet du navigateur, dans l’onglet Sécurité, sélectionnez Intranet local et cliquez sur le bouton Personnaliser le niveau. Faites défiler vers le bas et assurez-vous que Connexion automatique uniquement dans la zone intranet est sélectionné.

   Notes

   Il est possible de configurer la connexion automatique sur d’autres zones mais ce document ne traite pas des pratiques recommandées en matière de zones de sécurité Internet Explorer. Pour cette démonstration, la zone intranet sera utilisée pour tous les tests.

5. Assurez-vous que Détecter automatiquement le réseau Intranet est sélectionné dans Options Internet->Sécurité->Zone Intranet->Sites.

6. Si vous utilisez des noms de domaine complets pour accéder aux applications Web SharePoint Server, assurez-vous que les noms de domaine complets (FQDN) sont inclus dans la zone intranet, soit explicitement soit par inclusion générique (par exemple, *.vmlab.local).

Le moyen le plus simple de déterminer si l’authentification Kerberos est utilisée est d’ouvrir une session sur une station de travail de test et d’accéder au site Web en question. Si l’utilisateur n’est pas invité à fournir des informations d’identification et que le site s’affiche correctement, vous pouvez supposer que l’authentification Windows intégrée fonctionne. L’étape suivante consiste à déterminer si le protocole de négociation à été utilisé pour franchir l’authentification Kerberos en tant que fournisseur d’authentification de la demande. Vous pouvez effectuer cela des façons suivantes :

Journaux de sécurité des serveurs Web frontaux

Si l’authentification Kerberos fonctionne correctement, des événements Ouverture de session figureront dans les journaux d’événements de sécurité sur les serveurs Web frontaux avec l’ID d’événement 4624. Dans les informations générales de ces événements, vous devez voir l’ID de sécurité connectée à l’ordinateur et le processus d’ouverture de session utilisé, qui doit être Kerberos.

KList

KList est un utilitaire en ligne de commande inclus avec l’installation par défaut de Windows Server 2008 et Windows Server 2008 R2, qui permet de lister et purger les tickets Kerberos sur un ordinateur donné. Pour exécuter KLIST, ouvrez une invite de commandes dans Windows Server 2008 et tapez Klist.

Pour purger le cache des tickets, exécutez Klist avec le paramètre facultatif purge : Klist purge

KerbTray

KerbTray est un utilitaire gratuit inclus avec le Kit de ressources Windows Server 2000, que vous pouvez installer sur votre ordinateur client pour afficher le cache des tickets Kerberos. Téléchargez et installez Outil du kit de ressources Windows 2000 : Kerbtray.exe (éventuellement en anglais). Une fois l’outil installé, effectuez les opérations suivantes :

1. Accédez aux sites Web qui utilisent l’authentification Kerberos.

2. Exécutez KerbTray.exe.

3. Affichez le cache des tickets Kerberos en cliquant avec le bouton droit sur l’icône de kerb dans la barre d’état système et en sélectionnant Lister les tickets.

4. Vérifiez que les tickets de service pour les applications Web que vous avez authentifiées sont dans la liste des tickets mis en cache. Dans notre exemple, nous avons accédé aux sites Web ayant les noms principaux de service suivants enregistrés :

   URL du site Web	Nom principal de service
   http://portal	HTTP/Portal.vmlab.local
   http://teams:5555	HTTP/Teams.vmlab.local

Fiddler

Fiddler est un analyseur de trafic HTTP gratuit pouvant être téléchargé à partir du site http://www.fiddlertool.com/ (éventuellement en anglais). Dans Fiddler, vous pourrez voir le client et le serveur négocier l’authentification Kerberos et le client envoyer les tickets de service Kerberos au serveur dans les en-têtes HTTP de chaque demande. Pour vérifier que l’authentification Kerberos fonctionne correctement en utilisant Fiddler, effectuez les opérations suivantes :

1. Téléchargez et installez Fiddler (www.fiddlertool.com (éventuellement en anglais)) sur l’ordinateur client.

2. Déconnectez-vous puis reconnectez-vous pour vider toute connexion en cache au serveur Web et forcez le navigateur à négocier l’authentification Kerberos et à effectuer le protocole de transfert d’authentification.

3. Démarrez Fiddler.

4. Ouvrez Internet Explorer et accédez à l’application Web (http://portal dans notre exemple).

Vous devriez voir les demandes et les réponses du serveur Web frontal SharePoint Server dans Fiddler.

La première HTTP 401 est la tentative du navigateur de procéder à la demande GET sans authentification. En réponse, le serveur renvoie « HTTP 401 – Non autorisé » en indiquant les méthodes d’authentification qu’il prend en charge. Dans la demande suivante, le client envoie à nouveau la demande précédente, mais cette fois avec le ticket de service pour l’application Web dans les en-têtes de la demande. Si l’authentification réussit, le serveur renvoie la ressource demandée.

NetMon 3.4

NetMon 3.4 est un analyseur de paquets réseau gratuit Microsoft qui peut être téléchargé à partir du Centre de téléchargement Microsoft : Microsoft Network Monitor 3.4 (éventuellement en anglais).

NetMon vous permet de voir toutes les demandes et réponses TCP au centre de distribution de clés du domaine et aux serveurs Web SharePoint Server, ce qui vous donne un aperçu complet du trafic qui représente une demande d’authentification complète. Pour vérifier que l’authentification Kerberos fonctionne correctement en utilisant NetMon, effectuez les opérations suivantes :

1. Téléchargez et installez NetMon 3.4 (Microsoft Network Monitor 3.4 (éventuellement en anglais)).

2. Déconnectez-vous du client, puis reconnectez-vous pour vider le cache des tickets Kerberos. Vous pouvez sinon utiliser KerbTray pour purger le cache des tickets en cliquant avec le bouton droit sur KerbTray et en sélectionnant Purger les tickets.

3. Démarrez NetMon en mode administrateur. Cliquez avec le bouton droit sur le raccourci NetMon et sélectionnez Exécuter en tant qu’administrateur.

4. Démarrez une nouvelle capture sur les interfaces qui se connectent au contrôleur Active Directory dans votre environnement et aux serveurs Web frontaux.

5. Ouvrez Internet Explorer et accédez à l’application Web.

6. Après l’affichage du site Web, arrêtez la capture et ajoutez un filtre d’affichage pour afficher les trames de l’authentification Kerberos et du trafic HTTP.

7. Dans la fenêtre des trames, vous devez voir le trafic HTTP et KerberosV5.

Tester l’authentification Kerberos via SSL

Pour clairement afficher les noms principaux de service demandés lorsqu’un client accède à une ressource protégée SSL, vous pouvez utiliser un outil comme NetMon pour capturer le trafic entre le client et le serveur et examiner les demandes de ticket de service Kerberos.

1. Déconnectez-vous puis reconnectez-vous à l’ordinateur client ou effacez tous les tickets Kerberos mis en cache en utilisant KerbTray.

2. Démarrez une nouvelle capture NetMon sur l’ordinateur client. Assurez-vous de démarrer NetMon avec des autorisations d’administrateur.

3. Accédez à l’application Web en utilisant SSL (dans cet exemple, https://portal).

4. Arrêtez la capture NetMon et examinez le trafic KerberosV5. Pour des instructions sur la façon de filtrer l’affichage de capture, voir la section NetMon 3.4 de cet article.

5. Recherchez la demande TGS que le client envoie. Dans cette demande, le nom principal de service demandé apparaît dans le paramètre Sname.

   Notez que Sname contient HTTP/portal.vmlab.local et pas HTTPS/portal.vmlab.local.

Tester l’index de recherche et la requête SharePoint Server

Vérifier l’accès navigateur depuis le(s) serveur(s) d’index

Avant d’exécuter une analyse, assurez-vous que le serveur d’index peut accéder aux applications Web et procéder à l’authentification avec succès. Connectez-vous au serveur d’index et ouvrez les collections de sites de test dans le navigateur. Si les sites s’affichent avec succès sans apparition d’une boîte de dialogue d’authentification, passez à l’étape suivante. Si des problèmes se produisent lors de l’accès aux sites dans le navigateur, revenez aux étapes précédentes pour vérifier si toutes les opérations de configuration on été correctement effectuées.

Charger un échantillon de contenu et effectuer une analyse

Dans chaque collection de sites, chargez un document de départ (qui soit facilement identifiable en recherche) dans une bibliothèque de documents de la collection de sites. Par exemple, créez un document texte contenant les mots « alpha, bêta, delta » et enregistrez-le dans une bibliothèque de documents sur chaque collection de sites.

Ensuite, accédez à l’Administration centrale SharePoint et lancez une analyse complète sur la source de contenu Sites SharePoint locaux (qui doit contenir les deux collections de sites test par défaut).

Tester la recherche

Si l’indexation s’est déroulée avec succès, vous devez voir des éléments accessibles en recherche dans votre index et aucune erreur dans le journal d’analyse.

Ensuite, accédez à chaque collection de sites et effectuez une recherche du document de départ. La requête de recherche sur chaque collection de sites doit retourner le document ayant été chargé.

Tester la délégation de serveur Web frontal

Dans la dernière étape de ce scénario, vous utilisez le composant WebPart Visionneuse RSS sur chaque collection de sites pour vérifier que la délégation fonctionne correctement aussi bien localement qu’à distance.

Configurer des sources de flux RSS sur chaque collection de sites

Pour l’application de portail, vous devez activer les flux RSS sur la collection de sites. Pour activer les flux RSS, suivez les instructions de Gérer les flux RSS sur Office.com.

Une fois les flux RSS activés, créez une liste personnalisée et ajoutez-lui un élément à des fins de test. Accédez au menu de la barre d’outils Liste et cliquez sur Flux RSS pour afficher le flux RSS. Copiez l’URL du flux afin de l’utiliser dans les étapes suivantes.

Effectuez cette étape pour chaque collection de sites.

Ajouter des composants WebPart d’affichage RSS à la page d’accueil de chaque collection de sites

Sur l’application de portail, vous devrez activer la fonctionnalité de collection de sites SharePoint Enterprise Features pour utiliser le composant WebPart Visionneuse RSS. Une fois la fonctionnalité activée, ajoutez deux composants WebPart Visionneuse RSS à la page d’accueil. Pour le premier composant WebPart, configurez l’URL du flux de façon à pointer vers le flux RSS local que vous avez créé à l’étape précédente. Pour le second composant WebPart, configurez l’URL du flux de façon à pointer vers le flux RSS distant. Une fois terminé, vous devez voir les deux composants WebPart afficher correctement le contenu des flux RSS local et distant respectivement.