Analyse de performances de serveurs Windows

 

superfmonLorsque l’on met en production ou maintient un système on ne pense pas toujours à faire d’évaluation de performances des serveurs, parce qu'on a pas forcément les outils pour le faire et le temps d’analyser les résultats obtenus.

Lorsque j’étais Premier Field Engineer chez Microsoft, j’utilisais souvent avec mes clients un outil développé par des collègues et qui s’appelle PAL (Performance Analysis of Logs). Le but de PAL est simple : offrir un moteur d’analyse et de génération de rapports pour les performances des serveurs. Cerise sur le gâteau, il vient avec la possibilité de générer les modèles de capture d’informations pour Performance Monitor (perfmon) de Windows, afin de ne collecter que l’essentiel sur une machine. 

Dans mon scénario, je chercher à vérifier si performances de mes contrôleurs de domaines sont bonnes et si ce n’est pas le cas, à en déterminer la cause (disques lents, mémoire saturée, réseau engorgé, processus qui consomment toutes mes ressources, etc.)

 

Récupération de l’outil PAL

L’outil est disponible sur http://pal.codeplex.com/ et il est mis à jour régulièrement par Clint Huffman. Cette page contient l’outil qui a quelques prérequis parmi lesquels PowerShell qui sera utilisé pour analyser les données et Microsoft Chart Controls for Microsoft .NET Framework 3.5 qui sera utilisé pour générer les graphiques du rapport.

On récupère donc les binaires de l’outils et on l’installe sur un poste client.

 

Création des modèles

Sur le poste client toujours, nous allons dans un premier temps générer un modèle pour Perfmon qui permettra de prendre une trace de performance selon le rôle de serveur que je souhaite analyser.

Voici l’écran d’accueil de PAL, pour le moment allons dans la section Threshold File

PAL1

Lorsque l’on ouvre le menu déroule, on voit qu’il y a pas mal de modèles de capture de compteurs de performances pour différents scenarios serveurs.

PAL2

Sélectionnons le scénario Microsoft Active Directory et cliquons sur Export to Perfmon template file…

PAL3

On sauvegarde le fichier XML et on le copie sur le serveur où l’on souhaite effectuer la capture.

PAL4

Dans ce modèle, il y a tout simplement la liste des compteurs perfmon que l’on a besoin pour un scénario donné, vous pouvez rajouter vos propres compteurs si le coeur vous en dit. 

 

Import du modèle de compteurs de performances sur le serveur

Un fois le fichier de modèle perfmon généré, allons l’importer sur le serveur à analyser.

Lançons perfmon.exe et allons dans la section User-Defined

perfmon2

Click droit et sélectionnons New, Data Collector Set

perfmon3

Spécifions un nom explicite pour retrouver facilement la trace

perfmon4

Sélectionnons Browse pour importer le modèle que nous avons créé sur le poste de travail et copié sur le serveur.

perfmon5

Un œil fin aura remarqué que j’aurai pu utiliser également un scénario “Active Directory Diagnostics” déjà inclut dans l’OS. Mais celui ci fait un peu plus que prendre des traces perfmon (en fait, il prend un dump de la configuration de la base de registre et démarre une trace ETL, ce dont je n’ai pas besoin et qui a aussi un impact de performances).

Je confirme donc l’import du fichier XML.

perfmon6

J’utilise le modèle “PAL” défini dans le fichier XML.

perfmon7

Stockage à l’emplacement par défaut.

perfmon8

Utilisation du compte par défaut

perfmon9

La collecte est prête et stoppée.

perfmon10

Lorsque nous cliquons deux fois, nous pouvons vérifier la liste des compteurs inclus dans ce modèle ainsi que l’intervalle de capture.

perfmon11

 

Capture de compteurs de performance

Nous sommes prêts à prendre notre première capture. Nous vérifions dans un premier temps les propriétés définies dans la capture :

capture1

Une description du scénario.

capture2

Spécifions une limite de taille pour le fichier ainsi qu’une durée dans le temps. Pour une prise de compteurs perfmon, 500 MO, c’est plutôt large, on utilisera des valeurs plus petites lorsque l’espace disque est limité.

capture3

Je peux lancer ma première capture.

capture4

Je vois bien que la capture commence dans le repertoire attendu, c’est là que j’irai chercher le fichier BLG pour analyse.

capture5

Nous sommes partis pour une heure de capture, allons prendre un café et faire connaissance avec les nouvelles stagiaires de la compta.  

config

De retour sur le serveur, il nous faut vérifier quelle version d’OS on exécute et de combien de RAM est-il doté. Ceci sera utile quand nous lancerons l’analyse des compteurs de performance.

 

Analyse automatisée

On récupère le fichier de capture dans le répertoire que l’on a localisé (c:\perflogs)

BLG1

L’étape suivante consiste a analyser le fichier de log généré par perfmon. Le premier contact lorsqu’on double clique sur le fichier n’est pas forcément très engageant :

BLG2

On a mieux pour analyser tout cela : retournons dans PAL. Pour cela, copions le fichier BLG sur notre machine cliente et lançons à nouveau l’outil.

PAL1

