Travaux Pratique VM (TP1-TP23)

LIEU: LPO Louis-Armand

Date: Octobre 2025 Décembre 2025

TP01 : Machine Virtuelle Windows Server 2019

TITRE DE LA PAGE

TP01 – Mise en place d'un serveur Windows 2019

DESCRIPTION COURTE

Installation et configuration d'une machine virtuelle Windows Server 2019 sous VMware Workstation. Ce projet constitue la base de toute l'infrastructure réseau mise en place tout au long de l'année. Le serveur est configuré avec une adresse IP fixe et une connectivité internet vérifiée.

TECHNOLOGIES UTILISÉES

VMware Workstation · Windows Server 2019 · TCP/IP · Réseau NAT · CMD

COMPÉTENCES DÉMONTRÉES

→ Création d'une machine virtuelle (2 cœurs, 2 Go RAM, 60 Go disque, réseau NAT) → Installation de Windows Server 2019 depuis une image ISO → Configuration d'une adresse IP statique adaptée au sous-réseau NAT VMware → Désactivation du service DHCP intégré de VMware pour éviter les conflits → Vérification de la connectivité internet par ping (www.free.fr) → Renommage du serveur (SRV202501votrenom) et installation des VMware Tools

DIFFICULTÉS RENCONTRÉES

• Conflit d'adresses IP : le DHCP du réseau NAT VMware attribuait la même adresse que celle configurée manuellement → solution : désactiver le DHCP NAT dans le Virtual Network Editor avant de configurer l'IP fixe.
• Ping internet qui ne fonctionnait pas après l'IP fixe → cause : la passerelle ou le serveur DNS n'avait pas été renseigné dans les propriétés TCP/IP.

TP02 : Serveur DHCP Windows

TITRE DE LA PAGE

TP02 – Déploiement d'un serveur DHCP

DESCRIPTION COURTE

Mise en service du rôle DHCP sur le serveur Windows 2019. Ce service distribue automatiquement les configurations réseau (adresse IP, passerelle, DNS) aux machines clientes. Le fonctionnement est validé à l'aide d'une VM Windows 10 cliente.

TECHNOLOGIES UTILISÉES

Windows Server 2019 · DHCP · IPv4 · dhcpmgmt.msc · Windows 10 · ipconfig

COMPÉTENCES DÉMONTRÉES

→ Installation du rôle DHCP depuis le Gestionnaire de serveur → Création d'une étendue IPv4 (plage d'adresses .150 à .200) → Configuration des options d'étendue : routeur (passerelle) et serveur DNS → Activation et vérification de l'étendue (voyant vert dans la console) → Installation d'une VM Windows 10 cliente sur le même réseau NAT → Vérification de l'attribution DHCP via ipconfig /all sur le client

DIFFICULTÉS RENCONTRÉES

• Le PC client ne recevait pas d'adresse IP → cause : le DHCP du NAT VMware était encore actif, créant un conflit → solution : le désactiver dans le Virtual Network Editor.
• L'option DNS de l'étendue pointait vers un mauvais serveur → corrigé en modifiant les options d'étendue dans la console DHCP.

TP03 : Serveur DNS Windows

TITRE DE LA PAGE

TP03 – Configuration d'un serveur DNS

DESCRIPTION COURTE

Installation du service DNS sur le serveur Windows 2019. Le serveur devient son propre résolveur DNS et utilise des redirecteurs externes pour résoudre les noms de domaines internet. Le serveur DHCP est mis à jour pour distribuer l'adresse du nouveau serveur DNS.

TECHNOLOGIES UTILISÉES

Windows Server 2019 · DNS · dnsmgmt.msc · nslookup · Redirecteurs DNS · DHCP

COMPÉTENCES DÉMONTRÉES

→ Installation du rôle DNS et auto-référencement du serveur (il est son propre DNS) → Configuration des redirecteurs DNS externes pour la résolution internet → Mise à jour de l'option DNS dans le serveur DHCP (option 006) → Vérification depuis le client via la commande nslookup → Test de résolution d'un nom de domaine externe (www.free.fr)

