Tout ce qu’il y a à savoir sur les relations d’approbation avec AWS Managed Microsoft AD

Dans cet article, nous vous proposons d’approfondir divers aspects des relations d’approbation Active Directory et de démystifier certaines informations au passage.

De nombreux clients Amazon Web Services (AWS) utilisent Active Directory pour centraliser l’authentification et les autorisations des utilisateurs pour une grande variété d’applications et de services. Pour ces clients, Active Directory est un élément essentiel de leur infrastructure. AWS propose AWS Directory Service for Microsoft Active Directory, également connu sous le nom d’AWS Managed Microsoft AD, afin de fournir un service Active Directory hautement disponible et résilient.

L’un des cas d’utilisation les plus courants d’AWS Managed Microsoft AD concerne les clients qui ont besoin d’intégrer leur domaine ou leur forêt Active Directory on-premises à des services AWS tels qu’Amazon Relational Database Service (Amazon RDS), Amazon FSx, Amazon WorkSpaces et d’autres applications et services AWS. Ce type d’intégration peut nécessiter une relation d’approbation. En ce qui concerne les relations d’approbations, il y a souvent une incompréhension sur ce que permet ou ne permet pas de faire ce type de configuration.

Démarrons avec Kerberos

Pour comprendre le fonctionnement des relations d’approbations, il faut d’abord comprendre comment fonctionne l’authentification au sein d’une relation d’approbation, en particulier avec Kerberos. Kerberos est un sujet qui, à première vue, est assez simple, mais qui peut rapidement devenir beaucoup plus complexe. Cet article n’abordera pas en détail le fonctionnement de Kerberos dans Microsoft Windows. Si vous souhaitez approfondir le sujet, consultez la documentation de Microsoft Kerberos (en anglais). Dans cet article, nous allons simplement vous donner un aperçu du fonctionnement de l’authentification Kerberos au travers des relations d’approbations.

Si vous ne deviez retenir qu’une seul chose à propos de Kerberos, il s’agirait des références (referrals). Examinons les flux du schéma 1, qui montre un utilisateur du domaine A connecté à un ordinateur du domaine A et qui souhaite accéder à un partage de fichiers Amazon FSx dans le domaine B. Par souci de simplicité, on considère qu’il existe une relation d’approbation bidirectionnelle entre les domaines A et B.

Remarque : lorsqu’une relation d’approbation est intégrée à AWS Managed Microsoft AD, vous devez activer la pré-authentification Kerberos pour les comptes qui transitent par les relations d’approbations. La désactivation de la pré-authentification Kerberos n’est pas recommandée, car un utilisateur malveillant peut directement envoyer des fausses demandes d’authentification. Le centre de distribution de clés (KDC) renverra un ticket d’octroi de tickets (TGT) chiffré, qu’un utilisateur malveillant pourra déchiffrer par une attaque par force brute hors ligne. Consultez la section Pré-authentification Kerberos : pourquoi elle ne doit pas être désactivée pour plus de détails.

Les étapes du processus d’authentification Kerberos au travers d’une relation d’approbation sont les suivantes :

