2013-2014

Rapport de projet de fin dtudes

Encadr par : Dr. ROUHANA Nicolas

Ralis par : MROUEH Fatm

1|Page

REMERCIEMENTS :
Cest avec un grand plaisir que je rserve ces quelques lignes en signe de gratitude et de
reconnaissance tous ceux qui ont contribus la ralisation de ce travail.
Je suis reconnaissante Dieu Tout-Puissant qui a t avec moi et me maintient la
protection et la bndiction partout o je suis et quoique je fasse.
Je tiens galement remercier et exprimer ma gratitude mon encadrant Dr. ROUHANA
Nicolas qui, durant ce projet, na jamais cess de me fournir son aide utile, sans oublier ses
efforts mritoires quil a dploy pour suivre ce travail et laide permanente quil a su me
prodiguer tout le long de ce projet.
Je souhaite ensuite remercier mes parents qui ont t deux personnes cls depuis que jai
commenc mon projet et qui ne mont jamais oubli dans leurs prires.
Enfin, je tiens remercier lensemble du corps enseignant de lESIB et les membres du jury.

2|Page

ABRVIATIONS:
AAA: Authentication Authorisation Accounting
AES: Advanced Encryption Standard
AP: Access Point
DHCP: Dynamic Host Control Protocol
EAPOL: Extensible Authentication Protocol Over LAN
EDUROAM: Educational Roaming
ETLR: European Top-Level RADIUS server
FUNET: Finnish Universities Network
IdP: Identity Provider
IEEE: Institute of Electrical and Electronics Engineers
IP: Internet Protocol
LAN: Local Area Network
MS-CHAP v2: Microsofts Challenge Handshake Authentication Protocol version 2

NAS: Network Access Server

NPS: Network Policy Server
NREN: National Research and Education Network
NTLR: National Top-Level RADIUS server
PEAP: Protected Extensible Authentication Protocol

PMK: Pairwise Master Key

RADIUS: Remote Authentication Dial In User Service
SP: Service provider
3|Page

TERENA: Trans-European Research and Education Networking Association

TKIP: Temporal Key Integrity Protocol

TLS: Transport Layer Security
TTLS: Tunneled Transport Layer Security
VLAN: Virtual Local Area Network
WEP: Wired Equivalent Privacy
WPA: Wi-Fi Protected Access

4|Page

Table des matires:

REMERCIEMENTS
ABBRVIATIONS
RSUM
1-INTRODUCTION
2-CONTEXTE ET OBJECTIFS DU PROJET
2.1- Renseignements gnraux
2.2- Education Roaming (eduroam)
2.3- Eduroam confederation
3-DESCRIPTION DU PROJET
3.1- Notion eduroam
3.2- Network Access Server (NAS)
3.2.1- Wi-Fi Protected Access (WPA)
3.2.2- Wi-Fi Protected 2 (WPA2)
3.3- Protocole 802.1X
3.3.1- EAP-Tunnelled Transport Layer Security (EAP-TTLS)
3.3.2- PEAP-MSCHAP
3.4- Serveur Radius
3.4.1- Server Provider (SP)
3.4.1.1- Serveur proxy
3.4.1.2- Realm
3.4.2- Fournisseur didentit (Idp)
3.4.2.1- Protocole RADIUS
3.4.2.2- Authentification et Autorisation
3.4.2.3- Compatibilit
3.5-Base de donnes de lutilisateur
3.6-Laccs au rseau
4-CONCEPTION ET MISE EN UVRE
4.1-Planification du projet
4.2- Aperu de la conception
5-IMPLMENTATION
5.1- Choix du systme dexploitation des deux serveurs htes
5.2- Choix du serveur RADIUS
5.3- Installation du freeradius
5.4- Cration de la base de donnes des utilisateurs
5.5- Linstallation de linterface graphique webmin
5.6- Secret partag
5.7- Configuration des fichiers dans /etc/freeradius
5.7.1-proxy.conf
5.7.2-radiusd.conf
5.7.3-users

2
3
7
8
9
9
9
10
13
13
15
15
16
16
18
19
20
20
21
21
21
21
22
23
24
24
25
25
26
26
27
27
28
29
31
32
32
32
49
54
5|Page

5.7.4-clients.conf
5.7.5-eap.conf
5.7.6-sql.conf
5.7.7-sqlippool.conf
5.7.8-sites-enabled
5.7.8.1-default
5.7.8.2-inner-tunnel
5.7.9-sql/mysql
5.7.9.1-schema.sql
6-TEST, RSULTATS ET ANALYSE
6.1- Test du proxy
6.2- Test durseau l'aidedes informations d'identificationAdecampusA
6.3- Test avecles informations d'identificationd'untablissement B
deduroamactiv sur le campus A
7- LIMITATIONS
8- EXTENSION DU PROJET
9- CONCLUSION
10-LISTE DES FIGURES
11-RFRENCE

54
55
58
60
62
62
64
66
66
71
71
71
72
76
76
77
78
79

6|Page

RSUM :
Le but de ce projet est dtudier larchitecture de eduroam , proposer une solution pour
son dploiement au sein de l'Universit Saint-Joseph et de connecter ce rseau au rseau
eduroam mondial.
Le projet est divis en deux parties : le dploiement sur campus et la connexion au rseau
national.
Ce projet porte sur la mise en uvre, mise en place et la configuration des diffrents
systmes composants eduroam. La partie thorique vise fournir suffisamment une vue
complte sur le systme. Les termes de rseaux tels que le rseau sans fil, commutateur,
l'accs des points, serveur, etc sont discuts. Une grande partie de la thorie est
consacre l'explication de rseau sans fil eduroam.
Au cours de la mise en uvre, un serveur proxy sera dfini et configur. Plusieurs
commutateurs et points d'accs seront configurs. Lorsque la mise en uvre est termine,
les tests seront fabriqus partir de campus utilisant les informations d'identification
locales et externes. Aussi les utilisateurs aussi de diffrentes institutions seront en mesure
de se connecter sur les campus avec leurs pouvoirs domicile. En outre, je vais configurer
diffrents ordinateurs clients avec diffrents systmes d'exploitation pour tre capable de
se connecter eduroam. Enfin, je vais crire une configuration dtaille de suppliant qui
peut tre utilis par n'importe quel utilisateur peu familier avec l'informatique pour se
connecter au rseau.
Mots-cls: Eduroam, rseau sans fil, 802.1X, PEAP, MS-CHAP v2, RADIUS

7|Page

1. INTRODUCTION
Le but de ce projet est de dployer eduroam (education roaming) sans fil fdre rseau.
Eduroam est un service international visant offrir un accs sans fil scuris internet aux
membres des communauts de lEducation et de la Recherche depuis des tablissements
situs tout autour du monde, sans se soucier de leur localisation et de manire simple. Les
utilisateurs qui sont identifier dans le rseau l'tablissement d'accueil utilisent leur nom
et mot de passe de leur institution d'origine. En mettant en place ce systme sur le campus,
les tudiants et les administrateurs pourront identifier dans le rseau sans fil dans tout
tablissement eduroam activ n'importe o dans le monde. L'architecture du rseau
eduroam est base sur la mthode d'authentification 802.1X utilisant la mthode
d'authentification, d'autorisation et de comptabilit (AAA) pour RADIUS.
Le projet consistera dfinir et configurer un nouveau serveur proxy en fonctionnement
FreeRADIUS qui transfrera les demandes RADIUS soit au NPS Server (NPS) pour
l'authentification locale ou la prochaine hirarchique Serveur RADIUS pour les autres
utilisateurs. Il faudra galement la configuration de l'ensemble du rseau ressources
telles que les commutateurs, routeurs et points d'accs.

8|Page

2. CONTEXTE ET OBJECTIFS DU PROJET

2.1 Renseignements gnraux :
Avec la mondialisation, le monde est devenu un petit village. Pour de nombreuses raisons,
les gens voyageaient de ville en ville ou de pays pays. Aussi, des tudiants et des
personnels universitaires sont maintenant partie de ce mouvement de personnes. Le
premier groupe se dplace pour lducation et le second dans le but denseignement, de
recherche et/ou pour des raisons administratives.
Au cours de la dernire dcennie, lInternet a beaucoup grandi et devenu trs important
dans la vie de la plupart des gens. Pour les entreprises, tudes, divertissement etc., Internet
est utilis presque partout et presque par tout le monde. Internet est donc devenu une
partie importante dans notre vie. A consquence naturelle, les gens dans leur mobilit
doivent utiliser lInternet accomplir diffrentes matires. Ce fait est le mme pour les
tudiants et le personnel itinrant. Ils ont besoin daccs Internet pour leurs activits
quotidiennes. Dans presque tous les tablissements, le rseau et l'accs Internet doivent
avoir des autorisations. Lors de la visite universitaire locale ou trangre, les tudiants et
les personnels veulent accder aux ressources du rseau partir de leur ordinateur
portable. Les administrateurs de rseau rservent les comptes pour les invits ou les
visiteurs afin de leurs donner accs aux ressources du rseau (Internet). L'ide et le
concept sont bons, mais pas toujours simple. Qu'est-ce qui se passe par exemple si le
visiteur arrive le week-end et reste au campus ? Parfois, les gens qui veulent accder au
rseau ne sont pas en voyage officiel. Ils peuvent tre en vacances. Dans ce cas, il n'est pas
possible de postuler pour un client ou d'un compte visiteur. Ces faits sont des questions
que l'Internet daccs est confront quand les gens sont vagabondes.
Pourquoi les gens vagabondes ne peuvent pas utiliser les informations d'identification de
leurs universits pour avoir accs Internet? Par rponse cette question, TERENA (Trans
European Research and Education Networking Association) est venue avec lide
deduroam (education roaming).
2.2 Education Roaming (eduroam) :
L'initiative eduroam a commenc en 2003 au sein de l'quipe spciale de TERENA sur la
mobilit, TF-Mobilit. Le groupe de travail a cr un banc d'essai pour dmontrer la faisabilit
de la combinaison d'une infrastructure RADIUS avec la technologie standard 802.1X pour
fournir l'itinrance daccs au rseau travers les rseaux de recherche et d'enseignement. Le
premier test a t effectu entre cinq tablissements situs aux Pays-Bas, la Finlande, le
Portugal, la Croatie et la Royaume-Uni. Plus tard, d'autres organisations nationales de
9|Page

recherche et de rseautage de l'ducation dans l'Europe ont adapt l'ide et ont particip
progressivement l'infrastructure, qui tait alors nomm eduroam.

Le concept deduroam est bas sur le rseau sans fil. L'universit qui veut dployer
eduroam doit ajouter l'accs l'infrastructure sans fil dj en place. Les visiteurs avec leurs
ordinateurs portables configurs seront en mesure d'obtenir eduroam et avoir accs
Internet. Eduroam permet aux utilisateurs des universits connectes au rseau d'avoir
accs un rseau ressource dans d'autres universits eduroam activ l'aide de leurs
informations d'identification de leur universit domicile. L'ide de base est de donner
l'accs Internet pour les utilisateurs. Eduroam, qui, initialement, a commenc en Europe,
est devenu aujourd'hui un rseau mondial.
Eduroam est dploye en Europe, Amrique du Nord, Pacifique et maintenant Asie.
2.3 Eduroam confdration :
Comme indiqu prcdemment, eduroam est aujourd'hui un rseau mondial. Elle est
subdivise en rgions qui sont des groupes de confdrations (niveau de continent), qui
sont eux-mmes des groupes de fdrations (niveau national). Fdrations regroupent
toutes les institutions lies d'un pays. Dans chacun des pays, linstitution ou la socit
exploite les serveurs de haut niveau de la Fdration. Toutes les fdrations sur un
continent sont regroupes sous une confdration. Confdrations comme fdrations ont
des institutions ou des socits qui exploitent les serveurs de haut niveau de la
confdration. La fdration des serveurs de haut niveau prend soin de la communication
entre les serveurs de l'institution qui appartiennent un mme pays. Lorsque les
communications entre les deux institutions de diffrentes rgions sont en cours, les
confdrations de haut niveau les communiquent ensemble. Le schma ci-dessous est une
vue conceptuelle de eduroam rseau

