Local Admin Password Solution (LAPS)

Un problème de sécurité assez commun dans les grandes organisations est la gestion des comptes administrateurs locaux (aussi bien sur les machines clientes que sur les serveurs). En effet, très souvent ces comptes sont toujours actifs alors que nous recommandons de les désactiver et ces comptes ont tous les mêmes mots de passe sur l’ensemble des machines.

La menace est assez claire et simple à comprendre, si ce mot de passe est compromis sur une seule machine, alors c’est l’ensemble du parc informatique qui est compromis, sans même avoir besoin d’un compte administrateur du domaine. Il faut donc gérer ce mot de passe, s’assurer qu’il soit unique sur l’ensemble de l’organisation.

De grandes organisations avec lesquelles je travaille sur leurs problématiques de sécurité font donc appel à des outils d’éditeurs tiers pour compléter leur stratégie de sécurité. La bonne nouvelle est que Microsoft propose désormais un outil gratuit pour gérer cela : Local Admin Password Solution (ou LAPS).

Introduction à LAPS

LAPS est une solution de gestion des mots de passe pour les serveurs membres d’un domaine : machines clientes ou serveurs membres. Toutes les éditions de Windows sont supportées depuis Windows Vista (avec dernier SP disponible) et Windows Server 2008 (avec dernier SP disponible) en 32 ou 64 bits.

LAPS c’est :

  • Un composant client qui va mettre à jour le mot de passe dans le contexte système et envoyer le mot de passe aux contrôleurs de domaine Active Directory.
  • Le mot de passe est stocké comme attribut dans l’objet machine de l’Active Directory.
  • Un outillage graphique et de script qui permet de retrouver le mot de passe pour les utilisateurs habilités.
  • Un contexte de déploiement centralisé des paramètres (via stratégies de groupe)

Voici un schéma d’architecture de la solution que je vais vous détailler :

lapsarch

 

Déploiement des composants clients

LAPS est fourni comme un fichier MSI qui permet d’installer les composants clients et serveurs. L’installation par défaut n’installe que les composants clients, et on peut facilement scripter son installation avec la commande : msiexec /i <emplacement>\LAPS.x64.msi /quiet

lapscli

Concrètement, la partie cliente de LAPS est un CSE (Client Side Extension) : c’est une extension qui vient s’enregister auprès du service client de stratégies de groupe de Windows. On installe donc pas de nouveau service à gérer mais bien un composant de l’OS. Ce CSE va se retrouver par défaut dans %programfiles%\LAPS\CSE\AdmPws.dll

A chaque fois que le CSE va être déclenché, il va vérifier si le mot de passe a expiré (basé sur son dernier changement stocké dans l’attribut ms-Mcs-AdmPwdExpirationTime). Si le mot de passe a expiré, alors il en génère un de manière aléatoire et selon les conditions définies dans la stratégie de groupe (détails plus bas) et met à jour l’attribut ms-Mcs-AdmPwd (le mot de passe en clair) sur l’objet machine dans l’AD ainsi que l’attribut ms-Mcs-AdmPwdExpirationTime (pour mettre à jour l’information d’âge de mot de passe).

Notons que l’échange du mot de passe entre le lien et le contrôleur de domaine se fait de manière authentifiée par Kerberos et le transport par le dialogue sécurisé avec LDAP. La confidentialité du mot de passe est garantie car seulement les administrateurs du domaine ont la possibilité de voir ces informations (l’attribut étant flaggué comme confidentiel).

Déploiement des composants infrastructure

Sur un serveur membre nous allons installer les composants LAPS, on aura besoin dans un premier temps d’un compte avec les droits d’administrateur local sur le serveur, ensuite on doit disposer des droits d’administrateurs du schéma, puis finalement des droits d’administration sur l’unité d’organisation qu’on veut administrer (ou administrateur du domaine si on veut le déployer sur toute l’organisation).

Les deux attributs que j’ai mentionnés précédemment sont des nouveaux attributs à ajouter au schéma Active Directory qui seront rattachés à la classe « machine ». Il vous faut pour cela faire l’extension de schéma avec les composants PowerShell fournis par l’outil.

Installons LAPS avec les composants serveurs :

lapserv

On installe l’environnement, et procède à l’extension de schéma en utilisant la commande :

Import-module AdmPwd.PS

Update-AdmPwdADSchema

schemaup

On va ensuite attribuer aux machines le droit de modifier ces attributs pour leur propre compte machine :

