Présentation

Les services de domaine Azure Active Directory fournissent des services de domaine gérés tels que la jonction de domaine, la stratégie de groupe, le protocole LDAP, etc. Vous pouvez utiliser ces services sans avoir à déployer gérer et apporter des correctifs aux contrôleurs de domaine.

Microsoft à créé ce service pour faciliter aux entreprises la création d’un environnement full cloud dans Azure et de répondre aux différents besoins qui sont principalement le coût et la surcharge administrative.

Configuration

La particularité d’Azure ADDS est qu’on ne peux pas manager l’AD depuis son interface. Il faut obligatoirement passer par d’autres services, par exemple :

• Pour la gestion des comptes il faut passer par le service Azure AD ou un AD On-Prémisse synchronisé.

• Pour la gestion des GPO, des OU il faut passer par une VM du domaine et y installer les outils d’administrations.

Voici un schéma qui résume l’esprit d’Azure ADDS :

Information

Pour la création de VM Azure il est conseillé d’utiliser la série B. Cette série est une nouvelle offre qui a pour avantage d’être la plus basse car elle s’appuie sur un système de crédit. Elle est prévu en majorité pour des charges de travail ne sollicitant pas en permanences le processeur comme par exemple un serveur web ou un environnement de test. Ces machines sont disponibles dans les régions : US – West 2, US – East, Europe – West, et Asia Pacific – Southeast.

Pour plus d’information concernant la configuration d’Azure ADDS, Consulter le lien suivant : https://azure.microsoft.com/en-us/services/active-directory-ds/

Description

Sophos Central vous permet de gérer les politiques de sécurité et d’administrer plusieurs produits depuis une seule interface Web. Aucune installation ou déploiement de serveurs de gestion ne sont requis. Vos serveurs et appareils se connecteront directement à Sophos Central pour recevoir les nouveaux paramètres, envoyer des alertes et partager l’intelligence contextuelle de sécurité.

Installation

Pour pourvoir manager vos appareils il faut dans un premier temps ajouter les comptes utilisateurs dans la console Sophos Central. Pour ce faire il existe deux méthodes soit :

• Ajouter les comptes à la manuellement, en remplissant les informations suivantes :

• Synchroniser les comptes Active Directory de votre entreprise avec l’outil « AD Sync Settings/Status ».

Nous allons nous attarder sur la deuxième méthode.

Tout d’abord il faut se rendre dans l’onglet « Global Settings » et télécharger l’outil.

Lancer l’exécutable sur un Contrôleur de Domaine puis un assistant va apparaître pour configurer la synchronisation.

Mettre votre compte Sophos Central.

Cocher l’option “SSL” puis remplir les informations suivantes.

Note : utiliser un compte de service pour effectuer la synchronisation.

Choisir le ou les domaines puis les “OU” à synchroniser.

Il ne reste plus qu’a définir quand s’effectuera la synchronisation.

Une fois fini cliquer sur « Finished » et l’utilitaire ce synchronisera à l’heure que vous avez indiquez. Pour lancer une première synchronisation il faut cliquer sur « preview and sync ».

Les comptes sont maintenant ajoutés dans Sophos Central.

La dernière étape est d’installer les agents sur les appareils clients. Une des méthodes est de leurs envoyer un mail d’instruction expliquant les différentes étapes d’installation depuis la console Sophos.

Configuration

Dans l’onglet “Endpoint Protection” puis “Policies” vous pouvez configurer les règles de sécurité des utilisateurs.

Il ne reste plus qu’a créer vos règles en fonction de vos besoins.

Information :

Pour plus d’information concernant la configuration, je vous invite à consulter le lien suivant : http://docs.sophos.com/sophos-cloud/help/fr-fr/PDF/scloud_hfra.pdf

Description

Pour attribuer une licence a un utilisateur de votre annuaire Azure, cela nécessite l’une des étapes suivantes :

• Attribution de licences directement aux utilisateurs par l’intermédiaire du portail, de PowerShell ou des API.
• Attribution de licences à des groupes dans le portail Azure.

