Pour une meilleure compréhension, je vous conseille d’ailleurs vivement de commencer par lire le précédent billet avant de vous intéresser à la reproduction des scénarios d’attaque.

Pourquoi ce billet ?

Le premier réflexe de toute personne technique intéressée sera de mettre en place la solution ATA sur une plateforme de test et de vérifier si les attaques données comme étant détectées le sont effectivement (Voir https://technet.microsoft.com/en-us/library/dn707706.aspx).

Bien sûr, on ne peut pas voir la « soupe magique » utilisée par ATA pour corréler et analyser les événements mais on est directement intéressé pour vérifier son efficacité ; et c’est là que les choses se corsent, car il n’est pas facile de simuler sur un environnement de maquette une vraie infrastructure de production pour s’assurer que la détection comportementale permet réellement de détecter les prémices d’une attaque.

On trouve sur le blog ATA des « y a rien qui marche » https://social.technet.microsoft.com/Forums/security/en-US/home?forum=mata; l’objectif est donc de vous fournir quelques éléments vous permettant de comprendre les mécanismes d’attaque désormais bien connus tels que Pass-The-Hash (PtH) et Pass-The-Ticket (PtT) mais également de les tester sur une maquette ATA.

ATA vs bonnes pratiques ?

L’utilisation d’un outil de détection comme ATA n’est pas la solution magique et ne doit pas vous exonérer de mettre en place les mesures de protection décrites dans les 2 documents “Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft”, Version 1 and 2 https://www.microsoft.com/en-gb/download/details.aspx?id=36036 datés, rappelons-le, de 2012.

La mise en place de ces bonnes pratiques permet de limiter la surface d’attaque de votre SI et de contenir les attaques : plus on réduit la surface d’attaque en implémentant les bonnes pratiques, plus on limite le risque d’infection et de propagation. Investir dans des mesures de protection n’est certes pas quelque chose de très visible et donc de facilement justifiable d’un point de vue financier sauf, malheureusement, après coup.

On a pu cependant remarquer que des budgets impossibles à débloquer en temps normal pour renforcer des mesures de sécurité, devenaient soudainement disponibles pour remettre un SI en ordre de marche après découverte d’une compromission généralisée.

ATA apporte une solution complémentaire dans votre arsenal de défense : il est difficile de contrer une attaque, lorsque l’on n’est pas en mesure de détecter des signaux faibles. Même si l’ignorance peut passer pour une situation agréable (« cela n’arrive qu’aux autres ») jusqu’à la découverte, souvent fortuite, de l’infection, le réveil s’avère en général difficile.

Attaques et Activités suspectes

Parmi les attaques « déterministes », nous allons nous intéresser aux deux familles que sont, les attaques de type reconnaissance (reconnaissance DNS et énumération de comptes), et les attaques par mouvement latéral, les plus critiques étant PtH, PtT et exécution à distance.

Concernant les autres types d’attaques, elles sont plus difficiles à reproduire puisque mettant en œuvre la détection des comportements anormaux associés à une phase d’apprentissage.

Sans minimiser sa criticité, l’attaque Golden Ticket nécessite que l’attaquant ait déjà compromis un contrôleur de domaine, ce qui correspond à la phase finale de l’attaque ; on devrait pouvoir limiter la casse mais les jeux sont quasiment déjà faits. (Cf http://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_14_07_PassTheGolden_Ticket_v1_1.pdf).

L’attaque Forge PAC (MS14-068) utilise une vulnérabilité corrigée depuis plus d’un an (voir « Une vulnérabilité dans Kerberos pourrait permettre une élévation de privilèges » https://technet.microsoft.com/library/security/MS14-068. Si vos contrôleurs de domaine sont correctement patchés, ils ne sont plus vulnérables mais la détection est toujours intéressante car elle signifie que vous êtes sous attaque !

L’attaque Skeleton Key est plus récente. Mais ceci pourra faire le sujet d’un prochain billet.

Passons maintenant à la description des attaques.

1- Reconnaissance DNS

Après avoir compromis un poste ou un serveur, l’attaquant va classiquement tenter de découvrir l’environnement dans lequel il va pouvoir évoluer et va donc mener une action de reconnaissance. Un référentiel intéressant est évidemment l’annuaire DNS qui fournit la liste des noms des ordinateurs du domaine avec leur adresse IP.

Une simple ligne de commande nslookup permet d’essayer de lister la zone correspondante au domaine consoto.com.

On remarquera que, bien que la tentative soit infructueuse, elle déclenche une alerte dans la console ATA. L’ordinateur depuis lequel est effectuée la tentative est indiqué (PC-JHACKER) ainsi que le serveur DNS cible (ici DC01).

2- Reconnaissance avec énumération de comptes

Cette reconnaissance consiste à utiliser un outil (un script java, krbguess) qui initie une tentative d’authentification Kerberos avec un nom d’utilisateur et analyse ensuite la réponse. Le script prend en entrée un dictionnaire de noms d’utilisateurs pour tenter de deviner ceux qui sont présents dans l’annuaire Active Directory.

Pour l’attaquant, l’intérêt de ce script est qu’il ne provoque pas d’événements dans le journal Windows car c'est uniquement la première étape d'une authentification qui ne correspond pas à une authentification infructueuse. Mais bien sûr, ce type d’attaque n’échappe pas à ATA ;-)

La console ATA indique l’ordinateur depuis lequel la reconnaissance a été lancée, le nombre de tentatives avec les noms d’utilisateur associés, et les éventuels essais réussis avec les noms de comptes existants ayant été détectés.

Note: Pour cette attaque, il faut attendre un certain délai (des fois plusieurs minutes) avant que la reconnaissance soit détectée et l’alerte levée.

3- Attaque Pass-The-Hash

Une attaque Pass-The-Hash (PtH) utilise une technique par laquelle un attaquant capture les informations d’authentification d’un compte utilisateur sur un ordinateur, puis les utilise pour s’authentifier à d'autres ordinateurs sur le réseau. Une attaque PtH est très similaire dans le concept à une attaque de vol de mot de passe, mais il repose sur le vol et la réutilisation de hash de mot de passe plutôt que le mot de passe en clair. En effet, le hash du mot de passe (ou NT Hash) peut être utilisé directement comme un authentificateur pour accéder à des services pour le compte de l'utilisateur comme, par exemple, une connexion SMB sur un partage réseau (le hash est de fait le secret partagé entre le poste de l’utilisateur et le contrôleur de domaine).

Contrairement à une attaque profitant d’une faille comme MS14-068 et qui peut résulter d’une erreur dans l’implémentation (erreur de programmation), d’une faiblesse dans un protocole, etc., l’attaque PtH est basée sur le fait que,

• pour des besoins de SSO, les credentials de l’utilisateur sont présents en mémoire dans le processus de sécurité de Windows (Local Security Authority Subsystem Service ou LSASS)
• lorsque l’on est administrateur local d’un poste, on peut appeler des fonctions privilégiées du système qui permettent d’accéder à ces informations (par définition l’administrateur est omnipotent).
• si un compte avec plus de privilèges qu’un utilisateur standard se connecte sur le PC – par exemple pour des besoins de HelpDesk –, que ce soit en ouvrant une session locale ou à distance en RDP, il sera possible d’accéder à ses informations et pouvoir dès lors profiter de ses privilèges plus élevés (attaque par élévation de privilèges).

Il est donc inutile, vous l’aurez compris, de demander à Microsoft un correctif de sécurité pour corriger ce problème.

Une autre caractéristique de ce type d’attaque est le mouvement latéral : l’attaquant va passer de poste en poste pour « moissonner » des informations d’authentification au gré de ses déplacements ; son objectif est de pouvoir arriver à capturer les credentials de comptes privilégiés pour accéder à des informations sensibles ou prendre possession de l’infrastructure s’il a la « chance » de tomber sur un compte administrateur du domaine.

Pour une meilleure compréhension, je vous conseille vivement la lecture des 2 documents Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques https://www.microsoft.com/en-gb/download/details.aspx?id=36036

Pour simuler une attaque PtH, on utilise l’outil Windows Credential Editor (WCE) développé par la société Amplia Security. Il suffit de lancer WCE sur le poste compromis depuis le compte administrateur local de la machine pour lister le NTHash de l’utilisateur ayant une session ouverte sur le poste. Ici l’attaquant est chanceux car l’utilisateur jtrevages est administrateur du domaine (dans un cas réel, le moissonnage aurait sans doute nécessité de nombreux sauts).

L’attaquant se déplace sur un autre poste compromis (déplacement latéral) pour réinjecter le NT Hash dans une session administrateur local.

Pour vérifier que l’on a bien acquis les droits d’administrateur du domaine, il suffit d’ouvrir une connexion réseau sur le répertoire C$ du contrôleur de domaine.

C’est bon ! On a accès au contrôleur de domaine. Mais ATA veille et cette dernière action provoque l’apparition d’une alerte dans la console ATA.

L’alerte est identifiée comme critique et renseigne sur le compte utilisateur dont l’identité a été usurpée (jtrevages), le poste depuis lequel l’action a été effectuée (PC-JHACKER) et fournit des recommandations.

4- Attaque Pass-The-Ticket

Une attaque Pass-The-Ticket (PtT) est très similaire à l’attaque précédente. Depuis un poste compromis sur lequel l’attaquant dispose de privilèges élevés, par exemple administrateur local, il va utiliser un outil lui permettant d’extraire les informations d’authentification depuis la mémoire du processus privilégié LSASS. Dans le cas de PtT c’est le jeton Kerberos de l’utilisateur (le TGT ou Ticket Granting Ticket) qui est intéressant.

L’attaquant va ensuite injecter ce ticket Kerberos sur un autre poste (n’oubliez pas le mouvement latéral) pour accéder aux ressources réseau sous le compte de l’utilisateur dont l’identité a été usurpée.

Là encore, tout repose sur le fait qu’un utilisateur avec privilèges est ou s’est connecté sur le poste compromis et ce risque peut être largement minimisé avec l’adoption de bonnes pratiques. Désolé si j’ai l’air de me répéter ;-)

Pour simuler une attaque PtT, on va utiliser l’outil mimikatz sur le poste compromis avec la commande Sekurlsa ::tickets /export pour exporter dans les fichiers d’extension .kirbi le contenu des différents tickets.

Les fichiers qui nous intéressent sont ceux correspondant aux TGT des utilisateurs ici, associés à l’identité jtrevages.

On doit maintenant mener l’attaque à partir d’un autre poste. Il suffit recopier le fichier en XXX-jtrevages@krbtgt-CONTOSO.COM.kirbi dans le répertoire de mimikatz du poste de l’attaquant.

Pour vérifier que l’injection se passe correctement, lancer d’abord en ligne de commande klist pour lister les tickets Kerberos déjà existants sur la machine. Faites une tentative de connexion sur le partage avec la commande dir \\dc01\c$: la connexion est refusée.

On lance ensuite mimikatz et on injecte le TGT de jtrevages avec la commande Kerberos :: ptt XXX-jtrevages@krbtgt-CONTOSO.COM.kirbi

On vérifie par un klist que les jetons Kerberos de jtrevages sont injectés : c’est bien le cas.

On fait une nouvelle tentative de connexion au DC en faisant dir \\dc01\c$: connexion OK ! Bonne nouvelle pour l’attaquant, mais ceci déclenche une alerte ATA.

L’alerte jugée critique (rouge) nous fournit des informations intéressantes comme le poste depuis lequel l’attaque a été menée, la cible (DC01) et l’identité usurpée (jtrevages), ce qui permet d’envisager des actions correctives immédiates : la dévalidation du compte compromis et la déconnexion du poste utilisé pour l’attaque. Ce pourra être le point de départ d’une investigation en analysant le poste de l’attaquant et en tentant de remonter la piste à partir de l’identité compromise.

5- Remote Execution

PSExec est un outil développé par Mark Russinovich qui fait partie de la panoplie des utilitaires de la suite Sysinternals, bien connue des administrateurs Windows, et que vous trouverez sur technet https://technet.microsoft.com/en-us/sysinternals/bb842062. L’intérêt de PsExec est de pouvoir exécuter un processus sur une machine distante sans avoir à installer de client – ce qui permet de passer sous le radar des anti-virus –. De plus, les outils en ligne de commande qui n’offrent pas la possibilité d’être exécutés sur une machine distante deviennent utilisables avec PsExec. C’est pour cela que cet outil fait souvent partie de l’arsenal des attaquants.

Dans la suite logique d’une attaque de type Pass-The-Ticket, l’attaquant cherchera à exécuter des commandes sur le serveur cible.

On peut vérifier par la commande hostname que l’on est bien sur le DC, mais l’alerte est levée dans la console ATA.

Là encore, l’alerte nous fournit des informations intéressantes sur la cible et sur le poste depuis lequel est menée l’attaque.

Conclusion

Depuis plusieurs années, les entreprises font face à des attaques ciblées dont le scénario est connu et qui profite du fait que certaines bonnes pratiques de sécurité ne sont pas mises en œuvre ; celles principalement consistant à limiter au strict minimum le nombre et l’utilisation de comptes à privilèges. Ce billet décrit comment simuler certaines attaques “déterministes” comme Pass-The-Hash et Pass-The-Ticket qui sont détectées par ATA.  

La détection de ce type d’attaques n’est qu’un des aspects de la solution ATA, puisque la fonctionnalité de détection des comportements anormaux basée sur le Machine Learning doit permettre de détecter des attaques plus complexes (comme Over-Pass-The-Hash ou Golden Ticket) ou de mettre en évidence des signaux faibles caractéristiques d’une APT.

Cette solution, issue du rachat de la start-up AORATO en novembre 2014, a été disponible dans sa première version publique 1.0 le 31 aout dernier, la mise à jour en version 1 .5 venant tout juste d’être annoncée début décembre.

L’objectif est également d’expliquer les deux aspects de la solution : la détection des menaces et la détection des comportements anormaux par l’utilisation du Machine Learning.

Cela permettra entre autres de comprendre pourquoi certaines attaques sont détectées immédiatement alors que d’autres nécessitent de passer par une phase d’apprentissage.

Dans des billets suivants, on rentrera dans le détail de différents types d’attaques et de leur détection par ATA.

Mais tout d’abord, revenons sur la question fondamentale de savoir pourquoi déployer cette solution.

Contexte

Alors que la cybercriminalité revient de manière tragique sur le devant de la scène, on n’a cessé d’alerter depuis de nombreuses années les entreprises sur les faiblesses de leur protection vis-à-vis de ce qu’on a appelé des attaques ciblées, désignées également sous le terme d’Advanced Persistant Threats.

Ces attaques n’ont fait que s’amplifier et les entreprises victimes n’en découvrent la réalité qu’en moyenne 8 mois après le début de l’attaque, ce qui rend excessivement difficile l’éradication et laisse imaginer le volume de données sensibles qui a pu être exfiltré durant cette période.

La France n’a pas été épargnée par ce type d’attaque ; pour citer Guillaume Poupard, Directeur de l’ANSSI lors des Assises de la Sécurité de fin 2015 :

« Des entreprises françaises ont été victimes d'attaques informatiques ces derniers mois, dont la plupart n'ont pas été rendues publiques ».

« Des cas concrets, on en a eu, malheureusement, on ne les a pas médiatisés, ce n'est pas notre rôle », a déploré M. Poupard, en ouvrant les 15^es Assises de la sécurité et des systèmes d'information, à Monaco. « Des choses dont on ne parle pas, même sous la torture, se sont produites au cours de cette année », a insisté le patron de l'ANSSI, l'agence chargée depuis 2009 de coordonner la défense française face aux cybercriminels.

Source : Piratage informatique. De plus en plus d'entreprises françaises touchées http://www.ouest-france.fr/economie/piratage-informatique-de-plus-en-plus-dentreprises-francaises-touchees-3728087

Caractéristiques de ces cyber-attaques

Les investigations menées sur ces attaques nous apprennent plusieurs éléments caractéristiques :

• Dans 75% des cas, l’attaque a été perpétrée par vol ou compromission d’informations d’authentification d’utilisateurs légitimes de l’entreprise ; contrairement aux précédents préceptes, c’est l’identité qui est la nouvelle frontière de sécurité et non plus le (pseudo) périmètre de l’entreprise. L’attaquant pénètre dans le réseau interne soit par compromission d’un serveur ou d’une application exposée sur internet ou plus simplement par le biais d’un mail ciblé (spear phishing) avec un contenu infecté ou redirigeant par URL sur un serveur infecté.
• Les outils utilisés par les attaquants sont les outils de l’IT : la plupart des exploits sont disponibles sous forme de scripts Powershell et les accès en remote Powershell sont chiffrés. Il devient donc difficile d’identifier les attaques par le biais des outils.
• Les entreprises mettent en moyenne 8 mois pour s’apercevoir qu’elles ont été victimes d’une attaque ; il ne s’agit plus de se demander si on va être attaqué mais quand ? Là encore, il faut changer de mode de pensée en « assumant la compromission » (« Assume Breach »). La réflexion n'est plus de savoir comment j'empêche l'attaquant de rentrer, de franchir mon (semblant de) périmètre avec mes pare-feu ; il faut se demander quels outils on peut mettre en place pour détecter quand l’attaquant est dans les murs, quelles procédures de manière à bloquer l'attaquant pour éviter un mouvement latéral qui lui permettra de moissonner d'autres identités et d’accéder aux données critiques.
• Enfin, il faut considérer que ce n’est plus uniquement un problème de sécurité qui reste de la responsabilité du RSSI ; les impacts sur l’entreprise que ce soit au niveau financier, détérioration de l’image, perte de compétitivité par pillage des données confidentielles ou de propriété intellectuelle peuvent être considérables et impliquent le DSI et la direction de l’entreprise. On estime qu’en moyenne le coût associé à une éradication de l’infection suite une compromission est de l’ordre de 3,5 millions de dollars (3,2 millions €).

Advanced Threat Analytics : principes

ATA est une solution que l’on déploie sur le réseau interne de l’entreprise et qui intègre deux mécanismes complémentaires :

• la détection des attaques « déterministes »; par exemple les attaques Pass-The-Hash ou Pass-The-Ticket sur l’authentification Kerberos;
• l’analyse comportementale, qui permet, après une phase d’apprentissage, de détecter des comportements anormaux ; par exemple un déplacement latéral de l’attaquant passant d’une machine compromise à une autre, ce qui correspond à une empreinte caractéristique d’une attaque de type APT.

C’est l’association de ces deux facettes qui permet de faire face non seulement à des menaces connues, mais de détecter des menaces inconnues par détection de signaux faibles signalant des comportements hors norme.

Concernant l’implémentation, ATA s’appuie sur deux composants :

1. La passerelle (ATA Gateway) chargée de collecter et prétraiter les flux réseau et les événements;

2. Le Centre de traitement (ATA Center), le centre nerveux de la solution vers lequel les passerelles vont transférer leurs informations et qui va les ingurgiter, stocker, analyser et corréler pour identifier les comportements suspects et lever les alertes.

Collecte des informations : Passerelle ATA

Le parti pris de la solution ATA est d’analyser les flux vers et depuis les contrôleurs de domaine d’une infrastructure Active Directory. Pourquoi ? : parce qu’Active Directory est la pièce centrale qui contient l’ensemble des identités des utilisateurs, des comptes de machines, contrôle les authentifications et attribue ou valide l’accès aux ressources de l’entreprise. C’est donc l’endroit idéal pour surveiller et analyser !

Pour collecter le trafic des contrôleurs de domaine, la solution ATA utilise des passerelles (ATA Gateway) s’exécutant sous Windows Server 2012 R2 et configurées en port-mirroring : l’avantage est que la configuration est non-intrusive dans le sens où rien ne doit être installé sur les DC et que les passerelles sont invisibles pour les attaquants ; elles n’ont pas à être membre du domaine et une passerelle peut même surveiller plusieurs DC y compris de domaines différents. Bien sûr, il y aura du dimensionnement à prévoir en fonction du nombre de DC à surveiller et de leur sollicitation !

Les passerelles ATA peuvent également collecter les informations en provenance d’un SIEM déjà déployé dans l’entreprise (Syslog forwarding) et également d’autres sources comme les journaux d’événements en utilisant la fonctionnalité Windows Event Forwarding.

Les passerelles ATA ont une certaine intelligence car elles effectuent une inspection approfondie des trames réseau et assurent également la fonction de résolution de noms : par exemple, pour déterminer quel appareil est associé à une adresse IP ; mais également pour travailler sur des GUID plus faciles à manipuler et invariants au renommage. Pour les utilisateurs, le nom est indiqué dans les informations du jeton Kerberos mais il est intéressant de récupérer le GUID attribué au compte utilisateur en interrogeant Active Directory.

D’autres informations sont intéressantes à récupérer : si l’appareil tourne sous Windows et est référencé dans AD ; s’il s’agit d’un autre OS, Android, Mac…Contrairement à ce que l’on pourrait penser, la solution ne couvre pas uniquement les postes, serveurs ou mobiles sous Windows.

Ces informations sont ensuite compressées et envoyées par la passerelle vers le composant ATA Center qui intègre l’intelligence de la solution.

Traitement des informations : ATA Center

L’élément central de la solution est le composant ATA Center qui reçoit les informations en provenance des passerelles et les stocke dans sa base de données. Il les analyse en appliquant ses algorithmes de Machine Learning (d’où le terme Analytics dans ATA) pour détecter des activités suspectes ou des comportements anormaux en corrélant les événements.

De manière plus détaillée, ATA Center travaille sur des profils c’est-à-dire qu’il analyse les comportements des différentes « entités » visibles sur le réseau (par entité, on entend les utilisateurs, ordinateurs, serveurs, mobiles). Ce profil va indiquer, par exemple, quel utilisateur accède depuis quels appareils à quels serveurs.

Ceci va permettre de construire un arbre de décision du périmètre réseau observé. Pour bâtir cet arbre de décision, ATA Center va devoir apprendre à connaître son environnement, cette période d’apprentissage étant estimée à 3 semaines dans un véritable environnement de production. Comme pour tout moteur de Machine Learning, il faut qu’il soit alimenté en données et donc qu’il y ait une véritable activité.

Ceci explique pourquoi il est difficile de reproduire dans un simple environnement de maquette ce type de détection: autant on pourra simuler des attaques à détection immédiate (Pass-The-Hash, etc), autant des scénarios d’attaque plus subtils ne pourront être mis en évidence dans un environnement simpliste.

L’intérêt du Machine Learning est que, contrairement aux solutions de type SIEM, il n’y a PAS à définir de ligne de référence, de seuils ou de règles ; c’est à travers l’apprentissage et la construction de l’arbre de décision que se fera la distinction entre ce qui est normal ou anormal.

Il est intéressant de noter que l’arbre de décision n’est pas statique comme pourrait l’être une ligne de référence : il évolue sur une fenêtre glissante de 3 semaines pour prendre en compte automatiquement les variations. C’est en analysant et comparant les comportements durant les dernières 24 heures avec l’arbre de décision que l’on pourra détecter des comportements suspects comme le partage de mot de passe (le même compte identifiant et mot de passe utilisé depuis des machines différentes), un mouvement latéral caractéristique d’une attaque ciblée, etc., et lever des alertes.

Détection des attaques

L’objectif final est de détecter des attaques : certaines vont utiliser des techniques connues (par exemple Pass-The-Hash ou Pass-The-Ticket) et que l’on classifiera de déterministes, et d’autres que l’on pourra détecter par analyse comportementale en accumulant un certain nombre d’indices d’activités suspectes.

Prenons le cas de la très fameuse attaque Pass-The-Hash dont le principe est le suivant : l’attaquant réussit à compromettre un poste Windows et à s’octroyer des droits d’administrateur local ; il va pouvoir accéder au hash du mot de passe du ou des utilisateurs ouvrant une session sur ce poste. Une fois en possession de ce hash, il va être en mesure de l’utiliser à partir d’autres postes pour s’authentifier sur le réseau en tant que l’utilisateur dont il a usurpé l’identité, et accéder aux ressources avec les autorisations de cet utilisateur.

Pour ce type d’attaque, la détection est immédiate ; la console ATA lève une alerte indiquant le type de l’attaque (Pass-The-Hash), depuis quel poste a été effectuée l’action (PC-JHACKER) et sous quelle identité usurpée (jtrevages).

Pour d’autres types d’attaques, par exemple, Over-Pass-The-Hash, la détection nécessite de passer par une période de « profilage » d’environ 5 jours.

Ci-dessous, une première alerte sur une activité suspecte déclenchée par une tentative d’attaque Over-Pass-The-Hash ; le malware doit utiliser un algorithme de chiffrement plus faible (RC4 au lieu d’AES) dans la trame AS-REQUEST Kerberos, ce qui est un comportement anormal par rapport à de précédentes authentifications de l’utilisateur.

L’article Technet Microsoft Advanced Threat Analytics https://technet.microsoft.com/en-us/library/dn707706.aspxliste les différents types d’activités suspectes détectées parmi lesquelles

• Activités suspectes de Reconnaissance and Brute Force :
  • Reconnaissance DNS
  • Reconnaissance avec énumération de comptes
  • Brute force (LDAP, Kerberos)
• Activités suspectes de vol d’identité :
  • Pass-The-Ticket
  • Pass-The-Hash
  • Over-Pass-The-Hash
  • Skeleton Key
  • MS14-068 exploit (Forged PAC)
  • Golden Ticket
  • Remote Execution

Conclusion

Microsoft Advanced Threat Analytics (ATA) est un nouvel outil mis à votre disposition pour vous aider à lutter contre les cybermenaces. La solution est non-intrusive et, par l’analyse des flux réseau à destination des contrôleurs de domaine Active Directory, détecte les attaques connues de type Pass-The-Hash mais dont il est difficile de se protéger, et des attaques plus récentes comme Skeleton Key. Le profilage automatique de l’environnement associé à son moteur de Machine Learning permet de détecter les comportements anormaux qui sont souvent les signaux d’une attaque en cours.

On a également vu que le fait de pouvoir s’appuyer sur une infrastructure principalement Cloud ouvrait de nouveaux scénarios pour des petites ou moyennes entreprises, des établissements scolaires, réseaux d’agence, entreprises partenaires, franchisés, ONG…On peut dès lors disposer dans le Cloud, de services qui nécessitaient précédemment d’investir dans une infrastructure qu’il fallait déployer, gérer et faire évoluer.

L’autre avantage du Cloud, est qu’il s’adapte naturellement aux évolutions de l’entreprise : si l’entreprise est en croissance, il n’est nul besoin de faire des investissements supplémentaires pour accueillir de nouveaux collaborateurs ; cette caractéristique du Cloud que l’on désigne par « élasticité », permet de prendre en compte immédiatement les variations liées au business.

Pour revenir sur le sujet technique de jonction à Azure AD, la description du billet précédent était orientée IT. Mais il est également important de s’intéresser à l’expérience de l’utilisateur ou du collaborateur qui va rejoindre l’entreprise : c’est ce que vous trouverez désigné en version US comme Out-of-the-Box Experience, ou en abrégé OOBE (à prononcer Ououbi !), et que l’on pourrait traduire par expérience après déballage ou en sortie du carton. Cette expérience se doit d’être la plus simple possible : on part du principe que l’utilisateur n’est pas censé avoir une connaissance des arcanes d’Azure AD pour enregistrer sa tablette et accéder aux applications de sa nouvelle entreprise !

Pour continuer dans la lignée du précédent billet, on va s’appuyer sur l’annuaire Azure AD contosofrcloud.onmicrosoft.com que l’on a créé précédemment et sur l’utilisateur de test Janssey Trevages (petit nom : jtrevages) de ce domaine.

Expérience utilisateur

Dans le scénario cible, l’utilisateur reçoit de la part de l’entreprise un appareil avec Windows 10 ou en a fait l’acquisition.

L’entreprise (ou l’école) aura distribué un petit dépliant à l’utilisateur ou lui aura transmis un lien vers la procédure d’installation. On devra également lui fournir les seules deux informations nécessaires : son identifiant d’utilisateur et le mot de passe temporaire qu’il devra changer durant la procédure d’enregistrement.

De plus, l’utilisateur devra être en possession d’un smartphone dont le numéro de téléphone lui sera demandé et qui servira de second facteur d’authentification lors de la création du code PIN.

L’expérience utilisateur que l’on souhaite la plus simple se décompose en deux étapes :

1. Identification au niveau de l’annuaire Azure AD d’entreprise avec choix d’un mot de passe propre à l’utilisateur, ce qui va permettre l’enregistrement de l’appareil ;
2. Création d’un code PIN avec authentification multi-facteur pour accéder immédiatement à l’ouverture de session sur le compte de l’utilisateur

Commençons la procédure.

L’appareil est préinstallé avec l’OS et la personne le sort de son carton et l’allume.

L’écran ci-dessous s’affiche qui pose la question « A qui appartient ce PC ? ».

L’utilisateur doit faire ce choix important de spécifier que l’appareil « appartient » à une entreprise, que cette dernière lui ait fourni directement ou non ; en effet, il s’agit d’un appareil qui va passer sous le contrôle de l’entreprise─ on va la joindre à l’annuaire Azure AD ─ et l’utilisateur ouvrira sa session sur un compte utilisateur Azure AD de l’entreprise que l’on trouve classiquement désigné dans la prose Microsoft comme compte d’entreprise ou compte de travail. Voir dans le billet précédent « Qu’est-ce qu’un compte de travail ou d’entreprise ? ».

On choisit l’option « My organization » et on clique sur Next.

Note : Lorsque vous installer à partir d’une version Enterprise, ce premier écran n’apparaîtra pas.

Le deuxième écran permet de choisir entre joindre l’appareil à Azure AD ou à un domaine ; là encore, l’utilisateur n’est pas censé savoir à quoi correspond Azure AD et donc la petite notice sera la bienvenue. Il doit choisir l’option « Join Azure AD » puis cliquer sur Continue.

L’écran suivant va permettre de spécifier son compte d’utilisateur d’entreprise (compte Azure AD) qui sera associé à cet appareil.

Dans le champ Work or school account, l’utilisateur entre son identifiant d’utilisateur dans l’entreprise, dans notre exemple jtrevages@contosofrcloud.onmicrosoft.com, puis le mot de passe initial. Ce mot de passe est celui qui est attribué à la création du compte et qui lui a été transmis. Il valide en cliquant sur le bouton Sign-In.

Note: Le fait que l’on parle de compte de travail ou compte d’école (school account) indique que les scénarios pour l’éducation sont bien envisagés.

S’agissant d’une première authentification, l’écran « Update your password » s’affiche ; l’utilisateur entre de nouveau le mot de passe initial et choisit un mot de passe qu’il devra confirmer dans la 3^ème boite texte, puis cliquer sur le bouton Sign in.

L’écran suivant demande de patienter pendant l’enregistrement de l’appareil dans Azure AD et un premier paramétrage lié au compte utilisateur.

Effectivement, après quelques secondes, l’écran de demande de création d’un code PIN s’affiche.

Ce code PIN est associé au nouveau mode d’authentification de Microsoft Passport et est lié à l’appareil ; il servira ultérieurement pour s’authentifier –par exemple pour l’ouverture de session- ou enregistrer un geste biométrique à travers Windows Hello.

On peut cliquer sur le lien “How can a short PIN be safer than a long password?” pour répondre à une interrogation classique. Pour s’en convaincre, on peut s’appuyer sur l’analogie avec le code PIN d’une carte bancaire. (je vous laisse y réfléchir, et on ramasse les copies dans une heure )

Note : pour plus d’information sur Windows Hello et Passport, veuillez consulter les liens suivants Password-less Authentication with Microsoft Passport, Microsoft Passport overview et Making Windows 10 More Personal and More Secure with Windows Hello

L’utilisateur clique sur le bouton « Create PIN ».

Avant d’autoriser la création du code PIN, l’utilisateur doit spécifier un numéro de téléphone de manière à fournir un deuxième facteur d’authentification : la preuve de possession d’un appareil, ici le smartphone.

L’utilisateur clique sur le bouton «Set it up now ».

Dans l’écran “Verify your identity”, la liste déroulante permet de sélectionner la méthode de vérification parmi « Text Message », « Phone Call » ou « Mobile App ».

Dans cet exemple, on choisit « Text Message » pour recevoir un SMS, puis on remplit l’indicatif téléphonique du pays France(+33), suivi du numéro de téléphone sur lequel on veut recevoir le SMS, et on clique sur Next. (Attention à ne pas mettre de 0 devant le 6)

Sur réception du SMS, l’utilisateur rentre le code à usage unique transmis et clique sur Next.

L’écran Set up a work PIN s’affiche. L’utilisateur entre 2 fois le code PIN de son choix en respectant les politiques spécifiées (configurables) et appuie sur le bouton OK.

Après quelques secondes, la session Windows 10 s’ouvre sur l’appareil sous l’identité d’entreprise ! Remarquez bien que l’ouverture de session s’est bien faite sous l’identité Janssey Trevages.

La prochaine fois que l’utilisateur souhaitera ouvrir une session ou débloquer son appareil, il aura, pour s’authentifier deux possibilités : soit utiliser son mot de passe en choisissant l’icône avec la clé (cf ci-dessous), ou plus simplement le code PIN qui vient d’être créé, en sélectionnant l’icône avec le petit clavier.

La possibilité d’utiliser un code PIN est un véritable avantage d’un point de l’expérience utilisateur ; c’est un confort que connaissent les possesseurs de carte à puce physique ou virtuelle mais qui devient désormais accessible à tous!

POINT IMPORTANT : Contrairement à l’implémentation Windows 8/8.1, le code PIN n’est pas simplement un système d’authentification qui repose, au final, sur le mot de passe. Dans son principe, on s’approche plus de l’implémentation des cartes à puce virtuelles, où le code PIN permet d’autoriser l’accès à un ensemble de clés privées stockées dans un container local lui-même protégé par le TPM de l’appareil. (Pour être plus précis, pour permettre de faire effectuer des opérations cryptographiques nécessitant l’utilisation de clés privées).

Conclusion

Dans la suite du billet précédent qui détaillait la mise en place de la jonction à Azure AD et ses avantages, celui-ci a détaillé l’expérience de l’utilisateur qui déballe son appareil et doit l’associer à son entreprise ou son école pour pouvoir bénéficier immédiatement de l’accès à ses ressources et applications. L’expérience en deux étapes, comprenant l’identification dans l’annuaire d’entreprise et la création d’un code PIN pour une authentification simplifiée, se veut la plus simple possible.

L’appareil est automatiquement enregistré dans Azure AD ce qui ouvre de nouveaux horizons comme le contrôle d’accès conditionnel aux applications de l’entreprise. Mais ceci est une autre histoire…

1. l’appareil joue le rôle d’un deuxième facteur d’authentification ;
2. l’accès à des applications ou services puisse être autorisé selon que l’appareil de l’utilisateur soit ou non enregistré, des paramètres supplémentaires pouvant également être pris en compte comme le type d’appareil, l’accès depuis l’extérieur, etc.

Cet enregistrement concerne les OS Windows depuis Windows 7, mais également iOS et Android.

Durant la session des TechDays 2015 Joindre un domaine Cloud avec Windows 10 pour de nouvelles expériences BYOD et au-delà !, nous vous avons détaillé, avec mon collègue Philippe Béraud, une nouvelle fonctionnalité apportée par Windows 10 : la jonction à un domaine Azure Active Directory.

A l’époque, il n’était pas possible de vous en faire la démonstration en live car la fonctionnalité n’était pas encore disponible dans Azure AD, mais maintenant, vous allez pouvoir vous en faire une idée plus précise et très facilement la tester en suivant ce billet.

On peut décliner plusieurs scénarios autour de cette nouvelle fonctionnalité de jonction à Azure AD selon que l’on dispose d’une infrastructure uniquement Cloud – option tout à fait envisageable pour des PME, l’éducation, les réseaux d’agence, ONG, etc.) – ou d’une infrastructure hybride où l’annuaire interne de l’entreprise est utilisé comme référence par Azure AD. Les scénarios peuvent ensuite s’enrichir en introduisant un compte utilisateur personnel (scénario BYOD), une expérience de configuration simplissime après déballage de l’appareil, l’enregistrement automatique dans un outil de gestion de flotte (Mobile Device Management), etc.

