Saturday, January 13, 2018

Active Directory : récupération de la forêt (FR) - 4 - bilan de la récupération

English summary: I have restored one of my domain controllers (DC5) with success and now want to observe what elements are in a failure state. It is easy to predict that there will be numerous replication errors because of the absence of the other domain controllers. I also attempt to establish a link between the failures I observe and the elements that will have to be repared as outlined in the "Perform Initial Recovery" document provided by Microsoft (link below).


***

Et voilà ! Nous avons restauré un de nos contrôleurs de domaine (DC5) et nous avons réussi à ouvrir une session. Cela aurait pu se passer moins bien. Maintenant, nous allons essayer de récupérer notre forêt à partir de ce serveur. En premier lieu, je veux vérifier que le serveur est stable et constater quels éléments sont défaillants. Avant même de jeter le premier coup d’œil, il est facile de prévoir que les tentatives de réplication entre contrôleurs de domaine vont produire de nombreuses erreurs. A vrai dire, nous pourrions poursuivre les étapes de la récupération, énumérées dans le lien ci-dessous, sans nous gêner avec toutes ces observations :

Perform initial recovery

Cependant, j'ai parcouru le document et j'ai envie de voir s'il est possible de mettre en rapport les éléments à réparer qu'on énumère dans le document et l'observation de problèmes que j'ai faite directement moi-même.

***

Dans mon précédent article, j'ai remarqué qu'il fallait réactiver l'exception Bureau à distance. En revanche, je constate que le  "produit" est toujours activé :



La situation se dégrade à mesure que je regarde ailleurs.

De toute évidence, les tentatives de réplication échouent en l'absence de partenaires de réplication. N'importe qui aurait pu le prévoir mais j'ai envie de voir exactement à quoi cela ressemble.

Voici le résultat de la commande repadmin /replsum :



"Le serveur RPC n'est pas disponible."


Cette perspective confirme l'échec de la réplication :



Remarque: "ID de l'invocation DSA" est désormais différent, comme cela se doit après une restauration de la base de données Active Directory. En revanche, le "GUID de l'objet DSA" qui représente le serveur ne change pas. Pour comparaison, j'avais pris note de ces valeurs avant la récupération. Les voici :

C:\>repadmin /showrepl DC5
Site-1\DC5
Options DSA : IS_GC
Options de site : (none)
GUID de l'objet DSA : 5fa213de-9ac3-4871-a388-9e995cfa06fc
ID de l'invocation DSA : af7bac65-7777-449e-b168-31be3bf843e4



La commande DCDIAG relève de nombreuses erreurs aussi. Je ne donne que les extraits les plus pertinents ci-dessous :

---

Démarrage du test : DFSREvent
Erreurs ou avertissements détectés au cours des dernières 24 heures après le partage de SYSVOL. Des problèmes liés à l'échec de la réplication SYSVOL peuvent provoquer des problèmes de Stratégie de groupe.
......................... Le test DFSREvent de DC5 a échoué 

---

Remarque : les erreurs de réplication sont trop nombreuses pour que je recopie chacune ici. Je me contente de cet exemple :

Démarrage du test : Replications
[Replications Check,DC5] Une tentative de réplication récente a échoué :
De DC7 vers DC5
Contexte de nommage : DC=ForestDnsZones,DC=machlinkit,DC=biz
La réplication a généré une erreur (1256) :
Le système distant n'est pas disponible. Pour obtenir des informations à propos du dépannage réseau, consulter l'Aide Windows.
L'échec s'est produit à 2017-12-20 17:53:19.
La dernière réussite s'est produite à 2017-12-16 17:45:42.
3 échecs se sont produits depuis la dernière réussite.

---

Démarrage du test : RidManager
Données endommagées dans le service d'annuaire : rIDPreviousAllocationPool n'est pas une valeur valide
 Aucun RID n'est alloué -- vérifiez le journal des événements.
 ......................... Le test RidManager de DC5 a échoué

---

Tous les autres tests DCDIAG réussisent. En ce qui concerne le test "KnowsOfRoleHolders", je crois qu'il réussit parce que DC5 tient tous les rôles dits "FSMO" :




Dans ce cas contraire, le test échouerait. Voici un extrait de DCDIAG pris lors d'une série de tests avec d'autres contrôleurs de domaine où le détenteur des rôles FSMO n'est pas disponbile :

Démarrage du test : KnowsOfRoleHolders
[DC4] DsBindWithSpnEx() a échoué avec l'erreur 1722,
Le serveur RPC n'est pas disponible..
Avertissement : DC4 désigne Schema Owner, mais ne répond pas à la liaison DS RPC.
La recherche d'attribut de la fonctionnalité de recherche LDAP a échoué sur le serveur DC4 ; valeur
retournée : 81
Avertissement : DC4 désigne Schema Owner, mais ne répond pas à la liaison LDAP.
Avertissement : DC4 désigne Domain Owner, mais ne répond pas à la liaison DS RPC.
Avertissement : DC4 désigne Domain Owner, mais ne répond pas à la liaison LDAP.
Avertissement : DC4 désigne PDC Owner, mais ne répond pas à la liaison DS RPC.
Avertissement : DC4 désigne PDC Owner, mais ne répond pas à la liaison LDAP.
Avertissement : DC4 désigne Rid Owner, mais ne répond pas à la liaison DS RPC.
Avertissement : DC4 désigne Rid Owner, mais ne répond pas à la liaison LDAP.
Avertissement : DC4 désigne Infrastructure Update Owner, mais ne répond pas à la liaison DS RPC.
Avertissement : DC4 désigne Infrastructure Update Owner, mais ne répond pas à la liaison LDAP.
......................... Le test KnowsOfRoleHolders de DC6 a échoué


