REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université des Sciences et de le Technologie Houari Boumediene

Faculté d’Electronique et d’Informatique

Domaine Sciences et Technologie

Travaux Pratiques d’Administration

des Services Réseaux

COMPTE RENDU DE TP

Travail effectué dans le cadre d’un compte rendu de travaux pratiques par le quadrinôme :

Master 1 RT/ Groupe 02/ Sous-groupe 04

 I. Objectif de ce compte rendu :

Dans le cadre du module d’Administration des Services Réseaux, nous avons eu à faire des travaux
pratiques afin de mettre en application les connaissances que nous avons apprises en cours tout en
les approfondissant et se penchant sur le coté pratique et ce grâce à des manipulations.
Nous avons donc eu recours à la virtualisation afin de simuler un environnement et créer un petit
réseau de machines virtuelles pour tester et mettre en application nos connaissances.
A travers ce compte rendu, nous vous présentons les différentes étapes que nous avons effectuées
afin de mener à bien le travail demandé dans chacun des TPs donnés.

II. Manipulation :

1- TP 1 : Mise en place d’un environnement d’administration client/serveur

Avant de commencer les manipulations, il a fallu commencer par installer les machines virtuelles
(VMs) qui sont indispensable pour les travaux. Nous avons donc installé sous l’hyperviseur Oracle VM
Virtual Box un Serveur que nous avons appelé Serveur1 et un client que nous avons appelé Client1.
Ensuite, nous avons créé un réseau local entre les deux machines virtuelles précédentes afin qu’elles
puissent communiquer entre elles. La connexion sera testée à travers un Ping du Client1 vers
Serveur1 et vice versa. Les opérations seront effectuées avec succès, la communication a donc bien
été établie entre le client et le serveur.

Figure I.1 : VMs serveur et client

Notre environnement maintenant bien installé, nous disposons de toutes les ressources nécessaires
pour commencer les différentes simulations.
 2- TP 2 : Mise en place d’un environnement d’administration client/serveur
Durant ce TP, nous aurons à installer et configurer les serveurs DNS et DHCP sous Windows Server en
utilisant les ressources que nous avons préalablement installé sur nos deux VMs dans le TP1.

Première partie : Serveur DNS

Installation du service DNS

Dans un premier temps, nous avons installé le service DNS au niveau du « serveur1 ». En réalité,
comme celui-ci est déjà installé sous Windows Server, nous n’avons fait qu’installer le rôle DNS que
nous viendrons configurer par la suite.
 Figure II.2 : Installation service DNS

Configuration de la zone de recherche directe

Par la suite, nous avons configuré le serveur en commençant par la zone de recherche directe située
juste en dessous du serveur dans le gestionnaire DNS. Nous avons créé une zone principale sous le
nom de rt.local qui sera notre domaine ainsi qu’un nouveau fichier nommé qui portera
automatiquement le même nom que celui de notre domaine c'est-à-dire rt.local.

Nous avons autorisé les mises à jour dynamiques sécurisées et non sécurisées afin que notre serveur
puisse se mettre à jour automatiquement puis, au niveau des propriétés de l’enregistrement SOA
nous avons ajouté et sélectionné rt.local comme étant le serveur principal et personne responsable
(dans la figure suivante, nous voyons bien qu’au niveau de l’enregistrement SOA, notre serveur1 est
« hostmaster »).

Figure II.3 : Zone de recherche directe

 Configuration de la zone de recherche inverse

Cette étape n’est pas obligatoire mais reste nécessaire pour des raisons de sécurité. Nous avons alors
créé une zone principale que nous allons configurer en zone de recherche inversée IPv4 dans zone de
recherche inverse. Nous choisissons de donner à notre réseau l’adresse 192.168.0.
Lorsque nous avons créé le ficher nommé, celui-ci a automatiquement été nommé en 0.168.192.in-
arpa.dns. Nous remarquons que le fichier nommé prend automatiquement l’inverse de l’adresse du
réseau que nous avons configuré durant les dernières étapes. Le résultat obtenu est dans la figure
suivante et correspond à ce que nous attendions puisqu’il vient confirmer nos connaissances
théoriques avec la mention « in-arpa.dns ».
Pour finir, nous avons également autorisé les mises à jour dynamiques sécurisées et non sécurisées.
Ces mises à jour nous servirons dans la suite de nos travaux.

Figure II.4 : Zone de recherche inverse

Ajout de l’enregistrement des machines serveur et client dans une zone de recherche
directe et inverse

Afin d’ajouter manuellement les différents hôtes de notre réseau virtuel, nous avons créé de
nouveaux hôtes A (car nous travaillons en adresses IPv4) dans notre zone de recherche directe
rt.local à commencer par notre serveur « serveur1 » puis la machine cliente « client1 ».
Nous y avons configuré les adresses qui seront respectivement 192.168.0.1 et 192.168.0.2 pour le
serveur et le client sans oublier de cocher la case pour créer un pointeur d’enregistrement PTR dans
les deux cas pour éviter d’avoir à le faire dans la zone de recherche inverse.
Nous avons obtenu le résultat suivant.
 Figure II.5 : Enregistrements dans la zone directe

Si notre zone rt.local contient 20 machines (clients et serveurs compris), nous allons procéder de la
même manière pour configurer le serveur DNS en y ajoutant les enregistrements de chacune des
machines et accessoirement, les pointeurs dans la zone de recherche inverse.
Cette approche risque d’être longue et redondante principalement si le nombre de machines
devient important.

Vérification de la bonne configuration du service DNS

Maintenant que nous en avons fini avec l’installation et la configuration du service DNS, il serait
préférable de vérifier si la configuration que nous avons effectuée est correcte et fonctionnelle avant
de tester d’autres fonctionnalités et opérations. Pour ce, nous avons défini l’adresses de notre
serveur comme étant l’adresse du serveur DNS et nous avons ouvert l’invite de commande pour
afficher certains détails.

Figure II.6 : Configuration DNS

La première commande est le « nslookup » que nous introduisons sur l’invite des commandes des
deux machines virtuelles. Cette commande permet de trouver l’adresse IP d’un hôte spécifique qui
dans notre cas est celle du serveur DNS pour vérifier notre configuration. (Cette commande permet
également dans certains cas de trouver le nom de domaine d’une adresse IP spécifique, dans ce cas,
c’est une recherche DNS inverse).
Une fois que nous avons introduit cette commande dans l’invite de commande des deux machines
virtuelles, nous observons le résultat suivant.

Figure II.7 : Résultat du nslookup

Nous remarquons que sur les deux machines que ce soit le client ou le serveur, le serveur DNS est à
l’adresse 192.168.0.1 qui est bien l’adresse de notre serveur DNS, le serveur1.

Pour avoir plus de détails sur les enregistrements SOA, nous avons utilisé une autre commande ; set
type=soa. Cette commande permet d’afficher les détails du champ SOA (Start Of Authority).
 Figure II.8 : Résultat du set type=soa

