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

S’applique à : SharePoint Server 2010

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

Dans les articles de scénario suivants, nous créons un environnement SharePoint Server 2010 pour montrer comment configurer la délégation dans une série de scénarios couramment rencontrés au sein d’une entreprise. Les procédures supposent que vous créez une batterie de serveurs SharePoint avec montée en puissance parallèle en suivant la description fournie dans la section suivante.

Environnement et topologie de batterie de serveurs

Le diagramme suivant illustre la topologie de batterie de serveurs utilisée lors de la configuration des scénarios décrits dans les sections ci-après. La topologie de batterie de serveurs est équilibrée en charge et déployée sur plusieurs niveaux pour démontrer comment la délégation d’identité fonctionne dans des scénarios à plusieurs serveurs et plusieurs bonds.

Spécification de l’environnement

Tous les ordinateurs de l’environnement de démonstration sont virtualisés et reposent sur Windows Server 2008 R2 Hyper-V. Les ordinateurs sont joints à un domaine Windows unique, vmlab.local, qui s’exécute dans les niveaux de fonction de forêt et de domaine Windows Server 2008.

• Ordinateur client

  • Windows 7 Professionnel, 64 bits

• Serveurs Web frontaux SharePoint Server

  • Windows Server 2008 R2 Entreprise, 64 bits

  • Services :

    • Service d’application Web

  • Charge équilibrée avec équilibrage de la charge réseau Windows

• Serveur d’applications SharePoint Server

  • Windows Server 2008 R2 Entreprise, 64 bits

  • Microsoft SharePoint Server 2010 (RTM)

  • Services :

    • Services d’émission de jetons Revendications vers Windows de WIF

    • Service de métadonnées gérées

    • Index SharePoint

    • Requête SharePoint

    • Excel Services

    • Visio Graphics Services

    • Business Connectivity Services

    • Performance Point Services

• SQL Services

  • Windows Server 2008 R2 Entreprise, 64 bits

  • Microsoft SQL Server 2008 R2 Entreprise, 64 bits

  • Configuration active/passive

  • Services SQL Server :

    • Moteur de données SQL

    • SQL Server Analysis Services

    • SQL Agent

    • SQL Browser

• SQL Reporting Server

  • Windows Server 2008 R2 Entreprise, 64 bits (RTM)

  • Microsoft SQL 2008 R2 Entreprise, 64 bits (RTM)

  • Microsoft SharePoint Server 2010 (RTM)

  • Charge équilibrée avec équilibrage de la charge réseau Windows

  • Mode intégration Reporting Services SharePoint

  • Reporting Services, avec montée en puissance parallèle

Spécification de l’application Web

Les scénarios décrits dans la procédure référencent un ensemble d’applications Web SharePoint Server 2010 que vous allez configurer dans le scénario 1. La charge des applications Web suivantes est équilibrée grâce à l’utilisation de l’équilibrage de la charge réseau Windows dans les deux serveurs Web frontaux SharePoint Server de l’environnement de démonstration :

• http://sp10CA   Application Web Administration centrale pour la batterie de serveurs. Le scénario 1 ne présente pas la configuration de cette application Web.

• http://portal et https://portal   Application Web avec portail de publication de démonstration. Elle permet de montrer comment configurer la délégation pour les applications Web qui s’exécutent sur des ports standard (HTTP 80, HTTPS 443).

• http://teams:5555   Application Web avec site d’équipe de démonstration. Elle permet de montrer comment configurer la délégation pour les applications Web qui s’exécutent sur des ports non standard, en l’occurrence le port 5555.

Configuration de SSL

Certains des scénarios de procédure utilisent SSL pour montrer comment configurer la délégation avec HTTPS. Il est supposé que les certificats utilisés proviennent d’une autorité de certification racine de confiance, interne ou publique, ou que vous avez configuré tous les ordinateurs de manière à approuver les certificats utilisés. Le document ne traite pas la configuration l’approbation de certificat et ne fournit pas d’aide sur la résolution des problèmes liés à l’installation d’un certificat SSL. Il est vivement recommandé de consulter ces rubriques et de tester la configuration de SSL avant de configurer la délégation Kerberos contrainte avec des services protégés par SSL. Pour plus d’informations, voir :

