Windows Server, Active Directory et exploitation

DNS, avant toute autre hypothèse

Une grande partie des incidents attribués au réseau, à l’ERP ou à l’authentification sont des problèmes de résolution de noms. Un contrôleur de domaine pointant vers un redirecteur externe en premier serveur DNS, un enregistrement obsolète après un changement d’adresse, une zone de recherche inversée absente : chacun produit des symptômes éloignés de sa cause. Vérifier la résolution depuis le poste concerné, et non depuis un serveur d’administration, est le premier réflexe utile.

• Ordre des serveurs DNS sur les contrôleurs de domaine et sur les serveurs membres
• Réplication des zones intégrées à l’annuaire entre sites
• Enregistrements périmés après migration ou changement d’adressage
• Cohérence entre les sites et sous-réseaux déclarés dans l’annuaire et la topologie réelle

Certificats et TLS

Un certificat expire à date fixe et provoque une panne totale, sans avertissement pour les équipes qui ne le suivent pas. Au-delà de l’expiration, les incidents proviennent des chaînes de confiance incomplètes, des noms alternatifs manquants après un changement de nom de service, et des versions de protocole désactivées côté serveur mais encore utilisées par une application ancienne.

• Inventaire des certificats, de leur porteur et de leur échéance
• Chaîne intermédiaire réellement servie par le service, pas seulement présente sur le serveur
• Noms alternatifs couvrant tous les noms d’accès utilisés
• Compatibilité des versions TLS avec les applications métier existantes

Dérive de configuration et maintenance préventive

Une infrastructure ne se dégrade pas par accident mais par accumulation : correctifs différés, règles temporaires devenues permanentes, comptes de service partagés, documentation qui date de l’installation. Le travail d’exploitation consiste largement à empêcher cette dérive — vérifier ce qui est censé fonctionner avant que quelqu’un ne signale que cela ne fonctionne plus.

• Sauvegardes vérifiées par restauration, pas par la présence d’un rapport vert
• Correctifs appliqués selon une fenêtre planifiée, avec retour arrière prévu
• Comptes de service inventoriés, avec leur usage et leur échéance de mot de passe
• Documentation d’architecture maintenue à jour à chaque changement

Continuité d’activité

Un plan de reprise se juge sur deux chiffres : la durée d’interruption acceptable et le volume de données que l’on accepte de perdre. Tant que ces deux valeurs ne sont pas décidées par la direction, aucune architecture de sauvegarde ou de réplication ne peut être dimensionnée honnêtement. Le reste — copies hors site, réplication, haute disponibilité — découle de ce choix.