Remote Authentication Dial-In User Service (RADIUS)

Généralités

Le RADIUS est un service permettant de faire une authentification de machines ou personnes. Il permet au ResEl l'authentification des administrateurs sur les switchs cisco, mais également l'authentification des utilisateurs sur le Wi-Fi.

Le service utilisé est FreeRADIUS et il est hébergé à Brest sur les machines :

  • beowulf pour les utilisateurs (utilise le LDAP de Brest)

  • rescuerad pour les utilisateurs (utilise le LDAP de Rennes)

  • Beaune pour les switchs

Il est hébergé à Rennes sur :

Authentification en Wi-Fi

L'authentification en Wi-Fi utilise l'authentification PEAPv0/EAP-MSCHAPv2.

Configuration

Freeradius est utilisé en version 3 (la version disponible sur debian Stretch). La configuration entre les versions 2.x et 3.x à beaucoup évolué, et il y a actuellement très peu de documentation sur la version 3.x.

Il existe un tutoriel, assez incomplet et pas toujours très clair, pour transformer une configuration 2.x en 3.x.

Emplacement des différents fichers de configuration

Les fichiers de configurations de freeradius sont dans le répertoire /etc/freeradius/3.0/ :

freerad@beowulf ~/3.0 % ls
README.rst  clients.conf  experimental.conf  huntgroups@      mods-config/   
panic.gdb    policy.d/   radiusd.conf      sites-enabled/  trigger.conf
certs/      dictionary    hints@      mods-available/    mods-enabled/  
policy.conf  proxy.conf  sites-available/  templates.conf  users@

Les principaux fichiers de configuration sont détaillés ci-après :

Configuration principale de freeradius 3.x

radiusd.conf

Le fichier de configuration principal de freeradius est radiusd.conf.

Pas de remarques particulières concernant ce fichier, si ce n'est qu'il n'est plus possible d'y mettre de directive listen enversion 3.x. Tout ce qui concerne la connexion au serveur Radius doit maintenant se trouver dans mods-enabled/default ou le serveur virtuel de son choix. (La documentation semble dire qu'il est toujours possible de la mettre dans radiusd.conf, cependant cela a causé de nombreux problèmes dans la configuration et je le déconseille donc fortement).

clients.conf

Ce fichier référence les différents clients depuis lesquels il est possible d'envoyer des requêtes radius (en l'occurence, des bornes wifi et des switchs).

L'ancienne configuration : 

client 123.456.789.421 {
  shortname = "borne_wifi"
  secret = "sùperSecretpa55W0rD!"
}
devrait disparaitre dans une future version au profit de : 
client borneWifiDuPremierEtage {
  ipv4addr = 123.456.789.421
  shortname = "borne_wifi_01"
  secret = "sùperSecretpa55W0rD!"
}

Configurer un client localhost peut s'avérer utile pour tester le radius.

users

users est un lien symbolique vers mods-config/files/authorize, et est donc la nouvelle localisation du fichier 'users' des version 2.x et antérieures.

Il fait donc maintenant partie du module files qui doit être activé dans la config du serveur virtuel, mais qui doit aussi avoir un fichier de configuration dans mods-enabled/.

Modules

Depuis la version 3.x, freeradius à abandonné le dossier modules au profit d'un dossier mods-available et mods-enabled, fonctionnant de manière assez classique. A l'installation le dossier mods-enabled contient les exemples de configuration des différents modules.

Le dossier mods-enabled contient donc le fichier de configuration principal des modules chargés par le serveur freeradius. Les modules dont le fichier de configuration principal fait appel à d'autres fichiers de configuration stoquent ces config secondaires dans le répertoire mods-config

Serveurs Virtuels

Les dossiers sites-available et sites-enabled contiennent les configuration pour les différents serveurs virtuels. Le dossier sites-available contient des exemples de serveurs virtuels pour différentes utilisations-type ainsi qu'un README explicatif concernant les serveurs virtuels.

Configuration de freeradius au ResEl :

La configuration de freeradius est versionnée et disponible sur le git.

Avant de l'utiliser lire le Readme.md

Configuration d'un serveur RADIUS pour authentification PEAPv0/EAP-MSCHAPv2

C'est le serveur configuré sur Beowulf, Rescuerad et Wifiradix. La documentation disponible sur internet pour la version 2.x pour réaliser ce type de serveur est assez succinte, dans la version 3.x elle est inexistante à l'heure actuelle. Je vais essayer de détailler ce que j'ai réussi à comprendre ici, mais des erreurs peuvent se glisser dans les explications.

