Le blog technique

Introduction

DirectAccess a grandement évolué depuis sa première version sous Windows 2008 R2. Microsoft a simplifié le déploiement ce rôle tout en ajoutant des fonctionnalités supplémentaires. Ainsi, depuis Windows Server 2012, DirectAccess supporte l’authentification forte via une SmartCard ou un OTP (One Time Password). C’est le sujet de cet article où nous allons aborder plusieurs aspects de cette fonctionnalité. Tout d’abord, nous verrons le fonctionnement et les contraintes imposées sur ce type de déploiement, avant d’en réaliser un déploiement. L’usage de la Smartcard et de l’OTP sera détaillé.

La plateforme utilisée sera Windows 2012 R2. La partie OTP est composé d’un serveur multiOTP et d’un serveur radius Tekradius qui sont tous les deux gratuits et permettent de réaliser un environnement de test simplement. Nous partirons du principe que DirectAccess est déjà déployé et fonctionnel. Seuls le déploiement du service OTP et l’ajout du support de l’authentification forte dans l’infrastructure DirectAccess seront détaillés. Enfin, une infrastructure de PKI est nécessaire pour réaliser ce type de déploiement. Dans cet article, cette dernière est implémentée sur Windows 2012 R2.

Fonctionnement

Généralités

Lorsque l’utilisateur se connecte sur son ordinateur, DirectAccess tente de savoir s’il est sur le réseau interne comme dans un fonctionnement classique. Lorsque le tunnel infrastructure est monté, l’utilisateur est invité à entrer des informations d’authentification supplémentaires. Cela peut être une smartcard ou un code à usage unique (OTP). Si la fonctionnalité OTP est activée, cela active aussi obligatoirement l’authentification par smartcard (l’inverse n’étant pas réciproque). Il existe ensuite deux possibilités. S’il s’agit d’une authentification par carte à puce alors l’authentification est réalisé directement avec le certificat utilisateur.

Dans le cadre d’une authentification par OTP, les paramètres d’authentification entrés sont transmis en SSL au serveur DirectAccess avec une demande de certificat par carte à puce. En effet, cette fonctionnalité se base sur une authentification par certificat de type carte à puce (même avec un OTP). Le certificat généré possède une durée de vie très courte. Comme dans une demande de certificat par carte à puce classique, celle-ci sera signée par une entité possédant un certificat d’enrollment, c’est-à-dire donnant la possibilité de signer des demandes de certificats de carte à puce au nom d’un autre utilisateur. Dans le cadre de DirectAccess, ce seront les serveurs DirectAccess qui posséderont ces certificats d’enrollment et pourront dont signer les demandes de certificats des clients DirectAccess. Le serveur DirectAccess vérifie le code à usage unique auprès du serveur OTP. Ce dernier doit fonctionné avec un serveur radius. Le serveur DirectAccess s’adresse au serveur radius pour effectuer la vérification de l’authentification. Si le code à usage unique est correct, il signe la demande de certificat et la transmet au client DirectAccess. Le client transmet cette demande signée à l’autorité de certification et stocke le certificat associé. Le client se comporte désormais comme un client authentifié via carte à puce.

Voici un schéma récapitulatif de la cinématique de connexion pour l’OTP :

1 et 2/ Connexion à l’annuaire Active Directory via le tunnel infrastructure.

3/ Des paramètres d’authentification supplémentaires sont demandés pour monter le tunnel utilisateur

4/ Envoie du code à usage unique récupéré sur un périphérique (smartphone par exemple) et d’une demande de certificat de logon OTP via une connexion SSL avec le serveur DirectAccess.

5 et 6/ Communication du serveur DirectAccess avec le serveur Radius

7/ Le serveur radius contacte le serveur OTP pour vérifier le code à usage unique.

8 et 9/ Le serveur radius remonte le succès ou l’échec de l’authentification auprès du serveur DirectAccess

10/ Si l’authentification a réussi, le serveur DirectAccess signe la demande de certificat de logon OTP avec son certificat d’enrollment et l’envoie au client DirectAccess.

