Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

IUT des Pays de l’Adour Licence PRO ASUR Configuration AAA/RADIUS sur Cisco/Lin

IUT des Pays de l’Adour Licence PRO ASUR Configuration AAA/RADIUS sur Cisco/Linux 1 Objectifs Le but de ce TP est de mettre en place un serveur RADIUS sous Linux et de l’utiliser à des fins d’authentification et de comptabilité depuis un routeur Cisco. 2 Architecture de travail  Ayant la nécessité de disposer des droits d’administrateurs, vous devrez travailler sur les machines virtuelles. Un seul PC est néanmoins suffisant qui pourra servir (dans des fenêtres distinctes), de terminal, de client telnet et de serveur Radius.  Vérifiez AVANT TOUT que vous disposiez bien d’un PC sous Linux UBUNTU et que le package freeradius soit bien installé. Pour cela, vérifiez par exemple la présence du programme exécutable /usr/sbin/freeradius. Si ce n’est pas le cas, vérifiez votre connexion à internet et faites le avec : « aptitude install freeradius ». Si cela ne marche pas vérifiez : o Que le cache est configuré o Que le dépôt « tierce partie » est activé dans les dépôts utilisables ou utilisez l'interface graphique !  Mettez en place l’architecture suivante en utilisant des adresses IP en correspondance avec les adresses qui sont affectées à vos machines virtuelles. Les fichiers de configuration de freeradius se trouvent sous le répertoire /etc/freeradius/ De nombreux fichiers de configuration apparaissent dans ce répertoire, mais en réalité, le seul fichier pris en compte est le fichier « radiusd.conf ». Néanmoins, d'autres fichiers de configuration vont être utilisés depuis « radiusd.conf » par des directives « include ». Particulièrement, à la fin du fichier, vous pourrez remarquer une directive include de tous les fichiers se trouvant dans le répertoire « /etc/freeradius/sites-enabled ». Pour ceux qui sont habitués à la syntaxe d'Apache2, il s'agit du même principe permettant de configurer des serveurs virtuels. Dans le cadre de ce TP, vous n'aurez nul besoin de modifier « radiusd.conf ». Seul le fichier « default » se trouvant dans le dossier « /etc/freeradius/sites-available » devra être modifié. Mais AVANT de modifier quoi que ce soit dans ce fichier, FAITES EN UNE COPIE sous « default.orig » !!! 1 V 2.0 PC 2 (Linux UBUNTU) RZO : 10.2.18.0 / 24 Switch Central (Huguette ou Hortense) PC 1 (Linux UBUNTU) 18.Z 18.X / 24 18.Y / 24 IUT des Pays de l’Adour Licence PRO ASUR « radiusd.conf » est assez pénible à appréhender … quelques explications s’imposent. 3 Fichier de configuration « radiusd.conf » 3.1 Section « Directives générales » La première partie comporte un certain nombre de directives générales (qui ne sont pas sans rappeler les directives du fichier « httpd.conf » d’Apache, pour ceux qui connaissent). La plupart des directives sont assez explicites, et quoi qu’il en soit sont commentées. L’objectif de ce TP n’est pas de détailler ici toutes les fonctionnalités de freeradius, mais d’en comprendre le fonctionnement général. 3.2 Section « instanciation » (de modules) Freeradius est conçu de façon extrêmement modulaire, ce qui permet de l’interfacer facilement avec tout autre type de matériel ou service. Quelques exemples de modules :  « unix », qui permet d’utiliser les fichiers au format /etc/password, group et shadow d’Unix, comme base de données du serveur RADIUS  « eap », qui permet d’utiliser ce type d’authentification avec le NAS  « ldap », qui permet d’interfacer RADIUS avec un serveur ldap externe, contenant les bases d’authentification, voire de comptabilité,  « realm », (en français : royaume) permettant de relayer les requêtes sur un autre serveur RADIUS (fonctionnalité de « proxy-radius »).  … Cette section permet donc d’instancier tout module , c'est à dire en quelque sorte de le charger en mémoire en tenant compte de ses paramètres de configuration (voir section suivante: modules). Il est important de noter, que l'instanciation d'un module n'est pas obligatoire ICI … en effet, un module sera de toute façon AUTOMATIQUEMENT instancié au moment de son utilisation. A quoi sert donc cette section ? Certains modules sont … capricieux. Pour des raisons techniques, ils doivent être instanciés avant certains autres qui les utilisent. Cette section permet donc d'éviter ce genre de comportement particulier en faisant une instanciation manuelle. Inutile de dire que dans la grande majorité des cas, il n'est pas nécessaire de modifier quoi que ce soit ici ... 3.3 Section « Modules » 3.3.1 Généralités Cette section permet de définir les paramètres de configuration de chaque module. Vous la repèrerez grâce à la directive de début de bloc « modules { ». Jetez un coup d'œil, et vous comprendrez vite son intérêt. Les paramètres sont bien entendu spécifiques à chaque module. 3.3.2 Modules à utiliser pour le TP Dans le cadre de notre TP, pour gagner en lisibilité, il vous est possible de « nettoyer » quelque peu cette section et de ne conserver que les modules qui vont nous intéresser, à savoir : « preprocess » : ce module (quasi indispensable) est appliqué avant tous les autres. Il a pour rôle de réécrire dans un format aujourd’hui standard (essentiellement les attributs), les requêtes issues de NAS anciens ou pas parfaitement conforme aux dernières spécifications. « files » : module qui nous permettra d’utiliser une base de données d’authentification sous forme de fichier local au serveur RADIUS. Même si cette utilisation est rare dans un contexte de production, (ou on préfèrera une base de données SQL ou LDAP) elle est largement plus simple à mettre en œuvre dans le cadre de ce TP et permet de nous affranchir de tout problème d’installation d’un serveur de BD, hors sujet aujourd’hui. « acct_unique » : module dédié au service de comptabilité. Il permet de générer un identification unique de session, identique pour toutes les requêtes de comptabilité reçues par le serveur entre un « start » et un « stop ». Même si un identificateur semblable (géré par l’attribut 44 : Acct_Session_ID°est censé exister, ce module permet de concevoir un numéro d’identification plus fiable, qu’il est préférable d’utiliser. 2 V 2.0 IUT des Pays de l’Adour Licence PRO ASUR 3.4 Sections d’application de modules REMARQUE: Depuis la version 2.0 de Freeradius, les sections suivantes, spécifiques à chaque serveur virtuel, sont contenues dans les fichiers du dossier « sites-available » (dans ce TP, le fichier « default »). 3.4.1 Principe général 3.4.1.1 Le concept de Freeradius Chacune des sections suivantes correspond à une étape (dans la chaîne de traitement des messages, par le code de freeradius), pendant lequel les modules seront appliqués sur les messages. Par exemple, il est intuitivement facile de comprendre que la section « preacct » correspond à l’étape située APRES réception d’un message de comptabilité, et AVANT son traitement proprement dit. C’est donc dans cette section qu’il est particulièrement indiqué d’invoquer le module « preprocess » expliqué plus haut. De même, les sections « accounting » « pre- proxy » et « post-proxy » ont des noms assez éloquents… Autant vous avertir tout de suite, on en a fini avec l’intuitif et l’éloquent … pour bien comprendre les trois sections (TRES SPECIFIQUES A L’IMPLANTATION FREERADIUS ET ABSOLUMENT PAS GENERALES AU CONCEPT RADIUS…) « authorize » « authenticate » et « post-auth », il faut un certain nombre de connaissances préalables liées à la structure de données utilisée par le code de Freeradius. Allons y donc : Freeradius gère en interne 3 tables distinctes, qu’il appelle « Request », « Check » et « Reply » formalisées dans le tableau ci-dessous : « Request> « Check » « Reply » 3.4.1.2 Etape « authorize » Lors de la réception d’une requête d’AUTHENTIFICATION de la part du NAS, Freeradius exécute l’étape correspondant à la section maladroitement appelée « AUTHORIZE » dans le fichier de configuration. APRES application des modules contenus dans cette section (typiquement « preprocess »), il enregistre dans la table « Request » les attributs reçus dans la requête (et éventuellement modifiés par l’effet de ces différents modules). La table « Request » contient généralement au moins un attribut « User-Name » et un attribut « User-Password » (notez que dans le cadre d’un échange CHAP avec le NAS, à la place de l’attribut « User-password » vous pouvez trouver les attributs « CHAP-Password » et « CHAP-Challenge »). Toujours dans la même étape, Freeradius récupère dans la base de données d’authentification (dans notre cas, dans le fichier), les attributs correspondant au « User-Name » spécifié, et enregistre ces nouveaux attributs dans la table « Check ». Cette table contient maintenant des attributs sur lesquels on peut faire la même remarque que ci-dessus, en ce qui concerne le mot de passe. 3.4.1.3 Etape « authenticate » Après quoi, Freeradius exécute l’étape correspondant à la section « AUTHENTICATE » du fichier de configuration. Au cours de cette étape, il exécute les modules lui permettant de comparer « intelligemment » les attributs de la première table et de la seconde pour procéder à l’authentification proprement dite. « intelligemment » veut dire qu’il va invoquer les modules (configurés dans cette section), lui permettant de mettre éventuellement en forme les attributs d’une table pour les rendre comparables à uploads/Finance/ chapitre-3-tp-aaa-radius-v2-0.pdf