1. 1. Requête de service d’authentification Kerberos (KRB_AS_REQ) : le client contacte le service d’authentification (AS) du KDC (qui s’exécute sur un contrôleur de domaine) pour le domaine A, dont le client est membre, pour obtenir un ticket de courte durée appelé ticket d’octroi de tickets (TGT). La durée de vie par défaut du TGT est de 10 heures. Pour les clients Windows, cela se produit lors de l’ouverture de session, mais les clients Linux peuvent avoir besoin d’exécuter une commande kinit.
   2. Réponse du service d’authentification Kerberos (KRB_AS_REP) : L’AS construit le TGT et crée une clé de session que le client peut utiliser pour chiffrer les communications avec le service d’octroi de tickets (TGS). Au moment où le client reçoit le TGT, il n’a accès à aucune ressource, même aux ressources de l’ordinateur local.
   3. Requête de service d’octroi de tickets Kerberos (KRB_TGS_REQ) : le client Kerberos de l’utilisateur envoie un message KRB_TGS_REQ à un KDC local du domaine A, en spécifiant fsx@domainb comme cible. Le client Kerberos compare le domaine au domaine de sa propre station de travail. Ces valeurs étant différentes, le client définit un indicateur dans le champ Options KDC du message KRB_TGS_REQ pour NAME_CANONICALIZE, qui indique au KDC que le serveur se trouve peut-être dans un autre domaine.
   4. Réponse du service d’octroi de tickets Kerberos (KRB_TGS_REP) : le KDC local de l’utilisateur (pour le domaine A) reçoit le KRB_TGS_REQ et renvoie un ticket de référence TGT pour le domaine B. Le TGT est émis pour le domaine suivant sur le chemin le plus court menant au domaine B. Le TGT possède également un indicateur de référence défini, afin que le KDC soit informé que le KRB_TGS_REQ provient d’un autre domaine. Cet indicateur indique également au KDC de renseigner le champ Transited Realms. Le ticket de référence est chiffré avec la clé interdomaine qui est déchiffrée par le TGS du domaine B. Remarque : Lorsqu’une relation d’approbation est établie entre des domaines ou des forêts, une clé interdomaine basée sur le mot de passe de la relation d’approbation devient disponible pour authentifier les fonctions KDC et est utilisée pour chiffrer et déchiffrer les tickets Kerberos.
   5. Requête de service d’octroi de tickets Kerberos (KRB_TGS_REQ) : le client Kerberos de l’utilisateur envoie un KRB_TGS_REQ ainsi que le TGT qu’il a reçu du KDC du domaine A à un KDC du domaine B.
   6. Réponse du service d’octroi de tickets Kerberos (KRB_TGS_REP) : le TGS du domaine B examine le TGT et l’authentificateur. S’ils sont valides, le TGS crée un ticket de service. L’identité du client est extraite du TGT et copiée sur le ticket de service. Le ticket est ensuite envoyé au client. Pour plus de détails sur l’authentificateur, voir Comment fonctionne la version 5 du protocole d’authentification Kerberos (article en anglais).
   7. Requête de service du serveur d’applications (KRB_TGS_REQ) : une fois que le client a reçu le ticket de service, il envoie le ticket et un nouvel authentificateur au serveur cible pour demander l’accès. Le serveur déchiffrera le ticket, validera l’authentificateur et (pour les services Windows) créera un jeton d’accès pour l’utilisateur en fonction des SID (Security Identifier : identifiant de sécurité unique) figurant dans le ticket.
   8. Réponse du service du serveur d’applications (KRB_TGS_REP) : le client peut éventuellement demander au serveur cible de vérifier sa propre identité. C’est ce que l’on appelle l’authentification mutuelle. Si une authentification mutuelle est demandée, le serveur cible récupère l’horodatage de l’ordinateur client auprès de l’authentificateur, le chiffre à l’aide de la clé de session fournie par le TGS pour les messages client-serveur cible et l’envoie au client.

Les bases de la transitivité des relations d’approbations, les directions et les types

Commençons par définir ce qu’est une relation d’approbation. Les relations d’approbations Active Directory sont des relations entre des domaines qui permettent aux utilisateurs d’un domaine d’être authentifiés par un contrôleur de domaine de l’autre domaine. Les utilisateurs authentifiés, s’ils disposent des autorisations appropriées, peuvent accéder aux ressources de l’autre domaine.

Les services de domaine Active Directory prennent en charge quatre types de relations d’approbations : externe (domaine), forêt, domaine et raccourci (Plus d’informations sur les types de relations d’approbations – Understanding Trust Type en anglais). Parmi ces quatre types de relations d’approbations, AWS Managed Microsoft AD prend en charge les types d’approbation externe (domaine) et de forêt. Pour cet article, nous nous concentrerons sur les relations d’approbations externes (domaine) et de forêt.

Transitivité : Qu’est ce que c’est ?

Avant d’aller plus loin dans les types de relation d’approbation, il est important de comprendre le concept de transitivité. Une relation d’approbation transitive permet à l’authentification de passer par d’autres domaines (Enfants et Arbres) dans les forêts ou domaines approuvés. En revanche, une relation d’approbation non transitive est une relation d’approbation point à point qui permet à l’authentification de circuler exclusivement entre les domaines de confiance.

