Windows Server 2025 / Projet final : vérifier le domaine, les droits, les GPO et la restauration

Ce projet de synthèse Windows Server 2025 relie le DNS interne, les identités de domaine, les droits de partage, la stratégie de groupe et la sauvegarde. Pour le réussir, vérifiez l'accès avec des comptes ordinaires, l'application de la stratégie prévue et l'intégrité des données restaurées ; les messages de réussite des consoles ne suffisent pas.

Confirmez l'état de départ et les critères de réussite

Utilisez les serveurs isolés existants : DC1 (172.24.50.10) fournit Active Directory (AD) et le DNS pour ad.example.test, FS1 (172.24.50.20) est un serveur de fichiers membre, et CLIENT1 est joint au domaine. Vérifiez également la réplication si DC2 (172.24.50.11) existe. Ne recréez pas les rôles ou le domaine déjà installés.

Les prérequis sont labuser1 ; les unités organisationnelles (OU) LabUsers, LabGroups, Workstations et Servers sous Lab ; CLIENT1 dans Workstations ; un volume de données NTFS D: et une cible de sauvegarde séparée E: sur FS1. Si les lettres de lecteur servent déjà à d'autres fins, adaptez la préparation avant d'exécuter les commandes. Deux disques virtuels sur un hôte physique offrent de la pratique, mais pas un domaine de défaillance indépendant pour une sauvegarde de production.

Zone Condition de réussite
DNS et domaine Résolution interne, découverte du contrôleur de domaine et ouverture de session réussies
Autorisations labuser1 peut écrire ; l’accès est refusé à un autre compte ordinaire
Stratégie CLIENT1 applique la GPO et le paramètre prévus
Sauvegarde La version enregistrée et l’élément sont disponibles
Restaurer Le hachage du fichier restauré correspond ; les données actuelles sont préservées

Créez de nouveaux dossiers, un partage et des groupes réservés à cet exercice Capstone. Arrêtez si ces noms existent déjà. Des tests effectués uniquement avec un compte administrateur peuvent masquer les problèmes d'autorisation des utilisateurs ordinaires.

Enregistrez une base de référence saine du réseau et du domaine

Exécutez ces requêtes sur CLIENT1. Confirmez que FS1 se résout en 172.24.50.20 et que la découverte du contrôleur de domaine réussit. Gardez le client sur le DNS interne ; le DNS public n’est pas une solution de rechange pour un problème de résolution de domaine.

ipconfig /all
Resolve-DnsName fs1.ad.example.test
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.ad.example.test
nltest /dsgetdc:ad.example.test
whoami

Enregistrez l'état du rôle, l'heure du serveur et l'espace libre de D: et E: de FS1. Si DC2 existe, inspectez repadmin /replsummary et l'enregistrement DNS. Corrigez les problèmes réseau ou de réplication constatés avant d'ajouter de nouvelles politiques et modifications de permissions.

Construisez la chaîne des autorisations fondée sur les groupes

Exécutez ces commandes dans Windows PowerShell avec élévation de privilèges sur DC1. Utilisez l'utilisateur labuser1 existant sans mettre son mot de passe dans le code. AGDLP signifie Accounts → Global groups → Domain Local groups → Permissions (comptes → groupes globaux → groupes locaux de domaine → autorisations) :

Import-Module ActiveDirectory
$groupOu = 'OU=LabGroups,OU=Lab,DC=ad,DC=example,DC=test'
Get-ADUser -Identity 'labuser1' -ErrorAction Stop | Out-Null
foreach ($name in 'GG_Capstone','DL_FS_Capstone_Modify') {
    if (Get-ADGroup -Filter { Name -eq $name }) { throw ('Group already exists: ' + $name) }
}
New-ADGroup -Name 'GG_Capstone' -GroupScope Global -GroupCategory Security -Path $groupOu
New-ADGroup -Name 'DL_FS_Capstone_Modify' -GroupScope DomainLocal -GroupCategory Security -Path $groupOu
Add-ADGroupMember -Identity 'GG_Capstone' -Members 'labuser1'
Add-ADGroupMember -Identity 'DL_FS_Capstone_Modify' -Members 'GG_Capstone'
Get-ADGroupMember -Identity 'DL_FS_Capstone_Modify' -Recursive

Vérifiez que labuser1 apparaît dans le résultat récursif. Déconnectez-vous et reconnectez-vous sur CLIENT1 pour actualiser son jeton d'accès, puis inspectez whoami /groups. Une requête de groupe depuis la session d’un administrateur ne prouve pas que le jeton de l’utilisateur ordinaire a changé.

Vérifiez les accès autorisés et refusés au partage

Sur FS1 avec son rôle de serveur de fichiers installé, ouvrez le Gestionnaire de serveur → Services de fichiers et de stockage → Partages → Tâches → Nouveau partage. Sélectionnez Partage SMB – Rapide et créez D:\Capstone avec le nom de partage Capstone. N'écrasez aucun dossier ni partage existant.

  1. Conservez le contrôle total pour SYSTEM et les administrateurs dans les autorisations NTFS. Accordez à AD\DL_FS_Capstone_Modify le niveau de modification (Modify), en vérifiant les autorisations héritées trop larges et l’Accès effectif pour ce dossier de test.
  2. Accordez à ce même groupe local de domaine l'autorisation de modification (Change) dans les autorisations de partage, tout en conservant l’accès de gestion administrative et en supprimant les droits étendus non souhaités du groupe Everyone.
  3. Ouvrez une session sur CLIENT1 en tant que labuser1, ouvrez \\fs1.ad.example.test\Capstone et enregistrez sample.txt contenant le texte capstone version A.
  4. Ouvrez une session avec un autre compte de test ordinaire, non membre des groupes Capstone, et confirmez que l'accès est refusé.

