Configurer la délégation Kerberos contrainte (KCD) dans Microsoft Entra Domain Services

Article
10/23/2023

Pendant leur exécution, les applications peuvent avoir besoin d’accéder à des ressources dans le contexte d’un autre utilisateur. Active Directory Domain Services (AD DS) prend en charge un mécanisme, appelé délégation Kerberos, qui autorise ce cas d’usage. La délégation Kerberos contrainte (KCD) s’appuie alors sur ce mécanisme pour définir les ressources accessibles dans le contexte de l’utilisateur.

Les domaines managés Microsoft Entra Domain Services étant plus sécurisés que les environnements AD DS locaux classiques, utilisez un mécanisme KCD plus sécurisé basé sur les ressources.

Cet article vous montre comment configurer la délégation Kerberos contrainte basée sur les ressources dans un domaine managé Domain Services.

Prérequis

Pour effectuer ce qui est décrit dans cet article, vous avez besoin des ressources suivantes :

Un abonnement Azure actif.
- Si vous n’avez pas d’abonnement Azure, créez un compte.
Un client Microsoft Entra associé à votre abonnement, soit synchronisé avec un annuaire sur site, soit avec un annuaire cloud uniquement.
- Si nécessaire, créez un client Microsoft Entra ou associez un abonnement Azure à votre compte.
Un domaine managé Microsoft Entra Domain Services activé et configuré dans votre locataire Microsoft Entra.
- Si nécessaire, créez et configurez un domaine managé Microsoft Entra Domain Services.
Une machine virtuelle de gestion Windows Server jointe au domaine managé Domain Services.
- Si nécessaire, suivez les étapes du tutoriel pour créer et joindre une machine virtuelle Windows Server à un domaine managé, puis installez les outils de gestion AD DS.
Un compte d’utilisateur membre du groupe Administrateurs Microsoft Entra DC dans votre locataire Microsoft Entra.

Vue d’ensemble de la délégation Kerberos contrainte

La délégation Kerberos permet à un compte d’emprunter l’identité d’un autre compte pour accéder à des ressources. Par exemple, une application web qui accède à un composant web back-end peut emprunter sa propre identité comme s’il s’agissait d’un autre compte d’utilisateur au moment d’établir la connexion back-end. La délégation Kerberos n’est pas sécurisée dans le sens où le compte qui emprunte l’identité peut accéder à n’importe quelles ressources sans aucune limitation.

En revanche, la délégation Kerberos contrainte (KCD) restreint les services ou les ressources auxquels une application ou un serveur déterminé peut se connecter en empruntant une autre identité. Le mécanisme KCD classique exige des privilèges d’administrateur de domaine pour configurer le compte de domaine d’un service, et il contraint le compte à s’exécuter sur un seul domaine.

Le mécanisme KCD classique présente aussi quelques inconvénients. Par exemple, dans les anciens systèmes d’exploitation, les administrateurs de service n’avaient aucun moyen utile de savoir quels services front-end déléguaient vers les services de ressources qu’ils possédaient. Tout service front-end qui pouvait déléguer vers un service de ressources constituait un point d’attaque potentiel. Si un serveur qui hébergeait un service front-end configuré pour déléguer vers des services de ressources était compromis, les services de ressources pouvaient l’être tout autant.

Dans un domaine managé, il n’existe pas de privilèges d’administrateur de domaine. De ce fait, le mécanisme classique de délégation Kerberos contrainte basé sur les comptes ne peut pas être configuré dans un domaine managé. À la place, il est possible d’utiliser le mécanisme KCD basé les ressources, qui est aussi plus sécurisé.

KCD basée sur la ressource

Windows Server 2012 et les versions ultérieures offrent la possibilité aux administrateurs de service de configurer la délégation contrainte pour leur service. Ce modèle est appelé KCD basé sur les ressources. Avec cette approche, l’administrateur de service back-end peut octroyer ou refuser à des services front-end spécifiques le droit d’utiliser KCD.

La KCD basée sur la ressource est configurée à l’aide de PowerShell. Vous devez utiliser les applets de commande Set-ADComputer ou Set-ADUser, selon que le compte d’emprunt est un compte d’ordinateur ou un compte de service/compte d’utilisateur.

