Archives de catégorie : NAP

RIP Network Access Protection, miss you

Windows 10 just been released a month ago. Because I do not have enough time to actively participate to the insider phase, I did not yet tested with DirectAccess. Off course, it’s working. But there are a few changes some good, one bad. Let’s start with the bad one. My old friend Network Access Protection passed away.

If you have a look at the DirectAccess Unsupported Configurations, Network Access Protection was deprecated since Windows Server 2012 R2.

clip_image001

 

It was still included in Windows 7 / 8.1, but in Windows Server 2012 R2, it was the last Microsoft operating system that included Network Access Protection. If you have a look at your Windows 10 computer (Enterprise SKU off course), you will discover that’s true, the Network Access Control agent no longer exists.

clip_image002

 

And it’s the same on DirectAccess gateway. Even if we are on Technical Preview Stage, NAP integration with DirectAccess was removed. The Network Access Protection Checkbox was removed.

clip_image003

 

Why Microsoft removed Network Access Protection?

  • It was an old approach

Do you have an idea when NAP was introduced? With Windows Vista and Windows XP SP3. So more than a decade. During this decade many things changed. Something called Cloud emerged.

  • It was designed to protect LAN

Network Access Protection was designed du protect corporate networks from rogue computers and unsecured computers. At cloud era we need compliance enforcement anywhere.

  • Compliance definition changed

With NAP, compliance expression was limited to five criteria configured to true of false. Developing complex compliances policy was not easy. Even if we were able to extend with Desired Configuration Manager from SCCM, we were limited to Windows Devices

  • It was limited to Windows devices

At Vista time, company had very limited choices for devices. Vista introduced the first generation of tablets. Today we are at the BYOD era. Company must be able to manage any device, from Microsoft to IOS and even Android. Yes some partners were able to manage MACOS & Linux, but it’s not built-in.

  • It was complex to setup

That was the pain point. NAP was a combination of multiples technologies. If perfectly assembled, it was working like a charm.

 

How can we manage compliance with Windows 10 devices?

  • At the cloud era, response is simple : Windows Intune. We cannot rely on MDM capabilities provided by Office 365 because it does not include Windows devices
  • With Windows Intune we have the Extensible Windows PC Devices Configuration Settings that allow to perform WMI check and even registry key checks. We were not able to achieve this with Network Access Protection without DCM.
  • We can use App Compliance policies to restrict access to application (was very difficult to achieve with Network Access Protection)
  • We can use Selective Wipe to managed stolen DirectAccess enabled devices

Yes Windows Intune is not built-in Windows 10 Operating system generation, but things changed so much since introduction of Windows Vista.

RIP Network Access Protection, miss you.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Mais pourquoi mon HRA refuse t’il de s’installer?

Il y a des jours quand ça veux pas, ça veux pas. Voila le me message d’erreur que j’ai obtenu lors de l’installation d’un Health Registration Authority sur une plateforme Windows Server 2008 R2 française. Premier reflexe, la localisation. Mes récentes expériences avec Orchestrator m’ont démontré la subtilité qui existe entre des produits globalisés versus localisés. Dans mon cas, l’interface graphique ne nous donne pas beaucoup d’informations sur la nature de l’erreur. Par contre, il m’indique que l’installation de sous-rôles ou rôles complémentaires a elle échouée et qu’il est nécessaire de redémarrer.

clip_image001

Après avoir exclue la cause française (problématique reproduite sur plateforme full US), j’attaque une approche dichotomique (non, je ne fais pas de développement, juste de la recherche d’erreur de la manière rationnelle). Pour faire simple, installer manuellement chaque rôle, sous-rôle et fonctionnalité jusqu’à tomber sur celle qui pose problème. A première vue, c’est bien le HRA. Cette fois l’erreur est plus précise (détail recherches sur le code erreur). On avance, on a un code erreur, c’est déjà mieux.

clip_image002

Tous les autres composants ou sous-composants se sont bien installés. Il faut aller plus avant dans les logs du composant ServerManager. Allons donc faire un tour dans le fichier « C:\Windows\Logs\ServerManager.Log ». Le code erreur affiché dans la console ne nous aide pas. Une rapide consultation de votre moteur de recherche ne nous fournira pas de piste spécifique. Remontons donc la liste dans le fichier de log.

clip_image004

