Déployer 1X Network Access Control : configuration RADIUS, politique NAC et plan de déploiement pour réseaux d'entreprise

Dans les réseaux d’entreprise, quiconque souhaite contrôler sérieusement quels terminaux sont autorisés à fonctionner sur quels ports et quelles SSID (identifiants de réseau Wi‑Fi) ne peut guère faire l’impasse sur 1X Network Access Control. Dans la pratique, il s’agit presque toujours de IEEE 802.1X : un contrôle d’accès basé sur le port, où un switch ou un point d’accès (le Authenticator) transmet les informations d’authentification d’un client (le Supplicant) à un RADIUS-serveur (backend AAA pour Authentication, Authorization, Accounting). Le résultat n’est pas seulement « entrée ou sortie », il peut déclencher des affectations telles que VLAN, ACL ou mise en quarantaine.

Le hic : 802.1X est moins une fonctionnalité qu’un modèle opérationnel. Il échoue rarement à cause d’une case manquante sur un switch, mais plutôt à cause de certificats, d’identités hétérogènes, d’appareils particuliers (imprimantes, IoT), de timers mal réglés, de politiques floues et d’un déploiement sans plan de retour. Cet article vous guide de manière pragmatique à travers la configuration du RADIUS, la conception des politiques NAC et un plan de déploiement qui fonctionne de façon réaliste dans des réseaux hétérogènes (LAN/WLAN, Windows/macOS/Linux, gérés/non gérés).

Pourquoi 802.1X/NAC : ce que vous gagnez opérationnellement (et ce que vous ne gagnez pas)

802.1X s’attaque à un problème central des réseaux classiques de couche 2 : un port actif est souvent « de confiance » tant que le lien est présent. Cela ne convient plus au BYOD, aux postes de travail nomades, aux retours en télétravail, aux réseaux invités et à la contrainte de séparer proprement les segments. Avec 802.1X, vous imposez qu’un équipement prouve son identité avant d’accéder au réseau.

Important pour la gestion des attentes : 802.1X n’est pas une sécurité complète des endpoints. Il ne remplace ni la gestion des correctifs ni l’EDR. Et ce n’est pas une panacée contre des appareils compromis. Mais il crée une base technique solide pour standardiser les accès : « Qui es‑tu, de quel type es‑tu, et quel profil s’applique à toi ? » C’est précisément cette affectation qui, en exploitation et en audit, constitue souvent le levier décisif.

Principes d’architecture : rôles et protocoles sans ambigüité

Avec 802.1X, trois rôles interagissent :

• Supplicant : client sur l’équipement (p. ex. Windows Wired AutoConfig, macOS 802.1X, wpa_supplicant sous Linux).
• Authenticator : port de switch ou point d’accès WLAN, qui bloque initialement le port et traite EAPOL (EAP over LAN) ou EAP over WLAN.
• Authentication Server : serveur RADIUS qui termine ou traite EAP (Extensible Authentication Protocol) et renvoie des décisions.

Méthodes EAP importantes dans l’exploitation NAC :

• EAP-TLS : authentification basée sur certificat (certificat client). Très robuste, mais exigeante en PKI et en gestion du cycle de vie.
• PEAP : tunnel (TLS) plus méthode de mot de passe interne (typiquement MSCHAPv2). Plus simple à déployer, mais plus vulnérable aux faiblesses liées aux mots de passe et au phishing ; de plus dépendant d’une confiance correcte dans le certificat serveur.

Important pour les administrateurs : sur le lien ne circule pas un « mot de passe RADIUS », mais l’EAP est transporté entre le supplicant et le RADIUS via l’authenticator. En cas d’échec, vous devez donc toujours identifier : le problème provient‑il du client (supplicant), de l’authenticator (Switch/AP) ou du RADIUS/service d’annuaire (p. ex. AD/LDAP) et de sa chaîne de certificats ?

Prérequis avant le premier paquet: Inventaire, identités, PKI