Sur les deux résultats, nous remarquons bien que le serveur est notre serveur1 avec toutes les
configurations que nous avons introduites dans les étapes précédentes.
Pour vérifier notre configuration d’une autre méthode, nous pouvons le faire en ouvrant l’invite de
commande de la machine cliente et en effectuant un ping vers le domaine. Si celui-ci affiche le reste
du domaine, notre configuration est bonne.
On peut également lancer la commande ip config/all depuis l’invite de commande du PC, l’adresse du
serveur DNS devrait en principe s’afficher. Ou lancer la commande depuis
l’administrateur :dcdiag/test:dans/v/s:<DCNAME>/DnsBasic/f:dcdiagreport txt

Deuxième partie : Service DHCP

Installation du service DHCP

Dans un premier temps, nous avons eu à installer le service DHCP au niveau de notre serveur
serveur1. Comme pour le service DNS, celui-ci est également préinstallé sur Windows Server et il
suffit alors d’installer le rôle DHCP et ses fonctionnalités.
De la même façon, on ajoute le rôle DHCP dans le gestionnaire de serveur en suivant les étapes
complémentaires qui s’affichent à l’écran.

Figure II.9 : Installation DHCP

 Configuration du service DHCP

Maintenant que nous avons un serveur DHCP installé, il ne nous reste qu’à le configurer. Pour ce,
nous commençons par créer une nouvelle étendue d’adresses IPv4 que l’on appellera « etenduert »
dont la plage d’adresses est 192.168.0.5 jusqu’à 192.168.0.30 ainsi qu’une plage d’exclusion qui est
de 192.168.0.15 jusqu’à 192.168.0.20 sans oublier le bail que l’on fixe à une journée.
Nous ajoutons pour finir une passerelle par défaut ainsi que le nom de domaine, le nom et l’adresse
du serveur DNS que nous allons utiliser, le serveur1.
Dans ce cas, nous ajoutons l’adresse du serveur DNS pour éviter que le DHCP ne lui réattribue
d’adresse dans son processus automatique d’adresse par la suite.

Figure II.10 : Configuration DHCP

Vérification de la configuration
Pour vérifier la configuration que nous venons d’effectuer, nous utilisons la machine du client1. Dans
les paramètres réseaux, nous choisissons la case obtenir une adresse IP automatique. De ce fait, le
client1 oublie l’adresse que nous lui avons accordée manuellement et en demandera une autre qui
lui sera attribuée par le service DCHP.

Figure II.11 : Demande d’adresse IP automatique

Afin de vérifier cette manipulation, nous nous rendons sur l’invite de commande du client1. Grâce
aux commandes ipconfig/all, nous vérifions l’attribution des adresses. Nous obtenons ainsi

Figure II.12 : Vérification des paramètres

Réservation d’une adresse IP

Troisième partie : Intégration DHCP et DNS

Configuration des mises à jours dynamiques DNS via DHCP

Afin que le serveur DHCP puisse enregistrer et mettre à jour les informations de chaque client, nous
allons dans cette étape configurer celui-ci ses serveurs DNS.
Pour ce, il a fallu se rendre sur les propriétés DHCP du serveur1 et choisir les propriétés du DNS afin
d’activer les mises à jour dynamiques DNS et de toujours mettre à jour dynamiquement les
enregistrements DNS A et PTR. Cette étape permet au DHCP de communiquer avec le DNS et de
toujours être mis à jour des changements dans le réseau, de déconnexion et de toute modification
qui peut arriver. (Cette option est activée dans le DNS et nous avons bien pris le soin de le vérifier et
de le mentionner dans les différentes étapes précédentes).

Vérification de la configuration

Par la suite, nous allons supprimer les enregistrements Hôte A et PTR afin d’effacer toute trace de
l’adresse de notre machine du client1 dans les zones de recherche directe et inverse. Puis, sur la
machine client1, nous ouvrons l’invite de commande pour reconfigurer les paramètres réseaux non
plus manuellement mais cette fois, par programmation. Nous utilisons ipconfig/release pour libérer
l’ancienne adresse et ipconfig/renew pour demander une autre adresse qui sera cette fois ci
attribuer par le DHCP.
 Figure II.13 : Commande ipconfig/renew

A ce niveau, nous remarquons déjà que le client1 s’est vu attribué une nouvelle adresse qui est
192.168.0.5.

Pour vérifier que cette étape a bien été effectuée, nous vérifions les enregistrements au niveau des
zones de recherche directe et inverse.

Figure II.14 : Zone de recherche directe

 Figure II.15 : Zone de recherche inverse

Dans les zones de recherche directe et inverse, nous remarquons bien que les enregistrements Hote
A et PTR apparaissent de nouveau mais ne sont pas les mêmes que précédemment. En effet, la
nouvelle adresse du client1 est 192.168.0.5 alors que dans notre configuration manuelle, nous
l’avions fixé à 192.168.0.3.
Ainsi, nous pouvons conclure en disant que notre configuration a été correctement effectuée.
La méthode d’attribution automatique d’adresses par le DHCP pourrait être une solution au
problème soulevé au niveau de l’étape 4 de la première partie DNS. En effet, lorsque le nombre de
machines dans un réseau s’agrandit, l’attribution des adresses et l’enregistrement manuel au
niveau des fichiers de zone directe et inversée peut s’avérer long et il pourrait y avoir un problème
de confusion entre les différentes d’adresses qui sera attribuées de manière statique. En revanche,
en intégrant le DHCP et le DNS qui travailleront en étant mis à jour et configurés ensemble,
l’attribution d’adresses ainsi que l’enregistrement sera beaucoup plus rapide. De plus, comme les
enregistrements et les adresses seront dynamiques et comme les services se mettent à jour
mutuellement, il sera possible d’économiser des adresses.
Ces deux protocoles sont alors indispensables au bon fonctionnement dynamique du réseau, qu’il
soit virtuel et tout particulièrement quand il sera physique.
 3- Installation et configuration de Active Directory
Durant ce TP, nous avons créé notre premier domaine racine de foret Active Directory. Pour ce, nous
aurons besoin des machines virtuelles que nous avons installées précédemment sous Oracle Virtual
Box, principalement notre serveur serveur1 sur lequel, nous supprimons le service DNS
précédemment installé et nous nous assurons de lui attribuer une adresse statique.

Première partie : Création d’un domaine racine de forêt

Installation du service AD DS

Pour commencer, nous devons lancer le serveur virtuel et introduire l’adresse IP de notre serveur
dans le champ Serveur DNS préféré. Ensuite, sur le gestionnaire de serveur, nous ajoutons le rôle
Service AD DS (Active Directory Domain Services) et nous suivons les étapes affichées l’écran jusqu’à
terminer le processus.

Figure III.16 : Installation d’AD

Promotion du serveur en contrôleur de domaine

