I. Présentation
Beaucoup d'entreprises ont désormais une gestion des identités hybrides, Active Directory + Azure AD. Il devient alors intéressant de profiter de fonctionnalités disponibles dans Azure AD pour les exploiter sur des plateformes locales intégrées à l'Active Directory. L'une d'entre elles est l'utilisation d'une double authentification pour les connexions bureau à distance, RDP, avec des comptes à privilèges AD, grâce à Azure MFA.
Dans cet article, je vous propose un guide détaillé comprenant les choix d'architecture, les prérequis, et l'implémentation de la solution.
II. Architecture
A. Schéma de principe
Plusieurs briques sont nécessaires pour implémenter la solution :
- Passerelle RDS
- Serveur NPS (Radius)
- Contrôleurs de domaine Active Directory
- Azure AD
Le schéma ci-après décrit les échanges entre ces services :
L’authentification et la gestion de l’accès sont répartis entre les briques NPS et Passerelle RDS. Il convient de router les requêtes à la brique en charge en créant des stratégies.
| Serveur |
Nom stratégie (personnalisable) |
Console pour la configuration |
Description |
| RDS Gateway |
RAP1-Ressources autorisees |
RD Gateway Manager |
Détermine quelles ressources du réseau local seront accessibles via la passerelle RDS |
| RDS Gateway |
ToMFA |
NPS |
Stratégie de connexion pour définir dans quel contexte de connexion de l’utilisateur la demande doit être routée vers le serveur NPS central |
| RDS Gateway |
MFA for all users |
NPS |
Stratégie réseau pour contrôler si la machine est autorisée à se connecter au réseau |
| NPS server |
From RDS Gateway |
NPS |
Stratégie de connexion permettant de récupérer et de traiter la demande en provenance de la passerelle RDS |
| NPS server |
To RDS Gateway |
NPS |
Stratégie de connexion autorisant le transfert de la réponse vers la passerelle RDS |
| NPS server |
RDS Gateway Policy |
NPS |
Stratégie réseau qui spécifie les méthodes d’authentification à utiliser pour les échanges avec la passerelle RDS |
B. Choix d’architecture
Il pourrait être tentant d’utiliser le service NPS implémenté lors du déploiement d’une passerelle RDS, mais ce n’est pas supporté par Microsoft, la documentation le stipule. De plus, vous n’obtiendrez pas le résultat escompté, testé et vérifié !
Par ailleurs, l’installation de l’extension Azure MFA sur la machine exige, par défaut, que tous les utilisateurs qui tentent une authentification aient Azure MFA activé. Cela veut dire que si le serveur est utilisé pour gérer l’authentification des réseaux Wifi, le MFA est rendu obligatoire à chaque requête d’authentification. Il existe bien une entrée de registres (REQUIRE_USER_MATCH) permettant de modifier ce comportement, mais je n’ai pas eu de bons résultats avec elle.
Ma recommandation est donc d’utiliser un serveur NPS dédié.
Côté Passerelle RDS, les choses sont plus simples. Considérant que les connexions RDP seront à destination de serveurs internes, le rôle peut parfaitement être colocalisé sur un serveur local, pourquoi pas un serveur de la plateforme RDS si vous en disposez d’une.
C. Prérequis
Au-delà des briques citées précédemment et que je rappelle néanmoins dans le tableau suivant, d’autres prérequis sont nécessaires :
| Synchronisation comptes |
Les comptes issus de l’AD qui serviront pour l’authentification avec MFA doivent être synchronisés. L’UPN peut utiliser le domaine technique en onmicrosoft.com ou un domaine personnalisé. |
| Licences |
La licence Azure AD Multi-Factor Authentication doit être affectée au compte Azure AD qui sera utilisé pour s’authentifier sur le serveur cible en RDP. Je vous recommande le site M365 Maps pour savoir dans quel pack de licences, elle est disponible. |
| Enrollement MFA |
Les comptes synchronisés doivent être inscrits pour Azure MFA : aka.ms/MFAsetup
Les méthodes compatibles sont Push Notification (Approuver/Refuser) et l’appel téléphonique. L’une ou l’autre méthode doit être désignée comme méthode primaire. |
| Azure Tenant ID |
Il peut être récupéré depuis le portail d’administration Entra ID (Azure AD) |
| Parefeu
|
Le serveur NPS doit pouvoir communiquer sur le port TCP 443 vers les URL suivantes :
https://login.microsoftonline.com
https://credentials.azure.com
https://strongauthenticationservice.auth.microsoft.com
https://adnotifications.windowsazure.com |
| Serveurs infra |
Les serveurs jouant les rôles DC, NPS et RDS Gateway sont utilisés |
| Certificat |
La passerelle RDS nécessite un certificat de type Web server. Le nom du serveur ou l’alias utilisé pour s’y connecter doit figurer comme nom d’objet dans le certificat. Un certificat wildcard peut également être utilisé.
Il peut s’agir d’un certificat issu d’une autorité interne ou d’une autorité publique. |
| Groupe AD |
Pour définir quels utilisateurs pourront se connecter au travers de la passerelle RDS. |
C. Schéma plateforme de démo
Pour ce tutoriel, j’ai choisi l’architecture suivante :
Les prérequis étant validés, il est temps de se lancer. Commençons par la passerelle RDS !
III. Passerelle RDS
A. Ajout du rôle Passerelle RDS
Depuis le Gestionnaire de serveur, ajoutez le rôle de passerelle RDS :
Après cet écran de choix du service de rôle, cliquer sur Suivant en laissant les options par défaut.
Une fois l’installation terminée, lancer la console de gestion de certificats : certlm.msc
Importer un certificat existant ou demander un nouveau certificat depuis votre autorité interne.
Ouvrez la console Remote Desktop Gateway Manager.
Depuis les propriétés du serveur, cliquer sur "Import Certificate" pour sélectionner le certificat correspondant.
Toujours depuis les propriétés du serveur, dans l’onglet RD CAP Store, on indique à la passerelle RDS quel serveur central Radius doit être utilisé pour l’authentification. Un secret partagé vous sera demandé lors de la configuration. Nous le réutiliserons un peu plus tard.
B. Stratégie d’accès aux ressources
Il convient à présent de créer une stratégie pour indiquer quel groupe d’utilisateurs peut accéder à quelle machine.
Allez sous : Policies > Resource Authorization Policies.
Cliquez sur "Create New Policy", depuis le volet Actions, puis "Wizard".
Sur l’écran suivant, laisser sélectionner "Create only a RD RAP" puis cliquer sur Suivant.
Indiquez le nom de la stratégie.
Spécifiez le groupe d’utilisateurs autorisés à communiquer avec la passerelle RDS.
Ici, vous pouvez faire le choix d’autoriser l’accès à toutes les machines du réseau ou seulement à celles appartenant à un groupe. Dans mon cas, j’ai choisi « Allow user to connect to any network ressource (computer) ».
Sauf à vouloir utiliser un port différent du TCP 3389 pour se connecter aux machines derrière la passerelle RDS, laissez "Allow connections only to port 3389".
Le résumé s’affiche, il ne reste plus qu’à cliquer sur le bouton "Finish".
Petit contrôle intermédiaire avant de passer à la suite. Si vous revenez sur le serveur, l’écran de status doit ressembler à celui-ci :
C. Console NPS : client RADIUS
Attention : les actions suivantes sont bien à dérouler sur le serveur Passerelle RDS depuis la console NPS locale et non depuis le serveur NPS
Le serveur RADIUS central doit être client de la passerelle RDS, en effet le retour de l’authentification passe par une validation du RDS Gateway, au travers du NPS local.
Ouvrir la console Network Policy Server.
À la rubrique "RADIUS clients", effectuez un clic droit, "New".
Indiquez un nom convivial simple, nous en aurons besoin plus tard. Spécifier également le nom du serveur NPS et le secret partagé utilisé précédemment.
Ne changez rien dans l’onglet Advanced. Validez.
D. Console NPS : Groupe de serveurs
Pour envoyer les requêtes d’authentification vers le serveur RADIUS, il convient de créer un groupe, même s’il s’agit d’une seule machine. Cliquez sur "Remote RADIUS Server Groups" puis sur "New".
Précisez le nom du groupe et ajoutez le serveur NPS. Vous pourrez constater qu’un groupe de serveurs existe déjà, il est créé automatiquement lors du déploiement du rôle de passerelle RDS, mais nous ne l’utiliserons pas.
Depuis l’onglet "Authentication/Accounting", indiquez le secret partagé, puis cochez la case "Request must contain the message authenticator attribute".
À partir de l’onglet « Load Balancing », changer ensuite les valeurs de timeout, pour laisser suffisamment de temps à l’utilisateur de valider la demande de MFA.
Validez par OK, puis OK à nouveau.
E. Console NPS : Stratégie de connexion
À présent, il nous faut une stratégie de connexion pour définir dans quel contexte de connexion de l’utilisateur la demande doit être routée vers le serveur NPS central.
À la rubrique "Connection Request Policies", clic droit puis "New".
Indiquez un nom pour cette stratégie, et choisissez "Remote Desktop Gateway" dans la liste type.
Sur l’écran suivant, du choix des conditions, sélectionnez "NAS Port Type" avec comme valeur "Virtual (VPN) ".
Sur l’écran suivant, cochez "Forward Request" et spécifiez le groupe de serveurs Radius créé précédemment.
Dans la partie "Accounting", cochez la case, et sélectionnez le groupe de serveurs Radius.
Ne rien changer à l’écran suivant.
Le résumé de configuration s’affiche. Cliquez sur "Finish".
F. Console NPS : Stratégie réseau
Enfin, une stratégie réseau doit être créée pour contrôler si la machine est autorisée à se connecter au réseau. À la rubrique "Network policies", clic droit "New".
Fixez le nom de la stratégie et sélectionnez "Remote Desktop Gateway" dans le type.
Pour les conditions, vous pouvez sélectionner un groupe de machine ou d’utilisateurs. Dans mon cas, j’ai préféré une condition plus ouverte basée sur la restriction d’horaire.
S’agissant d’une stratégie d’autorisation d’accès, cochez "Access granted". À noter, qu’en cochant la dernière case, les propriétés Dial-in du compte utilisateur dans l’AD seraient évaluées pour autoriser ou non l’accès.
Autorisez l’authentification non chiffrée en cochant "Unencrypted authentication".
Aucune option ne doit être changée à l’écran suivant.
Idem, aucune modification requise.
L’écran de résumé s’affiche, cliquez alors sur le bouton "Finish".
G. Priorités des stratégies
À présent, changeons les priorités des stratégies.
S’agissant des "Connection Request Policies", il convient de positionner la stratégie que l’on a créée en premier et la stratégie TS par défaut en dernier, et de la désactiver. Le résultat doit être similaire à ceci :
Du côté des "Network Policies", notre stratégie doit figurer en tête de liste.
IV. Serveur NPS
Occupons-nous à présent de la configuration du serveur NPS.
A. Installation du rôle
Depuis le Gestionnaire de serveur, ajoutez le rôle "Network Policy and Access Services".
Une fois l’installation terminée, ouvrez la console "Network Policy Server".
B. Inscription du serveur dans l’AD
Première étape : inscrire le serveur dans l’AD à partir de la console NPS, via un clic droit sur "NPS" et le bouton "Register server in Active Directory".
C. Client radius
La passerelle RDS est un client RADIUS, elle doit être déclarée sur notre serveur NPS.
Effectuez un clic droit sur "RADIUS Clients" et cliquez sur "New".
La machine correspondante à la Passerelle RDS doit être ajoutée en spécifiant un nom convivial, le nom FQDN et le secret partagé.
Ne changez rien dans l’onglet Advanced.
D. Groupe de serveurs Radius
Même si nous n’avons qu’un seul serveur, il convient de créer un groupe de serveurs pour déclarer notre serveur de passerelle RDS. Effectuez un clic droit sur "Remote RADIUS Server" et cliquez sur "New".
Indiquez le nom du groupe puis cliquez sur "Add" et donnez le nom du serveur de passerelle RDS.
Depuis l’onglet "Authentication/Accounting", indiquez le secret partagé, puis cochez la case "Request must contain the message authenticator attribute".
À partir de l’onglet "Load Balancing", changez ensuite les valeurs de timeout, pour laisser suffisamment de temps à l’utilisateur de valider la demande de MFA.
Validez par OK, puis OK à nouveau.
E. Stratégie de connexion n°1
Première stratégie à créer, celle autorisant les accès depuis la passerelle RDS.
À la rubrique "Connection Request Policy", clic droit, "New".
Indiquez le nom "From RDS Gateway" pour cette stratégie, et choisissez le type "Remote Desktop Gateway".
Indiquez dans les conditions, le nom convivial fixé auparavant dans la déclaration du client RADIUS.
L’authentification sera portée par le serveur local, il n’est pas nécessaire de changer les choix.
Même principe pour la partie "Accounting".
Aucune modification nécessaire sur l’écran suivant.
Même chose ici.
Pour terminer, il ne reste plus qu’à cliquer sur le bouton "Finish" à l’écran de résumé.
F. Stratégie de connexion n°2
Toujours depuis la console NPS, à la rubrique "Connection Request Policy", une seconde stratégie doit être ajoutée pour les requêtes de réponse vers la passerelle RDS.
Indiquez le nom de la stratégie et le type "Remote Desktop Gateway".
À l’écran des conditions, spécifiez "Virtual (VPN)" comme "NAS Port Type".
On précise alors au serveur NPS de router la réponse vers la passerelle RDS en choisissant les options "Forward requests" et en sélectionnant le groupe de serveurs.
Même principe pour la partie "Accounting".
Aucun changement requis à l’écran suivant.
Il ne reste plus qu’à valider le dernier écran de l’assistant, en cliquant sur le bouton "Finish".
G. Stratégie Réseau
Comme pour la passerelle RDS, il nous reste à créer une stratégie réseau.
Depuis la rubrique "Network Policies", clic droit, "New".
Fixez le nom de la stratégie et le type "Remote Desktop Gateway".
Pour les conditions, vous pouvez sélectionner un groupe de machine ou d’utilisateurs. Dans mon cas, j’ai préféré une condition plus ouverte basée sur la restriction d’horaire.
S’agissant d’une stratégie d’autorisation d’accès, cochez "Access granted". À noter, qu’en cochant la dernière case, les propriétés Dial-in du compte utilisateur dans l’AD seraient évaluées pour autoriser ou non l’accès.
À l’écran des méthodes d’authentification, cochez la case "Allow clients to connect without negotiating an authentication method".
Aucun changement nécessaire sur l’écran des contraintes.
Rien à changer ici non plus.
L’écran de résumé s’affiche, il ne reste plus qu’à cliquer sur le bouton "Finish".
H. Liste des stratégies
À ce stade, vous devez trouver deux stratégies en plus de celle par défaut dans la partie "Connection Request Policies".
Et une stratégie à la rubrique "Network Policies".
V. Serveur NPS et l'extension Azure MFA
Passons à la mise en place de l'extension Azure MFA pour NPS ! Les étapes suivantes sont à réaliser sur le serveur NPS.
A. Installation de l'extension Azure MFA pour NPS
Tout d'abord, téléchargez l’extension Azure MFA depuis le site de Microsoft.
L’installation est de type "Next, Next" alors quelques clics suffisent.
B. Configuration de l'extension Azure MFA
Ouvrez une invite PowerShell avec élévation de privilèges (en tant qu’Administrateur), puis exécutez la commande suivante pour forcer la communication en TLS 1.2 :
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Puis, tapez :
cd 'c:\Program Files\Microsoft\AzureMfa\Config'
Ensuite, tapez la commande ci-dessous pour exécuter le script de configuration :
.\AzureMfaNpsExtnConfigSetup.ps1
Le script installe les modules PowerShell ActiveDirectory et MsOnline si pas encore installés. Entrez un login administrateur sur le tenant.
Entrez l’ID du tenant (celui récupéré depuis le portail Microsoft Entra ID). Un certificat autosigné (valable 2 ans) portant cet ID sera généré, et un Service Principal côté Entra ID également.
Enfin, le service NPS sera automatiquement redémarré.
C. Entrée de Registre Windows
Deux entrées de registres (noms et valeurs sensibles à la casse) sont nécessaires pour fixer la configuration.
Ouvrez "regedit. exe" et parcourez le Registre de cette façon :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureMfa
Créez une nouvelle valeur String (REG_SZ) avec les paramètres suivants :
- Nom = OVERRIDE_NUMBER_MATCHING_WITH_OTP
- Valeur = FALSE
Ce paramètre est décrit dans la documentation de Microsoft, sur cette page.
Redémarrez le service NPS pour prendre en compte la modification :
Restart-Service ias
Toujours au même endroit dans le Registre, il y a une nouvelle valeur à créer :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureMfa
Créez une entrée String (REG_SZ) avec les paramètres suivants :
- Nom = REQUIRE_USER_MATCH
- Valeur = TRUE
Elle permet de s’assurer que le compte existe dans l’Azure AD et que le MFA est actif.
Terminez par redémarrer le service NPS :
Restart-Service ias
La configuration est terminée !
VI. Le résultat en images
Après toutes ces étapes de configuration, il est temps de tester !
Lancer un client "mstc" depuis une machine, dans mon cas PCWIN10 et tapez le nom du serveur cible où vous souhaitez ouvrir une session, et l’identifiant de connexion. À noter que le samAccountName ou le UserPrincipalName (UPN) peuvent être utilisés indifféremment.
Depuis l’onglet "Advanced", cliquer sur "Settings" dans la partie qui permet de configurer l’utilisation d’une passerelle. Renseigner le nom du serveur de passerelle RDS.
Décochez "Bypass RD Gateway server for local addresses", nous avons en effet un usage interne à la fois du serveur cible et de la passerelle.
Cochez la case "Use my RD Gateway credentials for the remote computer", cela permettra de n’être prompté qu’une seule fois pour les infos d’authentification pour la passerelle RDS et pour le serveur cible.
Validez par OK.
Cliquez alors sur le bouton "Connect", et entrez votre mot de passe.
Le client RDP affiche le message "Initiating remote connection…" Une notification de MFA apparait alors sur votre smartphone !
Une fois la méthode de MFA validée, la session RDP s’ouvre…
VII. En cas de problèmes
Vous avez suivi à la lettre ce guide, mais quelque chose ne fonctionne pas ? Quelques indications utiles.
A. Journaux
En suivant les flux d’authentification décrits sur le schéma de principe plus haut, il vous faudra commencer par vérifier les logs de la passerelle RDS.
Applications and Services Logs > Microsoft > Windows > TerminalServices-Gateway > Operational
Ensuite, consultez les logs du serveur NPS…
… et plus particulièrement ceux de l’extension Azure MFA.
Applications and Services Logs > Microsoft > AzureMfa > AuthN > AuthZ
Si vous observez l’erreur illustrée ci-dessous, pas d’inquiétudes, c’est une erreur normale, dixit le support Microsoft. 
Il est également possible de désactiver temporairement les logs NPS, connus pour bloquer l’authentification si l’écriture échoue dans le log :
Les logs Entra ID (Journaux de connexion) seront aussi une source d’information intéressante.
B. Extension Azure MFA
Afin d’écarter un éventuel problème avec l’extension Azure MFA installée sur le serveur NPS, il est possible de la désactiver temporairement. Si l’authentification réussie (et donc que la session RDP s’ouvre) une fois l’extension désactivée, vous aurez une indication précieuse.
Voici la procédure :
- 1 - Ouvrez l’éditeur de registres en tapant "regedit"
- 2 - Allez à la clé "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Authsrv\Parameters"
- 3 - Exportez cette clé dans un fichier .reg pour permettre le retour arrière
- 4 - Sous la clé de registres désignée précédemment, supprimez les entrées AuthorizationDLLs et ExtensionDLLs
Tester alors l’ouverture d’une session RDP.
VIII. Conclusion
Avec tous ces éléments, vous devriez pouvoir configurer la solution avec succès. Lors de ma première implémentation pour un client, les documentations disponibles étaient fausses ou incomplètes, aussi il m’aura fallu faire appel au support Microsoft Azure.
Si la haute disponibilité est un sujet pour vous, l’ajout d’un second serveur NPS et d’un autre serveur de passerelle avec un mécanisme de load balancing vous permettra d’atteindre l’objectif. Les groupes de serveurs configurés depuis les consoles NPS autorisent cette évolution.
The post Sécuriser les accès RDP de vos serveurs avec Azure MFA (et NPS) first appeared on IT-Connect.