Figure 1: Hirarchie des Serveurs dans le rseau eduroam.

10 | P a g e

Figure 2: Carte des pays eduroam connect Europennes.

La partie en rouge est notre pays Liban qui est devenu un membre deduroam.

En Europe, le projet eduroam est entran par GANT2, qui est cofinanc par NREN et la
Commission europenne (CE).
Le Nerlandais NREN (SURFnet) et le NREN Danois (UNI-C) fonctionnent les serveurs de
haut niveau. Dans l'Europe d'aujourd'hui, le rseau eduroam relie 36 pays, ce qui signifie
que centaines universits offrent des installations d'itinrance.
Voici la carte des pays connects l'Europe:

11 | P a g e

En Finlande CSC-IT, FUNET exploite le National Serveurs de niveau suprieur. Elle relie
environ 80 institutions en Finlande. Le rseau eduroam se dveloppe en Finlande.
Aujourd'hui environ 15 tablissements sont connects sur le rseau. La carte de
Ltablissement est toujours connecte jour pour montrer la dernire information. La
carte est montre dans la figure ci-dessous:

Figure 3: Carte dinstitutions connectes eduroam en Finlande (avril 2010).

12 | P a g e

3. DESCRIPTION DU PROJET :
3.1 Notion Eduroam:
Lorsqu'un utilisateur d'un tablissement eduroam est en itinrance et se trouve dans une
institution eduroam active, il est capable d'utiliser l'installation. L'utilisateur utilise les
informations d'identification de son institution pour obtenir l'accs aux ressources rseau
de ltablissement visit et en particulier l'accs Internet. L'ide pourrait sembler
irraliste, sachant que la visite de l'utilisateur n'est pas dans la base de donnes de lcole,
mais cela est possible avec eduroam. Sur la base de son infrastructure, le rseau eduroam
offre une authentification distance l'institution de la base de donnes de l'abonn
itinrant. Le concept est bas sur les serveurs RADIUS. L'architecture hirarchique de
serveurs RADIUS dans rseau eduroam offre cette facilit.
Le client ou le visiteur entre dans les informations didentification : nom d'utilisateur (sous
la forme de username@institution.x ) et mot de passe de son institution pour se connecter
la demande est transmettre au serveur RADIUS de campus qui transmet la demande au
niveau national haut RADIUS (serveurs NTLR). Si l'utilisateur visiteur vient du mme pays,
la NTLR transmet la demande l'appropri serveurs RADIUS institution. Le serveur
RADIUS l'institution de l'utilisateur itinrant authentifie le nom d'utilisateur et le mot de
passe fournis dans la demande. Si l'utilisateur se trouve dans la base de donnes,
l'utilisateur est authentifi et peux accorder l'accs. Une rponse est renvoye au rseau
visit de l'tablissement dans un tunnel qui a t cr lorsque l'utilisateur demande
l'authentification. Le rseau de l'tablissement visit sur la base de la politique locale
donne l'accs utilisateur des ressources ddies.
Le processus est assez similaire lorsque l'utilisateur visiteur est d'un autre pays ou d'une
autre rgion (par exemple, entre l'Europe et l'Amrique). Dans le premier cas, le serveur de
NTLR visit va chercher dans sa base de donnes royaumes connus. Si celui-ci nest pas
dans la base de donnes, il transmet la demande aux serveurs RADIUS rgion. En Europe, le
serveur de rgion est appel l'Europe Top Level RADIUS (ETLR). Lorsque la rgion Serveur
RADIUS reoit la requte, elle la transmette sur la base de la sphre et l'autre NTLR adresse
dans la base de donnes transmet la demande au serveur maison NTLR qui transmet aux
serveurs de l'institution d'accueil.

13 | P a g e

Figure 4: Schmatisation des communications Radius.

Explication du schma ci-dessus :

Supposons quun membre nomm Dupont de luniversit x, membre deduroam, se dplace
luniversit y, galement membre deduroam, celui-ci dsire se connecter depuis y
Internet et aux services proposs par luniversit y. Il se place prs dune borne Wi-Fi avec
son ordinateur portable et se connecte grce son login et mot de passe habituels. Voici,
dans les grandes lignes le droulement de la connexion.
Lutilisateur tente de se connecter avec un login du type Dupont@univ-x.fr, le serveur RADIUS
de luniversit y ne reconnat pas le realm qui est le nom du domaine univ-x.fr, et renvoie donc
la requte de connexion au serveur RADIUS national qui lui ne reconnat pas le domaine.fr, il
transmet donc son tour la requte au serveur europen, qui lui reconnat le domaine.fr et
transmet la requte au serveur national franais qui connat son tour le domaine univ-x :
luniversit de x reoit la requte, consulte sa base de donnes et authentifie lutilisateur
Dupont avec son mot de passe : la demande est accepte et la rponse du serveur RADIUS
de x effectue donc le chemin inverse.

Le Procd d'authentification et de la scurit est bas sur cinq lments principaux:

Network Access Server ( NAS )

Protocole 802.1X
Server Radius
Base de donnes de l'utilisateur
L'accs au rseau
14 | P a g e


3.2 Network Access Server (NAS) :
Network Access Server (NAS) est une passerelle d'accs qui empche les utilisateurs
d'avoir accs certaines ressources rseau. NAS peut tre un commutateur ou un point
d'accs (AP). Ces dispositifs sont utiliss dans un rseau pour contrler l'accs.
Quand un utilisateur, aussi connu comme suppliant, se connecte un NAS, le NAS se
connecte de nouveau un serveur d'authentification ddi pour vrifier si les informations
d'identification fournies par l'utilisateur sont correctes. Sur la base de la rponse du
serveur, le serveur NAS autorise ou non l'utilisateur d'avoir l'accs des ressources
protges.
Un NAS ne contient pas d'informations sur les ressources auxquelles l'utilisateur peut avoir
accs. Il ne transmet que les informations d'identification du serveur d'authentification et
permet d'accder au rseau. Il est vident que les donnes passantes par le NAS doivent
tre fixes. Lorsqu'un point daccs est utilis comme NAS, les canaux doivent tre fixs. De
nombreux types de fil de diffrentes scurits existent. Ils ont tous leurs avantages et
inconvnients. Nous allons nous concentrer uniquement sur les types frquents de la
scurit utiliss dans eduroam :

Wi- Fi Protected Access (WPA)

Wi- Fi Protected Access (WPA2)

3.2.1 Wi-Fi Protected Access (WPA):

WPA est une norme de scurit adopte pour amliorer la prcdente norme utilise Wired
Equivalent Privacy (WEP). WPA utilise Temporal Key Integrity Protocole (TKIP) qui est un
protocole de scurit utilis dans les rseaux sans fil IEEE 802.11 standard. Dans TKIP, les
touches changent dynamiquement afin de protger la communication. En WPA, lappareil
sans fil utilise le mode cl pr-partage pour chiffrer les donnes avec soit 64 chiffres
hexadcimaux, soit comme un mot de passe de 6 63 caractres ASCII imprimables. Pour
que l'utilisateur ait l'accs aux ressources rseau protges, il doit saisir le mot de passe
correct dj fix dans le dispositif sans fil.
Le protocole WPA existe en deux versions : le mode personnel et le mode de l'entreprise. Le
mode personnel qui utilise la cl pr-partage a t trouv moins scuris car il peut tre
pirat.
Le mode de l'entreprise ncessite une authentification RADIUS en prenant le nom
d'utilisateur et le mot de passe. Ce second mode est celui utilis dans eduroam depuis
l'authentification est effectue contre RADIUS. Un an aprs, WPA a t libr. Wi-Fi Alliance
est venu avec un protocole WAP2 plus fort et robuste.
15 | P a g e

3.2.2 Wi- Fi Protected 2 (WPA2) :

WPA2 est un type amlior de WPA. En plus de TKIP, WPA2 a beaucoup plus avanc la
mthode de cryptage appel Advanced Encryption Standard (AES). WPA2 a t dvelopp
pour rsoudre l'intrusion de scurit WPA. Thoriquement, WPA2 n'est pas pirat. Tout
comme WPA, WPA2 a t publi en deux versions : personnels et d'entreprise. Les deux
versions de travail WPA. En plus des avantages de cryptage, WPA2 ajoute galement deux
amliorations pour soutenir rapidement l'itinrance des clients sans fil se dplaant entre
les points d'accs sans fil :

Pairwise Master Key (PMK) le support de la mise en cache : permet de reconnecter

l'accs le point ce que le client a rcemment reli sans utiliser pour r-authentifier.

Support pr-authentification : permet un client d'effectuer une prauthentification avec un point daccs vers lequel il se dplace tout en conservant
une connexion avec le point d'accs en sloignant.

Prenant en considration toutes les caractristiques, WPA2 est une bonne option pour le
point d'accs de paramtre de scurit dans eduroam.
Dans eduroam, les NAS qui sont dployes sont des points d'accs. Lorsqu'un utilisateur se
connecte au NAS, le NAS transmet les informations d'identification de l'utilisateur au
serveur RADIUS. En fonction de la rponse, l'utilisateur est autoris ou pas d'avoir accs
Internet. Entre les utilisateurs (suppliants), le NAS (authentificateur) et le serveur
d'authentification, 802.1X est le protocole utilis pour transporter les informations
d'identification.

3.3 802.1X protocole:

Le 802.1X est un Institute of Electrical and Electronics Engineers (IEEE) pour locale et
rseau mtropolitain. Il s'agit d'un protocole de contrle d'accs rseau d'un port sur la
base. Initialement conu pour le port Ethernet, il a t tendu pour tre utilis au rseau
sans fil.Le contrle d'accs de rseau utilise les caractristiques dinfrastructure de la
norme IEEE 802 LAN d'accs physique, afin de fournir un moyen d'authentification et
l'autorisation des dispositifs connects un port LAN qui a des caractristiques de
connexion point--point et de la prvention daccs ce port dans les cas o
l'authentification et l'autorisation choue. Un port dans ce contexte est un point de fixation
l'infrastructure LAN unique.
802.1X dfinit l'encapsulation du protocole EAP (Extensible Authentication Protocol) sur
16 | P a g e

IEEE qui est connu comme EAP over LAN (EAPOL). EAP est un cadre d'authentification
utilis dans la communication rseau sans fil ou le point--point. De nombreuses mthodes
existent, mais PAE WPA et WPA2 ont adopt cinq types mcanismes d'authentification
comme officielles.
La figure ci-dessous montre les tapes de l'authentification 802.1X

Figure 5: Etapes d'authentification 802.1X

Quand un authentificateur dtecte un nouveau suppliant, l'authentificateur demande ses