Schéma 2 : Relation d’approbation entre les deux forêts

Pour le moment, ne vous souciez pas des différents type de relations d’approbations, nous les couvrirons plus tard. L’exemple du schéma 2 montre une relation d’approbation de forêt entre Example.com et Example.local. La forêt Example.local possède un domaine enfant nommé Child. Avec une relation d’approbation transitive, les utilisateurs des domaines Example.local et Child.example.local peuvent être authentifiés auprès des ressources du domaine Example.com.

Si le schéma 2 est configuré avec une relation d’approbation externe, seuls les utilisateurs de Example.local peuvent être authentifiés auprès des ressources du domaine Example.com. Les utilisateurs de Child.Example.local ne peuvent pas traverser la relation d’approbation pour accéder aux ressources du domaine Example.com.

Directions des relations d’approbations

Les relations d’approbations bidirectionnelles sont des approbations qui autorisent des références d’authentification provenant de chaque côté de l’approbation afin de permettre aux utilisateurs d’accéder aux ressources d’un domaine ou d’une forêt. Si vous consultez la zone Domaines et approbations Active Directory de la console de gestion Microsoft (MMC), qui fournit des consoles permettant de gérer le matériel, les logiciels et les composants réseau du système d’exploitation Microsoft Windows, vous pouvez voir à la fois une approbation entrante et une approbation sortante pour le domaine approuvé.

Les relations d’approbations unidirectionnelles sont des approbations qui autorisent les références d’authentification provenant d’un seul côté de la relation d’approbation. Une approbation unidirectionnelle est sortante ou entrante, mais pas les deux (ce serait une approbation bidirectionnelle).

• Une approbation sortante permet aux utilisateurs du domaine de confiance (Example.com) de s’authentifier dans ce domaine (Example.local).
• Une approbation entrante permet aux utilisateurs de ce domaine (Example.local) de s’authentifier dans le domaine de confiance (example.com).

Schéma 3 : Relation d’approbation unidirectionnelle

Utilisons un schéma pour expliquer plus en détail ce concept. Le schéma 3 représente une relation d’approbation entre Example.com et Example.local. Il s’agit d’une approbation sortante depuis Example.com et d’une approbation entrante sur Example.local. Les utilisateurs de Example.local peuvent s’authentifier et, s’ils disposent des autorisations appropriées, accéder aux ressources de Example.com. Les utilisateurs de Example.com ne peuvent pas accéder aux ressources de Example.local ni s’authentifier auprès de ces ressources.

Les types de relations d’approbations

Dans cette section de l’article, nous examinerons les différents types de relations d’approbations Active Directory et leurs fonctionnalités.

Relation d’approbation externe

Ce type de relation d’approbation est utilisé pour partager des ressources entre deux domaines. Il peut s’agir de domaines individuels situés à l’intérieur ou à l’extérieur d’une forêt. Considérez cela comme une relation d’approbation point à point entre deux domaines. Voir Comprendre quand créer une approbation externe (documentation en anglais) pour plus de détails sur ce type de relation d’approbation.

• Transitivité : Non-transitive
• Direction : Unidirectionnelle ou bidirectionnelle
• Types d’authentification : NTLM seulement* (Possible d’utiliser Kerberos avec certains pré-requis; voir la documentation Microsoft correspondante pour plus de détails)
• Support par AWS Managed Microsoft AD : Oui

Relation d’approbation de forêt

Ce type de relation d’approbation est utilisé pour partager des ressources entre deux forêts. Il s’agit du modèle de relation d’approbation préféré, car il fonctionne pleinement avec Kerberos sans aucune réserve. Voir Comprendre quand créer une relation d’approbation de forêt (documentation en anglais) pour plus de détails.

• Transitivité : Transitive
• Direction : Unidirectionnelle ou bidirectionnelle
• Types d’authentification : Kerberos et NTLM
• Support par AWS Managed Microsoft AD : Oui

Relation d’approbation de domaine (Realm)