On retrouve bien l’information. Elle vient même du composant Component Based Servicing (CBS) qui est plus connu sous le nom de Trusted Installer. Allons donc faire un tour dans le fichier journal de ce composant : « C:\Windows\Logs\CBS\CBS.Log ». En remontant le fichier de journalisation en partant de la fin, on arrive bien à identifier que le problème vient bien du package « Microsoft-Windows-HealthCertificateServer-RunTime ».C’est bien le HRA, plus précisément un package particulier. Est-il corrompu? Nan, c’est beaucoup plus simple. Ce n’est pas non plus un problème de quota comme l’indique le fichier de journalisation.

clip_image006

La réponse est quelques lignes au-dessus. De belles commandes « APPCMD.EXE » pour assurer la création des répertoires virtuels « DomainHRA » et « NonDomainHRA ».

clip_image008

Ce sont ces commandes qui ne passent pas. A tout hasard, j’ouvre une invite de commande MS-DOS pour tenter de les exécuter manuellement pour finalement me rendre compte de ce qui manque. Et si mon site web par défaut n’existait tout simplement pas? Bingo, dans mon cas, ce n’est pas qu’il n’existe pas mais qu’il a été renommé (des normes applicatives, toujours des normes applicatives, …). Ben celle-là elle ne passe pas. Le processus d’installe ignore le fait qu’on puisse renommer le « Default Web Site ». Une fois le site renommé, le HRA s’installe tout seul.

clip_image009

Un petit tour rapide dans la console « Gestionnaire des services Internet (IIS) » pour vérifier la présence de mon répertoire virtuel. C’était bien cela.

clip_image011

Conclusion : Quand on vous dit que l’installation du serveur est « fresh out of the box », premier réflexe ne rien en croire et vérifier plutôt deux fois qu’une. C’est comme les projets qui se déroulent sans problème, c’est de la science-fiction.

 

Note : le processus d’installation du HRA n’est pas un cas isolé. Il existe d’autres produits Microsoft pour lesquels la présence du site web par défaut est nécessaire pour que le processus d’installation se déroule normalement.

 

BenoîtS – Simple and Secure by Design but Business compliant

DirectAccess Challenge Series : NAP strategy based on location

What Changed with Windows Server 2012?

With Windows Server 2008 R2, yon can configure NAP enforcement. NAP deployment is under your responsibility. With Forefront UAG 2010, Network Access Protection configuration can be performed by the UAG wizard and host the Health Registration Authority on the server.  But with Windows Server 2012, there is a small change documented here :

image

 

It’s no longer supported to host the Health Registration Authority with the (URA) Unified Remote Access role. This means we have two solutions. Having the HRA published on Internet or using an internal HRA. For the first solution have a look at this post from the cable Guy (aka Joseph Davies author of the Understanding IPV6 book series). For the second solution, let’s go deeper into NAP.

 

Back to the NAP roots

Technically speaking, its not a problem to combine DirectAccess with NAP. URL corresponding to the HRA must be reachable through the first IPSEC infrastructure tunnel. First, we must enable Network Access Protection at DirectAccess Level :

ENABLENAPINTERFACE

 

In Picture above, we see that enabling Network Access Protection is just a checkbox, but this checkbox is available only if you are using computer certificates for tunnel authentication. Deploying DirectAccess without certificate is a cool feature for quick deployment but if you want extra-cool feature, don’t forget to select an internal CA that will be providing certificate to be used for tunnel authentication .

 

If you want to know, the “Enforce corporate compliance for DirectAccess clients with NAP” status just run a Get-DAServer Powershell as illustrated bellow :

GETDASERVERHEALTHCHECK

 

When Network Access Protection is enabled, some small “changes” are performed into the DirectAccess Policy-DaServerToCorp connection Security Rule (on server-side). Let’s have a look in with an “old–school” way based on NETSH.EXE.

SHOWNAPDACONFIG

 

A specific certificate delivered by the Health registration Authority is required for user-tunnel establishment. This means that HRA URL must be reachable from the first IPSEC tunnel. For this reason, we must add this URL to the infrastructure server list.

APPSERVERSLIST

 

Is is possible to use a single internal HRA?

Technically speaking it’s not a problem. You can have a single HRA but remember one thing. URL will be reachable from DirectAccess clients located on Internet but also DirectAccess clients connected on Intranet. That’s a big (bug?) change. In a DirectAccess project, you expect to have computer compliance checking for External clients, but you may not expect to apply the same compliance criteria for all computers. Unless you are engaged in a global computer compliance enforcement project, you have a problem. It would be great to have different NAP policy based on your location (Internet/intranet). Let’s have a look at NAP filtering capabilities.

 

