Windows Server 2008 - Network Access Protection, intégration avec l'infrastructure réseau.
Au cours des précédents posts nous avons regardé à quels objectifs s'attachait à répondre NAP, puis ses grands principes de fonctionnement ainsi que les possibilités en terme de gestion des environnements composés de clients Linux, Unix et Mac OS, dans le présent post nous allons nous intéresser aux possibilités ainsi qu'aux contraintes liées à l'intégration des éléments réseau.
Sachant d'une part que l'interaction entre le client NAP et l'élément réseau repose sur une authentification 802.1x de type EAP et que d'autre part l'interaction entre l'élément réseau et le serveur NPS repose sur une l'échange de messages RADIUS Access Request/Response
Les pré requis liés aux éléments réseau sont les suivants:
1/ L'élément réseau DOIT ABSOLUMENT supporter de relayer une authentification EAP vers un serveur RADIUS
2/ L'élément réseau DOIT ABSOLUMENT supporter un mécanisme de ségrégation du trafic réseau, ex: VLANs ou filtres (ACLs)
3/ L'élément réseau DOIT ABSOLUMENT supporter l'assignation de ports (cas d'un switch) ou de connexions clients (cas d'un concentrateur VPN) au sein de VLANs ou de sous-réseaux via des attributs Radius (Vendor-ID) lors de l'authentification (ou de la réauthentification)
4/ IL EST RECOMMANDE que l'élément réseau supporte l'assignation des clients qui ne supportent pas 802.1x d'un accès de type "Guest"
5/ IL EST RECOMMANDE que l'élément réseau supporte l'assignation des clients qui ne sont pas authentifiés avec succès d'un niveau d'accès restreint
Maintenant vous savez tout ce que vous devez savoir d'un point de vue technique mais en même temps vous ne savez pas ce qui vous intéresse probablement le plus... à savoir avec qui ça marche... la suite c'est cet exemple de conversation quasi réel
Parfait, parfait, parfait mais est-ce que cela signifie que mes éléments réseau répondent aux contraintes ?
Bonne question (c'est une technique de communication qui a fait ses preuves que de toujours reconnaitre à la personne qui soulève une question à la quelle on n'a pas la réponse qu'elle est bonne ou intéressante, cela permet d'enchainer sur une mauvaise réponse) Ca dépend...
Ca dépend de qui ? de quoi ?
De votre fournisseur et probablement aussi du/des modèles utilisés
Vous pourriez être un peu plus explicite ?
Oui, bien sur voici la liste des constructeurs (et les modèles) avec lesquels nous testons NAP de manière régulière dans nos labs
Et les autres ils ont aussi des offres semblables à la votre, dans quelle mesure sont-elles compatibles ?
Nous travaillons afin de nous assurer au NAP puisse s'intégrer avec les investissements que vous avez pu réaliser, voyez pour cela nos accords avec CISCO sur l'interopérabilité NAP-NAC ainsi que nos accords avec le TNC sur l'interopérabilité NAP-TNC et la standardisation du format SoH et enfin la liste des partenaires NAP.
Ce post conclut (pour l'instant) la série consacrée à NAP, j'espère vous avoir donné un bon aperçu et vous donne rendez-vous prochainement pour un nouveau sujet.