11 et 12/ Le client DirectAccess envoie la demande de certificat signée à l’autorité de certification au travers du serveur DirectAccess. L’autorité de certification renvoie le certificat de logon OTP associé.

13/ Le client DirectAccess récupère le certificat, le stocke et réalise une authentification Kerberos (non représentée ici) via carte à puce pour monter le tunnel utilisateur.

Si l’authentification par carte à puce est réalisée alors le schéma s’arrête à l’étape 4 et cette dernière se déroule au travers du tunnel infrastructure.

Contraintes

Comme vu dans son fonctionnement, ce type de déploiement nécessite forcément une infrastructure de PKI. L’option force tunneling (non activée par défaut) ne peut pas être activée dans un déploiement avec l’OTP car ce type d’authentification nécessite une connexion SSL en dehors du tunnel IPSec pour que le client puisse transmettre ces paramètres d’authentification supplémentaires. De plus, lors d’un déploiement utilisant IPHTTPS avec des équipements réseaux se trouvant entre le client et le(s) serveur(s) DirectAccess (comme un load balancer), ceux-ci ne doivent pas décrypter le flux SSL (fonctionnement en mode path through).

Client Windows 8

Pour les clients utilisant cette version de Windows, l’activation de l’authentification OTP ne permet plus d’utiliser le “null encryption” sur les connexions IPHTTPS. Pour rappel, cela permet d’éviter une double encryption (IPSec et flux IPHTTPS). Cela peut donc affecter les performances des connexions utilisateurs.

Clients Windows 7