Les tests Advertising et LocatorCheck échouent aussi, sans compter une multitude de références aux erreurs dans le journal Système de l'Observateur que je me suis décidé à ne pas reproduire ici :

Test du serveur : Site-1\DC6
Démarrage du test : Advertising
Avertissement : DC6 n'effectue pas de publications en tant que serveur de temps.
......................... Le test Advertising de DC6 a échoué

[...]

Exécution de tests d'entreprise sur machlinkit.biz
Démarrage du test : LocatorCheck
Avertissement : l'appel DcGetDcName(PDC_REQUIRED) a échoué ; erreur 1355
Contrôleur principal de domaine introuvable.
Le serveur contenant le rôle PDC ne fonctionne pas.
Avertissement : l'appel DcGetDcName(TIME_SERVER) a échoué ; erreur 1355
Serveur de temps introuvable.
Le serveur contenant le rôle PDC ne fonctionne pas.
Avertissement : l'appel DcGetDcName(GOOD_TIME_SERVER_PREFERRED) a échoué ; erreur 1355
Serveur de temps introuvable.
......................... Le test LocatorCheckde machlinkit.biz a échoué



***


Nous avons récupéré notre contrôleur de domaine mais les erreurs surabondent. Je constate notamment une correspondance entre l'échec de DFSR et l'étape 2 du document (restaurer SYSVOL "avec autorité" - authoritative restore) et les étapes 8 et 9 qui pourraient avoir un rapport avec l'échec du test RidMaster. Dans mes prochains articles, je vais passer par les étapes du document cité plus haut et voir si je ne pourrai pas éliminer ces messages d'erreur.



Monday, January 8, 2018

Active Directory : récupération de la forêt (FR) - 3 - Restauration

English summary: after performing a Full Server Backup of the domain controller DC5 (a physical server) in my previous blog post, I will now attempt a Bare Metal Restore of the same server. It is essentially a matter of booting the server with the installation DVD (same OS, same version) and accessing the backup that was created in a remote shared folder.


***

Dans mon article précédent, j'ai effectué une sauvegarde du serveur entier (Full Server Backup - FSB) au contrôleur de domaine DC5, un serveur physique (IBM x3350). Toujours avec la récupération de notre forêt comme cadre, nous allons maintenant essayer de restaurer le contrôleur de domaine DC5 à même le matériel (Bare Metal Restore - BMR). Il s'agit de faire démarrer le serveur avec le DVD d'installation (même système d'exploitation, même version) et d'accéder à notre sauvegarde à l'emplacement distant où nous l'avons laissée à la fin de ce que j'appellerai notre dernier "chapitre".

Pour les images, je ne pouvais pas utiliser le logiciel de capture d'écran dont je me sers d'habitude. Il a fallu que je prenne des photos avec un téléphone intelligent (avec une caméra assez médiocre). Mais la qualité de l'image est souvent assez floue. De ce fait, j'ai recommencé le processus avec une machine virtuelle pour capturer des images d'une meilleure qualité.

La première étape consiste à faire démarrer le serveur (physique dans ce cas) avec le DVD d'installation. Pour une machine virtuelle, nous utiliserions un fichier .iso. A la fin du démarrage, nous devrions voir s'afficher le choix de la langue, de la monnaie et du clavier. Après avoir fait le choix qui convient à notre environnement, nous cliquons sur "Suivant" :




Au lieu de choisir "Installer maintenant", nous choisissons plutôt l'option "Réparer l'ordinateur" :




Deux choix s'offrent à nous. Dans d'autres scénarios, nous pourrions tenter de réparer le serveur avec divers outils (premier choix) mais dans le cas présent, il s'agit de restaurer notre serveur avec une image système et je choisis donc la seconde option : 




Un message d'erreur s'affiche : "Windows ne peut pas trouver d'image système sur cet ordinateur". Pour bien vérifier la capacité à tout restaurer avec l'image, j'ai recréé le regroupement de disques (RAID) à partir de zéro, ce qui a eu pour effet d'effacer les données en place. Je clique donc sur "Annuler" et puis sur "Suivant" :



Et... je me trouve à cette étape où il faut sélectionner une image système pour la restauration :




