Qu’est-ce que le 802.1X ?

Le 802.1X est une norme de l’IEEE (Institute of Electrical and Electronics Engineers) qui fait partie de la famille des protocoles de sécurité réseau. Il est souvent décrit comme un « port-based network access control » (PNAC), ou un contrôle d’accès basé sur les ports. Concrètement, cela signifie qu’il contrôle l’accès à un réseau local (LAN) ou sans fil (WLAN) en gérant l’authentification des utilisateurs ou appareils au niveau de chaque point d'entrée réseau.

Comment ca marche ?

Le protocole 802.1X repose sur trois acteurs principaux :

• Supplicant (client) : Il s’agit de l’utilisateur ou de l’appareil qui souhaite se connecter au réseau. Le client envoie les informations d’authentification (nom d’utilisateur, mot de passe ou certificat) pour accéder au réseau.
• Authenticator (authentificateur) : Généralement, il s’agit d’un commutateur pour les réseaux câblés ou d'un point d'accès pour les réseaux sans fil. L’authenticator agit comme un intermédiaire entre le client et le serveur d’authentification et contrôle l'accès au réseau.
• Authentication Server (serveur d’authentification) : En général c'est un serveur RADIUS (Remote Authentication Dial-In User Service), il vérifie les informations d'identification envoyées par le client et détermine si l'accès au réseau est autorisé.

Étapes de l'authentification 802.1X

Etapes d’une connexion via le protocole 802.1X :

1. Connexion initiale : Lorsqu'un appareil tente de se connecter au réseau, l'authenticator bloque l'accès jusqu'à ce que l'utilisateur ou l'appareil soit authentifié.
2. Déclenchement de l'authentification : L'authenticator demande des informations d'authentification au client via le protocole EAP (Extensible Authentication Protocol), une méthode de transmission de données de sécurité utilisée par 802.1X pour échanger les informations.
3. Transmission au serveur RADIUS : L'authenticator relaie les informations au serveur RADIUS, qui vérifie les informations d’identification (par exemple, en consultant une base de données d'utilisateurs autorisés).
4. Décision d'accès : Si l’authentification est réussie, le serveur RADIUS informe l’authenticator, qui accorde alors l’accès au réseau au client. En cas d'échec, l’accès est refusé.

Voici un schéma présentant ces étapes

Pourquoi utiliser du 802.1X ?

Le protocole 802.1X présente plusieurs avantages :

• Sécurité renforcée : Il empêche les accès non autorisés en exigeant une authentification formelle de chaque utilisateur ou appareil.
• Centralisation de la gestion des identités : Grâce à l'intégration avec des serveurs RADIUS, il devient possible de centraliser et de gérer l’accès aux ressources réseau à partir d’un point unique.
• Polyvalence : Le protocole s'adapte aux réseaux câblés comme sans fil, facilitant l’intégration dans des environnements hétérogènes.
• Contrôle granulaire : Avec 802.1X, il est possible de configurer des règles spécifiques pour différents utilisateurs et appareils, ce qui permet d'accorder ou de restreindre l'accès à certains segments du réseau en fonction de l'identité.

Le protocol 802.1X est donc un élément essentiel dans la sécurité réseau. En exigeant une authentification forte avant d'accorder l'accès, il garantit que seuls les utilisateurs et dispositifs autorisés peuvent entrer dans un réseau.

Dans notre cas, nous allons configurer de façon à pouvoir faire également de la double authentification 802.1x et MAB (MAC Authentication Bypass).

Nous n'allons pas aborder la partie configuration coté base de donnée pour le MAB.

1-Configuration 802.1 filaire pour windows

1.1-Activation du service

• Appuyer sur la touche Windows + R
• Dans la fenêtre "exécutez", saisir "service.msc"
• Cliquer sur "OK"
• Démarrer le service "configuration automatique de réseau câblé"

1.2-Configuration de la carte réseau filaire

• Appuyer sur la touche Windows + R
• Dans la fenêtre "exécutez", saisir "ncpa.cpl"
• Cliquer sur "OK"
• Clique droit sur la carte réseau > propriété

Onglet "authentification" :

Dans les paramètres PEAP :

Dans la configuration de MSHCHAP-V2 :