Les autorisations de partage et NTFS doivent toutes deux permettre l'opération. Si l’accès est autorisé contre toute attente, vérifiez l'identité réelle, les groupes imbriqués, l'héritage et d'autres entrées d'autorisation. Masquer un dossier n'est pas un contrôle d'accès. Si nécessaire, créez un compte ordinaire séparé dans LabUsers sans appartenance aux groupes Capstone ; un administrateur n'est pas adapté pour le test négatif.

Sur FS1, enregistrez le contenu du fichier créé, l’empreinte SHA256 et la liste de contrôle d'accès (ACL) du dossier avant la sauvegarde :

Get-Content -LiteralPath 'D:\Capstone\sample.txt'
Get-FileHash -LiteralPath 'D:\Capstone\sample.txt' -Algorithm SHA256
Get-Acl -LiteralPath 'D:\Capstone' | Format-List

Appliquez une GPO distincte et vérifiez le paramètre effectivement appliqué

Dans la gestion des stratégies de groupe sur DC1, créez et liez un nouvel objet de stratégie de groupe (GPO) Lab-Capstone à l’OU Workstations. Conservez les objets existants tels que Lab-Computer-Message séparés. Un objet GPO et son lien OU sont des éléments de configuration distincts.

  1. Modifiez Configuration de l’ordinateur → Stratégies → Paramètres Windows → Paramètres de sécurité → Stratégies locales → Options de sécurité.
  2. Définissez le paramètre « Ouverture de session interactive : titre du message destiné aux utilisateurs qui essaient de se connecter » sur Capstone lab, puis le texte du message sur Course verification.
  3. Vérifiez l’ordre des liens par rapport aux autres GPO définissant les mêmes valeurs.
  4. Dans une invite de commandes CLIENT1 avec élévation, exécutez gpupdate /force et examinez toute exigence de déconnexion ou de redémarrage.
  5. Exécutez gpresult /r /scope computer, puis déconnectez-vous et vérifiez le message de connexion.

Si la valeur diffère, vérifiez le placement de l'OU de l'ordinateur, le filtrage de sécurité, l'ordre des liens et les conflits. La désactivation temporaire du seul lien Lab-Capstone et le retraitement de la stratégie vous permettent de comparer le résultat précédent. Un autre GPO peut fournir une valeur antérieure ; la suppression d’un lien ne garantit pas un paramètre vide.

Sauvegardez la version A et restaurez-la dans un emplacement séparé

Confirmez que Windows Server Backup est installé sur FS1 et que E: est la cible de test séparée prévue. Conservez le hachage de la version A, examinez la source et la cible dans la référence de commande de sauvegarde, et lisez la confirmation avant de continuer :

wbadmin start backup -backupTarget:E: -include:D:\Capstone -vssCopy
wbadmin get versions -backupTarget:E:

Enregistrez l'heure de la sauvegarde réussie et les éléments disponibles. Modifiez uniquement le nouveau sample.txt pour qu’il contienne capstone version B et conservez B séparément. Cela simule un changement non désiré sans supprimer des fichiers existants ni endommager un volume.

  1. Ouvrez Windows Server Backup → Récupérer et sélectionnez l'heure réelle de la sauvegarde sur E:.
  2. Choisissez Fichiers et dossiers et confirmez que D:\Capstone\sample.txt est disponible.
  3. Sélectionnez la récupération dans un autre emplacement dans un nouveau dossier d’exécution vide au nom unique sous D:\CapstoneRestore.
  4. Vérifiez les options de gestion des collisions et de restauration de la sécurité, puis récupérez.
  5. Trouvez le sample.txt restauré et comparez le contenu A et son empreinte SHA256 avec l’enregistrement avant la sauvegarde.
  6. Confirmez que le fichier actuel D:\Capstone\sample.txt contient toujours B.

Les options de commande de récupération nécessitent également la version, l’élément et la destination corrects. Comparez également les ACL restaurées et l’accès réel. Décidez de remplacer les données actuelles uniquement après validation ; cet exercice ne remplace pas automatiquement l’original.

Enregistrez les preuves opérationnelles et effectuez un nettoyage sélectif

  • Conservez un enregistrement de configuration pour les adresses, DNS, rôles, UO, groupes, partage, GPO et version de sauvegarde.
  • Enregistrez séparément les identités autorisées et refusées, le résultat de la stratégie et l’empreinte du fichier restauré.
  • Documentez les échecs, les actions correctives, la vérification et le temps de récupération.
  • Identifiez les dépendances partagées d'hébergement, de stockage et d'alimentation encore présentes dans le laboratoire.

Pour nettoyer le laboratoire, supprimez d'abord le lien de Lab-Capstone et vérifiez le résultat de la stratégie précédente. Décidez de la conservation des données du partage de test, des copies restaurées et des sauvegardes ; supprimez ensuite uniquement les groupes créés pour l'exercice et, si nécessaire, le compte de test supplémentaire. Préservez les OU LabUsers et LabGroups existantes ainsi que les autres partages.

Les critères de réussite sont les accès autorisés et refusés constatés avec des comptes ordinaires, l'application de la stratégie prévue et la restauration de la version vérifiée. En cas d'échec, examinez chaque couche plutôt que d'assouplir largement le pare-feu, la signature ou les autorisations.