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. (bon en fait c'est pas encore fait, mais je m'en occupe très bientôt)

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

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

Cas de Beaune

TODO

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
  • Versionner la conf et mettre un lien ici
  • Expliquer un peu la conf
  • Vérifier que les infos de proxy radius sont toujours exactes