Configuration de base

Rien de particulier dans ces fichiers, simplement configurer un client localhost dans clients.conf permettra de tester la configuration (voir sections suivantes).

Serveurs virtuels

Deux serveurs virtuels sont nécessaires : default et inner-tunnel. Le premier réponds aux requêtes Radius provenant des bornes wifi. Le second est utilisé par le module EAP pour réaliser l'authentification MS-CHAPv2. Il ne réponds donc que aux requêtes locales (en provenance de la machine hôte du Radius).

On a donc, dans le répertoire sites-enabled, deux fichiers nommmés default et inner-tunnel. ATTENTION : On n'utilise pas les fichiers dans le dossier sites-available. Les fichiers dans sites-enabled ne sont PAS des liens symboliques. Ne ne demandez pas pourquoi.

default

La configuration complète de ce serveur virtuel est disponible ici

Points-clefs, dans l'ordre:

listen{
  type = auth
  ipaddr = *
  port = 1812
}
On configure un serveur virtuel qui va répondre aux requêtes en provenance de toutes les ip. (en réalité on définit les clients dans le fichier correspondant, voir plus haut) 
authorize {
  if (User-Name !~ /resel(.*)$/) {
    if (User-Name =~ /^(.*)@(.*)/) {
      update control {
        Proxy-To-Realm := 'FEDEREZ'
      }
    }
  }

  ......
}
Authentification pour les utilisateurs externes au ResEl mais faisant partit d'un réseau partenaire Federez (je ne sais pas si ça fonctionne toujours) 
authorize{
...

eap {
  ok = return
}

...
}
Permet l'exécution de requêtes de type EAP 
authorize{
...

files

...
}
Permet l'authentification avec le modules files (fichier users dans les versions de freeradius antérieures à la 3.x). Nagios et ???? se connectent au Radius via ce module. 
authenticate{
...

eap

...
}
Liste le module eap parmi les modules utilisables pour l'authentification.
inner-tunnel

La configuration complète de ce serveur virtuel est disponible ici

Points-clefs, dans l'ordre:

listen {
  ipaddr = 127.0.0.1
  port = 18120
  type = auth
}
Le serveur virtuel n'écoute que les requêtes locales, en provenance de la machine elle-même. 
authorize {

  mschap

  ...
}
Utilise le module mschap pour l'authentification. 
authorize {

  ...

  ldap
  pap
}
Utilise le LDAP pour trouver le mot de passe. Je ne sais pas pourquoi pap est listé aussi, quoi qu'il en soit si je ne le met pas après ldap une erreur bizarre apparait. 
authenticate {

  Auth-Type MS-CHAP {
    mschap
  }
}
Autorise le module mschap

Modules utilisés

De nombreux modules sont actvés, beaucoup sont activés par défault et leur config n'a pas été modifié. Elles ne seront pas détaillées ici.

18:53 root@beowulf ~ # ls ~freerad/3.0/mods-enabled
always@      digest@           expr@       mschap@      realm@      utf8@
attr_filter@  dynamic_clients@  files       ntlm_auth@   replicate@
cache_eap@   eap               ldap@       pap@         soh@
chap@        echo@             passwd@      sradutmp@
detail@      exec@             linelog@    preprocess@  unix@
detail.log@  expiration@       logintime@  radutmp@     unpack@
eap
eap {
    default_eap_type = peap
    timer_expire         = 60
    ignore_unknown_eap_types = no
    cisco_accounting_username_bug = no
    max_sessions = 4096

    tls-config tls-common {
        certdir = ${confdir}/certs
        cadir = ${confdir}/certs


        private_key_file = ${certdir}/wifi/2017/resel-fr.key
        certificate_file = ${certdir}/wifi/2017/resel-chained.pem
        dh_file = ${certdir}/dh
        random_file = /dev/urandom
        fragment_size = 1024
        include_length = yes
        ca_path = ${cadir}/empty

    }



    ttls {
        tls = tls-common

        default_eap_type = mschapv2
        copy_request_to_tunnel = yes
        use_tunneled_reply =yes
        virtual_server = "inner-tunnel"
        include_length = yes
    }
    peap {
        tls = tls-common

        default_eap_type = mschapv2
        copy_request_to_tunnel = yes
        use_tunneled_reply = yes
        virtual_server = "inner-tunnel"
    }
    mschapv2 {
        send_error = yes
    }
}
ldap