Network Access Protection filtering capabilities

Let’s have a look at some Network Access Protection Design considerations :

image

 

The only way we have to filter  a DirectAccess client from another from the NAP Point of view is the RADIUS client option. This means, that DirectAccess clients will use a dedicated HRA and internal clients will use another HRA. These two HRA will be considered as Radius clients from a central Network Policy Server that will use the Access Client IPv4/6 address condition. Technically speaking, that might be a solution but :

  • How can we be sure that a computer connected on Intranet will not use HRA dedicated to DirectAccess clients connected on Internet?
  • And more important, how can we be sure that a DirectAccess client connected on Internet will not use HRA dedicated to internal clients?

 

The Multiple NAP Challenge made simple

Specialize Health Registration authorities based on computer security level is a good option. Scenario explained before is technically possible, just complex to setup in a small DirectAccess deployment. The real challenge is how to be sure that NAP enabled client will always use the good HRA. DirectAccess have a solution for that. It’s always a question of name resolution capabilities.

 

In my scenario, I will dedicate a NPS/HRA to intranet clients and another one to Internet clients. Each NPS will have it’s own configuration (I said simple ). NAP enabled computers (DirectAccess or Not) will  be able to use a HRA based on their location (Intranet/Internet).

 

First we need to be sure that DirectAccess clients connected on Internet cannot reach HRA dedicated to Intranet clients. With DirectAccess, we have built-in host resolution blocker capabilities : Name Resolution Policy Table :

NRPTCONTENT

 

If I block name resolution for my internal HRA URL (HRALAN), I’m sure that DirectAccess clients will never be able to use it when connected on Internet. Great thing. But we also need that internal clients cannot resolve DNS host name for the DirectAccess Dedicated HRA (HRADA).

That’s more tricky. In my scenario, I consider that my DirectAccess infrastructure is located on a specific network in DMZ. For security reason, servers in this network can only use Read-Only domain Controllers located in the same network. So internal clients use  different DNS servers. In this case, I will use another host resolution blocker capability : DNS GlobalQueryBlockList. In illustration bellow, you can see the content of the GlobalQueryBlockList I configured on all DNS servers located on Intranet :

DNSCMDINFO

 

We can see the standard WPAD and ISATAP host blocked for DNS resolution. The HRADA host is my HRA dedicated to DirectAccess clients. If I add it to the GlobalQueryBlockList, I’m sure that clients connected on Intranet will never be able to reach it.

 

And last NAP client configuration. All my NAP clients will share the same Trusted Server group List including all HRA available in my environment (simple by design ).

NAPCLIENTCONFIG

 

DirectAccess clients connected on Internet will only be able to resolve “HRADA” hostname. Internal clients (DirectAccess enabled on not) will be able to resolve “HRALAN” only.

 

How fast is it to switch from an HRA to another?

Good question, after some tests on my lab and performing some research, I found the solution here : http://technet.microsoft.com/en-us/library/dd125359(v=ws.10).aspx

image

 

Since Windows Server 2008 R2 the initial timeout for HRA response is four seconds. If you add DirectAccess tunnel negotiation and network latency, I would be up to forty seconds when a DirectAccess clients connected on Intranet network switch to Internet network.

 

BenoîtS – Simple and secure by Design but Business compliant

Troubleshooting NAP with DirectAccess

These days, I spend most of my work time with DirectAccess and Network Access Protection (including night!). During A Poc, I was surprised to see a NAP client considered as compliant unable to access the internal Network. Problem, by default NAP client is not configured to trace relevant events. The Group Policy generated by Forefront UAG does not include this option. A little NETSH.EXE magic command can solve this problem :

NAPTRACING

 

Once tracing is activated, I was able to find the following event. NAP client is considered as compliant, but cannot get a certificate from the Health Registration Authority.

HRABUG0

 

Let’s keep in mind that Correlation ID and try to find a corresponding event in the SYSTEM log of my UAG box that is also my HRA. And I can find an event with the same correlation ID. And now the problem appears : 0x80070005, witch is the nick name for Access Denied!

HRABUG1

 

My Health registration does not have the required privileges in order to submit the System Health Authentication certificate. Hera are the good permissions.