Déroulons l’assistant, la première étape consiste à lui fournir le fichier de capture que nous avons pris (le fichier .BLG)

APAL1

Nous validons le modèle Active Directory, cette fois pour l’analyse.

APAL2

Sélectionnons l’OS qui est utilisé :

APAL3

Sélectionnons la quantité de RAM installé sur le serveur :

APAL4

Par défaut, laissons le choisir sa fréquence d’analyse :

APAL5

Le rapport sera généré dans le répertoire PAL Reports de l’utilisateur actif :

APAL6

Voici la commande PowerShell qui est lancée automatiquement à la fin de l’assistant :

APAL7

On choisi de l’exécuter immédiatement, mais on peut l’ajouter en file d’attente :

APAL8

Exécution de l’analyse et création du rapport qui prend quelques minutes :

APAL9

Une fois le fichier de rapport généré, à vous de partir à l’aventure de son exploration

APAL10

Et Voilà

Je commence toujours par la vue chronologique au début du fichier qui permet de voir ce qui s’est passé dans l’intervalle :

image

On voit dans mon exemple un certain nombre de points rouges et jaunes plus ou moins critiques.

Ici je vois que mon LDAP Bind Time est un peu lent, avec une moyenne de 16 ms. Ceci veut dire qu’un utilisateur qui se connecte au serveur LDAP sur ce serveur a un délai de réponse moyen de 16 ms (ceci n’inclus pas la latence réseau, et donc tout cumulé, ceci peut être considéré comme un peu lent).

Si je corrobore avec d’autres éléments, on voit que le disque sur lequel est stocké AD est également un peu lent avec en moyenne 18 ms pour les écritures et 9 ms pour les lectures : on a donc un coupable tout désigné pour les performances de mon AD.

Ceci n’a pas l’air dramatique, mais c’est vraiment un serveur à surveiller, à fortiori on observe des pics importants :

APAL12

Dans les détails du rapport, je peux observer les compteurs plus précisément :

NTDS_LDAP_Bind_Time0

PhysicalDisk_Avg_Disk_sec_Read0

PhysicalDisk_Avg_Disk_sec_Write0

Ce qui est très sympa également avec PAL, c’est que le rapport généré vous décrit les compteurs utilisés et les valeurs qui sont importantes pour ces compteurs, bref une vraie mine d’or !

Voilà pour cette petite introduction à PAL, j’espère vous avoir initié à des plaisirs insoupçonnés autour de l’analyse de performance de serveurs. Il existe bien d’autres outils, que l’on détaillera dans d’autres articles !

Si vous souhaitez plus d’informations sur le dépannage d’Active Directory et des performances, vous pouvez aussi retrouver un cours dédié sur la Microsoft Virtual Academy : Active Directory – Dépannage et mécanismes internes http://www.microsoftvirtualacademy.com/training-courses/active-directory-depannage-et-mecanismes-internes-fr

Encore plus de cours sur la Microsoft Virtual Academy : https://aka.ms/MVAFR

Egalement à suivre, le blog de Clint Huffman http://blogs.technet.com/b/clinth/ 

Arnaud Lheureux

Authentification multi facteurs avec Azure Multi-Factor Authentication – partie 6 : intégration ADFS

 

Dans un article précédent, nous discutions de la solution Azure Multi-Factor Authentication pour mettre en place une authentification d’entreprise multi facteurs.

Pour rappel, cet article fait partie d’une série :

  1. Introduction à Windows Azure Multi-Factor Authentication
  2. Installation et paramétrage du serveur Windows Azure Multi Factor Authentication
  3. Installation et paramétrage de Remote Desktop Gateway
  4. Installation et paramétrage du portail utilisateur
  5. Installation et paramétrage pour l’application mobile
  6. Installation et paramétrage pour ADFS (vous êtes ici)

L’objectif de ce dernier article et d’ajouter MFA à une infrastructure ADFS déjà en place afin d’enrichir l’authentification fédérée avec l’utilisation du téléphone.

Il sera nécessaire d’installer les binaires MFA sur le ou les serveurs ADFS (si on a une ferme de serveur ADFS). On pourra se référer à l’article 2 de cette série pour le premier serveur, et à l’article 3 pour un serveur additionnel.

1. Installation de l’adaptateur ADFS

Une fois les binaires du serveur MFA installés sur le serveur ADFS, on va dans la console MFA, vérifie qu’il est bien partenaire des autres serveurs MFA de l’organisation si nécessaire et on sélectionne Install ADFS Adapter dans la partie ADFS :

adfs01

adfs02

adfs03

Une fois le setup passé, on va activer les méthodes d’authentification que l’on souhaite pour les utilisateurs d’ADFS et si on leur autorise l’enrôlement :

adfs05

Il nous faut maintenant paramétrer la partie ADFS.

2. Enregistrement de l’adaptateur MFA pour ADFS

La première étape consiste à enregistrer le serveur MFA comme fournisseur d’authentification pour ADFS. On va pour cela lancer le script PowerShell présent dans \Program Files\Multi-Factor Authentication Server et qui s’appelle Register-MultiFactorAuthenticationAdfsAdapter.ps1

