Outils pour utilisateurs

Outils du site


admin:services:wififederez

Wifi Federez

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)

Identifiants, mots de passe

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

Ex : @federez.crans, @federez.iresam, @federez.rezometz, @federez.rezogif, @federez.via, @federez.resel, @federez.rezel

Après réflexion, il a été décidé de permettre également l'utilisation des suffixes suivants :
@larez.fr
@crans.org
@rezometz.org
@iresam.org

Les 2 systèmes de suffixes sont reconnus.

Les mots de passe sont inchangés

How To

Coté client

Dans le sens Client -> Federez

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 = 62.210.81.204
      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.

Dans le sens Federez->client

* 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 = 62.210.81.204 
        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

Monitoring

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

C'est par ici : https://status.federez.net/

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, si le serveurs répond, il considère que le serveur est up, sinon c'est qu'il est dead.

Enfin, il poste les informations over https via un token sur le cachet.io de FedeRez, hébergé sur dodecagon. (il poste le nom du radius, le last update, le groupe member id…). Tout passe en json via python request.

Etat actuel

Ce qui marche bien :

5 associations où FedeRez wifi est en production et fonctionnel :
Cr@ns, Iresam, VIA, Rezometz, Rezel, Rezorennes

En cours

1 asso où tout est prêt :
Resel : il suffit de diffuser le ssid et de remonter la vm federez des journées.

1 asso où le SSID n'est plus déployé:
Rezogif : les 2 radius sont fonctionnels, mais le SSID non déployé

En dev

Empêcher les connexions locales sur le ssid FedeRez (certaines assos le demandent)

Tout ça grâce à :

Pour le Cr@ns : tudor
Pour le rezo metz : cysi et Lazouz
Pour Iresam : martal et stonfute
Pour le rezo gif : ich, toadjaune, Arlequeen
Pour Via : eugene et Alphabet

Liste non exhaustive

--
Chirac

Projet encore en développement, contacter detraz@crans.org.

admin/services/wififederez.txt · Dernière modification: 2018/07/05 21:41 par chirac