Intégration professionnelle BTS SIO SISR · Étape 02

Évalue la résilience Active Directory et DNS

Prouve qu'un client conserve authentification et résolution de noms après la perte contrôlée d'un contrôleur de domaine, puis vérifie le retour à un état sain.

Durée indicative · ~2 hNiveau intermédiairePrérequis conseillé · Second contrôleur de domaine, réplication AD, DNS intégré à AD, méthode de diagnostic et dossier de preuvesPratique · TP
Évaluation BTS

« Deux contrôleurs de domaine dans la console suffisent à prouver la haute disponibilité. »

La résilience se démontre depuis le service consommateur : un client doit encore trouver un DC, résoudre les noms nécessaires et conserver un canal sécurisé malgré la perte contrôlée d’un nœud.

01Contrat de l’évaluation

assessmentId : BTS-SISR-Y2-RES-AD-DNS-001
blocs        : Bloc 1 + Bloc 2 SISR + Bloc 3
format       : TP évalué de basculement et retour à l'état sain
contexte     : SORIA Distribution — laboratoire synthétique
objectif     : observer → provoquer → vérifier → restaurer → prouver

Cette page ne redonne pas les commandes des leçons Windows. Les étudiants peuvent utiliser leur documentation, mais doivent choisir eux-mêmes les contrôles pertinents.

02État de départ

Le laboratoire fournit :

SRV-DC01  : AD DS + DNS, en ligne
SRV-DC02  : AD DS + DNS, en ligne
CLIENT-01 : membre du domaine
Domaine   : corp.soria.test

Les deux DC doivent être annoncés dans DNS et la réplication doit être saine avant l’incident.

L’étudiant doit produire une baseline comprenant au minimum :

  • DC découverts dans le domaine ;
  • Global Catalog attendu ;
  • état de réplication ;
  • enregistrements DNS utiles ;
  • résolution depuis le client ;
  • contrôleur actuellement utilisé ou découvert ;
  • secure channel du client ;
  • heure de début de la recette.

Si la baseline est déjà dégradée, l’évaluation de failover n’est pas valide tant que la cause initiale n’est pas traitée.

03Panne imposée

Le formateur ou le scénario impose la perte contrôlée de SRV-DC01 :

arrêt de la VM
OU
coupure réseau contrôlée de la VM

L’étudiant ne doit pas supprimer le DC, modifier sa base AD ou dégrader volontairement DNS.

Il doit d’abord démontrer que le nœud est réellement indisponible depuis le client et depuis le second serveur.

04Service restant à vérifier

Depuis CLIENT-01, l’étudiant doit démontrer sans modifier la configuration pour contourner la panne :

1. résolution d'un nom du domaine ;
2. découverte d'un contrôleur de domaine disponible ;
3. secure channel valide ;
4. accès à une ressource du domaine autorisée au client ;
5. DNS client cohérent avec l'architecture attendue.

Un simple ping n’est pas une preuve suffisante d’authentification ou de résolution AD.

L’étudiant enregistre :

heure de la panne
premier test échoué éventuel
premier test de service réussi
DC réellement utilisé/découvert
impact visible côté client

05Diagnostic si le basculement échoue

Si le client ne continue pas à fonctionner, l’étudiant doit construire des hypothèses au lieu de redémarrer au hasard.

Familles possibles à départager :

configuration DNS client
absence/mauvais enregistrement SRV
réplication AD préalable dégradée
réplication DNS incomplète
secure channel client
service DNS du second DC
routage / pare-feu
problème de temps ou d'authentification

Pour chaque hypothèse retenue :

symptôme observé
→ test discriminant
→ résultat
→ hypothèse conservée ou rejetée

06Retour du nœud

SRV-DC01 est remis en service.

L’étudiant doit alors vérifier que le retour de la VM ne suffit pas à lui seul pour clore l’incident. Il contrôle au minimum :

  • connectivité du DC revenu ;
  • service DNS ;
  • santé de réplication ;
  • SYSVOL ;
  • enregistrements SRV ;
  • découverte de DC depuis le client ;
  • absence d’erreur nouvelle pertinente ;
  • résolution de noms après convergence.

07Rapport de résilience

Le livrable final respecte le contrat de preuve :

EXIGENCE
le service AD/DNS doit rester utilisable après perte d'un DC

CONTEXTE
2 DC/DNS + 1 client membre du domaine

ACTION
panne contrôlée du nœud désigné

RÉSULTAT + VÉRIFICATION
preuves côté client + contrôles de réplication/DNS

LIMITE
ce test ne prouve pas la survie à une panne de site, à la perte simultanée des deux DC,
ni la restauration d'une donnée AD supprimée

Le rapport inclut une chronologie :

T0 baseline saine
T1 panne déclenchée
T2 panne confirmée
T3 service client validé
T4 nœud restauré
T5 réplication/DNS redevenus sains

08Critères de réussite

[ ] baseline AD/DNS réellement saine
[ ] panne du premier DC prouvée
[ ] résolution DNS validée depuis le client pendant la panne
[ ] DC disponible identifié pendant la panne
[ ] secure channel validé
[ ] impact et durée consignés
[ ] retour du DC contrôlé
[ ] réplication et DNS revalidés après retour
[ ] aucune donnée réelle/secrète dans les preuves
[ ] limite de l'expérience explicitement formulée
Décision

Résilient ou seulement redondant ?

À la fin, rends une décision RESILIENCE_VALIDEE, RESILIENCE_AVEC_ACTIONS ou RESILIENCE_NON_DEMONTREE. La décision doit citer les preuves et les limites, pas le nombre de serveurs installés.

✓À retenir

La redondance est une architecture ; la résilience est un comportement démontré sous panne. Pour AD/DNS, la preuve utile vient à la fois du client qui continue à travailler et des contrôles de cohérence lorsque le nœud revient.

0
Ta progression

Chargement de l’état… Se connecter pour synchroniser.