A la page suivante, nous avons plusieurs options. Si l'image se trouve sur un disque externe, nous pouvons cliquer sur "Actualiser" pour qu'il soit détecté (si cela ne s'est pas fait tout de suite). Il y a une option pour les sauvegardes sur DVD mais je crois que ce moyen ne doit pas servir bien souvent en raison de la taille limitée de ce type de média. Quoi qu'il en soit, ma sauvegarde réside sur un emplacement réseau et, pour ce cas de figure, il faut cliquer sur "Avancé" afin de lancer la connexion au réseau :




Je clique sur l'option "Chercher une image système sur le réseau" :





Un message nous avertit que le serveur est plus vulnérable dans cet état et que nous devons être certains que le réseau est sûr :




Si nous cliquons sur "oui", le serveur tente une "connexion au réseau" :




Dans mon cas, la connexion réussit (les pilotes pour la carte réseau ont dû s'installer sans accroc) et il nous suffit d'indiquer le chemin vers l'emplacement de la sauvegarde. Notre capacité à résoudre des noms étant sans doute limitée à cette étape, je me sers d'emblée de l'adresse IP :

\\10.8.1.2\dc5bu


Remarque : si la connexion au réseau échouait, ce serait sans doute faute de pilotes réseau convenables. Nous avons eu la possibilité de charger ceux qu'il faut à une étape précédente (voir la capture d'écran plus haut où j'ai cliqué sur l'option "Chercher une image système sur le réseau"


La connexion réussit. Le serveur qui abrite la sauvegarde n'étant pas un membre du domaine (choix fait exprès pour expérimenter ce scénario) et nos moyens d'authentification étant sans doute limités aussi, je suis obligé de saisir des informations de connexion à la main :




Je dois sélectionner l'emplacement...




Ainsi que la date et l'heure de la sauvegarde (au cas où vous auriez un choix - dans mon cas, il n'y a qu'une sauvegarde) :




Ensuite, je choisis l'option de reformater les disques. En cas de piratage, ce serait sans doute une bonne idée (mais peut-être inefficace si nous sommes en présence d'un logiciel malveillant capable de se cacher ailleurs que sur les disques durs) :


Remarque : le texte (un peu flou) en bas de l'écran ci-dessus nous explique que nous pouvons charger des pilotes pour les disques durs si le serveur ne les détecte pas de façon automatique.


Un petit résumé de l'opération s'affiche. Nous cliquons sur "Terminer"...




Nous confirmons une dernière fois...




Et la restauration se met en marche :




Dans mon cas, la restauration a réussi et j'ai fait redémarrer le serveur (aucune capture d'écran pour cela).

J'ai l'intention de présenter l'état du contrôleur de domaine après sa remise sur pied mais isolé de ses partenaires de réplication (les avertissements et les erreurs dans l'Observateur des événements ne manquent pas). Mais ce sera pour un article à venir. Toutefois, je tiens à faire remarquer que les connexions "bureau à distance" (RDP) échouent d'abord.

L'option est bel et bien cochée :


Mais si on lit attentivement (et un peu plus haut), on voit le message (avec le point d'exclamation sur fond jaune) qui nous informe qu'il faut (ré)activer l'exception du pare-feu Windows pour le bureau à distance. Nous pourrions sans doute aller dans les paramètres du pare-feu et les ajuster en conséquence. Cependant, il est plus facile de désactiver le bureau à distance et de le réactiver tout de suite après. Il s'agit de choisir l'option "Ne pas autoriser les connexions à cet ordinateur" (cliquer sur OK) et puis l'option de notre choix pour autoriser la connexion (il y en a deux).

Voici le résultat (et je peux me connecter à distance de nouveau ) :





***

Notre récupération a bien commencé. Nous avons pu restaurer une image complète d'un de nos contrôleurs de domaine et ouvrir une session ensuite. Mais ce n'est qu'un début. Nous nous doutons bien que, pour le moment, c'est le désordre qui règne dans notre domaine avec des partenaires de réplication qui manquent et encore d'autres problèmes. Nous verrons cela dans le prochain article et surtout les opérations à effectuer pour y remettre de l'ordre. 





Monday, January 1, 2018

Active Directory : récupération de la forêt (FR) - 2 - Sauvegarde

English summary: as announced in my previous blog post, I will backup one of my three domain controllers so that a forest recovery is possible. The procedure is simple but we should keep certain details in mind to facilitate the recovery. In particular, it is advisable to perform a full server backup with the system state. Backing up the entire server gives us the option of a "bare metal restore", potentially to different hardware and backing up the system state allows us, logically, to restore the system state. Since Windows Server 2008, the full server backup and the system state backup are similar (in both cases the entire volume containing the operating system and Active Directory elements is backed up) but there are some differences (no bare metal restore with a simple system state backup and no authoritative restore with a simple full server backup). 


***


Dans mon article précédent, j'ai exposé la démarche que j'allais suivre pour préparer une récupération de notre forêt Active Directory et dont la première étape consiste à sauvegarder au moins un de nos contrôleurs de domaine. La sauvegarde peut s'effectuer avec l'interface graphique (GUI) ou à la ligne de commande. C'est le premier de ces deux choix que je présente d'abord, utilisant le serveur DC5. Ensuite, je présente l'opération équivalente à la ligne de commande avec le serveur DC6. 



Sauvegarde avec interface graphique (GUI)

La sauvegarde est une opération assez simple mais pour avoir le plus d'options possibles pour la récupération, il faut tenir compte de certains détails que je préciserai le moment venu.  

Nous commençons le processus en ouvrant l'outil "Sauvegarde de Windows Server" qui se trouve parmi les autres "Outils d'administration". Si nous voyons un message indiquant que l'outil n'est pas installé, il suffit d'aller dans le Gestionnaire de serveur et de l'y ajouter en tant que fonctionnalité.

En pratique, nous voudrons sans doute planifier la sauvegarde afin qu'elle se répète selon un horaire à déterminer. Pour l'instant, je me contente d'effectuer une sauvegarde unique :





Et comme je n'ai justement pas configuré une sauvegarde planifiée, je dois choisir "Autres options", comme vous voyez dans la capture d'écran ci-dessous :


Remarque : Cliquez sur Suivant (ou Terminer, etc.) pour continuer. Je ne le répéterai pas à chaque étape.


Nous voulons faire une sauvegarde du serveur entier, y compris l'état du système. Le premier choix ci-dessous - "Serveur entier (recommandé)" - ferait l'affaire mais je suis curieux de voir les détails et je vais choisir "Personnalisé" à cette fin :




Nous devons cliquer sur "Ajouter des éléments" afin de voir, précisément, ceux qui peuvent se choisir :




Nous allons sélectionner tous les éléments. L'option "Récupération complète" est ce qui permet une restauration directement sur le matériel sans (ré)installer le système d'exploitation au préalable (Bare Metal Restore - BMR) : 




Quant aux paramètres avancés, nous avons la possibilité d'exclure certains fichiers (ce que je n'ai pas fait) et de régler les paramètres VSS. Nous choisissons "Sauvegarde complète VSS" si nous utilisons seulement l'application native ("Sauvegarde de Windows Server") pour nos sauvegardes, ce qui est mon cas :




