La fonctionnalité « DirectAccess » ne fait pas partie des rôles supportés sur la plateforme AZURE.
Outre le fait que la mise en service de DirectAccess dans le Cloud ne présente pas d’intérêt particulier dans un contexte de production, il existe des raisons techniques qui justifient cette absence de support de la part de Microsoft.
C’est tout l’objet de ce billet de blog dans lequel nous allons utiliser malgré tout la fonctionnalité DirectAccess dans AZURE à des fins de démonstration fonctionnelle, en ayant bien noté les problèmes potentiels liés à ce scénario et en anticipant le cas échant les méthodes de contournement.
Scénario d’usage
Nous disposons :
- D’un contrôleur de domaine sur plateforme Windows Server 2012 R2 dans AZURE
- D’un serveur dédié au rôle DirectAccess Windows Server 2012 R2 joint au domaine
- D’un poste de travail Windows 8.1 ou Windows 10 en édition Entreprise
Les prérequis en terme d’infrastructure AZURE ne sont pas décrits ici, mais sommairement, il convient d’avoir créé préalablement le réseau virtuel, le sous réseau et ses paramètres DNS.
Pour des raisons qui seront évoquées plus loin, le serveur DirectAccess sera monté sur une plateforme Windows Server 2012R2 en mode Core, les outils d’administration DirectAccess seront implémentés sur le contrôleur de domaine.
Installation du contrôleur de domaine.
Rien de particulier sur l’installation de ce rôle auquel nous adjoindrons le rôle de serveur DNS. Bien entendu nous affecterons une adresse IP statique à ce serveur selon la méthode AZURE, c’est-à-dire depuis une console PowerShell liée à notre tenant :
Get-AzureVM –ServiceName ad-hybridcloud -Name HC-SRV-DA01 |Set-AzureStaticVNetIP –IPAddress 10.100.0.102| Update-AzureVM
L’adresse IP 10.100.0.200 sera utilisée comme serveur DNS de notre réseau virtuel, ce qui permettra aux machines connectées à ce réseau de joindre le domaine :
Installation du serveur DirectAccess.
Le serveur DirectAccess sera monté sur une plateforme Windows Server 2012R2 en mode Core. Ce type de déploiement n’étant pas proposé sur la plateforme AZURE, il nous faudra choisir un déploiement basé sur une image DATACENTER classique, puis supprimér les fonctionnalités graphiques après l’installation.
La suppression des fonctionnalités graphiques se fait en une ligne de PowerShell et nécessite un redémarrage bien entendu:
Get-WindowsFeature Server-Gui* | Remove-WindowsFeature
Après redémarrage, l’installation de DirectAccess se fait également en une ligne de PowerShell :
Add-WindowsFeature DirectAccessVPN
Nous allons affecter une adresse IP statique à notre serveur DirectAccess, cela peut être fait depuis le nouveau portail de gestion AZURE (https://portal.azure.com) ou depuis une instance PowerShell disposant du module AZURE et liée à votre tenant.
Particularités des machines virtuelles dans AZURE
Dans le Cloud AZURE, les machines virtuelles sont facturées à la consommation (machine allouée = machine facturée), nous aurons donc tout interêt à désallouer les VMs non utilisées tant que nous ne les utilisons pas.
Ceci ne pose généralement pas de problème, mais….. pour DirectAccess, la configuration du service est intimément liée à l’interface réseau. La désallocation faisant que le « matériel » présenté lors de la réallocation n’est plus strictement le même, l’interface réseau se voit attribuer un nouvel identifiant et la configuration DirectAccess est perdue.
C’est cette raison qui me pousse a utiliser DirectAccess sur une VM en mode Core, ce mode me permettant l’utilisation d’une instance A0 allouée en permanence sans exploser mon crédit AZURE (4 fois moins chère que sa voisine A1, l’instance A0 à 12 € par mois ira très bien) :
Pour la partie réseau, DirectAccess écoute les connexions entrantes en https, sur le port TCP 443. Il nous faudra donc créer le « Endpoint » correspondant sur la VM AZURE :
Déploiement de DirectAccess
Notre serveur DirectAccess fonctionnant en mode Core, les outils d’administration ont été installés sur le contrôleur de domaine.
Nous lançons la console de gestion et établissons le contact avec notre serveur DirectAccess :
Nous choisissons de ne déployer que le rôle DirectAccess :
Paramétrage de DirectAccess
Une fois le rôle déployé, il ne reste qu’à le configurer, toujours depuis la même console :
Le paramétrage étant terminé, nous pouvons vérifier que les services DirectAccess sont opérationnels :
Provisionnement d’un poste windows 10
Nous allons provisionner un compte d’ordinateur dans le domaine par la commande « Djoin » qui nous permet de faire une jonction au domaine hors ligne.
Ref : https://technet.microsoft.com/fr-fr/library/jj574150.aspx
Dans notre cas, la syntaxe utilisée est la suivante :
djoin.exe /provision /machine W10-DA01 /domain hybridcloud.local /policynames “DirectAccess Client Settings-v2” /savefile W10-DA01.txt /reuse
Cette commande nous a généré un fichier de blob à rejouer sur le poste client et provisionné le compte d’ordinateur dans le domaine, nous le mettons dans la bonne OU et le rendons membre du groupe des ordinateurs éligibles à DirectAccess :
Sur notre poste Windows 10, nous rejouons le fichier blob, préalablement copié localement, avec la commande djoin :
djoin.exe /requestodj /loadfile c:\temp\w10-DA01.txt /windowspath C:\Windows /localos
Après redémarrage, nous pouvons ouvrir une session avec un compte de domaine, rafraichir les GPO, accéder aux ressources du domaine, la connexion DirectAccess est établie :
Conclusion.
Bien qu’il ne s’agisse pas d’un rôle supporté, la fonctionnalité DirectAccess peut fonctionner à des fins de tests sur la plateforme AZURE.
Il est cependant possible que votre machine soit désallouée, soit parce que vous l’avez éteinte, soit parce que Microsoft a procédé à des opérations de maitenance sur la plateforme AZURE et déplacé la VM sur un matériel différent.
Dans ce cas, votre paramétrage DirectAccess est « perdu », mais comme vous avez pu le constater, il est très simple de le refaire, il suffira de répéter l’étape 1 du paramétrage et de réaffecter la « nouvelle » interface réseau au rôle DirectAccess.