pshell1

On doit ensuite redémarrer le service ADFS, j’utilise Restart-Service adfssrv –force pour redémarrer automatiquement aussi le service drs, qui en dépend.

pshell2

Une fois cela validé, je vais l’activer comme méthode d’authentification disponible sur mon serveur.

Je vais pour cela dans ma console de gestion ADFS et choisi la section Authentication Policies, click droit sur Edit Global Multi-Factor Authentication.

adfsman01

je choisis d’ajouter la méthode AzureMFA :

adfsman02

Nous allons maintenant activer cette fonctionnalité pour une application et valider l’expérience utilisateur.

 

3. Activation pour une application

Pour activer cette fonctionnalité, je vais choisir mon application de base claimapp, et je vais demander une authentification MFA pour un utilisateur en particulier.

Je reste dans ma console ADFS et descend dans l’arborescence pour choisir Per Relying party trust. Je clique sur ma partie claimapp et selectionne Add dans la partie Multi-factor :

authpolicy1

Ici, je fais le test sur un utilisateur, je prendrais évidemment un groupe dans la vraie vie.

authpolicy2

Il est intéressant de remarquer, que l’on peut exiger du multifacteur SI un utilisateur n’est PAS sur un périphérique enregistré dans l’organisation (via workplace join). On peut alors combiner toutes sortes d’options pour couvrir les différents scenarios BYOD (Bring Your Own Device) que l’entreprise souhaite.

authpolicy3

On valide et teste l’application via mon portail ADFS.

4. Expérience utilisateur

J’accède à mon application claimapp, qui fait l’authentification via ADFS (cette application est publié via WAP Web Application Proxy, et je n’ai rien eu à changer sur ce serveur)

testuser1

Une fois que cet utilisateur a validé son mot de passe, on demande une authentification additionnelle, on a la possibilité de choisir si l’on effectue cela par certificat client ou pas Azure Multi Factor Authentication.

testuser2

On clique sur MFA et on l’écran suivant qui prévient de la notification ou de l’appel téléphonique :

testuser3

Une fois validé, j’ai bien accès à mon application claimapp !

testuser5

 

Voila, c’est la fin de cette série sur Azure Multi Factor Authentication, j’espère qu’elle vous aura intéressé !

N’hésitez pas à m’envoyer vos remarques par ce blog ou sur mon Twitter @arnaudlheureux 

Si vous souhaitez découvrir en 4 heures nos technologies telles que Windows Server 2012 R2, Windows 8.1 en entreprise, le Cloud Privé ou Hybride, vous pouvez vous inscrire gratuitement à un de nos IT Camps :

https://aka.ms/itCampFr

Pour finir quelques références additionnelles :

Technical Scenarios for Windows Azure Multi-Factor Authentication – http://technet.microsoft.com/en-us/library/dn394279.aspx

Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications – http://technet.microsoft.com/en-us/library/dn280946.aspx

Pour tester Windows Azure Multi-Factor Authentication, vous pouvez évaluer Windows Azure par ici : https://aka.ms/Azure0Euro

Pour tester Windows Server 2012 R2, vous pouvez télécharger gratuitement la version d’évaluation disponible sous la forme :

Arnaud – les bons tuyaux

Authentification multi facteurs avec Azure Multi-Factor Authentication – partie 5 : application mobile

 

Dans un article précédent, nous discutions de la solution Azure Multi-Factor Authentication pour mettre en place une authentification d’entreprise multi facteurs.

Pour rappel, cet article fait partie d’une série :

  1. Introduction à Windows Azure Multi-Factor Authentication
  2. Installation et paramétrage du serveur Windows Azure Multi Factor Authentication
  3. Installation et paramétrage de Remote Desktop Gateway
  4. Installation et paramétrage du portail utilisateur
  5. Installation et paramétrage pour l’application mobile (vous êtes ici)
  6. Installation et paramétrage pour ADFS

Parce que l’on n’est pas toujours disponible pour un appel téléphonique, mettons en œuvre la configuration pour faire fonctionner l’application mobile Multifactor Authentication.

testconnect2

Pour rappel, avec Azure Multi Factor Authentication, on peut utiliser une application disponible sur les plateformes suivantes :

 google_pla_store_android11 itunes_en_thumb3

Lien

Lien

Lien

L’objectif de cet article est de décrire comment mettre en œuvre dans un environnement de test la partie serveur permettant l’utilisation de ces applications.

Pour cela, je vais utiliser un serveur web et y installer les web services et SDK, je publierai ensuite ce serveur web en utilisant le reverse proxy de Windows Server 2012 R2 : Web Application Proxy. 

Les prérequis du serveur Web sont décrits ici : http://technet.microsoft.com/en-us/library/dn394277.aspx 

 

1. Installation du Web Services SDK

Dans un premier temps nous devons installer sur le serveur MFA les composants qui permettront l’appel des API depuis le frontal Web.

setupwebservices

Comme pour le cas du portail utilisateurs, un assistant permet de s’assurer que les prérequis sont remplis. Il s’agit sans doute du même développeur taquin qui nous propose de lire la documentation ; passons rapidement cette blague.

