Double authentification (2FA) avec un Fortigate via LDAP(S) : DUO Authentication Proxy (1/4)
Objectif et contexte
Cet article décrit comment déployer une solution d’authentification à deux facteurs (2FA) afin de sécuriser davantage les accès aux ressources informatiques d’une entreprise, depuis l’internet ou le réseau local.
La solution présentée ici est celle de la société Duo Security qui se nomme « DUO Authentication Proxy« . Il s’agit d’une solution « sur site » (on-promises) accessible librement qui s’intègre aussi bien avec un service d’annuaire (Active Directory) via le protocole applicatif LDAP(S) qu’un serveur de stratégie réseau (NPS) déployé en tant que serveur Radius.
L’autre avantage de cette solution est de proposer une version d’essai de 30 jours à la version « Duo Access » qui permet d’avoir un bon aperçu de leur solution. On bascule ensuite automatiquement à la version gratuite appelée « Duo Free » qui permet d’enregistrer jusqu’à 10 utilisateurs, toujours compatible avec l’application « DUO Authentication Proxy « .
Dans cette première partie, nous étudierons que la partie DUO et ce en mode LDAP(S), rapidement suivra d’autres articles dédiés au Fortigate et FortiClient.
Vue d’ensemble
Le serveur » DUO Authentication Proxy » aura pour fonction « d’intercepter » les requêtes de demande d’authentification (LDAP, RADIUS etc…) et de les relayer aux différents serveurs concernés (contrôleurs de domaine, serveur Radius etc…).
Il jouera le rôle de « mandataire » et devra valider les accès lors de la première demande d’authentification « classique » puis effectuera une deuxième demande d’authentification via un second mécanisme différent qui lui est propre.
Pour cette deuxième demande d’authentification, ce serveur « intermédiaire » utilise sa propre infrastructure Cloud à partir de laquelle il communiquera avec l’utilisateur et validera ou non l’accès.
Schéma réseau
Ci-dessous les différentes étapes successives permettant de valider ou non l’accès à l’utilisateur final.
Dans cet exemple, il s’agit d’une demande de connexion distante depuis le client FortiClient de Fortinet pour établir un tunnel (VPN SSL). Le serveur « Duo Authentication Proxy » se situe au cœur de ce schéma réseau et communique directement avec les serveurs internes et le Cloud Duo :
- Première demande d’authentification initiée sur le Firewall Fortinet Fortigate via SSL VPN (FortiClient)
- Le firewall transmet cette demande au serveur « Duo Authentication Proxy »
- Le serveur « Duo Authentication Proxy » transmet à son tour la requête aux serveurs de l’entreprise (via LDAP/RADIUS)
- En cas de succès, le serveur établit une connexion sécurisée avec les serveurs de Duo Security (via HTTPS)
- Si l’utilisateur existe, une seconde demande d’authentification est faite auprès de ce dernier
- Le serveur reçoit la réponse de l’utilisateur (via PUSH/SMS/PHONE)
- Si la demande est bien approuvée, le firewall accorde l’accès à l’utilisateur.
Prérequis et installation
Nous utiliserons deux serveurs sous OS windows pour la redondance, voici la liste des prérequis pour l’installation de l’application :
- Deux serveurs virtuels ou physiques avec Windows Server 2016 :
- 1 CPU, 4 GB de RAM et 40 GB d’espace disque (chacun)
- Créer un compte sur le site de Duo Security : https://signup.duo.com/
- Générer et récupérer les informations de connexion sur le Cloud Duo Security (API) : https://admin.duosecurity.com
- Il faut créer une API via le menu « Application«
- Cliquer sur le bouton bleu en haut à droite « Protect an Application«
- Chercher l’application « Fortinet » et cliquer sur le lien « Protect this application«
- Cliquer sur l’application « Fortinet FortiGate SSL VPN«
- Copier/coller les trois valeurs « Integration key« , « Secret key » et « API hostname«
- Télécharger la dernière version de l’application ( ~12 Mo ) : https://dl.duosecurity.com/duoauthproxy-latest.exe
- Vérifier l’intégrité du fichier téléchargé (SHA-256) : https://duo.com/docs/checksums#duo-authentication-proxy
- Ouvrir les flux réseaux en sortie (HTTPS 443) : https://help.duo.com/s/article/1337?language=en_US
- Ouvrir les flux réseaux sur le réseau interne :
- Depuis le serveur Duo vers le ou les contrôleurs de domaine : ports TCP 389 (LDAP) et 636 (LDAPS)
- Depuis le firewall Fortigate vers le serveur Duo : ports TCP 389 (LDAP) et 636 (LDAPS)
- Un compte de service dédié en lecture (seulement) pour pouvoir interroger l’Active Directory
Petite astuce pour vérifier le checksum d’un fichier avec PowerShell :
PS C:\Users\[username]\Downloads> Get-FileHash .\duoauthproxy-3.2.1.exe -Algorithm SHA256 | Format-List
L’Installation est ensuite très intuitive, il faut utiliser un compte avec des droits d’administrateur et lancer l’exécutable.
Si besoin : https://duo.com/docs/authproxy-reference#installation
Fichier de configuration
A ce stade l’application ou plutôt le service n’est pas encore démarré, il faudra d’abord remplir le fichier de configuration qui se trouve ici :
C:\Program Files (x86)\Duo Security Authentication Proxy\conf\authproxy.cfg
De préférence utiliser un éditeur de texte du type Notepad++ pour éviter les éventuels caractères parasites (retours chariots etc…).
Il faut ouvrir le fichier avec les droits d’administrateur et préciser différentes « sections » dans lesquelles nous allons mettre les paramètres et leur valeur.
Section [main]
La première section que nous devons configurer est la section [main] qui permet, notamment de :
- Activer le mode « debug » au besoin (debug),
- Inscrire dans un fichier toutes les tentatives d’authentification réussie ou non (log_auth_events),
- Définir le nombre maximum de fichiers de logs à conserver par type de fichier (log_max_files),
- Définir la taille maximale des fichiers de logs (log_max_size),
- L’interface ou les interfaces d’écoute pour les requêtes LDAP/Radius (interface),
- Et enfin d’activer ou non les tests de connectivité au (re)démarrage du service (test_connectivity_on_startup).
Voici un exemple ci-dessous que vous pouvez utiliser avec les explications :
[main]
# On désactive le debug (par défaut le cas)
debug=false
# On logs les connexions des usagers
log_auth_events=true
# On ne conserve que 20 fichiers au maximum
log_max_files=20
# Taille maximale des fichiers en octets (bytes) : ici 20 Mo
log_max_size=20971520
# Une seule interface en écoute sur le serveur
interface=10.20.30.40
# On active le tests de connexion à chaque démarrage du service
test_connectivity_on_startup=true
Section à adapter en fonction de vos besoins et de votre plan d’adressage IPv4.
Comme on le voit il est possible de mettre des commentaires. Pour cela, différents caractères/mots peuvent être utilisés en début de ligne : REM, # (dièse) ou encore ; (point-virgule)
Remarque : il faut donc absolument éviter d’utiliser l’un de ces caractères ou mots pour les paramètres exigeant un mot de passe comme nous le verrons plus bas. Si on opte pour utiliser les mots de passe en clair dans le fichier, cela risque de poser problème.
Sections [ad_client] et [ldap_server_auto]
Toujours dans le même fichier de configuration, on continue avec les sections [ad_client] et [ldap_server_auto] qui permettront d’un côté au serveur de se connecter aux contrôleurs de domaine de l’entreprise et d’autre de recevoir les requêtes de type LDAP(S) depuis le Fortigate.
Dans notre cas, ces deux sections, l’une pour le mode « client » et l’autre pour le mode « serveur », serviront notamment pour :
- Authentifier les usagers comme les consultants qui se connectent avec l’application FortiClient (tunnel VPN SSL)
- Authentifier les administrateurs qui se connectent sur les firewalls Fortigate
Voici un exemple ci-dessous que vous pouvez utiliser avec les explications détaillées plus bas :
[ad_client]
# Indiquer les différents contrôleurs de domaine
host=DC01.acme.corp
host_2=DC02.acme.corp
# Compte de service utilisé
service_account_username=ldap-query-svc
service_account_password_protected=[mot de passe chiffré avec l’utilitaire « authproxy_passwd.exe »]
search_dn=DC=acme,DC=corp
# On utilise le protocole sécurisé LDAPS (SSL), sinon mettre la valeur « clear » pour LDAP
transport=ldaps
# On ne vérifie pas le certificat du ou des contrôleurs de domaine
ssl_verify_hostname=false
[ldap_server_auto]
# Informations de connexion à l’API Cloud Duo Security
ikey=[copier/coller la clé au format DIXXXXXXXXXXXXXXXXXX]
skey_protected=[clé chiffrée avec l’utilitaire « authproxy_passwd.exe »]
api_host=[copier/coller le hostname au format api-XXXXXXXX.duosecurity.com]
# On indique le client que l’on utilise pour se connecter aux contrôleurs de domaine, en l’occurrence celui crée plus haut
client=ad_client
# On laisse passer la connexion si 2FA échoue
failmode=safe
Dans la section [ad_client] il est important de préciser plusieurs contrôleurs de domaine pour la redondance et on utilisera de préférence le protocole LDAPS, plus sécurisé. On incrémente pour cela le paramètre « host » : host pour le premier DC, host_2 pour le second, host_3 etc… le même compte de service sera utilisé.
Pour mettre le paramètre « ssl_verify_hostname » à « true » il faudrait mettre les certificats de chacun des contrôleurs de domaine dans le même répertoire que le fichier de configuration (ce qui est bien-sûr une bonne pratique). Ce ne sera pas le cas ici pour nos tests.
Dans la section [ldap_server_auto] trois groupes de données sont importants :
- La partie Duo Security Cloud (ikey, skey et api),
- Le client qui doit être utilisé (client),
- Et enfin le comportement à adopter en cas d’échec de la connexion avec le Cloud de Duo (failmode).
Ici, si la double authentification ne fonctionne pas mais que l’authentification principale ou « classique » fonctionne, on autorise la connexion (mode=safe).
Il est possible de durcir la sécurité en passant au mode « secure », qui cette fois bloquerait la connexion, au risque par contre de perturber ou gêner l’administration en cas d’incident réel.
Par défaut le serveur écoutera sur le port standard TCP 389 et recevra donc les requêtes via le protocole LDAP. On imagine que ce serveur est DMZ et que seul les firewalls Fortigate s’y connecte pour l’instant.
Un point crucial ici est le chiffrement des mots de passe : aucun mot de passe ne devrait être présent en clair dans le fichier de configuration une fois le service en production.
Cela concerne les deux champs « service_account_password_protected » et « skey_protected ». Les informations à protéger sont ici chiffrées.
Il faut pour cela utiliser l’un des utilitaires fourni avec l’application qui se trouve ici :
C:\Program Files (x86)\Duo Security Authentication Proxy\bin\authproxy_passwd.exe
Il suffit de lancer l’utilitaire en ligne de commande, de taper le mot de passe ou la clé puis de copier/coller le résultat, comme ici en jaune, dans le fichier de configuration :
Fichier complet
Vous trouverez ici un exemple de fichier complet (sans commentaire) à remplir avec vos propres informations :
Lancement et fichiers de logs
Le démarrage du service peut se faire directement dans les services ou bien en ligne de commande (administrateur) :
net start duoauthproxy
Le nouveau service Windows sera lancé, qui par défaut, est exécuté avec le compte système local :
Lors du démarrage, quatre fichiers de logs seront automatiquement créés dans le répertoire « log » :
C:\Program Files (x86)\Duo Security Authentication Proxy\log
Ceux qui nous intéressent sont en jaune, le dernier n’est pas utile dans notre cas :
connectivity_tool = dans ce fichier de log on peut voir l’état de la connexion du serveur avec le Cloud Duo Security lors d’un démarrage et permet de détecter un éventuel problème avec le fichier de configuration.
Par exemple ici les sections [ad_client] et [ldap_server_auto] sont correctes :
Ici un autre cas où le certificat du contrôleur de domaine est manquant dans la section [ad_client] :
authproxy = ce fichier de log est complémentaire au fichier précèdent qui apportera d’autres informations lors du démarrage de l’application et indiquera si les ports sont bien en écoute ou pas. Il permettra également de voir les connexions « clientes » à savoir les Firewalls (LDAP et LDAPS) et équipements réseaux (Radius).
authevents = ce fichier au format JSON contient tous les évènements d’authentification des usagers. Cela permet rapidement de voir pourquoi une tentative de connexion aurait échouée, pour les deux niveaux d’authentification.
Quelques exemples ci-dessous :
Important : tout changement dans le fichier de configuration nécessite un redémarrage du service pour que cela soit pris en compte, ici en ligne de commande :
net stop duoauthproxy & net start duoauthproxy
Mise à jour
La procédure de mise à jour de l’application est très simple :
- Télécharger la dernière version de l’application : https://dl.duosecurity.com/duoauthproxy-latest.exe
- Lancer l’exécutable en tant qu’administrateur et suivre les indications qui s’affichent à l’écran. Les fichiers de configuration et de logs seront préservés.
- Enfin, démarrer le service et vérifier les logs (connectivity_tool) : net start duoauthproxy
Remarques sur le « service »
J’ai remarqué que le service « DuoAuthProxy » ne démarrait pas toujours après un reboot suite à une maintenance par exemple.
Pour remédier au problème il m’a fallu modifier le type de démarrage à « Automatic (Delayed Start)« , comme ci-dessous :
De même pour le mode de récupération, où j’attends 5 minutes pour redémarrer le service après un incident :
Mot de la fin
Dans cette première partie nous avons vu comment installer, configurer et interpréter les fichiers de logs du serveur DUO Authentication Proxy.
Nous allons voir dans un prochain article comment utiliser ce nouveau type de serveur à partir d’un firewall Fortigate du constructeur Fortinet.
On pourra ainsi activer la double authentification à des usagers qui se connectent avec Forticlient ou à des administrateurs réseau pour l’administrer.