Différences

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

--- admin:services:wififederez [2015/10/17 10:56] – [How To] chirac
+++ admin:services:wififederez [2020/11/11 21:47] (Version actuelle) – [How To] david
@@ 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 le bon serveur radius.
-Coté technique, il est nécessaire d'ajouter chaque radius du projet dans le proxy.conf du baldrick, et de mettre baldrick dans le client.conf de chaque radius des assos.
+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)
@@ Ligne 19: / Ligne 19: @@
 ===== Identifiants, mots de passe =====
-Les identifiants sont ceux que vous utilisez sur le wifi de vos asso, auxquels on rajoute un @federez.votreasso
+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
-Ex : @federez.crans, @federez.iresam, @federez.resometz, @federez.rezogif
 Les mots de passe sont inchangés
@@ Ligne 63: / Ligne 72: @@
 home_server_pool federez_radius_servers {
       type = fail-over
-      home_server = baldrick
+      home_server = dodecagon
+      home_server = parangon
 }
-home_server baldrick {
+home_server dodecagon {
       type = auth
-      ipaddr = 138.231.142.239
+      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
@@ Ligne 83: / Ligne 108: @@
  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 :
+ * 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}" !~ /moncampus$/) {
-            update control {
-                Proxy-To-Realm := 'FEDEREZ'
-            }
-        }
-</code>
-Si jamais les identifiants de votre campus ne sont pas en @moncampus.org, on peut ruser, par ex:
 <code>
-        if (User-Name !~ /crans$/) {
+        if (User-Name !~ /@(.*)crans(.*)$/) {
              if (User-Name =~ /^(.*)@(.*)/) {
                  update control {
@@ Ligne 104: / Ligne 119: @@
         }
 </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.
@@ Ligne 114: / Ligne 131: @@
 <code>
-# Baldrick (radius de federez)
+# Parangon (radius de federez)
-client 138.231.142.239 {
+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
         }
@@ Ligne 121: / Ligne 145: @@
  * 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>
@@ Ligne 130: / Ligne 158: @@
 <code>
-        if ("%{request:User-Name}" =~ /^(.*)@/) {
+        if ("%{request:User-Name}" =~ /^(.*)@(.*)crans(.*)/) {
             update request {
                 Stripped-User-Name := "%{1}"
@@ Ligne 148: / Ligne 176: @@
 Il est évidemment nécessaire de savoir si les serveurs freeradius du projet sont up ou down.
-C'est par ici : [[admin:services:wififederez:monitoring]]
+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''.
-Un script, status.sh situé dans le /root/federezwifi de baldrick 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.
+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.
-Ensuite, il construit un template à partir de ces données, qui est la page wiki telle qu'affichée à la section monitoring.
+Enfin, il poste les informations via un script over ssh sur le présent wiki situé sur dodecagon.
-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.
-Projet encore en développement, contacter detraz@crans.org.
 === Etat actuel ===
@@ Ligne 167: / Ligne 189: @@
 Ce qui marche bien :
  associations où FedeRez wifi est en production et fonctionnel :
-Cr@ns, Iresam et Rezogif
+Cr@ns, Supélec Rezo Rennes, AURORE, Rezo Metz, ViaRézo, Rézoléo, Resel.
-asso où tout est prêt :
-Fonctionne dans le sens FedeRez -> Rezos
-Rezometz : il suffit de diffuser le ssid et de remonter la vm federez des journées.
-VIA : idem
-=== Bugs ===
-=== En dev ===
-=== A l'étude ===
-===== Remerciements =====
-Ce projet n'aurait jamais vu le jour sans l'acharnement de beaucoup.
-Pour le Cr@ns : Daniel (je vais pas me remercier non plus...)
-Pour le rezo metz : cysi et Lazouz
-Pour Iresam : Martal et Stonfute
-Et tout ceux qui nous ont filé un coup de main à divers degrés
 --
-Chirac
+Pour toute question sur le projet, contacter detraz@crans.org.