Quand vous attribuez des licences à un groupe, tous les membres de ce groupe disposent d’une licence. Si des utilisateurs sont ajoutés au groupe ou en sont supprimés, la licence appropriée leur est attribuée ou retirée.

Vous pouvez utiliser l’attribution de licence basée sur le groupe pour configurer des règles telles que les suivantes :

• Tous les utilisateurs de votre annuaire obtiennent automatiquement une licence
• Toute personne avec la fonction appropriée obtient une licence

Configuration

Pour créer un groupe il faut utiliser votre compte d’administration Azure et se rendre à l’adresse suivante : https://portal.azure.com.

Une fois connecté vous devez aller dans le menu « Azure Active Directory ».

Créer un groupe dans le sous menu « Utilisateurs et groupes ».

Puis revenir dans l’onglet « Azure Active Directory » et cette fois ci sélectionner « Licences ».

Une fois que vous êtes dans le menu de vos licences sélectionnez le produit sur lequel vous voulez créer un groupe dynamique et cliquez sur « Attribuer ».

Choisissez le groupe que vous avez crée et configuré le les options de la licence. Cette étape est importante car tous les utilisateur qui seront dans le groupe hériterons de ces options.

Ajouter les membres

L’utilisateur ci-dessous hérite maintenant du groupe «DL_O365_E5»

Information :

Pour plus d’information concernant la configuration, je vous invite à consulter le lien suivant :

Manage Azure Active Directory licencing

Contexte :

Le problème décrit ci-dessous a été rencontré sur le moteur anti-spam de la gamme SOPHOS UTM XG v15

Problème rencontré :

Les utilisateurs ne recevaient pratiquement plus aucuns mails de l’extérieur et les clients avaient en retour le message d’erreur suivant « internal Server Error » :

Analyse :

Les seuls mails qui passaient sont ce dont le domaine était autorisé dans le groupe « XXX Allowed Senders ».

Car une règle de bypass est créée pour ce groupe :

Résolution :

Pour résoudre cet incident il faut changer l’URL vers laquelle la liste Standard RBL pointe car le problème semble venir de cette liste (ou de son provider).

Pour cela vous allez dans Email -> Address Goup :

• Cliquer sur Premium RBL puis récupérer l’URL qui sera affichée.
• Se rendre dans Standard RBL et remplacé les URL présentes par celle de la Premium.
• Copier les URL Standard avant de les supprimer pour les remettre par la suite.

Pour information, l'erreur venait de certaines versions des boitiers UTM de SOPHOS et non d'une mauvaise configuration. Depuis un correctif est sorti afin que cet incident ne se reproduise plus si jamais le fournisseur des RBL Standards s’arrête de fonctionner.

Description

Le pack de contenu Office 365 Adoption dans Power BI permet d’obtenir des informations sur la façon dont votre organisation a adopté les différents services au sein de Office 365 pour communiquer et collaborer. Vous pouvez visualiser et analyser les données d’utilisation Office 365, créer des rapports personnalisés et les partager au sein de votre organisation.

Configuration

Pour profiter de cette nouvelle fonctionnalité il faut utiliser votre compte d’administration Office 365 et se rendre à l’adresse suivante : https://app.powerbi.com

Une fois dessus créer un compte en rentrant votre compte :

Une fois sur votre espace de travail cliquez sur « obtenir des données » depuis le volet de navigation

Cliquez sur « Obtenir » au niveau de la tuile Services

Vous pouvez maintenant choisir et installer l’application dont vous avez besoin. Par exemple vous pouvez installer l’application « Azure Active Directory Activity Logs » qui vas vous permettre d’avoir plusieurs statistiques sur votre infrastructure :

Le prérequis pour cette application est de rentrer le nom de domaine suivi de la procédure d’authentification.

Voici un autre exemple avec l’application « Office 365 Adoption Preview » :

Le prérequis pour cette application est de rentrer le nom de tenant suivi de la procédure d’authentification.

