Share via

BYOD : Construction d’une maquette Azure IaaS Partie 3

  • Article

Maintenant que l’ensemble des composants de l’infrastructure est fonctionnel, nous allons, durant tout ce billet, procéder à l’installation de la machine virtuelle WEBAPP qui va héberger une application de test basique et facile à mettre en place. Selon le même principe, toute application travaillant en mode fédéré, c’est-à-dire capable de s’appuyer sur un serveur de fédération et de consommer en entrée un jeton SAML pourrait être ajoutée à la maquette.

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 :

[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.image
  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.compar 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.

Mapping C 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 https://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 à cocherde 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.

image

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.msique 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 image, 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.

image

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 etappuyez 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.image
  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 image , 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.

image

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

image

       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 image, 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 :

image

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)

Error 511 AD FS

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

Error 325 AD FS

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