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 :

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

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

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

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

Et le traditionnel redémarrage.

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 :

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

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 :

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.

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

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

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

Choix du répertoire virtuel et du site :

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 :

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

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 :

Sélection du compte dans l’AD :

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.

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.

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 :

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

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

 

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

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 :

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

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.

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 :

• d'une image ISO : https://aka.ms/jeveuxwindows2012r2
• d'un fichier VHD avec un système préinstallé : https://aka.ms/jeveuxwindows2012r2

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

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.

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

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.

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”

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 :

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.

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 :

 

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

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.

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 :

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

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

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”);

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

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) :

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.

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 :

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 :

• d'une image ISO : https://aka.ms/jeveuxwindows2012r2
• d'un fichier VHD avec un système préinstallé : https://aka.ms/jeveuxwindows2012r2

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

Microsoft a racheté il y a quelques mois la société PhoneFactor, et son service d’authentification a été intégré au sein de nos solutions en tant que Windows Azure Multi-Factor Authentication (pour les plus assidus, il s’est aussi appelé Windows Azure Active Authentication durant quelques semaines).

Restons simples : Il s’agit ici d’offrir à nos clients un service d’authentification multi facteur utilisant un système dont nous disposons normalement tous : le téléphone. Lorsqu’un utilisateur va s’authentifier sur des ressources de l’entreprise hébergées sur site ou même dans un cloud, en plus des credentials du domaine, l’utilisateur sera authentifié avec son téléphone.

L’objectif de cette série d’articles est de vous montrer comment mettre en œuvre pas à pas la solution pour protéger l’accès à différents types de ressources.

Nous aurons plusieurs articles dans cette série :

1. Introduction à Windows Azure Multi-Factor Authentication (vous êtes ici)
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

Méthodes d’authentification utilisables

A l’heure actuelle, les méthodes supportées pour s’authentifier sont :

• Appel téléphonique automatisé : l’utilisateur doit répondre à l’appel et presser une touche ou un code PIN.
• Echange de SMS : l’utilisateur reçoit un SMS avec code OTP (one-time password) avec ou sans envoi de code PIN préalable
• Application sur téléphone ou tablette : une fois le périphérique associé à l’utilisateur, il génèrera un code d’authentification toujours avec la possibilité de saisie d’un code PIN préalable. L’application est présente sur les platerformes principales du marché :

Lien	Lien	Lien

Applications supportées

MFA permet de sécuriser l’accès à des applications directement dans un service de cloud comme Windows Azure, Office 365 et Dynamics CRM Online ou tout autre service qui s’intègre avec Windows Azure Active Directory.

Pour sécuriser des services dans vos datacenter, c’est aussi un composant serveur qui s’installe dans votre sur Windows Server et permet d’authentifier :

• connexion Terminal Server
• accès VPN
• accès à la messagerie OWA
• accès à ADFS
• accès à une application IIS

Enfin c’est également un Software Development Kit pour intégrer la solution à un projet plus personnalisé.

En attendant la suite pour mettre en œuvre la technologie dans un environnement de test, quelques lectures :

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 :

• d'une image ISO : https://aka.ms/jeveuxwindows2012r2
• d'un fichier VHD avec un système préinstallé : https://aka.ms/jeveuxwindows2012r2

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