BYOD : Construction d’une maquette Azure IaaS Partie 4

[アーティクル]
12/23/2013

Durant l’étape précédente, BYOD : Construction d’une maquette Azure IaaS Partie 3nous avons installé l’application Claimapp, avant de la déclarer au niveau du serveur de fédération AD FS pour déléguer à ce dernier la responsabilité de l’authentification. Puis nous avons pu tester l’accès à l’application depuis le réseau interne. L’objectif final est maintenant de pouvoir accéder à ClaimApp hébergée dans Azure depuis internet.

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 :

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.

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

Connectez-vous en RDP sur la VM WAP.
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

Connectez-vous en RDP sur la VM DC1 où est installé le service AD FS.
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é.
Copier l’empreinte du certificat correspondant à CN=adfs.contoso-corporation.com (dans l’exemple FF8F5CFD…).
Quitter PowerShell pour lancer CMD en ligne de commande (bouton Start maintenu et la touche R).
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

Connectez-vous en RDP sur la VM WAP
Utilisez le copier-coller entre VM pour récupérer le fichier adfscontoso .pfxdepuis la VM DC1 pour le recopier sur la VM WAP sur la racine de C:\ adfscontoso .pfx
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…).

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

Connectez-vous en RDP sur la VM WEBAPP où est installée l’application ClaimApp.
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é.
Copier l’empreinte du certificat correspondant à CN=webapp.contoso-corporation.com (dans l’exemple 217BB3495…).
Quitter PowerShell pour lancer CMD en ligne de commande (bouton Start maintenu et la touche R).
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

Connectez-vous en RDP sur la VM WAP.
Utilisez le copier-coller entre VM pour récupérer le fichier webappcontoso .pfxdepuis la VM DC1 pour le recopier sur la VM WAP sur la racine de C:\ webappcontoso .pfx.
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.

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.

Connectez-vous au portail de gestion de Windows Azure (https://manage.windowsazure.com/).
Dans le portail de gestion, dans le bandeau de gauche, choisissez MACHINES VIRTUELLES, puis sélectionnez la machine virtuelle WAP et POINTS DE TERMINAISON.
En bas au milieu appuyez sur le + AJOUTER.
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.
Dans NOM, sélectionnez HTTPS :les champsPROTOCOLE, 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.

Connectez-vous en RDP sur la VM DC1.
Ouvrez CMD.exe et entrez la ligne de commande suivante : certutil -ca.cert c:\contoso-root.cer
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.

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

Connectez-vous au portail de gestion de Windows Azure (https://manage.windowsazure.com/).
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.
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.

Lancer Internet Explorer et entrez l’URL https://webapp.contoso-corporation.com/claimapp/ (sans oublier de modifier le nom de domaine).
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).
Entrez l’identifiant et le mot de passe du compte d’administration que vous avez défini (dans l’exemple ahaddock@contoso-corporation.com).
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.

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.
Recopiez ensuite l’image sur le serveur DC1 dans un répertoire local (par exemple C:\ ADFS_Picture)
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"}
Dans Internet Explorer, ouvrez un nouvel IE en mode In Private, avec Ctrl+Shift et touche P.
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

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.

次の方法で共有