PI Services

Le blog des collaborateurs de PI Services

DirectAccess - Mise en place d'une ferme NLS en version Core virtualisée sous Hyper-V R2

Pré-requis et architecture

Parmis les pré-requis à la mise en place de DirectAccess, un serveur Web répondant en HTTPS est nécessaire. Ce serveur, nommé NLS pour Network Location Server, ne doit pas être joignable depuis l'extérieur. En effet, sa seule et unique fonction est de permettre aux postes clients sous Windows Seven de détecter correctement leur emplacement réseau :

  • Si le serveur NLS est accessible, alors le poste client sait qu'il est connecté à l'intérieur du réseau de l'entreprise (dans ce cas, le poste ne tente pas de se connecter à l'aide des technologies DirectAccess)
  • Si le serveur NLS est inaccessible, alors le poste client sait qu'il est connecté à l'extérieur (dans ce cas, le poste tente de se connecter à l'aide des technologies DirectAccess)

Le but du serveur NLS n’est pas d’afficher un site Web complexe mais juste de répondre à une simple requête HTTP encapsulé dans du SSL. En ce qui concerne le contenu de cette page, il n'y a pas de pré-requis particulier (une page HTML vide, ou bien la page par défaut de IIS 7.5 peut tout à fait être utilisée!). Pour héberger le "rôle" NLS, Microsoft conseille de respecter les préconisations suivantes :

  • Utiliser un serveur dédié (même si il est tout à fait envisageable de réutiliser un serveur Web existant)
  • Mettre en place un site Web hautement disponible

La mise en place de la haute disponibilité sur le rôle NLS est extrêmement importante ! En effet, si le serveur NLS tombe, tous les postes de travail situés en LAN pour lesquels DirectAccess est configuré, penseront qu'ils sont à l'extérieur de l'entreprise (car le NLS ne sera pas joignable) et tenteront alors de se connecter en IPv6 à la passerelle DirectAccess ce qui perturbera leur connexion au réseau de l'entreprise !

Si l'on respecte à la lettre les préconisations de Microsoft, la mise en oeuvre du rôle NLS implique donc l'utilisation de deux serveurs Web avec équilibrage de charge réseau (load balancer matériel ou NLB). Afin de minimiser les coûts en matériel, il est tout à fait possible de virtualiser les serveurs Web sous Microsoft Hyper-V R2 et d'activer le NLB entre les deux machines virtuelles pour fournir la haute disponibilité.

Dans la suite de ce billet, vous trouverez la procédure complète mettre en place cette configuration (ferme de machines virtuelles NLS en NLB). La petite subtilité étant l'usage d'une version Core de Windows Server 2008 R2 ce qui permet de réduire encore plus l'utilisation en ressources matérielles sur les serveurs Hyper-V tout en minimisant la maintenance.

Déploiement de 2008 R2 en version core

Une fois l'installation du système en version Core réalisée dans les deux machines virtuelles, et une fois le mot de passe du compte Administrator défini, une invite de commande telle que celle-ci s'affiche :

Cmd

Une série de commande va permettre de mettre en place le serveur Web IIS 7.5.

Pour commencer la commande sconfig (nouveauté de 2008 R2), permet d'effectuer une configuration rapide (nom de la machine, jointure au domaine, configuration TCP/IP).

sconfig 

Je ne détaille pas cette partie qui ne devrait pas poser trop de soucis. En cas de doute vous pouvez vous référer à la documentation sur Technet ( http://technet.microsoft.com/en-us/library/ee441254(WS.10).aspx). Pour les amateurs de l'invite de commande, il est également possible d'exécuter ces différentes opérations à l'aide de netsh (cf. : http://technet.microsoft.com/en-us/library/ee441257(WS.10).aspx).

Une fois ces différentes opérations effectuées on peut envisager d’activer le bureau à distance pour avoir une administration plus souple.

MMC-Remote-Management

Mise en place du rôle IIS 7.5 sur 2008 R2 en version core

Une fois le système correctement configuré, le rôle serveur Web doit être installé.

Remarque : Dans un premier temps, seuls les composants basiques de IIS sont déployés afin de pouvoir disposer d'un site (enfin une page ;-) ) complètement statique.

Une nouvelle commande est apparue dans 2008 R2 pour installer les rôles et fonctionnalités offerte par la version core :

dism /online /enable-feature /featurename:IIS-WebServerRole

Pour faciliter l’administration du site, il faut activer la prise de contrôle à distance au travers de la console d’administration Internet Information Service (IIS) Management et le WAS :

dism /online /enable-feature /featurename:IIS-ManagementService

dism /online /enable-feature /featurename:WAS-WindowsActivationService dism /online /enable-feature /featurename:WAS-ConfigurationAPI

Attention cela ne suffit pas, il faut aussi autoriser l’administration à distance par MMC en ajoutant la clé de registre suivante :

Reg Add HKLM\Software\Microsoft\WebManagement\Server /V EnableRemoteManagement /T REG_DWORD /D 1

La dernière étape consiste à démarrer le service de management et à modifier son type de démarrage en automatique pour qu'il se lance à chaque démarrage de la machine :

sc config wmsvc start= auto

net start wmsvc

Une fois ces étapes réalisées, le site Web par défaut de IIS doit être visible en saisissant http://<IP-SERVEUR> et le rôle IIS du serveur Core peut être configuré à distance à la console MMC graphique !

Installation du certificat et passage en HTTPS

Pour avoir accès au site en HTTPS il reste deux choses à faire. La première consiste à installer le certificat contenant la clé privée en ligne de commande :

certutil –importPFX  “C:\certificat.pfx”

Lors de son exécution la commande certutil nécessite la saisie du mot de passe pour valider l’import du PFX.

Une fois le certificat importé dans le magasin de certificat de l'ordinateur, il faut configurer IIS de manière à ce qu'il le prenne en compte. Pour cela, vous pouvez utiliser la console IIS Management depuis un poste distant. Il faut cliquer sur le site Web par défaut, puis sur Bindings, et enfin sélectionner le certificat voulu dans la liste déroulante (dans cet exemple le certificat se nomme "PI Services Secure Access").

Binding

A l'issue de cette étape, le site Web par défaut doit être accessible en saisissant l'URL https://<IP-SERVEUR>.

Mise en place du NLB entre les deux machines virtuelles

Remarque : Avant d'entamer la configuration du NLB sur les deux machines virtuelles, vérifiez que l'option enable spoofing of MAC address est bien activée dans les propriétés de la carte réseau sur les deux machines virtuelles (cette option se configure avec la console MMC Hyper-V Manager). Cette option est apparue avec Hyper-V R2 et permet le bon fonctionnement du NLB au sein des machines virtuelles.

Pour mettre en place le Network Load balancing, il faut commencer par installer la fonctionnalité sur chacun des serveurs de la ferme. Pour cela, saisissez la commande suivante :

Dism /online /Enable-Feature /FeatureName:NetworkLoadBalancingHeadlessServer

Une fois la fonctionnalité installée, le plus simple est d'utiliser la console Network Load Balancing Manager depuis un poste client pour configurer le cluster (la console doit être exécutée avec les "crédentials" d'un compte possédant les droits administrateur sur les serveurs Web).

Pour créer un nouveau cluster, il faut effectuer un clic droit sur Network Load Balancing Clusters, sélectionner New, puis se laisser guider par l’assistant :

 New-Cluster1 New-Cluster2

Il est possible d'affiner la configuration de la ferme NLB en précisant les ports TCP et UDP sur lesquels l'équilibrage de charge sera actif. Dans l'exemple ci-dessous, deux règles activent l'équilibrage de charge sur les ports 80 TCP et 443 TCP (seul l'équilibrage de charge sur le 443 est nécessaire à DirectAccess).

New-Cluster-Rules

Pour ajouter un nouveau membre à la ferme NLB, il faut effectuer un clic-droit sur le cluster existant, sélectionner Add Host to Cluster, puis préciser l'adresse IP du deuxième serveur Web.

New-Cluster-Membres

Une fois le second noeud ajouté et le cluster correctement convergé, il faut vérifier que le site Web est accessible en HTTPs via l'adresse IP virtuelle du cluster (saisir https://<adresse-IP-virtuelle> dans un navigateur).

La dernière étape consiste à créer une entrée dans le DNS pour pointer vers l'adresse IP virtuelle. Cette entrée DNS doit correspondre au FQDN du certificat précédemment importé (par exemple NLS.PISERVICES.FR).

Une fois l'entrée DNS créée, vérifiez que le site Web est accessible via l'URL https://nls.piservices.fr. Aucune erreur de certifiat ne doit s'afficher dans le navigateur !

Remarque : Il est possible de tester le cluster en mettant en pause l'une des deux machines virtuelles (via la console MMC Hyper-V Manager) !

A partir de cet instant la ferme de serveurs NLS est pleinement opérationnelle !

Mise en place d'une page Web dynamique sur la ferme NLS

Pour faciliter le dépannage lors de la mise en place de DirectAccess, il est souvent nécessaire de connaitre l'adresse IP utilisée par le poste de travail pour accéder au serveur NLS. Cela permet de déterminer quelle technologie de transition a été utilisée (6to4, Teredo, ISATAP, NAT64...).

Pour cela il suffit de modifier la configuration de la page par défaut des serveurs NLS afin d'afficher l’IP du client. Dans cet exemple, le langage ASP.net est utilisé.

Pour pouvoir héberger une page en ASP.net des composants supplémentaires doivent être installé sur les serveurs. Tout d’abord, il faut installer les Framework .NET 2 et 3 :

dism /online /enable-feature /featurename:NetFx2-ServerCore

dism /online /enable-feature /featurename:NetFx3-ServerCore

Les fonctionnalités ISAPI et ASP.NET doivent également être installées sur le rôle IIS :

dism /online /enable-feature /featurename:IIS-WebServerRole

dism /online /enable-feature /featurename:IIS-ISAPIFilter

dism /online /enable-feature /featurename:IIS-ISAPIExtensions

dism /online /enable-feature /featurename:IIS-NetFxExtensibility

dism /online /enable-feature /featurename:IIS-ASPNET

Enfin il faut installer le WAS et le service de gestion :

dism /online /enable-feature /featurename:IIS-ManagementService

dism /online /enable-feature /featurename:WAS-WindowsActivationService

dism /online /enable-feature /featurename:WAS-ConfigurationAPI

Pour démarrer le service de management, le rendre automatique et autoriser la gestion à distance, il faut exécuter les commandes suivantes :

Reg Add HKLM\Software\Microsoft\WebManagement\Server /V EnableRemoteManagement /T REG_DWORD /D 1

sc config wmsvc start= auto

net start wmsvc

A présent le serveur est capable d’interpréter du code ASP.net, il est donc possible de créer une page ASPX. Dans l'exemple ci-dessous, une page default.aspx a été créée et le site a été reconfiguré pour l'utiliser en document par défaut :

DefaultDocument

Voici le résultat obtenu avec les méthodes permettant de récupérer les adresses IP (seul le "body" de la page est affiché) :

<body>
    <form id="form1" runat="server">
    <div>
        Nom du serveur :    <%= Request.ServerVariables["SERVER_NAME"]%><br />
        Adresse IP du serveur :     <%= Request.ServerVariables["SERVER_ADDR"]%><br />
        Adresse IP du visiteur :     <%= Request.ServerVariables["REMOTE_ADDR"]%>
    </div>
    </form>
</body>

NLS

N'hésitez pas à laisser un commentaire sur cette procédure si vous avez des éléments à ajouter ou des précisions à demander.

2008 R2 – Activer Windows sur une version Core de Windows Server 2008 R2

Commande sconfig et activation de Windows

Les versions Core de Windows Server 2008 R2 intègrent un nouvel utilitaire nommé sconfig. Cet utilitaire permet de simplifier les tâches de configuration usuelles (installation des mises à jour Windows Update, intégration dans un domaine, activation du bureau à distance, réglage de la date et de l’heure…) via un système de menus textuels.

Malheureusement sconfig n’intègre pas d’option pour activer le système d’exploitation. Pour cela il faut toujours utiliser le script slmgr.vbs présent dans “C:\Windows\System32”.

Procédure d’activation

Voici la procédure à suivre pour effectuer l’activation avec slmgr.vbs :

Dans un premier temps il est possible d’afficher l’état d’activation du serveur en saisissant les commandes suivantes :

  • cd c:\Windows\System32
  • slmgr.vbs –xpr

Dans notre exemple le système n’est pas activé car une date de fin est annoncée pour la période de grâce.

image

Pour insérer la clé de produit dans le système il faut ensuite saisir la commande suivante :

  • slmgr.vbs –ipk AAAAA-BBBBB-CCCCC-DDDDD-EEEEE

image

image

Une fenêtre Windows Script Host doit apparaître suite à l’injection de la clé de produit. Pour débuter l’activation à travers Internet, la commande suivante doit être saisie :

  • slmgr.vbs /ato

Si l’activation est réussie, le message suivant doit apparaître au bout de quelques secondes : “Product activated successfully”.

image

Suite à l’activation du serveur, la commande slmgr.vbs –xpr doit renvoyer le message suivant “The machine is permanently activated”.

image

Positionnement d’un serveur de proxy

Si l’accès au Web est conditionné par le passage à travers un serveur de proxy, celui-ci doit être renseigné au préalable avec la commande suivante :

  • netsh winhttp set proxy <proxy-FQDN>:<proxy-port>

Dans le cas contraire une erreur de type “slui.exe 0x2a 0x80072EE2” ou “error: 0x80072EE2” se produit lors de la tentative d'activation.