La stratégie de groupe NPS n’est pas l’application des ressources VPN

Deux groupes, deux profils d’accès, une passerelle VPN, et au final les deux groupes atteignent les mêmes serveurs. La raison habituelle n’est pas une stratégie cassée mais une seconde moitié absente de la conception : NPS décide qui peut établir une session, et autre chose doit décider ce que cette session peut atteindre. Quand seule la première moitié existe, l’autorisation réussit pour tous ceux qui s’authentifient. La stratégie fait son travail, et la conception reste incomplète.

Une stratégie réseau correspondant à un groupe est une preuve d’admission. Ce n’est pas une preuve quant aux paquets, et l’écart entre ces deux affirmations est là où se déroule l’essentiel de ce travail.

Trouvez la stratégie qui a réellement admis la session

NPS évalue des stratégies réseau ordonnées, et la première règle activée dont les conditions correspondent l’emporte. Les conditions peuvent inclure l’appartenance à un groupe d’utilisateurs ou d’ordinateurs, le type de connexion, l’heure et l’état de l’appareil. Une stratégie large placée plus haut dans la liste admet donc une connexion avant qu’une règle plus étroite située plus bas ne soit même examinée. L’ordre n’est pas un détail de l’interface ; l’ordre est la stratégie.

Lisez la liste dans l’ordre et identifiez celle qui a correspondu, puis notez quels paramètres elle a renvoyés. Le nom du groupe dans l’éditeur n’est pas le résultat ; le résultat est l’autorisation que le serveur a reçue. Gardez séparées l’autorisation utilisateur et l’autorisation d’appareil là où le déploiement utilise les deux, car un compte autorisé à ouvrir un tunnel n’est pas automatiquement un compte qui devrait atteindre chaque service interne.

La réponse RADIUS est une instruction, pas un filtre

Un attribut Filter-Id porte le nom d’une liste de filtres. Il ne transporte pas un ensemble portable de règles de filtrage de paquets que chaque destinataire comprendrait, et envoyer un nom que la passerelle n’a jamais défini n’applique absolument rien. La même prudence vaut pour les attributs VLAN : affecter une session de tunnel à un VLAN n’est pas, en soi, une règle d’accès routée pour cet utilisateur.

C’est ici qu’une conception qui semble complète côté NPS ne fait silencieusement rien. Vérifiez dans la documentation du fournisseur de la passerelle quels attributs d’autorisation sont pris en charge et ce que le destinataire fait de chacun, au lieu de supposer qu’un nom d’attribut standard implique un comportement standard.

Placez l’application là où passe le trafic

Une passerelle qui traite les paquets de l’utilisateur peut appliquer un filtre par session, associer un groupe à une stratégie de passerelle ou remettre à la session une adresse issue d’un pool séparé qu’un pare-feu traite différemment. Chacune de ces options peut fonctionner, et elles échouent de manières différentes. Déterminez quel mécanisme votre passerelle prend en charge avant d’écrire la stratégie qui le nomme. Notez ensuite ce qui arrive à une session quand ce mécanisme est absent, car le silence est la valeur par défaut.

Décrivez l’autorisation visée en quatre parties: identité de source ou groupe, destination, protocole et port. Ajoutez les dépendances dont l’utilisateur a réellement besoin, comme DNS ou un service d’authentification, sinon la restriction cassera des flux de connexion que personne n’a pensé à tester. Écrivez la règle contre l’interface qui filtre réellement, pas contre l’interface qui se trouve ouverte dans l’éditeur.

Tenez compte aussi de la traduction d’adresses. Si un pare-feu en aval voit une seule adresse source traduite pour chaque utilisateur du tunnel, il ne peut pas distinguer les individus à partir de cette seule adresse, et une règle écrite comme s’il le pouvait sera soit inutile, soit trop large.

Les profils clients vivent du côté non fiable

Un profil VPN géré peut pousser des routes, des règles de tunnel partagé ou des filtres d’applications, et ceux-ci façonnent le comportement d’un appareil bien élevé. Ils ne protègent pas le service, car le client est la partie que vous cherchez à contraindre. Retirer une route d’un profil n’est pas non plus une autorisation, puisqu’un client peut disposer d’un autre chemin vers la même destination.

Traitez les paramètres du client comme un confort et ceux de la passerelle comme un contrôle. Quand les deux sont en désaccord, la passerelle a raison, car c’est elle qui voit les paquets.

Acceptez avec deux comptes, puis suivez dans l’ordre

Créez deux comptes de test ordinaires avec des permissions visées différentes, établissez de nouvelles sessions et vérifiez la stratégie effective de la passerelle pour chacun. Testez ensuite une opération autorisée inoffensive et une ressource spécifiquement refusée. Un ping qui échoue prouve très peu à lui seul, car ICMP peut être filtré tandis que le service TCP derrière répond volontiers.

Quand les deux comptes obtiennent encore un accès large, suivez un ordre fixe : quelle stratégie a correspondu, quelle autorisation la réponse portait et ce que la passerelle en a fait. Ajouter davantage d’attributs NPS avant de confirmer que le destinataire les implémente est la façon dont un petit problème d’autorisation devient une fenêtre de changement sans résultat.