Ce type de relation d’approbation est utilisé pour établir une relation de confiance entre un domaine Kerberos autre que Windows et un domaine Active Directory. Consultez la documentation (en anglais) Comprendre quand créer une relation d’approbation de domaine (Realm) pour plus de détails.

• Transitivité : Transitive ou Non-transitive
• Direction : Unidirectionnelle ou bidirectionnelle
• Types d’authentification : Kerberos seulement
• Support par AWS Managed Microsoft AD : Non

Relation d’approbation de raccourcis

Ce type de relation d’approbation est utilisé pour raccourcir le chemin d’authentification entre les domaines au sein de forêts complexes. Pour plus de détails, voir Comprendre quand créer une relation d’approbation de raccourcis (documentation en anglais).

• Transitivité : Transitive
• Direction : Unidirectionnelle ou bidirectionnelle
• Types d’authentification : Kerberos et NTLM
• Support par AWS Managed Microsoft AD : Non

Suffixes de nom d’ouverture de session utilisateur

Le suffixe du nom d’ouverture de session utilisateur (User Principal Name : UPN) par défaut pour un compte utilisateur est le nom de domaine DNS (Domain Name System) du domaine dans lequel réside le compte utilisateur. Dans AWS Managed Microsoft AD et les AD non managés, des suffixes UPN alternatifs sont ajoutés pour simplifier les processus d’administration et de connexion des utilisateurs en fournissant un suffixe UPN unique pour tous les utilisateurs. Le suffixe UPN est utilisé dans la forêt Active Directory et il n’est pas nécessaire qu’il s’agisse d’un nom de domaine DNS valide. Reportez-vous à la section Ajout de suffixes de nom d’ouverture de session utilisateur (documentation en anglais) pour savoir comment ajouter des suffixes UPN à une forêt.

Par exemple, si votre domaine est Example.local mais que vous souhaitez que vos utilisateurs se connectent avec ce qui semble être un autre nom de domaine (tel que ExampleSuffix.local), vous devez ajouter un nouveau suffixe UPN au domaine. Le schéma 4 montre un utilisateur en cours de création avec un autre suffixe UPN.

Schéma 4 : Liste déroulante UPN lors de la création d’un utilisateur

Si vous êtes connecté à un système Windows, vous pouvez utiliser la commande whoami /upn pour voir l’UPN de l’utilisateur actuel.

Relation d’approbation de forêt et routage des suffixes de noms

Le routage des suffixes de noms gère la façon dont les demandes d’authentification sont acheminées au travers des relations d’approbations de forêt. Un suffixe de nom unique est un suffixe de nom au sein d’une forêt, tel qu’un suffixe UPN ou un nom de forêt DNS ou d’arbre de domaine, qui n’est subordonné à aucun autre suffixe de nom. Par exemple, le nom de forêt DNS Example.com est un suffixe de nom unique au sein de la forêt example.com.

Tous les noms subordonnés à des suffixes de nom uniques sont routés implicitement. Par exemple, si la racine de votre forêt s’appelle Example.local, les demandes d’authentification pour tous les domaines enfants de Example.local (child.example.local) seront acheminées car les domaines enfants sont subordonnés au suffixe de nom Example.LOCAL. Si vous souhaitez empêcher les membres d’un domaine enfant de s’authentifier dans la forêt spécifiée, vous pouvez désactiver le routage des suffixes de nom pour ce nom. Vous pouvez également désactiver le routage pour le nom de la forêt elle-même, si nécessaire. Avec les domaines arbres (domain trees) et les suffixes UPN supplémentaires, le routage des suffixes de nom est désactivé par défaut et doit être activé pour que ces suffixes puissent traverser la relation d’approbation.

Remarque : Dans AWS Managed Microsoft AD, les clients n’ont pas la possibilité de créer ou de modifier des relations d’approbations à l’aide des outils Microsoft natifs. Si vous avez besoin d’une route de suffixe de nom activé pour votre relation d’approbation, envoyez une demande auprès du support Premium.

