Intégrer Active Directory à OPNsense avec LDAP : guide complet pour un Captive Portal unifié

« Marre des comptes locaux à gérer ? Branchez OPNsense sur votre Active Directory en 60 minutes. »

Vous jonglez encore avec des comptes locaux dans OPNsense tandis que tout le reste de votre infrastructure repose sur Active Directory ? Vous n’êtes pas seul : beaucoup d’administrateurs se lassent de créer les mêmes utilisateurs deux fois, de courir après des mots de passe expirés ou de révoquer des accès en double. Dans notre nouveau guide, nous montrons comment brancher votre pare-feu open-source directement sur l’annuaire Windows pour qu’il devienne, lui aussi, « AD-aware » en moins d’une heure.

Vous découvrirez pas à pas la création d’un compte de service minimal, la configuration LDAP/LDAPS côté OPNsense et surtout le décodage des fameuses erreurs 52e, 49 ou 81 qui font tourner les têtes sur les forums. Nous expliquons pourquoi vos utilisateurs n’apparaissent pas tout de suite dans l’interface, comment fonctionne l’option Automatic user creation et de quelle manière les groupes AD se transforment en politiques de bande passante ou en règles firewall intelligentes.

Vous hésitez encore à sauter le pas vers LDAPS ? Le chapitre « Sécuriser et durcir la liaison » vous guide pour importer le certificat racine et chiffrer toute la négociation, sans casse-tête. Et parce que la théorie ne suffit pas, nous terminons par des bonnes pratiques d’exploitation : sauvegarde de la config, supervision des tentatives ratées, haute disponibilité des DC… Autant de briques qui transforment une intégration rapide en solution robuste.

Bref, si vous voulez offrir à vos utilisateurs un SSO transparent sur le portail captif et vous débarrasser des tâches d’administration redondantes, ce billet est fait pour vous. Plongez-y maintenant : votre Active Directory n’attend plus qu’un clic pour prendre les commandes de votre OPNsense.

1. Introduction — pourquoi intégrer Active Directory à OPNsense ?

Dans la plupart des réseaux d’entreprise, Active Directory (AD) est déjà la source unique de vérité : c’est là que vivent vos comptes, vos mots de passe et vos groupes.
Brancher OPNsense sur cet annuaire présente donc trois atouts majeurs :

• Expérience utilisateur fluide : les employés se connectent au Captive Portal avec les mêmes identifiants que sur leur poste Windows.
• Administration simplifiée : plus de double saisie ni de comptes locaux à tenir à jour ; les ajouts, suppressions ou changements de groupes se propagent automatiquement.
• Application cohérente des politiques : quotas de bande passante, règles Zenarmor, accès VPN… tout peut s’appuyer sur les groupes AD existants.

2. Prérequis et architecture globale pour pouvoir intégrer Active Directory à OPNsense avec LDAP

2.1 Vue réseau et versions compatibles

• Un ou plusieurs contrôleurs de domaine Windows Server 2012 R2 → 2022.
• Un pare-feu OPNsense 24.x ou supérieur (community) ; la Business Edition offre des options d’import en masse mais le socle est identique.
• Connectivité réseau directe (LAN ↔ AD) sans inspection TLS destructrice.

2.2 Matériel et ports utilisés

• 389/TCP pour LDAP non chiffré (tests et dépannage).
• 636/TCP pour LDAPS (production recommandée).
• Horloge synchronisée (NTP) : Kerberos râle au-delà de ±5 minutes de dérive.

3. Préparation côté Active Directory

3.1 Création du compte de service ldap-bind

1. Ouvrez Active Directory Users and Computers (dsa.msc).
2. Dans le conteneur Users ou, mieux, dans une OU “Service Accounts”, créez un nouvel utilisateur :
   • Prénom : LDAP — Nom : Bind — Logon : ldap-bind.
   • Mot de passe solide, « Password never expires » et « User cannot change password ».
3. Le compte reste membre de Domain Users : lecture simple de l’annuaire suffit.

3.2 Récupération du DN complet et du certificat racine

• Activez View → Advanced Features dans la console, ouvrez les propriétés du compte, onglet Attribute Editor : copiez la valeur distinguishedName (ex. CN=ldap-bind,CN=Users,DC=corp,DC=exemple,DC=local).
• Exportez le certificat de l’Autorité de certification de votre domaine ou le certificat auto-signé du DC ; vous l’importerez plus tard dans System → Trust sur OPNsense.

3.3 Organisation des OU et filtrage futur

Décidez où résident vos utilisateurs / groupes ; notez les DN complets des OU que vous importerez dans Authentication containers pour limiter la recherche LDAP.

4. Ajouter un serveur d’authentification LDAP dans OPNsense

1. System → Access → Servers → Add ; type LDAP.
2. Transport : commencez en TCP-Standard (389) pour tester, puis passez en LDAPS – SSL/TLS (636) quand tout fonctionne.
3. Protocol version : 3.
4. Bind credentials :
   • User DN : DN copié (CN=ldap-bind,…).
   • Password : mot de passe du compte.
5. Base DN : DC=corp,DC=exemple,DC=local.
6. Search scope : Subtree.
7. Options :
   • Synchronize groups : oui
   • Automatic user creation : oui
   • Authentication containers : une OU par ligne (ex. OU=Comptes,DC=corp,DC=exemple,DC=local).
8. Enregistrez.

5. Tests et diagnostics initiaux

5.1 Tester la connexion

Pour tester si on a pu intégrer l’Active Directory à OPNsense avec LDAP, nous sommes allés dansSystem → Access → Tester : entrez un login AD (par ex. manager1) et son mot de passe.

