PI Services

Le blog des collaborateurs de PI Services

Le fichier NetSetup.log

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 !

 

Authentification SSO avec l'ADFS et Apache 2.5 (installé sur un linux)

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.

 

 

 

Active Directory : De l'importance de l'initialisation du SYSVOL lors d'un DCPROMO

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 !

Direct Access : configurer Manage-Out dans un environnement réel

 

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

(Get-DAServer).InternalIPv6Prefix

clip_image001

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 :

clip_image003

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

clip_image004

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 :

(Get-DAServer).ClientIPv6Prefix

clip_image005

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 :

Netsh int ipv6 add route xxxx:yyyy:967b:1000::/64 “Nom de la carte réseau” xxxx:yyyy:967b:1::1

Netsh int ipv6 add route xxxx:yyyy:967b:1001::/64 “Nom de la carte réseau” xxxx:yyyy:967b:1:: 2

clip_image006

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.

clip_image008

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

clip_image009

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

clip_image010

Cliquez sur Finish.

Enfin, cliquez sur Refresh Management Servers :

clip_image012

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 !

SOPHOS – Retour d’expérience sur la migration des agents antivirus depuis une gestion UTM SG vers Sophos Central

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 :

clip_image002

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  :

clip_image004

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

clip_image006

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 :

clip_image007

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.

User and Computer Policies

Server Policies

clip_image009

clip_image011

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é.

clip_image013

Trois Onglet s’offre à vous.

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

clip_image015

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.

clip_image017

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

clip_image019

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

clip_image021

Exchange 2013 – Le WinRM Shell client ne peut pas traiter la requête.

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 :

clip_image002

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 :

clip_image003

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. »

clip_image005

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 :

clip_image007

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
clip_image008

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

Double cliquer sur “https”:
clip_image012

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.

clip_image013

Migration DHCP Failover de Windows Server 2012 R2 à Windows Server 2016

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.

clip_image002

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

clip_image004clip_image006

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

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

clip_image007

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

clip_image008

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

clip_image009

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

clip_image011

Sélectionner le second serveur

clip_image013

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

clip_image015

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

Get-DhcpServerv4Failover

clip_image017

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 :

clip_image019

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

clip_image020

clip_image022

Skype for Business - Retour d'expérience sur la mise en place de la téléphonie 1/3

Contexte

La téléphonie d'entreprise est une pièce importante du SI. La migration de celle-ci est un projet majeur qui doit être bien préparé. Cet article divisé en trois parties est un retour d'expérience sur la migration d'une téléphonie VOIP/TOIP vers une Skype for Business. La première partie traitera des possibilités qu'offre la solution Skype for Business. La seconde partie traitera des différents aspects qui doivent être pris en compte lors de la migration. Enfin la troisième partie traitera des solutions connexes à Skype for Business qui d'augmenter le catalogue de fonctionnalités de la solution.

Les architectures possibles

Le déploiement de la téléphonie à travers Skype for Business est possible de trois façon :

  • Architecture OnPremise
  • Cloud PBX
  • PSTN Calling (à venir)

L'architecture OnPremise implique que l'ensemble de la solution soit hébergé en interne. L'architecture Cloud PBX correspond à une architecture Skype for Business Online (Office 365) et une sortie PSTN en interne. L'architecture PSTN Calling est quant à elle entièrement online. Cette architecture n'est pas encore disponible en France. Les différentes architectures sont définies au lien suivant : https://technet.microsoft.com/en-us/library/mt612869.aspx.

Mon retour d'expérience porte sur un déploiement entièrement OnPremise. L'ensemble de l'architecture déployée l'a été directement au DataCenter du client.

Une infrastructure redondée

La téléphone est un élément important dans une société, son architecture doit donc être hautement disponible. De plus, contrairement à la messagerie la voix est un service en temps réel, l'architecture doit également être réactive.

Ces deux contraintes (haute dispo et performance) compliquent le design de l'architecture.

Architecture physique ou virtuelle ?

Pour Skype for Business, Microsoft supporte une architecture composée de machines physiques ou virtuelles. Cependant Microsoft recommande fortement une architecture physique. Cette recommandation s'appuie sur le besoin de la performance et pour éviter tous problèmes liés à la couche de virtualisation.

Pool de serveurs et multi-sites