DIFFICULTÉS RENCONTRÉES

• Le serveur ne résolvait pas les noms internet → cause : aucun redirecteur DNS configuré → solution : ajouter l'IP du DNS fournie par VMware dans les propriétés du serveur DNS (onglet Redirecteurs).
• Le client continuait d'utiliser l'ancien serveur DNS après la modification DHCP → solution : renouveler le bail IP avec ipconfig /release puis ipconfig /renew.

TP04 : Serveur Active Directory (ADDS)

TITRE DE LA PAGE

TP04 – Active Directory et contrôleur de domaine

DESCRIPTION COURTE

Promotion du serveur Windows 2019 en contrôleur de domaine via le rôle ADDS (Active Directory Directory Services). Création d'une forêt et d'un domaine local, gestion centralisée des comptes utilisateurs et jonction d'un poste client au domaine.

TECHNOLOGIES UTILISÉES

Windows Server 2019 · Active Directory · ADDS · dsa.msc · lusrmgr.msc · Domaine Windows

COMPÉTENCES DÉMONTRÉES

→ Installation du rôle ADDS depuis le Gestionnaire de serveur → Promotion du serveur en contrôleur de domaine (nouvelle forêt, niveau fonctionnel 2016) → Création du domaine votrenom.local avec catalogue global et DNS intégré → Création de comptes utilisateurs de domaine via la console DSA (dsa.msc) → Autorisation du serveur DHCP dans le domaine Active Directory → Jonction d'un PC Windows 10 au domaine et ouverture de session avec un compte de domaine

DIFFICULTÉS RENCONTRÉES

• Erreur lors de la promotion : mot de passe du compte administrateur local vide → solution : définir un mot de passe via lusrmgr.msc avant la promotion.
• Échec de jonction du PC au domaine → cause : le PC n'utilisait pas le bon serveur DNS (il doit pointer vers le contrôleur de domaine) → corriger l'option DNS dans l'étendue DHCP et renouveler le bail IP du client.
• Le service DHCP ne fonctionnait plus après la promotion → cause : le serveur DHCP doit être autorisé dans le domaine Active Directory → action : Menu Action > Serveurs autorisés dans la console DHCP.

TP05 : Deuxième Contrôleur de Domaine

TITRE DE LA PAGE

TP05 – Redondance Active Directory (2e contrôleur de domaine)

DESCRIPTION COURTE

Ajout d'un second contrôleur de domaine pour assurer la haute disponibilité de l'infrastructure. Les deux serveurs se répliquent les données Active Directory toutes les 15 minutes. En cas de panne du serveur principal, l'authentification et les services réseau continuent de fonctionner sans interruption.

TECHNOLOGIES UTILISÉES

Windows Server 2019 · Active Directory · ADDS · DNS · Réplication AD · Haute disponibilité

COMPÉTENCES DÉMONTRÉES

→ Création d'une nouvelle VM Windows Server 2019 avec IP fixe sur le même réseau → Jonction du 2e serveur au domaine existant (votrenom.local) → Installation des rôles ADDS et DNS sur le second serveur → Promotion en tant que 2e contrôleur de domaine pour le domaine existant → Vérification de la réplication des données AD entre les deux serveurs (console DSA)

DIFFICULTÉS RENCONTRÉES

