BYOD : Construction d’une maquette Azure IaaS Partie 1

Article
12/05/2013

Dans les précédents billets, nous avons abordé la description d’un mécanisme important, le Workplace join (en français jonction au Lieu de travail) qui permet d’enregistrer des appareils dans Active Directory. L’idée de cette série de billets est de construire une infrastructure qui permette de démontrer cette fonctionnalité mais qui pourra ensuite être étendue pour tester d’autres scénarios relatifs au BYOD comme les Work Folders, l’authentification multi-facteur, etc.

Approche

La mise en œuvre du WorkPlace Join est décrite dans une série d’articles Technet, mais certaines étapes importantes sont plus ou moins éludées – par exemple la manipulation des certificats – rendant plus aléatoire l’atteinte de l’objectif final : s’assurer de disposer à la fin d’une maquette fonctionnelle sans se voir imposer une période de déboguage qui peut s’avérer pénible lorsque l’on découvre.

Certains blogs décrivent également les étapes principales, ce qui est intéressant pour comprendre les grandes lignes de la mise en place, mais sans s’attarder sur les points plus délicats qui risquent de vous faire chuter avant la fin voire, pire, abandonner avec un sentiment situé entre la colère et la désolation.

Mon premier objectif sera donc de décrire l’ensemble des étapes avec quelques explications pour vous éviter d’enchainer des clics, les écrans de wizards et les lignes de commande, en vous demandant à la fin, grisé par la succès ce que vous avez finalement compris et retenu.

J’ai pris le parti suivant :

Ne pas décrire uniquement les étapes sous forme de « cliquer sur » et au prochain écran entrez « contoso.com » ;
Ne pas faire que sous forme de copies d’écran, ce qui remplit rapidement mais alourdit ;
Ne pas tout scripter en PowerShell : j’ai utilisé PowerShell pour les étapes à moindre valeur ajoutée (par exemple l’installation d’AC CS avec toutes les valeurs par défaut) ce qui permet d’accélérer notoirement la construction ;
Conserver pour les étapes qui me semblaient intéressantes la manière interactive pour une meilleure compréhension ;
Me réserver le droit d’utiliser d’autres outils que PowerShell, par exemple le bon vieux certutil lorsqu’il s’avérait plus efficace à utiliser que d’enchainer des lignes de commande Powershell nettement plus cryptiques.