Jusque là, le servie Active Directory n’est pas encore prêt car nous n’avons fait que l’installer, nous
devons donc le configurer et le promouvoir en tant que contrôleur de domaine. Pour ce, nous nous
dirigeons vers le gestionnaire de serveur sur lequel on retrouve un point d’exclamation en haut sur
un drapeau. Nous cliquons dessus afin de promouvoir notre serveur en tant que contrôleur de
domaine.

Figure III.17 : Serveur en contrôleur de domaine

Comme il s’agit d’un nouveau domaine dans une nouvelle forêt, nous ajoutons une nouvelle forêt
sous le nom de rt.local en sélectionnant son niveau fonctionnel ainsi que celui du domaine.

Figure III.18 : Niveau fonctionnel de la forêt et du serveur

Afin de permettre la restauration de contrôleur de domaine, nous laissons cocher l’ajout de la

fonctionnalité serveur DNS. Nous remarquons qu’un message d’erreur en jaune s’affiche pour alerter
de la délégation du serveur DNS.
Nous renommons le domaine RT et nous choisissons un emplacement pour la base de données AD
DS ainsi que pour les journaux d’historique et pour SYSVOL et nous suivons le reste des étapes
affichées à l’écran pour finir par installer le tout.
 Figure III.19 : Etat d’avancement de l’installation

Windows redémarre après l’opération et après celui-ci, nous remarquons que le nom de la session a
changé.

Figure III.20 : Ecran verrouillage

Nous remarquons aussi un nouvel outil d’administration Windows, le module Active Directory pour
Windows.

Figure III.21 : Outil d’administration Windows

Deuxième partie : Vérification de la bonne configuration

Nous avons installé dans la partie précédente notre domaine racine de forêt et nous avons effectué
toutes les configurations nécessaires mais, avant de procéder à la suite des étapes et pour s’assurer
que celui-ci fonctionnera correctement dans le réseau, nous devons vérifier son fonctionnement.
Pour ce, nous procédons par étapes que nous détaillerons ici.

Vérification de la structure des dossiers

Pour vérifier les dossiers, nous allons vers le menu démarrer puis sur Exécuter. Grâce à une
commande, nous allons afficher le contenue SYSVOL donc les sous-dossiers domain, staging, staging
areas et sysvol.
 Figure III.22 : Sous dossiers SYSVOL

Ce qui prouve que notre dossier a correctement été créé.

Vérification des dossiers partagés

Figure III.23 : vérification des dossiers partagés

Les partages NETLOGON et SYSVOL sont biens apparus.

Vérification de la base de données et les fichiers journaux

Depuis l’outil Exécuter, on affiche le contenu du dossier Ntds.

 Figure III.24 : Contenu du dossier NTDS

Vérification de l’inscription des enregistrements de ressources DNS

Sur l’invite de commande, nous y introduisons une suite de commandes pour vérifier les
enregistrements des ressources dans le DNS.
 Figure III.25 : Enregistrements des ressources dans le DNS

Ensuite, nous consultons le fichier Netlogon pour les inscriptions de ressources SRV.

Figure III.26 : Contenu du fichier Netlogon

Vérification de l’intégration du DNS à Active Directory

Pour effectuer cette vérification, il nous faut pénétrer le DNS dans l’outil d’administration dans le
menu démarrer. Nous sélectionnons les propriétés de la zone de recherche directe et nous vérifions
si l’onglet Type indique bien « Intégrée à Active Directory ».
Au niveau des propriétés du serveur DNS, nous vérifions su l’option « A partir d’Active Directory et du
registre » est bien activée et elle l’est.

Vérification que le contrôleur de domaine DC est catalogue général GC

Toujours en se dirigeant vers l’outil d’administration, nous choisissons cette fois ci « Sites et services
AD ». Nous choisissons notre serveur puis Contrôleur de domaine pour ensuite se rendre dans les
propriétés de NTDS Settings afin de vérifier si la boite Global Catalog est choisie (catalogue global).
 Vérification des rôles FSMO

Nous vérifions les rôles FSMO détenus et on obtient.

Figure III.27 : Rôles FSMO

Nous remarquons que notre serveur est maître des noms de domaine, contrôleur de domaine
principal, gestionnaire du pool RID et maître de l’infrastructure. Ce qui veut dire que notre serveur
« serveur1 » est maître d’opérations unique à l’intérieur de la forêt et à l’intérieur du domaine.
 4- TP 4 : Active Directory –Gestion des comptes et des groupes-

Dans le TP précédent, nous avons configuré et promu notre serveur1 en tant que contrôleur de
domaine. Dans ce TP, nous allons créer et gérer des comptes utilisateurs, des groupes locaux, des
ordinateurs Active Directory ainsi que des groupes Active Directory.
Pour mener à bien notre TP, nous avons également besoin de notre machine cliente, le client1.

Première partie : Création et gestion des comptes utilisateurs et ordinateurs

Création d’un compte utilisateur local

Pour commencer, nous devon ouvrir et lancer notre VM client1 et nous connecter avec le compte
utilisateur. On clique sur Gérer dans Ordinateur avant de choisir Outils système puis Utilisateurs et
groupes locaux. Dans ce menu, nous choisissons Utilisateurs car c’est ce qu’il faut configurer dans un
premier temps et c’est là que tous les utilisateurs locaux de notre ordinateur apparaissent. On crée
un nouvel utilisateur et on spécifie son nom ainsi qu’un mot de passe. Comme nom, nous avons
choisi localUser.
 Figure IV.28 : Création d’un compte utilisateur sur client1

 REPONSE : Comme le compte utilisateur n’est pas encore créer dans le domaine, on ne peut
pas accéder au domaine par ce compte

Création d’un compte utilisateur de domaine

Maintenant que le compte utilisateur est créé au niveau local, nous devons le créer dans le domaine
et pour ce, nous lançons notre VM serveur1. On se connecte au serveur avec le nom
d’administrateur du domaine RT\Administrateur et on lance le gestionnaire de serveur dessus. Dans
l’onglet Outils, on choisit Utilisateurs et ordinateurs Active Directory. C’est dans ce menu que nous
pouvons dérouler et voir notre domaine rt.local ainsi que la liste des utilisateurs et des groupes déjà
existant (par défaut). On s’aperçoit qu’on y trouve le compte Administrateur que l’on utilise déjà.
 Figure IV.29 : Liste des utilisateurs

On crée un nouvel utilisateur en cliquant sur Users ensuite Nouveau et on y introduit le nom et le
prénom ainsi que le nom d’ouverture de session. On choisi un mot de passe et on précise que le mot
de passe n’expire pas en cochant la case.

Figure IV.30 : Création d’un compte utilisateur sur le serveur1

  REPONSE : Non, on ne peut pas accéder au domaine par ces comptes, car l’utilisateur peut se
connecter au domaine via son compte utilisateur qu’à travers un compte ordinateur ce qui
n’est pas encore le cas.

Création d’un compte ordinateur

Toujours sur le serveur1, on procède de la même façon mais cette fois-ci en se dirigeant sur
Ordinateur. On refait les mêmes étapes en spécifiant le nom de l’ordinateur