Ensuite, nous devons choisir un emplacement pour la sauvegarde, soit un lecteur local, soit un dossier partagé distant. Je choisis cette seconde option :




Je spécifie le chemin menant à l'emplacement distant. Le nom du serveur et l'adresse IP du serveur sont tous deux des options valables. Nous pouvons régler l'accès la sauvegarde selon les permissions existantes sur le dossier partagé ou préciser les informations d'identification d'un utilisateur unique. Je choisis l'option "Hériter" :




Selon la nature du serveur abritant le dossier partagé (membre du domaine ou non), nous pourrions avoir besoin de fournir un nom et un mot de passe :




A l'avant-dernière étape, nous avons un résumé de nos choix :




Enfin, je lance la sauvegarde et je peux en suivre la progression :



A la fin de la sauvegarde, nous devrions voir un message indiquant que la sauvegarde s'est achevée sans problème. Dans le cas contraire, évidemment, nous serions obligés de dépanner.



Sauvegarde à la ligne de commande

Voici à quoi ressemble la sauvegarde (avec les mêmes options) effectuée à la ligne de commande du serveur DC6 :

==========

C:\>wbadmin start backup -backuptarget:\\10.8.1.2\dc6bu -allcritical -systemstate -vssfull -quiet
wbadmin 1.0 - Outil de ligne de commande de sauvegarde
(C) Copyright 2004 Microsoft Corp.

Remarque : les données sauvegardées ne peuvent pas être protégées de façon sécurisée dans cette destination.
Les sauvegardes stockées dans un dossier partagé distant peuvent être accessibles à d'autres
personnes sur le réseau. Vous devez uniquement enregistrer vos sauvegardes dans un emplacement
où vous faîtes confiance aux autres utilisateurs qui ont accès à cet emplacement ou sur un
réseau disposant de précautions de sécurité supplémentaires.

Récupération des informations de volume...
Cette opération va sauvegarder le volume Réservé au système (100.00 Mo),Disque local(C:) sur \\10.8.1.2\dc6bu.
Indiquez le nom d'utilisateur et le mot de passe de l'utilisateur qui dispose d'un
accès en écriture sur le dossier partagé distant.

Entrez le nom d'utilisateur de '\\10.8.1.2\dc6bu': backup
Entrez le mot de passe de \\10.8.1.2\dc6bu :
L'opération de sauvegarde sur \\10.8.1.2\dc6bu démarre.
Création d'un cliché instantané des volumes spécifiés pour la sauvegarde...
Création d'un cliché instantané des volumes spécifiés pour la sauvegarde...
Création d'un cliché instantané des volumes spécifiés pour la sauvegarde...
La sauvegarde du volume Réservé au système (100.00 Mo) a abouti.
Création d'une sauvegarde du volume Disque local(C:) en cours, (0%) copiés.
Création d'une sauvegarde du volume Disque local(C:) en cours, (2%) copiés.
Création d'une sauvegarde du volume Disque local(C:) en cours, (5%) copiés.
[...]
Création d'une sauvegarde du volume Disque local(C:) en cours, (90%) copiés.
Création d'une sauvegarde du volume Disque local(C:) en cours, (93%) copiés.
Création d'une sauvegarde du volume Disque local(C:) en cours, (96%) copiés.
Création d'une sauvegarde du volume Disque local(C:) en cours, (99%) copiés.
La sauvegarde du volume Disque local(C:) a abouti.
L'opération de sauvegarde a abouti.
Récapitulatif de l'opération de sauvegarde :
-------------------------

La sauvegarde du volume Réservé au système (100.00 Mo) a abouti.
La sauvegarde du volume Disque local(C:) a abouti.

=========