setup1

Les prérequis étant atteints, on peut lancer le setup.

setup3

Le choix du Virtual Directory importe assez peu, puisque ce seront des appels uniquement techniques qui seront faits à cette URL, l’utilisateur n’aura jamais à saisir cette URL.

setup4

Le setup se déroule sans accroc…

setup6

 

2. Installation de l’application mobile

L’application mobile a pour vocation d’être installé sur un serveur Web diffèrent du serveur MFA, dans mon cas pour ne pas multiplier les efforts, je l’installe sur le serveur MFA, cela me fera l’économie d’une machine.

Les binaires d’installation de l’application mobile sont situés dans l’arborescence des exécutables du serveur MFA. Soit dans mon cas, il faut aller chercher cela dans : C:\Program Files\Multi-Factor Authentication Server et récupérons MultiFactorAuthenticationMobileAppWebServiceSetup64.msi

setupapp1

setupapp2

Notons que le répertoire virtuel utilisé par défaut est MultiFactorAuthMobileAppWebService.

Nous devons maintenant paramétrer cette application web.

 

3. Paramétrage de l’application mobile

Le paramétrage de l’application consiste à modifier le fichier web.config pour spécifier la chaine de connexion au serveur hébergeant le SDK , ainsi que les credentials nécessaires pour s’authentifier auprès des web services.

Dans le répertoire ou l’application Web a été installée, on va chercher le fichier Web.config et on localise particulièrement la section : WEB_SERVICE_SDK_AUTHENTICATION_USERNAME et WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD

On va alors remplir ces rubriques avec les nom d’utilisateur et mot de passe du compte utilisé:

    <appSettings>
        <add key="WEB_SERVICE_SDK_AUTHENTICATION_USERNAME" value="mondomain\monuser"/>
        <add key="WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD" value="ahmerdeUnmotdePasseEnClair"/>
        <add key="WEB_SERVICE_SDK_AUTHENTICATION_CLIENT_CERTIFICATE_FILE_PATH" value=""/>
        <add key="WEB_SERVICE_SDK_AUTHENTICATION_CLIENT_CERTIFICATE_FILE_PASSWORD" value=""/>
    </appSettings>

Chaine de connexion

Protection des credentials

Afin de régler le sujet toute de suite, le Technical Writer qui a écrit la doc de la configuration officielle sur Technet devait sans doute être au fond de la salle adossé au radiateur lors des cours de sécurité web, car on vient de stocker le mot de passe du compte en clair dans le fichier web.config.

Soyons clair, si quelqu’un fait cela chez vous, la réponse la plus appropriée : humiliation en place publique, épandage des tripes sur la place du marché, chacun jugera selon les coutumes les plus en usage dans sa région.

Sauvegardez le fichier avec les credentials en texte clair, et procédons à un peu de magie.

Localisez le répertoire contenant l’outil aspnet_regiis.exe. Sur mon Windows Server 2012 R2, il s’agit de c:\windows\Microsoft.NET\Framework64\v4.0.30319

Cela va modifier le fichier web.config et on aura alors chiffré les credentials de la section <appsettings>

.\aspnet_regiis -pe "appSettings" -app "/MultiFactorAuthMobileAppWebService" -site "1"

On a alors :

Microsoft (R) ASP.NET RegIIS version 4.0.30319.33440
Administration utility to install and uninstall ASP.NET on the local machine.
Copyright (C) Microsoft Corporation.  All rights reserved.
Encrypting configuration section…
Succeeded!

Quand on va vérifier le fichier web.config, on a maintenant :

<appSettings configProtectionProvider="RsaProtectedConfigurationProvider">
        <EncryptedData Type="
http://www.w3.org/2001/04/xmlenc#Element"
            xmlns="http://www.w3.org/2001/04/xmlenc#">
            <EncryptionMethod Algorithm="
http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
            <KeyInfo xmlns="
http://www.w3.org/2000/09/xmldsig#">
                <EncryptedKey xmlns="
http://www.w3.org/2001/04/xmlenc#">
                    <EncryptionMethod Algorithm="
http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
                    <KeyInfo xmlns="
http://www.w3.org/2000/09/xmldsig#">
                        <KeyName>Rsa Key</KeyName>
                    </KeyInfo>
                    <CipherData>
                        <CipherValue>merdiercrypté</CipherValue>
                    </CipherData>
                </EncryptedKey>
            </KeyInfo>
            <CipherData>
                <CipherValue>merdiercrypté</CipherValue>
            </CipherData>
        </EncryptedData>
    </appSettings>

Une autre alternative  consiste en l’utilisation d’un certificat pour cette authentification mais nous ne la décrirons pas ici !

 

Connection au backend MFA :

On spécifie ensuite la chaine de connexion au serveur MFA en backend, pensez URL complète et valide car on utilise SSL, à moins d’ajouter la valeur : <add key="SSL_REQUIRED" value="false"/> dans la chaine de connexion.

On spécifie alors :

<setting name="pfpaws_pfwssdk_PfWsSdk" serializeAs="String">
<value>https://URLDUBACKEND/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx</value>
</setting>