Un démarrage soigné vous évitera des semaines de dépannage. Clarifiez à l’avance ces points :

1) Inventorier les types d’appareils et les cas particuliers

Listez les ports/réseaux et les classes d’équipements : Managed Clients, Admin-Notebooks, VoIP-Telefone, Drucker, Konferenzsysteme, Kameras, Produktionsgeräte, Access Points, Thin Clients. Ce qui importe : qui peut faire 802.1X en tant que supplicant ? Qui nécessite MAB ? Qui utilise des MACs changeantes (randomization) et est donc inadapté au MAB ?

2) Déterminer la source d’identité : utilisateurs, appareils ou les deux

Pour le LAN, le choix « User-Auth » vs. « Machine-Auth » est central. Dans Windows-environnements, le certificat machine (EAP-TLS) pour « l’appareil appartient au domaine » est souvent plus stable que l’utilisateur/mot de passe, car l’authentification peut se produire avant la connexion de l’utilisateur. Pour le WLAN, vous aurez souvent besoin des deux (p. ex. Wi‑Fi collaborateurs via certificat utilisateur, appareils/WLAN via certificat machine).

3) Décision PKI : qui délivre les certificats et comment est gérée leur rotation ?

EAP-TLS tient et tombe avec les certificats : CA (Certificate Authority), templates/profiles, durées de validité, révocation (CRL/OCSP), distribution des CA root/intermédiaires et renouvellement. Piège typique : le client ne fait pas confiance au certificat du serveur RADIUS parce que des certificats intermédiaires manquent ou que des EKUs (Extended Key Usage) incorrects sont utilisés.

Si vous employez PEAP : vous avez également besoin d’un certificat serveur sur le RADIUS, et les clients doivent vérifier proprement sa confiance. Sinon, un « tunnel sécurisé » devient rapidement une sécurité « cliquer pour accepter ».

RADIUS-Setup: Redundanz, Ports, Zertifikate, Logging

Une configuration RADIUS productive ne se limite pas à un seul service serveur. Prévoyez au minimum deux instances (HA via équilibreur de charge ou double serveur dans les équipements réseau), des politiques cohérentes et une journalisation fiable.

Netzwerkseitige Basis: Erreichbarkeit und Shared Secrets

RADIUS utilise typiquement UDP/1812 (Auth) et UDP/1813 (Accounting). Dans des environnements anciens, on trouve UDP/1645/1646. Vérifiez pare-feu et routage, en particulier si l’Access Layer et les serveurs AAA sont dans des zones séparées. Par authenticator (Switch/AP/Controller) existe un secret partagé (clé commune) qui ne doit pas être deviné et doit pouvoir être renouvelé.

Un test de connectivité minimal (sans client 802.1X) est souvent utile. Un exemple avec radclient (Freeradius-Tools) contre un utilisateur de test peut montrer si RADIUS répond en principe :

# Beispiel: Access-Request an RADIUS schicken (Test-User/Passwort nur für Lab)
# radclient erwartet hier PAP/CHAP-ähnliche Attribute, nicht EAP-TLS.

echo "User-Name=testuser,User-Password=testpass" | 
  radclient -x 10.10.10.20 auth SuperSecretSharedKey

Important : Ce n’est pas un test EAP. Il s’agit de « le RADIUS est-il en vie et le secret est-il correct ? ». Pour EAP-TLS/PEAP, vous avez besoin de tests réels du supplicant ou d’outils de test EAP spécialisés.

Certificats sur le RADIUS : chaîne, EKU, nom

Le serveur RADIUS doit présenter un certificat serveur que les clients valident. Vérifiez :

• Subject/SAN : le nom DNS attendu par les clients doit figurer dans le certificat (SAN : Subject Alternative Name).
• EKU : « Server Authentication » doit être défini.
• Chaîne de certificats : les intermédiaires doivent être fournis correctement, sinon de nombreux clients échoueront silencieusement.
• CRL/OCSP : si les clients exigent la vérification de révocation, l’accessibilité des listes de révocation doit être assurée (y compris en pre-logon).

