Archives mensuelles : mai 2010

Authentication Assurance

Cette fonctionnalité est propre à Windows Server 2008 R2. Elle permet de détecter le type d’authentification utilisée pour l’ouverture de session. Plus précisément, cette fonctionnalité permet d’adapter le contenu du jeton Kerberos selon le type d’authentification.

 

Très concrètement, il est possible de détecter qu’un utilisateur a ouvert une session avec une carte à puce et non avec son compte utilisateur et d’en tenir compte dans l’accès à des ressources selon l’appartenance à un groupe donné. Dès lors que l’utilisateur a ouvert sa session avec sa carte à puce, il est membre d’un groupe spécifique, ce qui n’est pas le cas si l’utilisateur avait ouvert sa session avec son compte et son mot de passe.

 

Pré-requis

La fonctionnalité n’est disponible que sur les contrôleurs de domaine Windows 2008 R2, ceci implique un mode de domaine configuré au même niveau. Dès que cette contrainte a été levée, on peut s’attaquer à la mise en œuvre.

 

Une histoire de certificats

Tout se passera effectivement dans les certificats. Pour la base de travail, je renvoie vers ma série de billets sur la mise en œuvre de la carte à puce. Je vais donc me limiter aux seules différences avec une mise en œuvre classique. La subtilité consiste en la mise en place. Cela va se passer au niveau des extensions du modèle de certificat, plus précisément au niveau des Assurance Policies.

5

 

On va positionner la “High Insurance Policy”. C’est à celle-ci que l’on va associer le futur groupe de sécurité qui identifiera l’ouverture de session une carte à puce contenant ce certificat. Par défaut, on dispose déjà de plusieurs niveaux (high, medium, Low) mais il est possible de créer ses propres niveaux.

6

Une fois positionné dans le modèle de certificat d’authentification par carte à puce, on en a fini avec le personnalisation du gabarit de certificat.

7

 

Le coté obscur de l’Authentication Assurance

Le coté obscur, c’est qu’il n’y a pas d’interface graphique pour faire le lien entre l’”Insurance Policy” et le groupe de sécurité que l’on veut utiliser pour identifier l’ouverture de session par carte à puce. D’un autre coté, Microsoft a mit à disposition des scripts PowerShell pour faciliter la mise en œuvre. Ces scripts sont disponibles dans le guide de mise en œuvre de la fonctionnalité “Authentication Assurance”.

 

Microsoft met à disposition deux scripts :

  • Get-IssuancePolicy.ps1 : Permet d’afficher les lien entre les “Assurance Policy” est les groupes”
  • Set-IssuancePolicyToGroupLink.ps1 : Permet de configurer le lien entre les “Assurance Policy” et notre groupe de sécurité

 

Etant donné que nous allons travailler avec des scripts PowerShell, on va commencer par autoriser l’exécution de scripts. Par défaut, pour raison de sécurité, ce n’est pas autorisé.

10

Après, on va commencer par voir quels sont les associations déjà en place avec le script “Get-IssuancePolicy.ps1” et ce pour tous les groupes de sécurité.

11

le script a identifié qu’il y a trois “Assurance ¨Policy” déclaré dans la forêt Active Directory mais qu’il n’y a pas encore de lien avec un quelconque groupe de sécurité. En Parlant de groupe de sécurité, on va quand même penser à le créer ce groupe.

1

Levons maintenant un voile sur le coté obscur. Le lien entre l”Assurance Policy” et le groupe est déclaré dans la partition de configuration. L’information est stockée dans l’objet “Assurance Policy” (objet de type “msPKI-Enterprise-Oid”) et plus précisément dans l’attribut “msDS-OIDToGroupLink” dans lequel on doit stocker le DN du groupe.

 

Le script “Set-IssuancePolicyToGroupLink.ps1” va nous permettre d’établir le lien entre l’Assurance Policy “High Assurance” et le groupe de sécurité nouvellement créé.

12

Une fois l’opération réalisée, une nouvelle exécution du script “Get-IssuancePolicy.ps1” va nous confirmer que le lien est bien en place.

13

Et maintenant coté client

La différence entre une ouverture de session par compte/mot de passe et carte à puce doit être perceptible. Pour cela le plus simple consiste à comparer le résultat de l’exécution de la commande “WHOAMI /GROUPS” dans les deux cas sur le poste client.