Pour commencer simplement et éviter de tout mélanger, on va traiter dans un premier temps du scénario uniquement Cloud, qui possède en plus l’avantage d’être excessivement simple à mettre en œuvre.

Mais avant de rentrer dans l’implémentation, il n’est pas inutile de faire un petit rappel sur deux types de comptes utilisateur : le compte (personnel) Microsoft et le compte Azure AD.

Qu’est-ce qu’un compte Microsoft ?

Un compte Microsoft (Microsoft Account ou MSA) est tout d’abord un compte personnelaccessible avec un identifiant correspondant à une adresse de messagerie Microsoft (hotmail.com, outlook.fr, etc. ) ou associé à une autre messagerie comme par exemple gmail. Il permet d’accéder aux applications du Store Windows et aux services Cloud grand public de Microsoft tels que le service de stockage en ligne OneDrive. L’environnement personnel est accessible en mobilité et depuis tous les appareils Windows de l’utilisateur (PC, tablette, Windows Phone).

Dernier point important, depuis Windows 8, vous pouvez ouvrir une session sur un appareil Windows en utilisant ce compte personnel Microsoft.

Ci-dessous, une photo de mon écran d’authentification Windows 10 avec un compte Microsoft associé à l’adresse email jtrevages@hotmail.com.

Je vous conseille la petite vidéo de 2 minutes Qu’est-ce qu’un compte Microsoft ?