la configuration complète du module est disponible ici pour brest et ici pour Rennes. Le lien symbolique dans le dossier mods_enabled pointe vers le bon fichier. (il ne faut pas utiliser le fichier présent dans mods_available/ldap⁾

Cas de Beaune

TODO

Tester son serveur RADIUS

Pour tester l'authentification PEAPv0/MSCHAPv2 il y a deux outils. En effet, il faut tester séparément la partie MSCHAP et la partie EAP.

Test de l'authentification MSCHAP

C'est la première chose à tester. En effet, si l'authentification MSCHAP ne fonctionne pas l'authentification EAP n'aboutiera pas.

On va donc tester le Radius Virtuel "inner-tunnel" séparément

Pour cela, on utilise la commande radtest :

radtest -t mschap USER PASSWORD 127.0.0.1:18120 10 testing123 ou :

  • -t mschap permet de sélectionner l'authentification

  • USER et PASSWORD sont les identifiants d'un utilisateur de test du LDAP (on peut utiliser n'importe lequel, mais il faut écrire le mot de passe en clair dans la commande). Au ResEl, on peut utiliser le couple id/pwd : jdoetwo/jdoetwo.

  • 10 ne sert à rien mais est un paramètre obligatoire (voir man radtest)

  • testing123 est le mot de passe pour localhost dans le fichier client.conf

si la réponse ressemble à ceci alors le inner-tunnel doit être fonctionnel.

freerad@beowulf ~/3.0 % radtest -t mschap jdoetwo jdoetwo localhost:18120 10 testing123
Sent Access-Request Id 217 from 0.0.0.0:44752 to 127.0.0.1:18120 length 133
	User-Name = "jdoetwo"
	MS-CHAP-Password = "jdoetwo"
	NAS-IP-Address = 127.0.0.1
	NAS-Port = 10
	Message-Authenticator = 0x00
	Cleartext-Password = "jdoetwo"
	MS-CHAP-Challenge = 0x2f9b49eb165fcd82
	MS-CHAP-Response = 0x000100000000000000000000000000000000000000000000000059aa57b76bf01ea415ba8d7d2a14e4ec3759c805c29272a4
Received Access-Accept Id 217 from 127.0.0.1:18120 to 0.0.0.0:0 length 84
	MS-CHAP-MPPE-Keys = 0x00000000000000001a6f5e791bb802ec0f728f34860e1921
	MS-MPPE-Encryption-Policy = Encryption-Allowed
	MS-MPPE-Encryption-Types = RC4-40or128-bit-Allowed

La partie intéressante est Received Access-Accept Id 217 from 127.0.0.1:18120 to 0.0.0.0:0. En cas d'erreur on doit recevoir un Access-Reject.

Test de l'authentification PEAP

Pour tester l'authentification PEAP j'utilise l'outil eapol_test à compiler depuis les sources de wpa_supplicant. Un tuto est disponible ici. Le problème étant que je n'ai pas réussi à le compiler (des erreurs dans le code source, apparament...) donc j'ai réussi à le télécharger sur le site de Eduroam Tchèque.

Le fichier de configuration pour tester l'authentificatation PEAPv0/MSCHAPv2 à été trouvé sur deployingradius.com/scripts/eapol_test/ Des fichiers de configuration pour d'autres authentification sont aussi disponibles

peap-mschapv2.conf
#
#   eapol_test -c peap-mschapv2.conf -s testing123
#
network={
        ssid="example"
        key_mgmt=WPA-EAP
        eap=PEAP
        identity="jdoetwo"
        anonymous_identity="jdoetwo"
        password="jdoetwo"
        phase2="autheap=MSCHAPV2"

	#
	#  Uncomment the following to perform server certificate validation.
#	ca_cert="/etc/raddb/certs/ca.der"
}

Pour effectuer le test, la commande est la suivante:

sudo ./eapol_test -c peap-mschapv2.conf -s testing123 en se placant dans le répertoire contenant l'exécutable de eapol_test et le fichier de configuration.

  • -s testing123 est l'option pour choisir le mot de passe pour localhost configuré dans clients.conf

L'output est très verbeux, mais normalement si l'authentification échoue c'est assez clair. Avec une authentification réussie les dernières lignes sont : 

