Différences

Ci-dessous, les différences entre deux révisions de la page.

--- admin:services:wifi-federez [2015/05/21 00:41] – old revision restored chirac
+++ admin:services:wififederez [2020/11/11 22:47] (Version actuelle) – [How To] david
@@ Ligne 1: / Ligne 1: @@
-= Wifi Federez =
+====== Wifi Federez ======
 Il s'agit d'un système d'authentification radius wifi commune.
@@ Ligne 8: / Ligne 8: @@
-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, baldrick.
+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
+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 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
+==== 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
+<code>
+# 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
+</code>
+ * Ensuite, il faut éditer ledit proxy.conf pour y rajouter le serveur proxy qui sera utilisé, c'est à dire celui de federez :
+<code>
+# 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
+}
+</code>
+ 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) :
+<code>
+        if (User-Name !~ /@(.*)crans(.*)$/) {
+             if (User-Name =~ /^(.*)@(.*)/) {
+                 update control {
+                 Proxy-To-Realm := 'FEDEREZ'
+             }
+          }
+        }
+</code>
+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 :
+<code>
+# 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
+        }
+</code>
+ * 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.
+<code>
+Ex pour ldap :
+filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})"
+</code>
+ * Il faut ensuite peupler ce stripped username, ca se passe dans le site défaut. (comme pour les realms)
+<code>
+        if ("%{request:User-Name}" =~ /^(.*)@(.*)crans(.*)/) {
+            update request {
+                Stripped-User-Name := "%{1}"
+                }
+        }
+</code>
+ * Enfin, il peut être nécessaire de transmettre cette variable à l'intérieur du tunnel :
+<code>
+copy_request_to_tunnel = yes
+</code>
+=== Monitoring ===
+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.
+=== Etat actuel ===
+Ce qui marche bien :
+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.