Dans un environnement hybride, avec des utilisateurs synchronisés depuis l'Active Directory vers O365, il n'est actuellement pas possible de changer l'UPN directement par le portail d'administration O365.

Cependant avec les commandes Powershell suivante, il est possible de modifier l'UPN directement dans O365:

Il faut passer par l'adresse technique pour changer l'UPN de l'utilisateur d'un domaine à un autre, il faut cependant que l'UPN final soit égal à la valeur présente dans l'Active Directory Onpremise.

Suite à l'attaque du virus Wanna Cry, tout le monde a souhaité corriger la faille de sécurité au plus vite.

Avec tout ce qu'on a pu lire ou trouver sur internet on ne sait plus vraiment qui fait quoi et si nous sommes réellement protégé.

Liste des KB de Sécurité

Voici la liste des KB de sécurité couvrants la faille (pour information les KB se remplacent d'un mois à l'autre : exemple la KB du mois d'avril remplace celle de Mars):

1. Pour Windows XP, Vista, 8, Windows Server 2003 et 2008 : 
   1. Mars 2017
      1. KB4012598
2. Pour Windows 7 SP1 et Windows Server 2008 R2 SP1:
   1. Mars 2017
      1. Security only update : KB4012212
      2. Monthly Rollup : KB4012215
      3. Preview of Monthly Rollup : KB4012218
   2. Avril 2017
      1. Security only update : KB4015546
      2. Monthly Rollup : KB4015549
      3. Preview of Monthly Rollup : KB4015552
   3. Mai 2017
      1. Security only update : KB4019263
      2. Monthly Rollup : KB4019264
      3. Preview of Monthly Rollup : KB4019265
3. Pour Windows Server 2012 :
   1. Mars 2017
      1. Security only update : KB4012214
      2. Monthly Rollup : KB4012217
      3. Preview of Monthly Rollup : KB4012220
   2. Avril 2017
      1. Security only update : KB4015548
      2. Monthly Rollup : KB4015551
      3. Preview of Monthly Rollup : KB4015554
   3. Mai 2017
      1. Security only update : KB4019214
      2. Monthly Rollup : KB4019216
      3. Preview of Monthly Rollup : KB4019218
4. Pour Windows 8.1 et Windows 2012 R2 :
   1. Mars 2017
      1. Security only update : KB4012213
      2. Monthly Rollup : KB4012216
      3. Preview of Monthly Rollup : KB4012219
   2. Avril 2017
      1. Security only update : KB4015547
      2. Monthly Rollup : KB4015550
      3. Preview of Monthly Rollup : KB4015553
   3. Mai 2017
      1. Security only update : KB4019213
      2. Monthly Rollup : KB4019215
      3. Preview of Monthly Rollup : KB4019217
5. Pour Windows 10 (Release 1511) :
   1. Mars 2017
      1. KB4013198
      2. KB4016636
   2. Avril 2017
      1. KB4015219
   3. Mai 2017
      1. KB4019473
6. Pour Windows 10 (Release 1607) :
   1. Mars 2017 
      1. KB4013429
      2. KB4015438
      3. KB4016635
   2. Avril 2017
      
      1. KB4015217
   3. Mai 2017
      
      1. KB4019472
      2. KB4023680
7. Pour Windows 10 LTSB : 
   1. Mars 2017 
      1. KB4012606
      2. KB4016637
   2. Avril 2017
      
      1. KB4015221
   3. Mai 2017
      
      1. KB4019474

En espérant que cela pourra vous servir.

Pour télécharger les KB : http://www.catalog.update.microsoft.com/home.aspx

Lors de l’installation manuelle d’un agent SCOM (sans passer par l’assistant de la console SCOM), celui-ci doit, par défaut, être approuvé manuellement en passant par les Pending Management de l’onglet Administration de la console.

Dans de rares cas, il peut arriver que malgré une configuration correcte l’agent à approuver (ici nommé « 002 ») n’apparaisse pas et remonte les tant redoutées erreurs 21106 et 20070 indiquant que l’agent n’est pas autorisé à communiquer avec son serveur :

Par contre, l’agent apparait bien lorsqu’on utilise powershell :

Get-SCOMPendingManagement |where {$_.agentname –like ‘xxx’}

Il est alors possible de l’approuver également via Powershell :

Get-SCOMPendingManagement |where {$_.agentname -like ‘xxx’} | Approve-SCOMPendingManagement

Et le tour est joué, l’agent parvient maintenant à communiquer :

Une astuce bien utile, même si elle ne devrait pas vous servir tous les jours!

Bonjour à tous,

Qui n'a jamais rencontré d'échecs lors de la mise en domaine d'un poste ?

Les messages d'erreurs fournis à cette occasion ne sont pas forcément des plus explicites, ni des plus détaillés.

Heureusement il y a une solution et celle-ci s'appelle NetSetup.log

Vous trouverez ce fichier dans le dossier C:\Windows\debug.

Pour ce qui est de la structure du fichier, vous pouvez vous référer à la capture ci-dessous, mais voici un résumé des informations contenues dans celui-ci :

• Nom du contrôleur de domaine contacté pour la jonction au domaine
• Nom du site Active Directory détecté
• Identifiants utilisés pour la jonction
• OU de destination du poste
• Résultats lors de la création de l'objet ordinateur (SPNs, Nom DNS, ... )
• Etc ...

Bonne découverte !

Dans cet article nous allons apprendre comment permettre apache 2.4 (installée sur un linux) à communiquer avec l'ADFS pour faire de l'authentification SSO (Single Sign On)

Contexte 

Apache ne communique pas nativement avec l'ADFS. Pour permettre à des applications web qui tournent sur apache de faire de l'authentification SSO, il faudrait installer deux modules , auth_mellon et lasso , pour permettre la communication.  

Installation des modules nécessaires 

1. auth_mellon

« auth_mellon » est un module Apache qui permet l'authentification d'utilisateurs d'un site web avec un fournisseur d'identité (Identiy Provider — IdP) implémentant SAML 2.0. Il peut accorder des droits d'accès à des chemins et fournir des attributs à d'autres modules ou applications.

Téléchargement du module « auth_mellon » : https://packages.debian.org/fr/sid/libapache2-mod-auth-mellon (nom du paquet: libapache2-mod-auth-mellon) pour debian

Télécharger depuis https://packages.debian.org/fr/sid/libapache2-mod-auth-mellon le fichier *.deb pour l’installation du module « auth_mellon ».

Utiliser la commande suivante pour installer auth_mellon.

dpkg –i libapache2-mod-auth-mellon_0.9.1-1-bpo70+1_amd64.deb

Note: Installer toutes les dépendence liées à « auth_mellon » avant de continuer.

2. lasso

« lasso » est une bibliothèque de modules écrits en C avec des protocoles de communication pour des entités fédérées , SSO et autres produits identiques. Pour que lasso puisse fonctionner,il faudrait en plus de liblasso3, libxml2, XMLSec et OpenSSL. 

Lasso est disponible sur le site http://lasso.entrouvert.org/ en téléchargement en ajoutant la repository dans le fichier sources.list par exemple pour une debian.

deb http://deb.entrouvert.org wheezy main

Note: Installer toutes les dépendence liées à « lasso » avant de continuer.

Génération du fichier métadata *.xml, *.crt, *.key 

Pour la création d'une fédération (federation trust), l'ADFS nécessite le fichier de configuration du Service Provider (SP) qui est le serveur apache et ses applications. Ces fichiers sont créés par le script fournit ci-dessous: 

Le nom du script est mellon_create_metadata.sh et placer dans le dossier /etc/apache2/mellon

#!/usr/bin/env bash
set -e

PROG="$(basename "$0")"

printUsage() {
    echo "Usage: $PROG ENTITY-ID ENDPOINT-URL"
    echo ""
    echo "Example:"
    echo "  $PROG urn:someservice https://sp.mon-application.com/mellon"
    echo ""
}

if [ "$#" -lt 2 ]; then
    printUsage
    exit 1
fi

ENTITYID="$1"
if [ -z "$ENTITYID" ]; then
    echo "$PROG: An entity ID is required." >&2
    exit 1
fi

BASEURL="$2"
if [ -z "$BASEURL" ]; then
    echo "$PROG: The URL to the MellonEndpointPath is required." >&2
    exit 1
fi

if ! echo "$BASEURL" | grep -q '^https\?://'; then
    echo "$PROG: The URL must start with \"http://\" or \"https://\"." >&2
    exit 1
fi

HOST="$(echo "$BASEURL" | sed 's#^[a-z]*://\([^/]*\).*#\1#')"
BASEURL="$(echo "$BASEURL" | sed 's#/$##')"

OUTFILE="$(echo "$ENTITYID" | sed 's/[^0-9A-Za-z.]/_/g' | sed 's/__*/_/g')"
echo "Output files:"
echo "Private key:               $OUTFILE.key"
echo "Certificate:               $OUTFILE.cert"
echo "Metadata:                  $OUTFILE.xml"
echo "Host:                      $HOST"
echo
echo "Endpoints:"
echo "SingleLogoutService:       $BASEURL/logout"
echo "AssertionConsumerService:  $BASEURL/postResponse"
echo

# No files should not be readable by the rest of the world.
umask 0077

TEMPLATEFILE="$(mktemp -t mellon_create_sp.XXXXXXXXXX)"

cat >"$TEMPLATEFILE" <<EOF
RANDFILE           = /dev/urandom
[req]
default_bits       = 2048
default_keyfile    = privkey.pem
distinguished_name = req_distinguished_name
prompt             = no
policy             = policy_anything
[req_distinguished_name]
commonName         = "mon-application.com"
EOF

openssl req -utf8 -batch -config "$TEMPLATEFILE" -new -x509 -days 3652 -nodes -out "$OUTFILE.cert" -keyout "$OUTFILE.key" 2>/dev/null

rm -f "$TEMPLATEFILE"

CERT="$(grep -v '^-----' "$OUTFILE.cert")"

cat >"$OUTFILE.xml" <<EOF
<EntityDescriptor entityID="$ENTITYID" xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <KeyDescriptor use="signing">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>$CERT</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </KeyDescriptor>
    <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="$BASEURL/logout"/>
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="$BASEURL/postResponse" index="0"/>
  </SPSSODescriptor>
</EntityDescriptor>
EOF

umask 0777
chmod go+r "$OUTFILE.xml"
chmod go+r "$OUTFILE.cert"

Note : Changer le CommonName par le FQDN complet, exemple : mon-application.com.

le script se lance comme indique dans la commande ci-dessous: 

sh mellon_create.metadata.sh https://mon-application.com/url_application https://mon-application.com/mellon

L'exécution du script va générer 3 fichiers à envoyer à l'IDP pour la création d'une fédération:

1. https_mon-application.com_url_application.cert
2. https_mon-application.com_url_application.key
3. https_mon-application.com_url_application.xml

Configuration du fichier auth_mellon.conf

Configurer le fichier auth_mellon.conf (etc/apache2/mod-available/auth_mellon.conf) comme dans l’exemple ci-dessous.

# MellonCacheSize sets the maximum number of sessions which can be active
# at once. When mod_auth_mellon reaches this limit, it will begin removing
# the least recently used sessions.
# Default: MellonCacheSize 100
#MellonCacheSize 100

# MellonPostDirectory is the full path of a directory where POST requests
# are saved during authentication. This directory must writeable by the
# Apache user. It should not be writeable (or readable) by other users.
MellonPostDirectory "/var/cache/apache2/mod_auth_mellon/"

<Location />
    # Add information from the mod_auth_mellon session to the request.
    MellonEnable "info"

    # Configure the SP metadata
    # This should be the files which were created when creating SP metadata.
    MellonSPPrivateKeyFile /etc/apache2/mellon/https_mon-application.com_url_application.key
    MellonSPCertFile /etc/apache2/mellon/https_mon-application.com_url_application.cert
    MellonSPMetadataFile /etc/apache2/mellon/https_mon-application.com_url_application.xml

    # IdP metadata. This should be the metadata file you got from the IdP.
    MellonIdPMetadataFile /etc/apache2/mellon/FederationMetadata.xml

    # The location all endpoints should be located under.
    # It is the URL to this location that is used as the second parameter to the metadata generation script.
    # This path is relative to the root of the web server.
    MellonEndpointPath /mellon
</Location>

# This is a location that will trigger authentication when requested.
<Location /sspi/sspi_test.php>
    # This location will trigger an authentication request to the IdP.
    MellonEnable "auth"
MellonSecureCookie On
</Location>
<Location /index.php>
    # This location will trigger an authentication request to the IdP.
    MellonEnable "auth"
MellonSecureCookie On
</Location>
<Location /index_prod.html>
    # This location will trigger an authentication request to the IdP.
    MellonEnable "auth"
MellonSecureCookie On
</Location>
<Location /autoconnect_mail.php>
    # This location will trigger an authentication request to the IdP.
    MellonEnable "auth"
MellonSecureCookie On
</Location>

MellonIdPMetadataFile = le fichier de fédération de l'IDP.

Il ne reste plus qu'à paramétrer l'application pour la connection et redirection automatique.

Voici une petite commande vous permettant d'extraire la liste des updates installées sur une machine (poste client comme serveur).

Get-WmiObject -Class "win32_quickfixengineering"

Cette commande vous permet de récupérer le HotFixID, le compte qui a installé la KB ainsi que la date d'installation.

Bonjour à tous,

Aujourd'hui, nous allons aborder l'initialisation du dossier SYSVOL lors de la promotion d'un contrôleur de domaine (ou "DCPROMO" pour les intimes).

Quelques précisions pour débuter

Tout d'abord, il convient de rappeler quelques informations à propos du dossier SYSVOL en lui même.

Ce dossier se divise en plusieurs sous-dossiers, dont les deux plus importants sont :

• Policies : dossier qui contient tous les fichiers de définitions de toutes les GPO pour le domaine Active Directory concerné
• Scripts : dossier qui contient tous les scripts/fichiers/installeurs que vous voulez utiliser dans des GPO ou autres. Ce dossier Scripts est partagé sous l'URI \\contoso.com\NETLOGON.

Le principe du dossier SYSVOL est d'être automatiquement répliqué entre tous les contrôleurs de domaine d'un domaine Active Directory via les mécanismes suivants :

• FRS : mécanisme de réplication utilisé jusqu'à Windows Server 2003 R2. Il est à noter que lors d'une opération de mise à jour d'une Infrastructure AD, le mécanisme FRS reste en place même si le niveau fonctionnel du domaine est passé en 2008 R2. Il faut utiliser l'utilitaire Dfsrmig.exe pour mettre à jour manuellement le mécanisme de réplication vers DFS.
• DFS : mécanisme de réplication utilisé à partir de Windows Server 2008. Utilise DFS-N pour la mise à disposition du dossier Sysvol sous la forme de l'URI \\contoso.com\SYSVOL et DFS-R pour la réplication des données du dossier.

En résumé, ce dossier SYSVOL est mis à disposition sur chaque contrôleur de domaine via les deux partages suivants :

• SYSVOL : X:\SYSVOL\sysvol
• NETLOGON : X:\SYSVOL\sysvol\contoso.com\SCRIPTS

Promotion d'un contrôleur de domaine

Le but de cette section n'est pas de revenir sur comment faire la promotion d'un contrôleur de domaine, mais plutôt de préciser ce qu'il se passe lors de cette promotion pour l'initialisation du dossier SYSVOL.

Le diagramme de flux ci-dessous nous présente les étapes d'une promotion d'un contrôleur de domaine. La partie qui nous intéresse se situe plus spécifiquement lors de l'étape Installation et après le redémarrage post-promotion du contrôleur de domaine.

Une fois les pré-requis validés dans l'assistant de promotion, la copie de toutes les partitions de l'annuaire AD est effectuée à partir de l'AD de référence (renseigné précédemment).

Lorsque la copie des informations des partitions de l'AD est complète, le nouveau contrôleur de domaine redémarre.

Pour ceux que cela intéresse, le détail de la promotion se situe dans le fichier de log suivant : %SystemRoot%\debug\DCPROMO.TXT

Pour ceux qui veulent encore plus de détails, vous pouvez allez voir le fichier de log : %SystemRoot%\debug\DCPROMOUI.TXT

Initialisation du dossier SYSVOL

On pourrait croire, suite au redémarrage du serveur, que celui-ci est devenu d'office contrôleur de domaine mais ce n'est pas le cas.

En effet, si les informations des partitions de l'AD ont été copiées, en revanche, le dossier SYSVOL lui n'a pas encore été initialisé.

Vous pouvez le constater en tapant la commande net share, les partages en question n'apparaissent pas.

Si vous faites un DCDIAG, vous verrez que les tests Advertising et Netlogons sont en échec, ce qui est normal à cette étape.

Si vous regardez la section Replication DFS de l'observateur d'événements, vous devriez apercevoir l'événement suivant (4614) :

Cet événement indique clairement que le dossier SYSVOL est en cours d'initialisation à partir du DC de référence indiqué lors de l'assistant de promotion et que ce serveur ne s'annoncera pas contrôleur de domaine tant qu'il n'aura pas fini l'initialisation de ce dossier.

Si tout se passe bien, au bout de quelques minutes/heures/jours (rayez la mention inutile), vous devriez voir l'événement suivant (4604) indiquant que le dossier SYSVOL s'est bien initialisé :

Si vous tapez la commande net share, les partages SYSVOL et NETLOGON apparaissent et un DCDIAG ne vous donne plus d'erreur sur les tests Advertising et Netlogons.

En conclusion, votre serveur est devenu un contrôleur de domaine pleinement fonctionnel.

Quand l'initialisation ne fonctionne pas

Malgré de nombreux cafés pris, il se peut que le dossier SYSVOL n'est toujours pas initialisé, ce qui se traduit par la présence de l'événement 4614 mais que vous attendez en vain l'événement 4604 dans l'observateur d'événements.

Une plus ample analyse des journaux de votre serveur ne vous donnera pas beaucoup d'aide sur les raisons de cette non complétion, mais en revanche, ceux du serveur partenaire de réplication le peuvent.

En regardant ces journaux sur le serveur partenaire, nous voyons que la cause de la non-réplication est un fichier du dossier SYSVOL resté en lecture seule. Cependant, ce n'est qu'un exemple parmi d'autres de points de blocage.

Pour débloquer la situation, à partir de ce constat, vous avez deux choix :

• Résoudre le problème sur le serveur "source" pour la réplication
• Dé-promoter le serveur et le re-promoter mais en choisissant comme contrôleur de domaine source un serveur fonctionnel au niveau de la réplication DFS

Suite à ces corrections, vous n'aurez plus qu'à "guetter" l'événement 4604.

Désormais, lorsque vos partages SYSVOL et NETLOGON sont manquants, vous n'aurez plus d'excuses !

Lors du déploiement de Direct Access, le gros de l’attention est communément porté sur la configuration des accès de l’extérieur vers l’intérieur ; ce qui est tout naturel dans la mesure où il s’agit de l’utilisation principale de la solution.

Cependant, Direct Access peut également permettre les accès depuis votre LAN vers les clients connectés depuis l’extérieur, ce qui peut s’avérer extrêmement utile par exemple dans les scénarios d’assistance à distance de vos utilisateurs : il s’agit de la fonction dite de “manage out”

Une problématique peut alors vite émerger : comme vous le savez forcément si vous vous êtes déjà intéressés au sujet, Direct Access ne fonctionne qu’en IPv6 et repose sur des technologies de transition (IPHTTPS, 6to4, teredo… selon les scénarios, le premier étant de loin le plus utilisé) pour que les clients qui passent par internet (donc quasi systématiquement en IPv4) puissent dialoguer votre LAN (lui aussi très souvent en IPv4).
Par contre, la seule possibilité concernant les flux du LAN vers l’extérieur est le déploiement du routage ISATAP, avec tous ses inconvénients.
Par ailleurs, dans le cadre d’un déploiement multisite ou utilisant du load-balancing (très fréquent en entreprise pour des raisons de haute disponibilité), Microsoft ne supporte plus ce type de routage (cf. https://technet.microsoft.com/en-us/library/dn464274(v=ws.11).aspx#bkmk_isa ).

La seule solution restante est donc l’IPv6 natif.

Comme il n’est généralement pas envisageable d’entreprendre une migration complète de votre infrastructure réseau vers IPv6 simplement pour répondre à cette problématique, la solution d’un ou plusieurs serveurs « de rebond » dédiés à l’accès vers les clients externes reste la plus pratique, à défaut d’être la plus élégante. Il peut également tout à fait s’agir directement de vos serveurs SCCM ou de toute autre solutions de prise en main à distance dont vous disposeriez.
Ces serveurs seront configurés avec des adresses IPv6 statiques, leur permettant de communiquer avec votre infrastructure DirectAccess.

I Attribution des IPv6

Sur un des serveur Direct Access, lancez un shell powershell en tant qu’administrateur et exécutez la commande

Le préfixe IPv6 interne de votre déploiement Direct Access est donc ici xxxx:yyyy:967b:1::/64

Nous allons l’utiliser pour définir arbitrairement les IPv6 statiques de vos différents serveurs Direct Access et serveurs Manage Out :

xxxx:yyyy:967b:1::1 (premier serveur Direct Access)
xxxx:yyyy:967b:1::2 (second serveur Direct Access)
[…]
xxxx:yyyy:967b:1::10 (premier serveur de Manage Out)
xxxx:yyyy:967b:1::11 (second serveur de Manage Out)
etc.

Il reste ensuite à les attribuer à chaque serveur, de facon tout à fait classique :

Ouvrez les propriétés de la carte réseau concernée (carte « LAN » ou unique sur vos serveurs DA) puis sélectionnez le protocole IPv6 et cliquez sur Properties :

Indiquez l’IPv6 du serveur, le prefix length 64 et cliquez sur OK.

II Création des routes

Afin que les serveurs de Manage-Out puissent communiquer avec les clients DirectAccess, il est ensuite nécessaire de leur ajouter des routes statiques. En effet, selon le serveur DirectAccess auquel un client est connecté, il obtiendra une adresse IPv6 avec un préfixe distinct et le serveur de ManageOut a besoin de savoir par quel serveur DirectAccess il doit passer pour pouvoir atteindre le client.

Il est possible d’obtenir ce préfixe en exécutant la commande suivante sur n’importe lequel des serveurs DirectAccess :

On obtient ici le préfixe xxxx:yyyy:967b:1000::/59. Le préfixe client a une longueur de 59 bits.

Néanmoins ce dernier est subdivisé en préfixes de 64 bits et chacun d’entre eux est affecté à un serveur DirectAccess. Ainsi, selon l’exemple ci-dessus, les clients connectés au premier serveur DirectAccess obtiendront le préfixe xxxx:yyyy:967b:1000::/64, ceux connectés au second serveur auront le préfixe xxxx:yyyy:967b:1001::/64 etc.

Il est donc nécessaire d’ajouter autant de route que de serveur DirectAccess sur chaque serveur de Management.

Pour ce faire, on exécute les commandes suivantes :

III Ajout du serveur de Management à Direct Access

Le serveur de Manage-Out doit ensuite être ajouté aux serveurs de Management dans Direct Access.

Cela présente par ailleurs un intérêt majeur : il devient ainsi accessible même lorsqu’uniquement le tunnel infrastructure est monté, c’est-à-dire même si l’utilisateur n’a pas ouvert de session sur son PC.
Il devient alors envisageable de gérer à distance le déploiement de paquets, la synchronisation de console antivirus avec une gestion dans le LAN etc.

Pour réaliser cette opération, se rendre dans la console « Remote Access Management » puis dans le menu « DirectAccess and VPN » en ayant pris soin de sélectionner la ferme DirectAccess (« Load Balanced Cluster »). Ensuite, il est nécessaire de cliquer sur le bouton « Edit » de l’étape 3.

Dans l’onglet « Management », faites un clic-droit sur la liste de serveurs et sélectionnez « Add ».

Entrez le FQDN du serveur de manage-out et cliquez sur OK

Cliquez sur Finish.

Enfin, cliquez sur Refresh Management Servers :

Vous devriez maintenant pouvoir accéder à vos clients depuis le LAN, en utilisant leur nom DNS ou leur IPv6 directement.

Attention toutefois, les clients connectés via DirectAccess ont le profil de firewall Windows « public » actif, il peut donc être nécessaire d’ouvrir les ports dont vous aurez besoin pour ce profil !

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.