• Vue d’ensemble des services de certificats Active Directory (https://go.microsoft.com/fwlink/?linkid=196660&clcid=0x40C)

• Guide pas à pas sur les services de certificat Windows Server Active Directory (https://go.microsoft.com/fwlink/?linkid=196661&clcid=0x40C)

• Configuration des certificats de serveur dans IIS 7 (https://go.microsoft.com/fwlink/?linkid=196662&clcid=0x40C)

• Comment configurer SSL sur IIS 7> Configuration de la sécurité > Installation et configuration d’IIS 7 > Site Microsoft IIS officiel (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=193447&clcid=0x40C) (éventuellement en anglais)

• Ajouter une liaison à un site (IIS 7) (https://go.microsoft.com/fwlink/?linkid=196663&clcid=0x40C)

• Configurer un en-tête d’hôte pour un site Web (IIS 7) (https://go.microsoft.com/fwlink/?linkid=196664&clcid=0x40C) — (comment utiliser SSL avec des en-têtes d’hôte)

• Créer un certificat de serveur auto-signé dans IIS 7 (https://go.microsoft.com/fwlink/?linkid=196665&clcid=0x40C)

Équilibrage de charge

L’équilibrage de charge sur les serveurs SharePoint Web frontaux et les serveurs SQL Server Reporting Services a été implémenté en utilisant l’équilibrage de la charge réseau (NLB, Network Load Balancing) de Windows Server 2008. Les pratiques recommandées pour configurer NLB sont présentées dans ce document. Pour plus d’informations sur NLB, voir Vue d’ensemble de l’équilibrage de la charge réseau.

Alias SQL

La batterie de serveurs a été créée à l’aide d’un alias de client SQL permettant de se connecter au cluster SQL. Cette procédure correspond généralement à une meilleure pratique et vise à montrer comment l’authentification Kerberos est configurée lorsque des alias SQL sont utilisés. Le scénario 2 suppose que l’environnement est configuré de cette manière, mais il n’est pas nécessaire d’utiliser des alias SQL pour accomplir les scénarios ci-après. Pour plus d’informations sur la configuration d’alias SQL, voir Procédure : création d’un alias de serveur devant être utilisé par un client (SQL Server Configuration Manager).

Conseils pour parcourir les scénarios

Les scénarios ci-après présentent différentes activités nécessaires à la configuration de la délégation Kerberos dans différentes fonctions de la plateforme SharePoint Server. Dans chaque section :

Tous les scénarios supposent que vos applications Web sont configurées pour l’authentification classique entrante (Kerberos). Certains scénarios ci-après requièrent l’authentification classique et ne fonctionnent pas tels que documentés avec l’authentification par revendications entrante.

• Dans un premier temps, faites fonctionner les services SharePoint Server sans délégation pour vous assurer que les applications de service sont configurées correctement avant de passer à des configurations plus complexes faisant appel à la délégation.

• Accordez une attention particulière à chaque étape et évitez d’ignorer des étapes.

• Parcourez le scénario 1, puis consacrez du temps à l’utilisation des outils de débogage mentionnés dans le scénario, car ils peuvent servir dans d’autres scénarios pour hiérarchiser les problèmes de configuration.

• Pensez à parcourir le scénario 2. Vous aurez besoin d’un ordinateur exécutant SQL Server et configuré pour accepter l’authentification Kerberos et devrez utiliser la base de données de test que vous configurez dans ce scénario dans certains des scénarios ultérieurs.

• Revérifiez toujours la configuration des noms principaux de service dans chaque scénario à l’aide de SetSPN -X et SetSPN -Q. Pour plus d’informations, voir l’annexe.

• Consultez systématiquement les journaux des événements serveur et les journaux du service ULS lorsque vous essayez de résoudre un problème de configuration. Ces journaux comportent généralement des indications pertinentes et précises sur les problèmes qui se sont produits.

• Consultez la journalisation des diagnostics pour l’authentification par revendications dans SharePoint Foundation et pour toute application de service dont vous devez définir la priorité en cas de problème.

• Gardez à l’esprit que la mise en cache des applications de service peut avoir une incidence sur chaque scénario. Si vous apportez des modifications à la configuration, mais que le comportement de la plateforme demeure inchangé, essayez de redémarrer le service Windows ou le pool d’applications du service. Si cette opération est sans effet, un redémarrage du système peut s’avérer utile.

• Gardez à l’esprit que les tickets Kerberos sont mis en cache une fois demandés. Si vous utilisez un outil tel que NetMon pour afficher les demandes TGT et TGS, vous pouvez être amené à vider le cache de tickets si le trafic de demandes attendu n’apparaît pas. Le scénario 1, Configuration de l’authentification Kerberos : configuration de base (SharePoint Server 2010), explique comment procéder avec les utilitaires KLIST et KerbTray.

• Pensez à exécuter NetMon avec des privilèges d’administrateur pour capturer le trafic Kerberos.

• Dans le cadre des scénarios de débogage avancés, vous pouvez activer le suivi WIF pour le service d’émission de jetons Revendications vers Windows et le suivi WCF pour les applications de service SharePoint (services WCF). Voir :

  • Suivi WIF

  • Procédure : activer le suivi

  • Configuration du suivi