ATA

Advanced Threat Analytics (ATA) est une plateforme OnPremise qui permet d’analyser l’ensemble des actions effectuées (accès à des ressources, verrouillage de compte, déplacement latéral…) avec des comptes Active Directory.

ATA fonctionne avec un serveur central qui récupère l’ensemble des logs des contrôleurs de domaines.

Ces logs peuvent être récupérés de deux façons :

• Via un agent installé sur les DC (nommé Lightweight Gateway)
• Via du port mirroring (nommé Full Gateway)

Ce billet s’intéressera uniquement à la configuration d’ATA avec des Lightweight Gateway.

Mise en place

Prérequis pour les Lightweight Gateway

Pour qu’ATA soit efficace il est impératif d’installer l’agent sur l’ensemble des DC du domaine Active Directory.

Pour la mise en place il faut

• l’ouverture du port TCP 443 entre les DC et le serveur ATA
• un compte de service (sans droit d’administration) présent dans l’AD
• un certificat SSL (optionnel, il est possible d’utiliser un certificat auto-signé pour la console d’administration)

Installation du serveur ATA

L’installation du serveur d’administration est très simple et se fait via l’assistant d’installation.

Il est possible de paramétrer le chemin d’installation, le chemin des logs et le certificat qui sera utiliser pour la console web.

