Dans cet article nous allons voir comment utilisé les autorisations sélectives dans les relations d'approbation entre deux environnements Active Directory. Pour cela nous allons utiliser 2 forêts Active Directory « lab1.lan » et « lab2.lan ». Le domaine « lab1.lan » utilise la plage d'adresse « 172.21.x.x » et le domaine « lab2.lan » la plage « 172.22.x.x ». Les deux sous réseaux sont reliés par un routeur et il n'y a pas de filtrage. Si vous voulez sécuriser les liens entre les réseaux vous pouvez utiliser le lient suivant afin de filtrer les ports :

https://technet.microsoft.com/en-us/library/8daead2d-35c1-4b58-b123-d32a26b1f1dd?f=255&MSPPError=-2147217396

Les éléments de notre laboratoire :

• Lab1dc1 : contrôleur de domaine de « lab1.lan » en Windows 2012 R2
• Lab1dc2 : contrôleur de domaine de « lab1.lan » en Windows 2012 R2
• Lab1cl2 : poste client membre du domaine « lab1.lan » en Windows 10
• Lab2dc1 : contrôleur de domaine de « lab2.lan » en Windows 2012 R2
• Test1 et Test2 : 2 utilisateurs du domaine « lab2.lan » uniquement membre du groupe « Utilisateurs du domaine ».

Ensuite nous avons configuré des redirecteurs DNS afin d'assurer la résolution de nom entre les deux domaines :

• Sur « lab1.lan »

• Sur « lab2.lan »

Pour le premier exemple nous allons configurer une relation d'approbation externe unidirectionnelle où le domaine « lab1.lan » approuve le domaine « lab2.lan » :

Nous avons sélectionné l'authentification à l'échelle du domaine :

 

Sur le domaine « lab2.lan », nous créons deux utilisateurs « test1 » et « test2 » membre uniquement de « utilisateurs du domaine » de « lab2.lan » :

 

Si l'utilisateur « test1 » du domaine « lab2.lan » essaye d'ouvrir une session sur le poste « lab1cl2 » du domaine « lab1.lan », la session s'ouvre et il dispose bien du droit de s'authentifier sur le poste client « lab1cl2 ».

La commande « whoami » permet de vérifier que nous avons bien ouvert la session avec le compte « test2 » du domaine « lab2.lan »

La commande « whoami /groups » permet de lister les groupes inclus dans la session de l'utilisateur. Vous pouvez constater qu'il est bien inclus dans le groupe « utilisateurs authentifié », mais il ne fait pas partie du groupe « utilisateurs du domaine » du domaine « lab1.lan » :

Si l'utilisateur essaie de joindre le partage « netlogon » du contrôleur de domaine « lab1dc1 » du domaine « lab1.lan », il doit fournir des identifiants valide pour cette connexion :

Nous allons maintenant modifier l'étendue de l'authentification dans notre relation d'approbation sortante sur « lab1dc1 », afin d'utiliser une authentification sélective :

Après modification si nous essayons d'ouvrir la session avec le compte « test1 » de « lab2.lan » sur le poste client « lab1cl2.lab1.lan », nous obtenons un refus :

Pour que l'utilisateur « test1 » puisse ouvrir une session sur le poste client il doit disposer du droit de s'authentifier sur l'objet ordinateur « lab1cl2.lab1.lan ». Le droit « autorisation d'authentifier » est définis dans les paramètres de sécurité de l'objet ordinateur dans la partie sécurité (console « utilisateurs et ordinateurs Active Directory ») :

Pour faciliter la configuration nous allons créer un groupe de sécurité de domaine local « DL_Net_Lab2_ouvrir_session » dans le domaine « lab1.lan », ajouter l'utilisateur « test1@lab2.lan » dans ce groupe et autoriser l'authentification pour ce groupe :

Nous ajoutons dans ce groupe l'utilisateur « test1» du domaine « lab2.lan » ;

Comme nous avons mis en place une approbation unidirectionnelle, l'administrateur du domaine « lab1.lan » ne peut interroger les comptes du domaine « lab2.lan », puisqu'il ne dispose pas du droit de s'authentifier sur le DC de lab2. Une fenêtre de sécurité s'ouvre et nous demandes de fournir une identité disposant de ce droit (un simple utilisateur du domaine « lab2.lan » fera l'affaire puisqu'il dispose du droit de lecture de l'AD cible) :

Si nous avions configuré une approbation bidirectionnelle et autorisé l'administrateur du domaine « lab1.lan » à s'authentifier sur le contrôleur de domaine de « lab2.lan », il n'y aurait pas eu de demande d'authentification.

Nous pouvons donner le droit d'authentification au groupe « DL_Net_Lab2_ouvrir_session » sur l'ordinateur » « lab1cl2 », mais il est également possible de donner le droit directement à tous les ordinateurs présents dans une unité d'organisation. Nous avons créé une OU « Poste Clients partagés avec lab2 » et nous avons déplacé le poste « lab1cl2 » dans ce conteneur.

Afin de modifier les sécurités sur l'objet il est nécessaire d'activé l'affichage des « Fonctionnalités avancées » dans le menu « affichage » :

Dans les propriétés de l'unité d'organisation « Postes Clients partagés avec lab2 », la partie « sécurité » est maintenant apparente :

Nous ajoutons le groupe « DL_Net_Lab2_ouvrir_session » sur « objets Ordinateur descendant », ensuite nous sélectionnons l'option « autorisations d'authentifier » et nous validons.

La session « test1 » de l'utilisateur de « lab2.lan » s'ouvre sur le poste client « lab1cl2 » membre de « lab1.lan » :

Néanmoins l'utilisateur « test1 » ne peut accéder au partage de « lab1dc1 » et aucune demande d'authentification ne lui est demandée car il ne dispose pas du droit de s'authentifier sur ce dernier :

La commande « whoami /groups » permet de vérifier que l'utilisateur est bien membre de « DL_Net_Lab2_ouvrir_session » :

Si nous essayons d'ouvrir la session avec le compte « test2 » de « lab2.lan », nous obtenons un refus vu qu'il n'est pas membre du groupe : « DL_Net_Lab2_ouvrir_session »

Enfin nous allons ajouter le droit de s'authentifier pour le groupe « DL_Net_Lab2_ouvrir_session » sur le contrôleur de domaine « lab1dc1 » :

L'utilisateur « test1 » peut maintenant voir les partages présents sur « lab1dc1 », mais sans forcément avoir accès au contenu :

S'il essaie de se connecter au deuxième contrôleur de domaine « lab1dc2 » du domaine « lab1.lan », il obtient un refus :

 

Pour finir nous allons créer sur « lab1dc1 » un dossier partagé « PartageAvecLab1 » et autorisé l'accès « control total » au groupe « DL_Net_Lab2_ouvrir_session » :

 

 

Nous pouvons constater que l'utilisateur « test1 » peut créer des documents dans ce partage, mais n'a toujours pas d'accès aux autres partages :

Pour l'exemple j'ai créé le partage sur un contrôleur de domaine mais je ne vous recommande pas de faire la même chose dans votre environnement. Si vous disposez d'un serveur de fichier il suffit d'autoriser l'authentification sur celui-ci. Dans ce cas l'utilisateur ne disposera pas du droit de s'authentifier sur vos contrôleurs de domaine.

Merci d'avoir pris le temps de lire cet article en espérant que cet article puisse vous aider à comprendre l'authentification sélective dans les approbations Active Directory.