LOGONSANSSMARTCARD

Voila pour une ouverture de session avec compte et mot de passe, passons maintenant à l’ouverture de session par carte à puce puisque c’est là que tout se joue.

LOGONAVECSMARTCARD

Immédiatement, on constate deux points. D’une part la présence du groupe spécial “AUTORITE NT\Ce certificat d’organisation”, qui identifier une ouverture de session par carte à puce. L’utilisateur a été positionné comme membre de ce groupe car il a ouvert une session avec une carte à puce contenant un des certificats autorisés pour cet usage, sans distinction.

 

Mais le point le plus intéressant reste la présence du groupe “HighInsurranceGroup” qui est présent dans la liste. C’est bien une ouverture de session par carte à puce mais pas n’importe laquelle mais contenant un certificat bien précis, celui que nous avons personnalisé.

 

Conclusion

Voila pour une mise en œuvre simpliste. Comme indiqué, il est possible de créer ses propres niveaux d’Assurance Policy, ce qui ouvre la porte à des scénarios plus qu’intéressants. Immédiatement, on peut penser à appliquer la fonctionnalité à DirectAccess pour forcer l’utilisation de la carte à puce pour accéder à certaines ressources sensibles de l’entreprise.

 

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

DirectAccess et la magie de la smartcard

DirectAccess + NAP + Smartcard = La solution de mobilité la plus complète. C’est vrai, encore fallait-il creuser un peu plus la chose. Commençons avec la carte à puce. Car mine de rien, c’est un véritable tour de magie.

 

Vue de haut

Lors de la configuration de ForeFront Unified Access Gateway 2010, ce n’est qu’une simple case à cocher mais dont on a du mal à déterminer comment elle sera mise en œuvre. Pour la case à cocher, pas de problème.

SMARTCARD0

 

Une fois la mise en œuvre terminée, on constate toujours la présence de trois stratégies de groupe dont une vide (elle est dédiée au mode Selected Server). Coté contenu, on n’arrive pas à voir la différence avec avant.

 

Coté client, on constate qu’il est toujours possible d’ouvrir une session sans la carte à puce. Conclusion, il n’y a pas d’obligation à utiliser la carte à puce pour l’ouverture de session au niveau du poste ou de l’utilisateur par défaut. C’est à nous de configurer cela. Pour cela, deux options :

  • Au niveau du compte de l’utilisateur
  • Au niveau du poste de travail

 

De mon point de vue, la première option est la plus intéressante car il est plus facile de la débrayer alors que la seconde oblige l’ouverture de session sur le poste.

 

Vue de l’utilisateur

Dès lors que l’utilisateur a ouvert une session, on verra rapidement apparaître l’interface ci-dessous dans la zone de notification :

SMARTCARD1

 

Elle nous invite à insérer notre carte à puce.

SMARTCARD2

 

Ce qu’il faut comprendre, c’est que le Wizard UAG a bien activé la prise en charge de la carte à puce, mais au niveau du tunnel IPSEC initialisé par l’utilisateur. A ce stade, arrêtons nous sur quelques subtilités :

  • L’utilisateur n’est pas obligé d’insérer sa carte à puce, il est juste invité. S’il ne le fait pas, alors, le tunnel IPSEC “Utilisateur” ne monte pas. Pourtant, il est bien authentifié auprès du contrôleur de domaine grâce au tunnel “Ordinateur”.
  • Si l’utilisateur refuse d’insérer sa carte à puce et ferme l’interface, il n’y a plus de notification. Si l’utilisateur veut finalement s’authentifier avec sa carte à puce, il doit verrouiller sa session pour que la notification apparaisse de nouveau.
  • Si NAP est activé, la notification de l’utilisateur ne sera possible que si le poste de travail est reconnu comme conforme.

 

Mais quelle est cette magie?

Ce n’est pas de la magie mais simplement l’implémentation du protocole AuthIP, successeur  d’IKEV2 pour la négociation des tunnels IPSEC. Sa particularité est de permettre de prendre en charge de nouveaux critères pour l’authentification tel que :

  • Le certificat d’état de santé du poste de travail (NAP)
  • Le certificat de l’utilisateur (Smartcard)
  • L’appartenance à un groupe de sécurité

 

Pourtant, on a beau chercher, on ne voit pas comment cela se configure et fonctionne. La raison est simple, il n’y a pas d’interface graphique, tout se passe en ligne de commande avec NETSH. 

 