Une fois cela réglé, on publie le site web.

 

4. Publication du site web 

Dans mon environnement, j’utilise Web Application Proxy de Windows Server 2012 R2, j’utilise une publication en mode pass-through, l’authentification sera faite par l’application. L’URL que je publie est /MultiFactorAuthMobileAppWebService car j’ai déjà publié le portail utilisateur précédemment (/MultiFactorAuth).

 

5. Test de l’application mobile

L’utilisateur se loggue sur le portail et sélectionne l’option activer l’application.

appli-enroll1

On a alors un tag qui représente l’URL du Webservice, ce qui est pratique pour éviter de se taper l’URL sur le clavier du téléphone :

appli-enroll2

Je peux alors prendre mon téléphone et lancer l’application MultiFactor Auth :

Ajout de mon compte :

app1

Utilisation du bouton de scan de tag :

app2

Validation par la possession de la section relative à notre environnement :

app3

Et voila!

Il ne restera plus qu’a spécifier que l’utilisateur peut utiliser l’application dans l’ensemble des méthodes d’authentification supportées :

applivalid

L’utilisateur sera alors notifié qu’une authentification demande sa confirmation :

app4

Il valide avec son code PIN

app5

Tada!

La suite au prochain épisode !

Pour continuer, l’aventure, quelques lectures et références :

Deploying the Windows Azure Multi-Factor Authentication Server Mobile App Web Service – http://technet.microsoft.com/en-us/library/dn394277.aspx 

Encrypting Web.Config Values in ASP.NET 2.0 – http://weblogs.asp.net/scottgu/archive/2006/01/09/434893.aspx

How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI : http://msdn.microsoft.com/en-us/library/ff647398.aspx

Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication – http://msdn.microsoft.com/en-us/library/ff649224.aspx

Technical Scenarios for Windows Azure Multi-Factor Authentication – http://technet.microsoft.com/en-us/library/dn394279.aspx

Windows Azure Multi-Factor Authentication Release Notes – http://technet.microsoft.com/en-us/library/dn465794.aspx

Quelques exemples de mise en œuvre de la technologie chez Fredrikson & Byron, http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?casestudyid=710000003252

Pour tester Windows Azure Multi-Factor Authentication, vous pouvez évaluer Azure par ici :

https://aka.ms/Azure0Euro

Pour tester Windows Server 2012 R2, vous pouvez télécharger gratuitement la version d’évaluation disponible sous la forme :

Si vous souhaitez découvrir en 4 heures nos technologies telles que Windows Server 2012 R2, Windows 8.1 en entreprise, le Cloud Privé ou Hybride, vous pouvez vous inscrire gratuitement à un de nos IT Camps :

https://aka.ms/itCampFr

Arnaud – les bons tuyaux

Authentification multi facteurs avec Azure Multi-Factor Authentication – partie 4 : portail utilisateur

Dans un article précédent, nous discutions de la solution Azure Multi-Factor Authentication pour mettre en place une authentification d’entreprise multi facteurs. Ajoutons maintenant une fonctionnalité à cette solution : le portail utilisateur.

Pour rappel, cet article fait partie d’une série :

  1. Introduction à Windows Azure Multi-Factor Authentication
  2. Installation et paramétrage du serveur Windows Azure Multi Factor Authentication
  3. Installation et paramétrage de Remote Desktop Gateway
  4. Installation et paramétrage du portail utilisateur (vous êtes ici)
  5. Installation et paramétrage pour l’application mobile
  6. Installation et paramétrage pour ADFS

Nous avons vu dans l’article 2 comment mettre en place manuellement pour quelques utilisateurs la fonctionnalité d’authentification multi facteurs. En déploiement d’entreprise, afin d’éviter un surplus de travail pour les administrateurs, nous allons automatiser au maximum les fonctions de provisionning et fournir un portail pour que les utilisateurs puissent effectuer les opérations de base par eux-même.

Il nous faut alors un serveur Web avec IIS et les composants de rétrocompatibilité de la metabase pour IIS6, les composants .NET 2.0.

L’installation du portail peut se faire sur un simple serveur Web, sur lequel on installe les composants, et on spécifie dans le fichier web.config un chemin de connexion, nom d’utilisateur et mot de passe. Cela ne me plait pas beaucoup donc pour éviter cela, installons un nouveau serveur MFA dans le groupe que nous avons crée précédemment, et installons ensuite les composants Web sur ce serveur.

 

1. Installation du serveur MFA

Nous suivons les étapes telles que décrites dans l’article 2 de cette série

A l’étape 2., nous spécifions que le serveur rejoint un groupe, le même groupe de spécifié précédemment, en l’occurrence MyMFA :

portal0

Nous activons la réplication pour partager les informations avec le serveur spécifié précédemment.

portal1

Nous utilisons AD ainsi que les certificats pour authentifier nos serveurs MFA.

portal2

Ajoutons le compte machine aux administrateurs PhoneFactor, c’est obligatoire.

portal3

Validons la création des certificats pour l’authentification mutuelle entre serveurs MFA.

portal4

Et le traditionnel redémarrage.

portal5

