Vue d’ensemble de l’authentification Kerberos pour les Produits Microsoft SharePoint 2010

 

S’applique à : SharePoint Server 2010

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

Les Produits Microsoft SharePoint 2010 introduisent des améliorations sensibles dans la manière dont l’identité est gérée dans la plateforme. Il est important de comprendre comment ces changements affectent la conception de solution et la configuration de plateforme pour activer des scénarios qui nécessitent la délégation de l’identité utilisateur à des systèmes intégrés. Le protocole Kerberos version 5 joue un rôle majeur dans l’activation de la délégation et est parfois obligatoire dans ces scénarios.

Cet ensemble d’articles fournit des informations qui vous aideront à :

• comprendre les concepts d’identité dans les Produits SharePoint 2010 ;

• découvrir dans quelle mesure l’authentification Kerberos joue un rôle très important dans les scénarios d’authentification et de délégation ;

• identifier les situations dans lesquelles l’authentification Kerberos doit être utilisée ou peut être nécessaire dans les conceptions de solutions ;

• configurer l’authentification Kerberos de bout en bout dans votre environnement, y compris dans des scénarios qui font appel à différentes applications de service dans SharePoint Server ;

• tester et valider le fait que l’authentification Kerberos est configurée correctement et fonctionne comme prévue ;

• trouver des outils et ressources supplémentaires pour vous aider à configurer l’authentification Kerberos dans votre environnement.

Cet ensemble d’articles est divisé en deux sections principales :

• Cette présentation de l’authentification Kerberos dans les Produits SharePoint 2010

  Cet article contient des informations conceptuelles sur la façon de gérer l’identité dans Produits SharePoint 2010, sur le protocole Kerberos et sur la façon dont l’authentification Kerberos joue un rôle clé dans les solutions SharePoint 2010.

• Configuration pas à pas

  Ce groupe d’articles traite des étapes nécessaires à la configuration de la délégation et de l’authentification Kerberos dans différents scénarios de solution SharePoint.

À qui ces articles relatifs à l’authentification Kerberos sont-ils destinés ?

L’identité et la délégation dans Produits SharePoint 2010 sont un sujet très vaste, avec de nombreuses subtilités et niveaux de compréhension. Cet ensemble d’articles traite de ce sujet aux niveaux conceptuel et technique. Il a été rédigé de manière à répondre aux besoins de divers publics :

De bout en bout

« Dites-moi tout ce qu’il y a à savoir concernant l’identité et l’authentification Kerberos dans Produits SharePoint 2010 »

Si vous débutez et découvrez seulement Produits SharePoint 2010, l’authentification Kerberos et l’authentification par revendications, nous vous conseillons de lire la première section de ce document. Elle traite des concepts de base de l’identité et de la délégation et offre une vue d’ensemble de l’authentification par revendications et de l’authentification Kerberos. Assurez-vous de suivre les liens vers les articles externes et les informations supplémentaires pour approfondir vos connaissances avant de poursuivre et d’aborder les articles de configuration pas à pas.

Mise à niveau à partir d’Office SharePoint Server 2007

« Dites-moi ce qui a changé par rapport à la version 2007 et ce que je dois préparer en vue de la mise à niveau vers la version 2010 »

Si vous avez un environnement Microsoft Office SharePoint Server 2007 existant déjà configuré de façon à utiliser l’authentification et la délégation Kerberos, vous devez lire les articles suivants :

• Scénarios d'identité dans les Produits SharePoint 2010

• Vue d’ensemble des revendications

• Modifications relatives à l'authentification Kerberos dans Windows 2008 R2 et Windows 7

• Modifications relatives à la configuration Kerberos dans les Produits SharePoint 2010

• Considérations relatives à la mise à niveau à partir de SharePoint Server 2007

Si vous avez des questions supplémentaires sur la manière de configurer la délégation pour un scénario ou une fonctionnalité spécifique, consultez les articles de configuration pas à pas, notamment les listes de vérification de configuration. Cela vous aidera à vous assurer que votre environnement est configuré correctement après la mise à niveau.

Procédure pas à pas

« Je souhaite obtenir des instructions détaillées sur la manière de configurer la délégation Kerberos dans SharePoint Server et dans les applications de service SharePoint Server applicables »