Ce service Microsoft reste dédié pour le grand publicavec l’avantage de la gratuité (en version de base).

Pourquoi commencer par parler d’un compte personnel ? En toute logique, dans un scénario d’entreprise dans le cadre du BYOD, ou CYOD (Choose Your Own Device), on va souhaiter une utilisation à la fois personnelle et professionnelledu même appareil.

Qu’est-ce qu’un compte de travail ou d’entreprise ?

Vous trouverez dans la littérature Microsoft plusieurs dénominations telles que compte de travail (Work account), compte d’entreprise (Enterprise account ou organizational account), toutes pour désigner la même chose : un compte utilisateur Azure AD.

La différence fondamentale avec un compte Microsoft destiné au grand public, est que ce référentiel Azure AD est le vôtre ; il ne s’agit PAS d’un annuaire public partagé. Plus précisément Microsoft vous met à disposition un annuaire dans le Cloud dont vous êtes non seulement locataire mais dont vous avez également la gestion : c’est vous qui créez l’annuaire Azure Active Directory, qui l’administrez, qui gérez les utilisateurs ou qui choisissez de les synchroniser à partir de votre annuaire AD d’entreprise ; bref, c’est comme votre AD mais dans le cloud.

Ce domaine a, par défaut, un nom qui se termine avec le suffixe en onmicrosoft.com (ex. contosofrcloud.onmicrosoft.com);  vous pouvez également lui attribuer un nom de domaine que vous aurez préalablement enregistré, par exemple contosofrcloud.com.

L’énorme avantage d’Azure AD est qu’il sert de référentiel pour les services Cloud Microsoft, tels qu’Office 365 : en général, en tant qu’entreprise ou administration, il est bien vu d’offrir à chaque utilisateur, une boite mail, du stockage en ligne, de la messagerie instantanée, services qui sont fournis en ligne dans cette offre sur abonnement.

D’autres services s’appuient sur ce référentiel Azure AD, tels que Windows Intune, la solution de MDM Microsoft, mais également des milliers d’applications SaaS tierces disponibles sur le Market Place.

Si vous souhaitez creuser un peu plus, deux liens d’introduction What is Azure Active Directory? et Identity and Access Management for the Cloud.

Quel est l’intérêt d’enregistrer un appareil Windows 10 ?

Un premier intérêt est de pouvoir ouvrir une session sur le compte d’entreprise défini dans Azure ADce qui vous permet de bénéficier des services qui en découlent.

Si on fait le parallèle avec les services offerts avec votre compte personnel Microsoft, vous allez avoir le même type de services mais avec votre compte d’entreprise c’est-à-dire :

• les paramètres de configuration et l’environnement de travail automatiquement disponibles sur tous vos appareils Windows 10 qui sont enregistrés dans Azure AD et associés à votre compte ;

• le SSO avec les applications et services qui s’appuient sur Azure AD avec en premier lieu les services Office 365 ;

• L’enregistrement automatique dans l’outil de MDM, avec Windows Intune mais également les plateformes tierces qui ont choisi de s’intégrer avec Azure AD ;

• L’expérience de première configuration simplissime (Out Of the Box experience) qui permet à l’utilisateur de configurer son appareil dès déballage, en spécifiant son compte d’entreprise ;

• L’accès au Store d’entreprise pour installer les applications à utiliser dans le cadre de votre travail.

Pour plus d’informations sur le sujet, consultez le billet Azure Active Directory and Windows 10: Bringing the cloud to enterprise desktops!

Comment implémenter la jonction à Azure AD : les étapes

Dans la suite de ce billet, on décrit l’ensemble des étapes à suivre pour mettre en œuvre et tester la jonction d’un poste Windows 10 à votre propre annuaire Azure Active Directory.

1- Création de l’annuaire d’entreprise Azure Active Directory

Pour faire le test, il faut d’abord disposer d’un annuaire Azure Active Directory qui constituera votre annuaire d’entreprise. Dans la souscription Azure, il suffit de créer un Active Directory dénommé ici « contoso France cloud only », avec comme nom DNS contosofrcloud.onmicrosoft.com.

IMPORTANT: il vous faudra choisir un autre nom de domaine, car celui-là est déjà réservé

1. Connectez-vous sur le portail de gestion Azure https://manage.windowsazure.com/ et authentifiez-vous.

2. Dans le bandeau de gauche, cliquez sur l’onglet ACTIVE DIRECTORY pour afficher la liste des annuaires déjà créés.

3. Appuyez sur la croix + NEW en bas à gauche, puis sélectionnez DIRECTORY/CUSTOM CREATE.

4. Dans l’écran Add directory, entrez le nom de l’annuaire Azure AD, le nom de domaine (qui doit être unique dans l’espace de nom associé à onmicrosoft.com), puis sélectionnez le pays France dans la liste déroulante.

5. Appuyez sur le signe « Complete » en bas à droite.

Après quelques secondes, vous verrez apparaitre votre nouveau domaine dans la liste

2- Création de l’utilisateur de test

On crée ensuite un compte utilisateur de test, jtrevages@contosofrcloud.onmicrosoft.com.

1. Cliquez sur votre nouvel annuaire (Contoso France Cloud Only) puis sur l’onglet USER.

2. Cliquez sur le signe ADD USER en bas de l’écran.

3. Sur la page Tell us about this user, entrez le nom d’utilisateur (jtrevages) puis passez à l’écran suivant en appuyant sur la flèche en bas à droite.

4. Dans la page user profile, entrez les informations de l’utilisateur, et appuyez sur la flèche droite en bas à droite pour passer à l’étape 3. (Laissez décochée l’option MULTI-FACTOR AUTHENTICATION).

5. Dans l’écran suivant, appuyez sur le (gros) bouton vert create.

6. L’utilisateur est créé et un mot de passe initial lui est attribué, qui sera demandé lors de sa première tentative de connexion. N’oubliez pas de noter ce mot de passe et cliquez ensuite sur le signe en bas à droite.

Vous pouvez vérifier que l’utilisateur apparait bien dans la liste des utilisateurs du domaine.

Note : La création des utilisateurs peut être aisément automatisée avec PowerShell.

3- Activation de la fonction de jonction à Azure AD

Il suffit maintenant d’activer la fonctionnalité de jonction au domaine Azure AD qui vient d’être créé.

1- Sélectionnez votre nom d’annuaire dans le bandeau avec la flèche de retour arrière. Cliquez sur l’onglet CONFIGURE puis descendez jusqu’à la section devices.

2- A droite de USERS MAY AZURE AD JOIN DEVICES, cliquez sur le sélecteur ALL pour autoriser sans restrictions particulières. L’option SELECTED vous permettrait de restreindre la fonctionnalité à des utilisateurs ou groupes d’utilisateurs.

3- N’oubliez de valider en cliquant sur l’icône disquette SAVE.

Note : à la date de rédaction, la fonctionnalité est encore en PREVIEW.

Vous remarquerez aussi, que juste au-dessus, on retrouve l’option USER MAY WORKPLACE JOIN DEVICES permettant d’activer la jonction au lieu de travail décrite dans le précédent billet, même si le nom a changé (précédemment ENABLE WORKPLACE JOIN).

4- Installation d’un poste ou d’une machine virtuelle en preview Windows 10

Pour tester, il vous faut disposer d’un poste Windows 10. Il suffit de vous inscrire dans le programme Windows Insider à l’URL https://insider.windows.com/pour pouvoir récupérer le fichier ISO de la Preview de Windows 10, Build 10074 (à date).

Vous pouvez ensuite installer Windows 10 soit sur une machine physique, soit sur une machine virtuelle en profitant par exemple de la fonctionnalité Hyper-V disponible depuis Windows 8 (nécessite une machine 64 bit avec l’option Second Level Address Translation – SLAT).

Durant l’installation, spécifiez comme utilisateur, un compte Microsoft (dans l’exemple de ce billet jtrevages@hotmail.com), compte sur lequel vous ouvrirez votre première session.

Pour détailler la procédure de jonction à un domaine Azure AD, j’ai choisi volontairement de décrire le scénario où l’utilisateur possède déjà un compte personnel Microsoft qu’il utilise sur son appareil. Un autre scénario consistant à inscrire automatiquement l’appareil dès son déballage est également possible mais sera décrit ultérieurement.

5- Jonction du poste Windows 10 dans Azure Active Directory

Tout est prêt pour pouvoir tester la fonctionnalité de jonction dans Azure AD. Dans la build 10074 de Windows 10, l’option de jonction à AAD a été cachée au fin fond de l’application moderne SETTINGS.

1- Dans la barre de recherche Cortana, entrez « settings » et validez. L’application moderne SETTINGS se lance.

2- Naviguez vers SYSTEM\About pour afficher l’écran ci-dessous

Note : Au cas où vous ne verriez pas apparaitre les options «Join a domain » et « Connect to Cloud », vérifiez que le compte utilisateur sur lequel vous êtes authentifié est bien administrateur local du poste (ce qui doit être le cas si vous avez suivi la procédure d’installation selon les indications de l’étape précédente).

3 - En cliquant sur le lien Connect to cloud, on affiche un écran d’avertissement légal vous spécifiant que vous allez passer sous le contrôle d’une entreprise.

4- Après avoir tout lu précautionneusement, cliquez sur Continue.

5- La fenêtre suivante va permettre de spécifier le compte utilisateur Azure AD de l’entreprise ; on entre donc ici jtrevages@contosofrcloud.onmicrosoft.com et le mot de passe initialement attribué lors de la création du compte. Dans un scénario réel, ce mot de passe vous aura été transmis par l’administrateur dans le cadre de la procédure d’accueil.

6- Puis, on passe à l’étape suivante en cliquant sur le bouton Sign in.

7- S’agissant d’une première authentification, on demande à l’utilisateur de changer de mot de passe; remplissez les deux derniers champs avec le nouveau mot de passe que vous souhaitez attribuer à ce compte.

Ensuite, tout va très vite : un écran indiquant que l’enregistrement est en cours s’affiche avant de revenir sur l’écran initial.

Vous remarquerez que l’écran SYSTEM\About a été modifié et indique désormais un champ Organisation suivi d’un GUID (ici 2d041aa…), identifiant unique de votre annuaire Azure AD. De plus, l’option « Connect to cloud » a été remplacée par « Leave the organisation ». Votre appareil a donc bien rejoint le domaine Azure AD !

6- Ouverture de session avec le compte Azure

Vous êtes toujours dans la session ouverte sous votre compte personnel Microsoft, mais vous devrez être maintenant en mesure d’utiliser votre compte d’entreprise.

1- Fermez la session en cours sous votre compte Microsoft (ex. jtrevages@hotmail.com)

2- Cliquez sur l’option Other user et entrez votre compte d’entreprise Azure AD (ici, jtrevages@contosofrcloud.onmicrosoft.com) et le mot de passe (le nouveau, celui que vous avez choisi à l’étape précédente); votre session Windows 10 doit s’ouvrir avec votre compte d’entreprise Azure AD.

Note : Après cette première authentification, vous n’aurez plus à entrer cette identité : elle vous sera proposée par défaut sur la mire d’authentification.

3- La session s’ouvre et s’agissant de la première fois, on va vous demander de choisir un code PIN. Ce code PIN est associé au nouveau mode d’authentification de Microsoft Passport et est lié à votre appareil ; il vous servira ultérieurement pour vous authentifier ou enregistrer un geste biométrique à travers Windows Hello. Entrez votre code PIN 2 fois avant de valider en appuyant sur OK.

Note : pour plus d’information sur Windows Hello et Passport, veuillez consulter les liens suivants Password-less Authentication with Microsoft Passport, Microsoft Passport overview et Making Windows 10 More Personal and More Secure with Windows Hello.

Vous êtes désormais dans une session ouverte sous le compte Azure AD de votre entreprise. Mais, pour vous en persuader,

4. lancez une ligne de commande cmd.exe et entrer « set logonserver » puis ensuite la commande « whoami» .

Vous remarquerez que la variable d’environnement LOGONSERVER indiquant le contrôleur de domaine ayant procédé à l’authentification de l’utilisateur est \\AzureAD et que l’utilisateur authentifié est azuread\jeansseytrevages.

7- Vérification de la jonction au domaine (portail d’administration)