• Le 2e serveur ne pouvait pas joindre le domaine → cause : serveur DNS mal configuré (doit pointer vers l'IP du 1er contrôleur) → corriger dans les propriétés TCP/IP.
• Attention : un contrôleur de domaine ne peut pas être renommé après promotion → il faut d'abord le rétrograder (supprimer le rôle ADDS), le renommer, puis le re-promouvoir.

TP06 : Bascule DHCP (Failover)

TITRE DE LA PAGE

TP06 – Haute disponibilité DHCP par basculement

DESCRIPTION COURTE

Configuration du mécanisme de basculement DHCP entre les deux serveurs Windows 2019. Si le serveur DHCP principal tombe en panne, le serveur secondaire prend le relais automatiquement pour continuer à distribuer les adresses IP aux clients. Ce projet illustre la notion de continuité de service en infrastructure réseau.

TECHNOLOGIES UTILISÉES

Windows Server 2019 · DHCP Failover · Mode Serveur de secours · Active Directory · ipconfig

COMPÉTENCES DÉMONTRÉES

→ Installation du rôle DHCP sur le 2e serveur et autorisation dans le domaine AD → Configuration du basculement DHCP depuis le serveur principal (clic droit sur l'étendue) → Choix du mode "Serveur de secours" avec définition d'un secret partagé → Simulation de panne : arrêt du service DHCP sur SRV01 → Test de continuité : déconnexion/reconnexion de la carte réseau du client → Vérification via ipconfig /all (le serveur DHCP indiqué change vers SRV02)

DIFFICULTÉS RENCONTRÉES

• Le 2e serveur DHCP n'apparaissait pas dans la liste des serveurs partenaires disponibles → cause : il n'avait pas encore été autorisé dans le domaine AD → effectuer la configuration post-installation du rôle DHCP.
• Le client ne renouvelait pas son bail après l'arrêt de SRV01 → solution : simuler une déconnexion réseau en débranchant la carte réseau dans les paramètres de la VM.

TP07 : GPO – Raccourcis sur le bureau

TITRE DE LA PAGE

TP07 – Déploiement de raccourcis par stratégie de groupe (GPO)

DESCRIPTION COURTE

Mise en place d'une stratégie de groupe (GPO) pour déployer automatiquement des raccourcis sur le bureau des utilisateurs selon leur profil métier. Les comptables reçoivent un raccourci vers Sage, les commerciaux vers SalesForce. Le ciblage est géré via les groupes de sécurité Active Directory.

TECHNOLOGIES UTILISÉES

Windows Server 2019 · GPO · gpmc.msc · Active Directory · Groupes de sécurité · Ciblage

COMPÉTENCES DÉMONTRÉES

→ Création de groupes de sécurité globaux dans AD : GG_commerciaux et GG_comptables → Affectation des utilisateurs aux groupes selon leur profil métier → Création d'une GPO (GPO_raccourcis) liée au domaine via gpmc.msc → Ajout de raccourcis URL (Sage / SalesForce) dans les préférences utilisateur → Configuration du ciblage au niveau élément selon le groupe de sécurité → Vérification du bureau utilisateur selon le compte connecté (Rachid / Linda)

DIFFICULTÉS RENCONTRÉES

• Les raccourcis n'apparaissaient pas sur le bureau après ouverture de session → cause : la GPO n'était pas liée au bon niveau (domaine) → vérifier dans gpmc.msc que la GPO est bien liée au domaine et pas seulement créée.
• Le ciblage ne fonctionnait pas → cause : l'option "Exécuter dans le contexte de sécurité de l'utilisateur connecté" n'était pas cochée dans l'onglet Commun du raccourci.
• Forcer l'application de la GPO : utiliser gpupdate /force dans une invite CMD sur le client.

TP08 : NTFS et Partages Réseau

TITRE DE LA PAGE

TP08 – Sécurisation de dossiers partagés (NTFS)

DESCRIPTION COURTE

Mise en place de la sécurité des dossiers partagés réseau via les permissions NTFS et les groupes Active Directory. Application du principe du moindre privilège : chaque utilisateur n'accède qu'aux ressources strictement nécessaires à son travail. Ce projet met en œuvre une bonne pratique fondamentale en administration système.

TECHNOLOGIES UTILISÉES

Windows Server 2019 · NTFS · Partage réseau · UNC · Active Directory · Groupes de sécurité

COMPÉTENCES DÉMONTRÉES

→ Création d'un dossier racine "Partages" et analyse des permissions NTFS héritées → Désactivation de l'héritage et copie des permissions existantes en permissions explicites → Suppression des droits trop larges (groupe "Utilisateurs") pour appliquer le moindre privilège → Création des groupes de sécurité comptaRO (lecture seule) et comptaRW (lecture/écriture) → Attribution des permissions NTFS par groupe sur le sous-dossier compta → Partage du dossier réseau et configuration des droits de partage (chemin UNC) → Vérification des accès : écriture pour le chef comptable, lecture seule pour le stagiaire, accès refusé pour un utilisateur hors groupe

DIFFICULTÉS RENCONTRÉES

• Impossible de modifier les permissions NTFS → cause : l'héritage était actif, les permissions grisées ne sont pas modifiables → solution : désactiver l'héritage via le bouton "Avancé" puis choisir "Convertir en autorisations explicites".
• Un utilisateur hors groupe pouvait quand même accéder au dossier partagé → cause : les permissions de partage (onglet Partage) étaient trop larges, indépendantes des permissions NTFS → les deux niveaux doivent être configurés correctement.
• Le chemin UNC (\NomServeur\compta) ne fonctionnait pas depuis le client → cause : le dossier n'avait pas encore été partagé (onglet Partage > Partager).

TP09 : Module PowerShell NTFS

TITRE DE LA PAGE

TP09 – Gestion des autorisations NTFS en PowerShell

DESCRIPTION COURTE

Installation d'un module PowerShell (NTFSSecurity) permettant de gérer les permissions NTFS en ligne de commande. Ce TP introduit l'administration serveur via CLI et démontre comment auditer les droits d'accès sur les dossiers partagés de manière précise et reproductible, sans passer par l'interface graphique.

TECHNOLOGIES UTILISÉES

Windows Server 2019 · PowerShell · Module NTFSSecurity · Get-NTFSAccess · CLI

COMPÉTENCES DÉMONTRÉES

→ Installation d'un module externe dans PowerShell (NTFSSecurity) depuis PSGallery → Utilisation de la commande Get-NTFSAccess pour lister les permissions d'un dossier → Audit des droits NTFS sur le dossier "partages" (TP08) et son sous-dossier "compta" → Lecture et interprétation d'une sortie PowerShell (Account, Access Rights, IsInherited) → Documentation des résultats avec la commande hostname pour contextualiser les captures

DIFFICULTÉS RENCONTRÉES

• Erreur lors de l'installation du module : politique d'exécution PowerShell trop restrictive → solution : exécuter Set-ExecutionPolicy RemoteSigned avant d'installer le module.
• Le module n'était pas disponible sans connexion internet → solution : vérifier que le serveur accède à PSGallery, ou installer depuis un fichier local.
• La commande Get-NTFSAccess retournait une erreur de chemin → vérifier que le chemin du dossier est correct et que l'héritage a bien été désactivé (cf TP08).

TP10 : Deuxième Partage Réseau

TITRE DE LA PAGE

TP10 – Création d'un second partage réseau sécurisé (etudes)

DESCRIPTION COURTE

Mise en place d'un second dossier partagé "etudes" sur le serveur Windows 2019, en appliquant les mêmes principes que le TP08. Les droits d'accès sont attribués à deux nouveaux utilisateurs via des groupes de sécurité dédiés. La vérification est réalisée en PowerShell avec le module NTFSSecurity.

TECHNOLOGIES UTILISÉES

Windows Server 2019 · NTFS · Partage réseau · Active Directory · PowerShell · Get-NTFSAccess

COMPÉTENCES DÉMONTRÉES

→ Création de comptes utilisateurs de domaine : Lionel MENON et Rachel BEYONCE → Création d'un sous-dossier "etudes" dans le dossier "partages" existant → Désactivation de l'héritage et mise en place de permissions NTFS explicites → Attribution des droits via groupes de sécurité : modification pour Rachel, lecture seule pour Lionel → Isolation des accès : aucun autre utilisateur (hors système et admin) n'a accès → Vérification des permissions avec Get-NTFSAccess depuis PowerShell

DIFFICULTÉS RENCONTRÉES

• Les permissions héritées du dossier parent "partages" accordaient des droits trop larges → solution : désactiver l'héritage sur le sous-dossier "etudes" et supprimer les entrées indésirables une par une.
• Lionel accédait en écriture malgré un groupe en lecture seule → cause : il appartenait aussi au groupe "Utilisateurs du domaine" qui avait des droits résiduels → le supprimer explicitement des permissions du dossier.

TP11 : Lecteurs Réseau par GPO

TITRE DE LA PAGE

TP11 – Mappage automatique de lecteurs réseau par GPO

DESCRIPTION COURTE

Configuration d'une stratégie de groupe (GPO) pour monter automatiquement les dossiers partagés réseau sous forme de lecteurs (J: pour compta, K: pour etudes) à l'ouverture de session utilisateur. Le ciblage par groupe de sécurité garantit que chaque utilisateur n'accède qu'aux lecteurs qui lui sont autorisés.

TECHNOLOGIES UTILISÉES

Windows Server 2019 · GPO · gpmc.msc · Lecteurs mappés · Ciblage · gpupdate · net use

COMPÉTENCES DÉMONTRÉES

→ Création d'une GPO (GPO_lecteurs_reseau) liée au domaine → Ajout de lecteurs mappés dans Configuration utilisateur > Préférences > Paramètres Windows → Mappage du lecteur J: vers le partage \SRV\compta avec ciblage sur les groupes comptables → Mappage du lecteur K: vers le partage \SRV\etudes avec ciblage sur les groupes etudes → Configuration du ciblage par groupe de sécurité (condition OU pour plusieurs groupes) → Vérification : commandes set logonserver, set userdomain, set username et net use sur le client

DIFFICULTÉS RENCONTRÉES

• Les lecteurs n'apparaissaient pas après ouverture de session → cause : la GPO n'était pas encore appliquée → forcer avec gpupdate /force sur le serveur ET sur le client.
• Le lecteur mappé pointait vers un lecteur local (C:) au lieu du partage → erreur dans le champ "Emplacement" : toujours utiliser le chemin UNC complet (\NomServeur\partage).
• Avec plusieurs groupes dans le ciblage, utiliser la condition OU et non ET, sinon un utilisateur membre d'un seul groupe n'obtient pas le lecteur.

TP13 : Lecteur Personnel, Quota et Filtrage

TITRE DE LA PAGE

TP13 – Lecteur réseau personnel, quota et filtrage de fichiers

DESCRIPTION COURTE

Mise en place d'un espace de stockage réseau personnel (Home Drive) pour chaque utilisateur du domaine. Le dossier est créé automatiquement à la première ouverture de session, monté en lecteur U:, et soumis à un quota de 2 Go. Le stockage de fichiers audio et vidéo y est interdit via le Gestionnaire de ressources du serveur de fichiers (FSRM).

TECHNOLOGIES UTILISÉES

Windows Server 2019 · Home Drive · FSRM · Quota · Filtrage de fichiers · GPO · Active Directory

COMPÉTENCES DÉMONTRÉES

→ Création du dossier partagé "dossiersperso" avec permissions NTFS minimales → Partage invisible du dossier (nom terminé par $ pour masquer dans l'explorateur réseau) → Configuration du Home Drive dans les propriétés du compte utilisateur AD (lecteur U:) → Création automatique du sous-dossier personnel à la 1re connexion (via variable %username%) → Installation et configuration du rôle FSRM pour appliquer un quota de 2 Go par utilisateur → Filtrage actif des fichiers audio/vidéo (interdiction, pas seulement avertissement)

DIFFICULTÉS RENCONTRÉES

• Le lecteur U: n'apparaissait pas sur le client → cause : le chemin UNC du Home Drive dans les propriétés AD contenait une erreur de frappe → vérifier avec \NomServeur\dossiersperso$%username%.
• Le quota s'appliquait au dossier parent et non aux sous-dossiers → solution : activer l'option "Appliquer automatiquement le modèle aux sous-dossiers" dans FSRM.
• Le filtrage était en mode "Passif" (avertissement) au lieu d'"Actif" (interdiction) → dans FSRM, vérifier que le type de filtre est bien défini sur "Actif" et non "Passif".

TP23 : Réplication DFS

TITRE DE LA PAGE

TP23 – Haute disponibilité des fichiers avec DFS (réplication)

DESCRIPTION COURTE

Mise en place d'une infrastructure DFS (Distributed File System) pour répliquer automatiquement les dossiers partagés entre deux serveurs Windows. En cas de panne d'un serveur, les utilisateurs continuent d'accéder à leurs fichiers via le même chemin réseau. Ce TP illustre le concept de tolérance aux pannes appliqué au stockage de fichiers en entreprise.

TECHNOLOGIES UTILISÉES

Windows Server 2019 · DFS · DFSR · dfsmgmt.msc · Active Directory · Espaces de noms · Réplication

COMPÉTENCES DÉMONTRÉES

→ Installation du rôle DFS sur les deux contrôleurs de domaine → Création d'un espace de noms de domaine (FichiersVotreNom) géré par les 2 serveurs → Ajout du dossier "compta" dans l'espace DFS avec deux cibles (SRV01 et SRV02) → Configuration du groupe de réplication et désignation du membre principal → Création d'un rapport de propagation pour vérifier la synchronisation des données → Test de tolérance aux pannes : accès au partage DFS même en cas d'arrêt d'un serveur

DIFFICULTÉS RENCONTRÉES

• L'espace de noms DFS ne s'affichait pas sur le 2e serveur → cause : le rôle DFS n'avait pas été installé sur les deux serveurs → installer le rôle sur SRV01 et SRV02.
• La réplication ne démarrait pas → cause : aucun groupe de réplication créé → répondre "Oui" à la question proposée lors de l'ajout de la 2e cible dans l'espace de noms.
• Le rapport de propagation indiquait des erreurs → cause : les données existaient déjà sur les deux serveurs avec des contenus différents → choisir SRV01 comme membre principal pour écraser les données de SRV02 lors de la synchronisation initiale.

TP28 : Serveur Debian SSH et DNAT

TITRE DE LA PAGE

TP28 – Administration Linux à distance (SSH et règle DNAT)

DESCRIPTION COURTE

Installation d'un serveur Linux Debian 12 en mode console (sans interface graphique) et configuration d'un accès SSH à distance via PuTTY. Une règle DNAT est créée dans VMware pour rediriger le trafic SSH de l'hôte vers la machine virtuelle. Ce TP marque l'entrée dans l'administration système Linux, compétence fondamentale pour tout administrateur réseau.

TECHNOLOGIES UTILISÉES

Debian 12 · Linux CLI · SSH · OpenSSH Server · PuTTY · DNAT · VMware NAT · nano · systemctl

COMPÉTENCES DÉMONTRÉES

→ Installation de Debian 12 en mode serveur (CLI uniquement, sans interface graphique) → Configuration manuelle de l'adresse IP statique dans /etc/network/interfaces → Installation du service OpenSSH Server (apt install openssh-server) → Création d'une règle DNAT dans VMware NAT pour rediriger un port externe vers le port SSH 22 → Connexion SSH distante depuis l'hôte Windows via PuTTY (localhost:22010 → VM Debian) → Correction des fichiers réseau (/etc/resolv.conf) et redémarrage du service réseau

DIFFICULTÉS RENCONTRÉES

• La connexion PuTTY était refusée (Connection refused) → cause : erreur de passerelle et de DNS renseignés lors de l'installation → corriger dans /etc/network/interfaces (compte root, commande nano /etc/network/interfaces), puis systemctl restart networking.
• La résolution DNS ne fonctionnait pas malgré la correction réseau → le fichier /etc/resolv.conf n'était pas mis à jour automatiquement → le modifier manuellement avec nano /etc/resolv.conf en ajoutant la bonne adresse nameserver.
• Impossible de se connecter en root via SSH → comportement normal par défaut sur Debian → se connecter avec le compte utilisateur standard, puis utiliser su root si nécessaire.