« 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
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.