Les composants serveurs MFA sont bien installés, une fois le serveur redémarré, vérifions la console serveur MFA pour y confirmer la connexions de multiples serveurs :

portal6

On voit qu’on a bien les deux serveurs listés, qu’ils sont en ligne et que le serveur initial est bien le maitre de la configuration. A noter que cette notion de serveur maitre n’empêche en rien la configuration depuis le serveur “secondaire” que nous venons d’installer.

Passons donc maintenant à l’installation des binaires du portail.

 

2. Installation du portail

Nous vérifions que le Framework .net 2.0 est bien installé :

dnf2

Si ce n’est pas le cas, il est toujours temps de l’installer. Notons qu’il faudra spécifier un chemin alternatif (média d’installation de Windows) pour les binaires qui ne se situent pas par défaut dans les fichiers de Windows. Cela nous rappellera le (bon?) temps où il fallait insérer le CD à chaque fois qu’on ajoutait des composants à Windows.

Nous pouvons ensuite procéder à l’installation du portail :

portal7

La première étape de l’assistant déploiement nous propose de lire la documentation du produit, il s’agit évidemment d’un développeur taquin qui sait que personne ne la lit.

portal8

Le portail a aussi besoin des composants de rétrocompatibilité avec la meta base de IIS6, ajoutons les sous peine de ne pouvoir continuer.

portal9

L’assistant nous propose de créer le compte pour l’application IIS et de l’ajouter aux groupes de sécurité requis.

portal10

Une fois l’opération effectuée, on peut lancer véritablement l’installation des binaires.

portal11

Choix du répertoire virtuel et du site :

portal12

portal13

portal14

Une fois l’installation terminée, il nous faut maintenant configurer le portail !

 

3. Configuration du portail

Par défaut, l’application est crée dans http://<serveur>/MultifactorAuth. Spécifions cette URL dans notre configuration serveur et ajoutons quelques options pour que les utilisateurs puissent commencer à exploiter le serveur :

portal15

Je vais autoriser l’enrôlement des utilisateurs et leur permettre de choisir les méthodes d’authentification suivantes :

  • appel téléphonique
  • SMS
  • application mobile

portal16

Je vais ajouter mon compte “Arnaud” comme administrateur de la plateforme afin d’avoir un portail avec des rôles spécifiques pour ce compte :

portal17

Sélection du compte dans l’AD :

portal18

Choix des rôles qui seront permis pour ce compte, il conviendra de déterminer pour chaque organisation les délégations de rôles appropriées.

portal19

Enfin, la section question de sécurité vous permet d’éditer les questions qui seront posées à vos utilisateurs à l’enrôlement et qui leur permettront de gérer leur authentification multi facteur.

portal20

Le portail est maintenant opérationnel, testons-le avec le compte administrateur ainsi qu’un compte utilisateur régulier.

 

4. Tests du portail

Utilisation de l’URL spécifiée précédemment :  http://<serveur>/MultifactorAuth 

En tant qu’administrateur, je devrais avoir un portail bien particulier :

web1

Apres connexion avec utilisateur/mot de passe, je reçois un appel et confirme l’authentification, j’ai donc le prompt pour les questions de sécurité :

web2

Une fois cela effectué, j’ai accès à mon portail administrateur :

web3

 

En tant qu’utilisateur normal avec juste un numéro de téléphone provisionné :

webusr1

Après confirmation, j’ai un écran d’accueil qui explique le fonctionnement de la solution et me laisse effectuer des opérations telles que spécifiées par mon administrateur :

webusr2

Par exemple, modification de la langue pour l’appel, l’application et le SMS !

webusr3

Lorsque l’utilisateur n’arrive pas à confirmer avec le téléphone, il aura alors la méthode de fallback en répondant aux questions de sécurité auxquelles il a répondu lors de l’enrôlement.

webusr4

Et voilà ! Un beau portail pour que nos utilisateurs et administrateurs soient heureux !

 

Dans un prochaine épisode, nous mettrons en place l’infrastructure nécessaire pour utiliser l’application d’authentification sur le téléphone mobile, si l’on souhaite avoir une expérience utilisateur “améliorée” par rapport au simple appel ou SMS.

 

Quelques lectures  :

Installing the Windows Azure Multi-Factor Authentication Users Portal – http://technet.microsoft.com/en-us/library/dn394290.aspx 

User Enrollment and Self-Management – http://technet.microsoft.com/en-us/library/dn394292.aspx 

Technical Scenarios for Windows Azure Multi-Factor Authentication – http://technet.microsoft.com/en-us/library/dn394279.aspx

Windows Azure Multi-Factor Authentication Release Notes – http://technet.microsoft.com/en-us/library/dn465794.aspx

Quelques exemples de mise en œuvre de la technologie chez Fredrikson & Byron, http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?casestudyid=710000003252

Pour tester Windows Azure Multi-Factor Authentication, vous pouvez évaluer Azure par ici :

https://aka.ms/Azure0Euro

Pour tester Windows Server 2012 R2, vous pouvez télécharger gratuitement la version d’évaluation disponible sous la forme :