La première chose à faire, c’est de se positionner dans la stratégie de groupe que l’on va éditer. Dans le cas qui nous occupe, c’est la stratégie de groupe du serveur UAG qui configure AuthIP.

AuthIP0

On découvre deux paramètres très intéressants :

  • AuthzUserGrp
  • AuthzComputerGrp

 

C’est grâce au paramètre “AuthzUserGrp” que le tunnel IPSEC de l’utilisateur ne monte que si l’utilisateur est membre du groupe indiqué. Pourtant le groupe référencé ne semble pas très parlant. Cela ressemble juste à un groupe “Spécial” du fait de son SID court.

 

Regardons maintenant du coté du client. Lorsque celui s’authentifie avec une carte à puce, la commande “WHOAMI /GROUPS” nous retourne le résultat ci-dessous :

LOGONAVECSMARTCARD

En regardant bien, on retrouve notre SID “S-5-65-1”, plus connu sous le nom de “Ce certificat d’organisation. Et bien lorsque l’utilisateur s’est authentifié, il a été reconnu que la carte à puce a été utilisée et l’utilisateur a été reconnu comme membre de ce groupe spécial. C’est grâce à cela que le tunnel IPSEC de l’utilisateur va fonctionner. Magique non?

 

Allons plus loin

Par extension, il est donc possible de remplacer le contenu du paramètre “AuthzUserGrp” pour spécifier un autre groupe de sécurité (à condition de le formater la chaîne de caractère au format SDDL strings). On peut donc spécifier d’autres groupes et développer de nouveaux scénarios tel que :

  • Limiter l’utilisation de DirectAccess aux seuls utilisateurs autorisés (en plus des postes de travail)
  • Limiter l’accès à certains serveurs selon appartenance de l’utilisateur à un groupe, l’utilisation d’une carte à puce et même l’utilisation d’une carte à puce bien spécifique (Authentication Insurance)
  • Limiter l’accès à certains serveurs selon l’appartenance du poste de travail à un groupe de sécurité donné

 

Authentication Insurance

Si on regarde encore le résultat de la commande “WHOAMI /GROUPS”, on constate la présence d’un groupe “HighInsuranceGroup”, un simple groupe de domaine. Lui aussi, il n’est présent que parce que je me suis authentifié avec une carte à puce. Oui mais pas n’importe quelle carte à puce. Une carte à puce contenant un certificat bien spécifique.

 

L’authentification de l’utilisateur avec cette carte à puce à positionné l’utilisateur dans le groupe “HighInsuranceGroup”. C’est ce qu’on appelle l’”Authentication Insurance”, une nouvelle fonctionnalité de Windows 2008 R2 que je détaillerai prochainement.

 

Conclusion

Voila pour la magie de DirectAccess avec les Smartcard. Le wizard de DirectAccess fait un peu de la magie car AuthIP n’est pas configurable au travers des GPO. Il n’est possible de le manipuler qu’au travers de la boîte à outil NETSH.EXE. C’est pour cette raison qu’il ne faut surtout pas manipuler les GPO générées avec la console GPMC.

 

Voila de nouveaux scénarios autour de DirectAccess, que je développerai dès que j’aurai un peu de temps.

 

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

Actualisation de la liste des Updates pour Hyper-V R2

La liste vient tout juste d’être mise à jour. Cela se passe à cette adresse. Un lien à conserver car bien entendu, la liste des mises à jour évolue avec le temps. Au passage, on retrouvera la trace de la KB981791, sujet déjà évoqué dans un précédent billet.

 

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

DirectAccess, IPSEC et algorithmes impliqués

La question m’ayant été posée récemment, autant faire partager la réponse. DirectAccess repose sur des tunnels IPSEC. L’établissement des tunnels IPSEC (échange des clés) s’effectue selon les protocoles indiqués ci-dessous (dits à courbes elliptiques):

KEY

Pour le chiffrement des données en elle même, c’est de l’AES-CBC-192, donc les algorithmes de chiffrement ici aussi les plus récents.

ESP

Par défaut, on est donc en présence d’algorithmes éprouvés. Si besoin est, il reste encore possible de modifier les protocoles utilisés. Par contre il faudra penser à décharger le traitement IPSEC sur la carte réseau pour éviter de surcharger inutilement le processeur.

 

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