Il est aussi possible de vérifier que l’appareil est bien enregistré dans le domaine Azure AD à travers le portail d’administration.

1- Connectez-vous sur le portail de gestion Azure https://manage.windowsazure.com/ et authentifiez-vous.

2- Dans le bandeau de gauche, cliquez sur l’onglet ACTIVE DIRECTORY pour afficher la liste des annuaires déjà créés.

3- Cliquez sur le lien de votre domaine dans le bandeau bleu (ex. Contoso France Cloud only) puis sur USERS.

4- Cliquez sur l’utilisateur pour lequel vous venez d’enregistrer l’appareil Windows 10 (Janssey Trevages) : l’onglet PROFILE s’affiche.

5- Cliquez sur l’onglet DEVICES et assurez-vous que la liste déroulante VIEW indique Registered devices.

Vous devez constater que le DISPLAY NAME indique le nom de la machine enregistrée et que le champ TRUST TYPE spécifie AAD Joined

Conclusion

En résumé, Windows 10 vous apporte la possibilité d’enregistrer l’appareil dans votre annuaire d’entreprise Azure Active Directory pour permettre aux utilisateurs d’ouvrir une session « dans le Cloud » et de bénéficier de l’ensemble des services associés: SSO, environnement de travail sur tous les appareils de l’utilisateur, accès au Store d’entreprise, intégration avec Office 365, etc. Associé à des outils de MDM, cette fonctionnalité ouvre de nouveaux scénarios pour les entreprises qui souhaitent s’appuyer pour tout ou partie sur une infrastructure décidemment orientée Cloud.

Cette fonctionnalité est désormais disponible sous forme d’un service dans le nuage sous le nom d’Azure Device Registration Service. Il était possible de tester ce service depuis déjà plusieurs semaines en Preview, mais il devrait passer très prochainement en GA (General Availability dans le jargon Microsoft).

Remerciements à Anthony Munoz pour son aide précieuse sur le sujet.

Annonce TechDays 2015 !

Pour voir en live une maquette complète mettant en œuvre une infrastructure hybride s’appuyant sur Azure Device Registration Service, venez assister à la session Active Directory + BYOD = tranquillité d'esprit, chiche ! (1ère Partie).

Vous verrez comment enregistrer un appareil à travers Azure Device Registration Service, comment il est possible de contrôler l’accès à Office 365 ou à une application interne publiée par Web Application Proxy en fonction de l’enregistrement. On vous expliquera également les différentes typologies et le fonctionnement de la synchronisation-arrière des objets Device de Azure AD vers l’Active Directory à demeure.

Cette maquette s’appuie sur le guide de mise en œuvre :

Step-by-Step Guide for On-premises Conditional Access using Azure Active Directory Device Registration Service, et en plus, elle tourne !

Pour comprendre comment AD FS permet de piloter l’authentification de l’appareil, de l’utilisateur, d’imposer si besoin une authentification multi-facteur, venez assister à la session suivante (Azure) Active Directory + BYOD = tranquillité d'esprit, chiche ! (2nde Partie).

Azure Device Registration: pour quoi faire ?

Dès lors qu’un appareil est enregistré dans Azure Active Directory, il apparait sous la forme d’un objet Device associé à un utilisateur, lui-même créé dans ce référentiel (voir plus loin). Il sera donc possible d’imposer, par exemple, pour l’accès à une application particulière, que l’utilisateur y accède depuis un appareil qui lui est associé. Ce scénario est particulièrement intéressant car l’appareil joue le rôle de second facteur d’authentification transparent: l’utilisateur ne peut accéder à l’application que s’il s’authentifie et que l’appareil depuis lequel il effectue la tentative est enregistré dans l’annuaire et associé à cet utilisateur.

A la date de ce billet, le contrôle d’accès conditionnel pour les applications Azure n’est pas encore disponible mais est annoncé pour le 1^er trimestre de cette année. Par contre, on peut déjà l’utiliser dans un scénario hybrideen s’appuyant sur un serveur AD FS à demeure. Sans révéler tous les détails de l’affaire, l’objet Device est synchronisé depuis Azure AD vers l’AD on-premises par l’outil pré-packagé Dirsync, et c’est le serveur AD FS qui s’appuiera sur l’existence de l’enregistrement du device dans AD pour émettre ou non un jeton d’accès à l’application.

De fait, d’un point de vue contrôle d’accès, on revient exactement sur le cas de figure décrit dans le billet BYOD : Le “Workplace Join” de Windows Server 2012 R2 : Partie 2 (Vue du côté Active Directory)déjà référencé en début de ce billet.

L’autre intérêt d’Azure Registration Service réside dans le fait que, dès lors que vous disposez d’un locataire (tenant) Azure, il vous est possible d’activer ce service d’enregistrement sans avoir à déployer une infrastructure à demeure.

Quels appareils sont concernés ?

Dans un monde de mobilité, la plateforme Windows n’est pas la seule représentée : initialement, la jonction au Lieu de travail n’était disponible que pour Windows 8/8.1, Windows RT 8/8.1 et pour iOS. En février 2014, Samsung annonçait son support pour ses modèles de smartphones équipés de la solution logicielle Knox. Référez-vous au lien Samsung Knox enabled devices get Microsoft Workplace Join support.

En mars 2014, le support de Windows 7 était ajouté, bien que réservé aux postes joints à un domaine Active Directory (même s’il peut sembler au départ étonnant de cumuler ces deux possibilités). Voir le lien Workplace Join for Windows 7.

Plus récemment, l’application Azure Authenticator apporte sur les appareils Android la fonction d’authentification multi-facteur, mais aussi la possibilité d’ajouter un « Work account », ce qui permet d’enregistrer l’appareil dans AD/Azure AD à travers le mécanisme de « Workplace Join ». Consultez le billet Azure AD Workplace Join, now with Android Support!.

Comment activer la fonctionnalité Azure Device Registration Service ?

La première étape consiste à activer le service au niveau du locataire Azure:

• Connectez-vous sur le portail d’administration Azure https://manage.windowsazure.com/
• Sélectionnez dans le bandeau de gauche Active Directory, cliquez sur le domaine concerné (par exemple contoso-fr.onmicrosoft.com), puis sur l’onglet Configure. (Cliquez sur l’image pour agrandir).

• Dans la partie Device Registration, il vous suffit d’activer la fonctionnalité Enable Workplace Join en cliquant sur le côté YES de l’interrupteur.

Vous remarquerez qu’il est possible de spécifier le nombre maximum d’appareils qu’un même utilisateur peut enregistrer, et d’imposer l’utilisation de l’authentification multi-facteur intégrée dans Azure pour l’enregistrement de l’appareil, ce que l’on peut considérer comme une bonne pratique.

Joindre un appareil à l’espace de travail

L’expérience utilisateur pour joindre l’appareil au Lieu de travail à travers le service Azure Device Registration est identique à celle que l’on peut avoir avec le service d’enregistrement DRS à demeure, sauf que l’identité de l’utilisateur doit maintenant exister dans Azure AD (au lieu d’Active Directory).

Pour corser un peu, on a tenté l’exercice avec le dernier Build (9879) de la version Preview 1 de Windows 10. Il suffit d’aller dans Change PC Settings\Networks puis de choisir WorkPlace. On spécifie dans le champ User ID, l’identité qui sera associée à ce périphérique sous la forme de l’adresse email (UPN), par exemple janets@contoso-fr.com, puis on pousse sur le bouton Join.

L’écran suivant vous demandera les informations d’authentification de l’utilisateur: entrez l’identité de l’utilisateur telle qu’elle existe dans Azure AD (janets@contoso-fr.com) et le mot de passe associé.

Pour renforcer l’authentification lors de l’enregistrement de l’appareil, on a sélectionné d’imposer un 2^ème facteur d’authentification. L’écran suivant va s’afficher vous informant qu’un appel téléphonique va être adressé sur votre numéro de téléphone, celui que vous n’aurez pas oublié de renseigner dans votre compte Azure AD. Appuyez sur Continue dès que vous êtes prêt à recevoir l’appel. Répondez à l’appel et validez en appuyant sur la touche #du téléphone.

Une fois cette étape franchie, votre appareil est enregistré dans Azure Active Directory et associé à l’identité. Vous en avez la confirmation par l’affichage, au-dessus du bouton Leave, du message “’This device has joined your workplace network”.

Voir l’appareil enregistré dans Azure AD

Vous allez pouvoir vérifier que l’appareil est bien enregistré dans Azure AD.

• Connectez-vous sur le portail d’administration Azure https://manage.windowsazure.com/
• Sélectionnez dans le bandeau de gauche Active Directory, et cliquez sur le domaine concerné.
• Cliquer sur l’onglet USERS pour afficher la liste des utilisateurs du domaine puis sur l’utilisateur pour le compte duquel a été enregistré l’appareil (ici Janet Schorr).
• Sélectionnez l’onglet DEVICES et vérifiez que, dans le champ VIEW, est choisi Registered devices ; vous voyez apparaître la liste des appareils enregistrés pour l’utilisateur.

Pour finir

Le service Azure Device Registration n’est qu’un élément dans l’offre Microsoft concernant la prise en compte de la mobilité, mais il s’associe naturellement avec le service de fédération AD FS pour renforcer le contrôle d’accès conditionnel aux services et applications dans le Cloud et à demeure. Il augmente de plus le niveau de sécurité en ajoutant un facteur d’authentification supplémentaire: l’appareil de l’utilisateur.

Si le sujet vous intéresse, inscrivez-vous aux TechDays 2015 (c’est gratuit) et venez assister aux sessions citées en début du billet.

Dans ce billet, nous allons procéder à l’installation de la machine virtuelle DC1 créée précédemment, et qui va héberger plusieurs rôles : contrôleur de domaine de votre forêt Active Directory, service d’infrastructure à clés publiques pour délivrer les certificats pour l’ensemble de la maquette, service de fédération pour assurer l’authentification de l’application Web exemple, et enfin service d’enregistrement pour les appareils souhaitant joindre le Lieu de travail (Workplace Join).

Démarrage des machines

Si vous avez été jusqu’à la fin du précédent billet, vous avez compris l’intérêt d’arrêter complètement les VM pour optimiser les euros de votre crédit Azure. Il va donc falloir redémarrer les VM au fur et à mesure ; inutile de démarrer une machine sur laquelle vous n’intervenez pas et qui n’est pas nécessaire. Nous allons commencer par mettre en place le contrôleur de domaine DC1.

Choix du nom de domaine Active Directory

Avant de se lancer à corps perdu dans les lignes de commande PowerShell, vous devez vous poser la question du nom de domaine que vous allez choisir. Par souci de simplification, pour la gestion des certificats mais aussi pour éviter les erreurs, le nom de domaine interne est le même que le nom de domaine affiché à l’extérieur. Si vous souhaitez facilement joindre votre infrastructure depuis l’internet, je vous recommande d’enregistrer votre propre nom de domaine ; il vous en coûtera une dizaine d’euros par an mais vous n’aurez plus à vous souciez de la résolution de noms quel que soit l’appareil.

Dans la suite, on utilisera comme nom de domaine exemple contoso-corporation.com. Sachant que ce nom est déjà réservé, vous devrez le substituer avec le nom de domaine que vous aurez choisi.

Note : Dans le cas d’une maquette éphémère, vous pouvez économiser l’enregistrement du nom de domaine mais devrez intervenir sur le fichier host des machines clientes.

Certificats

La manipulation des certificats est inhérente à la mise en place d’une infrastructure s’appuyant sur des liaisons sécurisées entre les composants – serveur de fédération et application fédérée – et mettant à disposition des ressources à l’extérieur accessibles en https – publication à travers une passerelle qui doit présenter le certificat de la ressource publiée tout en possédant la clé privée associée – . Dans le cadre de cette maquette, on a choisi d’installer une autorité de certification interne qui permettra de délivrer les certificats nécessaires mais au prix de plus de manipulations ; l’obtention de certificats auprès d’un fournisseur reconnu peut s’avérer assez vite prohibitif surtout si l’on souhaite spécifier plusieurs noms DNS dans le champ SAN.

Avant de rentrer dans le vif du sujet, veuillez noter que toutes les actions sont réalisées sur la seule machine virtuelle DC1.

Etape 1 - Installation de la fonction contrôleur de domaine et création du domaine

1- Installation de la fonctionnalité de contrôleur de domaine

1- Démarrer la VM DC1: dans le portail de gestion Azure, dans le bandeau de gauche, sélectionnez MACHINES VIRTUELLES, cliquez sur DC1 puis TABLEAU DE BORD et appuyez sur le bouton DEMARRER dans le bandeau inférieur.

2- Attendez que la machine démarre et vérifiez dans le tableau de bord de la machine dans le bandeau à droite, que le champ ADRESSE IP INTERNE est bien à 10.0.0.4

3- Connectez-vous en RDP en vous authentifiant avec le compte d’administration et le mot de passe que vous avez spécifiés lors de la création de la VM.

4- Dans la VM DC1, ouvrez PowerShell en appuyant sur le bouton et entrer la ligne de commande suivante pour installer la fonctionnalité de DC

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

2- Création de la forêt contoso-corporation

Vous allez ensuite créer une forêt Active Directory mono-domaine qui constituera votre infrastructure de base avec l’annuaire des utilisateurs et qui servira également de base d’authentification pour l’accès aux services et applications que vous serez amenés à déployer.