Il faut bien mettre les options -allcritical et -systemstate pour bénéficier du maximum d'options pour la restauration.

Quelques remarques à garder à l'esprit :

  • Les sauvegardes du serveur entier et les sauvegardes de l'état du système ont à peu près la même taille car, dans les deux cas, est sauvegardé tout volume contenant des éléments du système d'exploitation ou d'Active Directory.
  • Nous ne pouvons pas effectuer une restauration sur du matériel "brut", c'est-à-dire sans système d'exploitation, avec une simple sauvegarde de l'état du système. Il faudrait installer la même version de Windows Server au préalable.
  • Cela dit, même après l'installation d'un système d'exploitation, la restauration de l'état du système vers une nouvelle installation de Windows Server n'est pas prise en charge, même si le matériel est identique et a fortiori si le matériel est différent.
  • Il faut préférer la sauvegarde du serveur entier (Full Server Backup - FSB) pour le scénario ci-dessus parce qu'elle prend en charge la restauration à même le matériel (Bare Metal Restore - BMR), voire vers un matériel différent (en principe - il faudrait éventuellement installer de nouveaux pilotes pour le matériel et cela pourrait malgré tout ne pas réussir pour une raison ou une autre).
  • Nous ne pouvons pas effectuer une restauration "faisant autorité" à même le matériel. Il faudrait, après une restauration vers le matériel même (BMR), effectuer une seconde restauration, celle-ci faisant autorité. C'est un fait à retenir, notamment pour la restauration de SYSVOL, un sujet qui sera traité en plus grand détail dans un article à venir.


***

Maintenant que j'ai une sauvegarde du serveur entier, la prochaine étape consiste à tenter une restauration, ce qui sera le sujet de mon article suivant (et toujours dans le cadre d'une récupération de la forêt).


Références

Sauvegarde de votre serveur

C'est valable pour Windows 2008 R2.

Selon la version originale du même article (en anglais - US), le contenu vaut aussi pour Windows 2012 aussi (et 2012 R2 ?) :

Backing Up Your Server

Wbadmin enable backup

wbadmin -allCritical vs Bare Metal Backup via GUI


Thursday, December 21, 2017

Active Directory : récupération de la forêt (FR) - 1 - Introduction

English summary: I'm starting a series of blog posts about the "forest recovery", one of the more complex Active Directory recovery scenarios. I start with a descripton of my test network. Indeed, one of the primary ingredients for a successful forest recovery is solid documentation. We should know the configuration of our domain controllers and our Active Directory topology. Later steps include a full server backup of one of the domain controllers and an attempt to recovery the forest from this backup. Note that the other domain controllers will most likely have to be reformatted and rebuilt (especially if malicious activity is the cause for forest recovery) although other scenarios are possible.

***  

Dans ce texte, et les textes à suivre, j'aborde un des sujets les plus complexes à propos d'Active Directory : la récupération d'une forêt entière. Certes, il est rare qu'on soit obligé de recourir à une telle opération et la plupart des administrateurs n'en ont jamais fait l'expérience. Cependant, Microsoft nous recommande de préparer pour ce scénario un plan d'action, adapté à notre environnement, et de le répéter au moins une fois par an.

Il faut préciser d'emblée qu'il s'agit d'une opération extrême (surtout si nous comptons de nombreux contrôleurs de domaine) et que nous ne devrions l'entreprendre qu'après avoir consulté l'Assistance technique de Microsoft directement. Selon le guide publié par Microsoft, la récupération d'une forêt entière ne devrait être tentée qu'en dernier recours.

Voici un lien vers l'ensemble de la documentation (en version anglaise originale) :

Active Directory Forest Recovery Guide


***


Mais cette opération à quoi se résume-t-elle exactement ?

Dans certaines circonstances, nous pourrions être amenés à restaurer un seul contrôleur de domaine à partir d'une sauvegarde jugée fiable. De toute évidence, l'existence d'une telle sauvegarde est cruciale. Ensuite, nous supprimerions tous les autres contrôleurs de domaine et les rebâtirions à partir de zéro. En voilà donc les grandes lignes. Nous verrons les détails plus tard. Mais on comprend tout de suite la magnitude d'une telle opération pour une société avec des dizaines, voire des centaines de contrôleurs de domaine.