Figure IV.31 : Création d’un ordinateur sur le serveur1

Joindre un ordinateur au domaine

Pour cette étape, nous devrons travailler depuis la machine cliente, le client1. Nous lançons alors la
machine et nous nous connectons avec le compte administrateur local.
Dans un premier temps, on spécifie l’adresse du serveur1 (notre contrôleur de domaine) comme
étant l’adresse du DNS préféré puis dans les propriétés du poste de travail, on modifie les
paramètres dans la zone Paramètres de Nom de l’ordinateur, de domaine et de groupe de travail afin
d’ajouter notre ordinateur en tant que membre du domaine rt.local. Une fois arrivée à cette étape,
un identifiant et un mot de passe nous est demandé. On y renseigne alors les données du compte
Administrateur.
 Figure IV.32 : Ajout de notre ordinateur au domaine
pan
Un message s’affiche à l’écran précisant que nous sommes bien intégrés au domaine Active
Directory.

Figure IV.33 : Message de bienvenue

- Cliquer sur Ok en suite redémarrer l’ordinateur pour appliquer les modifications.

- Que constatez-vous, lorsque l’ordinateur aura redémarré ?
On vérifie maintenant que l’enregistrement A de notre machine client1 est bien dans la zone directe
DNS.

Figure IV.33 : Enregistrement de client1 dans le DNS

 REPONSE : Depuis cette machine, tous les comptes utilisateurs qu’on a créé dans le domaine
peuvent s’identifier.

Désactivation et activation des comptes utilisateurs

Dans cette partie, nous nous remettons sur le serveur et nous nous connectons avec le compte de
l’administrateur du domaine, RT\Administrateur. Nous nous plaçons dans Utilisateurs et ordinateurs
Active Directory et nous déroulons la liste des utilisateurs. Sur l’utilisateur que nous avons créé
précédemment, nous cliquons sur Désactiver le compte.
 Figure IV.34 : Désactivation du compte utilisateur

Pour vérifier si cette modification a bien été apportée et que le compte de amel hemmam a bien été
désactivé, nous nous rendons sur la machine cliente client1 et nous essayons de nous connecter avec
son compte pour voir si la connexion est possible ou non.

On remarque bien que la connexion est impossible. Notre compte a bien été supprimé.
Pour la suite du TP, nous allons le réactiver.
Deuxième partie : Création et gestion des groupes

Création de groupes dans le domaine

Dans cette étape, nous allons créer des groupes dans notre domaine rt.local et pour ce, nous devons
nous replacer sur notre serveur1 en se connectant avec le compte administrateur RT\Administrateur.
On crée un nouveau groupe dans Utilisateurs dans la section Utilisateurs et ordinateurs Active
Directory. On y ajoute le nom de groupe que nous avons choisi c'est-à-dire G_SEC_Accounting en
choisissant une portée globale et un type de groupe « sécurité ».

Figure IV.35 : Création d’un groupe

En suivant les mêmes étapes, nous créons d’autres groupes comme G_SEC_Research, G_SEC_Sales.

Ainsi que 3 groupes de domaine local DL_SEC_Folder_Read, DL_SEC_Folder_Edit et

DL_SEC_Folder_FullControl.
 Gestion des appartenances aux groupes dans le domaine
Afin de gérer chacun des groupes, nous allons ajouter des membres dans chacun d’eux. Pour
commencer, nous allons ajouter un membre dans le groupe G_SEC_Accounting en cliquant sur ses
propriétés puis ensuite, sur Ajouter un membre. Dans la fenêtre Avancé, on choisi de faire une
recherche pour faire apparaître les utilisateurs enregistrées, on en choisi parmi ceux qui s’affichent et
on clique sur OK
Ces utilisateurs sont maintenant membre du groupe G_SEC_Accounting.

Figure IV.36 : Ajout des membres au groupe G_SEC_Accounting

Cette même procédure est répétée pour ajouter les groupes G_SEC_Accounting, G_SEC_Research et
G_SEC_Sales au groupe DL_SEC_Folder_Read.
 Figure IV.37 : Ajout de G_SEC_Accounting, G_SEC_Research et G_SEC_Sales au groupe
DL_SEC_Folder_Read

On répéte encore une fois la procédure pour ajouter le groupes G_SEC_Accounting au groupe
DL_SEC_Folder_FullControl.

 REPONSE : Cette imbrication de groupes permet de mieux gérer et administrer le domaine.

Gestion des appartenances aux groupes locaux

Maintenant que nous avons ajouté des membres dans les groupes et que nous avons imbriqué les
différents groupes relevant du même service afin de mieux gérer et administrer le domaine, nous
lançons la machine cliente client1 et nous nous connectons avec le compte administrateur afin
d’ajouter des administrateurs dans les groupes.
Pour ce, dans le menu Démarrer, on choisi Gérer dans Ordinateur et nous affichons la liste de tous les
groupes locaux de notre ordinateur. On ajoute alors des Administrateurs en faisant apparaître la liste
des utilisateurs enregistrés et en sélectionnant le compte utilisateur local que nous avons déjà créé.
Cette même opération est suivi afin d’ajouter les groupes G_SEC_Accounting, G_SEC_Research et
G_SEC_Sales au groupe Administrateurs.
Figure IV.38 : Ajout des groupes G_SEC_Accounting, G_SEC_Research et G_SEC_Sales au groupe
Administrateurs

 REPONSE : Ajouter des groupes globaux de domaine dans un groupe local permet
d’appliquer la stratégie AGDLP.

5- TP 5 : Active Directory –Gestion des partages et permissions NTFS-

Dans le TP précédent, nous avons créé des comptes utilisateurs, des groupes locaux, des ordinateurs
ainsi que des groupes Active Directory. Nous avons ajouté des administrateurs dans les différents
groupes afin de les gérer et nous avons également imbriqué des groupes afin de mieux gérer le
domaine et d’appliquer la stratégie ADGLP.
Dans ce TP, nous allons apprendre à gérer des dossiers partagés, les permissions NTFS pour le
contrôle d’accès aux dossiers ainsi que la publication des dossiers partagés dans Active Directory.
Pour mener à bien notre TP, nous aurons besoin des deux VMs installées, serveur1 et client1 ainsi
que de deux fichiers ; Fichier1.txt et 7z1900-x64.exe.

Création d’un dossier pour le partage

Depuis la machine virtuelle serveur1, nous nous connectons avec le compte administrateur du
domaine RT\Administrateur et on crée un dossier que l’on nomme « RESSOURCES PARTAGées » dans
le disque C. Dans ce dossier, on y place les 2 fichiers Fichier1.txt et 7z1900-x64.exe puis, toujours
dans le dossier RESSOURCES PARTAGées , on y crée un dossier « ressources spéciales » et on y place
encore une fois les deux fichiers précédents.

Figure V.39 : Création des fichiers

Partage du dossier dans le domaine