Les articles de configuration pas à pas traitent de plusieurs scénarios de Produits SharePoint 2010 qui peuvent être configurés de façon à utiliser la délégation Kerberos. Chaque scénario est traité en détail, avec notamment une liste de vérification de configuration et des instructions pas à pas pour vous aider à configurer l’authentification Kerberos dans votre environnement. Les scénarios traités sont les suivants :

• Scénario 1 : configuration principale

• Scénario 2 : authentification Kerberos pour SQL OLTP

• Scénario 3 : authentification Kerberos pour SQL Analysis Services

• Scénario 4 : délégation d’identité pour SQL Reporting Services

• Scénario 5 : délégation d’identité pour Excel Services

• Scénario 6 : délégation d’identité pour PowerPivot pour SharePoint 2010

• Scénario 7 : délégation d’identité pour Visio Services

• Scénario 8 : délégation d’identité pour Performance Point Services

• Scénario 9 : délégation d’identité pour Business Connectivity Services

Veillez à étudier soigneusement le premier scénario de configuration principal, car il s’agit d’une condition requise pour tous les scénarios qui suivent.

Environnements de Produits SharePoint 2010 existants

« Je possède un environnement de Produits SharePoint 2010 existant et je ne parviens pas à faire fonctionner l’authentification Kerberos. Comment faire pour valider et déboguer ma configuration ? »

Les articles Configuration pas à pas contiennent plusieurs listes de vérification pour vous aider à trier votre environnement dans divers scénarios. Apportez une attention particulière au Scénario 1, Configuration principale, qui traite des techniques et outils de base pour trier la configuration Kerberos.

Scénarios d’identité dans les Produits SharePoint 2010

Lorsque l’on étudie l’identité dans le contexte de l’authentification dans Produits SharePoint 2010, on peut examiner d’un point de vue conceptuel la façon dont la plateforme gère l’identité dans trois scénarios principaux : authentification entrante, authentification intrabatterie/entre batteries et authentification sortante.

Identité entrante

Le scénario d’authentification entrante représente le moyen par lequel un client présente son identité à la plateforme ou, autrement dit, s’authentifie auprès de l’application Web ou du service Web. SharePoint Server utilisera l’identité du client pour l’autoriser à accéder aux ressources sécurisées SharePoint Server telles que les pages Web, documents et ainsi de suite.

Produits SharePoint 2010 prend en charge deux modes dans lesquels un client peut s’authentifier auprès de la plateforme : le mode Classique et le mode Revendications.

Mode Classique

Le mode Classique autorise les méthodes d’authentification IIS (Internet Information Services) ordinaires que vous utilisez peut-être déjà dans une version précédente de SharePoint Server. Lorsqu’une application Web SharePoint Server 2010 est configurée de façon à utiliser le mode Classique, vous avez la possibilité d’utiliser les méthodes d’authentification IIS suivantes :

Authentification Windows intégrée

L’authentification Windows intégrée permet aux clients Windows de s’authentifier de façon transparente auprès de SharePoint Server sans avoir à fournir d’informations d’identification (nom d’utilisateur/mot de passe) manuellement. Les utilisateurs qui accèdent à SharePoint Server depuis Internet Explorer s’authentifient à l’aide des informations d’identification sous lesquelles le processus Internet Explorer s’exécute, à savoir par défaut celles que l’utilisateur a employées pour se connecter au Bureau. Les services ou applications qui accèdent à SharePoint Server en mode d’authentification Windows intégrée tentent de s’authentifier à l’aide des informations d’identification du thread en cours d’exécution qui, par défaut, correspondent à l’identité du processus.

NTLM

NT LAN Manager (NTLM) est le type de protocole par défaut lorsque l’authentification Windows intégrée est sélectionnée. Ce protocole fait appel à une séquence stimulation-réponse en trois parties pour authentifier les clients. Pour plus d’informations sur NTLM, voir Microsoft NTLM (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=196643&clcid=0x40C) (éventuellement en anglais).

Avantages :

• Il est facile à configurer et ne nécessite en général aucune configuration d’environnement/infrastructure supplémentaire.

• Il fonctionne lorsque le client n’appartient à aucun domaine ou n’est pas membre d’un domaine approuvé par le domaine dans lequel réside SharePoint Server.