Retour dans l’onglet authentification, dans « paramètres supplémentaires » :

2-Configuration du commutateur (authenticator)

2.1-Paramètres généraux

Configuration pour un switch Allied Telesis

radius-server host 192.168.34.68 timeout 2 retransmit 2 key *******
aaa authentication dot1x default group radius
aaa authentication auth-mac default group radius

2.2-Création de plusieurs profils d’authentification

• Profil d’authentification MAB (MAC Authentication Bypass) pour les téléphones ou du matériel qui n'est pas capable de faire du 802.1x

  auth profile mab
   auth-mac enable
   auth reauthentication
   auth timeout reauth-period 43200
   auth timeout server-timeout 2
   auth host-mode multi-supplicant
   auth max-supplicant 2
   auth dynamic-vlan-creation type multi
  

• Profil d’authentification dot1x (802.1x)

  auth profile dot1x
   dot1x port-control auto
   dot1x control-direction both
   auth reauthentication
   auth timeout reauth-period 300
  

• Profil d’authentification filaire en deux étapes (auth profile two-step-auth) pour les ordinateurs :
  1. 802.1x (utilisateur + mdp)
  2. MAB (authentification par adresse mac en dernier pour l’attribution du vlan dynamiquement)

  auth profile two-step-auth
   auth-mac enable
   dot1x port-control auto
   auth reauthentication
   auth timeout reauth-period 300
   auth session-timeout
   auth host-mode host-plus-voice
   auth max-supplicant 2
   auth dynamic-vlan-creation type multi
   auth-mac reauth-relearning
   auth two-step enable
   auth two-step order dot1x auth-mac
  

3-Configuration RADIUS

3.1-client.conf

Un client (wired-dot1x-mgmt) est configuré (fichier clients.conf) pour traiter les demandes des authenticator se trouvant dans les plages mgmt (ex 192.168.240.0/20).

Partie de configuration de clients.conf :

client wired-dot1x-mgmt {
    ipv4addr = 192.168.240.0/20
    shortname = "wired-dot1x-mgmt"
    secret = "*********"
    virtual_server = VS-dot1x
}

3.2-Serveur virtuel utilisé en dehors du tunnel

Le client est associé à un serveur virtuel (VS-dot1x) qui est utilisé pour la partie MAB et pour la partie outer tunnel 802.1x

