Introduction
Même si l'implémentation de DirectAccess s'est fortement simplifiée depuis Windows 2012 R2, il est possible de rencontrer de nombreuses difficultés lorsque le déploiement se fait en entreprise et non dans un lab. En effet, les postes clients, les équipements réseaux et bien d'autres facteurs peuvent influer sur le bon fonctionnement de cette technologie. Cet article à pour but de regrouper des conseils et des astuces pour réussir son déploiement de DirectAccess plus rapidement et est basé sur un retour d'expérience. Ainsi, j'évoquerai notamment les configurations non supportées, les outils pour dépanner un déploiement et quelques conseils lors de l’implémentation de son infrastructure DirectAccess.
NB : Cet article se base sur la version intégrée à Windows 2012 R2 de DirectAccess.
Configurations non supportées
Généralités :
Vous trouverez ci-dessous 2 liens vous indiquant les configurations non supportées et les types de déploiement possibles :
Manage Out et ISATAP :
Le Manage Out est la fonctionnalité permettant de gérer un client DirectAccess à distance. Cela peut offrir la possibilité à SCCM d'interagir avec l’ordinateur distant ou encore de se connecter à distance en remote desktop. Cependant, cela nécessite d'être en IPv6 natif. En effet, selon technet, bien que l'ISATAP soit fonctionnel, son utilisation n'est pas supportée. De plus, son déploiement n'est pas possible dans un environnement multisite ou avec du load balancing.
Modification des stratégies de groupes :
La modification des stratégies de groupes créés par DirectAccess n'est pas supportée.
Certificats à courbes elliptiques :
Les algorithmes de la suite B (dont font partie les algorithmes à courbes elliptiques) sont supportés depuis DirectAccess sous Windows 2008 R2 (https://technet.microsoft.com/en-us/library/ee382307(v=ws.10).aspx) et doivent pouvoir être utilisés pour les certificats ordinateurs . Cependant, il n'existe aucune documentation permettant de les utiliser avec DirectAccess. Aussi, le choix des algorithmes utilisés se fait au niveau des règles de connexion qui sont paramétrées par les stratégies de groupes DirectAccess. Par défaut, la règle de connexion utilise l'algorithme RSA. Pour le changer il faut se rendre dans les stratégies de groupe puis modifier les règles suivantes :
-
GPO DirectAccess Client Settings : DirectAccess Policy-ClientToCorp
-
GPO DirectAccess Client Settings : DirectAccess Policy-ClientToInfra
-
GPO DirectAccess Server Settings : DirectAccess Policy-DAServerToCorp
-
GPO DirectAccess Server Settings : DirectAccess Policy-DAServerToInfra
Les règles s'éditent dans “Computer Configuration > Windows Settings > Security Settings > Windows Firewall with Advanced Security”. Dans l'onglet “Authentication”, il faut cliquer sur le bouton “Customize” puis éditer la méthode d'authentification utilisant des certificats ordinateurs en la sélectionnant et en cliquant sur “Edit”.
Enfin, le champ “Signing Algorithm” peut être changé avec le bon algorithme.
Cependant, nous avons vu précédemment que la modification de stratégies de groupe DirectAccess n'est pas supportée. De plus, la customisation proposée sera écrasée à chaque modification de la configuration DirectAccess. L'une des solutions pourrait être de créer une stratégie de groupes avec des règles de connexion identiques mais incluant les algorithmes à courbes elliptiques. Cependant, il n'y a aucune certitude que cette règle sera traitée avant l'original car il n'y a pas de priorité sur celles-ci. Il existe donc un flou autour du déploiement de certificats signés par un algorithme à courbes elliptiques.
Contraintes système d'exploitation clients
Windows 8 et supérieur
Les versions Windows 8 clients et supérieures supportent toutes les fonctionnalités de DirectAccess ainsi que tous les types de déploiements. De plus DirectAccess sur Windows 8 ne nécessite pas d'avoir une infrastructure PKI (hormis dans le cas d'une authentification forte, y compris OTP) et fonctionne alors avec des certificats auto signés. Cependant vous pouvez rencontrez quelques contraintes lors de l'activation de l'authentification forte (http://blog.piservices.fr/post/DirectAccess-Deploiement-de-lauthentification-forte.aspx).
Windows 7
Le déploiement de DirectAccess sur des clients Windows 7 nécessite obligatoirement d'avoir une infrastructure PKI (certificat ordinateur en auto enrollment). De plus, si vous souhaitez une infrastrcture en haute disponibilité, sachez que vous ne pourrez opter que pour le load balancing. La fonctionnalité multisite permettant de posséder plusieurs serveurs DirectAccess en standalone tout en laissant le choix au client sur lequel il souhaite se connecter n'est pas disponible pour cette version de Windows. Aussi, si sur Windows 8, la méthode de transition IPv6 / IPv4 recommandée est l'IPHTTPS (notamment par sa simplicité de mise en oeuvre), ce n'est pas le choix le plus évident sous Windows 7. En effet, l'IPHTTPS réalise une double encryption des flux DirectAccess, ce qui peut causer des problèmes de performances. Pour rappel, depuis Windows 8, le tunnel IPSec étant sécurisé, la communication IPHTTPS ne réalise plus d'encryption évitant ainsi de réaliser deux fois cette opération (IPHTTPS et tunnel IPSec).
Troubleshooting
Netsh
L’outil en ligne de commande Netsh est sans doute l’un des outils les plus utiles pour effectuer un premier debug. Pour chaque interface liée à une technologie de transition IPv6/IPv4, nous pouvons obtenir un statut de connexion :
-
6To4 : netsh interface 6to4 show state
-
Teredo : netsh interface teredo show state
-
IPHTTPS : netsh interface httpstunnel show interfaces
Par exemple, lorsqu’il y a un problème avec la vérification de la CRL sur l’interface IPHTTPS, nous obtenons le code d’erreur 0x80092013 (pour l’attribut “Last Error Code”). Une recherche sur votre code d’erreur vous permettra d’identifier rapidement la cause d’une mauvaise connexion.
D’autre part Netsh peut vous aider à configurer vos interface réseaux. Il est d’ailleurs recommandé de désactiver les interfaces non utilisées. Par exemple, 6To4 qui n’est que très rarement utilisé peut être désactivé via la commande suivante :
Journaux d’événements
Vous pouvez retrouver des informations utiles dans l’observateur d’évènements pour dépanner votre connexion DirectAccess, Le journal “Operational” présent dans “Applications and services Logs > Microsoft > Windows > CAPI2” vous donnera des informations liés à vos certificats (erreur sur la vérification de la CRL, certificat expiré,…). Il convient de l’activer avant de pouvoir l’utiliser. en cliquant sur “Enable Log” via un clic droit sur le journal.
Aussi, le journal de sécurité peut vous renseigner sur les connexions IPSec qui ont réussies ou échouées. Pour se faire, il faut activer l’audit via la commande suivante :
En cas d’erreur, les id des évènements importants à retrouver sont les suivants : 4653, 4654, 4984.
Enfin, en cas de déploiement d’une infrastructure avec authentification forte via OTP, le journal “OTPCredentialProvider” présent dans “Applications and services Logs”, vous renseignera sur les évènements liés à cette méthode d’authentification.
Directaccess Connectivity Assistant
Le Directaccess connectivity assistant (DCA) est un assistant de connexion pour DirectAccess. Ce dernier est nativement disponible sur Windows 8 et supérieur mais nécessite d'être déployé sur Windows 7 (http://www.microsoft.com/en-us/download/details.aspx?id=29039). Il est d'ailleurs obligatoire dans le cadre de l'activation de l'authentification forte (via OTP ou carte à puce).
En marge du déploiement du client, il faut intégré le fichier ADMX dans le magasin central Active Directory afin de pouvoir le configurer par stratégie de groupe sur tous les postes utilisateurs concernés. Il convient donc de créer une stratégie de groupe possédant à minima les paramètres suivants (présent dans “Computer Configuration > Policies > Administratives Templates” ) :
Le paramètre “Corporate resources”, correspond à des ressources dont l'accès est testé pour valider que la connexion DirectAccess est opérationnelle. Attention : ces tests sont différents du serveur NLS (Network Location Server) qui permet à Windows de savoir s'il doit tenter de se connecter au réseau d'entreprise via DirectAccess. Ici, il s'agit simplement de tests réalisés par le DCA. La connexion DirectAccess peut être opérationnelle alors que l'une des ressources n'est pas disponible (et la connexion sera alors indiquée comme non fonctionnelle). Il est donc conseillé de fournir des ressources redondées. De plus, pour que DCA fonctionne de façon optimale, il est nécessaire d'indiquer une ressource de type PING et une autre de type HTTP (pointant sur un site web de votre infrastructure qui n’est pas le serveur NLS).
Le paramètre DTEs indique les points de terminaisons de la connexion DirectAccess sur le serveur. Ces derniers peuvent être obtenus de plusieurs manières. Chacune des règles “DirectAccess Policy-ClientToCorp” et “DirectAccess Policy-ClientToInfra” de la GPO cliente (“GPO DirectAccess Client Settings”) possède l'une des valeurs à renseigner. Pour l'obtenir, rendez-vous dans l'onglet “Advanced” puis cliquez sur le bouton “Customize” de la section “IPsec tunneling”. Le champ “IPv6” de la section “Remote tunnel endpoint” contient la valeur recherchée.
Celles-ci sont à indiquer au format “PING:IP_Récupérée” dans la stratégie de groupe de configuration du client DCA.
Ces valeurs peuvent aussi être récupérées dans le registre via la commande Powershell suivante :
Cet outil permet de générer des logs exploitables par un administrateur pour débugguer des problèmes de connexions (vérification des certificats, test des connexions teredo, 6TO4 et iphttps, configuration firewall, ...). Pour se faire, l'utilisateur qui rencontre une erreur devra effectuer un clic droit sur le client (dans la barre des tâches) et cliquer sur “Advances Diagnostics”. Cela aura pour effet de générer une page html contenant les résultats dans le répertoire “C:\Users\NOM_USER\AppData\Local\Microsoft\DCA”.
DirectAccess Client Troubleshooting Tool
Cet outil permet de débugguer une connexion DirectAccess en la vérifiant point par point (Test certificats, firewall, ...). Ce dernier est disponible à partir de Windows (http://www.microsoft.com/en-us/download/details.aspx?id=41938), cependant, veillez à l'installer sur un système d'exploitation avec langue US sinon vous rencontrerez une erreur pendant l'exécution des tests.
Astuces
Mise à jour du système d'exploitation
Cela peut paraître normal mais il est impératif de mettre à jour continuellement vos serveurs DirectAccess et surtout avant l'implémentation de cette fonctionnalité. En effet, un très grand nombre de correctifs concernant DirectAccess ont été mis à disposition depuis la sortie de Windows 2012 R2.
Configuration IP et changement
Il s'agit plus d'un conseil que d'une astuce mais je vous recommande fortement de ne jamais changer la configuration IP d'un serveur sur lequel DirectAccess est configuré. En effet, cela peut avoir des effets de bord sur le serveur lui-même en dehors de la fonctionnalité DirectAccess qui peut ne plus être configurable. Vous pouvez vous retrouver confronter à devoir remettre l'ordinateur dans le domaine ou réinstaller la machine elle-même.
Configuration IP et load balancing
Si vous envisager un déploiement avec du load balancing, l’IP de la VIP (HLB ou NLB) sera l'IP original de votre serveur DirectAccess lorsque vous configurerez la haute disponibilité. Il faut donc tenir compte de cet aspect lorsque l'on fixe l'IP de son premier serveur DirectAccess lors de ce type de déploiement.
Teredo, 6To4, IPHTTPS et NAT
Dans le cas où l'infrastructure DirectAccess est derrière du NAT, il n'est possible d'utiliser que l'IPHTTPS (quelque soit le mode de déploiement : load banlancing, standalone).
OTP et Carte à puces
Je vous invite à consulter le lien suivant concernant le déploiement de l'authentification forte pour DirectAccess : http://blog.piservices.fr/post/DirectAccess-Deploiement-de-lauthentification-forte.aspx. Ce dernier explique le fonctionnement mais aussi les éventuelles erreurs que vous pouvez rencontrer et comment les corriger.