Et quelles sont ces circonstances ? Voilà quelques exemples (d'autres se trouvent dans la documentation citée plus haut) :

  • Corruption de la base de données de tous les contrôleurs de domaine.
  • Piratage des contrôleurs de domaine.
  • Échec catastrophique d'une mise à niveau du schéma (extrêmement rare mais le recours préféré est un plan de récupération solide - plutôt que la désactivation de la réplication lors de la mise à niveau).

Best Practices for Implementing Schema Updates or : How I Learned to Stop Worrying and Love the Forest Recovery

(Comme d'habitude, la plupart de la documentation est en anglais. Quoi qu'il en soit, remarquez bien les liens vers d'autres sources dans l'article).


Parmi les ingrédients pour une récupération réussie :

  • Une sauvegarde valable.
  • Un DVD d'installation ou un fichier .iso pour le système d'exploitation en question. On fait démarrer le serveur avec ce média et amorce le processus de récupération.
  • Configuration des contrôleurs de domaine (documentation avec carte de la topologie éventuellement (plus il y a de contrôleurs de domaine, plus c'est utile)). 
  • Mot de passe DSRM (mode de restauration des services Active Directory).
  • Informations de connexion d'un administrateur de domaine, de préférence le compte administrateur par défaut. Du point de vue de la récupération, ce compte ne devrait pas être désactivé bien que cela se discute du point de vue de la sécurité. En effet, les tentatives de connexion infructueuses ne peuvent pas verrouiller ce compte et un pirate pourrait, en principe, tenter de se connecter sans cesse. Il vaut sans doute mieux doter le compte d'un mot de passe fort et surveiller de près les tentatives de connexion avec un bon outil d'audit.
  • DNS intégré à Active Directory. Ce n'est pas une obligation mais la mise en oeuvre d'une autre sorte de DNS risque de compliquer la récupération de manière considérable. La documentation suppose d'ailleurs que DNS s'intègre à Active Directory.
  • Des contrôleurs de domaine avec l'interface graphique. Il est possible de récupérer une forêt ne comprenant que des contrôleurs de domaine à interface minimale (Server Core) mais c'est plus complexe et la documentation ne traite pas ce scénario.
  • Une forêt à un seul domaine est le plus facile à récupérer et en particulier pour ce qui concerne les catalogues globaux. Contrairement au scénario pour une forêt à multiples domaines, nous n'avons nul besoin de supprimer le catalogue global existant après la récupération du premier contrôleur de domaine. La documentation fournit plus de détails sur le pourquoi de cette nécessité.

Remarque : je crois comprendre qu'il faut préférer les sauvegardes du serveur entier aux sauvegardes de l'état système. En effet, Microsoft ne prend pas en charge la restauration de l'état système à un autre contrôleur de domaine, voire le même contrôleur de domaine après une réinstallation du système d'exploitation (OS). 


Notre configuration

Nous ne pouvons pas le dire assez : une bonne documentation est un des ingrédients pour une récupération réussie. Dans les lignes suivantes, je fournis en guise de documentation une description de mon banc d'essai.
  • Nous avons une forêt à un seul domaine, ce qui est (depuis un bon moment) la topologie Active Directory que recommande Microsoft.
  • Nous avons trois contrôleurs de domaine exécutant Windows Server 2008 R2 SP1 :
  1. DC5 - 10.8.1.5
  2. DC6 - 10.8.1.6
  3. DC7 - 10.8.1.7
  • Le masque de sous-réseau est /8 ou 255.0.0.0
  • Je ne donne pas ici la passerelle par défaut mais c'est un paramètre à inclure dans la documentation.
  • Quant aux paramètres de serveur DNS, le premier désigne l'adresse IP d'un autre contrôleur de domaine et le second l'adresse IP du contrôleur de domaine en question (sa propre adresse IP). Cette configuration fait l'objet de discussions sur les forums consacrés à Active Directory. D'autres choix sont possibles.
  • Notre niveau fonctionnel de la forêt et du domaine (FFL/DFL) sont tous deux à Window 2008 R2.
  • DC5 tient tous les rôles dits "FSMO".
  • Tous les contrôleurs de domaine sont serveurs DNS (DNS intégré à Active Directory).
  • Les redirecteurs sont des serveurs OpenDNS : 208.67.220.123 et 208.67.222.123

Remarque : quand notre DNS s'intègre à Active Directory, les zones sont bel et bien répliquées entre contrôleurs de domaine. Il n'en va pas de même pour les paramètres des serveurs. Il faut les documenter et éventuellement les rétablir à la main.

  • Chaque contrôleur de domaine est "catalogue global" (GC).
  • DC5 tient tous les rôles dits "FSMO".
  • Nous utilisons DFSR pour la réplication des partages NETLOGON et SYSVOL.
  • Nous sauvegardons nos GPO vers un dossier local, lui-même sauvegardé lors des sauvegardes du serveur entier. Cela peut sembler superflu mais je l'ai vu recommander quelque part (une source fiable).
  • Les serveurs sont "activés" (licence d'essai de 180 jours).
  • Les mises à jour (Windows Updates) sont complètes au moment où j'écris ces lignes.
  • Si nous utilisons un certificat tiers (Verisign, Digicert, etc.), nous devrions en tenir compte. Il serait compris dans une sauvegarde entière du serveur mais si nous devions rebâtir d'autres contrôleurs de domaine (cas tout à fait probable dans une récupération de forêt) nous devrions en avoir un exemplaire sous la main. Une option : l'exporter du serveur qui fait l'objet d'une restauration complète.


Les étapes à suivre (démonstration et détails dans les "chapitres" à venir)

  1. Effectuer une sauvegarde de serveur entier d'un de nos contrôleurs de domaine.
  2. Restaurer le serveur entier sur le matériel même (Bare Metal Restore - BMR).
  3. Faire une restauration d'autorité du SYSVOL.
  4. Nettoyer les métadonnées des contrôleurs de domaine que nous n'allons pas restaurer.
  5. Rajouter ces contrôleurs de domaine à la forêt après une réinstallation du système d'exploitation.



Sunday, December 17, 2017

Office 365 : Exchange Online Protection - délégation des tâches (FR)

English summary: after the overview of Exchange Online Protection features in my previous blog post, I delegate le Hygiene Management role to one of my test users. This is useful for distributing the load of Exchange Online management without granting complete power over the whole tenant to our delegates. Of course, we can use delegation for other Exchange Online features as well. 

***

Dans mon article précédent, j'ai fait un survol des fonctions d'Exchange Online Protection ("EOP") contre les logiciels malveillants et le courrier indésirable (ou "courriel indésirable" ou encore "pourriel" au Québec). Comme pour d'autres éléments d'Exchange Online, il est possible de déléguer la gestion de cette fonction à un groupe de personnes qui n'ont pas un pouvoir d'administration total sur l'ensemble. Dans le cas de la lutte contre les maliciels et les pourriels, il s'agit du rôle : "Hygiene Management"

Remarque : même quand j'ai le français pour la langue d'interface, le nom de ces rôles est en anglais, soit pour des raisons de programmation, soit parce que le compte a été établi en anglais au début.


Nous déléguons la gestion de la protection contre les maliciels et les pourriels en nous reportant à la section "autorisations" du Centre d'administration Exchange :



Remarque : nous pouvons accéder directement au Centre via l'Url suivant :

https://outlook.office365.com/ecp


Je sélectionne le rôle "Hygiene Management" et je clique sur le crayon pour en modifier les propriétés, et notamment les membres (voir la capture d'écran ci-dessus).

Notons que par défaut ce rôle (ce groupe) ne contient aucun membre : 




Dans la section Membres, je clique sur le signe " + "...




Et je choisis la personne à qui j'entends déléguer le pouvoir de gérer EOP. Dans ce cas, nous choisirons Alan Reid :




Je clique sur "ajouter" puis "enregistrer" (etc.) et j'observe qu'Alan Reid tient désormais le rôle de "gestion de l'hygiène (du courrier)" : 



Et maintenant, nous allons ouvrir une session en tant qu'Alan Reid et vérifier que nous pouvons changer un paramètre sous la rubrique "protection".

Encore une fois, voici notre Url :

https://outlook.office365.com/ecp

Je saisis son UPN...



Et son mot de passe :




Nous nous rendons ensuite à la rubrique "protection" et puis au "filtrage du courrier indésirable" :


Remarque : dans le coin tout en haut et à droite, nous pouvons confirmer que nous sommes bien en session sous l'identité d'Alan Reid.


Nous allons changer l'action à faire quand EOP repère un pourriel. Par défaut, le message est déplacé vers le dossier "Courrier indésirable" de la boîte aux lettres de l'utilisateur. Nous voulons plutôt que le message soit dirigé vers la quarantaine :
 


Une remarque en rouge s'affiche. Nous devrions penser à configurer les notifications de courrier indésirable pour les utilisateurs :



Cela se fait à cet endroit (toujours dans la section protection | filtrage du courrier indésirable) :



Selon les apparences, nous devons nous contenter du texte de la notification par défaut. En effet, je ne vois pas d'option pour la composition d'un message personnalisé : 



Comme nous n'avons pas de message en quarantaine, nous ne pouvons pas observer la mise en application de l'action choisie. Il faut dire que mon réseau d'essai n'est sans doute pas une cible prioritaire des pourriels.



Wednesday, December 6, 2017

Office 365 : Exchange Online Protection - éléments de base (FR)

English summary: I present the basic features of Exchange Online Protection (EOP), available with Office 365 plans that include Exchange. I do not address DKIM (DomainKeys Identified Mail) or AMP (Advanced Malware Protection). The first constitutes a subject in itself and the second is not included with Exchange Online Plan 1 (which is what I have). After a brief presentation of each feature, I provide links to Microsoft documentation in English and French.

***

Je compose un nouveau texte de blogue consacré aux options d'Exchange Online Protection ou "EOP". Nous pouvons nous en servir si nous avons un plan Office 365 comprenant Exchange. Tous ces plans comportent au moins les options de base (que je vais passer en revue ici).  Certains plans (E5/G5 par exemple) offrent une protection accrue, notamment l'AMP (Advanced Malware Protection) ou "protection avancée contre les logiciels malveillants). Comme je n'ai pas accès à un tel abonnement, je ne pourrai pas en faire la présentation.

***

Nous accédons aux options EOP dans le Centre d'administration Exchange. La section en question a pour simple titre "protection". Cette section comporte plusieurs sous-sections, visibles dans la capture d'écran plus bas, y compris :
  • filtre anti-programme malveillant (malware filter)
  • filtre de connexion (connection filter)
  • filtrage du courrier indésirable (spam filter)
  • courrier indésirable sortant (outbound spam)
  • quarantaine
  • centre de maintenance (action center)
  • dkim



Remarque : je ne présenterai pas ici DKIM qui constitue un sujet à lui seul.



filtre anti-programme malveillant

EOP fournit un filtre par défaut qui s'appelle "Default" (le mot anglais d'origine). A droite, et sous le titre "Default", les paramètres en sont présentés :



Si nous voulions, nous pourrions créer d'autres filtres, auquel cas le filtre par défaut aurait une priorité relative plus faible (les paramètres des autres filtres s'imposeraient en cas de conflit). Dans le filtre par défaut, ou dans d'autres que nous pourrions être amenés à créer, nous avons la possibilité d'en modifier les paramètres. A priori, le rejet d'un message contenant un programme malveillant ne donne lieu à aucun avertissement au destinataire. Si, au contraire, nous voulons avertir celui-ci, nous pouvons cliquer sur le petit crayon (icône désignée par un point rouge dans notre première capture d'écran) et lui fournir un message, soit un message préfabriqué, soit un message que nous devons composer :





Tenons compte de la nuance entre un programme malveillant dans le corps du message et un tel programme dans une pièce jointe. Dans le premier cas, le message sera supprimé (sans recours, paraît-il). Dans le second cas, le message sera mis en quarantaine mais un administrateur pourrait le libérer. Il faut penser que la pièce jointe elle-même serait supprimée selon la même logique qui veut que le corps du message soit supprimé quand c'est lui qui contient le programme malveillant. Quoi qu'il en soit, si nous voulons que les messages soient libérés seulement à la demande d'un utilisateur qui se porte garant de l'expéditeur, nous aurons besoin de configurer l'envoi d'un avertissement afin qu'on soit au courant de la mise en quarantaine.


Remarque : la section "général" comprend simplement le nom du filtre et une description, le cas échéant :





Nous pouvons configurer encore d'autres options bien que toutes ne soient pas résumées sur ce que j’appellerai la page d'accueil (plus haut dans la première capture d'écran). Par exemple, nous pouvons activer une option qui bloque les pièces jointes d'un certain type (.exe ou .vbs par exemple) :



En cliquant sur le signe "+ ", nous pouvons ajouter encore d'autres types de fichiers.

Notre dernière option dans cette section consiste en la configuration de messages de non remise aux expéditeurs internes, externes, ou les deux, ou bien aux administrateurs. En voici un aperçu :





filtre de connexion

Le filtre de connexion fonctionne par le moyen d'adresses IP que nous pouvons autoriser ou bloquer, et d'une "liste verte". Toutes ces options sont désactivées par défaut :



Dans les propriétés du filtre, nous pouvons activer ces options et mettre les adresses IP de notre choix. Oui, il est possible de spécifier une plage d'adresses. Quant à la "liste verte" (ou "liste fiable" - "safelist" en version anglaise originale), l'infobulle en donne l'explication : il s'agit d'exempter du filtrage certains expéditeurs approuvés qui figurent sur la liste (gérée par Microsoft) :





filtrage du courrier indésirable

Le filtrage du courrier indésirable (spam) nous offre toute une variété d'options...



D'abord, que faire du courrier indésirable ? Nous pouvons le déplacer vers le dossier du même nom (dans Outlook) avec deux jeux d'options distincts selon la probabilité qu'il s'agit effectivement d'un message indésirable. D'autres paramètres sont configurables, comme la durée de conservation des courriers indésirables dans la quarantaine. Certains paramètres sont en gris (désactivés) car ils dépendent des choix en haut de la page. Selon nos choix, nous avons donc plus ou moins d'options activées en bas : 




Selon le choix retenu, d'autres précisions s'affichent :



EOP nous permet de dresser une "liste rouge" des expéditeurs (adresses spécifiques) et des domaines : 



En revanche, il est possible de constituer des "listes vertes" des expéditeurs et des domaines dont nous voulons assurer la remise des messages : 




Bien que des personnes malveillantes puissent lancer des attaques et envoyer des messages indésirables à partir de n'importe quel pays (autre que leur pays d'origine), et dans une variété de langues, nous pouvons tout de même bloquer des courriers selon ces critères :




Enfin, les options avancées nous permettent d'augmenter le taux de mise en quarantaine selon la présence de certaines caractéristiques dans le corps même du message (comme des liens ou un URL) :






courrier indésirable sortant

Il existe des actions spécifiques pour les messages indésirables sortant de notre système de messagerie, soit deux options : envoyer une copie du message à une adresse désignée (ou plusieurs) et envoyer une notification à l'expéditeur :




quarantaine

Comment gérer les messages mis en quarantaine ? Que faire si un utilisateur soumet une demande pour la libération d'un message légitime, bloqué par erreur ? Les administrateurs qui tiennent le rôle "Transport Hygiene" peuvent accéder à la quarantaine et gérer les messages là-dedans. Malheureusement (d'une certaine façon), je n'ai aucun message en quarantaine pour en faire la démonstration.



centre de maintenance

Si un de nos utilisateurs dépasse un certain seuil (non précisé - à ma connaissance) pour l'envoi de messages indésirables, cette personne se retrouvera dans la liste ci-dessous et ne pourra plus envoyer de messages. La documentation Microsoft indique que nous pouvons retirer notre utilisateur de cette liste un certain nombre de fois (non précisé encore une fois). Au-delà de cette limite, nous serions obligés de prendre contact avec l'assistance technique de Microsoft pour sortir notre utilisateur de ce qui fonctionne comme une sorte de quarantaine pour expéditeurs :





Références

Protection anti-courrier indésirable et anti-programme malveillant

Voici l'équivalent en anglais pour ceux qui auraient besoin de se rapporter à la documentation originale :

Anti-spam and anti-malware protection