Ajouter un utilisateur à un groupe VPN ne donne pas l’accès à lui seul

Le compte est dans le bon groupe, la connexion a réussi, et la passerelle refuse toujours, ou la session ne mène à rien d’utile. Le réflexe est d’ajouter des groupes jusqu’à ce que quelque chose cède, et c’est ainsi qu’on accorde bien plus que demandé. L’appartenance est une entrée de la décision d’autorisation, jamais la décision : la passerelle rassemble des faits sur la session, les compare à une politique ordonnée, puis décide. Si une autre condition a échoué, changer le groupe ne change que votre exposition.

L’appartenance à un groupe est une condition, pas une autorisation

Dans RADIUS, le groupe arrive comme attribut d’autorisation, et les attributs décrivent la session au lieu de l’accorder. Le serveur répond Access-Accept ou Access-Reject ; en cas d’acceptation il peut joindre Filter-Id, Class ou les attributs de tunnel de RFC 2868, que l’équipement d’en face interprète selon son constructeur. Rien dans le protocole ne transforme un groupe en accès complet : cette correspondance est écrite par celui qui a configuré la politique sur la passerelle ou le serveur d’accès réseau.

Voilà pourquoi un même nom de groupe se comporte différemment sur deux systèmes. Microsoft NPS compose ses politiques à partir de conditions, de contraintes et de réglages, évaluées dans un ordre défini. OpenVPN Access Server a son propre modèle de groupes et de règles, tandis qu’un serveur OpenVPN communautaire délègue souvent la question à un script client-connect ou à client-config-dir. Chacun consomme un groupe ; aucun ne partage la logique de priorité de l’autre.

C’est la règle qui a correspondu qui décide, pas le groupe attendu

La plupart des moteurs s’arrêtent à la première politique correspondante ou à la plus précise. Si la politique 3 refuse et la politique 7 autorise, la session peut échouer sans jamais atteindre la règle qui l’aurait laissée passer. L’ordre est un vrai réglage sur NPS et sur la plupart des produits de contrôle d’accès, et il dérive avec les années.

Les conditions qui accompagnent le groupe forment l’autre moitié. Posture de l’appareil, méthode d’authentification, MFA terminée, réseau source, sujet du certificat ou plage horaire peuvent figurer dans la même politique. Si l’une manque, la politique ne correspond pas, le moteur passe outre, et le refus par défaut s’applique. Du siège de l’utilisateur, le groupe semble ignoré ; du siège du moteur, il n’a jamais été consulté.

Les détails d’annuaire créent la même illusion. Une politique fondée sur l’appartenance aux groupes Windows lit les SID du jeton, où seuls les groupes de sécurité sont énumérés : un groupe de distribution n’apparaît jamais. Le groupe principal vit dans son propre champ, donc une politique qui s’y accroche peut échouer en silence.

Lisez l’enregistrement d’acceptation ou de refus avant de toucher à un groupe

Posez d’abord une question : la requête a-t-elle seulement atteint l’étape d’autorisation ? Sur NPS, la réponse est dans le journal, où 6272 note un accès accordé, 6273 un refus et 6274 une requête écartée avant l’évaluation. Ces trois nombres séparent trois enquêtes, et une seule concerne les groupes.

Si le journal est hors de portée, interrogez le serveur directement. Une réponse sans Filter-Id ni attributs de tunnel signifie que le serveur juge la session banale et que la passerelle applique ses propres règles. Une réponse portant des attributs que le point d’application n’implémente pas est une autre panne : l’autorisation est passée et l’équipement a ignoré le résultat.

radtest alice 'password' 10.0.0.5 0 testing123

Comparez les attributs renvoyés à ceux que la passerelle documente, pas à ce que suggère le nom du groupe. Cette comparaison sépare souvent un problème de politique d’un problème d’application.

Un changement de groupe n’est pas rétroactif

Les attributs d’autorisation sont renvoyés une fois, à l’authentification. La passerelle les stocke sur la session et ne relit pas l’annuaire à chaque paquet : une session établie continue donc après le retrait d’un groupe, et une nouvelle peut échouer tant que l’ancienne vit.

Pour rendre le changement effectif, il faut une nouvelle décision d’autorisation, pas seulement des clés neuves. Là où le serveur prend en charge RFC 5176, une Disconnect-Request ou CoA-Request vers UDP 3799 force la réévaluation ; sinon, déconnectez le client et laissez-le se reconnecter. La renégociation rafraîchit les clés du tunnel et laisse le résultat d’autorisation intact.

Corrigez la condition, pas le groupe

Une fois la politique fautive connue, la réparation est mince : réordonner un refus qui masque l’autorisation voulue, ajouter la condition d’appareil ou de MFA manquante, ou écrire une règle étroite pour la ressource au lieu de promouvoir l’utilisateur dans un groupe qui en porte dix autres.

Une boucle courte garde le changement honnête :

• Reproduisez le refus avec le compte d’origine et notez l’ID d’événement avant de changer quoi que ce soit.
• Ne changez qu’un objet, ordre de politique, condition ou groupe, et notez lequel.
• Ouvrez une session neuve, vérifiez que l’autorisation apparaît au journal et que la ressource s’ouvre vraiment.
• Testez un utilisateur qui doit rester refusé, pour vérifier que le correctif n’a pas élargi la politique.

Si l’autorisation est correcte et la ressource fermée, le problème a migré vers le routage ou la résolution de noms dès l’instant où l’autorisation est passée. Séparez ces deux pannes et le prochain ticket prendra des minutes, pas un après-midi.