Dans les propriétés du dossier RESSOURCES PARTAGées , nous choisissons l’onglet Partage afin
d’accéder aux Partage avancé et enfin, aux autorisations. C’est ici que nous allons partager le dossier
et accorder le contrôle total à tout le monde.
Notre dossier « RESSOURCES PARTAGées » est alors partagé avec tout le monde et le chemin de
partage est \\serveur1\RESSOURCES PARTAGées
 Figure V.40 : Partage du dossier RESSOURCES PARTAGées

Afin de vérifier si le dossier existe dans le répertoire du serveur1, nous accédons à Exécuter dans le
menu Démarrer.

Figure V.41 : Les dossiers existants dans le domaine

 REPONSE : Dans le domaine, on retrouve d’autres dossiers partagés existants qui sont
netlogon et sysvel.
 REPONSE : Pour afficher les différents dossiers partagés dans le domaine, on utilise la
commande NET SHARE.

Figure V.42 : Résultat de la commande net share

Vérification du bon fonctionnement du partage

Dans cette partie, nous allons travailler sur la machine virtuelle cliente « client1 » afin de vérifier si le
dossier RESSOURCES PARTAGées est bien partagé. Nous allons nous connecter dessus avec le compte
de Hemmam Amel et nous nous dirigeons dans le menu Démarrer afin d’accéder à Exécuter. On tape
\\serveur1 et on constate que le dossier RESSOURCES PARTAGées.

Figure V.43 : Dossier RESSOURCES PARTAGées depuis la machine client1

Nous pouvons bien accéder à ce dossier et exploiter ces différents fichiers. Nous pouvons créer,
supprimer et modifier des fichiers dans ce répertoire et dans le répertoire enfant « ressources
spéciales » également.
 Figure V.44 : Dossier ressources spéciales

Nous essayons d’accéder avec un autre compte utilisateur et celui-ci possède les mêmes droits que
Hemmam Amel, l’autre utilisateur. Tout le monde a bien accès aux données du dossier RESSOURCES
PARTAGées.

Affinement des droits d’accès en utilisant les permissions NTFS

Jusque là, nous avons effectué la configuration de manière à rendre le dossier « ressources
spéciales » accessible à tout le monde, c'est-à-dire à tous les utilisateurs du domaine. Dans cette
partie, nous nous proposons d’affiner les droits d’accès en utilisant les permissions NTFS sur ce
dossier.
Pour ce, nous nous connectons au serveur1 avec le compte administrateur RT\Administrateur et
nous nous rendons sur les propriétés du dossier RESSOURCES PARTAGées. On choisi l’onglet sécurité
puis sur Avancé. On constate que dans la liste Entrées d’autorisation, les utilisateurs et les groupes
qui ont les permissions sur ce dossier les ont hérités depuis le dossier parent C:\ et donc, pour
supprimer ces permissions, on doit désactiver l’héritage en bas de la fenêtre affichée à l’écran. Une
autre fenêtre s’affiche et on clique alors sur « Convertir les autorisations héritées en autorisation
explicites sur cet objet » et à partir de là, nous avons la main pour supprimer ligne par ligne. Dans un
premier temps, on supprime toutes les entrées pour ensuite ajouter des utilisateurs. On sélectionne
un principal et on choisi le groupe DL_SEC_Folder_Read et on garde « Lire » uniquement comme
autorisations de base.
La même procédure est suivie pour ajouter le groupe DL_SEC_Folder_Edit avec « Modification »
uniquement comme autorisation et le groupe DL_SEC_Folder_FullControl avec comme autorisation
« Contrôle total ».
Ainsi, le groupe DL_SEC_Folder_Read pourra lire uniquement, DL_SEC_Folder_Edit aura le droit de
modifier et DL_SEC_Folder_FullControl bénéficie du contrôle total.
 Figure V.45 : Autorisations des groupes

Vérification des permissions NTFS sur le dossier partagé

