Contrôler qui accède à un réseau — un Wi-Fi d’entreprise, un VPN, un port de switch — mobilise plusieurs protocoles dont les rôles se recoupent au point qu’on finit par les confondre. Il faut pourtant les distinguer nettement, chacun n’assurant qu’une partie du problème.

Qui fait quoi

RADIUS est un protocole AAAAuthentication, Authorization, Accounting — dédié au contrôle de l’accès réseau : Wi-Fi 802.1X, VPN, portail captif, port de switch. Il décide qui entre, avec quels droits (VLAN, ACL), et journalise l’activité.

LDAP est un protocole d’interrogation et de modification d’un annuaire — utilisateurs, groupes, machines. Il sert à chercher un compte, lire ses attributs, ou lier une application à l’annuaire (bind). LDAP n’est pas un protocole d’accès réseau comme RADIUS : c’est le protocole d’accès au répertoire lui-même.

Active Directory (AD) est le service d’annuaire de Microsoft, qui s’appuie sur Kerberos, LDAP, DNS et SMB pour stocker et exposer ses objets (utilisateurs, groupes, unités d’organisation) et fournir identité, groupes et politiques (GPO).

Kerberos est le protocole d’authentification par tickets qu’utilise AD, conçu pour éviter de faire transiter des mots de passe sur le réseau — au prix d’une exigence stricte : les horloges des systèmes impliqués doivent rester synchronisées, Kerberos étant sensible à la dérive temporelle.

RADIUS en pratique : le flux 802.1X

Le scénario le plus fréquent — Wi-Fi d’entreprise ou accès VPN — suit un enchaînement stable :

sequenceDiagram
    participant C as Client (supplicant)
    participant A as AP/Switch (NAS)
    participant R as RADIUS (NPS/FreeRADIUS)
    participant AD as AD (Kerberos/LDAP)

    C->>A: EAPOL (identité)
    A->>R: RADIUS Access-Request (EAP-Message)
    R->>AD: Vérification identité (Kerberos/LDAP)
    AD-->>R: OK (groupes/attributs)
    R-->>A: Access-Accept (VLAN/ACL attribués)
    A-->>C: Port autorisé (ou refusé)

Le point d’accès ou le switch joue le rôle de NAS (Network Access Server) — il est, du point de vue de RADIUS, un simple client. Le serveur RADIUS (Microsoft NPS ou FreeRADIUS) vérifie l’identité auprès d’AD via Kerberos ou LDAP, puis renvoie un Accept ou un Reject, assorti d’attributs d’autorisation — un VLAN dynamique, une ACL descendante (dACL).

Deux fonctions RADIUS méritent d’être retenues : l’accounting, qui consigne qui s’est connecté, quand, et pour combien de temps ; et le CoA (Change of Authorization), qui permet de modifier dynamiquement un VLAN ou une ACL sans déconnecter l’utilisateur, à la suite d’une évaluation de conformité (NAC).

Pour Wi-Fi ou VPN, l’authentification repose sur EAP (EAP-TLS, PEAP), les attributs RADIUS pilotant l’autorisation (VLAN, ACL), et l’accounting garantissant la traçabilité. Il vaut mieux privilégier des certificats (EAP-TLS) plutôt que des mots de passe, chaque fois que c’est possible.

LDAP et Active Directory : objets, DN, GUID

Dans AD, chaque objet possède un DN (Distinguished Name), qui décrit son emplacement dans l’arbre (CN=Alice,CN=Users,DC=exemple,DC=local), et un GUID (objectGUID), identifiant unique et immuable qui ne change pas même si l’objet est déplacé dans l’arborescence. Les unités d’organisation (OU) sont des conteneurs logiques permettant d’organiser les objets et d’y appliquer des GPO ; les groupes transmettent des droits par héritage à leurs membres. Enfin, AD publie des enregistrements DNS SRV (_kerberos._tcp, _ldap._tcp) qui permettent à tout poste membre du domaine de localiser automatiquement un contrôleur de domaine.

Le flux d’authentification Kerberos suit une logique en deux temps : le client obtient d’abord un TGT (Ticket Granting Ticket) auprès du KDC (composant du contrôleur de domaine), puis, pour accéder à un service donné, demande un TGS (service ticket) que l’application valide — assurant une authentification transparente, sans ressaisie de mot de passe (c’est le principe du SSO).

flowchart LR
    App[Application interne] -- "LDAP bind/search" --> AD[Active Directory]
    App -- "SSO/Kerberos" --> AD

Le tableau complet : qui authentifie l’utilisateur d’un VPN

Reconstituer le trajet complet éclaire mieux que n’importe quelle définition isolée. Une passerelle VPN (SSL ou IPSec) termine la connexion et agit comme NAS RADIUS ; elle envoie un Access-Request au serveur RADIUS (NPS ou FreeRADIUS) ; celui-ci vérifie l’identité auprès d’AD (Kerberos/LDAP) ; RADIUS renvoie un Accept accompagné des attributs adéquats (profil, ACL, groupe d’accès) ; et les journaux d’accounting permettent d’auditer qui s’est connecté, quand, tout en autorisant des politiques dynamiques via CoA.

flowchart LR
    U[Utilisateur VPN] --> G[Passerelle VPN / NAS]
    G -->|RADIUS| R[Serveur RADIUS]
    R -->|Kerberos/LDAP| AD[Active Directory]
    R -."Accept + attributs".-> G

Enfin, une nuance de vocabulaire à ne pas manquer : un « serveur LDAP » n’est jamais l’authentificateur de l’accès réseau — ce n’est que l’annuaire. C’est le serveur RADIUS qui joue le rôle d’intermédiaire AAA, en s’appuyant sur l’annuaire. Un bon design suppose donc un RADIUS redondé (au moins deux serveurs), une intégration AD propre, des certificats valides pour EAP-TLS, et des horloges système cohérentes — Kerberos ne pardonne pas la dérive temporelle.