Quelques schémas faciliteront l’explication. Le schéma 5 montre la configuration de relations d’approbations. Il existe une relation d’approbation unidirectionnelle sortant de Example.com vers Example.local. Un suffixe UPN nommé ExampleSuffix.local a été ajouté à Example.local. Example.local possède également un domaine enfant nommé Child et un domaine arbre nommé ExampleTree.local. Par défaut, les utilisateurs de Example.local et Child.Example.local pourront s’authentifier auprès des ressources de Example.com. Les utilisateurs du domaine ExampleTree.local ne pourront pas s’authentifier auprès des ressources d’Example.com, à moins que la route du suffixe de nom pour ExampleTree.local ne soit activé sur l’objet de relation d’approbation dans Example.com.

Schéma 5 : Forêt multi-domaines et suffixes avec une relation d’approbation

Le schéma 6 provient de la boîte de dialogue des propriétés de relations d’approbations de la forêt Example.com montrant la configuration d’une relation d’approbation entre Example.com et Example.local. Comme vous pouvez le constater, *.example.local est activé. Mais le suffixe UPN personnalisé ExampleSuffix.local et le domaine arbre ExampleTree.local sont désactivés par défaut.

Schéma 6 : Détails des relations d’approbations Example.local

Authentification sélective

Avec AWS Managed Microsoft AD et les AD non managés, vous avez la possibilité de configurer l’authentification sélective. Cette option limite l’accès par authentification via une relation d’approbation aux seuls utilisateurs d’un domaine ou d’une forêt approuvés qui ont reçu des autorisations d’authentification explicites pour les objets ordinateurs résidant dans le domaine ou la forêt de confiance.

Lorsque vous utilisez l’authentification à l’échelle du domaine ou de la forêt, selon la direction de la relation d’approbation, les utilisateurs peuvent s’authentifier au travers de la relation d’approbation. L’authentification en elle-même ne fournit pas d’accès : les utilisateurs doivent se voir déléguer des autorisations pour accéder aux ressources. Lorsque l’authentification sélective est activée, vous devez définir l’autorisation Autorisé à s’authentifier sur chaque objet ordinateur auquel l’utilisateur de confiance aura accès, en plus de toutes les autres autorisations requises pour accéder à l’objet ordinateur.

Bien que l’authentification sélective soit un moyen de renforcer davantage les relations d’approbations, elle nécessite beaucoup de planification et de délégation, car vous devez définir l’autorisation Autorisé à s’authentifier sur tous les objets ordinateurs auxquels vous accédez. Cela peut également compliquer la résolution des problèmes d’autorisations et de relations d’approbations.

Pour plus de détails sur l’authentification sélective, consultez Authentification sélective et Configuration des paramètres d’authentification sélective dans la documentation Microsoft (en anglais).

Filtrage SID

Nous n’allons pas nous attarder longuement sur le filtrage SID, car cette fonctionnalité est activée dans AWS Managed Microsoft AD et ne peut pas être désactivée. Le filtrage SID empêche les utilisateurs malveillants disposant d’un accès de niveau administrateur de domaine ou d’entreprise dans une forêt approuvée d’accorder des droits d’utilisateur élevés à une forêt approbatrice. Pour cela, il empêche l’utilisation abusive des attributs contenant des SID sur les principaux de sécurité (Security principals) dans la forêt approuvée. Par exemple, un utilisateur malveillant possédant des informations d’identification administratives situées dans une forêt approuvée pourrait, par divers moyens, obtenir les informations SID d’un administrateur de domaine ou d’entreprise dans la forêt approbatrice. Après avoir obtenu le SID d’un administrateur dans la forêt approbatrice, un utilisateur malveillant disposant d’informations d’identification administratives peut ajouter ce SID à l’attribut d’historique SID d’un principal de sécurité (Security principal) de la forêt approuvée et tenter d’obtenir un accès complet à la forêt approbatrice et aux ressources qu’elle contient.

Le fait de désactiver le filtrage SID sur votre domaine local peut exposer votre domaine à des risques liés à des utilisateurs malveillants. Nous sommes conscients que lors d’une migration de domaine, vous devrez peut-être la désactiver pour autoriser l’utilisation du SID d’un objet provenant du domaine d’origine pendant la migration. Toutefois, dans AWS Managed Microsoft AD, ce filtrage ne peut pas être désactivé. Voir Filtrage SID pour plus de détails.

