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