Le deuxième choix important a été celui d’utiliser des machines virtuelles Azure IaaS pour la construction de cette maquette. Les guides étapes par étapes que nous avons publiés précédemment (voir https://blogs.technet.com/b/byod-fr/archive/2013/05/06/publication-des-guides-etapes-par-etapes-bring-your-own-device-byod-test-lab-guides-series-v1_2d00_0.aspx) nécessitent de disposer d’un serveur bien dimensionné et d’éléments physiques comme une borne Wi-Fi pour mettre en œuvre une maquette représentative. Dans cette série de billets, la maquette sera réalisée en construisant une infrastructure dans le Cloud basée sur des machines virtuelles hébergées dans Azure.

Cette option présente un double avantage :

Vous n’avez pas à disposer d’une plateforme physique à demeure ou à investir dans du matériel : depuis la construction jusqu’aux tests, tout peut se faire depuis un poste de travail à la seule condition de disposer d’une connexion internet. Notez que, pour pouvoir tester la jonction au Lieu de travail, vous aurez besoin d’une machine W8.1 (physique ou VM), ou d’une tablette Windows RT 8.1 ou d’un iPad.
Vous allez pouvoir rapidement vous initier à l’utilisation d’Azure IaaS et aborder les concepts de base en implémentant une maquette qui marche (du moins la mienne) ;
L’architecture proposée devrait vous permettre de minimiser les coûts d’hébergement sur Azure en vous laissant la possibilité d’éteindre les VM (excepté la VM qui sert de passerelle ou sous certaines conditions).

Si vous êtes l’heureux possesseur d’un compte MSDN, vous disposez d’un crédit de 40€, 75€ ou 115€ selon le niveau d’abonnement inclus dans votre abonnement et recrédité tous les mois (https://www.windowsazure.com/fr-fr/pricing/member-offers/msdn-benefits-details/)

Si vous n’avez pas d’abonnement, vous pouvez profiter de la version d’évaluation et d’un crédit de 150 € qui vous permet de construire cette maquette sans frais. Voir Version d'évaluation gratuite de Windows Azure https://www.windowsazure.com/fr-fr/offers/ms-azr-0044p.

Mais l’idée est de pouvoir limiter la consommation en mettant en sommeil la maquette pourprofiter au mieux de ce crédit. J’expliquerai plus loin les points à respecter pour pouvoir arrêter et redémarrer sans problème votre maquette.

Un dernier point avant de démarrer : RESPECTEZ L’ORDRE DE CONSTRUCTION si vous voulez aller sans problème jusqu’à la fin sans avoir à refaire des étapes : par exemple, si vous créez une VM sans la rattacher à un réseau virtuel, elle sera créée avec son Cloud Service qu’il ne sera plus possible de rattacher après coup au réseau virtuel.

De même, prenez le temps de lire les explications ne serait-ce que pour minimiser les risques d’erreur.

Et maintenant, passons aux aspects techniques.

Description de la maquette

La maquette est composée de 3 machines virtuelles sous Windows Server 2012 R2.

La première VM, DC1, héberge les rôles de contrôleur de domaine (Active Directory), de PKI (AD Certificate Services), de serveur de fédération (AD Fedération Services) et enfin de DNS.
La 2ème VM est le serveur Web nommé WEBAPP, qui fera tourner une application de test permettant d’afficher les revendications (claims) de l’utilisateur qui y accède.
La dernière VM joue le rôle de passerelle Web à travers le service Web application Proxy, qui va publier l’application Web et le service d’enregistrement vers internet, et servir de proxy pour le service AD FS.

D’un point de vue réseau, les machines sont réparties dans 2 sous-réseaux (FrontEnd et BackEnd), dans un unique réseau virtuel, et lui-même englobé dans un Cloud service. Le Cloud service est accessible depuis l’extérieur par une adresse IP virtuelle (VIP) qui est attribuée automatiquement. Un point de terminaison sur la VM WAP permettra de récupérer le flux HTTPS en provenance de l’internet.

Note : La version AD FS 3 ne nécessite plus l’installation du service Web IIS, ce qui rend moins nerveux d’installer ce rôle sur un contrôleur de domaine.

Etape 1 - Création de l’infrastructure réseau

Avant de déployer la première machine virtuelle, nous allons mettre en place l’infrastructure réseau qui passe par la création d’un groupe d’affinité, d’un réseau virtuel à l’intérieur duquel, deux sous-réseaux seront définis pour héberger les 3 VM.

1- Création d’un groupe d’affinité

Un groupe d’affinité permet de s’assurer que toutes les VM qui vont être créées seront placées dans le même Datacenter.

Connectez-vous au portail de gestion de Windows Azure (https://manage.windowsazure.com/).
Dans le portail de gestion, dans le bandeau de gauche, choisissez PARAMETRES, puis GROUPES D’AFFINITES et cliquez en bas au milieu sur le + AJOUTER.
Spécifier

un nom : CONTOSO-AFFINITY-GROUP,
une description : Groupe affinité CONTOSO Western EUROPE
la région : sélectionnez Europe de l’Ouest

et valider

2- Création du réseau virtuel et des 2 sous-réseaux

Le réseau virtuel va s’appuyer sur le groupe d’affinité précédemment créé et va permettre de construire l’infrastructure réseau qui va être utilisée pour la maquette dans le DataCenter.

Dans le portail de gestion, dans le bandeau de gauche, choisissez RESEAUX, puis en bas à gauche sélectionnez + NOUVEAU
Choisissez RESEAU VIRTUEL/CREATION PERSONNALISEE
Spécifiez le nom : VN-CONTOSO puis sélectionnez dans la liste déroulante CONTOSO-AFFINITY-GROUP, le groupe d’affinité tout juste créé.
Passez l’écran suivant (serveur DNS et connectivité VPN)
Dans l’écran Espace d’adresses du réseau virtuel, dans l’espace d’adressage proposé par défaut 10.0.0.0, choisissez un CIDR de 27 (32 hosts) puis ajoutez 2 sous-réseaux :

- BackEnd en 10.0.0.0/27
- FrontEnd en 10.0.0.32/27

Point important :

Avec Windows Azure, les adresses sont attribuées dynamiquement ce qui peut sembler bizarre surtout lorsque l’on a l’habitude d’imposer des adresses fixes, par exemple, sur les contrôleurs de domaine. Pour être plus précis encore, l’utilisation d’adresses fixes n’est PAS supportée ; vous pouvez toujours tenter mais vous verrez que vous risquez rapidement de perdre toute connectivité sur cette machine virtuelle. Je vous recommande la lecture de « IP addressing and DNS » https://msdn.microsoft.com/en-us/library/windowsazure/jj156090.aspx#BKMK_IPAddressDNS

A l’intérieur d’un sous-réseau, les 3 premières adresses sont réservées et, dans le cas du 1^er sous-réseau, la première adresse qui sera attribuée par le DHCP Azure sera 10.0.0.4. Or, on a la garantie que cette première adresse restera constante, ce qui n’est pas le cas pour les adresses suivantes. Il est important de prendre en compte ce comportement dès lors que l’on souhaite qu’une VM retrouve la même adresse IP, ce qui va être le cas de notre contrôleur de domaine.

Etape 2 : Création des machines virtuelles

Il est possible d’utiliser PowerShell pour automatiser la création des machines virtuelles mais pour une première découverte, j’ai choisi de passer par l’interface du portail.

On va commencer par créer la VM qui hébergera le contrôleur de domaine DC1

Dans le portail de gestion, dans le bandeau de gauche, choisissez MACHINES VIRTUELLES, puis en bas à gauche sélectionnez + NOUVEAU
Choisissez A PARTIR DE LA GALERIE
Sélectionnez l’image Windows Server 2012 R2 Datacenter et cliquez sur la flèche suivant

4. Dans l’écran « Configuration de la machine virtuelle », spécifiez

- Nom de la machine virtuelle : DC1
- Taille : choisir Petite
- Nouveau nom d’utilisateur : ahaddock (ou le nom de votre choix pour l’administrateur local)
- Mot de passe : Choisir un mot de passe et Confirmer

5. Dans l’écran suivant, choisissez les options suivantes

- SERVICE DE CLOUD COMPUTING : Créer un nouveau service de Cloud Computing
- NOM DU CLOUD SERVICE DNS : CS-CONTOSO-CORP
- Région/Groupe d'affinités/Réseau virtuel : VN-CONTOSO
- Sous-réseaux du réseau virtuel : BackEnd
- Compte de stockage : Utiliser un compte de stockage généré automatiquement
- Groupe de haute-disponibilité : (Aucune)

6. Passez à l’écran suivant, laisser les points de terminaison par défaut et cliquer sur le bouton de validation.

Vous pourrez noter que l’on a créé un Cloud Service (CS-CONTOSO-CORP) qui sera utilisé pour les 2 VM suivantes. En effet, inutile de créer plusieurs Cloud Services dès lors que l’on n’a besoin que d’une seule VIP (adresse virtuelle) qui sera utilisée par la machine WAP qui publie les services internes y compris le serveur AD FS.

Vous allez maintenant répéter les étapes précédentes pour créer les 2 autres machines virtuelles. Faites bien attention à les positionner dans le même Cloud Service, le même réseau virtuel mais chacune dans un sous-réseau différent, WAP étant positionnée très logiquement dans le sous-réseau FrontEnd.

Pour créer la VM WEBAPP, suivez de nouveau le processus précédent mais avec les paramètres suivants :

Nom de la machine virtuelle : WEBAPP
SERVICE DE CLOUD COMPUTING : CS-CONTOSO-CORP
Région/Groupe d'affinités/Réseau virtuel : VN-CONTOSO
Sous-réseaux du réseau virtuel : BackEnd

Pour créer la VM WAP, suivez de nouveau le processus précédent avec les paramètres suivants :

Nom de la machine virtuelle : WAP
SERVICE DE CLOUD COMPUTING : CS-CONTOSO-CORP
Région/Groupe d'affinités/Réseau virtuel : VN-CONTOSO
Sous-réseaux du réseau virtuel : FrontEnd

Une fois les VM créées, vous allez pouvoir vous y connecter en RDP :

Sélectionnez MACHINES VIRTUELLES puis cliquez sur la VM sur laquelle vous souhaitez vous connecter.
Cliquez sur TABLEAU DE BORD : le bouton CONNECTER apparaît sur le bandeau inférieur.
Sauvegardez le fichier <nom de machine>.rdp que vous utiliserez ensuite pour accéder à cette VM.
Il vous suffit de double-cliquer sur le fichier RDP pour établir la connexion vers la machine après authentification.

Vous pouvez dès maintenant vous connectez sur les 3 VM et vérifier que les adresses IP sont correctes. (voir schéma de la maquette).

Etape 3 : Extinction de la maquette !

Pour éviter de consommer votre crédit, éteignez vos 3 VM tant qu’elles ne sont ni paramétrées, ni utilisées. Si vous faites simplement une extinction depuis la VM elle-même (un shutdown étant connecté en RDP), vous verrez l’avertissement suivant au niveau de la VM dans le portail d’administration.

Même si la VM éteinte ne tourne plus au sens consommation CPU, elle reste référencée et décrémente votre crédit.

Il faut donc les éteindre depuis le portail en sélectionnant la VM avec un statut « Arrêté » et en appuyant sur le bouton « Arrêter » du bandeau inférieur. Le statut passera alors en « Arrêté (Désalloué).

Nous redémarrerons les VM dans les prochaines étapes de la construction de la maquette qui seront décrites dans les billets à venir.

Récapitulons

Dans ce premier billet, si vous avez suivi la procédure, vous aurez appris comment construire une infrastructure réseau simple dans Azure à travers les concepts de Groupe d’affinité, Cloud Service, réseau virtuel. Vous aurez peut-être découvert que les adresses IP fixes n’ont plus bonne presse. Vous aurez construit vos 3 premières machines virtuelles et appris comment économiser votre crédit en faisant un arrêt avec désallocation des VM.

Dans les billets suivants, nous nous attaquerons à l’installation et la configuration des différents rôles hébergés sur les machines virtuelles et, contrairement à ce premier billet qui servait également d’initiation à Azure IaaS, nous recourrons à PowerShell pour automatiser une partie des étapes.

Share via