Outils pour utilisateurs

Outils du site


admin:services:wififederez

Ceci est une ancienne révision du document !


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, hexagon 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 hexagon 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

Les identifiants sont 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

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 = hexagon
      home_server = parangon
}


home_server hexagon {
      type = auth
      ipaddr = 5.39.82.35
      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 = 138.231.142.239
      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 138.231.142.239 {
        secret          = secret_convenu_avec_federez_admin
        }
        
# Hexagon (radius de federez)
client 5.39.82.35 {
        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}" =~ /^(.*)@/) {
            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 : monitoring

Un script, status.sh situé dans le /root/federezwifi de 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 radtest, si le serveurs répond, il considère que le serveur est up, sinon c'est qu'il est dead.

Ensuite, il construit un template à partir de ces données, qui est la page wiki telle qu'affichée à la section monitoring.

Pour finir, il copie via scp ce template d'abord dans /home/wififederez de hexagon, puis en tant que www-data (pour faire les choses proprement), il met la page dans le data du wiki.

Etat actuel

Ce qui marche bien :

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

En cours

Rezel (Telecom Paris)

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

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.1460936128.txt.gz · Dernière modification : 2016/04/18 01:35 de chirac

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki