Kerberos Constrained Delegation Overview

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cette rubrique de vue d’ensemble destinée aux professionnels de l’informatique décrit les nouvelles fonctionnalités de la délégation Kerberos contrainte dans Windows Server 2012 R2 et Windows Server 2012.

Description de la fonctionnalité

La délégation Kerberos contrainte a été introduite pour la première fois dans Windows Server 2003 pour fournir une forme de délégation plus sûre utilisable par les services. Lorsqu’elle est configurée, la délégation contrainte restreint les services sur lesquels le serveur spécifié peut agir pour le compte d’un utilisateur. Des droits d’administrateur de domaine sont requis pour configurer un compte de domaine pour un service et cela restreint le compte à un domaine unique. De nos jours, les services frontaux ne sont pas conçus pour être limités à une intégration aux seuls services dans leur domaine.

Dans les systèmes d’exploitation précédents sur lesquels l’administrateur de domaine a configuré le service, l’administrateur de service ne possédait aucun moyen de connaître les services frontaux qui déléguaient vers des services de ressources qu’ils détenaient. Et tout service frontal qui pouvait déléguer à un service de ressources représentait un point d’attaque potentiel. Si un serveur hébergeant un service frontal était compromis, et qu’il était configuré pour déléguer aux services de ressources, les services de ressources pouvaient également être compromis.

Dans Windows Server 2012 R2 et Windows Server 2012, la possibilité de configurer la délégation contrainte pour le service a été transférée de l’administrateur de domaine à l’administrateur de service. De cette façon, l’administrateur de service principal peut autoriser ou refuser les services frontaux.

Pour obtenir des informations détaillées sur la délégation contrainte telle qu’elle a été introduite dans Windows Server 2003, voir Transition du protocole Kerberos et délégation contrainte.

L’implémentation Windows Server 2012 R2 et Windows Server 2012 du protocole Kerberos inclut des extensions spécifiquement pour la délégation contrainte. Service for User to Proxy (S4U2Proxy) permet à un service d’utiliser son ticket de service Kerberos pour qu’un utilisateur obtienne un ticket de service à partir du centre de distribution de clés (KDC) pour un service principal. Ces extensions permettent de configurer la délégation contrainte sur le compte du service principal, lequel peut se trouver dans un autre domaine. Pour plus d’informations sur ces extensions, voir [MS-SFU] : extensions du protocole Kerberos : spécification du protocole de service pour l’utilisateur et de délégation contrainte dans MSDN Library.

Cas pratiques

La délégation contrainte fournit aux administrateurs de service la capacité de spécifier et d’appliquer des délimitations d’approbation d’application en limitant l’étendue dans laquelle les services d’application peuvent agir pour le compte d’un utilisateur. Les administrateurs de service peuvent spécifier les comptes de services frontaux qui peuvent effectuer une délégation sur leurs services principaux.

La prise en charge de la délégation contrainte sur plusieurs domaines dans Windows Server 2012 R2 et Windows Server 2012 permet aux services frontaux tels que Microsoft Internet Security and Acceleration (ISA) Server, Microsoft Forefront Threat Management Gateway, Microsoft Exchange Outlook Web Access (OWA) et Microsoft SharePoint Server d’être configurés pour utiliser la délégation contrainte pour s’authentifier auprès des serveurs dans d’autres domaines. Cela permet la prise en charge de solutions de service sur plusieurs domaines via une infrastructure Kerberos existante. La délégation Kerberos contrainte peut être gérée par les administrateurs de domaine ou les administrateurs de service.

Délégation contrainte basée sur les ressources sur plusieurs domaines

La délégation Kerberos contrainte peut être utilisée pour fournir une délégation contrainte lorsque les services frontaux et les services de ressources ne sont pas dans le même domaine. Les administrateurs de service sont en mesure de configurer la nouvelle délégation en spécifiant les comptes de domaine des services frontaux qui peuvent emprunter l’identité des utilisateurs sur les objets de compte des services de ressources.

Quels avantages cette modification procure-t-elle ?

En prenant en charge la délégation contrainte sur plusieurs domaines, les services peuvent être configurés pour utiliser la délégation contrainte pour s’authentifier auprès des serveurs dans d’autres domaines plutôt qu’utiliser une délégation non contrainte. Cela permet la prise en charge de l’authentification pour des solutions de service sur plusieurs domaines via une infrastructure Kerberos existante sans qu’il soit nécessaire d’approuver les services frontaux pour effectuer une délégation à un service quelconque.

