Partager via


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.

Important

Il est requis de configurer vos applications Web avec l’authentification Windows classique utilisant l’authentification Kerberos pour que les scénarios fonctionnent comme prévu. L’authentification basée sur les revendications Windows peut être utilisée dans certains scénarios, mais risque de ne pas produire les résultats présentés dans les scénarios ci-après.

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.

Image de l’enregistrement DNS

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

Image de l’enregistrement DNS

Notes

Il est important de s’assurer que les entrées DNS sont des enregistrements A et non des alias CNAME pour que l’authentification Kerberos fonctionne correctement dans des environnements où plusieurs applications Web s’exécutent avec des en-têtes d’hôte et des comptes de service dédiés distincts. Voir Problèmes connus de configuration Kerberos (SharePoint Server 2010) pour une explication du problème connu concernant l’utilisation de CNAME avec les applications Web se servant de Kerberos.

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

Notes

Voir l’annexe pour savoir pourquoi il est recommandé de configurer des noms principaux de service avec et sans numéro de port pour les services HTTP s’exécutant sur des ports non standard (autres que 80, 443). Techniquement, la façon correcte de faire référence à un service HTTP s’exécutant sur un port non standard est d’inclure le numéro de port dans le SPN, mais à cause des problèmes connus décrits dans l’annexe, nous devons configurer également des SPN sans port. Notez que les SPN sans port pour l’application Web teams ne signifient pas que l’accès aux services se fera via les ports par défaut (80, 443) dans notre exemple.

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

Important

Ne configurez pas des noms principaux de service avec HTTPS même si l’application Web utilise SSL.

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é.

Important

Avant de supprimer un SPN existant, assurez-vous qu’il n’est plus utilisé, sinon vous risquez de rompre l’authentification Kerberos d’une autre application de votre environnement.

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 :

Diagramme du 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 :

Diagramme de la délégation du pool d’applications.

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

Notes

Il peut sembler redondant de configurer la délégation d’un service à lui-même, tel le compte du service de portail délégant à l’application de service du portail, mais cela est requis dans les scénarios où plusieurs serveurs exécutent le service. Cela prend en compte le cas où un serveur doit pouvoir déléguer à un autre serveur exécutant le même service ; par exemple, un WFE traitant une demande via une visionneuse RSS qui utilise l’application Web locale comme source de données. Selon la topologie et la configuration de la batterie de serveurs, il y a la possibilité que la requête RSS soit traitée par un serveur différent qui requiert la délégation pour fonctionner correctement.

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).

Notes

Le placement de tous les services de recherche sur un seul serveur d’applications est à but démonstratif seulement. Ce document ne fait pas l’objet d’une discussion complète sur les options et les pratiques recommandées en matière de topologie de recherche SharePoint Server 2010.

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.

Notes

Si vous avez configuré l’Application de profil utilisateur et que vous effectuez une analyse sur le magasin de profils, assurez-vous que les autorisations appropriées sont configurées sur l’Application de profil utilisateur afin que le compte d’accès au contenu puisse accéder aux données de profil. Si vous n’avez pas configuré ces autorisations, vous obtiendrez des erreurs dans les journaux d’analyse indiquant l’impossibilité d’accès pour le robot au service de profil, qui a obtenu une erreur HTTP 401 lors de la tentative d’accès au service. Cette erreur n’est pas due à Kerberos, mais au compte d’accès au contenu qui ne dispose pas des autorisations pour lire les données de profil.

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.