Set-AdmPwdComputerSelfPermission -OrgUnit "OU=InfraDemo,DC=w2k12-demo,DC=net"

delegation

Vous remplacerez par le distinguished name de l’OU où vous déployez la solution.

L’étape suivante consiste à déployer les stratégies de groupe qui déterminent le comportement du client LAPS.

Par défaut, LAPS positionne les fichiers ADMX et ADML sur le poste local, si on veut les placer dans le SYSVOL de l’organisation, on ira donc récupérer :

  • C:\Windows\PolicyDefinitions\AdmPwd.admx
  • C:\Windows\PolicyDefinitions\en-us\AdmPwd.adml

Une fois l’opération effectuée, on ouvre une GPO et on accède aux paramètres :

gpmc

Ceux-ci permettent d’activer ou inhiber LAPS, de définir l’intervalle de changement de mots de passe, ses critères de complexité ainsi que le nom du compte administrateur si celui-ci n’est pas « administrator ».

Une fois les paramètres changés, on redémarre la machine membre et la magie doit opérer. On peut accéder au mot de passe de plusieurs manières :

En interface graphique :

flatui1

En PowerShell :

powershell1

Et voilà !

On a donc une bonne petite solution gratuite qui fait son travail, cela ne résout pas tous les problèmes de sécurité mais constitue une très bonne avancée pour votre stratégie de défense en profondeur, et tout cela pour un temps de mise en œuvre relativement réduit comme vous avez pu le voir.

On parle dans la série Concrètement de Pascal Sauliere, et la vidéo est ici :

 

 

Quelques références

Téléchargement – http://www.microsoft.com/en-us/download/details.aspx?id=46899

Security Advisory – https://technet.microsoft.com/en-us/library/security/3062591

KB – https://support.microsoft.com/en-us/kb/3062591

Blog – http://blogs.msdn.com/b/laps/

A bientôt!

Arnaud

Windows 10 pour l’Entreprise : quoi de neuf ?

Lors de l’événement Ignite à Chicago, Satya Nadella a rappelé une chose : nous fournissons les produits et solutions qui permettent aux personnes d’en faire plus, dans leur vie professionnelle comme personnelle.

Nos rythmes de vies et de travail changent et Windows ainsi que nous solutions accompagnent ce changement au rythme de chacun.

L’objectif de cet article est de revoir les principales nouveautés de Windows 10 qui concernent le monde de l’entreprise.

Parmi les sujets fondamentaux pour l’entreprise : protection des données des utilisateurs, gestions des identités, sécurité et intégrité de la machine, et surtout une maintenance plus aisées en commençant par des mécanismes de déploiement simplifiés.

 

1. Protection de l’information

Enterprise Data Protectionest un ensemble de technologies que l’on peut activer pour mieux gérer les données personnelles et professionnelles, dans un seul environnement.

Il a été montré à Ignite l’exemple d’un document édité dans Office déployé avec Intune et spécifié comme application d’entreprise : on a alors un containeur dédié aux informations d’entreprise qui apparait, celui-ci est automatiquement chiffré, il est alors aussi impossible de copier/coller des informations entre l’Office d’entreprise et toute autre application qui n’est pas également marquée comme entreprise.

