Il s'agit d'un système d'authentification radius wifi commune.

Le principe est simple : un adhérent d'une asso federez en déplacement dans un autre campus doit pouvoir se connecter.

Ce système est conçu un peu comme eduroam.

L'implantation actuelle consiste à rediriger les requêtes qui ne concerne pas le campus hôte (ex : .crans.org à iresam metz) vers le serveur radius centrale de federez, dodecagon et parangon.

Celui-ci reconnait la bonne destination, et renvoi la requête vers le bon serveur radius.

Coté technique, il est nécessaire d'ajouter chaque radius du projet dans le proxy.conf de dodecagon et parangon, et de mettre ceux-ci dans le client.conf de chaque radius des assos.

Enfin, dans le sites available pertinent, il faut rajouter une règle qui choisi ou non la proxification sur chaque radius, suivant la tête de l'identifiant anonyme (if .crans… etc)

Au départ, les identifiants étaient ceux que vous utilisez sur le wifi de vos asso, auxquels on rajoute un suffixe.

Les suffixe à adosser au login sont les suivants :

CRANS → @crans.org
Rezometz → @rezometz.org
ViaRezo → @viarezo.fr ou @larez.fr
Rezorennes → @rez-rennes.fr
Resel → @resel.fr
Aurore → @auro.re
Rezoleo → @rezoleo.fr

Les mots de passe sont inchangés

Si vous voulez vous aussi faire partie du projet, ce n'est pas très compliqué.

Il faut cependant comprendre que les authentification se font dans les 2 sens : federez→votre_radius, et votre_radius→ federez.

La partie proxy.conf et realm concerne donc le second sens, et la partie client.conf le premier, nous allons y revenir.

Il convient principalement de modifier 4 fichiers dans la configuration de freeradius sur votre serveur.

* Tout d'abord, il faut éditer le /etc/freeradius/radiusd.conf, et activer la fonctionnalité de proxy. Ici, il faut décommenter

# PROXY CONFIGURATION
#
#  To disable proxying, change the "yes" to "no", and comment the
#  $INCLUDE line.
#
#  allowed values: {no, yes}
#
proxy_requests  = yes
$INCLUDE ${raddbdir}/proxy.conf

* Ensuite, il faut éditer ledit proxy.conf pour y rajouter le serveur proxy qui sera utilisé, c'est à dire celui de federez :

# Proxy federez à utiliser   ####

realm FEDEREZ {
      auth_pool = federez_radius_servers
      nostrip
}

home_server_pool federez_radius_servers {
      type = fail-over
      home_server = dodecagon
      home_server = parangon
}


home_server dodecagon {
      type = auth
      ipaddr = 195.154.165.76
      port = 1812
      secret = un_secret_a_convenir_avec_federez_admin
      require_message_authenticator = yes
      response_window = 20
      zombie_period = 40
      revive_interval = 120
      status_check = status-server
      check_interval = 30
      num_answers_to_alive = 3
}

home_server parangon {
      type = auth
      ipaddr = 185.230.78.47
      port = 1812
      secret = un_secret_a_convenir_avec_federez_admin
      require_message_authenticator = yes
      response_window = 20
      zombie_period = 40
      revive_interval = 120
      status_check = status-server
      check_interval = 30
      num_answers_to_alive = 3
}

Maintenant, votre serveur est prêt à envoyer des requêtes d'authentification radius à Federez. Il ne peut pas encore en recevoir de federez. Il y a un autre problème ; il faut définir la règle qui va activer ou non la transmission de la requète à federez.

* Cela se passe dans /etc/freeradius/sites-available/defaut , il faut rajouter une petit règle (remplacer crans par votre asso évidemment) :

        if (User-Name !~ /@(.*)crans(.*)$/) {
             if (User-Name =~ /^(.*)@(.*)/) {
                 update control {
                 Proxy-To-Realm := 'FEDEREZ'
             }
          }
        }

Explication : dans cet exemple, on se situe au avec un login toto@federez.asso, la requête sera envoyée à FedeRez, pour toto différent de Crans. En effet, si il y a crans, on créerait alors une boucle entre le serveur FedeRez et le serveur local, chacun renvoyant la règle à l'autre…

Avec ça, tous les identifiants qui ne correspondent à @moncampus.org seront envoyés se faire authentifier vers federez-wifi.

* Il faut que le serveur puisse recevoir les requètes venant de federez.

Pour cela, il suffit d'ajouter baldrick dans le /etc/freeradius/client.conf :

# Parangon (radius de federez)
client parangon {
        ipaddr = 185.230.78.47
        secret          = secret_convenu_avec_federez_admin
        }
        
# Dodecagon (radius de federez)
client dodecagon {
        ipaddr = 195.154.165.76
        secret          = secret_convenu_avec_federez_admin
        }

* Mais la client reçoit des requêtes du type toto@federez.iresam, il faut retirer le @federez.iresam. Il faut modifier l'authentification ldap/sql, pour qu'elle n'utilise pas le User-Name, mais une autre variable, le stripped-username.

Pourquoi ne pas modifier le username directement ? Le protocole mschapv2 ne supporte pas cela, car il utilise le username comme sel au moment du chiffrement du mot de passe…

On ruse donc, on peuple une variable stripped username (voir ci dessous) qu'on utilise alors au moment de la recherche ldap/postgresql.

Ex pour ldap :
filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})"

* Il faut ensuite peupler ce stripped username, ca se passe dans le site défaut. (comme pour les realms)

        if ("%{request:User-Name}" =~ /^(.*)@(.*)crans(.*)/) {
            update request {
                Stripped-User-Name := "%{1}"
                }
        }

* Enfin, il peut être nécessaire de transmettre cette variable à l'intérieur du tunnel :

copy_request_to_tunnel = yes

Il est évidemment nécessaire de savoir si les serveurs freeradius du projet sont up ou down.

Un script, situé dans /root/federez-wifi/eapol_test.py sur parangon est exécuté par un cron toutes les 5 min. Il parse la liste des serveurs présents dans le /etc/freeradius/proxy.conf.

Pour chaque serveur radius, il extrait l'ip, le secret et le nom.

Puis il lance une commande eapoltest avec les bons arguments, login et mot de passe, si le serveurs répond ok, il considère que le serveur est up, sinon c'est qu'il est dead.

Enfin, il poste les informations via un script over ssh sur le présent wiki situé sur dodecagon.

Ce qui marche bien :

8 associations où FedeRez wifi est en production et fonctionnel :
Cr@ns, Supélec Rezo Rennes, AURORE, Rezo Metz, ViaRézo, Rézoléo, Resel.

--
Pour toute question sur le projet, contacter detraz@crans.org.