Partager via

BYOD - Montage d'une plateforme de démo dans Azure - 1ère partie

  • Article

Présentation

[mise à jour importante le 13/12/2013 - voir ci-dessous dans la section Planification]

Aujourd'hui je vous propose de commencer à décrire une plateforme de démo complète permettant de démontrer des fonctionnalités clés de Windows Server 2012 R2 et Windows 8.1. Il s'agit de mettre en œuvre les technologies suivantes, relatives au Bring Your Own Device (BYOD) :

  • le Workplace Join (lieu de travail), avec une application web de test,
  • les Work Folders (dossiers de travail),
  • le Web Application Proxy (WAP),
  • le Selective Wipe (effacement sélectif),
  • Windows Intune avec synchronisation d'annuaire, single sign-on et fédération d'identités.

Cet article fait partie d'une série :

  1. BYOD - Montage d'une plateforme de démo dans Azure - 1ère partie - préparation du réseau, installation du DC et préparation des autres VM (cet article)
  2. BYOD - Montage d'une plateforme de démo dans Azure - 2ème partie - Détails sur le certificat SSL
  3. BYOD - Montage d'une plateforme de démo dans Azure - 3ème partie - Workplace Join
  4. BYOD - Montage d'une plateforme de démo dans Azure - 4ème partie - Work Folders (à venir)
  5. BYOD - Montage d'une plateforme de démo dans Azure - 5ème partie - Windows Intune : Dirsync, SSO (à venir)

Toutes ces technologies ainsi mises en place permettent de démontrer l'expérience utilisateur la plus simple, dans laquelle il lui suffit de son email et son mot de passe professionnels pour utiliser son système personnel.

J'ai mis en place cette plateforme au cours des semaines précédentes, afin de servir de base à différents scénarios de démonstration - il se peut même qu'elle soit mise à contribution lors des prochains Techdays... Etant donné les spécificités de ces scénarios, il est nécessaire que l'infrastructure soit accessible depuis des postes disposant uniquement d'une connexion à Internet. C'est pourquoi j'ai décidé d'héberger tous les serveurs nécessaires dans Windows Azure, sous forme de machines virtuelles.

Afin de simplifier les problèmes de domaine DNS et de confiance aux certificats, j'ai également pris la décision d'acheter auprès d'un fournisseur reconnu un nom de domaine public et un certificat SSL pour plusieurs noms DNS, de façon à ce que tout poste client puisse le reconnaître par défaut. De cette manière la démo est réaliste dans son ensemble : les noms DNS sont accessibles et le certificat SSL est reconnu, ce qui évite les habituels "trucs" pour utiliser des noms fictifs.

Au final cette mise en œuvre a donc un coût lié à Windows Azure (non négligeable), un nom de domaine et un certificat SSL pour plusieurs noms.

A propos de noms : j'ai choisi un nom de domaine public (que j'appellerai pour l'exemple : mademo.fr), et tous les objets que je crée dans Windows Azure seront préfixés par un préfixe commun (que j'appellerai mademo). J'ai également choisi de donner le même nom de domaine DNS à mon domaine AD afin de simplifier mes configurations. Cela dit, ce n'est évidemment pas une obligation : si, comme dans la plupart des cas, le domaine AD interne n'a pas le même nom que le domaine public, il suffit d'ajouter ce dernier comme UPN des utilisateurs : leur "email" portera ainsi le nom de domaine public.

Planification

[Mise à jour importante le 13/12/2013 - je modifie cet article pour n'utiliser qu'un seul cloud service, contrairement à la première version où je recommandais l'utilisation de 2 vloud services. En effet, le Web Application Proxy tenant également le rôle de "ADFS Proxy", il est préférable de faire passer tout le traffic par lui, au lieu d'exposer directement le serveur ADFS. De plus, cela résoud plusieurs problèmes rencontrés dans mes premiers tests.]

Pour commencer, un peu de planification s'impose. En effet, il faut avoir à l'esprit plusieurs contraintes :

  • Il y aura un domaine AD, donc un DC et des serveurs membres : un serveur ADFS, un serveur de fichiers pour les Work Folders, un serveur pour le Web Application Proxy et un pour l'application web de test. Tous ces serveurs doivent communiquer entre eux et donc se trouver sur le même Virtual Network de Windows Azure.
  • Il doit y avoir un point d'entrée HTTPS sur le port 443 pour le Web Application Proxy. Ce dernier publiera, outre le serveur ADFS du fait de son rôle d'ADFS Proxy, le serveur web de test et le serveur de fichiers pour les Work Folders. Le plus simple est donc de n'utiliser qu'un seul Cloud Service dans Windows Azure pour l'ensemble de nos VM, ce qui signifie une seule adresse IP publique.