DirectAccess et le NAT

La question revenant souvent, il est donc temps de clarifier les choses. Commençons par la bible DirectAccess. Après lecture du volumineux document, il est effectivement possible de placer un pare-feu en frontal comme le rappelle Tom Shinder alias “The Edge Man”.

 

Note : Bien que cela ne soit pas indiqué dans le Design Guide, il reste aussi possible de configurer le pare-feu en mode Bridge, donc totalement transparent.

 

En dorsal, le guide référence aussi la possibilité de placer un pare-feu. Ici encore, il n’est pas possible d’implémenter NAT et ce pour plusieurs raisons :

  • Active Directory n’est pas supporté lorsque mis en œuvre au travers d’une translation d’adresse : KB978772.
  • ISATAP ne sera pas conscient de l’adresse translatée donc l’adresse ISATAP générée par l’hôte sera invalide, ce qui engendrera des problèmes de routages IPV6.
  • Le protocole DNS64 d’UAG n’a pas conscience du NAT. Il va interroger le DNS pour rechercher les adresses IPV6/IPV4 réelles.

 

Enfin, pour finir, le concept de NAT n’existe pas en IPV6. Il n’y a plus de justification technique au NAT. Pour rappel NAT, ce n’est qu’une fonctionnalité autorisant le partage d’une adresse IP publique par plusieurs hôtes situés sur un réseau privé et non une fonctionnalité de sécurité au sens propre. La "re-périmétrisation" est en marche.

 

Si ces sujets vous intéressent, vous pouvez toujours venir assister à la session des ExaTechDays de Lyon “Dépérimètrisation des réseaux, le nouveau challenge de la mobilité”, que je vais avoir le plaisir d’animer avec Alexandre GIRAUD.

 

 

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

Tester les extensions de schéma

Dès lorsqu’on se lance dans un projet de mise à niveau d’un environnement Active Directory existant se pose la problématique du schéma, et plus particulièrement les questions suivantes nous viennent à l’esprit :

  • Quelle est la version actuelle du schéma?
  • Le schéma a t’il été étendu pour Exchange, si oui quelle version?
  • L’objet Inetorg a t’il été corrigé?
  • D’autres applications ont-elles nécessité une extension de schéma (LCS, OCS, …)?

 

Généralement, on arrive facilement à répondre aux deux premières questions. Pour les suivantes, c’est un peu plus compliqué de répondre. Maintenant, qu’en est-il si je tente une extension de schéma pour Windows 2008 R2? Pour adresser cette problématique, on disposait jusqu’à maintenant de deux solutions :

  • L’optimisme : “ADPREP /ForestPrep /DomainPrep” et on verra
  • Tester : Virtualiser un contrôleur de domaine et tester l’extension de schéma

 

Passons pour la première solution, elle n’engage que celui qui va appuyer sur la touche Enter et celui qui a ouvert la session avec les privilèges nécessaires. Pour la seconde, c’est effectivement une bonne démarche, si on peut effectivement valider que les applications impactées (Exchange, OCS) sont toujours opérationnelles. La construction de la maquette prendra donc un certain temps.

 

Si on pouvait tester sans risque, ce serait encore mieux. Pour cela, Microsoft vient de mettre à disposition le ADSchemaExtensionConflictAnalyzer, un script PowerShell permettant de simuler une extension de schéma avant de la réaliser. Le script va exploiter les fichier LDF pour valider qu’il n’y aura pas de conflit lors de l’importation pour des cas classiques (Exchange, OCS) et même des applications tierces. Son utilisation est présentée  à cette adresse.

 

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

La Name Resolution Policy Table expliquée

Cela fait longtemps qu’il sévit le “Cable Guy”, ou plus simplement Joseph Davies, Principal Technical Writer de son état.

 

Régulièrement, il met en avant une fonctionnalité réseau méconnue, la décortique. En ce moment, c’est la Name Resolution Policy Table. C’est complet et encore une fois en relation avec DirectAccess. On ne peut faire plus complet sur le sujet.

 

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

DirectAccess/UAG et l’équilibrage de charge

Pour ceux qui ont suivi le Step-by-step guide DirectAccess avec UAG, vous avez peut être rencontré un problème si vous avez tenté de mettre en œuvre la ferme UAG. Une fois la ferme installé et configurée, l’interface réseau 6to4 avait disparu coté Internet.

 