Inconvénients :

• SharePoint Server doit contacter le contrôleur de domaine chaque fois qu’une réponse d’authentification de client nécessite une validation, ce qui accroît le trafic vers les contrôleurs de domaine.

• Il n’autorise pas la délégation des informations d’authentification clientes vers les systèmes principaux, également appelée règle de double saut.

• Il s’agit d’un protocole propriétaire.

• Il ne prend pas en charge l’authentification de serveur.

• Il est considéré comme moins sécurisé que l’authentification Kerberos.

Protocole Kerberos

Le protocole Kerberos est un protocole plus sécurisé qui prend en charge l’authentification par ticket. Un serveur d’authentification Kerberos accorde un ticket en réponse à une requête d’authentification d’un ordinateur client, si la requête contient des informations d’identification utilisateur et un nom de principal du service valides. L’ordinateur client utilise ensuite ce ticket pour accéder aux ressources du réseau. Pour activer l’authentification Kerberos, les ordinateurs client et serveur doivent disposer d’une connexion approuvée au centre de distribution de clés du domaine. Ce centre distribue les clés secrètes partagées pour permettre le chiffrement. Les ordinateurs client et serveur doivent également pouvoir accéder aux services de domaine Active Directory (AD DS, Active Directory Domain Services). Pour Active Directory, le domaine racine de la forêt est le centre des références d’authentification Kerberos. Pour plus d’informations sur le protocole Kerberos, voir Fonctionnement du protocole d’authentification Kerberos Version 5 (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=196644&clcid=0x40C) (éventuellement en anglais) et Microsoft Kerberos (éventuellement en anglais). (https://go.microsoft.com/fwlink/?linkid=196645&clcid=0x40C) (éventuellement en anglais)

Avantages :

• Protocole d’authentification Windows intégrée le plus sécurisé

• Autorise la délégation des informations d’identification clientes

• Prend en charge l’authentification mutuelle des clients et des serveurs

• Génère moins de trafic vers les contrôleurs de domaine

• Protocole ouvert pris en charge par de nombreux fournisseurs et plateformes

Inconvénients :

• Son bon fonctionnement nécessite une configuration supplémentaire de l’infrastructure et de l’environnement

• Nécessite des clients disposant d’une connectivité au centre de distribution de clés (contrôleur de domaine Active Directory dans les environnements Windows) sur le port 88 TCP/UDP (Kerberos) et le port 464 TCP/UDP (Kerberos Modifier le mot de passe – Windows)

Autres méthodes

Outre l’authentification Kerberos et NTLM, SharePoint Server prend en charge d’autres types d’authentification IIS tels que l’authentification de base, Digest et basée sur certificat, qui ne sont pas traités dans ce document. Pour plus d’informations sur le fonctionnement de ces protocoles, voir Méthodes d’authentification prises en charge dans IIS 6.0 (IIS 6.0) (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=196646&clcid=0x40C) (éventuellement en anglais).

Authentification basée sur les revendications

La prise en charge de l’authentification par revendications est une nouvelle fonctionnalité de Produits SharePoint 2010 qui repose sur Windows Identity Foundation (WIF). Dans un modèle de revendications, SharePoint Server accepte une ou plusieurs revendications relatives à un client afin de l’identifier et de l’autoriser. Les revendications se présentent sous la forme de jetons SAML ; il s’agit de faits relatifs au client qui sont déclarés par une autorité de confiance. Par exemple, une revendication pourrait indiquer « Bob est membre du groupe Administrateurs de l’entreprise pour le domaine Contoso.com. » Si cette revendication provient d’un fournisseur approuvé par SharePoint Server, la plateforme peut utiliser ces informations pour authentifier Bob et l’autoriser à accéder à des ressources SharePoint Server. Pour plus d’informations sur l’authentification par revendications, voir Guide du contrôle d’accès et de l’identité basée sur les revendications (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=187911&clcid=0x40C) (éventuellement en anglais).

Les genres de revendications pris en charge par Produits SharePoint 2010 pour l’authentification entrante sont les suivants : revendications Windows, revendications d’authentification basée sur les formulaires et revendications SAML.

Revendications Windows

En mode de connexion basée sur les revendications Windows, SharePoint Server authentifie le client à l’aide de l’authentification Windows intégrée standard (NTLM/Kerberos), puis traduit l’identité Windows résultante en identité de revendications.

Revendications d’authentification basée sur les formulaires

En mode de revendications d’authentification basée sur les formulaires, SharePoint Server redirige le client vers une page d’ouverture de session qui héberge les contrôles d’ouverture de session ASP.NET standard. La page authentifie le client à l’aide de fournisseurs de rôle et d’appartenance ASP.NET, de manière semblable au fonctionnement de l’authentification basée sur les formulaires dans Office SharePoint Server 2007. Une fois que l’objet d’identité qui représente l’utilisateur a été créé, SharePoint Server traduit cette identité en un objet d’identité de revendications.

Revendications SAML

En mode de revendications SAML, SharePoint Server accepte les jetons SAML provenant d’un fournisseur de jetons de sécurité externe de confiance. Lorsque l’utilisateur tente d’ouvrir une session, il est dirigé vers un fournisseur de revendications externe (par exemple le fournisseur de revendications Windows Live ID) qui authentifie l’utilisateur et génère un jeton SAML. SharePoint Server accepte et traite ce jeton et il augmente les revendications et crée un objet d’identité de revendications pour l’utilisateur.

Pour plus d’informations sur l’authentification basée sur les revendications dans Produits SharePoint 2010, voir Identité basée sur des revendications SharePoint.

Remarque relative à l’authentification entrante par revendications et le Service d’émission de jetons Revendications vers Windows (C2WTS)

Certaines applications de service requièrent l’utilisation du Service d’émission de jetons Revendications vers Windows (C2WTS) de Windows Identity Foundation (WIF) pour traduire les revendications dans la batterie en informations d’identification Windows pour l’authentification sortante. Il est important de comprendre que le service C2WTS fonctionne uniquement si la méthode d’authentification entrante est le mode Classique ou les revendications Windows. Si les revendications sont configurées, le service C2WTS nécessite uniquement des revendications Windows ; l’application Web ne peut pas utiliser plusieurs formes de revendications sur l’application Web, sinon le service C2WTS ne fonctionne pas.

Identité dans un environnement des Produits SharePoint 2010

Les environnements des Produits SharePoint 2010 utilisent l’authentification par revendications pour les communications intrabatterie et entre batteries avec la plupart des applications de service SharePoint et produits intégrés SharePoint, quel que soit le mécanisme d’authentification entrante utilisé. Cela signifie que même lorsque l’authentification classique est utilisée pour effectuer l’authentification auprès d’une application Web spécifique, les Produits SharePoint convertissent l’identité entrante en identité de revendications afin de réaliser l’authentification auprès des produits et applications de service SharePoint compatibles avec les revendications. En normalisant le modèle de revendications pour les communications intrabatterie et entre batteries, la plateforme peut s’abstraire des protocoles entrants utilisés.

Identité sortante

L’identité sortante dans les Produits SharePoint 2010 représente les scénarios dans lesquels des services de la batterie doivent s’authentifier auprès de services et de systèmes métiers externes. En fonction du scénario, l’authentification peut être effectuée selon l’un des deux modèles conceptuels de base suivants :

Sous-système approuvé

Dans le sous-système approuvé, le service frontal authentifie et autorise le client, puis s’authentifie auprès des services principaux supplémentaires sans passer l’identité du client au système principal. Ce dernier approuve le service frontal pour procéder à l’authentification et à l’autorisation en son nom. Le moyen le plus courant d’implémenter ce modèle consiste à utiliser un compte de service partagé pour s’authentifier auprès du système externe :

Dans SharePoint Server, ce modèle peut être implémenté de différentes manières :

• À l’aide de l’identité du pool d’applications IIS. Cela s’obtient généralement en exécutant du code dans l’application Web qui élève les autorisations lors d’un appel à un système externe. D’autres méthodes telles que RevertToSelf peuvent également utiliser l’identité du pool d’applications pour réaliser l’authentification auprès de systèmes externes.

• À l’aide d’un compte de service. Cela s’obtient généralement en stockant les informations d’identification d’applications dans la Banque d’informations sécurisée, puis en utilisant ces informations pour s’authentifier auprès d’un système externe. Il est également possible de stocker les informations d’identification du compte de service d’autres manières, par exemple avec des chaînes de connexion incorporées.

• Authentification anonyme, lorsque le système externe ne nécessite aucune authentification. Dans ce cas, le service SharePoint Server frontal ne doit passer aucune identité au système principal.

Délégation

Dans le modèle de délégation, le service frontal authentifie d’abord le client, puis utilise son identité pour s’authentifier auprès d’un autre système principal qui effectue ses propres authentification et autorisation :

Dans les Produits SharePoint 2010, ce modèle peut être implémenté de différentes manières :

• Délégation Kerberos. Si le client s’authentifie auprès du service frontal à l’aide de l’authentification Kerberos, la délégation Kerberos peut être utilisée pour passer l’identité du client au système principal.

• Revendications. L’authentification par revendications autorise le passage des revendications du client entre des services, du moment qu’il existe une approbation entre les deux services et qu’ils sont compatibles avec les revendications.

Délégation à travers les frontières de domaines et de forêts

Les scénarios décrits dans cet ensemble d’articles relatifs à l’authentification Kerberos requièrent que le service SharePoint Server et les sources de données externes résident dans le même domaine Windows, ce qui est obligatoire pour la délégation Kerberos contrainte. Le protocole Kerberos prend en charge deux genres de délégations : la délégation de base (sans contrainte) et la délégation contrainte. La délégation Kerberos de base peut traverser des frontières de domaines dans une même forêt, mais ne peut pas traverser de frontière de forêt, quelle que soit la relation d’approbation. La délégation Kerberos contrainte ne peut traverser de frontière de domaine ou de forêt dans aucun scénario.

Certains services SharePoint Server peuvent être configurés de façon à utiliser la délégation Kerberos de base, mais d’autres services requièrent le recours à la délégation contrainte. Tout service qui repose sur le Service d’émission de jetons Revendications vers Windows (C2WTS) doit utiliser la délégation Kerberos contrainte afin de permettre au service C2WTS d’utiliser la transition de protocole Kerberos pour traduire les revendications en informations d’identification Windows.

Les produits et applications de service suivants nécessitent le service C2WTS et la délégation Kerberos contrainte :

• Excel Services

• PerformancePoint Services

• InfoPath Forms Services

• Visio Services

Les produits et applications de service suivants ne sont pas affectés par ces exigences et peuvent par conséquent recourir à la délégation de base, si nécessaire :

• Service Business Data Connectivity et Services Microsoft Business Connectivity

• Services d’accès

• Microsoft SQL Server Reporting Services (SSRS)

• Microsoft Project Server 2010

L’application de service suivante n’autorise pas la délégation des informations d’identification clientes et n’est par conséquent pas affectée par ces exigences :

• Microsoft SQL Server PowerPivot pour Microsoft SharePoint

Vue d’ensemble des revendications

Pour obtenir une introduction aux concepts de revendications et à l’authentification basée sur les revendications, voir Introduction aux revendications (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=196648&clcid=0x40C) (éventuellement en anglais) and Identité basée sur des revendications SharePoint (https://go.microsoft.com/fwlink/?linkid=196647&clcid=0x40C).

Vue d’ensemble du protocole Kerberos

Pour obtenir une vue d’ensemble conceptuelle du protocole Kerberos, voir Microsoft Kerberos (Windows) (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=196645&clcid=0x40C) (éventuellement en anglais), Kerberos : explications (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=196649&clcid=0x40C) (éventuellement en anglais) et Ask the Directory Services Team : Kerberos pour les administrateurs débordés (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=196650&clcid=0x40C) (éventuellement en anglais).

Avantages du protocole Kerberos

Avant d’étudier en détail la manière de configurer SharePoint Server (ou toute application Web) de façon à utiliser le protocole Kerberos, examinons un peu ce qu’est ce protocole et pourquoi nous pourrions vouloir l’utiliser.

Il existe en général trois principales raisons d’utiliser le protocole Kerberos :

1. Délégation d’informations d’identification clientes — Le protocole Kerberos permet à un service d’emprunter l’identité d’un client afin de l’autoriser à passer cette identité à d’autres services réseau pour le compte du client. NTLM n’autorise pas cette délégation. (Cette limitation de NTLM porte le nom de « règle du double saut ».) L’authentification par revendications, comme l’authentification Kerberos, peut servir à déléguer des informations d’identification clientes mais nécessite que l’application principale soit compatible avec les revendications.

2. Sécurité — Des fonctionnalités telles que le chiffrement AES, l’authentification mutuelle ou la prise en charge de l’intégrité des données, pour n’en citer que quelques-unes, rendent le protocole Kerberos plus sûr que son homologue NTLM.

3. Des performances potentiellement plus élevées — L’authentification Kerberos requiert moins de trafic vers les contrôleurs de domaine, comparée à NTLM (selon la vérification PAC ; voir Microsoft Open Specification Support Team Blog : Présentation de la validation PAC Microsoft Kerberos (éventuellement en anglais)). Si la vérification PAC est désactivée ou n’est pas nécessaire, le service qui authentifie le client n’a pas à effectuer d’appel au contrôleur de domaine (voir : Vous observez un délai dans le processus d’authentification utilisateur lorsque vous exécutez un programme serveur à volume élevé sur un membre de domaine dans Windows 2000 ou Windows Server 2003). L’authentification Kerberos requiert également moins de trafic entre le client et le serveur, comparée à NTLM. Les clients peuvent s’authentifier auprès de serveurs Web en deux demandes/réponses, alors que la négociation NTLM s’effectue en trois étapes. Cette amélioration ne se remarque généralement pas sur les réseaux à faible latence si l’on examine chaque transaction, mais elle peut néanmoins s’observer dans le débit global du système. Souvenez-vous que de nombreux facteurs environnementaux peuvent affecter les performances d’authentification ; il convient par conséquent de tester les performances des authentifications Kerberos et NTLM dans votre propre environnement avant de déterminer si l’une des méthodes procure de meilleures performances que l’autre.

Cette liste des avantages offerts par l’utilisation du protocole Kerberos n’est pas exhaustive. Il existe d’autres raisons telles que l’authentification mutuelle, l’interopérabilité entre plateformes et l’approbation transitive entre domaines. Toutefois, dans la plupart des cas ce sont la délégation et la sécurité qui constituent les principaux facteurs d’adoption du protocole Kerberos.

Délégation Kerberos, délégation contrainte et transition de protocole

Le protocole Kerberos version 5 sur la plateforme Windows prend en charge deux genres de délégation d’identité : la délégation de base (sans contrainte) et la délégation contrainte :

Type	Avantages	Inconvénients
Délégation de base	Capable de traverser des frontières de domaines dans une même forêt. Nécessite moins de tâches de configuration que la délégation contrainte.	Ne prend pas en charge la transition de protocole. Sécurité. Si le service frontal est compromis, l’identité du client peut être déléguée à tout service dans la forêt qui accepte l’authentification Kerberos.
Délégation contrainte	Capable d’effectuer la transition du protocole d’authentification entrant non-Kerberos vers le protocole Kerberos (exemple : NTLM vers Kerberos, Revendications vers Kerberos). Plus sûre. Les identités ne peuvent être déléguées qu’au service spécifié.	Impossibilité de traverser des frontières de domaines. Nécessite une configuration supplémentaire.

Les services activés pour Kerberos peuvent déléguer l’identité à plusieurs reprises parmi plusieurs services et plusieurs sauts. À mesure qu’une identité se déplace de service en service, la méthode de délégation peut changer et passer de la délégation de base à la délégation contrainte, mais non l’inverse. Il est important de bien comprendre ce détail de conception : si un service principal requiert la délégation de base (par exemple pour déléguer de l’autre côté d’une frontière de domaine), tous les services situés devant le service principal doivent utiliser la délégation de base. Si l’un des services frontaux utilise la délégation contrainte, le service principal ne peut pas convertir le jeton contraint en jeton non contraint pour traverser une frontière de domaine.

La transition de protocole permet à un service d’authentification activé pour Kerberos (service frontal) de convertir une identité non-Kerberos en identité Kerberos susceptible d’être déléguée à d’autres services activés pour Kerberos (service principal). Étant donné qu’elle nécessite la délégation contrainte Kerberos, les identités ayant subi une transition de protocole ne peuvent pas traverser de frontières entre domaines. En fonction des droits utilisateur du service frontal, le ticket Kerberos renvoyé par la transition de protocole peut être un jeton d’identification ou un jeton d’emprunt d’identité. Pour plus d’informations sur la délégation contrainte et la transition de protocole, voir les articles suivants :

• Délégation contrainte et transition de protocole Kerberos (éventuellement en anglais) (https://technet.microsoft.com/fr-fr/library/cc739587(ws.10).aspx) (éventuellement en anglais)

• Supplément technique relatif à la transition de protocole avec délégation contrainte (éventuellement en anglais) (https://msdn.microsoft.com/fr-fr/library/ff650469.aspx) (éventuellement en anglais)

• La délégation contrainte Kerberos peut nécessiter une transition de protocole dans des scénarios à sauts multiples (éventuellement en anglais) (https://support.microsoft.com/kb/2005838/fr) (éventuellement en anglais)

En guise de meilleure pratique, si la délégation Kerberos est nécessaire il convient d’utiliser la délégation contrainte dans la mesure du possible. Si la délégation à travers les frontières de domaines est requise, tous les services situés dans l’itinéraire de délégation doivent utiliser la délégation de base.

Modifications relatives à l’authentification Kerberos dans Windows 2008 R2 et Windows 7

Windows Server 2008 R2 et Windows 7 introduisent de nouvelles fonctionnalités d’authentification Kerberos. Pour obtenir une vue d’ensemble de ces changements, voir Modifications apportées à l’authentification Kerberos (https://go.microsoft.com/fwlink/?linkid=196655&clcid=0x40C) et Améliorations apportées à l’authentification Kerberos (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=196656&clcid=0x40C) (éventuellement en anglais). Par ailleurs, vous devez vous familiariser avec l’authentification en mode noyau IIS 7,0 (Paramètres d’authentification en mode noyau Internet Information Services (IIS) 7.0 (éventuellement en anglais), (https://go.microsoft.com/fwlink/?linkid=196657&clcid=0x40C) (éventuellement en anglais)) même si elle n’est pas prise en charge dans les batteries SharePoint Server.

Modifications relatives à la configuration Kerberos dans les Produits SharePoint 2010

La plupart des concepts de base liés à la configuration de l’authentification Kerberos dans les Produits SharePoint 2010 n’ont pas changé. Il faut toujours configurer les noms de principal du service et les paramètres de délégation sur les comptes de services et d’ordinateurs. Toutefois, il convient de prendre note de certaines modifications :

• Délégation contrainte — elle est obligatoire pour les services qui utilisent le Service d’émission de jetons Revendications vers Windows. La délégation contrainte est nécessaire pour permettre à la transition de protocole de convertir les revendications en jetons Windows.

• Applications de service — Dans Office SharePoint Server 2007, les services SSP exigeaient des modifications de Registre de serveur et des noms de principal du service spéciaux pour activer la délégation. Dans les Produits SharePoint 2010, les applications de service utilisent l’authentification par revendications et le Service d’émission de jetons Revendications vers Windows ; ces modifications ne sont donc plus nécessaires.

• Windows Identity Foundation (WIF) — le Service d’émission de jetons Revendications vers Windows WIF (C2WTS) est un nouveau service qui permet aux Produits SharePoint 2010 de convertir des revendications en jetons Windows pour les scénarios de délégation.

Considérations relatives à la mise à niveau à partir de SharePoint Server 2007

Si vous mettez à niveau une batterie Office SharePoint Server 2007 vers SharePoint Server 2010, vous devez garder plusieurs éléments à l’esprit :

• Si des applications Web modifient des URL, assurez-vous de mettre à jour les noms de principal du service de façon à refléter les noms DNS.

• Supprimez les noms du principal du service d’émission de jetons Revendications vers Windows car ils ne sont plus nécessaires dans SharePoint Server 2010.

• Démarrez le Service d’émission de jetons Revendications vers Windows sur les serveurs qui exécutent des applications de service qui nécessitent une délégation (par exemple, Excel Services, Service Graphiques Visio).

• Configurez la délégation Kerberos contrainte avec l’option « Utiliser tout protocole d’authentification » afin d’autoriser la délégation Kerberos contrainte avec le service C2WTS.

• Assurez-vous que l’authentification en mode noyau est désactivée dans les services Internet (IIS).