HRABUG2

 

Don’t forget to restart the Certificate Services services to make the new permissions operational. Keep this URL in the bookmark of your favorite browser : Network Access Protection Troubleshooting guide.

 

DirectAccess project rule n°1 : always check prerequisites twice, it’s never enough!

 

BenoitS – Simple and Secure by Design but Business compliant

Network Access Protection et au Delas!

Network Access Protection est une brique présente depuis Windows 2008.  NAP doit être considéré comme une plateforme de gestion de la conformité qui est extensible.

image

 

Pour preuve, un produit tel que Forefront UAG vient y mettre son grain de sel avec un nouvel “enforcement client”. Depuis Windows 2008 R2, Network Access Protection est capable de proposer et gérer plusieurs stratégies de conformité.

 

La capacité à intégrer d’autres solutions et proposer plusieurs niveaux de conformité permettent de développer des nouveaux scénarios dans le domaine de la gestion de la conformité du poste de travail en entreprise.

 

Le cas du partenaire extérieur

C’est moi, ou plutôt nous tous qui intervenons chez nos clients respectifs. Se pose alors toujours la même problématique. Suis-je autorisé à connecter mon poste de travail au réseau? Lorsque la réponse est oui (Merci!), cela implique que notre poste de travail présente un certain nombre de garanties de sécurité tel que :

  • Pare-Feu
  • Antivirus
  • Antispyware
  • Mises à jour

 

Tout cela ressemble furieusement aux critères proposés par le System Health Agent de Windows. Dans le cas d’un scénario Network Access Protection basé autour de DHCP (ce qui est le cas le plus simple à mettre en œuvre), il suffit que je configure mon client NAP pour soumettre mon état de santé au travers de la méthode d’enforcement DHCP. Si je ne le fait pas, le serveur NPS va automatiquement me déclarer non conforme et me limiter fortement l’accès au réseau.

Le cas du poste d’entreprise

Dans le cas du poste d’entreprise, on attend de lui qu’il présente beaucoup plus de garanties. Pour les entreprises qui ont opté pour des antivirus et des pare-feu tiers, elles aimeraient en savoir un peu plus que les produits sont bien installés et opérationnel. Dans le cas des solutions McAfee, celle-ci présente l’intérêt d’être intégralement administrable au travers d’un ePolicy Orchestrator. Si on creuse un peu plus chez cet éditeur, on va trouver un produit nommé McAfee Network Access Control. C’est la solution de gestion de conformité de l’éditeur qui propose entre autre :

  • De reconfigurer le client NAC en client NAP (donc un SHA)
  • D’interfacer la gestion de remédiation avec en SHV

Coté client, l’agent McAfee Network Access Control est configuré pour opéré avec NAP. Cela signifie que le SHA de l’éditeur sera activé pour remonter les informations au SHV. Dans l’illustration ci-dessous, on constate que :

  • J’ai l’enforcement client DHCP actif
  • J’ai aussi l’enforcement client McAfee actif
  • Que mon poste n’est pas conforme

NAP0

On peut aussi constater que j’ai deux SHA :

  • Celui de Windows qui me dit que tout est conforme
  • Celui de McAfee qui me dit qu’il y a des problème.

NAP1

D’un point de vue Network Access Protection, on constate bien que mon poste n’est pas conforme. Ce qui manque, c’est le pourquoi.

NAP2

 

Le pourquoi on va le trouver dans l’agent NAC de McAfee qui nous indique que mon poste de travail d’entreprise présente une grave lacune, il n’a pas le pare-feu de l’entreprise. Pour cette raison, le poste de travail est considéré par NAP comme non conforme.

 

NAP3

 

Conclusion

Enrichir Network Access Protection avec une solution tierce est possible et présente un certain nombre d’avantages. D’une part, on peut simplement traiter le cas des partenaires extérieurs, et d’autre part, on dispose d’une plateforme unique pour gérer la conformité des postes de travail de l’entreprise.

La Méthode d’Enforcement DHCP de NAP travaille au niveau du client et non des équipements réseaux. C’est un premier pas vers la gestion de la conformité en attentant une refonte des réseaux d’agences pour intégrer des équipements réseaux supportant le 802.1.X et créer autant de VLAN de remédiation que de sites.

 

Grand merci à au consultant PHV dit “Pioupiou” grâce à qui j’ai pu travailler sur ce sujet. Suite à cet acte de bravoure il est élevé au rang de “PiouPiou Senior”.

 

