Le VPN FortiGate atterrit dans le mauvais groupe : correspondance RADIUS

La connexion réussit, le tunnel monte et l’utilisateur atterrit sur la mauvaise politique, voire sur aucune. Rien dans le journal FortiGate n’annonce que le groupe manquait, car de son côté l’authentification a fonctionné et la correspondance de groupe ne s’est tout simplement pas déclenchée. La chaîne à inspecter contient trois noms distincts, et ce n’est généralement pas la même chaîne.

Trois noms, trois rôles

Notez les trois avant de toucher à la moindre configuration, car deux d’entre eux vivent sur des systèmes différents.

Le groupe d’annuaire est ce que votre politique RADIUS évalue. L’attribut renvoyé est une valeur à l’intérieur de la réponse Access-Accept. Le groupe local FortiGate est un conteneur auquel la politique fait référence par son nom. Confondre deux de ces éléments produit une connexion qui fonctionne et une autorisation qui ne fonctionne pas.

Où la correspondance se fait réellement

L’ explication de la correspondance des groupes RADIUS de Fortinet indique Fortinet-Group-Name comme attribut de groupe par défaut. FortiGate compare le serveur distant configuré et la valeur du nom de groupe à ce que porte la réponse, ce qui signifie que la comparaison se fait sur la chaîne renvoyée, et non sur l’étiquette affichée de votre groupe local.

C’est pourquoi un groupe local nommé VPN-Engineering peut côtoyer une valeur renvoyée vpn-engineering et ne correspondre à rien du tout. La casse et l’orthographe ne sont pas cosmétiques dans cette comparaison. Choisissez une chaîne, utilisez-la dans la réponse et référencez la même chaîne dans la règle de correspondance de la passerelle.

Sur FortiAuthenticator, le groupe doit être associé à l’attribut et inclus dans la politique de service RADIUS correspondante, avec le contrôle de retour de l’attribut de groupe activé le cas échéant.

La réponse peut réussir sans l’attribut

Pour NPS ou un autre serveur RADIUS, imposez la condition de groupe d’annuaire dans la politique, puis configurez l’attribut de réponse pris en charge. Une vérification de mot de passe réussie produit à elle seule un Access-Accept, et un Access-Accept sans chaîne de groupe est une réponse parfaitement valide qui n’autorise rien du côté FortiGate. C’est la forme la plus courante du problème.

Définir un groupe n’est pas la même chose que l’envoyer. Ce sont deux étapes de configuration sur deux écrans différents, et une seule est généralement faite.

Pourquoi la correspondance avec Any est un piège

Une correspondance de groupe distant Any est une conception légitime lorsque le serveur RADIUS admet déjà exactement la population que vous voulez. Choisissez cette délégation délibérément. Élargir la correspondance pour faire disparaître un attribut manquant admet tous les comptes que le serveur RADIUS accepte, y compris ceux qui n’auraient jamais dû avoir accès au VPN. Le symptôme disparaît et le contrôle d’accès cesse discrètement d’exister.

Si vous ne pouvez pas nommer qui le serveur RADIUS est censé admettre, vous n’êtes pas prêt pour une correspondance Any.

Conservez quatre enregistrements pour le support

Quand cela ne fonctionne toujours pas, rassemblez quatre éléments : la politique RADIUS sélectionnée, l’attribut de groupe réellement renvoyé, le serveur FortiGate et la valeur à laquelle il a été comparé, et le groupe local résultant. Ces quatre enregistrements localisent la rupture sans exposer de mots de passe ni modifier l’appartenance aux groupes pour voir ce qui se passe.

Testez un compte autorisé et un compte hors périmètre selon la règle réelle, et vérifiez la politique et l’accès aux ressources qui en résultent, ainsi que le résultat de l’authentification. Seule la paire vous dit si la correspondance fait ce que vous croyez.