Configurer le mécanisme KCD basé sur les ressources pour un compte d’ordinateur

Dans ce scénario, supposons que vous avez une application web qui s’exécute sur l’ordinateur nommé contoso-webapp.aaddscontoso.com.

L’application web doit accéder à une API web qui s’exécute sur l’ordinateur nommé contoso-api.aaddscontoso.com dans le contexte des utilisateurs du domaine.

Pour configurer ce scénario, effectuez les étapes suivantes :

Créer une unité d’organisation personnalisée Vous pouvez déléguer des autorisations pour gérer cette unité d’organisation personnalisée aux utilisateurs du domaine managé.
Joignez les machines virtuelles (à la fois celles qui exécutent l’application web et celles qui exécutent l’API web) au domaine managé. Créez ces comptes d’ordinateur dans l’unité d’organisation personnalisée de l’étape précédente.

Notes

Les comptes d’ordinateur de l’application web et de l’API web doivent se trouver dans une unité d’organisation personnalisée dans laquelle vous êtes autorisé à configurer le mécanisme KCD basé sur les ressources. Vous ne pouvez pas configurer la KCD basée sur les ressources pour un compte d’ordinateur situé dans le conteneur intégré Ordinateurs Microsoft Entra DC.
Enfin, configurez le mécanisme KCD basé sur les ressources à l’aide de l’applet de commande PowerShell Set-ADComputer.

Sur votre machine virtuelle de gestion jointe au domaine, connectez-vous avec un compte d’utilisateur membre du groupe Administrateurs Microsoft Entra DC, puis exécutez les cmdlets suivantes. Indiquez vos propres noms d’ordinateur, si nécessaire :
```
$ImpersonatingAccount = Get-ADComputer -Identity contoso-webapp.aaddscontoso.com
Set-ADComputer contoso-api.aaddscontoso.com -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount
```

Configurer le mécanisme KCD basé sur les ressources pour un compte d’utilisateur

Dans ce scénario, supposons que vous disposez d’une application web qui s’exécute en tant que compte de service nommé appsvc. L’application web doit accéder à une API web qui s’exécute en tant que compte de service nommé backendsvc dans le contexte des utilisateurs du domaine. Pour configurer ce scénario, effectuez les étapes suivantes :

Créer une unité d’organisation personnalisée Vous pouvez déléguer des autorisations pour gérer cette unité d’organisation personnalisée aux utilisateurs du domaine managé.
Joignez les machines virtuelles qui exécutent la ressource/API web back-end au domaine managé. Créez son compte d’ordinateur dans l’unité d’organisation personnalisée.
Créez le compte de service (par exemple, appsvc) utilisé pour exécuter l’application web dans l’unité d’organisation personnalisée.

Notes

Là encore, le compte d’ordinateur de la machine virtuelle de l’API web et le compte de service de l’application web doivent se trouver dans une unité d’organisation personnalisée dans laquelle vous êtes autorisé à configurer le mécanisme KCD basé sur les ressources. Vous ne pouvez pas configurer la KCD basée sur les ressources pour des comptes situés dans les conteneurs intégrés Ordinateurs Microsoft Entra DC ou Utilisateurs Microsoft Entra DC. Cela signifie aussi que vous ne pouvez pas utiliser de comptes d’utilisateurs synchronisés à partir de Microsoft Entra ID pour configurer le mécanisme KCD basé sur les ressources. Vous devez créer et utiliser des comptes de service spécifiquement créés dans Domain Services.
Enfin, configurez le mécanisme KCD basé sur les ressources à l’aide de l’applet de commande PowerShell Set-ADUser.

Sur votre machine virtuelle de gestion jointe au domaine, connectez-vous avec un compte d’utilisateur membre du groupe Administrateurs Microsoft Entra DC, puis exécutez les cmdlets suivantes. Indiquez vos propres noms de service en fonction des besoins :
```
$ImpersonatingAccount = Get-ADUser -Identity appsvc
Set-ADUser backendsvc -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount
```

Étapes suivantes

Pour en savoir plus sur le fonctionnement de la délégation dans Active Directory Domain Services, consultez Vue d’ensemble de la délégation Kerberos contrainte.

Partage via