1- Dans PowerShell, entrer la ligne de commande suivante en substituant contoso-corporation.com par votre nom de domaine Active Directory et CONTOSO-CORP par le nom Netbios (Ignorer les avertissements sur l'IPV4 non statique).

Install-ADDSForest -DomainName contoso-corporation.com -DomainNetbiosName CONTOSO-CORP -NoRebootOnCompletion:$True

2- Entrez le mot de passe de récupération 2 fois puis validez avec Y.

L’option pour ne pas rebooter a été positionnée pour vérifier les éventuels avertissements.

3- Après vérification, lancer ligne de commande PowerShell pour redémarrer

Restart-Computer

3- Paramétrage du DNS

Maintenant que le service DNS est installé sur DC1, il est nécessaire de spécifier au niveau du réseau virtuel que ce service doit être utilisé en remplacement du DNS fourni dans Windows Azure ; en effet, ce dernier n’est pas capable d’assurer les fonctions qui sont attendues pour un domaine Active Directory, comme par exemple le support de l’enregistrement dynamique des enregistrements SRV.

Voir “IP addressing and DNS” dans le document de référence, Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines.

Le paramétrage s’effectue au niveau du réseau virtuel :

1. Dans le portail de management Azure, aller sur RESEAUX\RESEAUX VIRTUELS\, cliquer sur VN-CONTOSO puis sur CONFIGURER

2. En-dessous de « serveur dns », entrer dc1.contoso-corporation.com, 10.0.0.4

3. Enregistrez la modification en appuyant sur la disquette ENREGISTRER dans le bandeau inférieur.

Note : Changez contoso-corporation.com par votre nom de domaine mais conservez 10.0.0.4 comme adresse IP qui doit être celle de la VM DC1.

Etape 2 - Installation d’AD Certificate Services

L’installation du service AD CS va nous servir à produire les certificats nécessaires pour permettre aux clients externes d’accéder au service de fédération AD FS depuis internet à travers Web Application Proxy, et d’établir la connexion avec l’application Web hébergée sur le serveur WEBAPP.

1- Installation de la fonctionnalité AD Certificate Services

1. Connectez-vous en RDP sur DC1 et lancer PowerShell.

2. Entrez la ligne de commande suivante pour installer la fonctionnalité AD CS :

Install-WindowsFeature AD-Certificate -IncludeManagementTools

Pour plus d’information voir la description de la cmdlet Install-WindowsFeature.

2- Installation de l’Autorité de Certification

On installe ensuite l’autorité de certification avec les paramètres par défaut.

3. Toujours dans PowerShell, entrer la ligne de commande :

Install-ADCSCertificationAuthority et confirmez avec Y.

Pour plus d’information voir la description de la cmdlet Install-AdcsCertificationAuthority.

3- Paramétrage de la CRL

De manière à simplifier l’infrastructure et éviter d’avoir à publier la liste de révocation (CRL) à l’extérieur, nous allons paramétrer l’autorité de certification pour ne pas inclure de référence à un point de distribution de CRL (CRL distribution Point ou CDP) dans les certificats qui seront émis.

1. Dans Server Manager/Tools, sélectionnez Certification Authority.

2. Faites un clic-droit sur l’autorité de certification et choisissez Properties.

3. Dans l’onglet Extensions, sélectionnez la ligne ldap://CN=<CATruncatedName><CRLNameSuffix>…

4. Décochez l’option « Include in the CDP extension of issued certificates » et validez en appuyant sur OK. Validez pour le redémarrage du service.

Note : Remarquez que, par défaut, la CRL n'est pas publiée en http:// et file://

4- Création d’un gabarit de certificat

Le gabarit de certificat nommé « Web Server » est celui que l’on utilise classiquement pour demander un certificat. C’est parfait lorsque le certificat doit être installé sur le serveur qui en fait la demande. Par contre, si le certificat et sa clé privée doivent être exportés pour être utilisés, comme dans notre cas, sur une passerelle, le gabarit Web Server n’est pas adapté car il ne permet pas d’exporter la clé privée.

Basé sur ce gabarit de certificat, on va créer un nouveau gabarit que l’on nommera ADFSWebServer, qui présentera les mêmes caractéristiques que le gabarit initial mais avec la possibilité d’exporter la clé privée.

1- Dans la console Certification Authority, allez sur Certificate Templates, puis clic-droit et sélectionnez Manage : la mmc certificate templates s’ouvre.

2- Sélectionner le gabarit Web Server et faites un clic-droit pour choisir Duplicate Template.

3- Dans l’onglet Request Handling, cochez l’option « Allow private key to be exported » et validez.

4- Renommer “Copy of Web Server” en ADFSWebServer (clic-droit et Change Names)

Maintenant que le nouveau gabarit est créé, il faut lui attribuer les permissions nécessaires pour qu’il soit accessible depuis un contrôleur de domaine (DC1 sur lequel sera installé AD FS) et depuis les machines du domaine (le serveur WEBAPP qui utilisera également ce gabarit).

1. Double-cliquez sur le gabarit de certificat ADFSWebServer pour accéder aux propriétés
2. Dans l’onglet Security, ajoutez le groupe Domain Controllers et lui donner les permissions Read et Enroll.
3. Puis ajoutez également Domain Computers en donnant aussi les permissions Read et Enroll.
4. Validez et fermez la console Certificate Templates.

Enfin, pour pouvoir utiliser ce gabarit de certificat, il faut l’autoriser :

9. Dans la console Certificate Authority, clic-droit sur Certificate Templates et sélectionnez New\Certificate Template to Issue.

10. Sélectionnez le nouveau gabarit ADFSWebServer et confirmer en appuyant sur OK.

Etape 3 - Installation des prérequis du service de fédération

1- Création du compte de service pour AD FS

Le service AD FS s’exécute sous un nouveau type de compte de service : un compte de service administré de groupe (Group Managed Service Account). Avant de pouvoir créer ce type de compte de service, il est nécessaire d’activer préalablement le Key Distribution Service.

1. En ligne de commande PowerShell, entrez :

Add-KdsRootKey –EffectiveTime (Get-Date).AddHours(-10)

2. Puis créez le compte de service avec la ligne de commande suivante en n’oubliant pas de remplacer contoso-corporation.com par le nom de votre domaine :

New-ADServiceAccount FsGmsa -DNSHostName adfs.contoso-corporation.com -ServicePrincipalNames http/adfs.contoso-corporation.com

Pour plus d’information sur le KDS, voir Create the Key Distribution Services KDS Root Key.

Pour plonger dans les comptes de service administrés de groupe, référez-vous à Getting Started with Group Managed Service Accounts.

2- Création des enregistrements DNS

Le service AD FS va être installé sur le contrôleur de domaine DC1. Deux services sont mis à disposition : le service AD FS lui-même plus le service d’enregistrement chargé de la jonction au Lieu de travail et qui doit être accessible en enterpriseregistration.contoso-corporation.com.

On va donc créer deux alias DNS qui vont pointer sur DC1 qui héberge ces deux services.

1. En ligne de commande PowerShell, entrez en remplaçant contoso-corporation.com par le nom de votre domaine :

Add-DnsServerResourceRecord -ZoneName "contoso-corporation.com" -A -Name "adfs" -IPv4Address "10.0.0.4"

[Ajustement: La ligne de commande a été modifiée pour un enregistrement DNS adfs.contoso-corporation.com en A plutôt que CNAME. La maquette était fonctionnelle sans cette modification]

2. Puis, pour la création du 2ème ALIAS,

Add-DnsServerResourceRecord -CName -Name "enterpriseregistration" -HostNameAlias "dc1.contoso-corporation.com" -ZoneName "contoso-corporation.com"

3- Tirage du certificat pour AD FS

Enfin, nous allons utiliser le gabarit de certificat tout juste créé pour demander à notre Autorité de Certification de produire le certificat qui va servir au service de fédération AD FS, et le stocker dans le magasin des certificats machine.

1. En ligne de commande PowerShell, entrez en remplaçant contoso-corporation.com par le nom de votre domaine

Get-Certificate -Template ADFSWebServer -DnsName adfs.contoso-corporation.com,enterpriseregistration.contoso-corporation.com -SubjectName CN=adfs.contoso-corporation.com -CertStoreLocation cert:\LocalMachine\My

Etape 4 - Installation du service de fédération AD FS

Maintenant, tout est prêt pour installer le service de fédération.

1- Installation de la fonctionnalité AD Federation Services

1. Dans la console PowerShell, entrez la ligne de commande suivante pour installer la fonctionnalité de AD FS

Install-WindowsFeature ADFS-Federation

2- Installation du service AD Federation Services

Il faut d’abord récupérer l’empreinte du certificat (thumbprint)

1. Dans la console PowerShell, entrez cd cert:\localmachine\my, puis Dir ; vous avez en 1^ère colonne les empreintes de certificats et, en 2^ème colonne, le CN du certificat associé.

2. Copier l’empreinte du certificat correspondant à CN=adfs.contoso-corporation.com (dans l’exemple FF8F5CFD…)

3. Puis dans la ligne de commande suivante :

• Insérez l’empreinte entre les 2 caractères " derrière le paramètre CertificateThumbprint,
• Remplacez le nom du service de fédération Contoso Corporation par le nom qui vous convient (il s’agit juste d’un nom d’affichage),
• Remplacer contoso-corporation par le nom long de votre domaine, et CONTOSO-CORP par le nom Netbios de ce même domaine.

    

Install-AdfsFarm -CertificateThumbprint:"FF8F5CFD…" -FederationServiceDisplayName:"Contoso Corporation"-FederationServiceName:"adfs.contoso-corporation.com" -GroupServiceAccountIdentifier:"CONTOSO-CORP\FsGmsa$"

Vous pouvez ignorer l’avertissement sur la réplication de la clé du compte de service qui vous recommande d’attendre 10h ( !) pour qu’elle soit disponible sur l’ensemble de la forêt.

Note : J’ai volontairement tronqué l’empreinte exemple FF8F5CFD… pour que les plus inattentifs n’aient pas la tentation de conserver l’empreinte exemple, et de s’offusquer ensuite que la commande d’installation du service AD FS remonte systématiquement une erreur ;-)

Etape 5 - Activation du service d’enregistrement

Le service d’enregistrement est porté par AD FS : c’est lui qui implémente la jonction au Lieu de travail. Il faut l’initialiser et l’activer pour le rendre opérationnel.

1. Dans la console PowerShell, entrez la ligne de commande suivante pour installer la fonctionnalité d’enregistrement des appareils

Initialize-ADDeviceRegistration

2. Sur sollicitation, entrez le compte de service CONTOSO-CORP\fsgmsa$ (en remplaçant CONTOSO-CORP par le nom court de votre domaine) et validez avec Y.

3. Entrez ensuite la ligne de commande

Enable-AdfsDeviceRegistration

         4. Pour activer la prise en compte des appareils enregistrés au niveau d'AD FS, dans la console de gestion AD FS, naviguez jusqu'à Authentication Policies puis cliquez sur le lien Edit Global Primary Authentication dans le panneau droit.

         5.  Sélectionnez la case à cocher Enable Device Authentication et validez avec OK.

Note : Ne pas oublier cette dernière étape, sinon les revendications liées aux appareils (de type devicecontext) ne seront pas inclues dans le jeton SAML et ne pourront pas ensuite être utilisées comme critères d'accès.

Etape 6 - Arrêt de la VM

Si vous ne souhaitez pas continuer sur le billet suivant, n’oubliez pas d’arrêter la VM y compris à travers le portail de gestion pour ne plus consommer votre crédit Azure. Voir dans le billet précédent,  Etape 3 : Extinction de la maquette !

Récapitulons

Cette 2^ème étape de construction était un peu longue, bien que l’on se soit appuyé sur PowerShell pour une bonne partie des opérations. Mais au final, nous avons bâti une forêt, installé une PKI, défini un gabarit de certificat que nous avons immédiatement utilisé pour installer le service de fédération AD FS qui est au cœur du fonctionnement de notre maquette. Et pour finir, nous avons activé le service d’enregistrement qui nous permettra, plus tard, de tester la jonction au Lieu de travail.

Dans le prochain billet, nous nous intéresserons à la mise en place de l’application Web de test, avant de paramétrer AD FS pour ensuite accéder l’application Web fédérée depuis l’interne.

La maquette est fonctionnelle pour démontrer la jonction au Lieu de travail (le Workplace Join décrit dans le billet précédent BYOD : Le “Workplace Join” de Windows Server 2012 R2) à partir d’un poste Windows 8.1, d’une tablette Windows RT 8.1 ou d’un iPad, mais nous allons d’abord nous intéresser à une fonction de sécurité supplémentaire : l’authentification multifacteur.

Cette fonction est disponible sous la forme d’un service Cloud, Windows Azure Multi-factor Authentication (ou Azure MFA en plus court) qui permet de s’appuyer sur le couple identifiant-mot de passe de l’utilisateur en y ajoutant un facteur d’authentification supplémentaire : la preuve de possession d’un appareil mobile associé à l’utilisateur. Pour accéder à l’application, l’utilisateur doit d’abord entrer son identifiant et son mot de passe ; on lui signifiera alors qu’il doit passer par une étape supplémentaire consistant à valider un appel qu’il va recevoir sur son téléphone mobile. Il y a plusieurs possibilités mais la plus simple consiste à acquitter l’appel par appui sur la touche #. C’est uniquement après cette 2^èmeétape de vérification qu’il se verra accordé l’accès à l’application.

D’un point de vue sécurité, on voit bien l’intérêt : en cas de vol de l’identifiant et du mot de passe de l’utilisateur, la personne malveillante qui cherchera à accéder à l’application se trouvera bloquée. Pour pouvoir avoir accès à l’application, elle devrait en plus être en possession du téléphone mobile de l’utilisateur (lui avoir subtilisé) et avoir la connaissance du code PIN permettant de débloquer le téléphone. On voit que les critères d’accès deviennent plus compliqués pour l’attaquant, et la fenêtre d’utilisation des informations d’authentification assez courte car l’utilisateur risque de s’apercevoir assez rapidement du vol de son téléphone mobile. De plus, si l’attaquant tente (bêtement) de franchir la deuxième barrière, l’utilisateur recevra un appel lui signalant une tentative d’accès frauduleuse et, par là même, la compromission de son identifiant et mot de passe.

Dans ce billet, nous allons mettre en place les composants nécessaires pour faire qu’un utilisateur accédant à l’application WebApp doive prouver qu’il possède le téléphone mobile associé à son identité.

Pour rappel, avant de vous lancer dans les étapes ci-dessous, vous devez d’abord avoir suivi les premières étapes de construction de la maquette décrites dans les 4 précédents billets :

• BYOD : Construction d’une maquette Azure IaaS Partie 1
• BYOD : Construction d’une maquette Azure IaaS Partie 2
• BYOD : Construction d’une maquette Azure IaaS Partie 3
• BYOD : Construction d’une maquette Azure IaaS Partie 4

Si vous êtes intéressés par les différentes déclinaisons de Azure MFA, consultez le billet de mon collègue Arnaud Lheureux Authentification multi facteurs avec Windows Azure Multi-Factor Authentication – partie 2. La série de billets sur MFA proposée est beaucoup plus ambitieuse. Je me contenterai dans le cadre de cette maquette d’utiliser Azure MFA uniquement en tant que fournisseur d’authentification supplémentaire associé au service AD FS. Pour une présentation approfondie de l’authentification multifacteur, référez-vous au lien Windows Azure Multi-Factor Authentication.

Voir également l’article  Walkthrough Guide: Manage Risk with Additional Multi-Factor Authentication for Sensitive Applicationsqui décrit les étapes de mise en œuvre.

Remerciements à mon autre collègue Arnaud Jumelet pour avoir pris la peine de revalider la partie installation du composant MFA Server.

Etape 1 - Démarrage des VM

1- Démarrage des machines virtuelles

Si vous vous rappelez de la dernière étape du billet BYOD : Construction d’une maquette Azure IaaS Partie 1, vous avez compris l’intérêt d’arrêter complètement les VM pour optimiser les euros de votre crédit Azure. Si vous avez éteint les VM à travers le portail de gestion Azure, vous devrez démarrer DANS L’ORDREla machine DC1 puis ensuite WEBAPP et WAP, ces 2 dernières dans n’importe quel ordre.

1. Pour démarrer la VM DC1, dans le portail, dans le bandeau de gauche, sélectionnez MACHINES VIRTUELLES, cliquez sur DC1 puis TABLEAU DE BORD et appuyez sur le bouton DEMARRER dans le bandeau inférieur.
2. Attendez que la machine démarre et vérifiez dans le tableau de bord de la machine dans le bandeau à droite, que le champ ADRESSE IP INTERNE est bien à 10.0.0.4
3. Répétez l’opération 1 avec la VM WEBAPP et la VM WAP.

POINT IMPORTANT : Rappelez-vous que l’accès aux VM depuis l’extérieur se fait par le biais d’une adresse virtuelle (VIP) qui va rester attribuée tant qu’une VM reste allouée dans le Cloud Service. La VM la plus critique de notre maquette est DC1 qui porte l’ensemble des services d’infrastructure dont le service DNS. Pour éviter de se voir réattribuer systématiquement une nouvelle VIP et donc d’avoir à systématiquement mettre à jour les fichiers host ou les enregistrements dans le service DNS de votre provider, je vous conseille de conserver la VM DC1 allumée.

Pour les deux autres machines WAP et WEBAPP, vous pouvez soit les éteindre sans oublier de les désallouer, soit passer sur une modèle de machine « Très petite », plus économique et qui se révèle suffisant vu la très faible sollicitation de ces deux VM.

2- Ajustement de la taille des VM (Optionnel)

Si vous souhaitez ajuster la taille des VM WAP et WEBAPP, cette modification peut heureusement se faire sans avoir à réinstaller.

Par exemple, si vous souhaitez passer la VM WAP d’un modèle « Petite » à « Très petite » :

1. Connectez-vous en RDP sur la VM WAP et arrêtez-la.
2. Depuis le portail de gestion Azure, allez sur MACHINES VIRTUELLES puis sélectionnez la VM WAP, puis CONFIGURER.
3. Dans TAILLE DE LA MACHINE VIRTUELLE, choisir dans le menu déroulant « Très petite (Cœur partagé, 768 Mo de mémoire) », puis appuyez sur l’icône de la disquette ENREGISTRER.
4. Confirmez en cliquant sur la case OUI.
5. Après quelques instants, vous pouvez redémarrer la VM depuis le portail de gestion Azure.

Etape 2 - Création du Fournisseur d’authentification multifacteur

Avant de pouvoir utiliser le service MFA, il est nécessaire de passer par la création d’un fournisseur d’authentification multifacteur. L’utilisation du service MFA n’est pas gratuite mais le coût sera pris sur le crédit qui nous est alloué dans le cadre de la souscription. Pour un utilisateur de démonstration, le coût est raisonnable (1,49 € à la date de rédaction du billet), d’autant que l’on se contentera d’une activation pour un seul utilisateur.

1. Dans le portail de gestion Azure, cliquez sur le bouton + NOUVEAU, puis SERVICE D’APPLICATION, ACTIVE DIRECTORY, FOURNISSEUR D’AUTHENTIFICATION MULTIFACTEUR, et CREATION RAPIDE.
2. Choisissez un nom, par exemple BYOD-MFA, puis le modèle d’utilisation « Par utilisateur activé ».
3. Choisir dans notre cas de ne pas lier à un annuaire, puis appuyez sur la case CREER.

Note : Le modèle d’utilisation est soit « Par utilisateur activé» soit « Par authentification ». Dans le premier cas, pour un coût mensuel fixe (1,49€ à date), vous disposez d’un nombre illimité d’authentifications pour cet utilisateur, soit dans le 2^ème cas, vous payez (également 1,49€) par ensemble de 10 authentifications quel que soit le nombre d’utilisateurs. Voir Tarification de l'authentification multifacteur.

Etape 3 - Téléchargement du composant Multi-Factor Authentication Server