Afin de vérifier que ses permissions sont bien mises en place, nous nous connectons à la machine
cliente client1 avec le compte utilisateur Hemmam Amel (cette utilisatrice appartient au groupe
G_SEC_Sales qui est membre du groupe DL_SEC_Folder_Read.
Hemmam Amel possède bien la permission de Lire le dossier RESSOURCES PARTAGées et le dossier
enfant ressources spéciales.
Avec un autre compte, appartenant au groupe G_SEC_Research (membre des deux groupes
DL_SEC_Folder_Read et DL_SEC_Folder_Edit) on vérifie que celui-ci possède bien l’autorisation de
lire et de modifier le dossier RESSOURCES PARTAGées et le dossier enfant ressources spéciales.
Avec un autre compte appartenant au groupe G_SEC_Accounting (membre des trois groupes
DL_SEC_Folder_Read, DL_SEC_Folder_Edit et DL_SEC_Folder_FullControl).

 REPONSE : On constate que cet utilisateur possède le contrôle total sur le dossier partagé
RESSOURCES PARTAGées et le dossier enfant ressources spéciales. On peut expliquer ceci par
le fait que cet utilisateur appartient au groupe G_SEC_Accounting qui est lui membre des 3
groupes DL_SEC_Folder_Read, DL_SEC_Folder_Edit et DL_SEC_Folder_FullControl.

Bloquer l’héritage pour le dossier enfant

Nous pouvons facilement constater que tous les utilisateurs disposent des mêmes permissions sur
notre dossier enfant « ressources spéciales » et parent RESSOURCES PARTAGées et ceci s’explique
par le principe d’héritage. Pour bloquer l’héritage, nous nous connectons au serveur1 avec le compte
administrateur du domaine RT\Administrateur et nous nous dirigeons vers les propriétés du dossier
enfant « ressources spéciales ». Nous désactivons l’héritage depuis l’onglet Sécurité en choisissant
l’option Convertir les autorisations héritées en autorisation explicites sur cet objet afin de conserver
les permissions héritées du dossier «Ressources partagées» et de les transformer en permissions
explicites non-héritées. De ce fait, nous enlevons la permission de lire le dossier enfant «ressources
spéciales» au groupe DL_SEC_Folder_Read et nous le supprimons de la liste des entrées
d’autorisation.
 . Figure V.46 : Blocage de l’héritage

Nous procédons de la même manière pour enlever le droit de supprimer pour le groupe
DL_SEC_Folder_Edit, sur le dossier enfant «ressources spéciales ».

Publication du dossier partagé dans Active Directory

Le dossier que nous avons créé n’est jusque là pas encore un objet Active Directory et pour le rendre
visible dans l’annuaire, nous devons le publier manuellement dans Active Directory car il n’existe pas
de système d’intégration de publication automatique sous Windows Server.
Pour commencer, nous nous connectons au serveur1 avec le compte administrateur RT\
Administrateur et nous lançons le gestionnaire Utilisateurs et Ordinateurs Active Directory. Nous
créons une Unité Organisationnelle que l’on nomme Partages et qui contiendra tous les dossiers
partagés. Dans Partages, on crée un nouveau Dossier partagé que l’on nomme pareillement
RESSOURCES PARTAGées et en spécifiant son emplacement dans le domaine \\Serveur1\Ressources
partagées.
 . Figure V.47 : Publication du dossier partagé dans l’annuaire

 Réponse : publier le dossier partagé dans l’annuaire permet de le lier à des Unités
Organisationnelles (OU)
 6- TP 6 : Active Directory –Délégation de contrôle administratif-
Dans le TP précédent, nous avons appris à gérer les différents dossiers partagés, à supprimer
l’héritage ainsi qu’accorder les différentes permissions NTFS.
Dans ce TP, nous allons déléguer le contrôle administratif des unités d’organisation et pour ce, nous
aurons besoin de notre environnement de virtualisation ainsi que notre serveur1 configurée et
promu comme Contrôleur de domaine ainsi que notre machine cliente client1. Pour mener à bien ce
TP, nous aurons également besoin d’une connexion internet stable afin de télécharger les outils
RSAT.

Création d’une structure d’unités d’organisations

Pour commencer, nous nous plaçons au niveau du serveur1 et nous nous connectons avec le compte
administrateur du domaine RT\Administrateur. Dans le gestionnaire Utilisateurs et Ordinateurs
Active Directory, on crée 03 unités organisationnelles qu’on nomme Accounting, Research et Sales
qui accueilleront les utilisateurs et groupes des trois services.

Figure VI.48 : Création des Unités Organisationnelles

Ensuite, on déplace les groupes G_SEC_Research, G_SEC_Accounting et G_SEC_Sales que nous avons
créé dans le TP4 avec leurs comptes utilisateurs vers les unités organisationnelles correspondantes
que nous venons de créer.
 Figure VI.49 : Déplacement

Délégation de l’administration des OUs

Dans cette étape, nous allons déléguer l’opération basique de réinitialisation de mot de passe de
l’ensemble des utilisateurs de l’OU Research à l’utilisateur Amel Hemmam.
On commence ainsi par sélectionner l’OU en question et choisir Délégation d’administration en y
ajoutant le compte utilisateur Amel Hemmam. On choisir l’option Déléguer les tâches courantes
suivantes et on coche la case que nous voulons, c'est-à-dire, Réinitialiser les mots de passe utilisateur
et forcer le changement de mot de passe.

Figure VI.50 : Délégation de tâche

Les mêmes étapes sont suivies afin de déléguer cette tâche pour les deux OU Accounting et Sales.
 Installation des outils RSAT
Afin de vérifier la délégation de la tâche de réinitialisation des mots de passes, nous allons installer
sur la machine client la console Utilisateur et ordinateurs Active Directory via les outils RSAT. Ces
outils permettent de gérer des rôles et des fonctionnalités qui sont installés sur des ordinateurs
Windows Server ) partir d’un ordinateur distant.
On commence alors par télécharger les outils d’administration de serveur distant RSAT pour
Windows 7 en faisant attention à télécharger la version 32 bit. Nous nous connectons alors à la
machine client1 avec le compte Administrateur depuis lequel on lance l’installation des outils RSAT
que nous avons téléchargés et une fois que ceux-ci sont installés, on redémarre la machine client1.
On active par la suite des fonctionnalités Windows depuis la fenêtre spécifiée dans le Panneau de
configuration en faisant attention à cocher toutes les fonctionnalités dans Outils d’administration de
serveur distant.

Figure VI.51 : Activation des outils d’administration de rôles

Les RSAT sont maintenant installés et activés. Ils peuvent être utilisés depuis Panneau de
configuration puis Outils d'administration.

Vérification de la délégation de la tâche créée

Maintenant que les outils RSAT sont installés sur la machine client1, l’utilisateur Amel Hemmam peut
réinitialiser les mots de passe des utilisateurs des OUs correspondantes à partir de la machine client1
sans devoir se connecter au contrôleur de domaine. C’est ce que nous allons vérifier dans cette
étape.
On commence par se connecter à la machine cliente client1 avec le compte de Amel Hemmam
auquel nous avons accordé la délégation de la tâche de réinitialisation de mot de passe. On choisi un
utilisateur de l’OU Research ‘souhila merah ‘ dont nous souhaitons réinitialiser le mot de passe et on
en choisi un autre.

 REPONSE : L’utilisateur a bien le droit de réinitialiser les mots de passe de tous les autres
utilisateurs car il est délégué de cette OU.
 Figure VI.52 : Réinitialisation du mot de passe

 REPONSE : Si on veut changer le mot de passe d’un autre utilisateur de l’OU Sales par
exemple de ‘zahia merah’, nous nous pouvons pas le faire car nous sommes connectés avec
le compte de Amel Hemmam qui possède une délégation pour l’OU Research uniquement.

Figure VI.53 : Réinitialisation du mot de passe impossible

 REPONSE : En essayant de créer un compte utilisateur dans l’OU Research, nous constatons
que nous ne pouvons pas le faire car l’utilisateur Amel Hemmam ne possède la délégation
que pour la tâche de réinitialisation de mot de passe seulement.

On se connecte avec le compte de souhila merah et nous constatons que le mot de passe a bien été
changé. Nous suivons les mêmes étapes pour changer les mots de passe des utilisateurs des OUs
Sales et Accounting, Sofia Dabouz et Bouchra Derkaoua.
 Création d’une console personnalisée simplifiée pour le changement des mots de passe

Un administrateur du domaine délègue souvent les tâches administratives basiques à des utilisateurs
afin de soulager celui-ci de certaines demandes. L’étape précédente étant beaucoup trop technique,
on se propose alors de créer une console personnalisée simplifiée pour les utilisateurs qui n’auront
pas besoin de connaissances approfondies du domaine pour effectuer ces tâches.
Pour commencer, on se connecte au serveur1 avec le compte administrateur RT\Administrateur et
dans le menu Démarrer, on sélectionne Exécuter dans laquelle on saisi mmc.exe. On remarque
qu’une console MMC vierge s’ouvre. Dans l’onglet Fichier, on ajoute un composant logiciel enfichable
et dans la liste qui s’affiche, on choisi Utilisateurs et groupes Active Directory.
Dans l’arborescence, on choisi l’OU Research dont nous avons délégué le droit de réinitialiser les
mots de passe et on choisi une nouvelle fenêtre. On peut alors changer l’affichage de la fenêtre qui
s’affiche en suivant les étapes qui s’affichent à l’écran en faisant attention à laisser coché Exécuter
l’assistant Nouvelle tâche. Cet assistant apparaît et nous guide dans le choix d’une commande que
l’utilisateur aura à utiliser.
On se positionne sur la commande de menu et on sélectionne l’utilisateur auquel nous avons délégué
la réinitialisation des mots de passe (l’utilisateur Amel Hemmam). C’est la que la console
personnalisée apparaît et pour restreindre les actions que pourra exécuter l’utilisateur avec cet outil,
nous désactivons certaines options.

Figure VI.54 : Console vierge