Accounting et télémétrie : sans logs, pas d’exploitation

Le RADIUS-Accounting fournit les démarrages/arrêts de session et peut aider dans l’analyse NAC : quels ports/SSID sont utilisés et comment, qui sort du cadre ? Même si vous n’utilisez pas l’accounting pour la facturation, il est précieux pour l’exploitation, le dépannage et l’audit.

Planifiez vos sources de logs de manière à pouvoir corréler les événements :

• Logs RADIUS (Accept/Reject, Reason, EAP-State)
• Logs de switch/AP (Dot1x, AAA, Port-Events)
• Logs client (Windows observateur d’événements, macOS console, wpa_supplicant)

Concevoir la politique NAC : moins de « tout bloquer », plus de chemins contrôlés

Une politique NAC est la règle opérationnelle selon laquelle un terminal est placé dans un profil cible. Le classique : « Employee VLAN » ou « Guest VLAN ». En pratique, vous avez besoin de plus de paliers pour que le déploiement et l’exploitation restent stables.

Éléments de politique ayant fait leurs preuves

• Pre-Auth / Fail-Open / Fail-Closed : comportement lorsque le RADIUS n’est pas joignable. Le Fail-Open peut sauver l’activité, mais constitue un risque de sécurité ; le Fail-Closed est strict, mais peut entraîner une coupure généralisée en cas de panne AAA. Dans de nombreux environnements, un Fail-Open contrôlé avec un profil réduit (p. ex. accès uniquement à la remédiation/gestion) est le meilleur compromis.
• Quarantaine/Remédiation : VLAN ou ACL autorisant uniquement les services de mise à jour/gestion, DNS, DHCP, éventuellement un proxy. Objectif : rendre les dispositifs réparables plutôt que de les bloquer.
• Rôles par type d’appareil : Managed Client, Unmanaged Device, Voice, Printer, IoT, Admin-Workstation.
• Guest/BYOD séparés : SSID/ports dédiés, espaces d’adressage clairement séparés, privilèges réduits.

Techniquement, cela se met souvent en œuvre via des attributs RADIUS (p. ex. VLAN-ID, Tunnel-Private-Group-ID, Filter-ID, dACL). Les attributs supportés dépendent du fournisseur. L’essentiel est le principe d’exploitation : des profils clairs et testables.

EAP-TLS vs. PEAP dans le contexte des politiques

EAP-TLS est généralement le meilleur choix pour les appareils gérés, car il fournit une identité matérielle forte. L’inconvénient est la charge liée à la PKI : enrôlement, renouvellement, révocation, désaffectation. PEAP est souvent le point d’entrée lorsque vous avez besoin d’une authentification rapide basée sur l’utilisateur, mais il génère davantage de tickets de support (« avertissement de certificat », changement de mot de passe, verrous) et est plus vulnérable si les clients ne vérifient pas strictement l’identité du serveur.

Un hybride fréquent en entreprise : LAN via EAP-TLS (Machine), WLAN des collaborateurs via EAP-TLS (User ou Device), appareils hérités/spéciaux via MAB dans un VLAN RESTrictif.

Côté commutateur et WLAN : paramètres typiques déterminant la stabilité

De nombreux projets 802.1X ne butent pas sur « le commutateur gère-t-il 802.1X », mais sur les timers et les priorités. Veillez aux points suivants :

Rôles de port et scénarios multi-appareils (PC + téléphone)

Au poste de travail, un téléphone VoIP est souvent branché sur le port et le PC est connecté au téléphone. Il vous faut un modèle capable de représenter deux identités sur le même port. Les mots-clés sont «Multi-Auth» ou «Multi-Domain Authentication» (séparation Voice / Data). Si vous l’ignorez, un seul des appareils s’authentifie et l’autre tombe dans le mauvais profil.

Timers et tentatives