Benoits – Simple and Secure by Design but Business compliant.

Guide de dépannage de NAP avec UAG DirectAccess

Tout frais, histoire de compléter la série des UAG DirectAccess Test Lab Guides, le guide de dépannage de NAP avec UAG DirectAccess. Pour ma part une bonne base de dépannage de NAP coté client pour écrire par exemple un guide d’exploitation de la solution.

 

Benoîts – Simple and Secure By Design (J’insiste sur le Secure)

Le contrôle de conformité et DirectAccess

C’est facile, c’est Network Access Protection. Oui, mais il manque une brique, à savoir le contrôle. Pour cela, encore faut-il être capable de collecter les informations nécessaires concernant DirectAccess (initialisation et fermeture des tunnels IPSEC) ainsi que les données en relation avec la conformité pour les exploiter.

 

C’est exactement ce que propose un article de Technet Magazine. Tout y est, depuis la collecte des données (avec LogParser.Exe), le stockage dans une base de données pour finir avec un rapport de conformité des clients DirectAccess.

 

Quelque part, c’est dommage que le reporting ne soit pas intégrée au rôle NAP.

 

 

Benoîts – Simple and Secure by Design ‘(J’insiste sur le Secure)

Subtilité de la Health Registration Authority

Pour ceux qui ont suivi la série “Network Access Protection”, il existe une subtilité que je n’avais pas encore traité.

 

Lors de la mise en œuvre du gabarit de certificats “System Health Authentication”, celui-ci étant basé sur le gabarit “Workstation”, il a donc repris ses caractéristiques principales dont entre autre :

  • La durée de vie
  • Son renouvellement

 

Dans une configuration par défaut du rôle ADCS tel que je l’avais présentée, il n’était pas possible pour le Health Registration Authority de demander un certificat pour une durée de vie autre que celle inscrite dans le gabarit (un an).

Pour adresser cette problématique, il faut autoriser à ce que les demande de certificats précisent une date de fin autre que celle inscrite dans le certificat. Ci-dessous la ligne de commande à exécuter sur l’autorité de certification :

EDITF_ATTRIBUTEENDDATE0

Le service doit bien évidemment être redémarré.

EDITF_ATTRIBUTEENDDATE1

Lorsque notre client obtient un nouveau certificat prouvant son état de santé, on constate immédiatement que sa durée de vie correspond bien à ce que demande le HRA, à savoir quatre heures :

EDITF_ATTRIBUTEENDDATE3

 

 

 

Sans cela, le client peut outrepasser les contrôles d’état de santé car son certificat était toujours valable, jusqu’au prochain redémarrage.

 

 

Benoîts – Simple and Secure by Design (J’insiste sur le Secure)

DirectAccess + NAP + Smartcard = La solution de mobilité la plus complète

L’équipe WSiXN (Windows Server Information Experience Networking) en charge entre autre de DirectAccess et NAP a enfin mis à disposition un guide de mise en œuvre de DirectAccess intégrant Network Access Protection. L’ensemble est assez complet, couvrant à la fois :

  • L’architecture de la solution globale
  • Sa mise en œuvre détaillée
  • Un guide de mise en œuvre pas à pas.

D’un point de vue purement technique, NAP est mis en œuvre selon le scénario du Health Registration Authority. A noter que ce HRA est localisé en interne, de préférence sur un serveur dédié afin de s’assurer qu’il soit accessible aussi bien par les clients conformes que non conformes.

Donc maintenant, en recombinant mes séries de billets (Les sujets n’avaient pas été choisit au hasard) : DirectAccess + Network Access Protection + Smartcard = La solution de mobilité la plus complète.  La solution est :

  • Transparente pour les utilisateurs
  • Propose une gestion de la conformité LAN/WAN
  • Sécurisée car reposant sur une authentification forte

Il ne faut pas croire qu’on a fait le tour de DirectAccess. Il nous restera pas mal de sujets à développer (haute disponibilité, scénarios IPV6, …). Il y aura donc encore pas mal de séries de billets en perspective.

Benoîts – Simple and Secure by Design (J’insiste sur le Secure)

Network Access Protection and IPSEC : épisode 8 et fin