Après quelques recherche, il y a une KB qui décrit la problématique : KB977342 :  ISATAP and 6to4 tunneled addresses cannot be used by the NLB feature on a computer that is running Windows Server 2008 R2. Une fois le correctif installé, l’interface 6to4 réapparait.

 

Pour plus d’information sur le sujet, rien ne vaux la source Technet : Configuring NLB for a Forefront UAG DirectAccess array.

 

Au passage, je rappelle que si vous déployez une ferme UAG sur un environnement virtuel Hyper-V, pensez à activer la fonctionnalité “Enable spoofing of MAC addresses” dans les caractéristiques de la machine virtuelle. Cela fonctionnera tout de suite mieux.

 

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

DirectAccess en mode Selected Servers

DirectAccess, c’est pas la première fois que j’en parle sur ce blog, j’en ai déjà beaucoup parlé. Pour preuve, il suffit de consulter le nuage de Tags DirectAccess. Pourtant, il reste encore des choses à voir. Par exemple : le mode Selected Server.

 

Pour illustrer mon propos, voila l’interface de configuration DirectAccess UAG sur le sujet. Jusqu’à maintenant, on a tous coché la case d’option “Require end-to-Edge authentication and encryption”, ce qui signifie que tous les tunnels se terminaient au niveau du serveur Microsoft Forefront Unified Access Gateway 2010.

9

Pourtant le mode “Require-end-to-end authentication and encryption to specified applications servers” mérite qu’on s’attarde un peu sur lui. Prenons un cas concret avec ma maquette pour les Exatechdays à Lyon:

Maquette

Cela ressemble à du DirectAccess classique implémenté avec UAG et NAP. Cependant, j’ai ajouté deux serveurs applicatifs (Web-Server et File-Server) pour démontrer l’intérêt du mode “Selected Servers”. Concrètement, mon serveur “APP2.Exatechdays.Local” est bien accessible de l’extérieur mais avec la mise en place d’un tunnel IPSEC additionnel. Cette fois, le tunnel se termine donc sur le serveur visé et non sur le serveur UAG comme ce sera le cas pour le serveur “APP3.Exatechdays.Local”

 

La mise en œuvre

Pour illustrer mon propos, voila la configuration UAG qui va avec. En plus cela me permettra de présenter certaines spécificités liées à la mise en œuvre de DirectAccess avec UAG.

0

Premier étage : Rien de bien compliqué : Un groupe de filtrage qui sera utilisé pour filtrer l’application de la stratégie de groupe destinée à configurer les clients DirectAccess. Je reste simple.

1

Deuxième étage, cela se corse un peu : On retrouve la même interface que pour le DirectAccess Windows, dans le cas qui nous occupe, je n’ai rien changé. Si on passe ce cap, c’est que déjà les principaux pré-requis sont respectés.

2

Troisième étage, la spécificité UAG. DNS64 et NAT64 sont des protocoles de translation permettant d’accéder à nos ressources IPV4, ce que ne permet pas l’implémentation Windows de DirectAccess. Pour ceux qui veulent en savoir plus, je recommande la lecture des deux billets de Stanislas QUASTANA sur son blog : Partie n°1, Partie n°2. A mon sens, cela justifie pleinement l’utilisation d’UAG pour faire du DirectAccess.

3

Quatrième étape, l’authentification : Ici rien de bien nouveau, on doit décider quelle autorité de certification on va utiliser pour valider les tunnels IPSEC et désigner le certificat qui sera mis en œuvre pout le protocole IP-HTTPS.

4 

Note : A ce niveau, je signale qu’au moment de la rédaction de ce billet, il subsiste un bogue dans UAG lorsqu’on décide de faire du NAP sans Smartcard. J’espère que cette problématique sera résolue dans l’Update 2 d’UAG.

 

Cinquième étage, le Network Location Server : Ici encore rien n’a changé.

5

Sixième étage, la Name Resolution Policy Table : On pourrait croire que rien n’a changé, pourtant si on regarde de plus près l’adresse IP du DNS associée au domaine Active Directory, on observe la mention DNS64. Cela signifie que nos clients à l’extérieurs ne vont pas s’adresser directement aux serveurs DNS tel que c’était le cas dans une implémentation DirectAccess Windows.

6