Le composant Multi-Factor Authentication Server doit être installé sur le serveur DC1 hébergeant le service AD FS pour lui mettre à disposition le fournisseur d’authentification multifacteur. C’est lui qui se charge de communiquer avec le Service en ligne Azure MFA assurant la fonction d’appel téléphonique, puis de récupérer en retour l’acquittement (ou le refus).

Pour installer le composant sur la VM DC1, le plus simple est de le télécharger directement depuis cette machine.

1- Prérequis de résolution DNS

Pour accéder au portail depuis la VM DC1, vérifiez que la résolution de noms DNS pour l’externe passe bien uniquement par les root hints.

1. Connectez-vous en RDP sur DC1.
2. Ouvrez Server Manager, puis Tools et DNS pour lancer la console de gestion DNS.
3. Faites un clic droit sur DC1, puis Properties et allez sur l’onglet Forwarders.
4. Si vous voyez figurer un Forwarder, supprimez-le.

2- Téléchargement depuis le portail de gestion Azure

1. Connectez-vous en RDP sur DC1.
2. Cliquez sur le bouton Start pour aller à l’écran d’accueil et entrez iexplore puis validez.
3. Entrez l’URL https://manage.windowsazure.com/ et authentifiez-vous avec votre compte Azure.
4. Naviguez vers ACTIVE DIRECTORY, FOURNISSEURS D’AUTHENTIFICATION MULTIFACTEUR, puis sélectionnez GERER.

    5.    Vous êtes redirigés vers le portail Windows Azure MFA. Cliquez sur téléchargement.

    6.    Dans l’écran suivant Téléchargements Serveur, cliquez sur le lien télécharger et sauvegarder le fichier Multifactorauthenticationserversetup.exesur le bureau.

    7.    Cliquez sur le bouton Générer des informations d’identification d’activation : un email et un mot de passe sont automatiquement générés et devront être utilisés plus tard dans la procédure d’installation. Laissez l’écran ouvert. Vous avez un délai de 10 minutes avant d’arriver à l’écran de demande d’activation, sinon vous devrez demander de nouvelles informations d’identification.

Etape 4 - Installation du composant MFA Server

1- Installation du Framework .NET

Le .NET framework version 2.0.50727 doit être préalablement installé avant le lancement du programme d’installation du composant Multi-Factor Authentication Server.

1. Ouvrez une console PowerShell et lancer la commande suivante :

Install-WindowsFeature NET-Framework-Core

L’installation prendra quelques minutes (en fait moins de 10).

2- Installation et activation

Le composant MFA Server peut désormais être installé et activé en utilisant les informations d’identification fournies précédemment depuis le portail, à l’écran de téléchargement.

1. Lancer l’assistant d’installation de MFA Server en exécutant le fichier MultiFactorAuthenticationServersetup.exe précédemment téléchargé.
2. Cliquez sur Next puis en fin d’installation (moins d’une minute), cliquez sur Finish.
3. L’assistant d’installation se lance automatiquement : Sélectionnez “Skip Using the Authentication Configuration Wizard” et cliquez sur Next.

      4.   Sur l’écran Activate, on vous demande une adresse email et un mot de passe : retournez sur l’écran de téléchargement pour récupérer ces informations d’authentification qui ont été fournies suite à l’appui sur le bouton Générer des informations d’identification d’activation et les recopier dans les champs Email et Password. Cliquez sur le bouton Activate. (Si vous avez laissé passé le délai, PAS DE PANIQUE : il vous suffit de retourner sur l’écran de téléchargement et de redemander de nouvelles informations d’authentification).

      5.   Sur le pop-up suivant, choisissez le Groupe par défaut et validez.

      6.   Sur le pop-up ci-dessous, qui vous invite à lancer le wizard de configuration Multi-Server, choisissez No.

      7.   L’installation est terminée et vous voyez s’afficher l’interface de gestion du composant MFA Server.

Etape 5 - Paramétrage du composant MFA Server

1- Import des comptes utilisateurs et test

Les utilisateurs qui sont concernés par l’authentification multifacteur doivent être importés dans la base de Windows Azure MFA.

1. Dans l’écran Multi-Factor Authentication Server, cliquez sur l’icône Users puis sur le bouton Import From Active Directory.
2. Dans l’onglet List, déployez l’arborescence jusqu’au conteneur Users, et sélectionnez l’utilisateur sur lequel vous voulez tester l’authentification MFA (dans mon cas jtrevages@contoso-corporation.com).
3. Cliquez sur Import, OK, puis Close pour fermer l’écran d’import.
4. Positionnez-vous sur l’utilisateur qui vient d’être importé (vous remarquerez un petit triangle orange /danger qui indique que l’utilisateur n’est pas actif) et cliquez sur Edit.
5. Dans la fenêtre Edit User, renseignez l’indicatif et le numéro de téléphone portable qui devra être appelé pour la seconde authentification. N’oubliez pas ensuite de vérifier que la case à cocher Enabled est bien cochée et cliquez sur Close.

      6.   Vous pouvez tester en sélectionnant l’utilisateur puis en appuyant sur le bouton Test. Après avoir fourni le mot de passe dans le pop-up Test User, cliquez sur le bouton Test. Vous allez recevoir un appel sur le téléphone portable vous demandant de valider en appuyant sur la touche #.

Note: On n’explore pas toutes les possibilités du produit et plus particulièrement la possibilité de synchronisation automatique avec l’Active Directory.

2- Intégration avec AD FS

Ce qui nous intéresse dans ce billet est la possibilité d’utiliser Windows Azure MFA comme fournisseur d’authentification supplémentaire pour AD FS, ce qui nous permettra de profiter de cette fonction pour toutes les applications ou services s’appuyant sur le service de fédération.

1. Dans l’écran Multi-Factor Authentication Server, cliquez sur l’icône AD FS et sélectionnez les cases à cocher Allow user enrollment, puis Phone call et Enable logging (voir ci-dessous).

      2.   Lancer l’installation en cliquant sur Install ADFS Adapteret suivez le wizard d’installation.

3- Enregistrement du server MFA dans AD FS

Pour enregistrer le service MFA comme fournisseur d’authentification auprès d’AD FS, on doit s’appuyer sur un script PowerShell.

1. Ouvrez une ligne de commande PowerShell et lancer le script Register-MultiFactorAuthenticationAdfsAdapter.ps1 depuis le répertoire C:\Program Files\Multi-Factor Authentication Server.

      2.   Il faut ensuite redémarrer les services AD FS et DRS en entrant en ligne de commande

net stop adfssrv & net start adfssrv & net start drs

4- Activation du fournisseur MFA dans AD FS

La dernière étape de la configuration consiste à activer le fournisseur MFA au niveau du service AD FS lui-même.

1. Ouvrez la console de gestion AD FS, et naviguez jusqu’à Authentications Policies et dans la section Multi-factor Authentication, Global Settings, cliquez sur le lien Edit.

      2.   Dans l’écran Edit Global Authentication Policy, cochez la case WindowsAzureMultiFactorAuthentication.

Désormais, l’authentification Azure MFA est disponible globalement au niveau du service AD FS !

Etape 6 – Activation de l’authentification MFA pour l’accès à ClaimApp

Cette ultime étape de configuration consiste à paramétrer l’utilisation de l’authentification MFA pour l’accès à l’application de test ClaimApp.

Jusqu’à maintenant, tout utilisateur capable de s’authentifier avait accès à l’application de test. On peut imposer dorénavant des critères supplémentaires pour l’accès à l’application en fonction de nouveaux scénarios. Par exemple on peut décider que pour les accès depuis l’extérieur de l’entreprise, les utilisateurs dont les appareils ne sont pas enregistrés au Lieu de travail (Workplace joined) se verront imposer une authentification supplémentaire MFA.

Pour implémenter ce scénario, rien de plus simple :

1. Ouvrez la console de gestion AD FS et naviguez jusqu’à Authentications Policies, Per Relying Party Trust et sélectionnez Claimapp.
2. Dans le panneau Actions à droite, cliquez sur le lien Edit Custom Multi-factor Authentication.
3. Dans le cadre Devices, cochez la case Unregistered devices.

Tout accès depuis un appareil non-enregistré imposera l’authentification multifacteur à l’utilisateur.

Note : L’interface ci-dessus permet de configurer très facilement des règles avec des critères simples (appartenance à un groupe, appareil enregistré ou non, accès Internet ou Intranet) ; il est possible d’aller plus loin dans la configuration des politiques d’authentification MFA en utilisant PowerShell pour définir des règles basées sur le langage de description propre à AD FS. Pour plus de précisions, reportez-vous à l’article Technet Active Directory Federation Services-Configuring Authentication Policies.

Etape 7 – Test de l’authentification MFA pour l’accès à ClaimApp

Vous allez pouvoir savourer le résultat de votre travail !

A partir de votre poste de travail (qui a été préparé à l’étape 7 du précédent billet BYOD : Construction d’une maquette Azure IaaS Partie 4avec l’import du certificat racine et résolution DNS)  :

1. Lancer Internet Explorer et entrez l’URL https://webapp.contoso-corporation.com/claimapp/ (sans oublier de modifier le nom de domaine).
2. Comme vous n’êtes pas authentifié, l’application va vous rediriger vers le serveur AD FS (publié à travers WAP) qui va afficher la page d’authentification ci-dessous

      3.   Entrez l’identifiant et le mot de passe du compte d’administration que vous avez défini (dans l’exemple jtrevages@contoso-corporation.com). L’écran suivant vous souhaite la bienvenue dans CONTOSO, signe que l’authentification a été réussie, mais, comme votre poste n’a pas été joint au Lieu de travail, on vous propose de continuer à la condition que vous ayez à disposition votre téléphone portable. Cliquez sur le bouton Continuer.

      4.   Vous allez recevoir un appel téléphonique avec un message vous invitant à appuyer sur la touche # de votre téléphone. Une fois cet appui effectué, vous serez redirigé immédiatement vers l’application de test Claimapp.

FELICITATIONS ! Vous êtes arrivé à l’objectif visé de mettre en place l’authentification multifacteur pour l’accès à l’application de test ClaimApp accessible depuis internet.

Récapitulons

Nous venons d’ajouter à notre maquette BYOD une fonction supplémentaire par l’intégration de Windows Azure Multi-factor Authentication ; cette fonctionnalité apporte, de manière simple, une protection supplémentaire sur la phase d’authentification de l’utilisateur en lui permettant d’utiliser son téléphone mobile comme facteur additionnel. Dans ce billet nous nous sommes focalisés sur son intégration avec le service de fédération AD FS, ce qui implique que les applications qui s’appuient sur ce service pourront bénéficier immédiatement de l’authentification multifacteur.

Nous n’avons pas été dans le détail des possibilités pour la définition des critères pouvant être pris en compte comme déclenchement de l’authentification MFA, mais il est possible de s’appuyer sur le langage de description AD FS pour s’adapter à des scénarios de contrôle d’accès plus complexes.

Enfin, dans un contexte BYOD où le renforcement de l’authentification est un véritable enjeu, ce billet aura pu vous donner un premier aperçu des possibilités de l’authentification multifacteur.

Le livre blanc "Bring Your Own Device (BYOD) : Vision sécurité et approche de solutions v2.0" est disponible en téléchargement. Comme son titre l’indique, ce document est en français.

Une première version de ce livre blanc a été publiée en mars 2013 mais, suite à l’intégration de nombreuses fonctionnalités nouvelles dans Windows Server 2012 R2, Windows 8/8.1, Windows RT dédiées à la mise en œuvre de scénarios BYOD, il a été décidé de mettre rapidement à disposition une version 2.0 du livre blanc pour intégrer ces éléments au sein de la partie « solutions » : il s’agit donc d’une version enrichie.

Pour les audiences moins versées sécurité, la deuxième partie du livre blanc peut être également intéressante car elle aborde de manière synthétique un ensemble de technologies disponibles au sein des plateformes Microsoft que ce soit On-Premises ou dans le Cloud; pour en citer quelques-unes : Active Directory Federation Services, Workplace Join (jonction au Lieu de travail), Windows Azure Multi-factor Authentication, File Classification Infrastructure , Microsoft Rights Management (Azure RMS), Windows Intune, Enterprise Mobile Management, etc.

Bonne lecture et n’hésitez pas à diffuser !

Dans ce billet, nous allons rendre accessible l’application ClaimApp depuis internet en la publiant à travers Web Application Proxy, service intégré dans la plateforme Windows Server 2012 R2 qui met à disposition les fonctions de proxy AD FS et de reverse-proxy simple pour les applications Web.

Si vous souhaitez creuser le sujet, référez-vous à l’article TechNet Web Application Proxy Overview.

Pour rappel, avant de vous lancer dans les étapes ci-dessous, vous devez d’abord avoir suivi les premières étapes de construction de la maquette décrites dans les 3 précédents billets :

• BYOD : Construction d’une maquette Azure IaaS Partie 1
• BYOD : Construction d’une maquette Azure IaaS Partie 2
• BYOD : Construction d’une maquette Azure IaaS Partie 3

Etape 1 - Démarrage des machines virtuelles

Si vous vous rappelez de l’étape 3 “Extinction de la maquette !” du billet BYOD : Construction d’une maquette Azure IaaS Partie 1, vous avez compris l’intérêt d’arrêter complètement les VM pour optimiser les euros de votre crédit Azure. Pour cette 4^ème partie, vous devrez démarrer DANS L’ORDREla machine DC1 puis ensuite WEBAPP et WAP, ces 2 dernières dans n’importe quel ordre.

1. Démarrer la VM DC1 : dans le portail, bandeau de gauche, sélectionnez MACHINES VIRTUELLES, cliquez sur DC1 puis TABLEAU DE BORD et appuyez sur le bouton DEMARRER dans le bandeau inférieur.
2. Attendez que la machine démarre et vérifiez dans le tableau de bord de la machine dans le bandeau à droite, que le champ ADRESSE IP INTERNE est bien à 10.0.0.4
3. Répétez l’opération 1 avec la VM WEBAPP et la VM WAP.

Etape 2 - Installation de Web Application Proxy

La commande PowerShell suivante va permettre d’installer la fonctionnalité Web Application Proxy sur la machine virtuelle WAP.

1. Connectez-vous en RDP sur la VM WAP.
2. Ouvrez la console PowerShell et entrer la ligne de commande suivante

Install-WindowsFeature Web-Application-Proxy –IncludeManagementTools

Etape 3 - Installation du certificat AD FS sur WAP

Web Application Proxy joue le rôle de passerelle AD FS pour l’extérieur. Il doit être capable de se faire passer pour le service AD FS interne et présenter un certificat lors d’une connexion https tout en prouvant qu’il possède la clé privée associée à ce certificat. C’est la raison pour laquelle, on doit exporter depuis le serveur AD FS, le certificat et sa clé privée pour les installer sur WAP.

1- Export du certificat ADFS

1. Connectez-vous en RDP sur la VM DC1 où est installé le service AD FS.

2. Il faut d’abord récupérer l’empreinte du certificat (thumbprint) ; dans la console PowerShell, entrez cd cert:\localmachine\my, puis Dir ; vous avez en 1^ère colonne les empreintes de certificats et en 2^ème colonne, le CN du certificat associé.

   
3. Copier l’empreinte du certificat correspondant à CN=adfs.contoso-corporation.com (dans l’exemple FF8F5CFD…).
4. Quitter PowerShell pour lancer CMD en ligne de commande (bouton Start maintenu et la touche R).
5. Entrez la ligne de commande suivante en remplaçant l’empreinte de l’exemple (FF8F5CFD…) par celle que vous venez de copier

certutil -exportPFX -p "Password" my ff8f5cfdd34123e34b36e01b27b13c94040e3fc6 c:\adfscontoso.pfx

2- Import du certificat ADFS sur la VM WAP

1. Connectez-vous en RDP sur la VM WAP
2. Utilisez le copier-coller entre VM pour récupérer le fichier adfscontoso.pfx depuis la VM DC1 pour le recopier sur la VM WAP sur la racine de C:\ adfscontoso.pfx
3. Ouvrez CMD.exe et entrez la ligne de commande suivante :

Certutil -p "Password" -importpfx my c:\adfscontoso.pfx

Notez que cette commande vous installe également le certificat racine de la PKI.

Etape 4 - Configuration de Web Application Proxy

Dans cette étape, vous allez configurer le service Web Application Proxy pour l’associer au service AD FS déployé sur la VM DC1. En effet, WAP est indissociable du service AD FS dont il utilise entre autre la base de données de configuration. Dans sa version actuelle, WAP utilise uniquement AD FS pour toute pré-authentification, AD FS fournissant de son côté les différentes possibilités d’authentification (mot de passe, certificat, MFA…).