Ensuite, nous protégeons cette console des modifications ultérieures et dans les Options de l’onglet
Fichier, on choisi de nommer la console Réinitialisation des mots de passe et on choisi le Mode
utilisateur, accès limité, fenêtre unique comme mode de console. On autorise simplement
l’utilisateur à personnaliser les vues.
On copie colle la console dans la machine cliente afin que celle-ci soit mise à disposition et
maintenant, l’utilisateur n’a plus qu’à ouvrir la console pour avoir la possibilité de réinitialiser le mot
de passe des utilisateurs de l’OU Research uniquement de manière très simple.

Figure VI.55 : Console enregistrée

On refait les mêmes étapes pour les OU Accounting et Sales.

Suppression d’une délégation de contrôle

Dans cette étape, nous allons supprimer la délégation de réinitialisation de mot de passe que nous
avons accordé. Pour commencer, nous nous connectons au serveur1 avec le compte administrateur
du domaine RT\Administrateur et on lance le gestionnaire Utilisateurs et Ordinateurs Active
Directory. On sélectionne l’OU dont on veut supprimer la délégation c'est-à-dire Research et on
supprime l’utilisateur auquel on a accordé la délégation de réinitialisation de mot de passe de la liste
des entrées d’autorisation.

Figure VI.56 : Suppression de la délégation de contrôle

Afin de vérifier si Amel Hemmam peut toujours réinitialiser les mots de passe, nous nous connectons
à la machine cliente client1 avec son compte et nous essayons de changer le mot de passe.
On remarque que cet utilisateur n’a plus le droit de changer le mot de passe de l’utilisateur ‘souhila
merah’

Figure VI.57 : Accès refusé

Délégation de contrôle total d’un OU

Dans cette étape, nous nous proposons de donner le contrôle total de l’OU «Accounting » à
l’utilisateur Amel Hemmam.

Figure VI.58 : Contrôle total à Amel Hemmam

De ce fait, Amel Hemmam pourra lire, modifier et supprimer le contenu de l’OU.

Figure VI.59 : Récapitulatif

 7- TP 7 : Active Directory –GPO-
Dans le TP précédent, nous avons délégué le contrôle administratif à des unités d’organisation afin
de mieux gérer notre domaine.
Dans ce TP, nous allons apprendre la gestion de stratégie de sécurité locale et la gestion de stratégie
de groupe GPO. Pour ce, nous aurons besoin de notre environnement de virtualisation ainsi que
notre VM serveur1 configuré et promu comme contrôleur de domaine ainsi que du client1. Nous
aurons également besoin d’autres ressources comme le fichier d’installation du logiciel 7-zip :
7z1900.msi, les deux images ResearchWallpaper.png et DomainWallpaper.png.

Première partie : Stratégie de sécurité locale

Application d’une stratégie de sécurité locale

Pour commencer, nous nous plaçons au niveau de la machine client client1 afin d’appliquer une
stratégie de sécurité locale à celle-ci et pour ce, nous allons utiliser l’éditeur de stratégie local.
Cette stratégie de sécurité consistera à interdire l’accès au panneau de configuration. Nous
démarrons alors la VM client1 et nous nous connectons avec le compte de l’administrateur. Depuis
Exécuter du menu Démarrer, on tape gpedit.msc et c’est là que l’éditeur de stratégie de sécurité
s’ouvre et dans les menu, on choisi d’interdire l’accès au panneau de configuration et à l’application
paramètre du PC. On applique ces modifications et on clique OK.

Figure VII.60 : Editeur de stratégie local

On vérifie ensuite que l’accès est bien interdit.

 Figure VII.61 : Accès interdit

Application d’une stratégie de sécurité locale à un utilisateur spécifique

La stratégie de sécurité qu’on a appliqué dans l’étape précédente est appliquée de manière grossière
à tous les utilisateurs car avec gpedit, on ne peut pas spécifier un utilisateur précis et en pratique, ce
n’est pas ce qui est recherché car on ne voudra appliquer les interdictions qu’à quelques utilisateurs.
Dans cette partie, nous allons appliquer des stratégies de sécurité locale qu’à un utilisateur et pour
ce, nous devons lancer la commande mmm.exe dans Exécuter depuis le menu Démarrer. C’est la
qu’une console vierge MMC s’ouvre. On ajoute alors des composants logiciels enfichables dont
l’Editeur d’objet de stratégie de groupe. On recherche les menus spécifiés et on désactive la stratégie
que nous avons appliquée dans l’étape précédente.

Figure VII.62 : Application de la stratégie local à un utilisateur

On enregistre la console et on vérifie que l’on a bien accès au panneau de configuration.

Figure VII.63 : Accès au panneau de configuration autorisé

Deuxième partie : Gestion de stratégie de groupe

Application de stratégie de groupe-Configuration ordinateur

Ce type de stratégie s’applique à la machine peu importe l’utilisateur connecté et pour ce, on se
place sur la VM serveur1 et on la démarre. On se connecte avec le compte administrateur du
domaine qui est RT\Administrateur et on lance le gestionnaire de serveur depuis lequel on trouve
dans Outils la Gestion des stratégies de groupe. On accède au chemin Forest :rt.local > Domains >
rt.local > Objets stratégie de groupe. Le chemin Forest : rt contient toutes les GPO existantes dans le
domaine.
Il y a les GPO par défaut qui sont : default domain controllers et default domain policy
 Figure VII.64 : GPO par défaut

 Ces GPO s’appliquent aux utilisateurs du domaine.

On crée une nouvelle GPO « désactiver le traitement des stratégies locales »

Figure VII.65 : Création d’une nouvelle GPO

On procède ensuite à sa configuration depuis Modifier.

Dans la fenêtre qui s’ouvre, on active cette GPO et on applique ces modifications.
Cette GPO est créée, configurée mais il faut la lier à un conteneur. Dans cette étape, nous allons la
lier à l’OU Ordinateurs qui contient la machine client1.

Dans la boite qui s’ouvre, on sélectionne la GPO que nous avons créé. Il nous suffit de vérifier que
cette GPO est appliquée à n’importe quel utilisateur de l’ordinateur.
On se reconnecte à la machine cliente avec le compte appartenant au groupe G_SEC_Research et on
force l’application de la GPO en tapant dans l’invite de commande gpupdate/force et on vérifie si on
a bien accès au panneau de configuration.

 REPONSE : Oui on a bien accès à l’invite de commande. La GPO appliqué à une unité
d'organisation s'applique directement à tous les utilisateurs et ordinateurs de l'unité
d'organisation, donc elle annule la GPO locale
 Application de stratégie de groupe-Configuration utilisateur
Dans cette partie, nous allons appliquer une stratégie de groupe aux utilisateurs de l’OU « Research »
qui leur attribue un fond d’écran commun.
On se connecte au contrôleur de domaine avec le compte utilisateur du domaine RT\Administrateur
et on crée un partage pour héberger le fichier du fond d’écran qui nous a été fourni
ResearchWallpaper.png en plaçant l’image dans le répertoire partagé NETLOGON.