Flux réseaux nécessaires à la création d’une relation d’approbation

Les ports réseau suivants doivent être ouverts entre les contrôleurs de domaine des deux domaines ou des forêts avant de créer une relation d’approbation. Notez que ces ports entrants sont déjà ouverts dans le Security Group (groupe de sécurité : sert de filtrage pour toute ressource AWS communiquant sur le réseau) utilisé par votre annuaire AWS Managed Microsoft AD. Vous devrez ajuster les règles sortantes du Security Group pour lui permettre de communiquer avec les domaines ou les forêts devant être approuvés. Le tableau suivant est basé sur les recommandations de Microsoft. Selon votre cas d’utilisation, il est possible que certains de ces ports n’aient pas besoin d’être ouverts. Par exemple, si le protocole LDAP sur SSL n’est pas configuré, le port TCP 636 n’est pas nécessaire.

Création d’une relation d’approbation

AWS Managed Microsoft AD est basé sur les services de domaine Active Directory de Windows Server, ce qui signifie que les relations d’approbations Active Directory fonctionnent de la même manière qu’avec un Active Directory non managé. La seule différence réside dans la façon dont la relation d’approbation est créée. On utilise la console de gestion AWS (AWS Management Console) ou l’API pour créer la configuration de relation d’approbation sur un AWS Managed Microsoft AD. Cette configuration est documentée de manière approfondie dans le guide d’administration d’AWS Directory Service.

Les étapes principales de configuration sont les suivantes :

• Assurez-vous que la résolution des noms réseau et DNS sont disponibles et fonctionnelles entre les domaines.
• Créez la relation d’approbation sur l’Active Directory local.
• Complétez la configuration de la relation d’approbation sur AWS Managed Microsoft AD dans la console AWS Directory Service.

Scénarios de relations d’approbations les plus courants

Lorsque vous établissez une relation d’approbation entre un domaine on-premises et AWS Managed Microsoft AD, vous devez prendre en compte certains éléments qui vous aideront à décider de la direction de la relation de confiance qu’il faut configurer. Dans cet article, nous allons aborder quelques-uns des scénarios les plus courants.

Choisir un type de relation d’approbation

Commençons par le choix entre une relation d’approbation de forêt ou une relation d’approbation externe. Nous recommandons généralement d’utiliser une relation d’approbation de forêt. La raison principale étant que les relations d’approbations de forêt supportent pleinement Kerberos sans aucune réserve. Cependant, si vous avez des exigences spécifiques pour implémenter une relation d’approbation externe, vous pouvez le faire. Il suffit de tenir compte de ces conditions.

Scénario 1 : utiliser AWS Managed Microsoft AD comme forêt de ressources pour Amazon RDS, Amazon FSx for Windows File Server ou des instances Amazon EC2

Dans ce scénario, on utilise AWS Managed Microsoft AD comme forêt de ressources pour Amazon RDS, Amazon FSx for Windows File Server ou Amazon Elastic Compute Cloud (Amazon EC2). AWS Managed Microsoft AD devient alors un domaine de ressources, et les comptes utilisateurs résideront du côté local de la relation d’approbation et pourront accéder aux ressources du côté AWS Managed Microsoft AD de la relation d’approbation.

Dans cette configuration, les applications AWS (Amazon RDS, Amazon FSx for Windows File Server ou Amazon EC2) n’ont pas besoin d’une relation d’approbation bidirectionnelle pour fonctionner, car elles sont intégrées de manière native à Active Directory. Cela signifie que vous n’avez besoin que d’une authentification dans un sens pour fonctionner. Ce scénario nécessite une approbation entrante unidirectionnelle sur le domaine local et une approbation sortante unidirectionnelle sur le domaine AWS Managed Microsoft AD. Le schéma 7 explicite cette architecture.

Schéma 7 : relation d’approbation unidirectionnelle

Scénario 2 : utiliser AWS Managed Microsoft AD comme forêt de ressources pour toutes les autres applications AWS supportées