Information

Pour plus d’information concernant la configuration, je vous invite à consulter les liens suivants :

• Pack contenu adoption Office 365
• Enable the Power BI Adoption content pack for Office 365 

Le rançongiciel Petya est apparu fin juin en Ukraine pour ensuite se propager rapidement partout dans le monde.

Il s’agirait d’une variante de WannaCrypt qui était apparu en début d’année.

Se protéger

Si vous n’avez pas encore été infectée, vous devez vérifier que vos postes disposent des dernières mises à jour et de les installer si ce n’est pas le cas.

Pour agir rapidement vous pouvez installer uniquement la KB qui correspond à votre système d’exploitation en regardant la liste sur cette article https://blog.piservices.fr/post/2017/05/30/securite-kb-pour-wanna-cry et de se rendre sur le catalogue de Microsoft pour le télécharger http://www.catalog.update.microsoft.com/home.aspx.

Vérifier avec WSUS

Si vous disposez d’un serveur WSUS vous pouvez vérifier depuis la console si votre parc informatique est protégé. Pour se faire il faut se rendre dans l’onglet Updates -> Security Updates -> Search

Dans la fenêtre qui apparaît vous devez rentrer la KB souhaitez par exemple : 4012212

Lorsque vous regardé le report de la KB (en double cliquant dessus) vous verrez :

• La description de la KB
• Les groupes qui approuvent cette KB
• L’état de déploiement par rapport à vos machines

Microsoft a également sorti un script qui permet de savoir si votre machine dispose du patch ou non. Le seul prérequis est de disposer au minimum de Windows PowerShell 2.0. https://support.microsoft.com/fr-be/help/4023262/how-to-verify-that-ms17-010-is-installed

Voici le script :

[reflection.assembly]::LoadWithPartialName("System.Version")
$os = Get-WmiObject -class Win32_OperatingSystem
$osName = $os.Caption
$s = "%systemroot%\system32\drivers\srv.sys"
$v = [System.Environment]::ExpandEnvironmentVariables($s)
If (Test-Path "$v")     {     Try         {         $versionInfo = (Get-Item $v).VersionInfo         $versionString = "$($versionInfo.FileMajorPart).$($versionInfo.FileMinorPart).$($versionInfo.FileBuildPart).$($versionInfo.FilePrivatePart)"         $fileVersion = New-Object System.Version($versionString)         }     Catch         {         Write-Host "Unable to retrieve file version info, please verify vulnerability state manually." -ForegroundColor Yellow         Return         }     }
Else     {     Write-Host "Srv.sys does not exist, please verify vulnerability state manually." -ForegroundColor Yellow     Return     }
if ($osName.Contains("Vista") -or ($osName.Contains("2008") -and -not $osName.Contains("R2")))     {     if ($versionString.Split('.')[3][0] -eq "1")         {         $currentOS = "$osName GDR"         $expectedVersion = New-Object System.Version("6.0.6002.19743")         }      elseif ($versionString.Split('.')[3][0] -eq "2")         {         $currentOS = "$osName LDR"         $expectedVersion = New-Object System.Version("6.0.6002.24067")         }     else         {         $currentOS = "$osName"         $expectedVersion = New-Object System.Version("9.9.9999.99999")         }     }
elseif ($osName.Contains("Windows 7") -or ($osName.Contains("2008 R2")))     {     $currentOS = "$osName LDR"     $expectedVersion = New-Object System.Version("6.1.7601.23689")     }
elseif ($osName.Contains("Windows 8.1") -or $osName.Contains("2012 R2"))     {     $currentOS = "$osName LDR"     $expectedVersion = New-Object System.Version("6.3.9600.18604")     }
elseif ($osName.Contains("Windows 8") -or $osName.Contains("2012"))     {     $currentOS = "$osName LDR"     $expectedVersion = New-Object System.Version("6.2.9200.22099")     }
elseif ($osName.Contains("Windows 10"))     {     if ($os.BuildNumber -eq "10240")         {         $currentOS = "$osName TH1"         $expectedVersion = New-Object System.Version("10.0.10240.17319")         }     elseif ($os.BuildNumber -eq "10586")         {         $currentOS = "$osName TH2"         $expectedVersion = New-Object System.Version("10.0.10586.839")         }     elseif ($os.BuildNumber -eq "14393")         {         $currentOS = "$($osName) RS1"         $expectedVersion = New-Object System.Version("10.0.14393.953")         }     elseif ($os.BuildNumber -eq "15063")         {         $currentOS = "$osName RS2"         "No need to Patch. RS2 is released as patched. "         return         }     }
elseif ($osName.Contains("2016"))     {     $currentOS = "$osName"     $expectedVersion = New-Object System.Version("10.0.14393.953")     }
elseif ($osName.Contains("Windows XP"))     {     $currentOS = "$osName"     $expectedVersion = New-Object System.Version("5.1.2600.7208")     }
elseif ($osName.Contains("Server 2003"))     {     $currentOS = "$osName"     $expectedVersion = New-Object System.Version("5.2.3790.6021")     }
else     {     Write-Host "Unable to determine OS applicability, please verify vulnerability state manually." -ForegroundColor Yellow     $currentOS = "$osName"     $expectedVersion = New-Object System.Version("9.9.9999.99999")     }
Write-Host "`n`nCurrent OS: $currentOS (Build Number $($os.BuildNumber))" -ForegroundColor Cyan
Write-Host "`nExpected Version of srv.sys: $($expectedVersion.ToString())" -ForegroundColor Cyan
Write-Host "`nActual Version of srv.sys: $($fileVersion.ToString())" -ForegroundColor Cyan
If ($($fileVersion.CompareTo($expectedVersion)) -lt 0)     {     Write-Host "`n`n"     Write-Host "System is NOT Patched" -ForegroundColor Red     }
Else     {     Write-Host "`n`n"     Write-Host "System is Patched" -ForegroundColor Green     }
#