• Si un EAP-Message est vu alors on utilise le module eap (partie peap qui va rediriger vers le serveur virtuel (VS-dot1x-inner-tunnel) pour l’authentification en tunnel interne.
• S’il n’y a pas d’EAP-Message alors c’est l’authentification par adresse mac qui sera utiliser (MAB) par l’intermédiaire du module sql.

Partie de configuration de la section authorize du serveur virtuel VS-dot1x :

if(!EAP-Message) {
  sql
} else {
    eap {
    ok = return
  }
}

3.3-Serveur virtuel utilisé à l’intérieur du tunnel

Pour l’authentification 802.1x nous utilisons PEAP avec mshchapv2, nous sommes donc rediriger depuis le module eap, vers le serveur virtuel « VS-dot1x-inner-tunnel ».

Partie de configuration de la section authorize du fichier VS-dot1x-inner-tunnel :

mschap
if(&User-Name =~ /@/){
  suffix
}else{
  ntdomain
}
ldap
eap {
  ok = return
}

Si l’on détecte un « @ » dans le nom d’utilisateur nous allons utiliser la section « suffix » du module realm pour récupérer le nom et l’injecter dans la variable « Stripped-User-Name » qui sera la donnée utiliser pour vérifier l’existence du compte dans le ldap.

Le suffix, quant à lui, sera utile pour déterminer quel realm sera utilisé par l’intermédiaire du proxy.conf (authentification en local ou rediriger vers un autre serveur).

Exemple pour toto.dupont@mail-de-l-organisation.com :

• Stripped-User-Name = toto.dupont
• Realm = mail-de-l-organisation.com

Sinon on utilise la section « ntdomain » du module realm, c’est le même principe sauf que c’est le préfixe avant le délimiteur "" qui sera utilisé pour déterminer le realm au niveau du proxy.conf.

Exemple pour DomainOrg\tdupont :

• Stripped-User-Name = tdupont
• Realm = DomainOrg

Si aucun délimiteur n’est trouvé dans le nom d’utilisateur ou si le realm récupéré dans le suffix ou prefix, alors le realm est null et l’authentification se fait en local.

En résumé le ntdomain et suffix permettent de pouvoir authentifier les utilisateurs en :

• prenom.nom@mail-de-l-organisation.com (pour matériel qui n’est pas sur le domaine)
• DomainOrg\nomcourt (pour matériel qui est sur le domaine)
• prenom.nom (pour matériel qui n’est pas sur le domaine)

3.4- Module realm

Partie de configuration de la section suffix du module realm :

realm suffix {
  format = suffix
  delimiter = "@"
}

Partie de configuration de la section ntdomain du module realm :

realm ntdomain {
  format = prefix
  delimiter = "\\"
}

3.5- Configuration du proxy

Partie de configuration de la section realm mail-de-l-organisation.com du proxy.conf :

realm mail-de-l-organisation.com {
  type      = radius
  authhost  = LOCAL
  accthost  = LOCAL
}

Partie de configuration de la section realm DomainOrg du proxy.conf :

realm DomainOrg {
  type = radius
  authhost = LOCAL
  accthost = LOCAL
}

3.6- Module ldap

Maintenant que nous avons récupéré notre « Stripped-User-Name » nous sommes redirigé vers le module ldap qui va rechercher notre compte par rapport à la donnée de la variable « Stripped-User-Name » soit le prenom.nom, soit le nom court.

Coté LDAP nous avons besoin dans la branche dans laquelle nous recherchons l’utilisateur d’avoir les attributs suivant :

• uid (qui correpond au prenom.nom)
• supannAliasLogin (qui correspond au nom court)
• sambaLMPassword
• sambaNTPassword

Coté radius, au niveau de la requête pour trouver le compte nous allons rechercher :

• Soit par l’uid (dans le cas d’une authentification prenom.nom ou prenom.nom@*.fr
• Soit par le supannAliasLogin (dans le cas d’une authentification avec domaine\nomcourt)

base_dn = 'ou=service,ou=services,dc=organisation,dc=com'
user {
  base_dn = "${..base_dn}"
  filter = "(|(supannAliasLogin=%{%{Stripped-User-Name}:-%{User-name}})(uid=%{%{Stripped-User-Name}:-%{User-name}}))"
}

Au niveau du mot de passe, le module ldap va faire la corrélation au niveau de sa donnée de contrôle NT-Password et LM-Password avec les attributs LDAP de cette manière :

update {
  control:NT-Password := 'sambaNtPassword'
  control:LM-Password := 'sambaLmPassword'
}

Si le mot de passe est correct, l’authentification est réussie, cette information est renvoyée à l’authenticator/commutateur.

Dans le cadre d’une authentification à deux facteurs, la partie 802.1x/dot1x est ok et l’authentification MAB peut se faire (au travers cette fois, côté radius, du module sql qui va interroger la base de donnée).

Si le radius confirme que cette adresse mac existe et quelle est légitime, il transfère cette information ainsi que le numéro du vlan au commutateur/authenticator, qui va définir le port en autorisé et appliquer dynamiquement le bon vlan d’accès.

4- Conclusion

A vous d'adapter cette configuration en fonction de vos besoins.

Cette méthode d’authentification fonctionne sur les Allied Telesis x530 et les Cisco.

Elle permet de s’authentifier aussi bien avec du windows qu’avec du linux (testé avec Ubuntu, linux Mint).

Elle implique, néanmoins, d’avoir un port par machine authentifié.

Il faudra donc décorréler les ordinateurs des téléphones VOIP et les mettre chacun sur un port distinct.

Il faudra également, au niveau LDAP, définir comment l’on distingue les personnels autorisés ainsi que les attributs supanAliasLogin / uid / sambaLmPassword/sambaNtPassword.

Au niveau RDP, le 802.1X n'est tout simplement pas en mesure d'obtenir les informations d'identification de l'utilisateur à partir d'une session de connexion. La seule solution de contournement connue consiste à utiliser l'authentification par ordinateur pour obtenir des résultats 802.1X fiables dans une session RDP.