Dans ce scénario, on utilise AWS Managed Microsoft AD comme domaine de ressources pour toutes les autres applications AWS supportées qui ne sont pas incluses dans le scénario 1. Comme indiqué dans le scénario précédent, AWS Managed Microsoft AD sera un domaine de ressources et les comptes utilisateurs résideront du côté local de la relation d’approbation et devront pouvoir accéder aux ressources de l’AWS Managed Microsoft AD.

Dans cette configuration, les applications AWS (Amazon Chime, Amazon Connect, Amazon QuickSight, AWS IAM Identity Center successeur d’AWS Single Sign-On, Amazon WorkDocs, Amazon WorkMail, Amazon WorkSpaces, AWS Client VPN, la console AWS et AWS Transfer Family) doivent être en mesure de rechercher des objets depuis le domaine local pour qu’elles puissent fonctionner. Cela signifie que l’authentification doit se faire dans les deux sens. Ce scénario nécessite une relation d’approbation bidirectionnelle entre les domaines Microsoft AD on-premises et l’AWS Managed Microsoft AD. Le schéma 8 explicite cette architecture.

Schéma 8 : relation d’approbation bidirectionnelle

Mythes et incompréhensions courants autour des relations d’approbations

Nous avons eu de nombreuses conversations avec des clients concernant les relations d’approbations entre leur domaine on-premises et leur domaine AWS Managed Microsoft AD. Voici quelques-uns des mythes et incompréhensions les plus courants que nous avons rencontrés au cours de ces conversations.

Les relations d’approbations synchronisent les objects entre chaque domaine

C’est faux. Une relation d’approbation entre domaines ou forêts agit comme un pont qui permet aux demandes d’authentification validées, sous la forme de flux Kerberos ou NTLM, de circuler entre les domaines ou les forêts. Les objets ne sont pas synchronisés entre les domaines ou les forêts. Seul le mot de passe de la relation d’approbation est synchronisé et est utilisé pour Kerberos.

Mon mot de passe est transféré au travers de la relation d’approbation lors de l’authentification

C’est faux. Comme nous l’avons évoqué plus haut dans la section Démarrons avec Kerberos, lors de l’authentification au travers de relations d’approbations, le mot de passe de l’utilisateur n’est pas transmis entre les domaines. Les seuls éléments transmis entre les domaines sont les demandes et réponses du Ticket Granting Service (TGS), qui sont générées en temps réel, sont à usage unique et expirent en quelques heures.

Une relation d’approbation unidirectionnelle permet une authentification bidirectionnelle

C’est faux. Les relations d’approbations unidirectionnelles permettent aux authentifications de circuler dans une seule direction. Les utilisateurs ou les objets du domaine de confiance peuvent s’authentifier et, s’ils sont délégués, accéder aux ressources du domaine approbateur. Les utilisateurs du domaine approbateur ne peuvent pas s’authentifier auprès du domaine de confiance et ne sont pas autorisés à accéder aux ressources. Supposons qu’il existe un système de fichiers Amazon FSx dans Example.local et une relation d’approbation unidirectionnelle entre Example.com (relation d’approbation sortante) et Example.local (relation d’approbation entrante). Il n’est pas possible de déléguer à un utilisateur de Example.com l’autorisation d’accéder au système de fichiers Amazon FSx Example.local avec cette configuration de relation d’approbation. C’est la nature d’une relation d’approbation à sens unique.

Les relations d’approbations ne sont pas sécurisées par défaut

C’est faux. Bien qu’une relation d’approbation mal configurée puisse augmenter vos risques et votre exposition. Les relations d’approbations en elles-mêmes n’augmentent que très peu la surface d’attaque d’un Active Directory. Vous devez toujours utiliser les bonnes pratiques lors de la création d’une relation d’approbation afin de minimiser les risques. Par exemple, une relation d’approbation non utilisée doit être supprimée. Vous devez désactiver l’historique des SID sauf si vous êtes en train de migrer des domaines. Pour plus d’informations sur la sécurisation des relations d’approbations, consultez Considérations relatives à la sécurité des relations d’approbations (article en anglais).

Les utilisateurs d’un domaine de confiance obtiennent des permissions sur mon domaine lorsqu’une relation d’approbation est crée

