LE RADIUS DU CLIENT NE REÇOIT PAS LES REQUETES RADIUS

Problème 1. Le réseau du client a un FireWall
Certains clients mettent en place des FireWall pour protéger leur site client. Dans ce cas, il arrive qu'ils oublient de laisser passer le flux RADIUS provenant du PAS à destination des RADIUS Client.

Problème 2. Problème de routage
Vérifier que les routes permettent bien au PAS d'envoyer une requête RADIUS à destination du RADIUS Client. Vérifier aussi que des Access-List n'auraient pas été placées au niveau des routeurs, ce qui pourraient bloquer les requêtes RADIUS.

LE SERVEUR RADIUS REÇOIT BIEN LES REQUETES D'AUTHENTIFICATION MAIS REJETTE SYSTEMATIQUEMENT LA DEMANDE

La quasi totalité des RADIUS disposent de log facilement exploitables. Ils donnent des informations qui peuvent permettre de mieux cerner le problème rencontré.

Problème 3. Utilisateur inconnu
Si les logs du RADIUS indiquent un message du type " User unknown " ou " Utilisateur inconnu ", alors l'utilisateur qui cherche a s'identifier n'est pas connu du RADIUS Client.Dans le cas d'un problème de syntaxe, Il convient en premier lieu de vérifier que la syntaxe de l'utilisateur a été correctement saisie dans le RADIUS Client et lors de l'authentification.

Problème 4. Mot de passe incorrect
Si les logs du Radius indiquent un message du type " password incorrect " ou " mot de passe erroné ", le mot de passe reçu par le RADIUS Client ne correspond pas à celui de sa base.Dans le cas d'un problème de syntaxe, Il convient de vérifier que le mot de passe est correctement saisi dans le RADIUS Client et par l'utilisateur lors de sa demande d'authentification.

Problème 5. " Client " inconnu
Si les logs du RADIUS Client indiquent un message du type " unknown client" ou " client inconnu ", cela indique que l'émetteur de la requête vers le RADIUS Client est inconnu du serveur.Adresse IP de l'émetteur non connue du RADIUS Client : Les RADIUS Client doivent connaître les équipements qui vont leur envoyer des requêtes. Nos clients NetRevenu PACK doivent donc déclarer au niveau de leur RADIUS Client les adresses IP de nos PAS pour que le dialogue entre les PAS et les RADIUS Client fonctionne.Clé incorrecte : Chaque RADIUS Client connaît l'adresse IP des émetteurs de requêtes RADIUS. Néanmoins, pour éviter des attaques du type " spoofing ", à chaque adresse IP on associe un clé secrète connue uniquement du PAS et du RADIUS Client. Il se peut qu'une erreur de saisie de la clé soit intervenue, soit au niveau du RADIUS Client, soit au niveau du PAS. Il convient donc de vérifier la syntaxe de la clé sur chaque équipement (les majuscules sont importantes).Translation d'adresse : L'adresse IP de l'émetteur est connue du RADIUS Client et les clés sont correctement saisies dans tous les équipements. Pourtant, le message " unknown client " persiste. Il se peut dans ce cas qu'il y ait une translation d'adresse au niveau d'un FireWall ou d'un routeur, ce qui expliquerait le problème.

NON REPONSE D'UN RADIUS CLIENT

Ce phénomène se caractérise par la non réponse des RADIUS Client vers le PAS. On peut constater ce cas sur le PAS qui indiquent que des requêtes sont en " Time-Out " avec un client. Il se peut qu'il y ait non réponse d'un serveur Radius parce qu'il ne reçoit pas les requêtes.

Problème 6. Temps de réponse lent
Le client reçoit bien la requête du PAS et y répond. Néanmoins, il se peut que l'architecture liée à sa base d'utilisateur soit coûteuse en traitement et entraîne des mauvais temps de réponse. Dans ce cas, il est possible de changer la valeur du " Time-Out " au niveau du PAS.

Problème 7. " Client " inconnu
Se reporter au paragraphe " Le serveur Radius reçoit bien les requêtes d'authentification mais rejette systématiquement la demande "

REPONSE D'UN SERVEUR RADIUS IGNOREE PAR LE PROXY

Il arrive que certaines requêtes arrivent au PAS, mais ce dernier les ignore. Dans ce cas, il se peut que la clé échangée entre le PAS et le RADIUS Client est incorrecte. Il convient donc de vérifier la syntaxe de la clé sur le PAS et sur les RADIUS Client.