Cela déplace également la décision de décider si un serveur doit approuver la source d’une identité déléguée de l’administrateur de domaine délégué au propriétaire de la ressource.

En quoi le fonctionnement est-il différent ?

Une modification dans le protocole sous-jacent permet la délégation contrainte sur plusieurs domaines. L’implémentation du protocole Kerberos dans Windows Server 2012 R2 et Windows Server 2012 inclut des extensions du protocole S4U2Proxy (Service for User to Proxy). Il s’agit d’un ensemble d’extensions au protocole Kerberos qui permettent à un service d’utiliser son ticket de service Kerberos pour qu’un utilisateur obtienne un ticket de service à partir du centre de distribution de clés (KDC) pour un service principal.

Pour obtenir des informations d’implémentation concernant ces extensions, consultez [MS-SFU] : extensions du protocole Kerberos : spécification du protocole de service pour l’utilisateur et de délégation contrainte dans MSDN.

Pour plus d’informations sur la séquence de message de base pour la délégation Kerberos avec un ticket TGT (Ticket-Granting Ticket) transmis par rapport aux extensions S4U (Service for User), reportez-vous à la section 1.3.3 Vue d’ensemble du protocole dans le document [MS-SFU] : extensions du protocole Kerberos : spécification du protocole de service pour l’utilisateur et de délégation contrainte.

Implications de sécurité de la délégation contrainte basée sur les ressources

La délégation contrainte basée sur les ressources place le contrôle de la délégation entre les mains de l’administrateur propriétaire de la ressource accessible. Elle dépend des attributs du service de ressource plutôt que du service approuvé pour déléguer. Par conséquent, la délégation contrainte basée sur les ressources ne peut pas utiliser le bit Trusted-to-Authenticate-for-Delegation qui contrôlait précédemment la transition de protocole. Le centre de distribution de clés (KDC) autorise toujours la transition de protocole lors de l’exécution d’une délégation contrainte basée sur les ressources comme si le bit était défini.

Étant donné que le KDC ne limite pas la transition de protocole, deux nouveaux ID de sécurité (SID) connus ont été introduits pour donner ce contrôle à l’administrateur de la ressource. Ces SID identifient si une transition de protocole a eu lieu, et peuvent être utilisés avec des listes de contrôle d’accès standard pour accorder ou limiter l’accès en fonction des besoins.

SID	Description
AUTHENTICATION_AUTHORITY_ASSERTED_IDENTITY S-1-18-1	SID qui signifie que l’identité du client est déclarée par une autorité d’authentification à partir de la preuve de possession des informations d’identification du client.
SERVICE_ASSERTED_IDENTITY S-1-18-2	Un SID qui signifie que l’identité du client est déclarée par un service.

Un service de back-end peut utiliser des expressions ACL standard pour déterminer la façon dont l’utilisateur a été authentifié.

Comment configurer la délégation contrainte basée sur les ressources ?

Pour configurer un service de ressources pour autoriser l’accès à un service frontal pour le compte d’utilisateurs, utilisez les applets de commande Windows PowerShell.

• Pour récupérer une liste de principaux, utilisez les applets de commande Get-ADComputer, Get-ADServiceAccountet Get-ADUser avec le paramètre Properties PrincipalsAllowedToDelegateToAccount.

• Pour configurer le service de ressources, utilisez les applets de commande New-ADComputer, New-ADServiceAccount, New-ADUser, Set-ADComputer, Set-ADServiceAccountet Set-ADUser avec le paramètre PrincipalsAllowedToDelegateToAccount.

Configuration logicielle requise

La délégation contrainte basée sur les ressources peut uniquement être configurée sur un contrôleur de domaine exécutant Windows Server 2012 R2 et Windows Server 2012, mais elle peut être appliquée au sein d’une forêt mixte.

Vous devez appliquer le correctif logiciel suivant à tous les contrôleurs de domaine qui exécutent Windows Server 2012 dans les domaines de compte d’utilisateur sur le chemin d’accès de référencement entre les domaines frontaux et principaux qui exécutent des systèmes d’exploitation antérieurs à Windows Server : échec KDC_ERR_POLICY de délégation contrainte basée sur les ressources dans des environnements dotés de contrôleurs de domaine basés sur Windows Server 2008 R2 (https://support.microsoft.com/en-gb/help/2665790/resource-based-constrained-delegation-kdc-err-policy-failure-in-enviro).