Septième étage, les serveurs d’infrastructure : Ici l’interface est plus claire. On peut enfin classer ses serveurs selon des catégories. A noter que tous ceux qui seront référencés ici seront autorisés à utiliser le tunnel IPSEC infrastructure.

7

Note : A ce niveau, assurez vous que vos serveurs DNS répondent bien en IPV6, plus particulièrement qu’ils écoutent bien sur l’interface ISATAP. Si le serveur est un Windows 2008 sans Service Pack 2, attention à la KB958194, je me suis encore fait avoir récemment.

 

Dans la catégorie NAP, j’ai ajouté mon HRA. Oui, mon HRA est interne et alors?

8

Huitième étage, le Selected server mode : On va commencer par s’assurer de cocher la bonne case.

9

Puis de cliquer sur le lien “Edit IPSEC Cryptographic settings…” pour constater les spécifications du tunnel IPSEC qui sera mis en œuvre.

10

Il ne reste plus qu’à spécifier un groupe de serveurs pour lesquels le tunnel sera mis en place. D’un point de vue technique, le groupe est utilisé pour filtrer l’application de la troisième stratégie de groupe (celle qu’on n’utilisait jamais jusque là).

11

Le résumé de la configuration nous rappelle bien notre configuration :

  • On a accès à tout le réseau interne
  • L’accès à certains serveurs nécessitera la mise en place d’un tunnel IPSEC additionnel

14

Neuvième étage, l’activation de la configuration d’UAG. A ce niveau, je tiens à remercier Alexandre GIRAUD pour son workaround sur le bug “The adapter configured as external-facing is connected to a domain”.

16

Le résultat coté client

Maintenant que tout est en place, voyons ce qui a changé coté client. Dans la console “Firewall with Advanced Security”, on constate la présence d’une nouvelle association de sécurité avec l’adresse ISATAP de notre serveur App2.exatechdays.local.

CLIENT0

Dès lors que je vais accéder à mon serveur “App2.exatechdays.local”, il va automatiquement mettre en place le tunnel IPSEC additionnel vers le serveur.

CLIENT1

Le résultat coté serveur

Coté serveur, on constate la présence de deux associations de sécurité dans la console “Firewall and Advanced Security” sur le serveur “App2.exatechdays.local”. C’est le résultat de la stratégie de groupe appliquée au membres du groupe de serveurs.

APP2_0

Dans le détail, on constate la mise en place de l’association de sécurité avec le client, plus particulièrement l’utilisateur.

APP2_1

 

Pour aller plus loin

Par extension, ce mode de fonctionnement peut être utilisé pour les scénarios suivants :

  • On peut facilement limiter l’accès au système d’information de l’entreprise au travers de DirectAccess.
  • En personnalisant les règles de pare-feu et plus particulièrement les associations de sécurité on peut autoriser l’accès à certaines ressources interne selon l’utilisateur et ou l’ordinateur (scénarios VIP par exemple)

 

Les limites

On en dénombre deux, concernant uniquement les serveurs internes :

  • Les serveurs référencés dans le groupe de filtrage fonctionnent au moins sous Windows 2008, (sinon ils ne seront pas capable d’interpréter les règles de pare-feu).
  • Les serveurs référencés dans le groupe de filtrage pour un tunnel IPSEC sans protection de la charge (ESP Null) doivent nécessairement fonctionner sous Windows 2008 R2 ou supérieur.

 

Conclusion

Voila un scénario DirectAccess bien intéressant. Dans mon prochain billet, je vais élever encore le niveau avec un scénario pour utilisateurs VIP en DirectAccess :

Credentials 

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

Hyper-V et les processeurs Intel Westmere

Les hyperviseurs sont fortement dépendants des processeurs et des évolutions de ceux-ci. De ce fait, toute modification même mineure sur les processeurs peut avoir des répercutions sur l’hyperviseur.

 

C’est actuellement le cas avec la dernière génération de processeurs Intel Westmere qui intègre de nouvelles fonctionnalités, plus particulièrement, autour des machines virtuelles (Virtual Machine Control Block caching feature).

 

Hyper-V ne gérant pas cette nouvelle fonctionnalité, cela conduit à des erreurs 0x0000001a. la KB981791, documente ce problème. Des correctifs sont désormais disponibles aussi bien pour Windows Server 2008 que Windows Server 2008 R2.

 

 

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