Les clients Windows 7 doivent obligatoirement posséder le DirectAccess Connectivity Assistant v2.0 (http://www.microsoft.com/en-us/download/details.aspx?id=29039). Un popup permettant d’insérer des paramètres d’authentification supplémentaires apparait lorsque cela est nécessaire. Sa configuration est détaillé dans l’article suivant : http://blog.piservices.fr/post/DirectAccess-Conseils-et-Astuces.aspx.

Déploiement

Généralités

Si vous ne souhaitez configurer que l’authentification par Smartcard alors vous pouvez vous rendre directement sur le chapitre nommé “Configuration de DirectAccess”. Les autres chapitres sont dédiés au déploiement de l’authentification par OTP.

Installation et configuration de multiOTP

Tout d’abord, il faut commencer par récupérer les binaires de multiOTP sur le site suivant : http://www.multiotp.net/. Une fois l’archive extraite, la configuration peut être réalisée via une invite de commande. Celle-ci va nous permettre de réaliser une synchronisation des comptes utilisateurs Active Directory afin qu’ils soient présent dans multiOTP. Ci-dessous, vous trouverez les commandes à exécuter commentées :

Nous pouvons ensuite lancer une synchronisation via la commande suivante :

Cette dernière affichera les utilisateurs créés ainsi que les éventuelles erreurs de synchronisation. Cette commande est à insérer dans une tâche planifiée pour exécuter une synchronisation à intervalle régulier. Pour chaque utilisateur, un fichier est créé dans le sous dossiers “Users” de multiOTP.

Dans ce déploiement les utilisateurs récupère le code à usage unique via Google Authenticator (qui peut s’installer sur tous les téléphones mobiles android, windows phone et iOS). Pour configurer le client Google Authenticator, il est nécessaire de générer un QR Code pour chaque utilisateur que ce dernier scannera avec son téléphone. Pour se faire, il faut exécuter la commande ci-dessous :

NB : Pensez à remplacer NOM_USER par le nom de l’utilisateur pour lequel vous générer le QR Code et NOM_FICHIER par le nom du fichier image. Le fichier peut être envoyé à l’utilisateur afin qu’il puisse ajouter son compte dans Google Authenticator. L’OTP est normalement opérationnelle. Vous pouvez effectuer des tests de connexion avec la commande suivante :

NB : Pensez à remplacer NOM_USER par le nom de l’utilisateur et CODE par le le code à usage unique fourni par Google Authenticator.

Si l’opération réussi, vous obtenez un résultat similaire à l’image ci-dessous :

Astuce : Si vous vous trompez souvent de code (6 échecs) alors votre compte peut être bloqué ou votre authentification retardée de 300 secondes (3 échecs). Pour débloquer un compte il faut lancer la commande suivante :

Vous pouvez modifier le comportement de multiOTP (nombre de fois avant que le compte ne soit bloqué ou que l’authentification soit retardée ainsi que le délai avant la prochaine tentative de connexion) via les commandes ci-dessous :

Installation et configuration de TekRadius

Cette étape consiste à configurer un serveur radius avec lequel DirectAcces va communiquer. Ce dernier doit pouvoir s’intégrer avec multiOTP et est donc installé sur le même serveur que celui-ci. Pour rappel, c’est par lui que transite la vérification du code à usage unique. Les deux serveurs recommandés avec multiOTP sont FreeRadius et TekRadius LT. J’ai choisi le second qui est supporté nativement sur Windows (FreeRadius est un portage linux) et qui bénéficie d’une interface graphique permettant de la configurer simplement. Les binaires peuvent être récupérés sur http://www.kaplansoft.com/download.html.

Il faut ensuite exécuter le fichier setupe.exe afin d’installer l’outil.

La configuration principale se fait dans l’onglet “user” de l’interface qui s’ouvre en cliquant sur “TekRadius LT Manager”. Il faut créer un utilisateur par défaut (que l’on doit nommé “default”) puis ajouter le lancement d’un programme externe lorsqu’une requête sera effectuée par le serveur DirectAccess. Le programme lancé sera multiOTP. Dans la section “Attribute”, il faut sélectionner l’option “Check”, puis définir l’action effectuée à “External-Executable” et enfin insérez la commande exécutée par TekRadius comme suit : C:\multiotp\multiotp.exe %ietf|1% %ietf|2% (il est supposé ici que multiOTP est déployé dans “C:\multiOTP\”).

Dans l’onglet client, il faut ajouter notre server DirectAcces afin que ce dernier soit autorisé à communiquer avec TekRadius. Il faut insérer l’IP du serveur DirectAccess puis le secret (code utilisé pour communiquer) et enfin cliquez sur le bouton “Add/Update”.

Enfin dans la section “Service Parameters” de l’onglet “Settings” , on peut changer le port utilisé par TekRadius (par défaut 1812 UDP&TCP) ainsi que le niveau de trace généré par l’outil (je vous conseille de le définir à Debug dans un premier temps afin de valider la configuration, cela permet d’identifier clairement les éventuelles erreurs de configuration). On termine la configuration en cliquant sur le bouton “Save Settings” et en lançant le service via le bouton à gauche de ce dernier.

Le serveur TekRadius est à présent opérationnel.

Configuration des modèles de certificats

Certificat d’enrollment (signature des demandes de certificat OTP) :

Lancer la console de gestion des modèles de certificat. Choisir le modèle “Computer” puis dupliquer le (clic droit “Duplicate template”).

Dans l’onglet “Compatibility”, définissez à Windows 2012 R2 la valeur du champ “Certification Authority” et à Windows 8.1 / Windows Server 2012 R2 celle du champ “Certificat Recipient”. Cette valeur est à adapter selon le système d’exploitation utilisé sur votre autorité de certification et vos serveurs DirectAccess.

Dans l’onglet “General”, définissez un nom ainsi que la durée de vie du certificat et la période avant son expiration durant laquelle le serveur DirectAccess pour renouveler son certificat.

Dans l’onglet “Security”, ajouter vos serveurs DirectAccess (via le bouton “Add”) et donner leurs les permissions de lecteur (“Read”), d’enrollement (“Enroll”) et d’autoenrollement (“Autoenroll”).

Pour les utilisateurs authentifiés (“Authenticated Users”), laissez uniquement la permission de lecture.

Supprimez la permission d’enrollement (“Enroll”) sur le groupe des ordinateurs du domaine (“Domain computers”).

Enfin, pour les groupes administrateurs du domaine (“Domain Admins”) et administrateur de l’entreprise, définissez la permission à contrôle total (“Full Control”).

Dans l’onglet “Subject Name”, sélectionner l’option “DNS name” dans la liste déroulante “Subject Name format” et cocher la case “DNS name” sous “Include this information in alternate subject name” afin d’ajouter le nom DNS de l’ordinateur trouvé dans l’annuaire Active Directory en tant que sujet du certificat mais aussi comme SAN (subject alternative name).

Enfin, dans “Extensions”, il faut sélectionner le champ “Application Policies” et supprimer toutes les entrées existantes. Il est ensuite nécessaire de cliquer sur “Add” puis “New” et d’ajouter un nom ainsi que la valeur “1.3.6.1.4.1.311.81.1.1” dans le champ “Object Identifier”. La création de ce modèle est terminée.

Certificat OTP :

Dans la console de gestion des modèles de certificat. Choisir le modèle “Smartcard Logon” puis dupliquer le (clic droit “Duplicate template”).

Dans l’onglet “Compatibility”, définissez à Windows 2012 R2 la valeur du champ “Certification Authority” et à Windows 7 / Windows Server 2008 R2 celle du champ “Certificat Recipient”. Cela correspond à la version du système d’exploitation minimale pour nos clients DirectAccess. Si vous n’utiliser pas de client sous Windows 7, vous pouvez changer cette valeur à Windows 8 ou Windows 8.1 en fonction de vos besoins.

Dans l’onglet “General”, définissez un nom ainsi que la durée de vie du certificat. La période de renouvellement doit être nulle.

Dans l’onglet “Security”, il faut définir les permissions du groupe des utilisateurs authentifiés (“Authenticated Users”) à “Read” et “Enroll”.

Il est aussi nécessaire de donner les permissions de contrôle total (“Full Control”) aux groupes administrateurs du domaine et administrateurs de l’entreprise.

Dans l’onglet “Subject Name”, sélectionnez l’option “Full Distinguished Name” dans la liste déroulante “Subject Name format” et cocher la case “User principal name (UPN)” sous “Include this information in alternate subject name”.

Dans l’onglet “Server”, cocher la case “Do not store certificates and requests in the CA database” afin de ne pas polluer la base de donnée de l’infrastructure PKI lors des connexions des clients DirectAccess.

Dans l’onglet “Issuance Requirements”, vérifier que la case “This number of authorized signatures » est cochée et insérez la valeur 1. Vérifiez que le champ “Policy type required in signature” possède la valeur “Application Policy” et choisissez le modèle créé précédemment (DirectAccess OTP RA) pour le champ “Application Policy”. Cela permet de définir le certificat ayant le droit de signer des requêtes de certificat.

Enfin, dans “Extensions”, il faut sélectionner le champ “Application Policies” et supprimer toutes les entrées existantes sauf “Smart Card Logon”. La création de ce second modèle est terminée.

Ajout des modèles à l’infrastructure PKI :

Dans la console de gestion de l’autorité de certification (“Certificate Authority”), il est nécessaire de publier les modèles qui viennent d’être créé. Cette opération se réalise dans l’onglet “Certificate Templates”. Il suffit de faire un clic droit et de choisir l’option “Certificate Template to Issue”. Il faut sélectionner les deux modèles créés précédemment et valider avec le bouton “OK”.

Enfin, afin d’autoriser la PKI à ne pas stocker certaines demandes de certificat ou certains certificat, il faut exécuter la commande ci-dessous :

Il vous sera ensuite demandé de redémarrer le service Active Directory Certificate Services pour que le changement soit pris en compte.

Configuration de DirectAccess

Nous pouvons maintenant configurer DirectAccess afin qu’elle fonctionne avec l’authentification forte (Smartcard ou OTP).

Pour réaliser cette étape, il faut se rendre dans la console “Remote Access Management” permettant de configurer son infrastructure DirectAccess. Dans la section “Configuration”, il faut éditer l’étape 2 nommée “Remote Access Server” (Bouton “Edit”).

Lorsque l’assistant s’ouvre, il faut ajouter des paramètres sur l’onglet nommé “Authentication”. Par défaut, la case “Active Directory Credential” est sélectionnée dans “User Authentication”. Pour activer uniquement l’authentification par carte à puce, il suffit de sélectionner la case “Two-factor authentication” et la configuration est terminée. Si vous souhaitez également activer l’authentification par OTP, il faut cocher la case “Use OTP”. Cela activera des onglets de configuration supplémentaires.

Dans la section “OTP Radius Server”, il faut indiquer le nom DNS ou l’IP du serveur TekRadius que nous avons installé précédemment ainsi que le secret (via le bouton “Change”) que nous avons défini dans la section client de l’outil et enfin le port s’il ne s’agit pas de celui par défaut (1812).

Dans l’onglet “OTP CA Servers”, il convient de renseigner l’autorité de certification délivrant les certificats dont nous avons créé les modèles (l’ajout se fait via le bouton “Add”).

NB : Vous pouvez rencontrez une erreur indiquant qu’aucune autorité de certification n’a pu être détectée. Il s’agit d’un bug de l’assistant graphique corrigé par un hotfix disponible en suivant ce lien : https://support.microsoft.com/fr-fr/kb/3047733 (Toutefois, il reste possible de réaliser la configuration via Powershell sans le hotfix).

Dans l’onglet “OTP Certificate Templates”, il faut indiquer le modèle utilisé pour l’authentification par OTP puis le modèle permettant de signer les requêtes de certificat OTP.

Par défaut, tous les utilisateurs doivent s’authentifier via carte à puce ou OTP. Cependant, vous pouvez spécifier un groupe d’utilisateurs pouvant s’authentifier uniquement grâce à l’authentification intégré dans la section “OTP Exemptions”. Vous pouvez ensuite valider cet assistant.

Dans l’étape 3 de la configuration de DirectAccess, il est nécessaire d’effectuer une modification lorsque l’on configure l’OTP. Il faut autoriser les clients DirectAccess à contacter l’autorité de certification délivrant les certificats pour l’authentification par OTP avant qu’il n’est accès aux ressources internes de l’entreprise. Cela leur permet d’obtenir le certificat pour monter le tunnel utilisateur. Dans la section “Management” de l’assistant, il convient d’indiquer le nom DNS de l’autorité de certification sur laquelle nous avons ajouté les modèles précédemment créés.

Il est ensuite nécessaire d’appliquer le changement de configuration (ce bouton apparait en dessous de la vue globale de configuration de DirectAccess).

Pour vérifier que le service est fonctionnel, nous pouvons nous rendre dans l’onglet “Operations Status” de la console de gestion d’accès à distance.

Il est aussi possible de vérifier qu’un site IIS a été créé sur le serveur. Ce dernier est nommé “DAOtpSite”.

Enfin, en ouvrant un navigateur sur le serveur, on peut vérifier que ce site est fonctionnel via l’url : https://localhost/DAOtpauth.dll

Vous pouvez maintenant mettre à jour les stratégies de groupes de vos postes clients (gpupdate /force) et tester l’authentification en vous connectant à distance.

Si vous rencontrez des erreurs sur l’OTP, n’hésitez pas à regarder le journal d’évènements “OTPCredentialProvider” (dans “Applications and Services Logs”) de votre poste client ainsi que les traces générés par TekRadius sur le serveur radius (présent dans le répertoire Logs du dossier d’installation de TekRadius). Nous pouvons d’ailleurs remarqué qu’un utilisateur nommé DAProbeUser tente de s’authentifier à intervalle régulier. Comme ce dernier n’existe pas dans multiOTP, une erreur est remontée. Ce comportement est tout à fait normal. Il s’agit simplement du sonde DirectAccess permettant de tester la disponibilité de l’OTP.

NB : Vous pouvez rencontrez l’erreur 0x80040001 sur votre client lorsque vous tentez de vous authentifier via OTP. Il s’agit d’un bug qui se corrige en installant la KB suivante :

• Windows 8 : https://support.microsoft.com/en-us/kb/2973071

• Windows 7 : https://support.microsoft.com/en-us/kb/2939489