informations personnelles. ce moment-l, aucun autre trafic nest autoris : trafic tel que
DHCP ou HTTP est tomb. Seul le trafic 802.1X est autoris. Le "port" est ferm. Jusqu' une
couche de transport crypte Scurit (TLS) tunnel est en place, la vritable identit de
l'utilisateur n'est pas envoye. Identit cache est utilise. Aprs que l'identit a t
envoye, le processus d'authentification commence. Le protocole utilis entre le suppliant
et l'authentificateur est l'encapsulation EAP sur rseau local(EAPOL). L'authentificateur r
-encapsule le message EAP puis la transmet au serveur d'authentification. Au cours du
processus d'authentification, lauthentificateur relaie seulement les paquets entre le
logiciel client et le serveur d'authentification. Lorsque l'authentification est termine, le
serveur renvoie un accs en succs (si l'authentification tait succs) ou accs rejet
(quand il choue) pour le suppliant. Si l'authentification est russie, le port est alors ouvert.
Aprs une authentification russie, le suppliant est accs autoris aux ressources de rseau
17 | P a g e

protges.

Figure 6: Fonctionnement interrupteur de 802.1X.

En eduroam, deux types de mthode d'authentification sont proposes:

EAP Tunnel Transport Layer Security(EAP-TTLS)

Protected EAP Microsofts Challenge Handshake Authentication Protocol(PEAPMSCHAP)

3.3.1 EAP- Tunnelled Transport Layer Security (EAP-TTLS):

EAP-TTLS est un protocole EAP qui s'tend de la scurit EAP-Transport Layer (EAP-TLS)
protocole. Il a t dvelopp par Funk Software et Certicom. Il est largement soutenu sur les platesformes bien qu'il n'y ait pas de support natif pour ce protocole dans Microsoft Windows. Le support
sur MS Windows se fait travers un logiciel comme SecureW2. Dans EAP-TTLS, le client peut ou pas
s'authentifier. Cela signifie un certificat client n'est pas dlivr lors de l'installation. Seule
l'authentification du serveur au client est importante. Le serveur certificat est donc install pour
tre en mesure de transmettre la requte d'authentification partir du serveur. La connexion
scurise tablie par l'tablissement de liaison est ensuite utilise par le serveur pour authentifier
le client en utilisant les mcanismes d'authentification tels quEAP ou autres.
18 | P a g e

Figure 7: Mthode d'authentification EAP-TTLS.

Un avantage de ce type de procd d'authentification est le tunnel scuris tabli lors de

l'authentification. Il prvient les coutes. Un autre avantage est que le nom du client est
galement envoy sous forme crypte pas en texte clair. Eduroam est un systme
d'authentification distance. Avoir une mthode d'authentification scurise est trs
importante. EAP-TTLS est adapt pour le rseau eduroam.

3.3.2 PEAP- MSCHAP :

Le protocole d'authentification extensible protg (PEAP) est un protocole qui encapsule la

communication EAP dans un tunnel TLS chiffr. Conjointement dvelopp par des systmes
Cisco, Microsoft et RSA Security, il a t libr la protection de plus la communication
EAP. Mme si EAP est utilis dans l'authentification, la totalit de la conversation EAP peut
tre envoy en texte clair (non chiffr). Cette situation n'est pas scurise car un utilisateur
malveillant peut capturer les messages EAP partir d'une authentification russie pour
l'analyse. Pour rsoudre ce problme de scurit, PEAP cre d'abord un canal scuris qui
est la fois crypt et protg en termes d'intgrit de donnes avec Transport Layer
19 | P a g e

Security (TLS). Cela empche la conversation EAP paquets d'tre pirat. Avec le tunnel
PEAP, diffrents types de mthodes EAP sont utilises: l'une de ces mthodes est le
Challenge Handshake Authentication Protocol de Microsoft (MS-CHAP).
MS-CHAP est la version Microsoft du Challenge Handshake Authentication Protocol. Il en
existe deux versions : MS- CHAPv1 dfini dans RCF 2433 et MS- CHAPv2 dfini dans RCF
2759. Comme un produit Microsoft, il a t inclus dans le systme d'exploitation natif
depuis Windows 2000 SP4. MS- CHAP v2 est un dfi-rponse en fonction de mot de passe,
mutuel protocole d'authentification qui utilise le standard de l'industrie Message Digest 4
(MD4) et des donnes Encryption Standard (DES) algorithmes pour crypter les rponses.
MS-CHAP seul utilis, a des failles de scurit. Une capture de succs MS-CHAPv2change
par un pirate peut tre utilise pour deviner les mots de passe mthodiquement. Lorsque
MS CHAPv2 est utilis avec PEAP, l'change de MS-CHAP v2 est protg par le canal TLS
forte scurit. Dans le rseau eduroam, l'une des parties importantes est l'authentification.
L'quipement que prend soin de cela est la Remote Authentication Dial In User Service
(RADIUS).

3.4 Serveur RADIUS:

Quand un utilisateur visiteur se connecte eduroam, il envoie ses informations
d'identification afin d'tre authentifi. En fonction du type de serveur RADIUS, les
donnes envoyes seront soit utilises pour authentification ou vers l'avant un autre
serveur RADIUS. Quels types de serveurs RADIUS avons-nous dans le rseau eduroam?

Figure 8: Architecture du serveur Radius.

3.4.1 Server Provider (SP) :

Un serveur du fournisseur de service est un serveur RADIUS qui ne fait pas

20 | P a g e

l'authentification. Le serveur est utilis pour les demandes proxy RADIUS au serveur
RADIUS hirarchique dans le rseau. Ce type de serveur est un serveur proxy.
3.4.1.1 Serveur proxy :

Un serveur proxy RADIUS a un dossier de tous les serveurs RADIUS hirarchiques dans le
rseau. Quand un serveur proxy reoit une requte RADIUS, le serveur dballe la demande
encapsule. Si le domaine est connu dans le serveur r-encapsule la requte et la transmet
au serveur appropri. Dans le cas contraire, la demande est transmise l'autre serveur
RADIUS dans le rseau hirarchique.
3.4.1.2 Realm :

Le realm est utilis pour transmettre les requtes un autre serveur RADIUS (cest un
champ qui permet de savoir vers quel serveur RADIUS la requte doit tre transmise). Dans
le cadre d'eduroam, le realm d'un serveur RADIUS d'un tablissement correspond son
nom de domaine. Dans le rseau eduroam, le nom de lutilisateur doit tre au format
"nom@domaine". Ce n'est pas un courrier lectronique adresse. Le domaine est trs
important dans le rseau eduroam. Sans ce domaine, la demande ne peut pas tre
transmise l'authentification institutionnelle approprie Fournisseur d'identit (IdP).
3.4.2 Fournisseur d'identit (IdP) :

Le fournisseur d'identit est le serveur qui se charge de l'authentification. Contrairement au

service fournisseur, le fournisseur d'identit met fin la demande de radius reu par
l'application du protocole radius d'authentification. Qu'est-ce que RADIUS ?
3.4.2.1 Protocole RADIUS :

Radius est un protocole rseau qui fournit l'authentification, lautorisation et la

comptabilit plate-forme (AAA) pour permettre un client d'accder des ressources
rseau protges. Initialement dvelopp par Livingstone Enterprises Inc., il est devenu
plus tard l'Internet Engineering Task Force (IETF).
RADIUS est un service de client / serveur utilisant (UDP) User Datagram Protocol transport
et fonctionnant sur la couche d'application. Il a trois fonctions principales :

Authentifier les utilisateurs avant de leur accorder l'accs un rseau

Autoriser les utilisateurs authentifis d'avoir accs une ressource particulire
Compte pour les services antrieurs

La figure ci-dessous montre la structure d'un paquet RADIUS :

21 | P a g e

Figure 9: Format de paquet RADIUS.

Lgende:

Code - Un octet contenant le RADIUS commande / rponse.

Identifier - Un octet utilis pour correspondre la commande et la rponse.
Longueur - La longueur du paquet (2 octets).

Authenticator - Valeur utilise pour authentifier la rponse du serveur RADIUS, et

est utilise dans l'algorithme de dissimulation de mot de passe.
Attributs - Les donnes appartenant la commande ou une rponse.

3.4.2.2 Authentification et Autorisation :

Dans une conversation RADIUS, l'authentification et l'autorisation arrivent ensemble, mais

une aprs l'autre. Lorsqu'un client se connecte un serveur NAS, il envoie ses informations
d'identification pour accder au rseau. Le NAS envoie alors une demande d'accs au
serveur RADIUS demandant l'autorisation d'accorder l'accs au rseau. Le RADIUS vrifie
le reu des informations d'identification avec la base de donnes d'utilisateurs installs
localement ou distance (sur un autre serveur). Une fois le serveur RADIUS a vrifi les
informations d'identification, il rpond au client dans un de ces formats :

Accs Accept: lorsque l'utilisateur est authentifi

Accs Rejet : lorsque l'utilisateur n'a pas pu tre authentifi

Dfi d'accs: lorsque l'utilisateur doit fournir des informations supplmentaires.

Dans le cas de la mthode d'authentification en tunnel o l'identit est cache par
22 | P a g e

rapport au NAS, un dfi d'accs est envoy l'utilisateur.

3.4.2.3 Comptabilit

Le processus comptable est une fonction supplmentaire qui excute le serveur RADIUS.
Quand l'authentification et l'autorisation sont effectues, l'utilisateur est en mesure
d'obtenir l'accs aux ressources rseau. La comptabilit est une piste de la consommation
des ressources NAS par l'utilisateur. Cette information peut tre utilise plus tard par
l'administrateur pour vrifier la faon dont les ressources du rseau ont utilis pour
planifier ou restructurer le rseau. Certaines des informations recueillies dans la
comptabilit sont : l'identit de l'utilisateur, la nature du service rendu, le temps
dterminant quand le service a commenc et s'est termine. Quand un accs au rseau est
accord par le NAS, un dbut de comptabilit (comptabilit RADIUS paquet de demande)
est envoy par le NAS sur le serveur RADIUS pour indiquer que le service a dmarr. Lors
de la connexion, priodiquement, le NAS envoie un dossier de mises jour intermdiaires
(Paquet RADIUS) au serveur pour mettre jour l'tat de la session active. Enfin lorsque la
session se termine, le NAS envoie un enregistrement comptable arrt (paquet RADIUS) au
serveur. Ce paquet fournit des informations sur l'accs au rseau de l'utilisateur.

La figure ci-dessous montre le flux de l'authentification, autorisation et de comptabilit

dans RADIUS

23 | P a g e

Figure 10: Flux de messages RADIUS.

3.5 Base de donnes de l'utilisateur :

L'utilisateur authentifi doit d'abord tre enregistr quelque part. Les informations
enregistres sur l'utilisateur (nom d'utilisateur, mot de passe, numro de tlphone etc.)
cest ce qui est utilis au cours de la squence d'authentification. J'appelle cette information
enregistre la base de donnes de l'utilisateur.
Lorsque le serveur RADIUS reoit les informations d'identification utilisateur itinrance
(souvent le nom d'utilisateur et mot de passe), il vrifie par rapport des donnes dont il
dispose dans la base de donnes utilisateur. Si l'utilisateur existe, il vrifie le mot de passe.
Lorsque tout est correct, le serveur envoie une rponse en retour de notifier que lutilisateur
existe et le mot de passe fourni est correct. De nombreuses bases de donnes utilisateur sont
aujourd'hui utilises dans le processus d'authentification. Certaines d'entre eux sont actives :
LDAP, SQL, Kerberos, etc. Ces bases de donnes de l'utilisateur peuvent tre installes
localement sur le mme serveur RADIUS ou distance sur un autre serveur.

3.6 L'accs au rseau :

Les ressources du rseau que l'utilisateur peut avoir accs aprs avoir t authentifi
varient. Chaque institution dfinit des rgles ou des politiques sur le rseau.
24 | P a g e

Habituellement, ces rgles sont dfinies dans Virtual Local Area Network (rseau local
virtuel). Un VLAN est logique de segmentation d'un rseau local (LAN). En segmentant un
rseau local, l'administrateur peut regrouper diffrents jeunes de moins de mmes rgles :
leur donner une certaine permission ou leur refuser certains accs. Il est facile et simple
pour un administrateur de concevoir VLAN dans un rseau local.
En eduroam l'ide fondamentale est d'accorder l'accs Internet l'utilisateur visiteur.
Dans le mme temps, les utilisateurs qui ne sont pas rdent et qui appartiennent
l'institution d'accueil ont un accs diffrent au rseau. Il est conseill l'administrateur de
dfinir une politique locale contenant les rgles dun particulier VLAN. Certaines des
rgles qui sont dfinis dans le rseau local virtuel sont:

Les adresses IP qui seront assignes l'hte

La route statique ou dynamique, etc.

Maintenant, le concept deduroam a t clarifi, passons sa conception et mise en uvre.

4. CONCEPTION ET MISE EN UVRE

4.1 Planification du projet:
Une fois la thorie de l'architecture et de la scurit du rseau eduroam a t dtaille, il est
maintenant important de se pencher sur la porte de la faon de configurer le systme pour
rpondre aux exigences autant que possible.

La conception suivante a t convenue:

25 | P a g e

Figure 11: Architecture Wi-Fi eduroam.

4.2 Aperu de la conception :

Le Wi-Fi du campus dispose dj d'un ensemble de serveurs d'authentification qui sont
utiliss pour authentifier les utilisateurs dans le rseau sans fil. J'ai donc dcid de dfinir
un nouveau service fournisseur (SP) qui agit comme un proxy. Ce SP transmettra ensuite
nos clients les demandes d'authentification et reoit galement les demandes
d'authentification.

5. Implmentation :
La mise en uvre du systme est divise en plusieurs parties:

26 | P a g e

Le choix du systme dexploitation des deux serveurs htes

Le choix du serveur RADIUS
Linstallation du freeradius
La cration de la base de donnes des utilisateurs
Linstallation de linterface graphique webmin
Secret partag
Configuration des composants de freeradius

5.1 Choix du systme d'exploitation des deux serveurs htes :

Un serveur virtuel n'est pas constip et facile mettre en place. Il existe dj de nombreux
serveurs virtuels. Dans ce cas, le serveur virtuel Linux a t utilis sous Ubuntu du systme
d'exploitation avec la version 14.04.
5.2 Choix du serveur RADIUS :
Diffrents types de serveur RADIUS existent. Les plus utiliss sont Radiateur, Windows
NPS, Diamtre et FreeRADIUS etc. Pour ce projet Freeradius a t slectionn parce que
d'abord il est logiciel open source, deuxime il est simple dans la configuration et soutient
finalement tous les type de procd d'authentification.
Ce premier tableau est un comparatif des
diffrentes mthodes dauthentification
supportes par le service RADIUS :
Mthodes

Freeradius CistronRADIUS

ICRadius

XTRadius

OpenRADIUS

GNURadius

YARDRadius

EAP/TLS
EAP/TTLS
EAP/MD5
CHAP
PAP
PEAP
CISCO-LEAP
Couple
Login/pass

Oui
Oui
Oui
Oui
Oui
Oui
Oui
Oui

Non
Non
Non
Non
Non
Non

Non
Non
Non
Non
Non
Non

Non
Non
Non
Non
Non
Non

Non
Non
Non
Oui
Oui
Non

Non
Non
Non
Non
Non
Non

Oui

Oui

Oui

Oui

Oui

Non
Non
Non
Non
Non
Non
Non
Oui

Figure 12: Mthodes dauthentification supportes par Radius

27 | P a g e

Le second critre de comparaison se fait sur les types dauthentifications

supports pour authentifier les utilisateurs.
Support
dauthentification

Freeradius CistronRADIUS

ICRadius

XTRadius

OpenRADIUS

GNURadius

YARDRadius

PAM
Unix
MySQL
PostgresSQL
Oracle
LDAP

Oui
Oui
Oui
Oui
Oui
Oui

Oui
Oui
Oui
Non
Non
Non

Non
Oui
Non
Non
Non
Non

Oui
Oui
Oui
Oui
Non
Oui

Oui
Oui
Oui
Oui
Non
Non

Oui
Oui
Non
Non
Non
Non

Oui
Oui
Non
Non
Non
Non

Figure 13: Typesdauthentifications supports

5.3 Linstallation du freeradius :

Pour linstallation du freeradius sur le serveur, on tape les commandes
suivantes sur ubuntu :
Sudo apt-get install freeradius
Sudo apt-get install freeradius-common
Sudo apt-get install freeradius-mysql
Sudo apt-get install freeradius-utils
Sudo apt-get install freeradius-dbg
Sudo apt-get install freeradius-postgresql
Sudo apt-get f install

--pour complter linstallation

Le paquet install contient plusieurs fichiers :

28 | P a g e

Figure 14: Fichiers dans le paquet freeradius

5.4 La cration de la base de donnes des utilisateurs :

Une base de donnes (son abrviation est BD, en anglais DB, database) est une entit dans
laquelle il est possible de stocker des donnes de faon structure et avec le moins
de redondance possible. Ces donnes doivent pouvoir tre utilises par des programmes,
par des utilisateurs diffrents.
Ainsi, la notion de base de donnes est gnralement couple celle de rseau, afin de
pouvoir mettre en commun ces informations, d'o le nom de base. On parle gnralement
de systme d'information pour dsigner toute la structure regroupant les moyens mis en
place pour pouvoir partager des donnes.

Figure 15: Schma de la base de donnes des clients

29 | P a g e

Dans le cas deduroam, il faut quon cre une base de donnes pour les tudiants afin quils
puissent sauthentifier.
Jai install phpmyadmin pour copier le fichier de la base de donnes qui existe dans
freeradius (schema.sql) et par suite les utilisateurs seront stocks dans une base de
donnes appel radius :

Figure 16: La base de donnes Radius cr sur phpmyadmin

# apt-get install mysql-server-5.5

# apt-get install apache2
# apt-get install phpmyadmin
# apt-get install freeradius
# mysql u root p radius < /etc/freeradius/sql/mysql/schema.sql
30 | P a g e

Cette dernire commande nous permet de copier le fichier schema.sql dans la base de
donnes radius cr dans phpmyadmin.
5.5 Installation de linterface graphique Webmin :
Webmin est une interface web, sous licence BSD, qui permet d'administrer simplement un
serveur UNIX ou Linux distance via n'importe quel navigateur web.
Il est conseill de l'installer avec un paquet spcifique sa distribution (UNIX ou Linux).
Ainsi, le paquet va installer Webmin en prenant en considration ses spcificits,
notamment les chemins des fichiers de configuration. la premire connexion, le
programme demande un mot de passe (le root pour un contrle total du serveur). Il est
possible de crer d'autres utilisateurs Webmin en indiquant les parties que l'utilisateur
pourra administrer depuis l'interface.
Webmin est un service qui se lance au dmarrage du serveur et qui est accessible via un URI.
L'utilisateur peut se connecter l'interface en indiquant dans l'URL (URL, adresse IP, etc.) du
serveur le port de l'application (par dfaut 10000). Ce port peut tre redfini directement depuis
l'interface, tout comme beaucoup d'autres paramtres.
Par exemple : https://www.mondomaine.com:10000

# apt-get install webmin

# apt-get f install

Figure 17: Linterface graphique webmin

31 | P a g e

5.6 Secret partag :

Avant quil puisse y avoir une RADIUS conversation entre deux appareils (NAS-SP ou SP-IdP), un secret partag doit exister.
Un secret partag est une cl commune (de prfrence de 16 chiffres) utilis par les deux
extrmits dans la conversation pour crypter le paquet. S'il y en a une erreur dans le secret,
personne des fin dispositifs ne peuvent lire et dcoder le chiffrement du contenu du
paquet.
Dans un systme le secret est utilis entre les deux quipements. Ce secret peut tre
reproduit (utilis entre d'autres dispositifs dans le systme), ou d'autres secrets peuvent
tre utiliss dans le systme.
Il peut ressembler ceci :

Figure 18: Le secret partag pour le chiffrement du paquet

5.7 Configuration de fichiers dans /etc/freeradius :

5.7.1 proxy.conf:

Le fichier de configuration de proxy.conf est le fichier qui contient toutes les informations
sur la faon dont le fournisseur de services transmet les demandes RADIUS. Dans le
proxy.conf un pool de serveurs domicile sont dfinis. Les serveurs domicile sont le
serveur RADIUS utilis pour l'authentification (identit fournisseur). Il dfinit galement si
le serveur domestique gre l'authentification et la comptabilit ensemble ou sparment.
Aujourd'hui, les ports standard sont 1812 pour l'identification et 1813 pour les comptes.
Tous ces paramtres sont dfinis dans le proxy.conf

proxy.conf :
# -*- text -*##
## proxy.conf -- proxy radius and realm configuration directives
##
##
$Id$
32 | P a g e

##############################################################
#########
#
# Proxy server configuration
#
# This entry controls the servers behaviour towards ALL other servers
# to which it sends proxy requests.
#
proxy server {
#
# Note that as of 2.0, the "synchronous", "retry_delay",
# "retry_count", and "dead_time" have all been deprecated.
# For backwards compatibility, they are are still accepted
# by the server, but they ONLY apply to the old-style realm
# configuration. i.e. realms with "authhost" and/or "accthost"
# entries.
#
# i.e. "retry_delay" and "retry_count" have been replaced
# with per-home-server configuration. See the "home_server"
# example below for details.
#
# i.e. "dead_time" has been replaced with a per-home-server
# "revive_interval". We strongly recommend that this not
# be used, however. The new method is much better.
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#

In 2.0, the server is always "synchronous", and setting

"synchronous = no" is impossible. This simplifies the
server and increases the stability of the network.
However, it means that the server (i.e. proxy) NEVER
originates packets. It proxies packets ONLY when it receives
a packet or a re-transmission from the NAS. If the NAS never
re-transmits, the proxy never re-transmits, either. This can
affect fail-over, where a packet does *not* fail over to a
second home server.. because the NAS never retransmits the
packet.
If you need to set "synchronous = no", please send a
message to the list <freeradius-users@lists.freeradius.org>
explaining why this feature is vital for your network.

#
# If a realm exists, but there are no live home servers for
# it, we can fall back to using the "DEFAULT" realm. This is
# most useful for accounting, where the server can proxy
33 | P a g e

#
#
#
#
#

accounting requests to home servers, but if they're down,

use a DEFAULT realm that is LOCAL (i.e. accthost = LOCAL),
and then store the packets in the "detail" file. That data
can be later proxied to the home servers by radrelay, when
those home servers come back up again.

# Setting this to "yes" may have issues for authentication.

# i.e. If you are proxying for two different ISP's, and then
# act as a general dial-up for Gric. If one of the first two
# ISP's has their RADIUS server go down, you do NOT want to
# proxy those requests to GRIC. Instead, you probably want
# to just drop the requests on the floor. In that case, set
# this value to 'no'.
#
# allowed values: {yes, no}
#
default_fallback = no
}
##############################################################
#########
#
# Configuration for the proxy realms.
#
# As of 2.0. the old-style "realms" file is deprecated, and is not
# used by FreeRADIUS.
#
# As of 2.0, the "realm" configuration has changed. Instead of
# specifying "authhost" and "accthost" in a realm section, the home
# servers are specified seperately in a "home_server" section. For
# backwards compatibility, you can still use the "authhost" and
# "accthost" directives. If you only have one home server for a
# realm, it is easier to use the old-style configuration.
#
# However, if you have multiple servers for a realm, we STRONGLY
# suggest moving to the new-style configuration.
#
#
# Load-balancing and failover between home servers is handled via
# a "home_server_pool" section.
#
# Finally, The "realm" section defines the realm, some options, and
# indicates which server pool should be used for the realm.
#
# This change means that simple configurations now require multiple
34 | P a g e

#
#
#
#
#
#
#
#
#

sections to define a realm. However, complex configurations

are much simpler than before, as multiple realms can share the same
server pool.
That is, realms point to server pools, and server pools point to
home servers. Multiple realms can point to one server pool. One
server pool can point to multiple home servers. Each home server
can appear in one or more pools.

##############################################################
########
#
# This section defines a "Home Server" which is another RADIUS
# server that gets sent proxied requests. In earlier versions
# of FreeRADIUS, home servers were defined in "realm" sections,
# which was awkward. In 2.0, they have been made independent
# from realms, which is better for a number of reasons.
#
home_server localhost {
#
# Home servers can be sent Access-Request packets
# or Accounting-Request packets.
#
# Allowed values are:
#
auth
- Handles Access-Request packets
#
acct
- Handles Accounting-Request packets
#
auth+acct - Handles Access-Request packets at "port",
#
and Accounting-Request packets at "port + 1"
#
coa
- Handles CoA-Request and Disconnect-Request packets.
#
See also raddb/sites-available/originate-coa
type = auth
#
# Configure ONE OF the following entries:
#
#
IPv4 address
#
ipaddr = 127.0.0.1
#
OR IPv6 address
# ipv6addr = ::1
#
OR virtual server
# virtual_server = foo
35 | P a g e

#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#

Note that while both ipaddr and ipv6addr will accept

both addresses and host names, we do NOT recommend
using host names. When you specify a host name, the
server has to do a DNS lookup to find the IP address
of the home server. If the DNS server is slow or
unresponsive, it means that FreeRADIUS will NOT be
able to determine the address, and will therefore NOT
start.
Also, the mapping of host name to address is done ONCE
when the server starts. If DNS is later updated to
change the address, FreeRADIUS will NOT discover that
until after a re-start, or a HUP.
If you specify a virtual_server here, then requests
will be proxied internally to that virtual server.
These requests CANNOT be proxied again, however. The
intent is to have the local server handle packets
when all home servers are dead.
Requests proxied to a virtual server will be passed
through the pre-proxy and post-proxy sections, just
like any other request. See also the sample "realm"
configuration, below.
None of the rest of the home_server configuration is used
for the "virtual_server" configuration.

#
# The port to which packets are sent.
#
# Usually 1812 for type "auth", and 1813 for type "acct".
# Older servers may use 1645 and 1646.
# Use 3799 for type "coa"
#
port = 1812
#
#
#
#
#
#
#
#
#

The shared secret use to "encrypt" and "sign" packets between

FreeRADIUS and the home server.
The secret can be any string, up to 8k characters in length.
Control codes can be entered vi octal encoding,
e.g. "\101\102" == "AB"
Quotation marks can be entered by escaping them,
36 | P a g e

#
e.g. "foo\"bar"
# Spaces or other "special" characters can be entered
# by putting quotes around the string.
#
e.g. "foo bar"
#
"foo;bar"
#
secret = testing123
##

##########################################################
#
# The rest of the configuration items listed here are optional,
# and do not have to appear in every home server definition.
#
##########################################################

##

#
# You can optionally specify the source IP address used when
# proxying requests to this home server. When the src_ipaddr
# it set, the server will automatically create a proxy
# listener for that IP address.
#
# If you specify this field for one home server, you will
# likely need to specify it for ALL home servers.
#
# If you don't care about the source IP address, leave this
# entry commented.
#
src_ipaddr = 127.0.0.1
# RFC 5080 suggests that all clients SHOULD include it in an
# Access-Request. The configuration item below tells the
# proxying server (i.e. this one) whether or not the home
# server requires a Message-Authenticator attribute. If it
# is required (value set to "yes"), then all Access-Request
# packets sent to that home server will have a
# Message-Authenticator attribute.
#
# We STRONGLY recommend that this flag be set to "yes"
# for ALL home servers. Doing so will have no performance
# impact on the proxy or on the home servers. It will,
# however, allow administrators to detect problems earlier.
#
# allowed values: yes, no
require_message_authenticator = yes
37 | P a g e

#
# If the home server does not respond to a request within
# this time, this server will initiate "zombie_period".
#
# The response window is large because responses MAY be slow,
# especially when proxying across the Internet.
#
# Useful range of values: 5 to 60
response_window = 20

#
# If you want the old behavior of the server rejecting
# proxied requests after "response_window" timeout, set
# the following configuration item to "yes".
#
# This configuration WILL be removed in a future release
# If you believe you need it, email the freeradius-users
# list, and explain why it should stay in the server.
#
no_response_fail = no
#
# If the home server does not respond to ANY packets during
# the "zombie period", it will be considered to be dead.
#
# A home server that is marked "zombie" will be used for
# proxying as a low priority. If there are live servers,
# they will always be preferred to a zombie. Requests will
# be proxied to a zombie server ONLY when there are no
# live servers.
#
# Any request that is proxied to a home server will continue
# to be sent to that home server until the home server is
# marked dead. At that point, it will fail over to another
# server, if a live server is available. If none is available,
# then the "post-proxy-type fail" handler will be called.
#
# If "status_check" below is something other than "none", then
# the server will start sending status checks at the start of
# the zombie period. It will continue sending status checks
# until the home server is marked "alive".
#
# Useful range of values: 20 to 120
zombie_period = 40
38 | P a g e

##

##

##########################################################
#
# As of 2.0, FreeRADIUS supports RADIUS layer "status
# checks". These are used by a proxy server to see if a home
# server is alive.
#
# These status packets are sent ONLY if the proxying server
# believes that the home server is dead. They are NOT sent
# if the proxying server believes that the home server is
# alive. They are NOT sent if the proxying server is not
# proxying packets.
#
# If the home server responds to the status check packet,
# then it is marked alive again, and is returned to use.
#
##########################################################
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#

Some home servers do not support status checks via the

Status-Server packet. Others may not have a "test" user
configured that can be used to query the server, to see if
it is alive. For those servers, we have NO WAY of knowing
when it becomes alive again. Therefore, after the server
has been marked dead, we wait a period of time, and mark
it alive again, in the hope that it has come back to
life.
If it has NOT come back to life, then FreeRADIUS will wait
for "zombie_period" before marking it dead again. During
the "zombie_period", ALL AUTHENTICATIONS WILL FAIL, because
the home server is still dead. There is NOTHING that can
be done about this, other than to enable the status checks,
as documented below.
e.g. if "zombie_period" is 40 seconds, and "revive_interval"
is 300 seconds, the for 40 seconds out of every 340, or about
10% of the time, all authentications will fail.
If the "zombie_period" and "revive_interval" configurations
are set smaller, than it is possible for up to 50% of
authentications to fail.
As a result, we recommend enabling status checks, and
we do NOT recommend using "revive_interval".
39 | P a g e

#
# The "revive_interval" is used ONLY if the "status_check"
# entry below is "none". Otherwise, it will not be used,
# and should be deleted.
#
# Useful range of values: 60 to 3600
revive_interval = 120
#
# The proxying server (i.e. this one) can do periodic status
# checks to see if a dead home server has come back alive.
#
# If set to "none", then the other configuration items listed
# below are not used, and the "revive_interval" time is used
# instead.
#
# If set to "status-server", the Status-Server packets are
# sent. Many RADIUS servers support Status-Server. If a
# server does not support it, please contact the server
# vendor and request that they add it.
#
# If set to "request", then Access-Request, or Accounting-Request
# packets are sent, depending on the "type" entry above (auth/acct).
#
# Allowed values: none, status-server, request
status_check = status-server
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#

If the home server does not support Status-Server packets,

then the server can still send Access-Request or
Accounting-Request packets, with a pre-defined user name.
This practice is NOT recommended, as it may potentially let
users gain network access by using these "test" accounts!
If it is used, we recommend that the home server ALWAYS
respond to these Access-Request status checks with
Access-Reject. The status check just needs an answer, it
does not need an Access-Accept.
For Accounting-Request status checks, only the username
needs to be set. The rest of the accounting attribute are
set to default values. The home server that receives these
accounting packets SHOULD NOT treat them like normal user
accounting packets. i.e It should probably NOT log them to
a database.
40 | P a g e

#
# username = "test_user_please_reject_me"
# password = "this is really secret"
#
# Configure the interval between sending status check packets.
#
# Setting it too low increases the probability of spurious
# fail-over and fallback attempts.
#
# Useful range of values: 6 to 120
check_interval = 30
#
# Configure the number of status checks in a row that the
# home server needs to respond to before it is marked alive.
#
# If you want to mark a home server as alive after a short
# time period of being responsive, it is best to use a small
# "check_interval", and a large value for
# "num_answers_to_alive". Using a long "check_interval" and
# a small number for "num_answers_to_alive" increases the
# probability of spurious fail-over and fallback attempts.
#
# Useful range of values: 3 to 10
num_answers_to_alive = 3
#
# Limit the total number of outstanding packets to the home
# server.
#
# if ((#request sent) - (#requests received)) > max_outstanding
#
then stop sending more packets to the home server
#
# This lets us gracefully fall over when the home server
# is overloaded.
max_outstanding = 65536
#
#
#
#
#
#
#
#

The configuration items in the next sub-section are used ONLY

when "type = coa". It is ignored for all other type of home
servers.
See RFC 5080 for the definitions of the following terms.
RAND is a function (internal to FreeRADIUS) returning
random numbers between -0.1 and +0.1
41 | P a g e

#
# First Re-transmit occurs after:
#
#
RT = IRT + RAND*IRT
#
# Subsequent Re-transmits occur after:
#
#
RT = 2 * RTprev + RAND * RTprev
#
# Re-trasnmits are capped at:
#
#
if (MRT && (RT > MRT)) RT = MRT + RAND * MRT
#
# For a maximum number of attempts: MRC
#
# For a maximum (total) period of time: MRD.
#
coa {
# Initial retransmit interval: 1..5
irt = 2
# Maximum Retransmit Timeout: 1..30 (0 == no maximum)
mrt = 16
# Maximum Retransmit Count: 1..20 (0 == retransmit forever)
mrc = 5

# Maximum Retransmit Duration: 5..60

mrd = 30

# Sample virtual home server.

#
#
#home_server virtual.example.com {
#
virtual_server = virtual.example.com
#}
##############################################################
########
#
# This section defines a pool of home servers that is used
# for fail-over and load-balancing. In earlier versions of
# FreeRADIUS, fail-over and load-balancing were defined per-realm.
# As a result, if a server had 5 home servers, each of which served
42 | P a g e

# the same 10 realms, you would need 50 "realm" entries.

#
# In version 2.0, you would need 5 "home_server" sections,
# 10 'realm" sections, and one "home_server_pool" section to tie the
# two together.
#
home_server_pool my_auth_failover {
#
# The type of this pool controls how home servers are chosen.
#
# fail-over - the request is sent to the first live
#
home server in the list. i.e. If the first home server
#
is marked "dead", the second one is chosen, etc.
#
# load-balance - the least busy home server is chosen,
#
where "least busy" is counted by taking the number of
#
requests sent to that home server, and subtracting the
#
number of responses received from that home server.
#
#
If there are two or more servers with the same low
#
load, then one of those servers is chosen at random.
#
This configuration is most similar to the old
#
"round-robin" method, though it is not exactly the same.
#
#
Note that load balancing does not work well with EAP,
#
as EAP requires packets for an EAP conversation to be
#
sent to the same home server. The load balancing method
#
does not keep state in between packets, meaning that
#
EAP packets for the same conversation may be sent to
#
different home servers. This will prevent EAP from
#
working.
#
#
For non-EAP authentication methods, and for accounting
#
packets, we recommend using "load-balance". It will
#
ensure the highest availability for your network.
#
# client-balance - the home server is chosen by hashing the
#
source IP address of the packet. If that home server
#
is down, the next one in the list is used, just as
#
with "fail-over".
#
#
There is no way of predicting which source IP will map
#
to which home server.
#
#
This configuration is most useful to do simple load
#
balancing for EAP sessions, as the EAP session will
43 | P a g e

#
always be sent to the same home server.
#
# client-port-balance - the home server is chosen by hashing
#
the source IP address and source port of the packet.
#
If that home server is down, the next one in the list
#
is used, just as with "fail-over".
#
#
This method provides slightly better load balancing
#
for EAP sessions than "client-balance". However, it
#
also means that authentication and accounting packets
#
for the same session MAY go to different home servers.
#
# keyed-balance - the home server is chosen by hashing (FNV)
#
the contents of the Load-Balance-Key attribute from the
#
control items. The request is then sent to home server
#
chosen by taking:
#
#
server = (hash % num_servers_in_pool).
#
#
If there is no Load-Balance-Key in the control items,
#
the load balancing method is identical to "load-balance".
#
#
For most non-EAP authentication methods, The User-Name
#
attribute provides a good key. An "unlang" policy can
#
be used to copy the User-Name to the Load-Balance-Key
#
attribute. This method may not work for EAP sessions,
#
as the User-Name outside of the TLS tunnel is often
#
static, e.g. "anonymous@realm".
#
#
# The default type is fail-over.
type = fail-over
#
# A virtual_server may be specified here. If so, the
# "pre-proxy" and "post-proxy" sections are called when
# the request is proxied, and when a response is received.
#
# This lets you have one policy for all requests that are proxied
# to a home server. This policy is completely independent of
# any policies used to receive, or process the request.
#
#virtual_server = pre_post_proxy_for_pool
#
# Next, a list of one or more home servers. The names
44 | P a g e

# of the home servers are NOT the hostnames, but the names
# of the sections. (e.g. home_server foo {...} has name "foo".
#
# Note that ALL home servers listed here have to be of the same
# type. i.e. they all have to be "auth", or they all have to
# be "acct", or the all have to be "auth+acct".
#
home_server = localhost
# Additional home servers can be listed.
# There is NO LIMIT to the number of home servers that can
# be listed, though using more than 10 or so will become
# difficult to manage.
#
# home_server = foo.example.com
# home_server = bar.example.com
# home_server = baz.example.com
# home_server = ...

#
# If ALL home servers are dead, then this "fallback" home server
# is used. If set, it takes precedence over any realm-based
# fallback, such as the DEFAULT realm.
#
# For reasons of stability, this home server SHOULD be a virtual
# server. Otherwise, the fallback may itself be dead!
#
#fallback = virtual.example.com

##############################################################
########
#
#
# This section defines a new-style "realm". Note the in version 2.0,
# there are many fewer configuration items than in 1.x for a realm.
#
# Automatic proxying is done via the "realms" module (see "man
# rlm_realm"). To manually proxy the request put this entry in the
# "users" file:
#
#
#DEFAULT
#

Proxy-To-Realm := "realm_name"
45 | P a g e

#
#realm example.com {
realm fatme.edu {
#
# Realms point to pools of home servers.
#
# For authentication, the "auth_pool" configuration item
# should point to a "home_server_pool" that was previously
# defined. All of the home servers in the "auth_pool" must
# be of type "auth".
#
# For accounting, the "acct_pool" configuration item
# should point to a "home_server_pool" that was previously
# defined. All of the home servers in the "acct_pool" must
# be of type "acct".
#
# If you have a "home_server_pool" where all of the home servers
# are of type "auth+acct", you can just use the "pool"
# configuration item, instead of specifying both "auth_pool"
# and "acct_pool".
#
#

authhost = LOCAL
auth_pool = my_auth_failover
acct_pool = acct
#
# Normally, when an incoming User-Name is matched against the
# realm, the realm name is "stripped" off, and the "stripped"
# user name is used to perform matches.
#
# e.g. User-Name = "bob@example.com" will result in two new
# attributes being created by the "realms" module:
#
#
Stripped-User-Name = "bob"
#
Realm = "example.com"
#
# The Stripped-User-Name is then used as a key in the "users"
# file, for example.
#
# If you do not want this to happen, uncomment "nostrip" below.
#
# nostrip

# There are no more configuration entries for a realm.

46 | P a g e

#
# This is a sample entry for iPass.
# Note that you have to define "ipass_auth_pool" and
# "ipass_acct_pool", along with home_servers for them, too.
#
#realm IPASS {
#
nostrip
#
#
auth_pool = ipass_auth_pool
#
acct_pool = ipass_acct_pool
#}
#
# This realm is used mainly to cancel proxying. You can have
# the "realm suffix" module configured to proxy all requests for
# a realm, and then later cancel the proxying, based on other
# configuration.
#
# For example, you want to terminate PEAP or EAP-TTLS locally,
# you can add the following to the "users" file:
#
# DEFAULT EAP-Type == PEAP, Proxy-To-Realm := LOCAL
#
realm LOCAL {
# If we do not specify a server pool, the realm is LOCAL, and
# requests are not proxied to it.
}
#
# This realm is for requests which don't have an explicit realm
# prefix or suffix. User names like "bob" will match this one.
#
#realm NULL {
#
authhost
= radius.company.com:1600
#
accthost
= radius.company.com:1601
#
secret
= testing123
#}
#
# This realm is for ALL OTHER requests.
#
#realm DEFAULT {
#
authhost
= radius.company.com:1600
#
accthost
= radius.company.com:1601
#
secret
= testing123
47 | P a g e

#}
realm DEFAULT {
nostrip
authhost
= toplevel.edu:1812
#
accthost
= radius.company.com:1601
secret
= testing123
}
# This realm "proxies" requests internally to a virtual server.
# The pre-proxy and post-proxy sections are run just as with any
# other kind of home server. The virtual server then receives
# the request, and replies, just as with any other packet.
#
# Once proxied internally like this, the request CANNOT be proxied
# internally or externally.
#
#realm virtual.example.com {
#
virtual_server = virtual.example.com
#}
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#

Regular expressions may also be used as realm names. If these are used,
then the "find matching realm" process is as follows:
1) Look for a non-regex realm with an *exact* match for the name.
If found, it is used in preference to any regex matching realm.
2) Look for a regex realm, in the order that they are listed
in the configuration files. Any regex match is performed in
a case-insensitive fashion.
3) If no realm is found, return the DEFAULT realm, if any.
The order of the realms matters in step (2). For example, defining
two realms ".*\.example.net$" and ".*\.test\.example\.net$" will result in
the second realm NEVER matching. This is because all of the realms
which match the second regex also match the first one. Since the
first regex matches, it is returned.
The solution is to list the realms in the opposite order,. e.g.
".*\.test\.example.net$", followed by ".*\.example\.net$".
Some helpful rules:
48 | P a g e

#
# - always place a '~' character at the start of the realm name.
# This signifies that it is a regex match, and not an exact match
# for the realm.
#
# - place the regex in double quotes. This helps the configuration
# file parser ignore any "special" characters in the regex.
# Yes, this rule is different than the normal "unlang" rules for
# regular expressions. That may be fixed in a future release.
#
# - use two back-slashes '\\' whenever you need one backslash in the
# regex. e.g. "~.*\\.example\\.net$", and not "~\.example\.net$".
# This is because the regex is in a double-quoted string, and normal
# rules apply for double-quoted strings.
#
# - If you are matching domain names, use two backslashes in front of
# every '.' (dot or period). This is because '.' has special meaning
# in a regular expression: match any character. If you do not do this,
# then "~.*.example.net$" will match "fooXexampleYnet", which is likely
# not what you want
#
# - If you are matching domain names, put a '$' at the end of the regex
# that matches the domain name. This tells the regex matching code
# that the realm ENDS with the domain name, so it does not match
# realms with the domain name in the middle. e.g. "~.*\\.example\\.net"
# will match "test.example.netFOO", which is likely not what you want.
# Using "~(.*\\.)example\\.net$" is better.
#
# The more regex realms that are defined, the more time it takes to
# process them. You should define as few regex realms as possible
# in order to maximize server performance.
#
#realm "~(.*\\.)*example\\.net$" {
# auth_pool = my_auth_failover
#}

5.7.2 radiusd.conf:

Le fichier de configuration de radiusd.confest un fichier de configuration du serveur

freeradius.

radiusd.conf :
# -*- text -*-

49 | P a g e

##
## radiusd.conf

-- FreeRADIUS server configuration file.

##
##

http://www.freeradius.org/

##

$Id$

##

##############################################################
########
prefix = /usr
exec_prefix = /usr
sysconfdir = /etc
localstatedir = /var
sbindir = ${exec_prefix}/sbin
logdir = /var/log/freeradius

raddbdir = /etc/freeradius
radacctdir = ${logdir}/radacct
name = freeradius
# Location of config and logfiles. confdir = ${raddbdir}
run_dir = ${localstatedir}/run/${name}
# Should likely be ${localstatedir}/lib/radiusd db_dir = ${raddbdir}

libdir = /usr/lib/freeradius pidfile = ${run_dir}/${name}.pid user = freerad

group = freerad max_request_time = 30 cleanup_delay = 5
max_requests = 1024 listen {
type = auth ipaddr = * port = 0
50 | P a g e

listen {
ipaddr = *

port = 0
type = acct
}
hostname_lookups = no
allow_core_dumps = no
regular_expressions = yes
extended_expressions = yes
log {

file = ${logdir}/radius.log
syslog_facility = daemon
stripped_names = no
auth = no

auth_badpass = no
auth_goodpass = no
}
# The program to execute to do concurrency checks. checkrad =
${sbindir}/checkrad

51 | P a g e

# SECURITY CONFIGURATION
security {
# Setting this number to 0 means "allow any number of attributes"

max_attributes = 200
#

Useful ranges: 1 to 5 reject_delay

=1
# See also raddb/sites-available/status

status_server = yes

# PROXY CONFIGURATION
proxy_requests = yes
$INCLUDE proxy.conf

# CLIENTS CONFIGURATION
# Client configuration is defined in "clients.conf". $INCLUDE
clients.conf
# THREAD POOL CONFIGURATION
thread pool {
# Number of servers to start initially --- should be a reasonable

# ballpark figure.
start_servers = 5
52 | P a g e

max_servers = 32
min_spare_servers = 3
max_spare_servers = 10

max_requests_per_server = 0
}

# MODULE CONFIGURATION modules {

#
# Each module has a configuration as follows:
#
#

name [ instance ] {

config_item = value

...

$INCLUDE ${confdir}/modules/

# Extensible Authentication Protocol

$INCLUDE eap.conf
$INCLUDE sql.conf $INCLUDE sqlippool.conf
}
instantiate
{
exec
53 | P a g e

expr expiration logintime

}
#

Policies that can be applied in multiple places are listed

globally. That way, they can be defined once, and referred

to multiple times.

$INCLUDE policy.conf
$INCLUDE sites-enabled/
##############################################################
5.7.3 users:

Dans ce fichier, on dfinit la liste des utilisateurs quon autorise.

# Default for CSLIP: dynamic IP address, SLIP mode, VJ-compression.
DEFAULT

Hint == "CSLIP"

Framed-Protocol = SLIP,
Framed-Compression = Van-Jacobson-TCP-IP

# Default for SLIP: dynamic IP address, SLIP mode.

DEFAULT Hint == "SLIP"
Framed-Protocol = SLIP
##############################################################
5.7.4 clients.conf:

Ce fichier permet de dfinir la liste des AP que lon autorise accder au serveur Radius. Ce
serveur et lAP partagent un secret (une cl) pour crypter les donnes.

54 | P a g e

clients.conf:
# -*- text -*## clients.conf -- client configuration directives
##

$Id$

##############################################################
client localhost {
ipaddr = 127.0.0.1
secret = testing123
require_message_authenticator = no

nastype = other # localhost isn't usually a NAS...

}
client 192.168.8.22/24 { /* Access point de Radius2 */
secret = testing123
shortname = private-network-2
}
###########################################################

5.7.5 eap.conf:

On specifie que lon veut utiliser peap et non MD5.

eap.conf:
# -*- text -*## eap.conf -- Configuration for EAP types (PEAP, TTLS, etc.)
##
##

$Id$

##############################################################
55 | P a g e

eap {
default_eap_type = peap timer_expire =
60 ignore_unknown_eap_types = no
cisco_accounting_username_bug = no

max_sessions = 4096
md5 {
}
leap {
}
gtc {
auth_type = PAP
}
tls {
certdir = ${confdir}/certs

cadir = ${confdir}/certs private_key_password = whatever

private_key_file = ${certdir}/server.key certificate_file =
${certdir}/server.pem CA_file = ${cadir}/ca.pem
dh_file = ${certdir}/dh random_file = /dev/urandom CA_path =
${cadir}

cipher_list = "DEFAULT"

56 | P a g e

make_cert_command = "${certdir}/bootstrap" cache {

enable = no lifetime = 24 # hours max_entries =
255
}
ttls {
default_eap_type = md5
copy_request_to_tunnel = no use_tunneled_reply
= no

virtual_server = "inner-tunnel"
}
peap {
default_eap_type = mschapv2

copy_request_to_tunnel = no
use_tunneled_reply = no
virtual_server = "inner-tunnel"
}

mschapv2 {
}
}
##############################################################

57 | P a g e

5.7.6 sql.conf:

Contient la configuration du module SQL.

sql.conf:
# -*- text -*##
## sql.conf -- SQL modules
##
##
$Id$
##############################################################
########
#
# Configuration for the SQL module
#
# The database schemas and queries are located in subdirectories:
#
#
sql/DB/schema.sql Schema
#
sql/DB/dialup.conf Basic dialup (including policy) queries
#
sql/DB/counter.conf counter
#
sql/DB/ippool.conf IP Pools in SQL
#
sql/DB/ippool.sql schema for IP pools.
#
# Where "DB" is mysql, mssql, oracle, or postgresql.
#
sql {

#
# Set the database to one of:
#
#
mysql, mssql, oracle, postgresql
#
database = "mysql"
#
# Which FreeRADIUS driver to use.
#
driver = "rlm_sql_${database}"
# Connection info:
server = "localhost"
#port = 3306
58 | P a g e

login = "radius"
password = "radpass"
# Database table configuration for everything except Oracle
radius_db = "radius"
# If you are using Oracle then use this instead
# radius_db =
"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))(CONNECT
_DATA=(SID=your_sid)))"
# If you want both stop and start records logged to the
# same SQL table, leave this as is. If you want them in
# different tables, put the start table in acct_table1
# and stop table in acct_table2
acct_table1 = "radacct"
acct_table2 = "radacct"
# Allow for storing data after authentication
postauth_table = "radpostauth"
authcheck_table = "radcheck"
authreply_table = "radreply"
groupcheck_table = "radgroupcheck"
groupreply_table = "radgroupreply"
# Table to keep group info
usergroup_table = "radusergroup"
# If set to 'yes' (default) we read the group tables
# If set to 'no' the user MUST have Fall-Through = Yes in the radreply table
# read_groups = yes
# Remove stale session if checkrad does not see a double login
deletestalesessions = yes
# Print all SQL statements when in debug mode (-x)
sqltrace = no
sqltracefile = ${logdir}/sqltrace.sql
# number of sql connections to make to server
num_sql_socks = 5
# number of seconds to dely retrying on a failed database
# connection (per_socket)
connect_failure_retry_delay = 60
59 | P a g e

# lifetime of an SQL socket. If you are having network issues

# such as TCP sessions expiring, you may need to set the socket
# lifetime. If set to non-zero, any open connections will be
# closed "lifetime" seconds after they were first opened.
lifetime = 0
# Maximum number of queries used by an SQL socket. If you are
# having issues with SQL sockets lasting "too long", you can
# limit the number of queries performed over one socket. After
# "max_qeuries", the socket will be closed. Use 0 for "no limit".
max_queries = 0
# Set to 'yes' to read radius clients from the database ('nas' table)
# Clients will ONLY be read on server startup. For performance
# and security reasons, finding clients via SQL queries CANNOT
# be done "live" while the server is running.
#
#readclients = yes
readclients = yes
# Table to keep radius client info
nas_table = "nas"

# Read driver-specific configuration

$INCLUDE sql/${database}/dialup.conf

5.7.7 sqlippool.conf:

Contient la configuration de SQL base sur le module IP pool.

sqlippool.conf:
## Configuration for the SQL based IP Pool module (rlm_sqlippool)
##
## The database schemas are available at:
##
##
raddb/sql/DB/ippool.sql
sqlippool {
60 | P a g e

#########################################
sql-instance-name = "sql"
## SQL table to use for ippool range and lease info
ippool_table = "radippool"

## IP lease duration. (Leases expire even if Acct Stop packet is lost)

lease-duration = 3600
pool-key = "%{NAS-Port}" $INCLUDE
sql/postgresql/ippool.conf
sqlippool_log_exists = "Existing IP: %{reply:Framed-IP-Address} \
(did %{Called-Station-Id} cli %{Calling-Station-Id} port %{NAS-Port} user %{UserName})"
sqlippool_log_success = "Allocated IP: %{reply:Framed-IP-Address} from %{control:PoolName} \
(did %{Called-Station-Id} cli %{Calling-Station-Id} port %{NAS-Port} user %{UserName})"
sqlippool_log_clear = "Released IP %{Framed-IP-Address}\
(did %{Called-Station-Id} cli %{Calling-Station-Id} user %{User-Name})"
sqlippool_log_failed = "IP Allocation FAILED from %{control:Pool-Name} \
(did %{Called-Station-Id} cli %{Calling-Station-Id} port %{NAS-Port} user %{UserName})"
sqlippool_log_nopool = "No Pool-Name defined \
(did %{Called-Station-Id} cli %{Calling-Station-Id} port %{NAS-Port} user %{UserName})"
}

61 | P a g e

##############################################################
5.7.8 sites-enabled:

Dans le rpertoire /etc/freeradius/sites-available on place les serveurs potentiellement

utilisables, mais en /etc/freeradius/sites-enabled on place ceux qui sont rellement utiliss.

5.7.8.1 default:
#

$Id$

authorize {
preprocess
chap
mschap
digest
eap {
ok = return
}
files sql

expiration logintime pap

}
authenticate { Auth-Type PAP {

pap
}

Auth-Type CHAP {
62 | P a g e

chap
}

Auth-Type MS-CHAP {
mschap
}
digest unix eap
}
preacct {

preprocess acct_unique files

}
accounting {
detail

unix radutmp
sql
exec
}

session { radutmp sql

}
post-auth { sql exec
Post-Auth-Type REJECT {

63 | P a g e

# log failed authentications in SQL, too. sql

attr_filter.access_reject
}
} pre-proxy {
}
post-proxy {
eap
}

Inner-tunnel:
#

$Id$

server inner-tunnel { listen {

ipaddr = 127.0.0.1 port = 18120

type = auth
}
authorize { chap mschap eap {
ok = return
}
sql expiration logintime pap
}
authenticate { Auth-Type PAP {
pap
}
Auth-Type CHAP {
chap
64 | P a g e

}
Auth-Type MS-CHAP {
mschap
}
unix eap

}
session { radutmp sql
}
post-auth {
sql
Post-Auth-Type REJECT {
sql attr_filter.access_reject
}
}
pre-proxy {
}

post-proxy {
eap
}
}
############################################################

65 | P a g e

5.7.9 Fichiers dans /sql/mysql:

Table nas qui permet de remplacer le fichier client.conf en stockant la liste des NAS
autoris.
Table radacct qui stocke les informations que retourne le NAS quand on fait de
l'accounting.
Table radcheck qui permet de vrifier une option d'un utilisateur (par exemple le mot de
passe quand on utilise PEAP ou TTLS).
Table radgroupcheck mme chose que radcheck mais pour une option de groupe.
Table radgroupreply qui permet de retourner une option de groupe (un numro de Vlan
par ex).
Table radpostauth qui stocke chaque authentification russie.
Table radreply qui permet de retourner une option pour l'utilisateur.
Table usergroup qui permet de faire la liaison entre le nom d'utilisateur et son groupe.
Quand on utilise FreeRadius avec une base de donnes, la gestion des utilisateurs est un
peu diffrente, chaque utilisateur est rattach un groupe. Ce qui fait qu'il y a les options de
groupe et les options pour l'utilisateur.

Figure 19: Fichiers dans /sql/mysql

5.7.9.1 schema.sql:
66 | P a g e

# $Id$

# schema.sql
# Table structure for table 'radacct'

# CREATE TABLE radacct (

radacctid bigint(21) NOT NULL auto_increment,
acctsessionid varchar(64) NOT NULL default '',
acctuniqueid varchar(32) NOT NULL default '',
username varchar(64) NOT NULL default '',
groupname varchar(64) NOT NULL default '',
realm varchar(64) default '',
nasipaddress varchar(15) NOT NULL default '',
nasportid varchar(15) default NULL,
nasporttype varchar(32) default NULL,
acctstarttime datetime NULL default NULL,
acctstoptime datetime NULL default NULL,
acctsessiontime int(12) default NULL,
acctauthentic varchar(32) default NULL,
connectinfo_start varchar(50) default NULL,
connectinfo_stop varchar(50) default NULL, acctinputoctets bigint(20) default NULL,
acctoutputoctets bigint(20) default NULL, calledstationid varchar(50) NOT NULL default '',
callingstationid varchar(50) NOT NULL default '', acctterminatecause varchar(32) NOT
NULL default '',

67 | P a g e

servicetype varchar(32) default NULL,

framedprotocol varchar(32) default NULL,
framedipaddress varchar(15) NOT NULL default '',
acctstartdelay int(12) default NULL,
acctstopdelay int(12) default NULL,
xascendsessionsvrkey varchar(10) default NULL,
PRIMARY KEY (radacctid),
KEY username (username),
KEY framedipaddress (framedipaddress),
KEY acctsessionid (acctsessionid), KEY acctsessiontime (acctsessiontime), KEY
acctuniqueid (acctuniqueid),
KEY acctstarttime (acctstarttime), KEY acctstoptime (acctstoptime), KEY
nasipaddress (nasipaddress) ) ;
# Table structure for table 'radcheck' CREATE TABLE radcheck (
id int(11) unsigned NOT NULL auto_increment, username varchar(64) NOT NULL default '',

attribute varchar(64) NOT NULL default '', op char(2) NOT NULL DEFAULT '==', value
varchar(253) NOT NULL default '', PRIMARY KEY (id),
KEY username (username(32)) ) ;
# Table structure for table 'radgroupcheck' CREATE TABLE radgroupcheck (
id int(11) unsigned NOT NULL auto_increment,
groupname varchar(64) NOT NULL default '', attribute varchar(64) NOT NULL default '',

op char(2) NOT NULL DEFAULT '==', value varchar(253) NOT NULL default '',
PRIMARY KEY (id),
68 | P a g e

KEY groupname (groupname(32)) ) ;

# Table structure for table 'radgroupreply' CREATE TABLE radgroupreply (
id int(11) unsigned NOT NULL auto_increment, groupname varchar(64) NOT NULL default '',
attribute varchar(64) NOT NULL default '',

op char(2) NOT NULL DEFAULT '=', value varchar(253) NOT NULL default '',
PRIMARY KEY (id),
KEY groupname (groupname(32)) ) ;
# Table structure for table 'radreply' CREATE TABLE radreply (
id int(11) unsigned NOT NULL auto_increment, username varchar(64) NOT NULL default '',
attribute varchar(64) NOT NULL default '',