1. Connectez-vous en RDP sur la VM WAP
2. Cliquez sur le bouton Start pour vous retrouver sur l’écran d’accueil, tapez Remote (Remote Access Management doit être automatiquement proposé) et validez.
3. Cliquez sur le lien Run the Web Application proxy Configuration Wizard.
4. Appuyez sur Next pour passer l’écran d’accueil. L’écran Federation Server s’affiche :

5. Entrez les paramètres suivants :

   • Federation service name : adfs.contoso-corporation.com (en changeant contoso-corporation.com par votre nom de domaine)
   • Username : le nom du compte d’administration
   • Password : le mot de passe du compte d’administration
6. Au niveau de l’écran AD FS Proxy Certificate, sélectionnez le certificat adfs.contoso-corporation.com que vous venez d’importer et qui doit apparaître dans la liste déroulante, et cliquez sur Next.
7. Dans l’écran Confirmation, vérifiez les paramètres d’installation (vous devez retrouver l’empreinte du certificat exporté dans l’étape Export du certificat ADFS), et lancer l’installation en appuyant sur le bouton Configure.
8. A la fin de l’installation, vérifiez que tout s’est passé correctement et terminez en appuyant sur Close.

Note : on pourrait utiliser la commande PowerShell Install-WebApplicationProxy, mais je vous ai réservé ce plaisir pour l’étape suivante.

Etape 5 - Publication de l’application ClaimApp

Maintenant que le service Web Application Proxy est fonctionnel et capable déjà d’assurer le rôle de reverse-proxy pour le service AD FS interne, on va l’utiliser pour publier l’application Claimapp et la rendre ainsi accessible depuis l’internet.

On va devoir effectuer la même manipulation d’export puis import du certificat que l’on a déjà réalisée pour AD FS mais en le faisant maintenant pour WEBAPP.

1- Export du certificat WEBAPP

1. Connectez-vous en RDP sur la VM WEBAPP où est installée l’application ClaimApp.
2. Il faut d’abord récupérer l’empreinte du certificat (thumbprint) ; dans la console PowerShell, entrez cd cert:\localmachine\my, puis Dir ; vous avez en 1^ère colonne les empreintes de certificats et en 2^ème colonne, le CN du certificat associé.
3. Copier l’empreinte du certificat correspondant à CN=webapp.contoso-corporation.com (dans l’exemple 217BB3495…).
4. Quitter PowerShell pour lancer CMD en ligne de commande (bouton Start maintenu et la touche R).
5. Entrez la ligne de commande suivante en remplaçant l’empreinte de l’exemple (217BB3495…) par celle que vous venez de copier

certutil -exportPFX -p "Password" my 217BB34957E9FAF5FCD641115DC37EAF34CCCC78 c:\webappcontoso.pfx

2- Import du certificat WEBAPP sur la VM WAP

1. Connectez-vous en RDP sur la VM WAP.
2. Utilisez le copier-coller entre VM pour récupérer le fichier webappcontoso.pfx depuis la VM DC1 pour le recopier sur la VM WAP sur la racine de C:\ webappcontoso.pfx.
3. Ouvrez CMD.exe et entrez la ligne de commande suivante :

Certutil -p "Password" -importpfx my c:\webappcontoso.pfx

Si vous jetez un œil au magasin des certificats machines (lancer certlm.msc), vous devriez vérifier que vous disposez de 4 certificats :

• Les 2 certificats que vous venez d’importer pour ADFS et WEBAPP,
• Le certificat en cloudapp.net qui vous permet d’établir la connexion RDP sur la machine,
• Un certificat ADFS Proxy Trust, auto-signé, généré automatiquement durant la configuration de WAP.

3 - Déclaration de l’application ClaimApp

Maintenant que le certificat associé à l’application ClaimApp est importé, il suffit de déclarer l’application de test ClaimApp en indiquant, les URL interne et externe, le certificat à utiliser et le type d’authentification ; dans le cas d’une authentification par ADFS, il suffit de spécifier le Relying Party tel qu’il est déclaré au niveau du service AD FS.

1. Ouvrez la console PowerShell et entrer la ligne de commande suivante en utilisant votre nom de domaine en remplacement de contoso-corporation.com et en remplaçant l’empreinte du certificat associé au paramètre ExternalCertificateThumbprint par celle du certificat que vous venez d’importer.

Add-WebApplicationProxyApplication -BackendServerURL 'https://webapp.contoso-corporation.com/claimapp/' -ExternalCertificateThumbprint '217BB34957E9FAF5FCD641115DC37EAF34CCCC78' -ExternalURL 'https://webapp.contoso-corporation.com/claimapp/' -Name 'Claims App' -ExternalPreAuthentication ADFS -ADFSRelyingPartyName 'claimapp'

Etape 6 -  Ajout d’un point de terminaison à WAP

Il suffit désormais de rendre visible WAP depuis l’extérieur en HTTPS en créant un point de terminaison HTTPS sur le port 443.