Si vous souhaitez découvrir en 4 heures nos technologies telles que Windows Server 2012 R2, Windows 8.1 en entreprise, le Cloud Privé ou Hybride, vous pouvez vous inscrire gratuitement à un de nos IT Camps :

https://aka.ms/itCampFr

Arnaud – les bons tuyaux

Authentification multi facteurs avec Azure Multi-Factor Authentication – partie 3 : Windows Server 2012 R2 – Remote Desktop Gateway

Continuons notre série d’articles décrivant la mise en place de la solution Azure Multi-Factor Authentication pour déployer une authentification d’entreprise multi facteur. 

Pour rappel, cet article fait partie d’une série :

  1. Introduction à Windows Azure Multi-Factor Authentication
  2. Installation et paramétrage du serveur Windows Azure Multi Factor Authentication
  3. Installation et paramétrage de Remote Desktop Gateway (vous êtes ici)
  4. Installation et paramétrage du portail utilisateur
  5. Installation et paramétrage pour l’application mobile
  6. Installation et paramétrage pour ADFS

Nous avons précédemment déployé un serveur d’authentification WAMFA (acronyme pas forcément officiel). Intéressons nous maintenant à la protection d’une connexion à un serveur Remote Desktop Session Host via la passerelle Remote Desktop Gateway.

Mise en œuvre de l’authentification multi facteur pour Remote Desktop Gateway

L’environnement d’évaluation que nous allons mettre en place est le suivant :

  • DUB-SRV1 : serveur Remote Desktop Session Host qui héberge la session Remote Desktop que nous souhaitons protéger
  • DUB-SRV2 : serveur Remote Desktop Gateway : permet d’accéder à un serveur Remote Desktop Session Host ou d’administration à distance, en encapsulant le protocole RDP dans HTTPS. Ce composant effectue également le contrôle d’accès et l’authentification des utilisateurs (en contactant l’AD)
  • DUB-SRV4 : serveur Azure Multi Factor Authentification : autorise l’accès à l’application. Celui-ci a été configuré de manière basique dans l’article 2 de cette série.

topolab_thumb4_thumb

Notons quelques points importants de cette topologie :  

  • Le service RDG (situé sur DUB-SRV2) redirige ses demandes d’authentification au serveur MFA (DUB-SRV4).
  • Une fois son travail effectué le serveur MFA renvoi les paquets au serveur NPS (installé par défaut) sur DUB-SRV2
  • le serveur MFA doit être configuré en tant que proxy pour l’authentification. Cela veut dire que pour les déploiements d’entreprise il faudra prévoir une ferme de serveurs MFA en frontal de la ferme RADIUS (NPS) d’entreprise.
  • le protocole utilisé pour échanger des messages entre le serveur NPS et le serveur MFA est RADIUS.

Le fonctionnement de la boucle d’authentification est le suivant :

  1. Le composant Remote Desktop Gateway (RDG) reçoit une demande d’authentification d’un utilisateur.
  2. Le composant RDG transmet la requête d’authentification au serveur MFA (via son composant NPS, et une règle de forwarding de la demande d’authentification).
  3. Le serveur MFA procède à l’authentification (accès autorisé ou pas selon la réponse à la demande d’authentification téléphonique)
  4. Le serveur MFA envoi la réponse (oui/non) au serveur NPS (ici situé également sur la machine RDG)
  5. Le serveur NPS évalue les critère de la demande envoyé par le serveur MFA et envoi une autorisation de connexion selon les règles configurées localement.
  6. L’utilisateur est connecté à sa session Remote Desktop Connection Session Host sur DUB-SRV1.            

1. Paramétrage de Remote Desktop Gateway pour l’authentification multi-facteur

L’intégration avec Remote Desktop Gateway s’effectue en utilisant le serveur RADIUS embarqué par le serveur MFA en mode proxy, il nous faut pour cela, nous connecter sur DUB-SRV2 et spécifier dans l’interface de gestion Remote Desktop Gateway que nous utiliserons un serveur centralisé :

rdg1

Nous spécifions alors l’adresses IP du serveur MFA, ici l’adresse IP de DUB-SRV4, soit 10.0.1.4 et spécifions également une clé partagée, notons la car nous devrons spécifier la même à l’étape suivante : configuration du serveur MFA pour RADIUS.

rdg2

2. Configuration du serveur RADIUS de MFA

Pour cette étape, connectons nous sur DUB-SRV4 et configurons le rôle serveur RADIUS, cochons le cache “Enable RADIUS Authentication”

radius1

Ajoutons notre serveur DUB-SRV2 en tant que client RADIUS en spécifiant son adresse IP ainsi que la clé partagée que nous avons définis à l’étape précédente :

radius2

radius2b

Cliquons ensuite sur l’onglet Target et spécifions également DUB-SRV2 en tant que serveur RADIUS vers lequel nous renverrons les paquets une fois l’authentification MFA effectuée.

radius3

Cela peut sembler bizarre de spécifier le serveur DUB-SRV2 à la fois comme client ET serveur RADIUS, mais cela n’est nécessaire dans notre environnement que parce que nous utilisons le serveur DUB-SRV2 pour effectuer l’authentification NPS une fois le travail fait par MFA. 