Des intervalles de réauthentification trop agressifs ou des timeouts trop courts entraînent du « flapping » : le port est périodiquement réauthentifié, les connexions se coupent, Teams/VoIP en souffre. Des intervalles trop longs retardent le offboarding. Démarrez de manière conservative et optimisez ensuite.

Définir proprement les fallbacks : MAB et VLAN invité

Si vous autorisez MAB comme exception, le commutateur doit clairement prioriser : d’abord 802.1X, puis MAB (ou l’inverse, selon la classe d’appareil). Un VLAN invité pour les échecs d’authentification peut sécuriser le déploiement, mais devient une porte d’entrée si trop permissif. Le Guest/Fail-VLAN ne devrait recevoir que des accès minimaux.

Plan de déploiement : du Lab via Monitor-Mode jusqu’à l’application

Un déploiement est moins une action purement technique qu’une transition contrôlée. Une approche en plusieurs étapes, avec points de mesure et chemins de repli, s’est avérée efficace.

Phase 0 : Lab et chemin de référence

Montez un petit chemin de référence : 1–2 Switches/1 AP, un RADIUS-Cluster (ou deux instances), un Windows-Client, un macOS-Client, un Linux-Client, plus un appareil particulier (p. ex. imprimante). L’objectif n’est pas l’exhaustivité, mais la détection précoce des problèmes sérieux : chaîne de certificats, nom, accessibilité de la CRL, décisions de politique, attribution de VLAN.

Phase 1 : visibilité sans application (Monitor/Low Impact)

Si votre plateforme le permet : commencez en « Monitor Mode » ou avec une configuration qui journalise les authentifications sans bloquer. En alternative : les ports RESTent ouverts, mais l’accounting et les requêtes RADIUS fonctionnent en parallèle (selon le fournisseur). Cela vous fournit des données : quels appareils pourraient faire du 802.1X, lesquels ne le peuvent pas, où il y a une randomisation inattendue des adresses MAC, où des appareils sont derrière des commutateurs non gérés ?

Phase 2: Pilotgruppe mit klarer Ownership

Wählen Sie einen Bereich mit supportfähigen Nutzern (IT, Power User, ein Standort), und definieren Sie Erfolgskriterien:

• Connexion/déverrouillage stable
• VPN/VDI/téléphonie/impression fonctionnent
• Pas de coupures « sporadiques » dues à une réauthentification
• Test d’offboarding : retirer l’appareil/le certificat et vérifier le comportement

Phase 3: Stufenweise Enforcement pro Segment

Déploiement le long de limites naturelles : bâtiment/étage/Access-Switch, SSIDs séparées, puis zones centrales. Important : pas « tous les ports en une fois ».

Mettez en place une gestion explicite des exceptions : les appareils spéciaux doivent être enregistrés, classés et transférés dans un profil RESTrictif avant l’enforcement. Sinon, les équipes inventeront des « workarounds » (mini-switch, pont WLAN), qui finissent par être plus risqués que le réseau d’origine.

Praxis-Checklisten: Was Sie vor, während und nach dem Cutover prüfen

Pre-Cutover Check (pro Switch/AP-Block)

• Redondance RADIUS configurée et testée (les deux instances Accept)
• Shared Secrets documentés, sujets à rotation, pas réutilisés
• NTP synchronisé (la dérive temporelle casse TLS et la corrélation des logs)
• DHCP/DNS présents dans les profils Quarantine et Guest
• Atteignabilité de la CRL/OCSP vérifiée depuis le contexte pré-logon (si pertinent)
• Scénario multi-appareils Voice/PC testé
• Accès d’urgence : au moins un port/SSID défini comme Break-Glass (contrôlé physiquement/administrativement)

Cutover-Protokoll (im Betrieb runbook-fähig)

1. Définir la fenêtre de changement et le canal de communication (Ops/Réseau/Sec/Service Desk)
2. Activer l’enforcement pour le bloc défini
3. Vérifier en direct : nouvelles sessions s’authentifient, pas de Port-Flaps
4. Contrôles ponctuels : Windows/macOS/Linux, téléphone, imprimante/IoT
5. Regrouper les logs RADIUS par motifs de Reject (Top-3 causes en priorité)