1. Connectez-vous au portail de gestion de Windows Azure (https://manage.windowsazure.com/).
2. Dans le portail de gestion, dans le bandeau de gauche, choisissez MACHINES VIRTUELLES, puis sélectionnez la machine virtuelle WAP et POINTS DE TERMINAISON.
3. En bas au milieu appuyez sur le + AJOUTER.
4. Conserver l’option par défaut Ajouter un point de terminaison autonome et passer à l’étape suivante en cliquant sur la flèche en bas à droite.
5. Dans NOM, sélectionnez HTTPS : les champs PROTOCOLE, PORT PUBLIC et PORT sont automatiquement remplis par les valeurs par défaut. Validez en appuyant sur la case à cocher en bas à droite.

Etape 7 -  Test d’accès à l’application ClaimApp depuis Internet

Nous y sommes presque ! La configuration de l’infrastructure est complètement terminée. Avant de pouvoir tester l’accès à l’application, il ne reste plus qu’à installer un certificat racine sur le poste qui va être utilisé pour les tests et à être capable de résoudre les noms du serveur ADFS et du serveur Web WEBAPP.

1- Export-Import du certificat racine de la PKI contoso-corporation

Effectuez l’export du certification racine de la PKI depuis DC1.

1. Connectez-vous en RDP sur la VM DC1.
2. Ouvrez CMD.exe et entrez la ligne de commande suivante :  certutil -ca.cert c:\contoso-root.cer
3. Utilisez le copier-coller entre VM pour récupérer le fichier contoso-root.cer depuis la VM DC1 pour le recopier sur votre poste sur la racine de C:\ contoso-root.cer.

Effectuez maintenant l’import depuis le poste de test.

1. Sur votre poste de test, pour ouvrir CMD.exe en tant qu’administrateur, appuyez sur le bouton Start pour aller sur l’accueil, puis tapez CMD, puis clic-droit sur l’icône et choisir Run as Administrator.
2. Entrez la ligne de commande suivante : certutil -addstore root C:\contoso-root.cer

2- Résolution de noms pour l’application et le service AD FS

Il faut d’abord récupérer l’adresse publique de la machine WAP qui correspond à sa VIP.

1. Connectez-vous au portail de gestion de Windows Azure (https://manage.windowsazure.com/).
2. Dans le portail de gestion, dans le bandeau de gauche, choisissez MACHINES VIRTUELLES, puis sélectionnez la machine virtuelle WAP et TABLEAU DE BORD : sous ADRESSE VIRTUELLE (VIP) PUBLIQUE, notez l’adresse IP V4 qui est attribuée à WAP.
3. Ajouter les 2 entrées suivantes dans le fichier host de votre poste (fichier situé dans le répertoire %windir%\system32\drivers\etc)

• <adresse IPV4 WAP> webapp.contoso-corporation.com
• <adresse IPV4 WAP> adfs.contoso-corporation.com

Un ping (sans réponse) sur adfs.contoso-corporation.com doit vous permettre de vérifier la résolution en vous indiquant l’adresse IPv4 de WAP.

Note: Si vous pouvez dépenser quelques euros pour réserver votre nom de domaine, il vous suffit de créer ces 2 enregistrements DNS à travers le portail de votre fournisseur. Ceci vous permet de rendre visible depuis l’internet les services mis à disposition de votre infrastructure Azure IaaS sans aucune manipulation sur l’appareil.

IMPORTANT : La maquette s’appuie sur un seul Cloud Service auquel sont rattachées les 3 machines virtuelles. L’adresse VIP reste attribuée au Cloud Service tant qu’il reste une VM non désallouée. Si vous souhaitez complètement éteindre la maquette, vous devrez, au rédémarrage, réactualiser l’adresse IPv4 de la nouvelle VIP dans le système de résolution de noms DNS utilisé. Par contre, si vous souhaitez conserver votre maquette fonctionnelle tout en minimisant la consommation, je vous recommande de conserver allumé le serveur DC1 qui tient la plus grande partie des services d’infrastructureet d’éteindre le serveur Web WEBAPP et la passerelle WAP.

3- Test d’accès à l’application

Pour enfin voir le résultat de vos efforts, vous allez utiliser votre navigateur pour accéder à l’application ClaimApp depuis votre poste.

1. Lancer Internet Explorer et entrez l’URL https://webapp.contoso-corporation.com/claimapp/ (sans oublier de modifier le nom de domaine).
2. Comme vous n’êtes pas authentifié, l’application va vous rediriger vers le serveur AD FS (publié à travers WAP) qui va vous afficher la page d’authentification ci-dessous (voir note).
3. Entrez l’identifiant et le mot de passe du compte d’administration que vous avez défini (dans l’exemple ahaddock@contoso-corporation.com).
4. La page de l’application ClaimApp doit s’afficher :

FELICITATIONS ! Vous êtes arrivé à l’objectif visé de créer une infrastructure de base dans Azure sur laquelle vous appuyer pour mettre à disposition une application exemple accessible depuis internet. 

Note: votre page d’authentification sera en fait la page d’authentification par défaut d’ADFS ; celle qui est affichée a été customisée avec une image et un texte différents, mais vous verrez comment faire dans le paragraphe suivant « Bonus ».

Récapitulons

Cette série de 4 billets vous aura permis de faire connaissance avec Azure IaaS pour construire les services de base d’une infrastructure s’appuyant sur une partie des composants de la plateforme Windows Server 2012 R2. Vous avez également déployé une application de test s’appuyant sur le service de fédération AD FS qui devient la véritable pierre angulaire de l’authentification et du SSO entre applications et services Web à la fois hébergés à demeure ou dans le Cloud.

Certaines étapes auraient pu être scriptées mais il est souvent intéressant de réaliser une première fois la manipulation à la main pour mieux fixer.

Vous aurez remarqué qu’il y a beaucoup de manipulation de certificats : c’est inhérent au fait que toutes les communications Web doivent être protégées et que l’on n’utilise pas de certificat émis par une autorité de certification externe faisant partie des autorités déclarées, par défaut, de confiance.

Enfin, cette maquette peut être utilisée comme base pour l’implémentation d’autres scénarios : par exemple l’accès à l’application ClaimApp avec prise en compte de l’enregistrement de l’appareil au Lieu de travail (la fonctionnalité de jonction est déjà opérationnelle sur la maquette), la mise en œuvre de l’authentification multi-facteur avec Windows Azure MFA, l’utilisation d’Azure RMS, etc.

Bonus !

Je vous avais promis un bonus que voici, qui va vous permettre de goûter à la personnalisation du service AD FS.

1. Pour personnaliser l'image de l'écran d'authentification, choisir une image que vous ajusterez à environ 1420x1080 pixels, 96 DPI et une taille maximale de 200 ko.
2. Recopiez ensuite l’image sur le serveur DC1 dans un répertoire local (par exemple C:\ ADFS_Picture)
3. Ouvrez une console PowerShell et entrez la commande en spécifiant le chemin vers votre image                        Set-AdfsWebTheme -TargetName default -Illustration @{path="C:\ADFS_Picture\Seattle Tower 1420X1080-96DPI.jpg"}
4. Dans Internet Explorer, ouvrez un nouvel IE en mode In Private, avec Ctrl+Shift et touche P.
5. Entrer l’URL https://webapp.contoso-corporation.com/claimapp/ et admirez la nouvelle page d’authentification!

Pour changer le texte sous le bouton Connexion, entrez en ligne de commande PowerShell

1. Set-AdfsGlobalWebContent -SignInPageDescriptionText "<p>L'accès aux applications de Contoso Corporation peut nécessiter l'enregistrement de votre PC ou appareil mobile. </p>"

Pour avoir l’ensemble des possibilités de personnalisation, référez-vous à l’article Technet Customizing the AD FS Sign-in Pages.

Après avoir réalisé l’ensemble des étapes de ce billet, vous serez en mesure d’accéder à l’application de test depuis le réseau interne ; la dernière étape consistant à publier l’application à l’extérieur avec la fonctionnalité Web Application Proxy - incluse dans Windows Server 2012 R2 - sera décrite dans le prochain et dernier billet de cette série.

Cette étape reprend en partie la procédure d’installation décrite dans l’étape 3 de la fiche technique Technet Set up the lab environment for AD FS in Windows Server 2012 R2. J’ai pris l’option de la décrire en français en l’adaptant au contexte de cette maquette dans Azure même si certaines parties diffèrent peu de la version originale.

Pour rappel, avant de vous lancer à corps perdu dans les étapes ci-dessous, vous devez d’abord avoir suivi les premières étapes de construction de la maquette décrites dans les 2 précédents billets :

• BYOD : Construction d’une maquette Azure IaaS Partie 1
• BYOD : Construction d’une maquette Azure IaaS Partie 2

[MISE A JOUR 3/01/2014] Quelques corrections de typo et un ajout de certains prérequis en étape 6 pour le test de l'application claimapp. 

Etape 1 - Démarrage des VM et intégration de WEBAPP dans le domaine

1- Démarrage des machines virtuelles

Si vous avez été jusqu’à la fin du précédent billet, vous avez compris l’intérêt d’arrêter complètement les VM pour optimiser les euros de votre crédit Azure. Pour cette 3^ème partie, vous devrez démarrer DANS L’ORDRE la machine DC1 puis ensuite WEBAPP.

1. Pour démarrer la VM DC1, dans le portail, bandeau de gauche, sélectionnez MACHINES VIRTUELLES, cliquez sur DC1 puis TABLEAU DE BORD et appuyez sur le bouton DEMARRER dans le bandeau inférieur.
2. Attendez que la machine démarre et vérifiez dans le tableau de bord de la machine au niveau du bandeau à droite, que le champ ADRESSE IP INTERNE est bien à 10.0.0.4.
3. Répétez l’opération avec la VM WEBAPP.

Note: Rappelez-vous que les adresses IP des VM sont attribuées dynamiquement et que la seule assurance que l’on ait est l’adresse de début d’attribution des IP dynamiques dans le sous-réseau. Voir Etape 1 - Création de l’infrastructure réseau dans le 1er billet BYOD : Construction d’une maquette Azure IaaS Partie 1.

2- Paramétrage du client RDP pour l’accès à WEBAPP

Pour installer la VM WEBAPP, nous allons devoir transférer des données vers cette VM. Le plus simple est d’utiliser la possibilité offerte par RDP de mapper le disque local du poste depuis lequel on opère pour le rendre visible depuis la VM.

1. Connectez-vous au portail de management Azure, naviguez vers MACHINES VIRTUELLES\webapp\TABLEAU DE BORD et notez le nom DNS de WEBAPP situé sur la colonne de droite (dans notre exemple cs-contoso-corporation.cloudapp.net qui correspond au nom du Cloud Service).
2. Sélectionnez l’onglet POINTS DE TERMINAISON et notez le port PUBLIC correspondant à la ligne Remote Desktop (par exemple : 544243).
3. Lancez mstsc.exe (appuyez sur le bouton Windows, tapez mstsc.exe et validez).
4. Cliquez sur la flèche Show Options.
5. Dans l'onglet Local Resources, dans la zone Local Devices and resources, cliquez sur More
6. Sélectionnez sous Drives la case à cocher OS Disk (C:) et validez.
7. De retour sur l'onglet General, entrez dans Computer, le nom DNS de la VM WEBAPP suivi du port public utilisé pour y accéder en RDP (dans notre exemple cs-contoso-corporation.cloudapp.net:544243).
8. Cliquez sur Save As et sauvegardez sur le Bureau sous le nom de fichier WebApp.rdp de manière à le réutiliser lors des prochaines connexions.
9. Connectez-vous en RDP en vous authentifiant avec le compte d’administration et le mot de passe que vous avez spécifiés lors de la création de la VM.

3- Intégration de WEBAPP dans le domaine

1. Vérifiez que le serveur DNS est bien 10.0.0.4 en lançant en ligne de commande ipconfig /all  sinon rebootez la VM WEBAPP.
2. Une fois la session ouverte sur WEBAPP, lancez PowerShell et entrez la ligne de commande suivante en substituant contoso-corporation.com par votre nom de domaine :

           Add-Computer -DN contoso-corporation.com

       3. Après vérification, lancez ligne de commande PowerShell pour redémarrer

          Restart-Computer

Etape 2 - Récupération des prérequis à l’installation

1- Récupération du répertoire sources\sxs

Vous allez devoir récupérer à partir de l’image ISO d’une distribution Windows Server 2012 R2, le répertoire sources\sxs et le recopier ensuite sur WEBAPP.

1. Monter l’ISO sur votre machine locale (sous Windows 8, sélectionnez l’image ISO et après clic-droit, sélectionnez l’option Mount).
2. Recopiez le répertoire sources\sxs sur votre disque local (par exemple sous C:\Azure-Temp)
3. Ouvrez la session RDP sur WEBAPP en tant qu'administrateur du domaine (ex. CONTOSO-CORP\ahaddock), recopiez le répertoire sources\sxs depuis le mappage du disque local (voir ci-dessous C on MY-PC\Azure-Temp) vers le disque C : de la VM WEBAPP.

Note : la recopie de l'ensemble des fichiers peut prendre plusieurs minutes.

2- Récupération du SDK WindowsIdentityFoundation

Le SDK de Windows Identity Foundation va nous permettre de disposer des composants de la bibliothèque WIF, des outils et du code de l’application exemple que l’on va installer sur WEBAPP.

1. Téléchargez le Windows Identity Foundation SDK depuis l’URL http://www.microsoft.com/en-us/download/details.aspx?id=4451
2. Recopiez le SDK (WindowsIdentityFoundation-SDK-3.5.msi) sur WEBAPP selon la même méthode de copie que précédemment.

Etape 3 - Installation du rôle de serveur Web (IIS)

Cette étape installe le serveur Web en y incluant la fonctionnalité Windows Identity Foundation sur laquelle va s’appuyer l’application de démonstration.

1. Depuis Server Manager, dans le Dashboard, choisissez Add roles and features pour lancer le Wizard d’installation.
2. A partir de l’écran d’accueil cliquez sur Next 3 fois pour conserver les choix par défaut (Role-based or feature-based installation puis Select a server from the server pool).
3. Sur la page Select server roles, sélectionnez la case à cocher de Web Server (IIS), puis Add Features et Next.
4. A la page Select Features, sélectionnez Windows Identity Foundation 3.5 et appuyez sur Next.
5. A la page Web Server Role (IIS) page, appuyez sur Next.
6. A la page Select role services, sélectionnez et étendre Application Development, choisir ASP.NET 3.5, cliquez sur Add Features et Next.
7. A la page Confirm installation selections, choisir Specify an alternate source path et entrer le chemin vers le répertoire sxs que vous venez de copier sur le disque de la VM (C:\Azure-Temp).
8. Appuyez sur OK et Install.
9. Vérifiez que l'installation s'est passée correctement et appuyez sur Close.

Etape 4 - Installation de l’application Web exemple : Claimapp

1- Installation du SDK WIF

L’étape la plus simple consiste à installer le SDK WIF qui va permettre ensuite de disposer du code de l’application exemple et de l’outil Fedutil ; ce dernier sera utilisé pour sa configuration en mode “revendication” (claim-aware) pour qu’elle soit en mesure de se connecter avec le serveur de fédération AD FS et d’accepter des jetons SAML.

1. Exécuter le fichier WindowsIdentityFoundation-SDK-3.5.msi que vous venez de recopier sur la VM avec toutes les options par défaut.

2- Tirage du certificat pour l’application

Nous allons utiliser le gabarit de certificat ADFSWebserver créé à l’étape 2 du précédent billet BYOD : Construction d’une maquette Azure IaaS Partie 2 pour demander un certificat à l’autorité de certification interne. Ce certificat va servir pour le dialogue en https avec l’application claimapp. Rappelez-vous que le gabarit ADFSWebserver a eu précédemment les droits positionnés pour le groupe "Domain computers" ce qui va nous permettre de pouvoir y accéder depuis la VM WEBAPP.

1. Pour tirer et installer le certificat dans le magasin local, exécutez la commande PowerShell suivante (en n’oubliant pas de remplacer conto-corporation.com) :

Get-Certificate -Template ADFSWebServer -DnsName webapp.contoso-corporation.com -SubjectName CN=webapp.contoso-corporation.com -CertStoreLocation cert:\LocalMachine\My

2. Appuyez sur le bouton Start , entrez certlm.msc et validez ; naviguez vers Personal\Certificates et vérifiez que le certificat webapp.contoso-corporation.com est bien présent. Remarquez l’existence d’un 2^ème certificat qui correspond au certificat auto-signé qui sert à se connecter en RDP sur la VM.

3- Recopie de l’application Claimapp

L’installation du SDK nous met à disposition un ensemble d’applications exemples dont l’une, basique mais qui a l’avantage d’être simple à mettre en œuvre, va nous servir à d’application de test.

1. Recopiez le contenu du répertoire C:\program files (x86)\Windows Identity Foundation SDK\v3.5\Samples\Quick Start\Web Application\PassiveRedirectBasedClaimsAwareWebApp vers c:\inetpub\claimapp

4- Adaptation de l’application Claimapp

Le code de l’application Claimapp doit subir une modification mineure pour afficher l’ensemble des revendications (claims) qui seront intégrées dans le jeton SAML présenté à l’application.

1. Ouvrir le fichier Default.aspx.cs dans Notepad et rechercher la 2^ème occurrence de la chaine de caractères WriteClaim.
2. Mettez en commentaire (en préfixant la ligne avec //) la ligne if et les 2 parenthèses entourant la fonction WriteClaim. (les lignes mises en commentaires sont indiquées ci-dessous en graissé).

foreach ( Claim claim in claimsIdentity.Claims )

{

// Before showing the claims validate that this is an expected claim

// If it is not in the expected claims list then don't show it

//if ( ExpectedClaims.Contains( claim.ClaimType ) )

//{

WriteClaim( claim, table );

//}

}

       3. Fermer Notepad en sauvegardant les modifications.

5- Paramétrage du fichier de configuration Web.config

Le fichier web.config, situé dans le répertoire de l’application, est un fichier éditable qui contient la description du paramétrage de l’application. Il doit être adapté pour pouvoir se relier au serveur de fédération AD FS. Heureusement, un outil inclus dans le SDK, Fedutil, va s’occuper d’effectuer ces modifications après qu’on lui aura spécifié les quelques informations nécessaires.

On doit d’abord éditer le fichier web.config pour simplement supprimer une section.

1. Ouvrez le fichier web.config dans Notepad.
2. Supprimez toute la section depuis <microsoft.identityModel> jusqu’à </microsoft.identityModel> y compris ces 2 balises.
3. Fermez Notepad en sauvegardant les modifications.

Ensuite, on se repose sur l’outil Fedutil fourni dans le SDK WIF pour effectuer le reste des modifications dans web.config permettant de relier l’application au serveur de fédération.

1. Lancez Fedutil depuis le répertoire C:\Program Files (x86)\Windows Identity Foundation SDK\v3.5.
2. Dans le champ Application Configuration Location, indiquez le chemin vers le fichier web.config de l’application soit C:\inetput\claimapp\web.config.
3. Dans le champ Application URI, spécifiez https://webapp.contoso-corporation.com/claimapp/, en remplaçant contoso-corporation.com par le nom de votre domaine et sans oublier le « / » à la fin de la ligne, puis appuyez sur Next.
4. Dans l’écran suivant, sélectionnez la case à cocher Use an existing STS et entrez le chemin vers les métadonnées que publie le serveur de fédération https://adfs.contoso-corporation.com/federationmetadata/2007-06/federationmetadata.xml.
5. Je vous recommande d’appuyer sur le bouton Test location pour vérifier que l’URL que vous venez de spécifier est correct et accessible. Appuyez sur Next.
6. Conservez l’option par défaut Disable certificate chain validation et appuyez sur Next.
7. Conservez de même l’option No encryption et appuyez sur Next.
8. Arrêtez-vous 1 minute sur l’écran Offered claims, qui visualise la liste des revendications qui sont disponibles au niveau du serveur AD FS. Cette liste de revendications est issue du fichier de méta-données qui est accessible depuis l’URL précédent. Vous pouvez remarquer que des revendications concernant les devices ont été ajoutées (devicecontext, requestcontext) qui ont une utilité dans un scénario BYOD. Puis cliquez sur Next.
9. Sur l’écran récapitulatif, cliquez sur l’option Schedule a task to perform daily WS-Federation metadata updates pour que l’application puisse prendre en compte régulièrement toute modification dans les métadonnées exposées par le service de fédération.
10. Appuyez sur Finish.

6- Configuration du serveur Web IIS

Enfin, cette dernière étape de configuration consiste à paramétrer l’application au niveau du serveur Web IIS.

1. Appuyez sur le bouton Start  , tapez IIS manager et validez.
2. Cliquez sur Applications Pools , DefaultAppPool puis sur Advanced Settings dans le bandeau droit. Positionnez Load User Profile à True et validez avec OK.
3. Toujours positionné sur DefaultAppPool, cliquez sur Basic Settings et positionnez .NET CLR Version à .NET CLR Version v2.0.50727. Validez avec OK.
4. Déployez Sites puis cliquez sur Default Web Site et sélectionnez Bindings sur le bandeau droit.
5. Ajouter un binding https sur le port 443 et sélectionnez le certificat SSL que vous avez installé à l’étape 4 (avec le nom DNS webapp.contoso-corporation.com).
6. Faites un clic-droit sur Default Web Site et sélectionnez Add Application.
7. Entrez claimapp dans le champ Alias, c:\inetpub\claimapp dans Physical path et validez avec OK.

Etape 5 - Déclaration de WebApp au niveau du serveur AD FS

L’installation et la configuration de l’application claimapp est terminée ! Avant de pouvoir la tester, il est nécessaire de déclarer l’application en tant que Relying Party (que je traduirais par « parti dépendant »). Ceci établit une relation entre l’application et le serveur de fédération vers lequel sera redirigée la requête en provenance du navigateur lorsqu’aucun jeton n’est présenté dans cette requête.

1- Déclaration de Claimapp en tant que Relying Party pour le serveur AD FS

La commande PowerShell suivante va permettre de référencer claimapp en tant que Relying Parti.

1. Connectez-vous en RDP sur la VM DC1 (attention car toutes les étapes précédentes étaient réalisées sur WEBAPP).
2. Ouvrez la console PowerShell et entrer la ligne de commande suivante (en remplaçant contoso-corporation.com par votre nom de domaine) :

Add-ADFSRelyingPartyTrust -Name "Claimapp" -MetadataURL "https://webapp.contoso-corporation.com/claimapp/federationmetadata/2007-06/federationmetadata.xml"

2- Création de la règle d’émission du jeton

On va ensuite créer une règle de transformation (Issuance Transform Rule) pour que toutes les revendications reçues par le serveur AD FS soient inclues dans le jeton SAML à destination de l’application claimapp. On termine par la création d'une règle d'autorisation d'émission du jeton sans mettre de restrictions.

1. Pour ouvrir la mmc AD FS, appuyer sur le bouton Start, tapez AD FS (ad fs management doit vous être proposé) et validez.
2. Prendre le chemin AD FS\Trust Relationships\ Relying Party Trusts\claimapp et tout en étant positionné sur claimapp, cliquez Edit Claim Rule sur le bandeau à droite.
3. Appuyez sur Add Rule, choisissez Send Claims Using a Custom Rule et cliquez sur Next.
4. Dans le champ Claim rule Name, spécifiez All Claims et dans le champ Custom rule, entrez les deux lignes suivantes :

c:[ ]
=> issue(claim = c);

       5.  Cliquez sur Finish et OK.

       6. Toujours positionné sur ClaimApp, cliquez sur le lien Edit Claims Rules, et choisir l'onglet "Issuance Authorization Rules".

       7. Cliquez sur Add Rule, choisir Permit All Users, puis Next, Finish et validez avec OK. 

Etape 6 Test de l’application claimapp

Nous allons enfin pouvoir tester l’accès à l’application claimapp depuis l’interne. Il est important de noter que ce test va se faire depuis la machine virtuelle WAP qui est hors-domaine.

On doit d'abord s'occuper de quelques prérequis :

1. Vérifiez d'abord que le serveur DNS attribué à WAP est bien 10.0.0.4 (avec ipconfig /all en ligne de commande) sinon rebootez la VM WAP.
2. Ensuite pour importer le certificat racine de la PKI, Connectez-vous en RDP sur la VM DC1.
3. Ouvrez CMD.exe et entrez la ligne de commande suivante :  certutil -ca.cert c:\contoso-root.cer
4. Utilisez le copier-coller entre VM pour récupérer le fichier contoso-root.cer depuis la VM DC1 pour le recopier sur WAP sur la racine de C:\ contoso-root.cer.
5. Pour effectuer l'import du certificat racine sur WAP, ouvrir CMD.exe en tant qu’administrateur : appuyez sur le bouton Start pour aller sur l’accueil, puis tapez CMD, puis clic-droit sur l’icône et choisir Run as Administrator.
6. Entrez la ligne de commande suivante : certutil -addstore root C:\contoso-root.cer

Enfin, un dernier paramétrage avant le test qui va forcer l'authentification par formulaire au niveau du service AD FS.

1. Sur DC1, ouvrez la console de gestion AD FS, naviguez jusqu'à Authentication Policies et cliquez sur le lien Global Primary Authentication.
2. Dans la section Intranet, décochez Windows Authentication et sélectionnez uniquement Forms Authentication. Validez en appuyant sur OK.

Pour faire le test :

1. Appuyer sur le bouton Start , entrez iexplore et validez.
2. Entrez dans le navigateur l’URL https://webapp.contoso-corporation.com/claimapp/
3. Dans la fenêtre d’authentification, rentrez comme nom d’utilisateur, le compte d’administration et le mot de passe que vous avez spécifiés pour votre domaine (ou le nom d’un utilisateur que vous aurez créé).

L’écran suivant doit s’afficher :

C’est vrai que l’application n’est pas très affriolante mais elle a pour avantage d’être didactique en affichant l’ensemble des revendications qui sont présentées dans le jeton SAML. Elle nous permettra également de faire connaissance avec les nouvelles revendications associées aux appareils qui sont intéressantes dans le contexte BYOD.

Note : Au cas où l’accès à l’application ne marcherait pas, je vous livre quelques points à vérifier

• Vérifier que vous avez accès depuis WAP aux métadonnées de l’application claimapp  https://webapp.contoso-corporation.com/claimapp/federationmetadata/2007-06/federationmetadata.xml sans avertissement de certificat. Un avertissement implique que l’AC racine  n’est pas dans le magasin des certificats Trusted Root Authorities de la machine.
• Vérifier dans le journal des évènements les logs du service AD FS: c’est une source d’information très intéressante sur l’état du service, les requêtes qui lui sont adressées et bien sûr les éventuelles erreurs. Vous pourrez par exemple vérifier si le service ne répond pas correctement suite à un problème de configuration (Event 511, ci-dessous)

Le deuxième exemple correspond à une erreur dans la règle d’émission des jetons (Issuance Transform Rule).

Etape 7 Arrêt des VM

Si vous ne souhaitez pas continuer sur le billet suivant, n’oubliez pas d’arrêter les VM y compris à travers le portail de gestion pour ne plus consommer votre crédit Azure. Reportez-vous à Etape 3 : Extinction de la maquette ! BYOD : Construction d’une maquette Azure IaaS Partie 1.

Récapitulons

Cette 3^ème étape de construction a permis d’installer une application de test mais surtout de mieux comprendre comment s’effectuait la connexion entre l’application et le serveur de fédération AD FS. L’application doit référencer le serveur de fédération à qui elle va déléguer l’authentification et la génération du jeton SAML incluant les revendications ; ce paramétrage se fait à travers l’outil Fedutil qui va renseigner le fichier web.config de l’application en y incluant les chemins vers le serveur AD FS, les revendications demandées, etc.

Ensuite, l’application doit être déclarée en tant que Relying Party (« parti dépendant ») au niveau du serveur de fédération pour que ce dernier puis se charger de construire le jeton avec les revendications demandées et lui retransmettre.

Enfin, tous ces efforts sont récompensés par l’affichage d’une page énumérant l’ensemble des revendications contenues dans le jeton SAML présenté à l’application.

Dans le prochain et dernier billet de la série, nous verrons comment utiliser Web Application Proxy pour rendre cette application accessible depuis l’’internet et comment utiliser le service DRS pour l’enregistrement des appareils au Lieu de travail (Workplace join).