Voici le résultat de se script exécuté sur un poste patché et non patché.

Information :

Si vous êtes déjà touché par le rançongiciel, la première chose à faire est d’isoler tous les équipements identifiés comme étant contaminés en les débranchant du réseau afin de contenir l’action du programme. De plus vous devez si possible mettre en veille prolongé la machine ou de la mettre hors tension pour arrêter l’action du programme et de ne surtout pas payer la rançon.

Vous pouvez lire également deux notes de l’Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI) qui permet de savoir quelle attitude adopter avant et après une attaque rançongiciel.

http://www.cert.ssi.gouv.fr/site/CERTFR-2017-INF-001/CERTFR-2017-INF-001.html

http://www.ssi.gouv.fr/actualite/alerte-campagne-de-rancongiciel-3/

Introduction :

Cette article va vous montrer comment basculer d’un environnement de gestion SG vers un environnement de gestion Sophos Central.

Note : Les boitiers SG (ancienne gamme Sophos) permettent de jouer le rôle de “serveur antivirus”. 

Prérequis :

• Accès à la console d’administration SOPHOS SG et SOPHOS Central.
• Avoir créé ou importé vos utilisateurs dans SOPHOS Central.
  • Pour que les utilisateurs remontent dans Sophos Central il faut au préalable mettre en place l’outil de synchronisation Sophos.

Déploiement :

La première étape consiste à s’identifier sur SOPHOS XG et de désactiver la « Tamper protection » sur tous les utilisateurs.

Pour réaliser cette action la méthode la plus simple est de créer un groupe réunissant tous les utilisateurs à migrer et de désactiver la fonction :

La deuxième étape consiste cette fois ci à s’identifier sur SOPHOS Central et d’envoyer email d’installation aux utilisateurs concerné par la migration  :

La dernière étape quant à elle, est de lancer l’exécutable téléchargé à partir du mail reçu :

L’installation doit être lancé en tant qu’administrateur et prend environ 15 minutes. Pendant ce lapse de temps le logiciel va désinstaller l’ancien antivirus, télécharger le nouveau et l’installer.

