Le Network Policy Server

un proxy RADIUS pour fournir le routage des messages RADIUS entre les clients RADIUS (les serveurs d’accès) et les serveurs RADIUS qui effectuent l’authentification, l’autorisation et l’enregistrement de la tentative de connexion.

Le NPS peut aussi être un serveur RADIUS pour effectuer l’authentification, l’autorisation et l’accounting des clients RADIUS. Un client RADIUS peut être soit un serveur d’accès réseau soit un proxy RADIUS. Quand le NPS est utilisé en tant que serveur RADIUS, il fournit un service central d’authentification et d’autorisation pour toutes les requêtes d’accès et un service de journalisation pour toutes les requêtes effectuées par les clients RADIUS.

Les clients RADIUS peuvent être des serveurs d’accès réseau (NAS, Network Access Server), qui sont n’importe quel élément fournissant un accès à un réseau plus grand. Un NAS utilisant une infrastructure RADIUS est aussi un client RADIUS, envoyant des requêtes de connexion et des journaux de requêtes au serveur RADIUS pour authentification, autorisation et enregistrement. Les serveurs DHCP, VPN et Terminal Services Gateway doivent aussi être déclarés comme clients RADIUS dans NPS. Les ordinateurs clients, comme les ordinateurs portables ou autres ordinateurs, ne sont pas des clients RADIUS.

Les stratégies d’authentification et d’autorisation forment un ensemble de règles ordonné définissant si le NPS doit traiter la requête localement ou la relayer. Chaque stratégie est composée d’une à N conditions et d’un ensemble d’actions. Les conditions peuvent être par exemple l’IP du client RADIUS, le type de tunnel VPN ou l’horaire, tandis que les actions peuvent par exemple être la configuration d’une variable locale, une modification d’attributs ou juste l’accounting de la requête. Intéressons-nous maintenant aux stratégies. Les stratégies NPS forment un ensemble ordonné traité de manière séquentielle.

Une seule et unique stratégie s’applique à un client. Tant qu’un client ne correspond pas à une stratégie, on passe à la stratégie suivante, jusqu’à la stratégie par défaut. Par exemple : Si la machine appartient à un groupe d’exception (stratégie 1), alors on autorise un accès complet. Sinon, on passe à la stratégie suivante : si la machine est en bonne santé (stratégie 2), alors on autorise un accès complet. Sinon, on passe à la stratégie suivante : si la machine est compatible NAP mais pas en bonne santé, alors on la place dans un réseau restreint et on lui pousse les mises à jour. Sinon, on tombe sur la stratégie par défaut : on la place dans un réseau restreint.

On l’a vu, les stratégies d’autorisation sont composées de conditions et d’actions. On peut sélectionner des machines NAP, uniquement elles, ou uniquement des machines non-NAP. Puis on va sélectionner le SHV devant évaluer l’état de santé du client, et sa valeur de retour. On peut mettre des exceptions, par exemple pour exempter certaines machines il est nécessaire de créer une stratégie et de l’associer à un groupe de sécurité spécifique auquel sont ajoutées les machines.

Au niveau des actions, on peut choisir le niveau d’application : ne pas appliquer, ou appliquer et restreindre l’accès des postes non conformes, avec éventuellement un délai de grâce défini pour permettre la mise à jour des postes non conformes. On définit également des serveurs de remédiation, qui indiquent les ressources auxquelles les clients avec un accès restreint peuvent accéder.

Enfin, on peut préciser une « URL help » pour fournir des informations aux clients avec un accès restreint, et accessible via l’interface du client NAP. On configure également le System Health Validator, en choisissant si on veut qu’il vérifie qu’un pare-feu est activé pour toutes les connexions réseau, si un antivirus est installé et à jour ou non, ou encore si les mises à jour automatiques sont activées. On peut également choisir si on met en quarantaine un poste suivant l’importance des mises à jour de sécurité non installées.