Combiné à des technologies comme Azure RMS Document Tracking (http://blogs.technet.com/b/rms/archive/2015/05/04/doctracking.aspx) cela fournit des résultats spéctaculaires pour la gestion des documents sensibles en entreprise.

 

2. Protection de l’identité

Avec Microsoft Passport, nous souhaitons sonner la fin de l’utilisation des mots passe, et utiliser de manière plus large des certificats en utilisant le Trusted Platform Module (TPM), maintenant omniprésent sur les machines, pour stocker les clés privées. L’accès à ce moyen d’authentification se faisant ensuite en utilisant un code PIN, ou de la biométrie (empreinte digital, visage, etc.)

Windows Hello est la partie visible de Passport et permet par exemple une authentification par biométrie en reconnaissance faciale (cela nécessite tout de même des capteurs spéciaux comme la caméra RealSense 3D de Intelqui est déjà intégrée à certains laptops.)

 

3. Protection de la machine

DeviceGuardest une technologie qui permet de n’exécuter que ce qui est désigné comme digne de confiance par l’entreprise. Ce mécanisme peut être renforcé encore en utilisant la virtualisation matérielle.

La virtualisation matérielle (Hyper-V Virtual Secure Mode) est utilisée par LSASS (le service qui qui possède les hashs et jetons d’authentifications) pour tourner dans un niveau de confiance différent du noyau et des autres processus, ce qui permet d’éviter de voler les secretset donc d’utiliser des mécanismes de récupération du hash.

 

4. Gestion des machines

Le client Mobile Device Management (MDM) inclus et compatible OMA-DM 2.0 évolue et permet notamment maintenant un effacement à distance de la machine en cas de perte/vol. Cet effacement passe par un retour à l’image d’originale de la machine. Parmi les autres possibilités : gestion de multiples utilisateurs, des profils VPN, etc.

On peut joindre une machine Windows 10 à un domaine Azure Active Directory et donc utiliser l’identité cloud d’un utilisateur en bénéficiant de Single Sign On (SSO) et de gestion de la machine de manière transparente (combiné à Intune)

Accès conditionnel: en fonction de critères de conformité (définis dans SCCM ou Intune) on pourra restreindre l’accès à une application.

Device Lockdown: évolution du mode assigné qui permet de préparer des machines qui sont en libre-service (kiosque). Ce mode évolue pour être plus personnalisable (couleurs, menus etc.)

Gestion des certificats: on peut gérer le déploiement (et suppresion) des certificats sur les machines en utilisant le format PFX et en utilisant le protocol SCEP (Simple Certificate Enrollment Protocol)

 

5. Déploiement aisé

Vous avez sans doute lu que Windows 10 sera proposé gratuitement pour les possesseurs d’éditions grand public de Windows 7 et ultérieur. Celui-ci sera déployé au monde avec Windows Update : sauf pour la version Entreprise.

La version Entreprise se déploiera de plusieurs manières :

  • Wipe and Load : ce que l’on connait actuellement, dans une mise à jour en entreprise. Capture de l’état utilisateur, installation du nouvel OS, restauration de l’état utilisateur.
  • Mise à jour en place : installation par WSUS ou Windows Update for Business (je parlerai de cette fonctionnalité dans un autre article).
  • Provisionning packages : qui permettront de déployer facilement des portions d’OS, des logiciels, des paramètres comme le Wifi, VPN, certificats, etc. On pourra aussi par exemple simplement passer d’une édition grand public de Windows à la version Entreprise (utile dans le Bring Your Own Device)

Notons également un changement fondamental dans la manière dont nous gérons les mises à jour : l’apparation d’une branche de support long terme, qui si vous la choisissez, ne mettra à jour que les failles de sécurité et aucun autre composants. Plus de details sur le Blog de Terry.

 

6. Meilleure productivité

Windows 10 a aussi pour vocation d’être un OS que les gens et les entreprises désirent (Joe Belfiore). Cela veut dire qu’ils aiment les fonctionnalités sympas dont ils profitent déjà à la maison, mais savent être productifs rapidement avec le nouveau système.

Pour cela le menu démarrer ne devrait pas les surprendre par rapport à Windows 7, mais il vient s’enrichir des applications universelles(UWP) qui sont les mêmes qu’ils utilisent sur leurs téléphones.

Afin de remplacer votre navigateur préféré (Internet Explorer), Windows 10 apporte Edge(ex projet Spartan) qui apporte des technologies de rendu HTML avancés ainsi que des expériences utilisateurs modernes (écrire/commenter directement une page Web, un mode lecture qui traduit automatiquement dans votre langue, ainsi que d’autres perles qui restent à annoncer).

Notons qu’Internet Explorer reste disponible et sera utilisable notamment pour des raisons de compatibilité avec les applications métiers (notamment avec son mode IE Entreprise).

Dans un article ultérieur, nous parlerons aussi de nouveautés comme la gestion du store en entreprise qui est aussi très prometteuse.

7. Le résumé en vidéo

Voilà ce que j’ai noté pour vous, il y a plein d’autres sujets que l’on couvrira dans des articles ultérieurs.

Mais en fait, le mieux, c’est de l’installer !

Nous discutons du sujet également avec Pascal dans le podcast ITCast : http://itcast.cloudapp.net/?name=2015-05-07_episode-12.mp3

Téléchargez le livre Microsoft Press : Introducing Windows 10 for IT Professionals, Preview Edition https://t.co/fHpuAuNYO7

Si vous voulez en savoir plus et venir découvrir Windows 10, inscrivez-vous au TechDays Tour, il y a une date près de chez vous ! Par-ici

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