C’est faux. Par défaut, avec les relations d’approbations bidirectionnelles, les objets disposent d’une autorisation en lecture seule sur les Active Directory dans les deux sens. Les objets n’ont par défaut pas d’autorisations déléguées ni un accès à des ressources ou à des serveurs. Par exemple, si vous souhaitez qu’un utilisateur se connecte à un ordinateur d’un autre domaine, vous devez d’abord lui déléguer l’accès à la ressource de l’autre domaine. Sans cette délégation, l’utilisateur ne pourra pas accéder à la ressource.

Diagnostic et dépannage des anomalies de relation d’approbation

Au travers de notre expérience avec de nombreux clients, la grande majorité des problèmes de configuration de relations d’approbations sont liés à la résolution du DNS ou à des erreurs de connectivité réseau. Voici quelques étapes de dépannage qui vous aideront à résoudre les problèmes les plus courants :

• Vérifiez si vous avez autorisé le trafic réseau sortant sur AWS Managed Microsoft AD. Reportez-vous à Étape 1 : Configuration de votre environnement pour les relations d’approbations pour savoir comment trouver le Security Group de votre annuaire et comment le modifier.
• Si le serveur DNS ou le réseau de votre domaine local utilise un espace d’adresses IP public (non conforme à la RFC 1918), procédez comme suit :

• • Dans la console AWS Directory Service, accédez à la section de routage IP de votre annuaire, choisissez Actions, puis choisissez Ajouter une route.
  • Entrez le bloc d’adresses IP de votre serveur DNS ou de votre réseau local en utilisant le format CIDR, par exemple 203.0.113.0/24.

Cette étape n’est pas nécessaire si votre serveur DNS et votre réseau local utilisent des espaces d’adresses IP privés RFC 1918.

• Après avoir vérifié le Security Group et vérifié si des routes sont requises, lancez une instance Windows Server et joignez-la au domaine AWS Managed Microsoft AD. Reportez-vous à l’étape 3 : Déployer une instance EC2 pour gérer votre AWS Managed Microsoft AD pour savoir comment procéder. Une fois l’instance lancée, procédez comme suit :
  • Exécutez la commande PowerShell suivante pour tester la connectivité DNS :

Resolve-DNSName -Name "example.local" -DnsOnly

• Vous pouvez également consulter les explications des messages dans le guide des raisons du statut de création d’une relation d’approbation dans la documentation d’AWS Directory Service.

Résumé des considérations relatives aux relations d’approbations dans AWS Managed Microsoft AD

Dans cet article, nous avons abordé l’authentification Kerberos au travers des relations d’approbations Active Directory et ce que sont les approbations ainsi que leur fonctionnement. Voici une liste condensée des éléments à prendre en compte lorsque vous planifiez la création d’une relation d’approbation avec AWS Managed Microsoft AD :

• Assurez-vous que vous disposez d’une connexion réseau et que les ports réseau nécessaires sont ouverts entre les deux domaines. Notez qu’il est recommandé que tout le trafic Active Directory passe par une connexion réseau privée telle qu’un VPN ou un Direct Connect.
• Assurez-vous que la résolution DNS fonctionne des deux côtés de la relation d’approbation.
• Planifiez l’implémentation de l’authentification sélective. S’il est prévu de l’utiliser, planifiez votre stratégie de délégation de liste de contrôle d’accès (ACL) Active Directory avant la mise en œuvre.
• Au moment de la publication de ce article, n’oubliez pas qu’AWS Managed Microsoft AD prend actuellement en charge les relations d’approbations de forêt et les approbations externes uniquement.
• Assurez-vous que la pré-authentification Kerberos est activée pour tous les objets qui traversent des relations d’approbations avec AWS Managed Microsoft AD.
• Si vous constatez que vous avez besoin d’une route avec suffixe de nom activée pour votre relation d’approbation, ouvrez un ticket de support auprès d’AWS Support, en demandant que la route avec suffixe de nom soit activée.
• Enfin, consultez Considérations de sécurité pour les relations d’approbations : approbations de domaine et de forêt pour des considérations supplémentaires relatives à la configuration des relations d’approbations.

Article orginal contribué par Jeremy Girven et adapté en français par Alexis Roger, Specialist Solutions Architect chez AWS France.