Une fois l’opération fini vous allez voir un nouveau logo apparaitre :

Configuration

Sophos Central permet comme à l’instar de SOPHOS SG de créer des groupes pour gérer l’administration. Le plus avec SOPHOS central est qu’il distingue deux catégories. La première est « User and Computer Policies » et la seconde « Server Polices ».

Voici la liste des paramètres qui peuvent être modifié pour les deux catégories.

Fonctionnalité Innovante

La nouveauté de Sophos Central est le module Intercept X qui contient plusieurs outils dont CryptoGuard qui empêche les ransomwares et la Root Cause Analysis.

La RCA permet en cas d’attaque subit d’analyser en profondeur et de donner les détails de l’attaque.

Pour accéder à cette l’interface il faut se rendre dans l’onglet « Root Cause Analysis » puis de sélectionner l’attaque souhaité.

Trois Onglet s’offre à vous.

Overview : Regroupant les informations essentielles de l’attaque QUOI, OU, QUAND et QUI.

Artifacts : Liste tous les fichiers, adresses IP, Processus, clé de registre et toutes les connexions que l’attaque ai touché. Que ce soit en lecture, écriture, connexion.

Visualize : Montre graphiquement comment l’attaque c’est propagé.

Il suffit ensuite de cliquer sur la bulle qui nous intéresse pour nous afficher le détail.

Contexte :

Le problème ci-dessous a été rencontré suite à la suppression du certificat auto-signé d’un Serveur Microsoft Exchange 2013 depuis la console MMC :

Problème rencontré :

Après avoir exécuté quelques mises à jour et redémarré le serveur, le message suivant apparaissait à l’ouverture d’une session PowerShell :

Analyse :

L’observateur d’évènement est un bon outil qui permet d’avoir plus d’information sur une erreur rencontrée. Dans notre cas l’observateur a noté l’Event ID : 15021

« An error occurred while using SSL configuration for endpoint 0.0.0.0:444.  The error status code is contained within the returned data. »

Comme il est impossible de vérifier depuis l’environnement de ligne de commande Exchange Management Shell à quel site Web IIS est attribué un certificat Exchange (la cmdlet Get-ExchangeCertificate permet uniquement de voir que le certificat est associé à IIS sans préciser sur quel site Web), nous allons passer par IIS (Internet Information Services).

Pour se faire nous ouvrons IIS Manager depuis Server Manager :

Note :

Lors de l’installation d’Exchange 2013 celui-ci va créer deux sites Web dans IIS qui doivent avoir ce certificat affecté :

- Default Web Site

- Exchange Back End

Par défaut c’est le site Web Exchange Back End qui a une liaison au port 444 pour le HTTPS. Ce qui correspond à l’Event du dessus.

Sur IIS nous sélectionnons Exchange Back End


Dans l’onglet Edit Site clic droit sur “Bindings” :


Double cliquer sur “https”:

Nous nous apercevons qu’il n’y aucun certificat assigné.

Solution :

Pour résoudre le problème, il suffit de régénérer un certificat auto signé soit avec le centre d’administration Exchange soit en PowerShell.

Une fois le certificat en place nous relançons PowerShell et nous pouvons constater que celui-ci arrive à se connecter au serveur.

Introduction :

Cette article va vous montrer comment migrer un DHCP failover existant de Windows server 2012 à Windows server 2016

Installation :

Installer le rôle DHCP sur les deux nouveaux serveurs.

Sur un des nouveaux serveurs créer deux répertoires : export et backup avec la commande mkdir. Par la suite toutes les commandes seront à effectuer sur ce serveur

Exporter la configuration DHCP de l’ancien Serveur en exécutant la commande suivante :

Export-DhcpServer –ComputerName nameoldserver –File C:\export\naomeoldserverexp.xml -Verbose

Importer la configuration sur le nouveau serveur DHCP avec la commande suivante