Post-Cutover: Stabilität und Hygiene

• Réduire les exceptions : inventorier les appareils MAB et les migrer si nécessaire
• Optimiser les intervalles et timers de réauthentification lorsque les données sont stables
• Mettre en place du reporting : authentifications rejetées, nouveaux OUI/fournisseur MAC, classes d’appareils inconnues

Troubleshooting: Die häufigsten Fehlerbilder und wie Sie sie zügig eingrenzen

Les erreurs 802.1X se manifestent souvent de la même manière (« pas de réseau »), mais ont des causes très différentes. Travaillez de manière structurée du bas vers le haut : lien/port, démarrage EAP, requête RADIUS, vérification des certificats, décision de politique, application VLAN/ACL.

Fehlerbild 1: Client bekommt keine IP (DHCP) nach erfolgreichem Login

Les causes ne sont souvent pas « 802.1X en panne », mais un VLAN incorrect, le DHCP absent dans le VLAN cible, ou l’absence de DHCP-Relay/Helper. Vérifiez sur le switch : dans quel VLAN se trouve le port après Accept ? Et : le DHCP est-il autorisé (avec dACL/Filter-IDs) ?

Fehlerbild 2: „Zertifikat nicht vertrauenswürdig“ oder sporadische Warnungen

Typique avec PEAP et aussi pour la validation serveur EAP-TLS : nom de serveur incorrect, certificats intermédiaires manquants, Root-CA obsolète sur les clients, ou CRL/OCSP non atteignable. Si les utilisateurs peuvent ignorer les alertes, c’est un problème de conception. L’objectif : validation stricte du serveur sans invites.

Fehlerbild 3: Telefonie instabil nach Einführung

Souvent dû à une méthode de port incorrecte (pas de Multi-Auth/Multi-Domain), à une priorisation incorrecte (MAB/802.1X), ou à une réauthentification trop agressive. Les appareils VoIP nécessitent souvent un profil dédié (Voice VLAN, marquages QoS), et ils gèrent 802.1X de façons très variées.

Fehlerbild 4: Drucker/IoT fällt aus, obwohl „MAB aktiviert“ ist

Vérifiez la randomisation des adresses MAC (chez certains appareils/adaptateurs), les limites de port-security (nombre maximal d’adresses MAC), et si l’appareil est connecté derrière un petit switch. MAB verra alors l’adresse MAC de l’uplink, pas celle de l’équipement terminal. Dans ces cas, vous aurez besoin soit d’équipements compatibles 802.1X, soit de ports séparés, soit d’une autre stratégie d’accès.

Cas d’erreur 5: tout fonctionne en phase pilote, mais lors du déploiement cela échoue dans certaines zones

Cela indique souvent des templates de switch incohérents, des versions de firmware différentes, des paramètres AAA divergents, ou un problème de routage/firewall vers les serveurs RADIUS. Une gestion de configuration basée sur des diffs pour les équipements réseau s’avère immédiatement utile.

Exemples d’extraits de configuration: ce que vous devez documenter et versionner

La configuration concrète des switchs/AP dépend du fabricant. Pour l’exploitation et le change-control, il est toutefois crucial que vous versionniez proprement vos paramètres : serveurs RADIUS, gestion des secrets, ordre d’authentification, mapping VLAN/ACL, timers, basculement. Ci‑dessous figurent volontairement des exemples génériques comme modèle de documentation.

Définition du client RADIUS (exemple de type INI)

; Dokumentationsvorlage: RADIUS-Clients pro Authenticator
; Nicht 1:1 für ein bestimmtes Produkt gedacht.

[client:access-switch-12]
ip = 10.20.30.12
secret = <rotierbares_shared_secret>
ports = 1812,1813
coa_port = 3799
notes = Access-Layer, Etage 3, Ports 1-48

Mapping de politiques (exemple YAML pour documentation interne/automatisation)