La fin de l’installation s’effectue depuis l’interface d’administration web (https://localhost depuis le serveur ATA).

Le compte de service est nécessaire à ce moment pour lire l’AD.

L’étape suivante consiste à télécharger le setup pour les DC.

Installation des Lightweight gateways

L’installation de l’agent sur les DC se fait à travers l’assistant d’installation. Il est possible de paramétrer le chemin d’installation.

Une fois l’agent installé, celui-ci démarre automatiquement et le DC est visible dans l’interface d’administration.

Il est nécessaire de modifier la configuration d’un des DC dans l’interface d’administration pour le désigner comme Domain synchronizer candidate.

Tout DC défini comme Domain synchronizer candidat peut être responsable de la synchronisation entre ATA et le domaine Active Directory.

Analyse

Depuis l’interface d’administration les différentes alertes remontent automatiquement. Celles-ci sont classées par niveau de criticité : High, Medium et Low.

Il est possible de configurer des alertes mail et/ou d’envoyer l’ensemble de ces logs dans un SIEM.

Privileged Identity Management

Privileged Identiy Mangement (PIM) une une fonctionnalité de Microsoft Azure qui permet de déléguer des droits et des ressources dans Azure, Office 365 et Intune.

Mise en place

Prérequis

Pour mettre en place PIM il est indispensable d’avoir sur les comptes qui l'utiliseront :

• Une license Enterprise Mobility + Security (EMS) E5 ou à minima une license Azure AD Premium P2
• Le MFA activé

Par défaut, PIM n’est pas actif dans Azure. Pour l’activer, il faut se rendre sur le portail Azure (https://portal.azure.com) avec des droits d'"administrateur global" et rechercher Privileged Identity Management.

Une page nous invite à vérifier notre identité via le MFA.

Une fois la vérification d’identité effectuée il est possible d’activer la fonctionnalité.

Quelques instants après le service est disponible.

Il est ensuite nécessaire de se déconnecter / reconnecter du portail Azure.

Configuration des rôles

Depuis PIM, dans la section Manage puis Roles, il existe par défaut une quarantaine de rôle que l’on peut modifier.

Dans cet article, je vais modifier le rôle Exchange Administrator pour qu’il soit actif durant 3H et qu'il nécessite une validation (par défaut le rôle est en auto-validation pour une durée d’une heure). Les utilisateurs Adminstrator et Megan auront le pouvoir d’accepter ou non la demande d’accès au rôle.

Pour ça, dans PIM, dans la section Manage puis Settings, je sélectionne Roles.

Je sélectionne le rôle Exchange Administrator et je change les paramètres.

Je peux ensuite depuis PIM, dans la section Manage puis Roles ajouter un utilisateur à mon rôle.

Obtention du rôle

Une fois le rôle ajouté sur l’utilisateur, celui-ci reçoit un mail pour le prévenir.

Depuis le lien présent dans le mail il est alors possible de faire la demande pour activer le rôle.

Une vérification d’identité via MFA est nécessaire à cette étape également.

Une fois l’identité confirmée, il est possible de demander l’activation du rôle.

Je peux réduire le temps d’activation du droit (de 30 minutes à 3h) et je dois indiquer un message pour obtenir les droits.

Une fois la demande effectuée, il ne reste plus qu’à attendre la validation par un administrateur.

Les administrateurs reçoivent un mail indiquant qu’une demande d’activation de rôle est en attente.

Depuis le lien présent dans le mail, il est possible d’accepter ou de refuser la demande.

Un message est obligatoire pour approuvé la demande.

L’utilisateur reçoit alors un mail lui indiquant qu’il dispose des droits d’administration.

Depuis le portail PIM l’utilisateur peut voir ses droits en cours et passés.

Il a également accès à la tuile Admin et bien évidement à la page d’administration d’Exchange dans notre cas.

Log

L’ensemble des droits demandées, validées et refusées est loggé dans PIM, section Activity puis Directory roles audit history.

Les administrateurs ont également le mail prouvant la validation au rôle.

Voila qui conclut ce billet sur PIM !

Azure Information Protection c’est quoi ?

Azure Information Protection abrégé en AIP est une solution disponible dans Azure qui permet de classifier et de protéger des documents / e-mails.

Une fois le document / e-mail classifié il est possible de voir et de contrôler comment celui-ci est utilisé. Par exemple, il est possible d’interdire l’édition du document ou le transfert d’un mail.

Comment ça marche ?

Prérequis

AIP est présent dans les licences Office 365 à partir de la licence E3 avec comme fonctionnalités :

• Licence E3 et + : Classification et protection des documents / e-mails par défaut et automatiques (géré par l’administrateur)
• Licence EMS, AIP Plan 1 : Classification et protection des documents / e-mails par défaut, automatiques et manuels
• Licence EMS, AIP Plan 2 : Prise en compte du chiffrement via HYOK (Hold your own key, chiffrement à partir d’une clé isolée du cloud afin d’augmenter la sécurité)

Le détail de l’ensemble des fonctionnalités est disponible au lien suivant https://azure.microsoft.com/en-us/pricing/details/information-protection/.

Mise en place

Depuis le portail Azure, rechercher Azure Information Protection.

 Labels

Par défaut la page d’administration d’AIP s’ouvre sur les Labels de classification. Il en existe 5 par défaut : Personnel, Public, Général, Confidentiel, Hautement Confidentiel.

A la création d’un label, il est possible de proteger le document. Le chiffrement s’effectue alors via une clé dans Azure ou via une clé de type HYOK.

Il est ensuite possible d’ajouter des permissions sur le label.

Policy

Une fois le label créé, il est nécessaire de créer une politique et de l’appliquée sur les utilisateurs.

Résultats

Il est possible d’installer sur les postes de travail le client AIP (https://www.microsoft.com/en-us/download/details.aspx?id=53018) afin d’avoir un bouton Protéger dans Outlook, Word, Excel…

En sélectionnant dans Protéger le label, un message apparaît pour informer que le mail intègre la protection.

Contexte

Après la migration d'un serveur Mailbox virtualisé vers un nouvel hoster, la réplication des bases Exchange ne fonctionne plus et le message d'erreur suivant est présent lorsque la commande Test-ReplicationHealth est utilisée :

The log copier was unable to continue processing for database DAG\MBX because an error occured on the target server: Continuous replication - block mode has been terminated. Error : the log file sector size does not match the current volume's sector size (-546)

Problèmatique

Ce problème est causé par un changement de la taille de secteur physique des disques sur lesquels les bases sont. Le problème intervient lorsque le nouvel hoster est plus récent que l'ancien et qu'il ne possède pas le même firmware pour le stockage. Exchange n'est pas en capacité de supporter automatiquement le changement d'un disque avec des secteurs de 512 bytes vers un disque avec des secteurs de 4096 bytes.

Pour vérifier cela, lancer la commande suivante : fsutil fsinfo ntfsinfo <Disk>

On remarque que le paramètre Bytes Per Physical Sector n'est pas supporté.

Solution

La solution pour reprendre la synchronisation des bases est de désactiver la réplication granulaire dans un premier temps. Pour cela, créer la clé de registre DWORD suivante avec la valeur 1 :

HKLM\Software\Microsoft\ExchangeServer\v14\Replay\Parameters\DisableGranularReplication

Après avoir redémarré le serveur, si on relance la commande fsutil fsinfo ntfsinfo <Disk> le paramètre Bytes Per Physical Sector accepte désormais les secteurs en 4096 bytes.

A la suite de ce changement, la réplication fonctionne de nouveau correctement.

Remarque : Attention, Microsoft ne supporte pas que la méthode de réplication ne soit pas la même sur l'ensemble des noeuds d'un DAG. Il est donc nécessaire de revenir en arrière une fois le changement effectué ou de désactiver la réplication granulaire sur l'ensemble des noeuds.

L'ensemble de ce problème est expliqué plus en détails sur le lien TechNet : https://blogs.technet.microsoft.com/exchange/2013/04/24/exchange-2010-database-availability-groups-and-disk-sector-sizes/

Contexte

Après le passage d’un Rollup Update, lorsque vous vous connectez à l’OWA la page ne se charge pas et reste vide.

Dans le journal d’évènement l’erreur suivante est présente :

Outlook Web App couldn’t initialize.
A base theme couldn’t be found. The base theme must be in a folder with name = “base”

Solution

Pour résoudre cette erreur, il faut lancer le script UpdateCas.ps1 qui se trouve dans le dossier Scripts présent dans le répertoire d’Exchange Server.

Contexte

Lors d’un passage d’un Rollup Update ou d’un Service Pack (voir lors de l’utilisation d’un script PowerShell fourni par Microsoft), l’assistant d’installation d’Exchange 2010 échoue et l’erreur suivante est présente dans les logs :

Flow of control cannot leave a Finally block.

Solution

L’erreur provient d’une incompatibilité entre votre version de PowerShell et le script.

Pour résoudre l’erreur il faut regarder dans le fichier de log quel script et quelle ligne pose problème.

Ici c’est le script ManageScheduledTask.ps1 ligne 462 qui contient la commande return $success qui est en erreur.

Pour la résoudre il faut remplacer le return $success par Write-Output $success.

Une fois le script modifié, relancer l’assistant d’installation.

Problématique

Lors de l’installation d’un CU sur un serveur Exchange 2013, l’assistant d’installation vous demande de redémarrer en boucle sans jamais valider le redémarrage.

Solution

Si après un redémarrage le message d’erreur apparaît toujours, vous pouvez aller modifier la clé de registre suivante :

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations

Supprimer la valeur de cette clé et relancer l’assistant d’installation.

Problématique

Sur un serveur Exchange 2013, la connexion PowerShell ne s’effectue pas et le portail d’administration affiche une page blanche.

Dans le journal d’événements système un grand nombre d’erreur HttpEvent 15021 est présent.

Ces erreurs peuvent intervenir après le changement d’un certificat sur le serveur Exchange.

Résolution

Le problème vient de la liaison du certificat qui est incorrect sur le port 444. Il faut donc la supprimer et la recréer.

Pour cela, afficher l’ensemble des liaisons SSL avec la commande :

netsh http show sslcert

Récupérer les valeurs du hash et l’application ID de la liaison sur le port 443.

Supprimer la liaison du port 444 avec la commande :

netsh http delete sslcert ipport=0.0.0.0:444

Et recréer une liaison en utilisant le hash et l’application ID du port 443 avec la commande :

netsh http add sslcert ipport=0.0.0.0:444 certhash=XXXXXXX appid=”{XXXXXXXX}”

Dans le journal d’événements deux avertissements HttpEvent 15300 et 15301 apparaissent.

Une fois la modification effectuée, la connexion PowerShell et le portail d'administration sont de nouveau accessibles.

Contexte

La synchronisation entre l’Active Directory et Office 365 est un sujet extrêmement sensible dans un environnement de production. Une mauvaise configuration peut entrainer la suppression de nombreux objets dans le cloud (comptes, groupes…).

Le domaine enfant de mon domaine Active Directory a été décoché dans la configuration de mon connecteur dans la console Synchronization Service Manager.

Figure 1 – Propriétés du connecteur

Lorsque l’on coche à nouveau le domaine enfant et que l’on relance une synchronisation, le domaine enfant n’est pas resynchronisé.

Solution

Lors de la suppression du domaine enfant, les étapes de synchronisation associées sont supprimées.

On remarque en allant dans Configure Run Profiles… sur le connecteur qu’il n’y a qu’une seule étape qui correspond au domaine parent.

Figure 2 – Profil du connecteur pour le Full Import avec une seule étape (domaine parent)

Il est donc nécessaire de recréer les étapes pour le domaine enfant. Pour cela il est recommandé de lancer l’outil de configuration d’Azure AD Connect.

Une fois l’outil de configuration terminée, les étapes pour le domaine enfant sont de nouveaux en place.

Figure 3 – Profil du connecteur pour le Full Import avec deux étapes (domaine parent et domaine enfant)

Il est ensuite nécessaire de relancer dans l’ordre :

• Full Import – Connecteur Active Directory
• Full Synchronisation – Connecteur Active Directory
• Export – Connecteur Active Directory
• Delta Import – Connecteur Office 365 (domaine.onmicrosoft.com)
• Delta Synchronisation – Connecteur Office 365 (domaine.onmicrosoft.com)
• Export – Connecteur Office 365 (domaine.onmicrosoft.com)

Contexte

Depuis la mise à jour de Windows 10 Fall Creator Update (Windows 10 - 1709), lorsque vous éteignez votre machine, au redémarrage l’ensemble des applications qui étaient ouvertes s’ouvrent à nouveau automatiquement.

Pas très pratique si l’on est du genre à éteindre son poste alors que de nombreux programmes sont encore ouverts.

Solution

Pour le moment Microsoft ne propose pas d’option pour activer / désactiver cette (nouvelle) fonctionnalité.

Les solutions possibles pour ne pas avoir ce comportement :

• Passer par ALT + F4 pour éteindre Windows : on remarque alors que Microsoft à ajouter la ligne Ferme toutes les applications et éteint le PC (cf. image)
• Utiliser la ligne de commande shutdown /r /t 0