...
EAPOL: Received EAP-Packet frame
EAPOL: SUPP_BE entering state REQUEST
EAPOL: getSuppRsp
EAP: EAP entering state RECEIVED
EAP: Received EAP-Success
EAP: EAP entering state SUCCESS
CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
EAPOL: IEEE 802.1X for plaintext connection; no EAPOL-Key frames required
WPA: EAPOL processing complete
EAPOL: SUPP_PAE entering state AUTHENTICATED
EAPOL: SUPP_BE entering state RECEIVE
EAPOL: SUPP_BE entering state SUCCESS
EAPOL: SUPP_BE entering state IDLE
eapol_sm_cb: success=1
PMK from EAPOL - hexdump(len=32): 4d e7 bf c7 3f 05 e8 dd 8d d0 12 2d 98 9a 94 3d e7 fb 25 77 92 74 00 4f 1c 41 01 fc 2b ce 76 41
EAP: deinitialize previously used EAP method (25, PEAP) at EAP deinit
ENGINE: engine deinit
MPPE keys OK: 1  mismatch: 0
SUCCESS

On peut aussi regarder si on a bien recu un auth ok dans le fichier de log radius.log par défault dans /var/log/freeradius/radius.log pour l'utilisateur jdoe.

Proxy RADIUS

Dans le cadre d'un éventuel partenariat, les utilisateurs externes pourraient utiliser leur identifiants distants pour se loguer localement (à la "eduroam").

Ce service est utile pour la connexion au Wi-Fi Federez.

Exemple pour un utilisateur du ResEl en roaming chez un partenaire

Dans cet exemple, le partenaire fictif serait '''unet.fr'''

  • John Doe (utilisateur jdoe au ResEl) veut se connecter chez UNet. Pour cela, il utilise le nom d'utilisateur suivant: jdoe@resel.fr et son mot de passe habituel.
  • Le serveur radius de UNet comprend que la requête concerne le ResEl et redirige le dialoque vers notre pool de serveurs RADIUS.
  • Notre pool de serveurs RADIUS prend une décision, qui est ensuite appliquée par le point d'accès auquel John Doe s'est connecté.

Exemple pour un utilisateur d'un partenaire en roaming chez nous

Dans cet exemple, le partenaire fictif serait '''unet.fr'''

  • Emma Michu (utilisatrice emichu chez UNet) veut se connecter chez nous. Pour cela, elle utilise le nom d'utilisateur suivant: emichu@unet.fr et son mot de passe habituel.
  • Le serveur radius comprend que la requête concerne UNet et redirige le dialoque vers leur pool de serveurs RADIUS.
  • Le pool de serveurs RADIUS d'UNet prend une décision, qui est ensuite appliquée par le point d'accès auquel Emma Michu s'est connectée.

Radmin : Outil de debug radius

Radmin est un outil qui permet de contrôler le serveur radius la manPage est dispo ici : http://freeradius.org/radiusd/man/radmin.html

faire une trace pour un utilisateur

  • créer un fichier vide avec les droits 777 dans le répertoire /var/log/freeradius ce fichier va contenir l'ensemble des messages radius que l'on souhaite capturer
23:27 srecher@beowulf ~ % sudo touch /var/log/freeradius/radmin_20141102_voileux.log
23:28 srecher@beowulf ~ % sudo chmod 777 /var/log/freeradius/radmin_20141102_voileux.log

  • lancer radmin 

    23:24 srecher@beowulf ~ % sudo radmin
radmin 2.1.12 - FreeRADIUS Server administration tool.
Copyright (C) 2008-2011 The FreeRADIUS server project and contributors.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
You may redistribute copies of FreeRADIUS under the terms of the
GNU General Public License v2.
radmin>
    • indiquer le niveau de debug voulu (0 le plus élevé) 
      radmin> debug level 0

  • indiquer le fichier de log précédemment créé 

    radmin> debug file radmin_20140211_voileux.log

  • indiquer le filtre 

    23:28 srecher@beowulf ~ % sudo radmin -e "debug condition '(User-Name == voileux)'"
    a la place de voileux mettre le login de l'utilisateur

ou sinon mettre condition * si vous voulez voir tout les messages radius

  • lire le fichier de log qui contient la trace réaliser

Arrêter le debug

23:28 srecher@beowulf ~ % sudo radmin -e "debug condition"

voir les infos de debug

radmin> show debug file

radmin> show debug condition

radmin> show debug level

TODO (rédacteur)

  • Détailler un peu le rôle de chaque serveur
  • Vérifier que les infos de proxy radius sont toujours exactes