Planifier l’authentification Kerberos dans SharePoint Server
S’APPLIQUE À :
2013 2016 2019 Édition d’abonnement 
SharePoint dans Microsoft 365
Le protocole Kerberos prend en charge une méthode d'authentification qui utilise des tickets fournis par une source authentifiée. Les tickets Kerberos indiquent que les informations d'identification réseau d'un utilisateur associé à un ordinateur client ont été authentifiées. Le protocole Kerberos définit la façon dont les utilisateurs interagissent avec un service réseau pour avoir accès aux ressources du réseau. Le centre de distribution de clés (KDC) Kerberos émet un ticket TGT (ticket-granting-ticket) sur un ordinateur client de la part d'un utilisateur. Dans Windows, l'ordinateur client est membre d'un domaine AD DS (Active Directory Domain Services) et le ticket TGT prouve que le contrôleur de domaine a authentifié les informations d'identification utilisateur.
Avant d'établir une connexion réseau avec un service réseau, l'ordinateur client présente son ticket TGT au KDC et demande un ticket de service. En fonction du TGT émis précédemment, qui confirme que l'ordinateur client a été authentifié, le KDC émet un ticket de service sur l'ordinateur client. L'ordinateur client soumet ensuite le ticket de service au service réseau. Le ticket de service doit également contenir un nom de principal du service (SPN) acceptable qui identifie le service. Pour activer l'authentification Kerberos, les ordinateurs client et serveur doivent disposer déjà d'une connexion approuvée au KDC. Les ordinateurs client et serveur doivent également pouvoir accéder à AD DS.
Authentification Kerberos et SharePoint Server
Voici les avantages de l’authentification Kerberos :
Le protocole Kerberos est le protocole d'authentification Windows intégrée le plus fort et prend en charge des fonctionnalités avancées de sécurité, notamment le chiffrement AES (Advanced Encryption Standard) et l'authentification mutuelle de clients et de serveurs.
Le protocole Kerberos autorise la délégation des informations d'identification du client.
Parmi les méthodes d'authentification sécurisée disponibles, Kerberos est celle qui nécessite le moins de trafic réseau vers les contrôleurs de domaine AD DS. Suivant les scénarios, Kerberos peut réduire la latence des pages ou augmenter le nombre de pages qu'un serveur web frontal peut servir. Kerberos peut également réduire la charge sur les contrôleurs de domaine.
Kerberos est un protocole ouvert qui est pris en charge par de nombreuses plateformes et par de nombreux fournisseurs.
Voici les inconvénients de l’authentification Kerberos :
Contrairement à d’autres méthodes d’authentification, l’authentification Kerberos nécessite une configuration supplémentaire de l’infrastructure et de l’environnement pour fonctionner correctement. Dans de nombreux cas, une autorisation d’administrateur de domaine est requise pour configurer l’authentification Kerberos qui peut être difficile à configurer et à gérer. Une mauvaise configuration de Kerberos peut entraîner l'échec de l'authentification auprès de vos sites.
L'authentification Kerberos nécessite que l'ordinateur client dispose d'une connexion à un centre de distribution de clés (KDC) et à un contrôleur de domaine des services de domaine Active Directory (AD DS, Active Directory Domain Services). Dans un déploiement Windows et SharePoint, le KDC est un contrôleur de domaine AD DS. Bien qu'il s'agisse d'une configuration réseau courante dans l'intranet d'une organisation, les déploiements exposés à Internet ne sont généralement pas configurés de la sorte.
Délégation Kerberos
L'authentification Kerberos prend en charge la délégation de l'identité des clients. Cela signifie qu'un service peut emprunter l'identité d'un client authentifié. L'emprunt d'identité permet à un service de transmettre l'identité authentifiée à d'autres services réseau pour le compte du client. L'authentification basée sur les revendications permet également de déléguer les informations d'identification clientes, mais nécessite que l'application principale soit compatible avec les revendications.
Utilisée avec SharePoint Server, la délégation Kerberos permet à un service frontal d'authentifier un client, puis d'utiliser l'identité du client pour s'authentifier auprès d'un système principal. Ce dernier procède ensuite à sa propre authentification. Lorsqu'un client utilise l'authentification Kerberos pour s'authentifier auprès d'un service frontal, la délégation Kerberos permet de transmettre l'identité du client à un système principal. Le protocole Kerberos prend en charge deux types de délégations :
délégation Kerberos de base (non contrainte) ;
délégation Kerberos contrainte ;
délégation Kerberos de base et délégation Kerberos contrainte.
La délégation Kerberos de base peut traverser les frontières de domaine au sein de la même forêt, mais ne peut pas franchir une frontière de forêt. La délégation Kerberos contrainte ne peut pas traverser les frontières de domaine ou de forêt, sauf si vous utilisez des contrôleurs de domaine qui s'exécutent sur Windows Server 2012.
Suivant les applications de service qui font partie d’un déploiement SharePoint Server, l’implémentation des authentifications Kerberos avec SharePoint Server peut nécessiter la délégation Kerberos contrainte.
Importante
Pour déployer l’authentification Kerberos avec l’une des applications de service suivantes, SharePoint Server et toutes les sources de données externes doivent résider dans le même domaine Windows : > Excel Services > PerformancePoint Services > InfoPath Forms Services > Visio Services > Ces applications de service ne sont pas disponibles dans SharePoint Foundation 2013. Excel Services n'est pas disponible dans SharePoint Server 2016.
Pour le déploiement de l’authentification Kerberos avec l’une des applications de service ou l’un des produits suivants, SharePoint Server peut utiliser la délégation Kerberos de base ou la délégation Kerberos contrainte :
Service Business Data Connectivity (cette application de service n'est pas disponible dans SharePoint Foundation 2013)
Access Services (cette application de service n'est pas disponible dans SharePoint Foundation 2013)
SQL Server Reporting Services (SSRS) (produit séparé)
Project Server 2016 (produit séparé)
Les services qui sont activés pour l'authentification Kerberos peuvent déléguer l'identité plusieurs fois. À 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 Kerberos de base à la délégation Kerberos contrainte. L'inverse est impossible. La méthode de délégation ne peut pas passer de la délégation Kerberos contrainte à la délégation Kerberos de base. Il est donc important de déterminer à l'avance si un service principal nécessitera la délégation Kerberos de base. Cela peut avoir une incidence sur la planification et la conception des frontières de domaine.
Un service activé pour Kerberos peut utiliser la transition de protocole pour convertir une identité non-Kerberos en une identité Kerberos pouvant être déléguée à d'autres services activés pour Kerberos. Cette fonctionnalité permet, par exemple, de déléguer une identité non-Kerberos depuis un service frontal à une identité Kerberos sur un service principal.
Importante
La transition de protocole nécessite la délégation Kerberos contrainte. Ainsi, les identités ayant subi une transition de protocole ne peuvent pas traverser de frontières entre domaines.
L'authentification basée sur les revendications peut être utilisée à la place de la délégation Kerberos. L'authentification basée sur les revendications permet la transmission de la revendication de l'authentification d'un client entre des services différents si ceux-ci satisfont à tous les critères suivants :
Il existe une relation d’approbation entre les services.
Les services doivent prendre en charge les revendications.
Pour plus d’informations sur l’authentification Kerberos, voir les ressources suivantes :
Authentification Kerberos et authentification basée sur les revendications
SharePoint 2013 et SharePoint Server 2016 prennent en charge l'authentification basée sur les revendications. Celle-ci repose sur Windows Identity Foundation (WIF), ensemble de classes .NET Framework servant à implémenter l'identité basée sur les revendications. L'authentification basée sur les revendications repose sur des normes telles que WS-Federation et WS-Trust. Pour plus d'informations sur l'authentification basée sur les revendications, voir les ressources suivantes :
Quand vous créez une application web UNRESOLVED_TOKEN_VAL(SharePoint Server) en utilisant l'Administration centrale, vous devez sélectionner un ou plusieurs types d'authentifications basées sur les revendications. Quand vous créez une application web UNRESOLVED_TOKEN_VAL(SharePoint Server) en utilisant l'applet de commande New-SPWebApplication Microsoft PowerShell, vous pouvez indiquer l'authentification par revendications et les types d'authentifications par revendications ou l'authentification en mode classique. L'authentification par revendications est recommandée pour toutes les applications web UNRESOLVED_TOKEN_VAL(SharePoint Server). Avec cette authentification, tous les types d'authentifications pris en charge sont disponibles pour vos applications web et vous pouvez bénéficier de l'authentification de serveur à serveur et de l'authentification d'application. Pour plus d'informations, voir What's new in authentication for SharePoint Server 2013.
Importante
The following service applications in SharePoint Server require the translation of claims-based credentials to Windows credentials. Ce processus de traduction utilise le service c2WTS (Claims to Windows Token Service) : >Excel Services>PerformancePoint Services>InfoPath Forms Services>Visio Services>> Ces applications de service ne sont pas disponibles dans SharePoint Foundation 2013. Excel Services is not available in SharePoint Server 2016.
Les applications de service qui nécessitent le C2WTS doivent utiliser la délégation Kerberos contrainte, car C2WTS nécessite une transition de protocole, qui n’est prise en charge que par la délégation Kerberos contrainte. Pour les applications de service de la liste précédente, C2WTS traduit les revendications au sein de la batterie en informations d’identification Windows pour l’authentification sortante. Il est important de comprendre que ces applications de service peuvent utiliser le C2WTS uniquement si la méthode d’authentification entrante est des revendications Windows ou du mode Classique Windows. Les applications de service accessibles via des applications web et qui utilisent des revendications SAML (Security Assertion Markup Language) ou des revendications d’authentification basée sur des formulaires n’utilisent pas le C2WTS. Par conséquent, ils ne peuvent pas traduire les revendications en informations d’identification Windows.
L’authentification Kerberos et le nouveau modèle d’application SharePoint
Si vous utilisez le mode de revendications Windows pour l'authentification d'utilisateur et que l'application web est configurée pour utiliser uniquement l'authentification Kerberos sans revenir au protocole d'authentification NTLM, l'authentification d'application ne fonctionne pas. Pour plus d'informations, voir Planifier l'authentification d'application dans SharePoint Server.
Voir aussi
Concepts
Planifier les méthodes d'authentification utilisateur dans SharePoint Server