Dans un déploiement d’entreprise, on spécifiera dans la partie serveur RADIUS (target) une ferme de serveurs RADIUS centralisés, qui fera l’authentification sur le domaine.

3. Configuration du serveur NPS

La configuration du serveur NPS sur le serveur DUB-SRV1 est un peu spéciale :

A l’étape 1 de cet article, nous avons spécifié un transfert automatique des demandes d’authentification vers le serveur MFA (DUB-SRV4) dans la console Remote Desktop Gateway. Cela a eu pour conséquence de modifier la règle par défaut sur le composant NPS installé localement.

Nous allons ajouter ensuite rajouter une règle qui permettra de traiter les authentifications une fois que le serveur MFA a effectué son travail.

3.1 Extension du délai d’authentification

Dans un premier temps vérifions et modifions les règles d’authentification initiale (lorsque la demande d’authentification passe du serveur RDG au serveur MFA):

Observons la règle par défaut :

rdg3 

On a bien comme serveur distant le serveur 10.0.1.6 soit le serveur MFA.

rdg4

Comme l’authentification par téléphone peut prendre un peu de temps, nous devons étendre le délais de réponse du serveur MFA, pour cela prenons l’onglet ”Load Balancing” et modifions la valeur à 60 secondes pour cet environnement de test.

rdg6

Une fois cette opération effectué nous continuons en spécifiant le serveur MFA comme client RADIUS et une règle de traitement spécifique.

3.2 Ajout du client RADIUS

Dans la console principale de NPS, on sélectionne la partie RADIUS client et on fait un click droit pour ajouter un nouveau client RADIUS :

rdg7

On spécifie ici le serveur MFA ainsi que la clé partagée que nous avons défini dans la partie Target du serveur MFA, ceci afin que le serveur NPS local accepte les requêtes renvoyées par le serveur MFA.

Donnons un friendly-name à ce client RADIUS et notons le quelque part. C’est très important car nous utiliserons cet attribut dans une règle NPS pour filtrer les requêtes et appliquer un traitement spécifique.

3.3 Création d’une règle d’authentification locale

On ouvre la console NPS et on se dirige dans la section Policies. On édite alors la Connection Request Policy. Cette section est utilisée pour faire un filtrage des requêtes basé sur divers critères et déterminer si l’on procède à l'authentification en local ou si on la renvoi à un autre serveur.

On va créer une règle d’authentification basée sur la règle par défaut (TS Gateway Authorization Policy) en ajoutant comme critère que cette règle s’appliquera aux demandes qui proviennent du serveur MFA (basé sur le friendly-name).

rdg9

On double click sur la règle, modifie son nom pour être un peu plus explicite et on l’active (Policy Enabled).

rdg10

Dans l’onglet Conditions, on click sur Add pour ajouter le Client Friendly Name qui correspond à celui entré à l’étape 3.2 (ici le nom “mfa”);

rdg11

On défini que cette règle sera évaluée localement : dans l’onglet Settings, on prend la partie Authentication et sélectionne “Authenticate requests on the server”.

rdg12

Enfin, comme il s’agit d’une règle spécifique, on la positionne avant la règle générale dans le processing order des règles NPS (click droit sur la règle, Move up) :

processingNPS

Cela devrait bien se passer… testons cela !

4. Vérification du bon fonctionnement de la solution

Il nous reste alors a configurer une session Remote Desktop utilisant notre passerelle.

testcon

Après saisie du mot de passe du domaine et à l’établissement de la connexion, on reçoit un coup de fil, on valide selon les paramètres que l’on a spécifié pour le compte utilisateur (code PIN ou touche #) et la magie devrait opérer ; et ceci à plus forte raison sur un superbe Nokia 1020 comme celui-ci :

testconnect2

Dans un prochain article nous étudierons le provisionning avec le portail WAMFA. Bons tests !

Quelques lectures  :

Remote Desktop Gateway and Windows Multi-Factor Authentication Server using RADIUS – http://technet.microsoft.com/en-us/library/dn394287.aspx 

Technical Scenarios for Windows Azure Multi-Factor Authentication – http://technet.microsoft.com/en-us/library/dn394279.aspx 

Windows Azure Multi-Factor Authentication Release Notes – http://technet.microsoft.com/en-us/library/dn465794.aspx 

Quelques exemples de mise en œuvre de la technologie chez Fredrikson & Byron, http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?casestudyid=710000003252

Pour tester Windows Azure Multi-Factor Authentication, vous pouvez évaluer Azure par ici : https://aka.ms/Azure0Euro

Nos amis Azuréens vous en parleront avec plus de détails dans l’Azure Camp à venir : https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032570149&Culture=fr-FR&community=0 

Pour tester Windows Server 2012 R2, vous pouvez télécharger gratuitement la version d’évaluation disponible sous la forme :

Si vous souhaitez découvrir en 4 heures nos technologies telles que Windows Server 2012 R2, Windows 8.1 en entreprise, le Cloud Privé ou Hybride, vous pouvez vous inscrire gratuitement à un de nos IT Camps :

https://aka.ms/itCampFr

Arnaud – les bons tuyaux