# Beispiel: Rollen auf Netzprofile abbilden (für Doku, IaC oder NAC-Policy-Design)
roles:
  managed_workstation:
    auth_method: eap-tls
    network_profile:
      vlan: 120
      RESTrictions: standard
  managed_admin:
    auth_method: eap-tls
    network_profile:
      vlan: 130
      RESTrictions: privileged
  unmanaged_printer:
    auth_method: mab
    network_profile:
      vlan: 220
      RESTrictions: limited
  guest:
    auth_method: captive_or_psk
    network_profile:
      vlan: 300
      RESTrictions: internet_only
fallbacks:
  radius_unreachable:
    behavior: controlled_fail_open
    network_profile:
      vlan: 210
      RESTrictions: remediation_only

Commandes de diagnostic pour la recherche d’erreurs (Linux-Client, contexte EAP/WLAN)

# Link und Treiberzustand
ip link
nmcli device status

# WLAN-Details (wenn zutreffend)
iw dev

# Logs (systemd-basierte Distributionen)
journalctl -u NetworkManager --since "-30 min" | tail -n 200

Ces blocs ne remplacent pas la documentation fournisseur, mais aident à exploiter votre projet NAC de façon reproductible : ce qui est « standard », ce qui est une exception, et quels fallback ont été délibérément définis ?

Stratégie de retour (rollback) qui fonctionne réellement, pas seulement sur le papier

Un rollback pour 802.1X n’est pas un simple interrupteur lorsque vous avez déjà modifié des VLANs/ACLs et des profils. Définissez donc une stratégie de retour sur trois niveaux :

1) Repli technique par segment

• Templates de ports de switch préparés : « Enforcement » et « Open/Legacy »
• Limites de périmètre claires : quel bloc de switch/AP peut être rétabli de manière isolée ?
• Ports Break-Glass : physiquement sécurisés, documentés et testés

2) Repli AAA (incident RADIUS)

• Exploiter activement la redondance RADIUS (ne pas se contenter d’une installation)
• Supervision de la disponibilité des serveurs RADIUS et des pics de rejets
• Décision définie de fail-open/fail-closed par classe de réseau (bureaux vs. production)

3) Repli organisationnel

• Runbook du Service Desk : quelles questions, quels logs, quelles mesures standard ?
• Communication : page d’état / canal pour les sites concernés
• Critères de gel : à partir de quand le déploiement est suspendu, jusqu’à ce que les causes soient clarifiées ?

L’essentiel est le suivant : le rollback doit être exercé. Un chemin de repli non testé est sans valeur en cas d’incident.

Sécurité et exploitation : hardening, monitoring, cycles de vie

Après le rollout, l’exploitation proprement dite commence. Ces sujets devraient être intégrés à vos processus opérationnels :

• Cycle de vie des certificats : renouvellement automatique, rapports d’expiration, procédures de révocation en cas de perte d’appareil.
• Contrôle des modifications de politique : traiter les changements de rôles/VLAN comme des règles de pare-feu (revue, test, rollback).
• Journalisation/Audit : classifier les raisons de rejet, alerter sur des motifs inhabituels (p. ex. de nombreux événements MAB sur un port).
• Réduction de la dette technique : réduire les exceptions MAB, remplacer les anciens équipements, supprimer les commutateurs « fantômes ».

Conclusion : 1X Network Access Control est un projet qui se consolide avec l’exploitation

802.1X et RADIUS sont des technologies matures, mais leur succès dépend de l’interaction entre identités, certificats, politiques NAC claires et d’un déploiement qui contrôle les exceptions plutôt que de les masquer. Si vous démarrez par une phase de monitoring, séparez proprement les profils (standard, quarantaine, équipements spéciaux), prenez la journalisation au sérieux dès le départ et définissez une véritable stratégie de repli, 1X Network Access Control ne deviendra pas un chantier permanent, mais une base stable pour la segmentation, des modèles d’accès proches du Zero Trust et des décisions réseau auditables.