• « Authentication success » + liste des groupes : tout est bon.
• data 52e : identifiants invalides.
• Server unreachable ou code 81/91 : problème réseau ou TLS.

5.2 Déchiffrer les erreurs LDAP courantes

• 52e : mauvais login / mot de passe ou compte hors scope.
• 775 : mot de passe expiré.
• 533 : compte désactivé.
• 49 : DN bind incorrect.
• 81 / Can’t contact LDAP server : port ou chiffrement bloqué.

6. Brancher le Captive Portal sur Active Directory avec LDAP

6.1 Sélection du backend LDAP

1. Services → Captive Portal → Zones : éditez (ou créez) votre zone.
2. Dans « Authenticate using », choisissez le serveur LDAP que vous venez de configurer.
3. Enregistrez et appliquez.

6.2 Création automatique des comptes et synchronisation des groupes

• Au premier login sur le portail, l’utilisateur AD est créé localement (grâce à Automatic user creation), puis assigné aux groupes OPNsense portant le même nom que ses groupes AD.
• À chaque connexion ultérieure, l’appartenance est rafraîchie : si vous retirez quelqu’un du groupe WifiUsers dans AD, il perd immédiatement les droits correspondants dans OPNsense.

6.3 Politiques, quotas et règles basées sur les groupes AD

1. Créez dans System → Access → Groups les groupes locaux exactement nommés comme dans AD (par ex. Direction, Manager, Utilisateur).
2. Dans Captive Portal → Policies, associez les groupes à des limitations de bande passante ou de durée de session.
3. Dans Firewall → Rules ou dans Zenarmor/Sensei, appliquez vos profils en sélectionnant ces groupes ; l’utilisateur héritera instantanément des règles dès qu’il se connecte.

7. Comment la synchronisation utilisateurs / groupes fonctionne réellement

7.1 Création locale au premier login

Pas d’import massif : si l’utilisateur ne s’authentifie jamais, il n’existe pas dans OPNsense. C’est normal et voulu pour alléger la base locale.

7.2 Mise à jour des appartenances

Le pare-feu relit memberOf à chaque authentification ; aucun redémarrage ni tâche planifiée n’est nécessaire pour propager les changements de groupes.

7.3 Gestion des comptes orphelins

Quand vous supprimez un compte AD, sa trace locale reste, mais il ne peut plus se connecter. Purgez-les périodiquement dans System → Access → Users si vous tenez à une liste propre.

8. Sécuriser et durcir la liaison LDAP

8.1 Passer en LDAPS

• Importez le certificat racine de votre domaine AD dans System → Trust → Authorities → Import.
• Changez le Transport du serveur LDAP sur LDAPS – SSL/TLS ; laissez le port par défaut 636.
• Refaites un test d’authentification : succès attendu.

8.2 Gérer le mot de passe du compte de service

• Mot de passe long, stocké dans un coffre-fort.
• Si votre politique impose une rotation, prévoyez un rappel juste avant l’expiration ; OPNsense ne vous alerte pas.

8.3 Limiter la portée de recherche

• Renseignez précisément Authentication containers pour exclure les comptes admins ou de service inutiles.
• Utilisez un filtre Extended Query si besoin :
  (&(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))) pour ignorer les comptes désactivés.

9. Bonnes pratiques d’exploitation

9.1 Sauvegardes

• Sauvegardez la configuration OPNsense (encrypted backup) après chaque changement majeur.
• Planifiez une sauvegarde régulière de l’état système AD ; certains logiciels restaurent aussi les objets supprimés.

9.2 Supervision

• Activez System → Settings → Logging pour consigner les échecs d’authentification.
• Surveillez les verrous de compte dans AD et les codes 52e récurrents : ils révèlent souvent des mots de passe expirés.

9.3 Haute disponibilité des DC

• Déclarez plusieurs serveurs LDAP dans OPNsense ou utilisez le FQDN d’un site AD qui pointe vers plusieurs DC ; ainsi, la perte d’un contrôleur ne casse pas l’authentification.

10. Annexes

10.1 Cheat-sheet PowerShell

# dn complet de l'utilisateur
Get-ADUser manager1 -Properties DistinguishedName | Select -Expand DistinguishedName

# test rapide d'authentification
$cred = Get-Credential   # domaine\utilisateur
([adsisearcher]"").SearchRoot = "LDAP://DC=corp,DC=exemple,DC=local"
([adsisearcher]"(sAMAccountName=manager1)").Credential = $cred
([adsisearcher]"(sAMAccountName=manager1)").FindOne()

10.2 FAQ des codes d’erreur LDAP

• 52e : mauvais identifiants.
• 775 : mot de passe expiré.
• 533 : compte désactivé.
• 525 : utilisateur introuvable.
• 49 : DN bind incorrect.
• 81 : serveur indisponible.

10.3 Ressources officielles

• Documentation OPNsense LDAP : https://docs.opnsense.org/manual/how-tos/user_ldap.html
• Microsoft LDAP error codes : https://learn.microsoft.com/troubleshoot/windows-server/identity/ad-ldap-error-codes
• Forum OPNsense (catégorie Authentication) : https://forum.opnsense.org/

Conclusion

En quelques étapes, vous pouvez intégrer Active Directory à OPNsense avec LDAP et délégué l’authentification du Captive Portal à votre annuaire d’entreprise. Vos utilisateurs profitent d’un SSO transparent, tandis que vous gagnez un contrôle fin grâce aux groupes AD existants. Une base solide pour aller plus loin : filtrage applicatif par groupe, intégration 802.1X ou reporting avancé — tout devient plus simple lorsque votre pare-feu parle le même langage qu’Active Directory.