Pour faire fonctionner les différentes démos, j'ai donc besoin des machines suivantes.

Nom de la VM Cloud Service Nom de la machine Description
mademo-dc mademo-svc dc Contrôleur de domaine
mademo-adfs mademo-svc adfs Serveur ADFS
mademo-proxy mademo-svc proxy Web Application Proxy
mademo-web1 mademo-svc web1 Site web de test
mademo-file mademo-svc file Serveur de fichiers, Work Folders

Peu importe les noms choisis pour les VM et le Cloud Service. Ce dernier est soumis au à la contrainte que son nom ne doit pas déjà exister dans Azure en général.

Infrastructure réseau

J'ai donc commencé par créer un réseau virtuel, et deux Cloud Services :

  • Un réseau virtuel : mademo-vnet, à Dublin (North Europe), avec l'adressage IP suivant :
    Address Space : 192.168.0.0/16
    • Subnet-1 : 192.168.1.0/24
  • Un Cloud Service : mademo-svc, à Dublin (North Europe)

Installation du contrôleur de domaine

L'étape suivante est d'installer le contrôleur de domaine. il faut donc créer une nouvelle VM en choisissant dans la galerie le modèle Windows Server 2012 R2 Datacenter (dernière version) et avec les caractéristiques suivantes :

  • nom de la VM : mademo-dc (à adapter si vous voulez reproduire la démo)
  • taille de la VM : Small (1 coeur, 1,75 Go de RAM)
  • nom et mot de passe de l'administrateur : choisir un nom et un mot de passe (vous utiliserez vraisemblablement ce nom et ce mot de passe en permanence pendant la configuration et l'accès aux VM)
  • cloud service : mademo-svc
  • région/groupe d'affinité/réseau virtuel : choisir le réseau virtuel créé précédemment (mademo-vnet)
  • Subnet : Subnet-1 (le seul subnet du réseau virtuel)
  • compte de stockage : un compte de stockage dont je dispose déjà à Dublin. Il n'est pas contre-indiqué de choisir le compte de stockage créé automatiquement.
  • groupe de disponibilité : (aucun)
  • endpoints : Remote Desktop et PowerShell par défaut, avec des ports publics AUTO.

Une fois la VM provisionnée et démarrée, aller dans ses propriétés et noter son adresse IP interne (dans mon cas, 192.168.1.4 puis que 4 est la première adresse disponible sur un subnet).