Skype for Business intègre nativement un système de pool de serveurs afin de gérer la haute disponibilité du service. Il est ainsi possible d'avoir une architecture redondée sur un seul site.

Bien sur cette haute disponibilité native n'est pas à toute épreuve si l'architecture est présente sur un seul site. Avoir une architecture multi-sites permet de se prémunir des risques tels que les inondations, les feux, les coupures de liens...

Les rôles à déployer

Pour pouvoir déployer la téléphonie, il est indispensable de déployer les rôles Skype suivants :

  • Front-End : serveur principal où les clients se connectent, il est recommandé d'en avoir entre 3 et 12 dans un pool
  • Back-End : serveur SQL qui contient la configuration (une mise en miroir de la base de données est recommandée)
  • Médiation : serveur nécessaire pour la voix, il sert d'interconnexion entre Skype et le monde téléphonique
  • Edge : serveur qui permet la communication avec et depuis l'extérieur
  • Reverse Proxy (rôle non Skype) : serveur qui permet la publication de tous les services web

Il est possible également de déployer les rôles suivants :

  • Directeur : serveur qui permet d'authentifier les utilisateurs avant de transmettre la demande de connexion au Front-End. Il permet de ne pas faire tomber les Front-End en cas d'attaque (type DDOS)
  • Persistent Chat : serveur de conversations permanentes, il permet d'avoir des salles de conversations multi-utilisateurs 
  • Watcher Node : serveur qui exécute des transactions synthétiques afin d'avoir plus de rapport dans SCOM  
  • Office Web Apps (rôle non Skype) : serveur qui permet de partager des PowerPoint dans Skype

Enfin pour que la téléphonie fonctionne il est nécessaire d'avoir une passerelle PSTN.

Ce qu'il faut retenir

Il est possible de faire différentes architectures de Skype for Business. Celle-ci doit être faite en fonction des besoins. 

Voilà qui conclut la première partie de mon retour d'expérience. A bientôt pour la suite !

Skype for Business - Retour d'expérience sur la mise en place de la téléphonie 2/3

Contexte

Cet article divisé en trois parties est un retour d'expérience sur la migration d'une téléphonie VOIP/TOIP vers une Skype for Business. Voici la seconde partie qui traitera des différents aspects qui doivent être pris en compte lors de la migration.

Préparer la migration

Choix des terminaux

Le choix des nouveaux terminaux est un élément important de la migration. De nombreux modèles de téléphones et de casques sont compatibles avec Skype for Business. Voici les principaux facteurs de décisions :

  • Qualité du son (entrant et sortant)
  • Qualité générale du produit : est-il solide ?
  • Ergonomie / prise en main / confort
  • Support : quelles parties du téléphone / casque peut-on changer (câble, coussinets, mousse...) ? peut-on changer facilement ces pièces ?
  • Prix
  • Possibilité d'approvisionnement du fournisseur

Ce choix doit être fait à l'aide d'utilisateurs et il est également conseillé de prévoir différentes gammes de produits en fonction des utilisateurs (utilisateur standard, VIP...).

Ne rien oublier !

Le monde de la téléphonie est vaste et ne se limite pas uniquement aux téléphones des utilisateurs.

De nombreuses autres solutions utilisent les lignes téléphoniques classiques tels que :

  • Les fax ou les serveurs de fax
  • Les timbreuses
  • Les centres d'appel (Service Desk par exemple) et les groupements d'appels (cellule voyage par exemple)
  • Les accueils
  • Les relations entre patrons et secrétaires

Exceptions

Parmi les nombreuses solutions qui utilisent les lignes téléphoniques, certaines doivent utiliser des lignes classiques et ne doivent pas être migrées :

  • Les ascenseurs
  • Les alarmes

Maquette

Comme dans de nombreux projets, monter une architecture de recette est fortement recommandé. Celle-ci doit être le plus ressemblant possible à l'architecture de production. Cette maquette permettra d'effectuer différents tests : ajout/suppression d'un rôle, modification d'une option, tests de failover...

Conclusion

La migration de la téléphonie doit être bien préparée. Un grand nombre de décisions sont à prendre avant de lancer le projet. Certains choix prennent plusieurs semaines avant d'être validé (choix des terminaux par exemple). Ce temps d'analyse et de décisions est impératif pour éviter les problèmes durant la phase de migration.

Voilà qui conclut la seconde partie de mon retour d'expérience. A bientôt pour la suite !