Import-DhcpServer –ComputerName DHCP2012R2-1 –File C:\export\DHCP2012-1exp.xml -BackupPath C:\backup\ -ServerConfigOnly -Verbose -Force

Note : Le paramètre « -BackupPatch » est utilisé pour sauvegarder la database du serveur actuel avant toute modification dans le cadre de la migration. Pour annuler l’opération de migration il suffit d’utiliser la commande Restore-dhcpServer suivit du paramètre –path en spécifiant le répertoire backup.

Configuration :

Pour configurer le mode DHCP Failover il faut se rendre dans l’interface DHCP du nouveau serveur et de cliquer sur Configure Failover

Choisir les scopes qui vont être répliqués

Sélectionner le second serveur

Configurer le Failover a isopérimètre avec l’ancien Failover.

Pour vérifier que le Failover est en place utiliser la commande suivante :

Get-DhcpServerv4Failover

Désinstaller l’ancien DHCP :

Une fois le nouveau DHCP Failover en place il faut supprimer l’ancien. Pour ce faire nous allons commencer par retirer la relation entre les deux avec la commande :

Remove-DhcpServerv4Failover –Name nameofrelationship

Une fois la commande réalisée avec succès, il faut arrêter les deux anciens DHCP depuis l’interface :

Si aucun effet de bord ce produit, Il ne reste plus qu’à désinstaller les rôles sur les deux anciens serveurs :

Contexte :

Le problème décrit ci-dessous a été rencontré dans le cadre de la mise en place d’un serveur WSUS sous Windows Server 2012 R2.

Problème rencontré :

Suite à la mise en place de WSUS, toutes les installations de mises jours depuis les serveurs étaient en échec ainsi que la remontée des rapports.

Un code d’erreur apparait : 80244016.

Analyse :

Pour obtenir plus de détails sur ce type de problème, l’outil WireShark peut être utilisé depuis un « client » WSUS afin d’analyser les flux réseau entre le client et le serveur WSUS.

Il faut ensuite filtrer les résultats obtenus sur les protocoles http et https.

La traceWireShark permet de mettre en évidence qu’une erreur de type « http/1.1 400 Bad Request » est déclenchée.

En observant en détail la requête http, on observe que le client WSUS tente de récupérer un fichier « .cab » sur le serveur WSUS avec le nom complet du serveur WSUS (FQDN).

La requête essai de communiquer avec l’host : hote.mondomaine.com.

Explication :

Le problème est dû à une incohérence entre la configuration du site IIS du serveur WSUS et l’URL positionnée sur les clients WSUS.

Les deux valeurs doivent être identiques (soit le nom NetBIOS du serveur WSUS, soit son FQDN).

Pour trouver le paramètre erroné il suffit de vérifier tous les endroits où l’URL est rentrée.

Le premier point à vérifier est la configuration de la stratégie de groupe positionnant l’URL WSUS sur le client.

Pour vérifier il suffit de lancer la commande « Rsop.msc » sur le client WSUS, puis d’aller dans le dossier « Windows Update » dans la section Configuration Ordinateur / Modèle d’administration / Composant Windows :

L’URL est positionnée dans le paramètre « Spécifier l’emplacement intranet du service de mise à jour Microsoft »

Il ne reste plus qu’à vérifier la configuration de IIS. Une fois la page de management est ouverte il faut se mettre sur le site « WSUS Administration ».

Puis aller dans le paramètre « Bindings »

Et d’éditer l’adresse http.

Dans notre exemple, la GPO demande au client d’utiliser le FQDN du serveur alors que le site IIS accepte uniquement les requêtes adressées au nom court.

Résolution :

Pour résoudre le problème, il suffit de modifier le « host name » du site Web IIS par le FQDN du serveur.

Suite au redémarrage de IIS, les clients WSUS peuvent appliquer les mises à jour avec succès.

On peut vérifier en relançant une capture de trames et on s’aperçoit bien que le serveur WSUS répond avec le code 200, ce qui signifie que la requête a été traitée avec succès.