Remarque : aucune VM dans Azure ne doit avoir une adresse IP fixe. Bien que DC soit destinée à être un contrôleur de domaine, il est impératif de conserver l'adresse IP dynamique.

  • Dans la console Windows Azure, dans les propriétés du réseau  virtuel, dans l'onglet Configurer, entrer comme serveur DNS l'adresse IP de la VM. De cette manière, toutes les VM sur ce réseau recevront, par le DHCP d'Azure, l'adresse IP du DC comme serveur DNS.
  • Ouvrir une session Remote Desktop sur la VM (sélectionner la VM et cliquer sur Connect en bas de la page).
  • Renommer la machine virtuelle en DC (son nom interne peut être différent de son nom de VM dans Windows Azure) et redémarrer le système. Ce redémarrage permettra en même temps la récupération de la bonne adresse IP de DNS, à savoir sa propre adresse IP interne.
  • Installer toutes les mises à jour disponibles par Windows Update (mais ça, je n'ai pas besoin de vous le rappeler...)

A ce stade la machine virtuelle est prête à accueillir le rôle AD DS et à être configurée comme le DC d'une nouvelle forêt. Inutile d'entrer dans les détails :

  • Ajouter le rôle Active Directory Domain Services
  • Configurer AD DS pour une nouvelle forêt, avec le nom de domaine de votre choix (mademo.fr dans mon cas) et le serveur DNS sur le DC
  • Redémarrer

J'ai également installé le rôle Active Directory Certificate Services pour avoir une CA d'entreprise dans la démo, mais ce n'est pas une obligation.

Préparation des autres VM

Une fois le DC fonctionnel, il suffit de créer toutes les autres VM, selon le tableau présenté plus haut. Pour chacune :

  • Créer la VM à partir de la galerie et du modèle Windows Server 2012 R2 Datacenter, dans le Cloud Service mademo-svc et sur le même réseau virtuel.
  • Dans la VM :
    • installer les mises à jour de Windows Update
    • renommer la machine selon le tableau et joindre le domaine mademo.fr (cela peut se faire en une seule opération et un reboot.)

Pour chaque VM, je trouve personnellement pratique de conserver un fichier .rdp (celui fourni par le site d'administration Azure lorsque l'on se connecte à une VM), ce qui évite par la suite de rouvrir le site d'administration d'Azure pour se connecter aux VM.

Pour la VM proxy, il faut également créer un endpoint pour le port 443, de façon à ce qu'elle soit joignable en HTTPS. Pour cette VM donc, créer un endpoint avec comme port public 443 et comme port privé 443. Dans mon exemple pour la machine proxy cela donne :

image

Au final, lorsque le proxy sera configuré, les flux SSL sur le port 443 seront comme indiqué sur ce schéma :

image

 

Domaine et certificat SSL

Comme précisé en introduction, j'ai fait l'acquisition d'un nom de domaine et d'un certificat SSL multi-noms. Il existe suffisamment de fournisseurs pour trouver celui qui vous convient.

Dnas la zone DNS du domaine ainsi créé il faut ajouter quelques noms sous la forme de CNAME de façon à ce que ces noms aboutissent sur nos deux Cloud Services dans Windows Azure. La méthode exacte dépend du fournisseur de noms DNS que l'on a choisi. Les noms à créer sont les suivants :

Nom Type Valeur TTL
adfs CNAME mademo-svc.cloudapp.net. 3h
enterpriseregistration CNAME mademo-svc.cloudapp.net. 3h
workfolders CNAME mademo-svc.cloudapp.net. 3h
www CNAME mademo-svc.cloudapp.net. 3h

Concernant le certificat SSL, le plus simple est d'acheter un seul certificat avec tous les noms nécessaires, cela simplifiera la mise en œuvre. Lors du processus d'achat et d'installation du certificat, il est primordial que vous exportiez le certificat avec sa clé privée dans un fichier PFX avec mot de passe. Ne vous lancez pas dans cet achat si vous n'êtes pas sûr(e) de savoir faire ces opérations.

Les noms à demander, par exemple pour un domaine mademo.fr, sont les suivants :

  • www.mademo.fr (pour la ou les applications web de test)
  • adfs.mademo.fr  (pour le serveur ADFS)
  • enterpriseregistration.mademo.fr  (pour le Workplace Join)
  • workfolders.mademo.fr  (pour les Work Folders)

Nous verrons dans les prochains articles comment configurer les différentes VM pour les scénarios à mettre en place. Mais l'article suivant se focalise spécifiquement sur ce certificat SSL.

Comments

  • Anonymous
    January 01, 2003
    Bonjour Jérémy,

    Azure impose que toutes les VM soient configurées en DHCP, même si les baux sont très longs. Si l'on force une IP statique, la VM sera déconnectée.

    Néanmoins il existe maintenant un moyen d'affecter une IP "statique", qui est en fait une réservation DHCP pour la VM. Voir ces articles de mon collègue Stanislas :

    http://blogs.technet.com/b/stanislas/archive/2014/06/11/comment-configurer-une-adresse-ip-statique-sur-une-vm-azure-existante.aspx
    http://blogs.technet.com/b/stanislas/archive/2014/06/12/microsoft-azure-iaas-comment-affecter-une-adresse-ip-statique-lors-dans-la-cr-233-ation-d-une-vm.aspx
  • Anonymous
    July 02, 2014
    Cet article fait partie d'une série : BYOD - Montage d'une plateforme de démo dans Azure - 1ère
  • Anonymous
    July 02, 2014
    Cet article fait partie d'une série : BYOD - Montage d'une plateforme de démo dans Azure - 1ère
  • Anonymous
    July 02, 2014
    Cet article fait partie d'une série :

    BYOD - Montage d'une plateforme de démo
  • Anonymous
    August 06, 2014
    Bonjour.

    Pourquoi dis-tu qu'aucune VM ne doit avoir une IP fixe ? Il me semblait qu'il était justement vivement recommandé d'attribuer une IP fixe à chaque DC.
    Par ailleurs, quelle passerelle par défaut faudrait-il indiquer dans ce cas => 192.168.1.0 ?

    Merci d'avance,
    Jérémy
  • Anonymous
    August 12, 2014
    Durant mes pérégrinations dans Azure pour le montage de mes plateformes de démo autour du BYOD et autres