PROBLEMATIQUE DU PAP ENTRE WINDOWS ET LES NAS LUCENT

CERTAINS SERVEURS D'AUTHENTIFICATION FORTE NE FONCTIONNENT QU'EN PAP
Certains produits permettant de réaliser de l'authentification ne fonctionnent pas en mode CHAP ! Il s'agit essentiellement des produits permettant de réaliser de l'authentification forte. La principale raison est que les éditeurs ont totalement confiance en leur système qui génère des mots de passe dynamiques et non rejouables, et donc n'ont pas jugé utile d'implémenter le CHAP.

DES RADIUS CLASSIQUES QUI OFFRENT DES FONCTIONNALITES INCOMPATIBLES AVEC LE CHAP
Le principe du serveur Radius est d'authentifier un utilisateur. Le Radius valide un utilisateur lorsqu'il reçoit deux informations : un identifiant et un mot de passe associé à cet identifiant. Si ces informations coïncident avec celles que le Radius possède dans sa base, alors l'utilisateur est authentifié.
Certains Radius proposent d'utiliser des bases de données contenant déjà ces informations. Par exemple, des Radius sous Unix proposent d'utiliser le fichier /etc/password ! Malheureusement, dans ce cas, l'authentification ne pourra se faire qu'en PAP ! En effet, le fichier /etc/password contient bien les identifiants et les mots de passe, excepté que ces mots de passe sont codés au format DES !
Le problème réside dans le fait que le mot de passe soit codé dans le fichier password et qu'il n'est pas possible de le décoder. En effet, lorsqu'un serveur Radius reçoit une demande d'authentification en CHAP, celui-ci va coder le mot de passe qu'il possède dans sa base et va le comparer avec le mot de passe codé qu'il reçoit. Si les deux mots de passe codés sont égaux, alors l'utilisateur est authentifié !
Malheureusement, dans notre cas, le Radius va coder un mot de passe qui est déjà codé dans un autre format (DES) et va le comparer avec un mot de passe codé en MD5... L'authentification ne pourra jamais se faire :

POURQUOI NE PAS UTILISER DU PAP POUR LES SERVEURS QUI NE SUPPORTENT PAS LE CHAP ?
La solution pour les serveurs qui ne fonctionnent pas en CHAP serait donc de faire des requêtes en PAP... Le seul problème est que cela n'est pas possible dans notre chaîne d'authentification actuelle avec l'utilisation du Kit de connexion de Windows (95 et supérieure).
En effet, sous Windows (95 et supérieure) s'il est possible de configurer son Kit de connexion pour faire du CHAP, il n'est pas possible de le configurer pour faire du PAP :

La case à cocher " Require Encrypted Password " signifie lorsqu'elle est cochée : " je désire faire du CHAP ". Si cette case n'est pas cochée, cela ne signifie pas " je ne veux pas faire du CHAP " ou " je veux faire du PAP " ! Lorsque la case n'est pas cochée, le PC utilisateur indique au NAS qu'il est indifférent à la méthode d'authentification.
L'autre inconvénient est que les NAS Lucent utilisés pas Transpac sont configurés pour supporter le PAP et le CHAP. Comme ils supportent ces deux modes, lorsqu'ils reçoivent une connexion leur disant " je veux travailler en CHAP ", alors les NAS dialoguent avec le poste utilisateur en CHAP. Malheureusement, si les NAS reçoivent une connexion disant " je suis indifférent à la méthode d'authentification " , alors ceux-ci choisissent de travailler en CHAP car le CHAP offre une meilleure sécurité que le PAP !
Pour résumer ce paragraphe, on peut donc considérer qu'avec Windows (95 et supérieure) et des NAS Lucent , il n'est pas possible de faire du PAP si ce NAS est configuré pour supporter le PAP et le CHAP !

LES SOLUTIONS

CHANGER DE KIT DE CONNEXION
Une solution serait de remplacer le Kit de connexion de windows (95 et supérieure) par un Kit de connexion qui forcerait le PAP.

RAJOUTER UNE NOUVELLE COUCHE PPP SUR LE POSTE CLIENT
Il existe un logiciel nommé Wandelink qui rajoute une nouvelle couche PPP (sur le PC de l'utilisateur) qui supporte le PAP. Cette solution n'a pas été testée dans le cadre des offres " Collecte IP en modèle ouvert " et NetRevenu PACK. France Télécom ne s'engage pas sur l'utilisation de ce logiciel dans ce contexte.