op char(2) NOT NULL DEFAULT '=', value varchar(253) NOT NULL default '',
PRIMARY KEY (id),

KEY username (username(32)) ) ;

# Table structure for table 'radusergroup'
CREATE TABLE radusergroup (
username varchar(64) NOT NULL default '', groupname varchar(64) NOT NULL default
'', priority int(11) NOT NULL default '1',
KEY username (username(32)) ) ;
# Table structure for table 'radpostauth'
CREATE TABLE radpostauth (

id int(11) NOT NULL auto_increment,

username varchar(64) NOT NULL default '',
pass varchar(64) NOT NULL default '',
69 | P a g e

reply varchar(32) NOT NULL default '',

authdate timestamp NOT NULL,
PRIMARY KEY (id)
);
##############################################################

TOPLEVEL Radius :
Dans le fichier proxy.conf de TopLevel, on ajoute les realms des deux universits :

Realm fatme.edu
{
nostrip
authhost= fatme.edu
secret= testing123
}

Realm fatme2.edu
{
nostrip
authhost= fatme2.edu
secret= testing123
}

70 | P a g e

6. TEST, RSULTATS ET ANALYSE:

6.1 Test du proxy :
FreeRADIUS est le serveur RADIUS install. L'ide de ce test est de s'assurer que le serveur
est en cours d'excution et il transmet les demandes au serveur appropri quand il les
reoit.
Le test ultime qui peut tre fait sur le serveur RADIUS est la "radtest". Le radtest est un
outil d'essai qui envoie la demande d'authentification au serveur. Il peut tre localement
(en utilisant localhost) ou distance ( partir d'un client ajout). Lorsque le radtest donne
une rponse Access-Accept puis lauthentification fonctionne sur le serveur. Le format de la
commande est radtest:

"radtest {nom d'utilisateur} {mot de passe} {hostname} 1812 radius_secret ", dans mon cas
ctait de la forme :
radtest x user1 123456 fatme 1812 testing123
ce qui donne:
Sending Access-Request of id 17 to 127.0.0.1 port 1812
User-Name = "user1"
User-Password = "123456"
NAS-IP-Address = 127.0.1.1
NAS-Port = 1812
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812,id=147, length=40
6.2 Test durseau l'aidedes informations d'identificationAdecampusA :
Le concept deduroam est pour l'itinrance. Ce n'est pas pour toute utilisation dans
linstitution d'accueil. Dans ce cas, il n'a pas de sens pour tester le systme la maison
institution. Au moins le test de l'tablissement d'origine n'est pas si loin fiable. L'ide
derrire le test de campus A est de tester si le serveur proxy sera en mesure de transmettre
le paquet d'authentification pour serveur proxy de A et si les informations d'identification
valides sont fourni, pouvons-nous avoir l'authentification succs. Peu importe o le paquet
est provenant, lorsque le proxy reoit une demande RADIUS contenant "fatme.edu" comme
domaine, il devrait tre transmis au serveur proxy A. Je pense que la vrification du rseau
sur le campus A est un grand pas dans le processus de test. Si le test est russi du campus A,
il devrait tre succs des autres campus eduroam permis. Si le dernier cas ne russit pas, il
71 | P a g e

est facile de localiser le problme et de trouver une manire de la rsoudre. Reportez-vous

la figure (s) ci-dessous:

Figure 20:Eduroam fentre de connexion et la fentre de connexion russie.

6.3 Test avec les informations d'identification d'un tablissement B

deduroam activ sur le campus A :
Ce test est plus important que le prcdent. Le rsultat de ce test nous dira si le systme va
jouer le rle pour lequel il a t mis en place: laisser les lves itinrants utiliser leurs
informations d'identification personnelles pour avoir accder au rseau. Dans ce test, un
nom d'utilisateur et mot de passe pour la tlcommande eduroam institution permis sont
utiliss.
Si l'authentification russit, il va dire deux choses:
-Le proxy est de transmettre la demande selon le domaine
-La connexion de notre proxy pour le serveur RADIUS distant (domaine : fatme2.edu)
institution russie.
72 | P a g e

La fentre de connexion et l'authentification russie sont affiches ci-dessous:

Figure21: fentre de connexion Eduroam avec des rfrences externes et connexion russie.

73 | P a g e

Le schma final de mon projet tant le suivant :

Figure22: schma final du projet

Explication du schma :
Jai cr deux domaines illustrant deux diffrentes universits eduroam (A et B). Chaque
tudiant dune universit se connecte sur lAccess point deduroam en utilisant ou non le
nom du domaine de son universit (user/ user@doamine.edu).
En cas ditinrance, le proxy server de luniversit contenant le nom du domaine de lautre
universit, envoie la requte par lintermdiaire dun Gateway lautre universit pour
vrifier les informations de ltudiant dans la base de donnes et permet donc, en cas de
vrification, laccs Internet.

74 | P a g e

Le plan dadresses choisi :

University A :
Access Point : 192.168.7.33
Server Radius : 192.168.7.3
Gateway : 192.168.7.1
Domaine name: fatme.edu
University B :
Access Point : 192.168.8.22
Server Radius : 192.168.8.2
Gateway : 192.168.8.1
Domaine name: fatme2.edu

75 | P a g e

7. LIMITATIONS :
La premire difficult dans ce projet, c'est le fait que je n'tais pas familier avec Ubuntu au
dbut. Ensuite, ctait un travail personnel, jtais monme durant ce projet, donc pas de
travail partag, je dois tout tester et tout faire seule. Mais malgr ces limitations, jai pu
raliser ce projet avec succs.

8. EXTENSION DU PROJET:
Pour plus d'extension de ce travail, il serait intressant de travailler sur la faon de refuser
l'accs pour les utilisateurs locaux qui tentent d'obtenir eduroam de campusA. Ce serait
de trouver et conserver les adresses IP alloues pour seuls clients et viter que les
utilisateurs jouent autour avec les adresses IP publiques.

76 | P a g e

9. CONCLUSION:
Eduroam est un rseau sans fil qui permet aux utilisateurs d'utiliser leurs pouvoirs de leur
institution eduroam activ pour se connecter un autre rseau connect eduroam. Pour les
utilisateurs, c'est un moyen simple d'tre connecter Internet l'aide de leurs ordinateurs
portables.
Avec eduroam situ sur un campus, deux options sont offertes : les usagers de
l'tablissement lui-mme peut aller n'importe quel tablissement eduroam - permis et
d'avoir accs au rseau; les utilisateurs d'un autre tablissement d'eduroam - permis
peuvent galement utiliser leurs pouvoirs d'accueil sur ce campus.
Au cours de la mise en uvre, j'ai configur le serveur RADIUS qui agit en tant que
fournisseur de services (SP), et configur tous les commutateurs et points d'accs.
Dans ce projet, le serveur FreeRADIUS est utilis comme serveur de SP.
Aprs la mise en uvre, les essais du systme ont russi des campus A (domaine :
fatme.edu) et les autres campus.
Le processus d'authentification qui a lieu avant d'accorder l'accs au rseau est un bon
systme qui peut tre dploy dans de nombreuses entreprises ou institutions pour
empcher la connexion non dsire.

77 | P a g e

10. LISTE DES FIGURES :

Figure 1: Hirarchie des Serveurs dans le rseau eduroam.
Figure 2: Carte des pays eduroam connect Europennes.

Figure 3: Carte dinstitutions connectes eduroam en Finlande (avril 2010).

Figure 4: Schmatisation des communications Radius.
Figure 5: Etapes d'authentification 802.1X.
Figure 6: Fonctionnement interrupteur de 802.1X.
Figure 7: Mthode d'authentification EAP-TTLS.
Figure 8: Architecture du serveur Radius.
Figure 9: Format de paquet RADIUS.
Figure 10: Flux de messages RADIUS.
Figure 11: Architecture Wi-Fi eduroam.

Figure 12: Mthodes dauthentification supportes par Radius

Figure 13: Types dauthentifications supports
Figure 14: Fichiers dans le paquet freeradius Figure 15: Schma de
la base de donnes des clients
Figure 16: La base de donnes Radius cr sur phpmyadmin
Figure 17: Linterface graphique webmin
Figure 18: Le secret partag pour le chiffrement du paquet
Figure 19: Fichiers dans /sql/mysql
Figure 20: Eduroam fentre de connexion et la fentre de connexion russie.
Figure 21: fentre de connexion Eduroam avec des rfrences externes et connexion
russie.
Figure 22: schma final du projet
78 | P a g e

11. RFERENCE :

www.eduroam.fr

https://ideasnet.wordpress.com/category/ubuntu-12-04lts-freeradius-server-edition/

http://lists.freeradius.org/pipermail/freeradius-users/2013-January/064640.html

https://www.eduroam.us/technical_overview

https://confluence.terena.org/display/H2eduroam/freeradius-sp

https://confluence.terena.org/display/H2eduroam/How+to+deploy+eduroam+on
site+or+on+campus

79 | P a g e