Figure VII.66 : Dossier NETLOGON

On crée une GPO nommée Fond d’écran Research.

Figure VII.67 : Création d’une GPO fond d’écran

On active le papier paint du Bureau et on choisi le chemin d’accès du fichier que l’on indique dans
l’URL du fichier.
On lie la GPO à l’OU Research

Et pour vérifier le bon fonctionnement de la configuration, on lance la machine cliente avec un

compte de l’OU Research et on force l’application de la GPO depuis l’invite de commande avec
gpupdate/force.
Le fond d’écran s’applique au bureau.
 Figure VII.67 : Fond d’écran appliqué

Le fond d’écran ResearchWallpaper s’applique bien à l’utilisateur de l’ou Research mais on constate
qu’il reste tout noir.

Ordre d’application des GPO

Nous allons dans cette étape appliquer un fond d’écran différent du précédent au domaine afin de
voir l’ordre d’application des GPO. Pour ce, on se connecte au contrôleur de domaine avec le compte
administrateur du domaine RT\Administrateur et on place le fichier DomainWallpaper.png dans le
répertoire partagé NETLOGON.
On crée par la suite une GPO que l’on nomme fond d’écran domaine.
 Figure VII.68 : Nouvelle GPO fond d’écran domaine

On lie ensuite cette GPO à un objet de stratégie de groupe existant.

On se connecte à la machine cliente avec un compte utilisateur appartenant à l’OU Accounting

On le lie à une stratégie de groupe existante

On se connecte à la machine client avec un compte utilisateur appartenant à l’OU « Accouting», on
force l’application de la GPO en tapant gpupdate / force dans l’invite de commande.
 REPONSE : Le fond d’écran appliqué au bureau de l’utilisateur appartenant à l’OU Accounting
est le DomainWallpaper.png, la GPO est appliquée sur le domaine, donc elle s’applique sur
l’OU Accounting.

 REPONSE : Les GPO qui sont appliqués aux utilisateurs de l’OU Accounting sont GPO fond
d’écran domaine et default domain policy.
On se connecte à présent sur la machine client avec un utilisateur qui appartient à l’OU Research.
 REPONSE : le fond d’écran qui est appliqué au bureau de l’utilisateur appartenant à l’OU
Research est le DomainWallpaper.png, la GPO appliquée sur le domaine est prioritaire à
celle appliquée aux OU.

 REPONSE : Les GPOs qui sont t appliquées aux utilisateurs de l’OU «Research» sont fond
d’écran domaine, GPO fond d’écran Research, default domain policy.

Bloquer l’héritage et forcer l’application d’une GPO

On se connecte au contrôleur de domaine avec le compte administrateur du domaine RT\

Administrateur et on lance le gestionnaire des stratégies de groupe et on accède à l’OU Accounting
afin de bloquer l’héritage.
On se reconnecte à la machine cliente avec un compte de l’OU Accounting
 REPONSE : le fond d’écran appliqué au bureau est le fond d’écran par défaut windows,
l’héritage du domaine est bloqué.

Les GPOs qui sont appliquées aux utilisateurs de l’OU Accounting est Default Domain Policy car nous
avons bloqué l’ancienne GPO.

On bloque ensuite l’héritage de l’OU Research dans le Gestionnaire des stratégies de groupe et pour
vérifier, on se connecte à la machine cliente client1 avec un compte utilisateur de l’OU Research.
 REPONSE : le fond d’écran appliqué au bureau est le Researchwallpaper.png. L’héritage du
domaine est bloqué, donc la stratégie appliquée est celle de l’OU.

Ensuite, dans le Gestionnaire des stratégies de groupe du serveur, on applique l’image fond d’écran
domaine au domaine. Cette procédure va changer l’ordre de l’application de la GPO.
Cette manipulation a pour effet de changer les fonds d’écran des utilisateurs des deux OUs Research
et Accounting en forçant l’application du fond d’écran domain.wallpaper.png malgré le blocage de
l’héritage.
 Déploiement du logiciel par GPO
Dans cette étape, nous allons installer un logiciel au format MSI dans la machine cliente en utilisant
une GPO. Nous allons déployer le logiciel 7-zip en mode attribué. Pour ce, nous allons nous connecter
au contrôleur de domaine avec le compte administrateur du domaine RT\Administrateur et nous
déposons le fichier d’installation 7z1900.msi dans le répertoire partagé NETLOGON.

On lance ensuite le gestionnaire de stratégies de groupe et dans le conteneur Objets stratégie de

groupe, on crée une GPO que l’on nomme Installation Application 7-zip.
Dans la GPO, on développe le chemin Configuration ordinateur > Stratégies > Paramètres du logiciel
> Installation de logiciel et on crée un nouveau Package et on spécifie le chemin complet du fichier
\\Serveur1\ NETLOGON\7z1900.msi afin de l’ouvrir et de l’attribuer.
On lie cette GPO à l’OU ordinateur et on constate que le logiciel s’installe au démarrage de la
machine.
On se connecte ensuite à la machine cliente et on vérifie que le logiciel est installé. Le démarrage de
la machine prend un peu plus de temps que d’habitude.
 Configuration d'un script d'ouverture de session via GPO

Nous allons, dans cette étape, configurer un script d’ouverture de session en utilisant les GPO.
On crée un fichier texte dans le répertoire partagé NETLOGON et on tape la commande logoff qui
permet de déconnecter l’utilisateur, on enregistre le fichier avec l’extension .bat

On crée une nouvelle GPO nommée logoff script

On clique droit sur la GPO crée en suite sur Modifier et on développe le chemin Configuration
utilisateur > Stratégies > Paramètres Windows > Scripts> ouverture de session
On clique sur ajouter, et on ajoute le nom complet du fichier, on lie ensuite la GPO à l’OU Research.

On se connecte à la machine client avec un utilisateur appartenant à l’OU Research.

 REPONSE : Dès la connexion au compte utilisateur appartenant à l’OU Research, le compte

se déconnecte instantanément car la GPO applique le script logoff à la connexion.

Mappage automatique d’un lecteur via les Préférences

On commence par créer une nouvelle GPO nommée mappage lecteur réseau :

On clique droit sur la GPO en suite sur Modifier et on développe le chemin suivant: Configuration
utilisateur > Préférences > Paramètres Windows > Mappages de lecteur > Nouveau > Lecteur mappé.
Dans la fenêtre qui s’ouvre, on saisi les informations suivantes :

On Lie cette GPO à l’OU « Accounting» et on se connecte à la machine client avec un compte
utilisateur appartenant à l’OU « Accounting»
 REPONSE : Dans le poste de Travail, le lecteur Ressources partagées existe. (nous n’avons pas
pu faire des captures)

 REPONSE : En changeant l’adresse IP de la machine, le lecteur Ressources partagées n’existe

plus, car nous n’avons ajouté que l’adresse du client.

 REPONSE : Non, nous ne pouvons pas supprimer ce lecteur car nous n’avons pas
l’autorisation.