Après une parenthèse causée un par l’indisponibilité du blog mais aussi par un projet tout aussi intéressant qu’accaparant, revenons à notre série en cours sur Network Access Protection. Pour ceux qui prennent la série à ce stade, l’infrastructure NAP est totalement opérationnelle. Nous en sommes maintenant à la mise en œuvre des mesures d’isolation.

 

Etant donné que les clients et le serveur NPS ont déjà été traités, il ne reste plus que notre fameux serveur secure.corp.windows2008R2.com pour lequel l’accès doit être restreint si la conformité du poste de travail n’est pas établie. Volontairement, le contrôleur de domaine ne fera pas l’objet de mesure d’isolation car même non conforme, j’ai tout de même besoin de m’authentifier.

 

Donc attaquons nous à notre serveur : secure.corp.windows2008R2.com. Son accès doit être exclusivement réservé aux clients ayant démontré leur conformité. Comme c’est le dernier article, je vais donc skiper certaines étapes considérant qu’elles ont été documentées dans les billets précédents (Je passe en mode fainéant, les vacances approchent, …).

 

Stratégie de groupe d’isolation

Comme pour les deux précédentes mesures d’isolation, on va ici encore travailler avec les stratégies de groupe. On commencera donc par créer un conteneur organisationnel pour les serveurs sécurisés pour y déplacer notre serveur.

SECURE0 

Ensuite, nous pouvons créer une stratégie de groupe pour gérer notre isolation. Nous l’appelleront “NAP Serveurs sécurisés”.Comme pour les autres, on va créer une stratégie d’isolation uniquement pour le mode “Domaine”, le seul qui nous intéresse.

ISOLATION31 

On N’oublie pas le “ping” pour aider au dépannage.

ISOLATION31 

Passons maintenant à la stratégie d’isolation à proprement parlé.

ISOLATION33 

Petite subtilité à ce niveau avec l’exigence d’authentification. Le serveur exigera l’authentification pour les connexions entrantes sans pour autant l’imposer pour les connexions sortantes. Sinon, notre serveur serait incapable de joindre le contrôleur de domaine. Si on voulait être plus que complet alors oui, on exigerait aussi l’authentification sortante mais cela imposerait de positionner aussi une stratégie d’isolation sur le contrôleur de domaine.

SECURE1 

Ici encore, c’est une méthode d’authentification avancée.

SECURE2 

Avec une méthode d’authentification basée sur un certificat, plus précisément un certificat d’état de santé.

SECURE3 

La règle d’isolation ne sera applicable que pour les interfaces de type “domaine”, ce qui est le cas de mon serveur sécurisé, membre de domaine.

SECURE4

Elle sera nommé” IPSEC Secure Rule”.

SECURE5 

Dès lors que la stratégie de groupe est liée au conteneur “Serveurs sécurisés” et que notre serveur a bien appliqué la stratégie de groupe, la magie de l’IPSEC va opérer, à condition que le serveur dispose d’un certificat de santé. Oups, il doit donc lui aussi être placé dans le groupe des exceptions NAP.

 

Des preuves

La meilleure preuve, c’est encore le client qui lui est refusé l’accès au serveur par ce qu’il n’est pas conforme à la stratégie imposée par le serveur NPS.

SECURE6

 

Pourtant, dès que le client remonte un état de santé convenable, il accède bien au serveur sécurisé avec ses données critiques.

SECURE7 

Conclusion

Voila pour Network Access Protection. C’est la fin d’une première plongée dans Network Access Protection. On se rend vite compte que l’infrastructure en elle même n’est pas très compliqué. On peut donc mettre en place NAP sans aucune mesure d’isolation. C’est d’ailleurs ma recommandation. De cette manière on arrive à collecter des informations sur la capacité des systèmes à se maintenir conformes. Par contre, cela deviendra nettement plus complexe dès lors qu’il faudra traiter des mesures d’isolation.

 

On n’a pas tous la chance d’avoir un environnement utilisant les dernières technologies. On a encore beaucoup de serveurs de génération antérieurs pour lesquels la mise en place de la mesure d’isolation est un peu plus complexe à mettre en œuvre. C’est cette phase du projet qui sera la plus complexe puisque selon l’exigence d’isolation définie, on peut en arriver à isoler le poste de tout le système d’information. On constate alors ici les limites de NAP IPSEC et l’intérêt que peut présenter NAP 802.1.x, pourvu que l’infrastructure réseau s’y prête.

 

Benoîts – Simple and Secure by Design (j’insiste sur le “Secure”)