FortiGate : LDAP, RADIUS et authentification firewall

Un utilisateur peut être reconnu par un serveur sans appartenir au groupe attendu dans la politique. Il peut aussi appartenir au bon groupe tout en visant un service interdit. Pour analyser un accès, séparez la validation de l’identité, l’association au groupe et la correspondance de la règle réseau.

L’authentification active sollicite des informations auprès de l’utilisateur ; une méthode passive exploite une information d’identité déjà disponible, par exemple via FSSO. Décrivez comment FortiGate obtient cette information et quand il doit la renouveler. Le fonctionnement du réseau seul ne démontre pas celui de l’identité.

Un serveur LDAP se configure avec son adresse, son attribut d’identification, le Distinguished Name et la méthode de bind. Ces paramètres déterminent où et comment les comptes sont recherchés. Un attribut mal choisi ou une base de recherche trop limitée peut ressembler à un mauvais mot de passe.

La documentation recommande LDAPS pour sécuriser le transport et un compte de bind au moindre privilège. Vérifiez la confiance des certificats et la connectivité vers le serveur. N’utilisez pas un compte administrateur du domaine comme solution de facilité à un problème de droits de recherche.

FortiGate agit comme client du serveur RADIUS. Le serveur doit accepter ce client ; les profils et secrets doivent correspondre. L’authentification RADIUS peut être utilisée dans plusieurs fonctions FortiGate, mais cette révision porte sur son association à des utilisateurs ou groupes et aux politiques.

Confrontez la réponse du serveur aux règles de groupe. Un résultat positif d’authentification ne vérifie pas tous les critères d’autorisation réseau. Consignez les propriétés nécessaires au scénario et les événements côté serveur, sans publier les secrets ou les données nominatives.

FortiOS distingue les timeouts idle, hard et session. Idle dépend de l’inactivité, hard d’une durée écoulée et session laisse certaines sessions existantes poursuivre leur fonctionnement tout en imposant une nouvelle authentification aux nouvelles. Cette distinction explique des symptômes apparemment contradictoires.

Pour la recette, utilisez un utilisateur autorisé puis un utilisateur exclu du groupe. Comparez une session existante et une nouvelle communication après le délai choisi. Reliez l’identité connue, le groupe appliqué et la politique observée avant de modifier les durées d’authentification.

Construire un scénario avec un groupe autorisé et un groupe refusé. Distinguer la vérification de l’identité, l’appartenance au groupe et l’autorisation réseau.

Pour terminer, formulez votre résultat attendu, les observations relevées et une hypothèse alternative si le résultat diffère. Conservez la version du produit et le contexte de test avec vos notes de laboratoire.