Parlez-nous de l’expérience de téléchargement de PDF.

Documentation sur la sécurité de

Windows Server
La sécurité de Windows Server fournit des couches de protection intégrées au système
d’exploitation pour protéger contre les violations de la sécurité, bloquer les attaques
malveillantes, et durcir la sécurité de vos machines virtuelles, applications et données.

Vue d’ensemble de la sécurité dans Windows Server

ｅ VUE D’ENSEMBLE

Billet de blog sur la sécurité de Windows Server

Blog sur la sécurité des centres de données et du cloud privé

Répondre aux menaces émergentes et aux changements de paysage

Billet de blog - Protection de votre centre de données et de votre cloud contre les nouvelles
menaces

Virtualisation sécurisée avec des VM dotées d’une protection maximale

ｑ VIDEO

Démonstration de machine virtuelle protégée

Vidéo complète sur les machines virtuelles dotées d’une protection maximale dans Windows
Server

ｃ GUIDE PRATIQUE

Guide de déploiement de Guarded Fabric

Machine virtuelle dotée d’une protection maximale et infrastructure protégée dans les filiales

Guide de résolution des problèmes pour les machines virtuelles protégées et les
infrastructures surveillées

Durcissement du système d’exploitation et des applications

ｅ VUE D’ENSEMBLE
Guide de déploiement du Contrôle d’application Windows Defender (WDAC)

Paramètres de Registre du protocole TLS

Control Flow Guard

Windows Defender

Serveur Secured-core

ｑ VIDEO

Vidéo de démonstration Device Guard

Gestion de l’accès privilégié

ｅ VUE D’ENSEMBLE

Sécurisation de l’accès privilégié

Administration Just in Time avec Microsoft Identity Manager

Article Just Enough Administration

ｑ VIDEO

Vidéo de démonstration Just Enough Administration

Protection des informations d’identification

ｅ VUE D’ENSEMBLE

Protéger les informations d’identification de domaine dérivées avec Credential Guard

Protéger les informations d’identification du bureau à distance avec la fonctionnalité Remote

Credential Guard

ｑ VIDEO

Vidéo de démonstration Credential Guard

Détecter et répondre aux menaces

ｑ VIDEO

Microsoft Operations Management Suite (OMS)

OMS et Windows Server

ｅ VUE D’ENSEMBLE

Microsoft Advanced Threat Analytics

Sécurité réseau

ｅ VUE D’ENSEMBLE

Présentation du pare-feu de centre de données

Nouveautés du système de noms de domaine (DNS) dans Windows Server

Correspondance entre fonctionnalités de sécurité et normes de

conformité

ａ TÉLÉCHARGER

Livre blanc sur les correspondances de conformité pour les VM Hyper-V dotées d’une
protection maximale

Livre blanc sur les correspondances de conformité pour JEA et JIT

Livre blanc sur le mappage de conformité Credential Guard

Livre blanc sur le mappage de conformité Credential Guard

Livre blanc sur les correspondances de conformité pour Windows Defender

Versions antérieures de Windows Server

ｅ VUE D’ENSEMBLE

Documentation des versions précédentes de Windows

Rechercher des informations spécifiques

Commencer à appliquer le Règlement
général sur la protection des données
(RGPD) pour Windows Server
Article • 17/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cet article fournit des informations sur le RGPD et le définit. Il présente également les
produits mis à disposition par Microsoft pour vous aider à garantir la conformité.

Introduction
Le 25 mai 2018, une loi européenne sur la confidentialité des données va entrer en
vigueur. Elle doit fixer une nouvelle norme globale pour la protection, la sécurité et le
respect des données personnelles.

Le Règlement général sur la protection des données (RGPD) vise essentiellement à

protéger et à garantir les droits à la protection des données personnelles de chacun. Le
RGPD établit des exigences mondiales strictes en matière de protection des données
personnelles, qui régissent la façon dont vous gérez et protégez les données
personnelles dans le respect des choix individuels, et ce, quel que soit l’emplacement
dans lequel les données sont envoyées, traitées ou stockées.

Microsoft et nos clients sont en voie de réaliser les objectifs de protection des données
personnelles du RGPD. Pour Microsoft, la protection des données personnelles est un
droit fondamental et le RGPD constitue une étape importante dans l’explication et
l’exercice des droits à la protection des données personnelles de chacun. Nous sommes
également conscients que le RGPD exigera des changements significatifs de la part des
organisations du monde entier.

Nous avons exposé notre engagement envers le RGPD et la façon dont nous soutenons
nos clients dans le billet de blog Garantir la conformité au RGPD grâce au
Microsoft Cloud rédigé par notre responsable de la protection des données
personnelles, Brendon Lynch , ainsi que dans le billet de blog Mériter votre confiance
par des engagements contractuels au Règlement général sur la protection des
données rédigé par Rich Sauer , vice-président & conseiller juridique général adjoint
de Microsoft.
Il peut sembler difficile d’assurer la conformité au RGPD, mais nous sommes là pour
vous aider. Pour obtenir des informations spécifiques sur le RGPD, nos engagements et
la façon de vous conformer au RGPD, consultez la section RGPD du Centre de gestion
de la confidentialité Microsoft .

Le RGPD et ses implications

Le RGPD est un règlement complexe qui peut exiger des changements considérables
dans la façon dont vous collectez, utilisez et gérez les données personnelles. Microsoft
se dévoue depuis de longues années à aider ses clients à se conformer aux règlements
complexes. En ce qui concerne la conformité au RGPD, nous vous accompagnons et
vous aidons à la garantir.

Le RGPD impose des règles aux organisations qui proposent des biens et des services
aux citoyens de l’Union européenne (UE), ou qui collectent et analysent des données
concernant ces citoyens, et ce, quel que soit le lieu d’activité de ces organisations. Les
éléments clés du RGPD sont notamment les suivants :

Droits améliorés en matière de protection des données personnelles. La

protection des données des citoyens de l’UE est renforcée, en veillant à ce qu’ils
aient le droit d’accéder à leurs données personnelles, de corriger les inexactitudes
de ces données, d’effacer ces données, de s’opposer au traitement de leurs
données personnelles, et de les déplacer.

Obligation accrue en matière de protection des données personnelles. La

responsabilité des organisations qui traitent les données personnelles est
renforcée, ce qui garantit une définition claire des responsabilités en matière de
conformité.

Signalement obligatoire des violations de données personnelles. Les

organisations qui contrôlent des données personnelles sont tenues de signaler, à
leurs autorités de contrôle, les violations de données personnelles qui présentent
un risque pour les droits et les libertés de chacun, et ce, sans délai indu et, dans la
mesure du possible, au plus tard 72 heures après avoir pris connaissance de la
violation.

Comme vous pouvez le prévoir, le RGPD peut avoir une incidence considérable sur votre
entreprise, en vous obligeant potentiellement à mettre à jour vos stratégies de
confidentialité, à mettre en place et à renforcer les contrôles de protection des données
et les procédures de notification de violations, à déployer des stratégies hautement
transparentes, et à investir davantage dans les technologies de l’information et les
formations. Microsoft Windows 10 peut vous aider à répondre efficacement à certaines
de ces exigences.

Données personnelles et sensibles

Afin de vous conformer au RGPD, vous devez comprendre la définition des données
personnelles et sensibles du règlement, ainsi que le lien entre ces définitions et les
données détenues par votre organisation. Vous serez alors en mesure de déterminer
l’emplacement dans lequel ces données sont créées, traitées, gérées et stockées.

Selon le RGPD, les données personnelles constituent toute information relative à une
personne physique identifiée ou identifiable. Il peut être question d’une identification
directe (par exemple, votre nom légal) ou indirecte (par exemple, des informations
spécifiques indiquant clairement que les données vous concernent). Le RGPD détaille
également le concept des données personnelles qui inclut les identifiants en ligne (tels
que les adresses IP, les ID d’appareil mobile) et les données de localisation.

Le RGPD définit spécifiquement les données génétiques (telles que la séquence

génétique d’une personne) et les données biométriques. Les données génétiques et
biométriques, ainsi que d’autres sous-catégories de données personnelles (données
personnelles inhérentes à l’origine raciale ou ethnique, aux opinions politiques, aux
croyances religieuses ou philosophiques, ou à l’appartenance syndicale ; données
relatives à la santé ; ou données relatives à la vie sexuelle ou à l’orientation sexuelle
d’une personne), sont traitées en tant que données personnelles sensibles en vertu du
RGPD. Les données personnelles sensibles bénéficient d’une protection renforcée et
requièrent généralement le consentement explicite d’une personne pour pouvoir être
traitées.

Exemples d’informations relatives à une personne

physique identifiée ou identifiable (personne concernée)
Cette liste comporte des exemples de types d’informations réglementées dans le cadre
du RGPD. Cette liste est non exhaustive.

Nom

Numéro d’identification (par exemple, SSN)

Données de localisation (par exemple, adresse du domicile)

Identifiant en ligne (par exemple, adresse e-mail, noms affichés, adresse IP, ID
d’appareil)
 Données pseudonymes (par exemple, utilisation d’une clé pour identifier des
personnes)

Données génétiques (par exemple, échantillons biologiques)

Données biométriques (par exemple, empreintes digitales, reconnaissance faciale)

Commencer à se conformer au RGPD

Compte tenu des efforts et des ressources nécessaires pour assurer la conformité au
RGPD, nous vous recommandons vivement de ne pas attendre la dernière minute. Vous
devez passer en revue vos pratiques en matière de confidentialité et de gestion
des données dès maintenant. Nous vous recommandons de vous concentrer sur quatre
étapes clés :

Découvrez. Identifiez les données personnelles dont vous disposez et

leur emplacement.

Gestion. régir la manière dont les données personnelles peuvent être consultées et
utilisées.

Protéger. établir des contrôles de sécurité pour prévenir, détecter et traiter les
failles de sécurité et les violations de données.

Rapport. Prenez les mesures nécessaires en réponse aux demandes de données,

signalez les violations de données et conservez la documentation requise.

Chacune de ces étapes s’accompagne d’exemples d’outils, de ressources et de

fonctionnalités dans différentes solutions Microsoft, qui peuvent vous aider à répondre
aux exigences de l’étape en question. Cet article n’est pas un guide pratique complet.
Nous y avons inclus des liens vous permettant d’en savoir plus. Des informations sont
également disponibles dans la section RGPD du Centre de gestion de la confidentialité
Microsoft .

Sécurité et confidentialité Windows Server

Le RGPD vous oblige à mettre en œuvre des mesures de sécurité techniques et
organisationnelles appropriées afin de protéger les données personnelles et les
systèmes de traitement. Dans le cadre du RGPD, vos environnements de serveurs
physiques et virtuels traitent potentiellement des données personnelles et sensibles. Le
terme « traitement » fait référence à n’importe quelle opération ou n’importe quel
ensemble d’opérations, comme la collecte, le stockage et la récupération de données.

Votre capacité à répondre à cette exigence et à mettre en œuvre des mesures de

sécurité techniques appropriées doit refléter les menaces auxquelles vous êtes confronté
dans l’environnement informatique actuel, qui est de plus en plus hostile. Le paysage
actuel des menaces de sécurité est un paysage de menaces agressives et tenaces.
Auparavant, les attaquants malveillants cherchaient principalement à obtenir une
reconnaissance communautaire par leurs attaques ou prenaient simplement plaisir à
mettre temporairement un système hors ligne. Les motivations des attaquants ont
évolué, ces derniers cherchant désormais à gagner de l’argent en prenant en otage des
appareils et des données jusqu’à ce que le propriétaire paie la rançon demandée.

Les attaques modernes portent de plus en plus sur le vol de la propriété intellectuelle à
grande échelle, sur la dégradation ciblée de systèmes qui peut occasionner des pertes
financières, et même sur le cyberterrorisme qui menace la sécurité des personnes, des
entreprises et des intérêts nationaux dans le monde entier. Ces attaquants sont
généralement des personnes hautement qualifiées et des experts en sécurité. Certains
d’entre eux travaillent pour des États-nations à gros budgets et à ressources humaines
apparemment illimitées. De telles menaces nécessitent une approche particulière.

Ces menaces mettent non seulement à mal votre capacité à garder le contrôle de vos
données personnelles ou sensibles, mais elles présentent également un risque matériel
pour votre entreprise dans son ensemble. Prenez connaissance de ces récentes données
provenant de McKinsey, de Ponemon Institute, de Verizon et de Microsoft :

Le coût moyen d’une violation de données que vous êtes tenu de signaler selon le
RGPD est de 3,5 millions de dollars.

63 % de ces violations impliquent des mots de passe faibles ou volés auxquels

vous êtes tenu de remédier selon le RGPD.
 Plus de 300 000 nouveaux échantillons de programmes malveillants sont créés et
diffusés chaque jour, ce qui complique davantage votre tâche de protection des
données.

Comme on a pu l’observer avec les récentes attaques par ransomware, autrefois

appelées la peste noire d’Internet, les attaquants s’attaquent à de plus grandes cibles
qui peuvent se permettre de payer plus, ce qui entraîne des conséquences
potentiellement catastrophiques. Le RGPD prévoit des sanctions qui font de vos
systèmes, notamment les appareils de bureau et les ordinateurs portables, qui
contiennent des données personnelles et sensibles, de véritables cibles riches.

Deux principes clés ont guidé et continuent de guider le développement de Windows :

Sécurité. Les données stockées par nos logiciels et services pour le compte de nos
clients doivent être protégées et utilisées ou modifiées uniquement de manière
appropriée. Les développeurs doivent pouvoir facilement comprendre les modèles
de sécurité et les intégrer dans leurs applications.

Confidentialité. Les utilisateurs doivent être maîtres de l’utilisation de leurs

données. Les stratégies d’utilisation d’informations doivent être clairement définies
et exposées à l’utilisateur. Les utilisateurs doivent déterminer s’ils souhaitent
recevoir des informations et à quel moment ils souhaitent les recevoir, afin de tirer
le meilleur parti de leur temps. Les utilisateurs doivent pouvoir facilement spécifier
la nature appropriée de l’utilisation de leurs informations, notamment en
contrôlant l’utilisation des e-mails qu’ils envoient.

Microsoft se conforme à ces principes. Comme l’a récemment souligné la PDG de

Microsoft, Satya Nadella,

« Dans ce monde qui ne cesse de changer et où les besoins et exigences des

entreprises évoluent, certaines réalités sont bien ancrées, comme la demande d’un
client en matière de sécurité et de confidentialité. »

Pour vous conformer au RGPD, il est important de comprendre le rôle de vos serveurs
physiques et virtuels dans la création, l’accès, le traitement, le stockage et la gestion,
dans le cadre du RGPD, des données qui peuvent être personnelles et potentiellement
sensibles. Windows Server fournit des fonctionnalités qui vous aideront à vous
conformer aux exigences du RGPD en mettant en place des mesures de sécurité
techniques et organisationnelles appropriées afin de protéger les données personnelles.

La posture de sécurité de Windows Server 2016 ne passe pas par un logiciel

complémentaire ; elle repose sur une architecture à part entière. Quatre principes
essentiels permettent de mieux comprendre cette posture :
 Protéger. Intérêt et innovation permanents en matière de mesures préventives.
Blocage des attaques connues et des programmes malveillants connus.

Détecter. Outils de surveillance complets permettant de détecter les anomalies et

de réagir plus rapidement aux attaques.

Répondre. Technologies de pointe en matière de réponse et de récupération, et

expertise approfondie en consultation.

Isolez. Isolez les composants des systèmes d’exploitation et les secrets de

données, limitez les privilèges d’administrateur, et évaluez rigoureusement
l’intégrité des hôtes.

Avec Windows Server, votre capacité à détecter les attaques pouvant entraîner des
violations de données, à vous protéger et à vous défendre contre ces attaques est
considérablement améliorée. Compte tenu des exigences strictes imposées en matière
de notification des violations dans le RGPD, afin de réduire les risques qui pourraient
entraîner une analyse et une notification coûteuses des violations, assurez-vous que vos
systèmes d’appareils de bureau et d’ordinateurs portables sont bien protégés.

La section suivante explique comment les fonctionnalités Windows Server s’accordent

parfaitement à la phase « Protéger » de votre processus de conformité au RGPD. Ces
fonctionnalités s’inscrivent dans trois scénarios de protection :

Protégez vos informations d’identification et limitez les

privilèges d’administrateur. Windows Server 2016 vous permet de mettre en place
ces changements, afin d’éviter que votre système serve de point de lancement
pour d’autres intrusions.

Sécurisez le système d’exploitation pour exécuter vos applications et votre

infrastructure. Windows Server 2016 offre des couches de protection qui
permettent d’empêcher les attaquants externes d’exécuter des logiciels
malveillants ou d’exploiter des vulnérabilités.

Sécurisez la virtualisation. Windows Server 2016 garantit une virtualisation

sécurisée, grâce à des machines virtuelles dotées d’une protection maximale et à
une structure Service Guardian. Cela vous permet de chiffrer et d’exécuter vos
machines virtuelles sur des hôtes approuvés au sein de votre structure. Vos
machines virtuelles sont ainsi mieux protégées contre les attaques malveillantes.

Ces fonctionnalités, détaillées ci-dessous et mises en correspondance avec des

exigences spécifiques du RGPD, s’appuient sur une protection avancée des appareils
pour préserver l’intégrité et la sécurité du système d’exploitation et des données.
Une disposition clé du RGPD concerne la protection des données à dessein et à défaut.
Nous vous aidons à satisfaire à cette disposition grâce à des fonctionnalités de
Windows 10 telles que le chiffrement d’appareil BitLocker. BitLocker exploite la
technologie du Module de plateforme sécurisée (TPM), qui assure des fonctions de
sécurité matérielles. Le circuit du cryptoprocesseur est infalsifiable grâce à plusieurs
mécanismes de sécurité physique, et les logiciels malveillants ne peuvent falsifier aucune
donnée grâce aux fonctions de sécurité du TPM.

La puce comprend plusieurs mécanismes de sécurité physique qui la protègent contre la

falsification, et les logiciels malveillants ne peuvent pas falsifier les fonctions de sécurité
du TPM. Les principaux avantages de la technologie de TPM sont que vous pouvez :

générer, stocker et limiter l’utilisation des clés de chiffrement ;

Exploitez la technologie TPM à des fins d’authentification des appareils de la

plateforme, à l’aide de la clé RSA unique du TPM qui est gravée sur elle-même.

Assurez l’intégrité de la plateforme en réalisant et en stockant des mesures de

sécurité.

Le démarrage approuvé Windows est une protection avancée supplémentaire adaptée à

votre système d’exploitation sans violation de données. Il aide à préserver l’intégrité du
système en veillant à ce que les programmes malveillants ne puissent pas démarrer tant
que le système n’est pas protégé

Windows Server : une aide pour vous

conformer au RGPD
Les fonctionnalités clés de Windows Server peuvent vous aider à efficacement mettre en
place les mécanismes de sécurité et de confidentialité requis par le RGPD à des fins de
conformité. L’utilisation de ces fonctionnalités ne garantit pas votre conformité ; elles
constituent une aide.

Le système d’exploitation du serveur se trouve au niveau d’une couche stratégique de

l’infrastructure d’une organisation, ce qui ouvre de nouvelles perspectives pour créer
des couches de protection contre les attaques visant à voler des données et à
interrompre vos activités. Les aspects clés du RGPD, tels que la confidentialité à dessein,
la protection des données et le contrôle des accès, doivent être traités au sein de votre
infrastructure informatique au niveau du serveur.

Afin de protéger les couches d’identité, de système d’exploitation et de virtualisation,

Windows Server 2016 bloque les vecteurs d’attaque courants visant à obtenir un accès
illicite à vos systèmes (informations d’identification volées, programmes malveillants et
structure de virtualisation compromise). En plus de réduire les risques pour les
entreprises, les composants de sécurité intégrés à Windows Server 2016 permettent de
répondre aux exigences de conformité des règlements de sécurité clés imposés par le
gouvernement et l’industrie.

Ces protections d’identité, de système d’exploitation et de virtualisation vous

permettent de mieux protéger votre centre de données exécutant Windows Server en
tant que machine virtuelle dans un cloud, et de limiter la capacité des attaquants à
compromettre les informations d’identification, à lancer des programmes malveillants et
à ne pas être détectés dans votre réseau. De même, lorsqu’il est déployé en tant qu’hôte
Hyper-V, Windows Server 2016 assure la sécurité de vos environnements de
virtualisation grâce à des machines virtuelles dotées d’une protection maximale et à des
fonctionnalités de pare-feu distribué. Avec Windows Server 2016, le système
d’exploitation du serveur participe activement à la sécurité de votre centre de données.

Protégez vos informations d’identification et limitez les

privilèges d’administrateur.
Le contrôle des accès aux données personnelles et aux systèmes qui traitent ces
données s’accompagne d’exigences spécifiques dans le RGPD, notamment en ce qui
concerne l’accès par les administrateurs. Les identités privilégiées sont des comptes
dotés de privilèges élevés, tels que les comptes d’utilisateur qui sont membres des
administrateurs de domaine, des administrateurs d’entreprise, des administrateurs
locaux ou même des groupes d’utilisateurs avec pouvoir. Ces identités peuvent
également inclure des comptes auxquels des privilèges ont été accordés directement,
tels que des privilèges pour réaliser des sauvegardes ou arrêter le système, ou d’autres
droits répertoriés dans le nœud Attribution de droits utilisateur dans la console
Stratégie de sécurité locale.

Le principe général de contrôle des accès et de conformité au RGPD consiste à protéger

ces identités privilégiées contre toute compromission par des attaquants potentiels. Il
est essentiel que vous compreniez comment ces identités sont compromises avant de
vous préparer et d’empêcher les attaquants d’accéder à ces identités privilégiées.

Comment les identités privilégiées sont-elles compromises ?

Les identités privilégiées peuvent être compromises lorsque les organisations ne

disposent d’aucune instruction régissant leur protection. Voici quelques exemples :
 Plus de privilèges que nécessaire. L’un des problèmes les plus courants est que les
utilisateurs disposent de plus de privilèges que nécessaire à l’exécution de leur
fonction. Par exemple, un utilisateur qui gère le DNS peut être un
administrateur AD. Le plus souvent, cela permet d’éviter de devoir configurer
différents niveaux d’administration. Toutefois, si un tel compte est compromis,
l’attaquant a automatiquement accès aux privilèges élevés.

Connexion permanente avec des privilèges élevés. Un autre problème courant est
que les utilisateurs dotés de privilèges élevés peuvent les utiliser pendant une
durée illimitée. Cette situation est très courante, par exemple, lorsque les experts
informatiques qui se connectent à un appareil de bureau par le biais d’un compte
privilégié, restent connectés et utilisent le compte privilégié pour naviguer sur le
Web et envoyer/consulter leurs e-mails (fonctions classiques du travail
informatique). La nature illimitée de la durée d’utilisation des comptes privilégiés
rend le compte plus vulnérable aux attaques et augmente les risques d’une
compromission.

Recherches par le biais de l’ingénierie sociale. Le point de départ de la majorité

des menaces inhérentes aux informations d’identification n’est autre que des
recherches sur l’organisation par le biais de l’ingénierie sociale. Par exemple, un
attaquant peut entreprendre une attaque d’hameçonnage par e-mail pour
compromettre des comptes légitimes (mais pas nécessairement élevés) qui ont
accès au réseau d’une organisation. L’attaquant utilise ensuite ces comptes valides
pour effectuer des recherches supplémentaires sur votre réseau et pour identifier
les comptes privilégiés qui peuvent effectuer des tâches d’administration.

Profit des comptes avec des privilèges élevés. Même avec un compte d’utilisateur
normal (non élevé), les attaquants peuvent accéder aux comptes dotés
d’autorisations élevées dans le réseau. Les méthodes les plus courantes sont les
attaques Pass-the-Hash ou Pass-the-Token. Pour plus d’informations sur les
attaques Pass-the-Hash et d’autres techniques de vol d’informations
d’identification, consultez les ressources sur la page Pass-the-Hash (PtH).

Il existe bien sûr d’autres méthodes qui permettent aux attaquants d’identifier et de
compromettre les identités privilégiées (de nouvelles méthodes sont créées chaque
jour). Il est donc important d’établir des pratiques afin que les utilisateurs se connectent
par le biais de comptes de moindre privilège afin de réduire la capacité des attaquants à
accéder aux identités privilégiées. Les sections ci-dessous décrivent les fonctionnalités
qui permettent à Windows Server d’atténuer ces risques.

Administration juste-à-temps (JIT) et Just Enough Administration

(JEA)
Malgré les méthodes de protection contre les attaques Pass-the-Hash ou Pass-the-
Ticket, les informations d’identification d’administrateur peuvent toujours être volées
par d’autres moyens, notamment l’ingénierie sociale, les employés mécontents et la
force brutale. Par conséquent, en plus d’isoler autant que possible les informations
d’identification, il est également souhaitable de limiter la portée des privilèges de niveau
administrateur en cas de compromission.

À l’heure actuelle, les comptes administrateur sur-privilégiés, même s’ils n’ont qu’un seul
domaine de responsabilité, sont trop nombreux. Par exemple, un administrateur DNS,
qui n’a besoin que de privilèges restreints pour gérer les serveurs DNS, se voit souvent
accorder des privilèges propres à l’administrateur du domaine. En outre, étant donné
que ces informations d’identification sont accordées à perpétuité, aucune limite ne régit
leur durée d’utilisation.

Tout compte disposant, de manière non nécessaire, de privilèges propres à

l’administrateur du domaine accroît votre exposition aux attaquants qui cherchent à
compromettre les informations d’identification. Pour réduire la surface d’attaque,
accordez uniquement les droits spécifiques dont un administrateur a besoin pour
exécuter la tâche, et uniquement pendant la durée nécessaire à l’exécution.

Avec les technologies Just Enough Administration et d’administration juste-à-temps, les

administrateurs peuvent demander les privilèges spécifiques dont ils ont besoin
pendant la durée exacte requise. Pour un administrateur DNS, par exemple, l’utilisation
de PowerShell dans le cadre de la technologie Just Enough Administration vous permet
de créer un ensemble limité de commandes disponibles aux fins de la gestion DNS.

Si l’administrateur DNS doit mettre à jour l’un de ses serveurs, il demande un accès pour
gérer le DNS à l’aide de Microsoft Identity Manager 2016. Le flux de travail de demande
peut inclure un processus d’approbation tel que l’authentification à deux facteurs, qui
peut appeler le téléphone mobile de l’administrateur pour confirmer son identité avant
d’accorder les privilèges demandés. Une fois accordés, ces privilèges DNS confèrent un
accès au rôle PowerShell pour le DNS pendant une période spécifique.

Imaginez que les informations d’identification de l’administrateur DNS ont été volées
dans ce contexte. D’abord, étant donné qu’aucun privilège d’administrateur n’est associé
aux informations d’identification, l’attaquant ne serait pas en mesure d’accéder au
serveur DNS (ou à tout autre système) pour y apporter des modifications. Si l’attaquant
essayait de demander des privilèges pour le serveur DNS, l’authentification à deux
facteurs lui demanderait de confirmer son identité. Étant donné qu’il est peu probable
que l’attaquant dispose du téléphone mobile de l’administrateur DNS, l’authentification
échouerait. Cela empêcherait donc l’attaquant d’entrer dans le système et avertirait le
service informatique de l’organisation que les informations d’identification pourraient
être compromises.

En outre, de nombreuses organisations utilisent la Solution de mot de passe

d’administrateur local (LAPS) gratuite en tant que mécanisme d’administration JIT
simple, mais puissant, pour leurs systèmes de serveur et de client. La LAPS permet de
gérer les mots de passe des comptes locaux sur les ordinateurs joints à un domaine. Les
mots de passe sont stockés dans Active Directory (AD) et protégés par des listes de
contrôle d’accès (ACL). Par conséquent, seuls les utilisateurs éligibles peuvent les lire ou
demander leur réinitialisation.

Comme indiqué dans le Guide d’atténuation du vol d’informations d’identification

Windows ,

« les outils et les techniques utilisés par les criminels pour réaliser des attaques de vol
et de réutilisation d’informations d’identification s’améliorent. Les attaquants
malveillants atteignent plus facilement leurs objectifs. Le vol d’informations
d’identification repose souvent sur des pratiques opérationnelles ou sur l’exposition des
informations d’identification des utilisateurs. Par conséquent, pour efficacement
atténuer ces attaques, une approche holistique inhérente aux personnes, aux processus
et à la technologie est nécessaire. En outre, les attaquants volent les informations
d’identification après avoir compromis un système pour étendre ou préserver l’accès,
de sorte que les organisations doivent contenir les violations rapidement en mettant
en place des stratégies qui empêchent les attaquants de se déplacer librement et sans
être détectés dans un réseau compromis. »

L’atténuation du vol d’informations d’identification, en particulier des informations

d’identification dérivées, était au cœur du processus de conception de Windows Server.
Credential Guard confère une sécurité considérablement améliorée contre le vol et la
réutilisation d’informations d’identification dérivées. L’architecture de Windows a été
modifiée en vue d’éliminer les attaques par isolation basées sur le matériel, plutôt que
de simplement assurer une protection contre celles-ci.

Grâce à Windows Defender Credential Guard, les informations d’identification dérivées

Kerberos et NTLM sont protégées à l’aide d’une sécurité basée sur la virtualisation, et les
techniques et les outils d’attaque de vol d’informations d’identification utilisés dans de
nombreuses attaques ciblées sont bloqués. Les programmes malveillants exécutés dans
le système d’exploitation avec des privilèges administratifs ne peuvent pas extraire les
secrets protégés par la sécurité basée sur la virtualisation. Bien que
Windows Defender Credential Guard permette de réduire efficacement les risques, les
attaques de menace persistante sont susceptibles d’avoir recours à de nouvelles
techniques. Par conséquent, vous devez également intégrer Device Guard, décrit ci-
dessous, et d’autres stratégies et architectures de sécurité.

Windows Defender Credential Guard

Windows Defender Credential Guard utilise la sécurité basée sur la virtualisation pour
isoler les informations d’identification, empêchant ainsi l’interception des hachages de
mot de passe ou des tickets Kerberos. Il a recours à un tout nouveau processus
d’autorité de sécurité locale (LSA) isolée, qui n’est pas accessible aux autres composants
du système d’exploitation. Tous les fichiers binaires utilisés par la LSA isolée sont signés
à l’aide de certificats validés avant leur lancement dans l’environnement protégé ; les
attaques de type Pass-the-Hash sont ainsi complètement inefficaces.

Windows Defender Credential Guard utilise :

Sécurité basée sur la virtualisation (requise) Également requis :

Processeur 64 bits

Extensions de virtualisation d’UC, et tables de pages étendues

Hyperviseur Windows

Démarrage sécurisé (requis)

TPM 2.0 discret ou microprogramme (de préférence, avec liaison au matériel)

Vous pouvez utiliser Windows Defender Credential Guard pour protéger les identités
privilégiées en protégeant les informations d’identification et les informations
d’identification dérivées sur Windows Server 2016. Pour plus d’informations sur les
exigences relatives à Windows Defender Credential Guard, consultez Protéger les
informations d’identification de domaine dérivées avec
Windows Defender Credential Guard.

Windows Defender Remote Credential Guard

Windows Defender Remote Credential Guard sur Windows Server 2016 et la mise à jour
anniversaire Windows 10 permet également de protéger les informations
d’identification des utilisateurs disposant de connexions Bureau à distance. Auparavant,
toute personne utilisant les services Bureau à distance devait se connecter à son
ordinateur local, puis devait à nouveau se connecter lors d’une connexion à distance à
son ordinateur cible. Cette seconde étape de connexion transmettait les informations
d’identification à l’ordinateur cible, ce qui les exposait aux attaques Pass-the-Hash ou
Pass-the-Ticket.

Avec Windows Defender Remote Credential Guard, Windows Server 2016 exécute une
authentification unique pour les sessions Bureau à distance. Ce faisant, vous ne devez
plus entrer une nouvelle fois votre nom d’utilisateur et votre mot de passe.
Windows Server 2016 tire profit des informations d’identification que vous avez déjà
utilisées pour vous connecter à votre ordinateur local. Pour utiliser
Windows Defender Remote Credential Guard, le client et le serveur Bureau à distance
doivent répondre aux exigences suivantes :

Être associés à un domaine Active Directory et se trouver dans le même domaine

ou un domaine doté d’une relation d’approbation.

Utiliser l’authentification Kerberos.

Exécuter au moins Windows 10 version 1607 ou Windows Server 2016.

L’application Windows classique Bureau à distance est requise. L’application

Bureau à distance de la plateforme Windows universelle ne prend pas en charge
Windows Defender Remote Credential Guard.

Vous pouvez activer Windows Defender Remote Credential Guard par le biais d’un
paramètre de registre sur le serveur Bureau à distance et d’un paramètre de stratégie de
groupe ou de connexion Bureau à distance sur le client Bureau à distance. Pour plus
d’informations sur l’activation de Windows Defender Remote Credential Guard,
consultez Protéger les informations d’identification Bureau à distance avec Windows
Defender Remote Credential Guard. À l’instar de Windows Defender Credential Guard,
vous pouvez utiliser Windows Defender Remote Credential Guard pour protéger les
identités privilégiées sur Windows Server 2016.

Sécurisation du système d’exploitation pour exécuter vos

applications et votre infrastructure
Aux fins de la prévention des cybermenaces, il est également nécessaire de trouver et de
bloquer les programmes malveillants et les attaques qui cherchent à prendre le contrôle
en minant les pratiques d’exploitation standard de votre infrastructure. Si les attaquants
parviennent à ce qu’un système d’exploitation ou une application s’exécute d’une
manière non prédéterminée et non viable, ils utilisent probablement ce système pour
effectuer des actions malveillantes. Windows Server 2016 offre des couches de
protection qui empêchent les attaquants externes d’exécuter des logiciels malveillants
ou d’exploiter des vulnérabilités. Le système d’exploitation protège activement
l’infrastructure et les applications en alertant les administrateurs en cas d’activité
indiquant la violation d’un système.

Windows Defender Device Guard

Windows Server 2016 inclut Windows Defender Device Guard pour garantir que seuls
les logiciels approuvés peuvent être exécutés sur le serveur. La sécurité basée sur la
virtualisation lui permet de limiter les fichiers binaires qui peuvent s’exécuter sur le
système selon la stratégie de l’organisation. Si un composant, autre que les fichiers
binaires spécifiés, tente de s’exécuter, Windows Server 2016 le bloque et journalise
l’échec de tentative afin que les administrateurs puissent voir qu’il y a eu une violation
potentielle. La notification de violation est une composante essentielle des exigences de
conformité au RGPD.

Windows Defender Device Guard est également intégré à PowerShell afin que vous
puissiez autoriser les scripts qui peuvent s’exécuter sur votre système. Dans les versions
antérieures de Windows Server, les administrateurs pouvaient contourner l’application
de l’intégrité du code en supprimant simplement la stratégie du fichier de code. Avec
Windows Server 2016, vous pouvez configurer une stratégie signée par votre
organisation afin que seule une personne ayant accès au certificat de signature de la
stratégie puisse modifier ladite stratégie.

Control Flow Guard

Windows Server 2016 inclut également une protection intégrée contre certaines classes
d’attaques de corruption de mémoire. Il est important de retoucher vos serveurs, mais il
y a toujours un risque que des programmes malveillants puissent être développés pour
une vulnérabilité qui n’a pas encore été identifiée. Certaines des méthodes les plus
courantes pour exploiter ces vulnérabilités consistent à fournir des données
inhabituelles ou extrêmes à un programme en cours d’exécution. Par exemple, un
attaquant peut exploiter une vulnérabilité de dépassement de mémoire tampon en
fournissant plus d’entrées que prévu à un programme et dépasser la zone réservée par
le programme pour contenir une réponse. Cela peut endommager la mémoire adjacente
qui peut contenir un pointeur de fonction.

Lorsque le programme exécute un appel par le biais de cette fonction, il peut accéder à
un emplacement imprévu spécifié par l’attaquant. Ces attaques sont également
appelées attaques Jump-Oriented Programming (JOP). Control Flow Guard empêche les
attaques JOP en prévoyant des restrictions strictes quant au code d’application qui peut
être exécuté, en particulier les instructions d’appel indirect. Il intègre des vérifications de
sécurité légères en vue d’identifier l’ensemble de fonctions dans l’application qui
constituent des cibles valides pour les appels indirects. Lorsqu’une application s’exécute,
Control Flow Guard vérifie la validité de ces cibles d’appels indirects.

Si la vérification de Control Flow Guard échoue au moment de l’exécution,

Windows Server 2016 arrête immédiatement le programme, ce qui interrompt toute
exploitation qui tente d’appeler indirectement une adresse non valide.
Control Flow Guard offre une couche supplémentaire importante de protection à
Device Guard. Si une application de liste d’autorisation a été compromise, elle pourrait
s’exécuter sans avoir été vérifiée par Device Guard, car le processus de filtrage de
Device Guard déterminerait que l’application a été signée et est approuvée.

Toutefois, étant donné que Control Flow Guard peut identifier si l’application s’exécute
dans un ordre non prédéterminé et non viable, l’attaque échouerait, et l’application
compromise ne pourrait pas s’exécuter. Lorsque ces protections sont utilisées ensemble,
il très difficile pour les attaquants d’injecter des programmes malveillants dans des
logiciels s’exécutant sur Windows Server 2016.

Les développeurs qui créent des applications de gestion de données personnelles sont
encouragés à activer Control Flow Guard (CFG) dans leurs applications. Cette
fonctionnalité est disponible dans Microsoft Visual Studio 2015 et s’exécute sur les
versions « compatibles avec CFG » de Windows, à savoir les versions x86 et x64 de
Desktop et Server de Windows 10 et de la mise à jour Windows 8.1 (KB3000850). Vous
ne devez pas activer CFG pour chaque partie de votre code, car un mélange de code
avec CFG activé et sans CFG activé s’exécute correctement. Toutefois, le fait de ne pas
activer CFG pour l’ensemble du code peut créer une brèche dans la protection. En outre,
le code avec CFG activé fonctionne parfaitement sur les versions « non compatibles avec
CFG » de Windows et est donc totalement compatible avec celles-ci.

Antivirus Windows Defender

Windows Server 2016 inclut les fonctionnalités de pointe de détection active de

Windows Defender pour bloquer les programmes malveillants connus.
Windows Defender Antivirus (AV) fonctionne avec Windows Defender Device Guard et
Control Flow Guard pour empêcher l’installation, sur vos serveurs, de code malveillant
de quelque nature que ce soit. Il est activé par défaut. L’administrateur n’a rien à faire.
Windows Defender est également optimisé pour prendre en charge les différents rôles
de serveur dans Windows Server 2016. Auparavant, les attaquants utilisaient des shells,
tels que PowerShell, pour lancer du code binaire malveillant. Dans Windows Server 2016,
PowerShell est désormais intégré à Windows Defender AV et analyse les programmes
malveillants avant de lancer le code.
Windows Defender AV est une solution anti-programmes malveillants intégrée qui
confère des fonctionnalités de gestion de sécurité et de protection contre les
programmes malveillants pour les appareils de bureau, les ordinateurs portables et les
serveurs. Windows Defender AV a été considérablement amélioré depuis son
introduction dans Windows 8. Windows Defender Antivirus dans Windows Server a
recours à une approche à plusieurs volets pour renforcer la protection contre les
programmes malveillants :

La protection assurée par le cloud permet de détecter et de bloquer les nouveaux

programmes malveillants en quelques secondes, même si le programme
malveillant n’a jamais été identifié auparavant.

Le contexte local enrichi améliore l’identification des programmes malveillants.

Windows Server signale à Windows Defender AV non seulement les contenus
(fichiers et processus), mais également leur provenance, leur emplacement de
stockage, etc.

Les capteurs globaux étendus maintiennent Windows Defender AV à jour et

signalent les derniers programmes malveillants en date. Ceci, de deux façons : en
collectant les données du contexte local enrichi à partir de points de terminaison
et en analysant ces données de manière centralisée.

La protection contre les falsifications permet à Windows Defender AV de se

protéger contre les attaques de programmes malveillants. Par exemple,
Windows Defender AV utilise des processus protégés qui empêchent les processus
non approuvés de falsifier les composants de Windows Defender AV, ses clés de
registre, etc.

Les fonctionnalités au niveau de l’entreprise offrent aux experts informatiques les

outils et les options de configuration nécessaires pour configurer
Windows Defender AV en tant que solution anti-programmes malveillants
d’entreprise.

Audit de sécurité amélioré

Windows Server 2016 alerte activement les administrateurs en cas de tentatives de
violation potentielle grâce à un audit de sécurité amélioré qui génère des informations
plus détaillées, qui peuvent être utilisées pour accélérer la détection des attaques et
l’analyse d’investigation. Il journalise les événements de Control Flow Guard,
Windows Defender Device Guard et d’autres fonctionnalités de sécurité dans un
emplacement unique, ce qui permet aux administrateurs de déterminer plus facilement
les systèmes à risque.
Les nouvelles catégories d’événements sont les suivantes :

Audit de l’appartenance à un groupe. Cela vous permet d’auditer les informations

d’appartenance à un groupe dans le jeton de connexion d’un utilisateur. Des
événements sont générés lorsque des appartenances à un groupe sont énumérées
ou interrogées sur le PC sur lequel la session de connexion a été créée.

Audit de l’activité PnP. Cela vous permet d’auditer la détection par Plug-and-Play
d’un appareil externe, qui peut contenir des programmes malveillants. Les
événements PnP peuvent être utilisés pour suivre les modifications apportées au
matériel du système. Une liste des ID de fournisseurs de matériel est incluse dans
l’événement.

Windows Server 2016 s’intègre facilement aux systèmes de gestion des événements
d’incident de sécurité (SIEM), tels que Microsoft Operations Management Suite (OMS),
qui peuvent saisir des informations dans les rapports de veille sur les violations
potentielles. La nature détaillée des informations fournies par l’audit amélioré permet
aux équipes de sécurité d’identifier les violations potentielles et d’y répondre plus
rapidement et plus efficacement.

Virtualisation sécurisée
À l’heure actuelle, les entreprises virtualisent tout ce qu’elles peuvent, de SQL Server à
SharePoint, en passant par les contrôleurs domaine Active Directory. Les machines
virtuelles (VM) facilitent le déploiement, la gestion, la maintenance et l’automatisation
de votre infrastructure. Toutefois, sur le plan de la sécurité, les structures de
virtualisation compromises sont un nouveau vecteur d’attaque contre lequel il est
difficile de se protéger, jusqu’à présent. Dans le cadre du RGPD, vous devez penser à
protéger les machines virtuelles comme vous le feriez pour protéger les serveurs
physiques, notamment à l’aide de la technologie TPM pour machine virtuelle.

Windows Server 2016 révolutionne la sécurisation de la virtualisation des entreprises. Il

inclut plusieurs technologies qui vous permettent de créer des machines virtuelles qui
s’exécuteront uniquement sur votre propre structure, ce qui renforce la protection
contre le stockage, le réseau et les appareils hôtes sur lesquels elles s’exécutent.

Machines virtuelles dotées d’une protection maximale

Les composants qui facilitent la migration, la sauvegarde et la réplication des machines
virtuelles facilitent également leur modification et leur copie. Une machine virtuelle n’est
qu’un fichier ; elle n’est donc pas protégée sur le réseau, dans le stockage, dans les
sauvegardes, ou dans d’autres emplacements. Un autre problème se pose : les
administrateurs de structure, qu’ils soient administrateurs de stockage ou
administrateurs de réseau, ont accès à toutes les machines virtuelles.

Un administrateur compromis au sein de la structure peut facilement contribuer à la

compromission des données des machines virtuelles. L’attaquant n’a qu’à utiliser les
informations d’identification compromises pour copier les fichiers de machine virtuelle
de son choix sur un lecteur USB et accéder à ces fichiers de machine virtuelle à partir de
n’importe quel autre système. Si l’une de ces machines virtuelles volées était un
contrôleur de domaine Active Directory, par exemple, l’attaquant pourrait facilement en
consulter le contenu et utiliser des techniques de force brutale aisément accessibles
pour déchiffrer les mots de passe dans la base de données Active Directory, ce qui lui
donnerait finalement accès à tous les autres composants et éléments de votre
infrastructure.

Windows Server 2016 intègre des machines virtuelles dotées d’une protection maximale
pour vous protéger contre de tels scénarios. Les machines virtuelles dotées d’une
protection maximale incluent un appareil TPM virtuel, qui permet aux organisations de
chiffrer, par BitLocker, leurs machines virtuelles et de garantir que celles-ci s’exécutent
uniquement sur des hôtes approuvés pour vous protéger contre les administrateurs de
stockage, de réseau et d’hôte compromis. Les machines virtuelles dotées d’une
protection maximale sont créées à l’aide de machines virtuelles de 2e génération, qui
prennent en charge le microprogramme UEFI (Unified Extensible Firmware Interface) et
disposent d’un TPM virtuel.

Service Guardian hôte

Outre les machines virtuelles dotées d’une protection maximale, le service Guardian
hôte est un composant essentiel pour la création d’une structure de virtualisation
sécurisée. Il permet d’attester l’intégrité d’un hôte Hyper-V avant d’autoriser le
démarrage et la migration d’une machine virtuelle dotée d’une protection maximale
vers cet hôte. Il contient les clés des machines virtuelles dotées d’une protection
maximale et les libère uniquement lorsque l’intégrité de la sécurité est assurée. Il existe
deux façons d’attester l’intégrité de la sécurité par les hôtes Hyper-V auprès du service
Guardian hôte.

La première façon, qui est la plus sécurisée, est l’attestation approuvée matérielle. Pour
le bon fonctionnement de cette solution, vos machines virtuelles dotées d’une
protection maximale doivent s’exécuter sur des hôtes dotés de circuits TPM 2.0 et
d’UEFI 2.3.1. Ce matériel est nécessaire pour fournir les informations de démarrage
mesuré et d’intégrité du noyau du système d’exploitation requises par le service
Guardian hôte afin de garantir que l’hôte Hyper-V n’a pas été falsifié.
Les organisations informatiques peuvent aussi utiliser l’attestation approuvée
administrative, qui peut être souhaitable si le matériel TPM 2.0 n’est pas utilisé au sein
de votre organisation. Ce modèle d’attestation est facile à déployer, car les hôtes sont
simplement placés dans un groupe de sécurité et le service Guardian hôte est configuré
pour permettre aux machines virtuelles dotées d’une protection maximale de s’exécuter
sur des hôtes membres du groupe de sécurité. Grâce à cette méthode, il est facile de
s’assurer que l’ordinateur hôte n’a pas été falsifié. Vous éliminez toute possibilité que
des machines virtuelles non chiffrées soient copiées sur des lecteurs USB ou que la
machine virtuelle s’exécute sur un hôte non autorisé. En effet, les fichiers de machine
virtuelle ne s’exécuteront pas sur une machine autre que celles du groupe désigné. Si
vous n’avez pas encore le matériel TPM 2.0, vous pouvez commencer avec une
attestation approuvée administrative et passer à une attestation approuvée matérielle
lorsque votre matériel est mis à niveau.

Module de plateforme sécurisée de machine virtuelle

Windows Server 2016 prend en charge le TPM pour les machines virtuelles, ce qui
permet de prendre en charge des technologies de sécurité avancées telles que le
chiffrement de lecteur BitLocker® dans les machines virtuelles. Vous pouvez activer la
prise en charge du TPM sur n’importe quelle machine virtuelle Hyper-V de
2e génération, avec le gestionnaire Hyper-V ou l’applet de commande
Windows PowerShell Enable-VMTPM.

Vous pouvez protéger le TPM virtuel (vTPM) à l’aide des clés de chiffrement locales
stockées sur l’hôte ou dans le service Guardian hôte. Le service Guardian hôte requiert
plus d’infrastructures, mais il assure une meilleure protection.

Pare-feu de réseau distribué utilisant la mise en réseau à définition

logicielle
Afin d’améliorer la protection dans les environnements virtualisés, il convient de
segmenter le réseau de façon à ce que les machines virtuelles puissent communiquer
uniquement avec les systèmes spécifiques au fonctionnement. Par exemple, si votre
application n’a pas besoin de se connecter à Internet, vous pouvez la diviser en
partitions. Ce faisant, ces systèmes ne sont plus des cibles pour les attaquants externes.
La mise en réseau à définition logicielle (SDN) dans Windows Server 2016 inclut un
pare-feu de réseau distribué. Ce dernier vous permet de créer dynamiquement les
stratégies de sécurité qui visent à protéger vos applications contre les attaques internes
ou externes à un réseau. Ce pare-feu de réseau distribué ajoute des couches à votre
sécurité en vous permettant d’isoler vos applications au sein du réseau. Les stratégies
peuvent être appliquées dans toute votre infrastructure de réseau virtuel. Elles
permettent d’isoler le trafic de machine virtuelle à machine virtuelle, le trafic de machine
virtuelle à hôte, ou le trafic de machine virtuelle à Internet, si nécessaire, que ce soit
pour des systèmes individuels qui pourraient être compromis ou par programmation sur
plusieurs sous-réseaux. Les fonctionnalités de mise en réseau de Windows Server 2016
définies par logiciel vous permettent également d’acheminer ou de mettre en miroir le
trafic entrant vers des appliances virtuelles non Microsoft. Par exemple, vous pouvez
envoyer l’intégralité de votre trafic d’e-mails par le biais d’une appliance virtuelle
Barracuda pour assurer une protection supplémentaire contre le filtrage des courriers
indésirables. Cela vous permet de renforcer facilement la sécurité localement ou dans le
cloud.

Autres considérations relatives au RGPD concernant les

serveurs
Le RGPD prévoit des exigences explicites de notification des violations, une violation de
données personnelles étant « une violation de la sécurité entraînant la destruction
accidentelle ou illégale, la perte, l’altération, la divulgation non autorisée ou l’accès aux
données personnelles transmises, stockées ou traitées ». Il est évident que vous ne pouvez
pas essayer de répondre aux exigences strictes du RGPD en matière de notification dans
les 72 heures si vous ne pouvez pas détecter la violation en premier lieu.

Comme indiqué dans le livre blanc du centre de sécurité Windows, Post Breach: Dealing
with Advanced Threats,

« Contrairement à la préviolation, la postviolation suppose qu’une violation a déjà eu

lieu, à titre d’enregistreur de version d’évaluation et d’enquêteur de scène de crime
(CSI). La postviolation fournit aux équipes de sécurité les informations et l’ensemble
d’outils nécessaires pour identifier et examiner les attaques qui, autrement, ne seraient
pas détectées, et pour y répondre. »

Cette section explique comment Windows Server peut vous aider à respecter vos
obligations en matière de notification de violation dans le cadre du RGPD. Vous devez
d’abord comprendre les données de menace sous-jacentes disponibles pour Microsoft
qui sont collectées et analysées dans votre intérêt. Vous devez aussi comprendre
comment ces données, grâce à Windows Defender Advanced Threat Protection (ATP),
peuvent être critiques pour vous.

Données de diagnostic de sécurité pertinentes

Depuis près de vingt ans, Microsoft transforme les menaces en informations utiles pour
renforcer sa plateforme et protéger ses clients. À l’heure actuelle, grâce au cloud et à ses
considérables avantages, nous trouvons de nouvelles façons d’utiliser nos moteurs
d’analytique enrichis pilotés par la veille des menaces pour protéger nos clients.

En adoptant une combinaison de processus automatisés et manuels, de machine

learning et d’experts humains, nous pouvons créer un Intelligent Security Graph qui
apprend de lui-même et évolue en temps réel, réduisant ainsi le temps que nous
consacrons collectivement à la détection et à la réponse aux nouveaux incidents dans
nos produits.

La fonction de veille des menaces de Microsoft s’étend littéralement à des milliards de

points de données : 35 milliards de messages analysés chaque mois, 1 milliard de clients
dans les segments des entreprises et des clients accédant à plus de 200 services cloud,
et 14 milliards d’authentifications effectuées quotidiennement. Toutes ces données sont
rassemblées en votre nom par Microsoft pour créer l’Intelligent Security Graph et vous
aider à protéger dynamiquement vos points d’entrée. Ce faisant, votre sécurité, votre
productivité et votre conformité aux exigences du RGPD sont garanties.

Détection des attaques et investigation

Même les meilleurs composants et processus de défense de point de terminaison

peuvent finir par être violés, les cyberattaques étant de plus en plus sophistiquées et
ciblées. Deux fonctionnalités facilitent la détection des violations potentielles : Windows
Defender Advanced Threat Protection (ATP) and Microsoft Advanced Threat Analytics
(ATA).

Windows Defender Advanced Threat Protection (ATP) vous permet de détecter et

d’examiner les attaques avancées et les violations de données sur vos réseaux, et d’y
répondre. Dans le cadre du RGPD, vous êtes tenu de vous protéger contre les violations
de données par le biais de mesures de sécurité techniques pour garantir la
confidentialité, l’intégrité et la disponibilité permanentes des données personnelles et
des systèmes de traitement.

Les principaux avantages de Windows Defender ATP sont les suivants :

Détection des éléments indétectables. Capteurs intégrés au noyau du système

d’exploitation, experts en sécurité Windows et optique unique provenant de plus
de 1 milliard de machines et de signaux sur l’ensemble des services Microsoft.

Fonctionnalité intégrée, non complémentaire. Sans agent, avec des performances

élevées et des répercussions minimales, dans le cloud ; gestion facile sans
déploiement.

Volet unique pour la sécurité Windows. Découvrez 6 mois d’événements de

sécurité et de chronologie de machine unifiés et enrichis, par rapport à Windows
Defender ATP, à Windows Defender Antivirus et à Windows Defender Device
Guard.

Puissance de Microsoft Graph. Microsoft Intelligence Security Graph est mis à

profit pour intégrer la détection et l’exploration à l’abonnement ATP Office 365,
afin de suivre les attaques et d’y répondre.

Pour plus d’informations, consultez Nouveautés de la version préliminaire de Windows

Defender ATP Creators Update .

ATA est un produit local qui permet de détecter les compromissions d’identités au sein
d’une organisation. ATA peut capturer et analyser le trafic réseau pour les protocoles
d’authentification, d’autorisation et de collecte d’informations (tels que Kerberos, DNS,
RPC, NTLM, etc.). ATA utilise ces données pour créer un profil comportemental
concernant les utilisateurs et d’autres entités d’un réseau, afin de détecter les anomalies
et les modèles d’attaque connus. Le tableau suivant répertorie les types d’attaques
détectés par ATA.

Type Description
d’attaque
 Type Description
d’attaque

Attaques Ces attaques sont détectées en recherchant des attaques répertoriées dans une
malveillantes liste connue de types d’attaques, notamment :
Pass-the-Ticket (PtT)
Pass-the-Hash (PtH)
Overpass-the-Hash
Faux PAC (MS14-068)
Golden Ticket
Réplications malveillantes
Reconnaissance
Force brute
Exécution à distance

Pour obtenir la liste complète des attaques malveillantes pouvant être détectées
et consulter leur description, reportez-vous à Quelles activités suspectes ATA
peut-il détecter ?

Comportement Ces attaques sont détectées par le biais d’une analyse comportementale et
anormal exploitent le machine learning pour identifier les activités douteuses,
notamment :
Connexions anormales
Menaces inconnues
Partage de mot de passe
Mouvement latéral

Problèmes et Ces attaques sont détectées en examinant la configuration actuelle du réseau et

risques de du système, notamment :
sécurité Relation de confiance rompue
Protocoles faibles
Vulnérabilités de protocole connues

Vous pouvez utiliser ATA pour détecter les attaquants qui tentent de compromettre les
identités privilégiées. Pour plus d’informations sur le déploiement d’ATA, consultez les
rubriques Planification, Conception et Déploiement dans la documentation Advanced
Threat Analytics.

Contenu connexe pour les solutions

Windows Server 2016 associées
Windows Defender Antivirus :
Windows Defender Antivirus (vidéo YouTube)
Paramètres Antivirus Microsoft Defender
 Windows Defender Advanced Threat Protection :

Aperçu de Windows Defender Advanced Threat Protection pour Windows 10

Creators Update (vidéo YouTube)

Embarquer des serveurs Windows dans le service Microsoft Defender for Endpoint

Windows Defender Device Guard :

Windows Defender Device Guard (vidéo YouTube)

Déploiement de stratégies Windows Defender Application Control (WDAC)

Windows Defender Credential Guard :Windows Defender Credential Guard (vidéo

YouTube)

Protéger les informations d’identification de domaine dérivées avec Windows

Defender Credential Guard

Control Flow Guard :

Control Flow Guard pour la sécurité de la plateforme

Sécurité et assurance :

Documentation sur la sécurité de Windows Server

Clause d'exclusion de responsabilité

Cet article est un commentaire sur le RGPD, tel que Microsoft l’interprète, à la date
de publication. Nous nous sommes beaucoup consacrés au RGPD, et nous aimons à
croire que nous avons judicieusement réfléchi à son intention et à sa signification. Mais
l’application du RGPD est vraiment spécifique aux faits, et tous les aspects et
interprétations du RGPD ne sont pas bien établis.

Dès lors, cet article sert uniquement à titre d’information et ne doit pas être considéré
comme un avis juridique ou comme un moyen de déterminer l’application du RGPD à
votre organisation et à vous. Nous vous encourageons à collaborer avec un
professionnel légalement qualifié pour discuter du RGPD, de son application spécifique
à votre organisation et de la meilleure façon d’en garantir la conformité.

MICROSOFT NE DONNE AUCUNE GARANTIE, EXPLICITE, IMPLICITE OU STATUTAIRE, EN

CE QUI CONCERNE LES INFORMATIONS DE CET ARTICLE. Cet article est fourni en l’état.
Les informations et idées exprimées dans cet article, y compris les URL et autres
références à des sites Web sur Internet, peuvent faire l’objet de modifications sans
préavis.
Cet article ne vous fournit aucun droit légal de propriété intellectuelle de tout produit
Microsoft. Vous pouvez copier le présent article pour une utilisation interne à des fins de
référence uniquement.

Publié en septembre 2017

Version 1.0
© 2017 Microsoft. Tous droits réservés.
Qu’est-ce qu’un serveur à noyau
sécurisé ?
Article • 19/04/2023

S’applique à : Windows Server 2022, Azure Stack HCI version 21H2 et ultérieur

Le concept de noyau sécurisé regroupe un ensemble de fonctionnalités de sécurité

intégrées pour le matériel, les microprogrammes, les pilotes et les systèmes
d’exploitation. La protection fournie par les systèmes à noyau sécurisé commence avant
que ne démarre le système d’exploitation et se poursuit pendant l’exécution. Un serveur
à noyau sécurisé est conçu pour fournir une plateforme sécurisée pour les données et
les applications critiques.

Un serveur à noyau sécurisé repose sur trois piliers de sécurité clés :

Création d’une racine de confiance matérielle.

Défense contre les attaques au niveau des microprogrammes.

Protection du système d’exploitation contre l’exécution de code non vérifié.

Comment reconnaître un serveur à noyau

sécurisé
L’initiative du concept de noyau sécurisé a commencé avec les PC Windows grâce à une
collaboration étroite entre Microsoft et des fabricants de PC partenaires visant à fournir
une sécurité Windows encore jamais atteinte. Microsoft a étendu son partenariat à des
fabricants de serveurs partenaires pour s’assurer que Windows Server fournit un
environnement de système d’exploitation sécurisé.

Windows Server est étroitement intégré au matériel pour fournir des niveaux de sécurité
croissants :

Base de référence recommandée : valeur minimale recommandée pour tous les

systèmes afin de fournir une intégrité système de base avec TPM 2.0 pour une
racine matérielle de confiance et un démarrage sécurisé. TPM 2.0 et un démarrage
sécurisé sont requis pour la certification matérielle de Windows Server. Pour en
savoir plus, consultez Microsoft hausse les standards de sécurité dans la prochaine
version majeure de Windows Server .
 Serveur à noyau sécurisé : recommandé pour les systèmes et les secteurs d’activité
nécessitant des niveaux d’assurance plus élevés. Un serveur à noyau sécurisé
s’appuie sur les fonctionnalités précédentes et utilise des fonctionnalités de
processeur avancées pour fournir une protection contre les attaques de
microprogramme.

Le tableau suivant montre comment chaque concept et chaque fonctionnalité de

sécurité sont utilisés pour créer un serveur à noyau sécurisé.

Concept Fonctionnalité Condition requise Base de Serveur

référence à noyau
recommandée sécurisé

Créer une racine

de confiance
matérielle

Démarrage Le Démarrage sécurisé est ✓ ✓

sécurisé activé par défaut dans le
BIOS UEFI (Unified Extensible
Firmware Interface).

Trusted Répond aux dernières ✓ ✓

Platform exigences de Microsoft pour
Module la spécification TCG (Trusted
(TPM) 2.0 Computing Group).

Certifié pour Indique qu'un système ✓ ✓

Windows serveur atteint la barre
Server technique la plus élevée de
Microsoft en matière de
sécurité, de fiabilité et de
facilité de gestion.

Protection Prise en charge sur les ✓

DMA au appareils qui ont l’unité
démarrage IOMMU (Input/Output
Memory Management Unit).
Par exemple, Intel VT-D ou
AMD-Vi.

Se défendre
contre les
attaques au
niveau des
microprogrammes
 Concept Fonctionnalité Condition requise Base de Serveur
référence à noyau
recommandée sécurisé

Lancement Activé dans le système ✓

sécurisé de d’exploitation avec du
System Guard matériel Intel et AMD
compatible avec DRTM
(Dynamic Root of Trust for
Measurement).

Protéger le
système
d’exploitation
contre l’exécution
de code non
vérifié

sécurité basée Nécessite l’hyperviseur ✓ ✓

sur la Windows, qui est
virtualisation uniquement pris en charge
(VBS) sur les processeurs 64 bits
avec des extensions de
virtualisation, notamment
Intel VT-X et AMD-v.

HVCI Pilotes compatibles avec ✓ ✓

(Hypervisor HVCI (Hypervisor Code
Enhanced Integrity) et exigences VBS.
Code Integrity)

Créer une racine de confiance basée sur le matériel

Le Démarrage sécurisé UEFI est un standard de sécurité qui protège vos serveurs contre
les rootkits malveillants en vérifiant les composants de démarrage de vos systèmes. Le
Démarrage sécurisé vérifie qu’un auteur approuvé a signé numériquement les pilotes et
applications du microprogramme UEFI. Lorsque le serveur est démarré, le
microprogramme vérifie la signature de chaque composant de démarrage, y compris les
pilotes du microprogramme et le système d’exploitation. Si les signatures sont valides, le
serveur démarre et le microprogramme donne le contrôle au système d’exploitation.

Pour en savoir plus sur le processus de démarrage, consultez Sécuriser le processus de

démarrage Windows.

TPM 2.0 fournit un stockage sécurisé et basé sur le matériel pour les clés et données
sensibles. Chaque composant chargé pendant le processus de démarrage est mesuré et
les mesures sont stockées dans le module TPM. En vérifiant la racine de confiance
matérielle, il élève la protection fournie par des fonctionnalités telles que BitLocker, qui
utilise TPM 2.0 et facilite la création de workflows basés sur des attestations. Ces
workflows basés sur les attestations peuvent être incorporés dans des stratégies de
sécurité de Confiance Zéro.

Découvrez plus en détail les modules de plateforme sécurisée et l’utilisation du module

TPM par Windows.

En plus du Démarrage sécurisé et de TPM 2.0, la fonctionnalité Noyau sécurisé de

Windows Server utilise la protection DMA au démarrage sur les processeurs compatibles
qui disposent de l’unité IOMMU (Input/Output Memory Management Unit). Par
exemple, Intel VT-D ou AMD-Vi. Avec la protection DMA au démarrage, les systèmes
sont protégés contre les attaques d’accès direct à la mémoire (DMA) pendant le
démarrage et pendant l’exécution du système d’exploitation.

Se défendre contre les attaques au niveau des

microprogrammes
Les solutions de protection et de détection des points de terminaison ont généralement
une visibilité limitée du microprogramme, étant donné que le microprogramme
s’exécute derrière le système d’exploitation. Le microprogramme a un niveau d’accès et
de privilège plus élevé que le système d’exploitation et le noyau de l’hyperviseur, ce qui
en fait une cible intéressante pour les attaquants. Les attaques ciblant le
microprogramme affaiblissent les autres mesures de sécurité implémentées par le
système d’exploitation, ce qui rend plus difficile l’identification d’un système ou d’un
utilisateur compromis.

À compter de Windows Server 2022, le lancement sécurisé de System Guard protège le

processus de démarrage contre les attaques de microprogramme à l’aide des
fonctionnalités matérielles d’AMD et d’Intel. Avec la prise en charge des processeurs par
la technologie DRTM (Dynamic Root of Trust for Measurement), les serveurs à noyau
sécurisé placent le microprogramme dans un bac à sable matériel afin de limiter les
effets des vulnérabilités dans le code de microprogramme à privilèges élevés. System
Guard utilise les fonctionnalités DRTM qui sont intégrées à des processeurs compatibles
pour lancer le système d’exploitation, en veillant à ce que le système se lance dans un
état approuvé en utilisant du code vérifié.

Protéger le système d’exploitation contre l’exécution de

code non vérifié
Un serveur à noyau sécurisé utilise la sécurité basée sur la virtualisation (VBS) et
l’intégrité du code protégée par l’hyperviseur (HVCI) pour créer et isoler une région
sécurisée de la mémoire du système d’exploitation normal. VBS utilise l’hyperviseur
Windows pour créer un mode sécurisé virtuel (VSM, Virtual Secure Mode) afin d’offrir
des barrières de sécurité au sein du système d’exploitation, qui peuvent être utilisées
pour d’autres solutions de sécurité.

HVCI, communément appelé protection de l’intégrité de la mémoire, est une solution de

sécurité qui permet de s’assurer que seul le code signé et approuvé est autorisé à
s’exécuter dans le noyau. L’utilisation de code signé et approuvé uniquement empêche
les attaques qui tentent de modifier le code en mode noyau. Par exemple, les attaques
qui modifient les pilotes ou les programmes malveillants comme WannaCry qui tentent
d’injecter du code malveillant dans le noyau.

Pour en savoir plus sur VBS et la configuration matérielle requise, consultez Sécurité
basée sur la virtualisation.

Gestion simplifiée
Vous pouvez afficher et configurer les fonctionnalités de sécurité de système
d’exploitation des systèmes à noyau sécurisé avec Windows PowerShell ou l’extension
de sécurité dans Windows Admin Center. Avec les systèmes intégrés Azure Stack HCI, les
fabricants partenaires ont encore plus simplifié l’expérience de configuration pour les
clients afin que la meilleure sécurité des serveurs de Microsoft soit disponible dès le
départ.


Explorez plus en détail Windows Admin Center.

Défense préventive
En activant la fonctionnalité de serveur à noyau sécurisé, vous pouvez vous défendre de
manière proactive et bloquer la plupart des méthodes utilisées par les attaquants pour
exploiter les failles de sécurité des systèmes. Un serveur à noyau sécurisé permet d’avoir
des fonctionnalités de sécurité avancées dans les couches inférieures de la pile
technologique qui protègent les zones les plus privilégiées du système avant que de
nombreux outils de sécurité n’aient connaissance de programmes malveillants. Cette
défense ne nécessite pas de tâches ou de surveillance supplémentaires de la part des
équipes du service informatique et SecOps.

Commencer votre parcours vers un serveur à

noyau sécurisé
Vous trouverez le matériel certifié pour les serveurs à noyau sécurisé dans le catalogue
Windows Server et pour les serveurs Azure Stack HCI dans le catalogue Azure
Stack HCI . Ces serveurs certifiés sont entièrement équipés avec des atténuations de
sécurité de pointe intégrées au matériel, au microprogramme et au système
d’exploitation pour aider à contrecarrer certains des vecteurs d’attaque les plus avancés.

Étapes suivantes
Maintenant que vous savez ce qu’est un serveur à noyau sécurisé, voici quelques
ressources pour vous aider à démarrer. Découvrez comment :

Microsoft apporte une sécurité matérielle avancée à Server et Edge avec les
serveurs à noyau sécurisé dans le blog sur la sécurité Microsoft.
De nouveaux serveurs à noyau sécurisé sont disponibles dans l’écosystème
Microsoft pour vous aider à sécuriser votre infrastructure dans le blog sur la
sécurité Microsoft.
Créer des appareils, systèmes et pilotes de filtrage compatibles avec Windows sur
toutes les plateformes Windows dans Spécifications et stratégies du programme
de compatibilité matérielle Windows.
Configurer le serveur à noyau sécurisé
Article • 04/09/2023

Le concept de noyau sécurisé regroupe un ensemble de fonctionnalités de sécurité

intégrées pour le matériel, les microprogrammes, les pilotes et les systèmes
d’exploitation. Cet article vous montre comment configurer le serveur Secured-core à
l'aide de Windows Admin Center, de Windows Server Desktop Experience et de la
stratégie de groupe.

Un serveur à noyau sécurisé est conçu pour fournir une plateforme sécurisée pour les
données et les applications critiques. Pour plus d’informations, consultez Qu’est-ce
qu’un serveur Secured-core ?

Prérequis
Avant de pouvoir configurer le serveur Secured-core, vous devez avoir installé et activé
les composants de sécurité suivants dans le BIOS :

Démarrage sécurisé.
Module de plateforme sécurisée (TPM) 2.0.
Le micrologiciel du système doit répondre aux exigences de protection DMA avant
le démarrage et définir les indicateurs appropriés dans les tables ACPI pour activer
et activer la protection DMA du noyau. Pour en savoir plus sur la protection DMA
du noyau, consultez Protection DMA du noyau (protection de l'accès à la mémoire)
pour les OEM.
Un processeur avec prise en charge activée dans le BIOS pour :
Extensions de virtualisation.
Unité de gestion de mémoire d'entrée/sortie (IOMMU).
Racine de confiance dynamique pour la mesure (DRTM).
Le cryptage transparent et sécurisé de la mémoire est également requis pour les
systèmes basés sur AMD.

） Important

L'activation de chacune des fonctionnalités de sécurité dans le BIOS peut varier en

fonction du fournisseur de votre matériel. Assurez-vous de consulter le guide
d'activation du serveur Secured-core du fabricant de votre matériel.

Vous trouverez le matériel certifié pour les serveurs à noyau sécurisé dans le catalogue
Windows Server et pour les serveurs Azure Stack HCI dans le catalogue Azure
Stack HCI .

Activer les fonctionnalités de sécurité

Pour configurer le serveur Secured-core, vous devez activer les fonctionnalités de
sécurité spécifiques de Windows Server, sélectionner la méthode appropriée et suivre
les étapes.

Interface graphique utilisateur

Voici comment activer le serveur Secured-core à l'aide de l'interface utilisateur.

1. Depuis le bureau Windows, ouvrez le menu Démarrer, sélectionnez Outils

d'administration Windows, ouvrez Gestion de l'ordinateur.
2. Dans Gestion de l'ordinateur, sélectionnez Gestionnaire de périphériques,
résolvez toute erreur de périphérique si nécessaire.
a. Pour les systèmes basés sur AMD, confirmez que le périphérique DRTM
Boot Driver est présent avant de continuer
3. Depuis le bureau Windows, ouvrez le menu Démarrer, sélectionnez Sécurité
Windows.
4. Sélectionnez Sécurité de l'appareil > Détails d'isolation du noyau, puis
activez Intégrité de la mémoire et protection du micrologiciel.
5. Redémarrez votre serveur lorsque vous y êtes invité.

Une fois votre serveur redémarré, votre serveur est activé pour le serveur Secured-
core.

Vérifier la configuration du serveur à noyau

sécurisé
Maintenant que vous avez configuré le serveur Secured-core, sélectionnez la méthode
appropriée pour vérifier votre configuration.

Interface graphique utilisateur

Voici comment vérifier que votre serveur Secured-core est configuré à l'aide de
l'interface utilisateur.

1. Depuis le bureau Windows, ouvrez le menu Démarrer, tapez [Link]

pour ouvrir les informations système. Sur la page Résumé du système,
 confirmez :

a. L’état de démarrage sécurisé et la protection DMA du noyau sont activés.

b. La sécurité basée sur la virtualisation est en cours d'exécution.

c. L'exécution des services de sécurité basés sur la virtualisation montre

l'intégrité du code et le lancement sécurisé appliqués par l'hyperviseur.

Étapes suivantes
Maintenant que vous avez configuré le serveur Secured-core, voici quelques ressources
pour en savoir plus :

Sécurité basée sur la virtualisation (VBS)

Intégrité de la mémoire et activation VBS
Lancement sécurisé de System Guard
Structure protégée et machines
virtuelles dotées d’une protection
maximale
Article • 12/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

L’un des objectifs les plus importants de la fourniture d’un environnement hébergé est
de garantir la sécurité des machines virtuelles exécutées dans l’environnement. En tant
que fournisseur de services cloud ou administrateur d’un cloud privé d’entreprise, vous
pouvez utiliser une structure protégée pour offrir un environnement plus sécurisé pour
les machines virtuelles. Une structure Service Guardian se compose d’un Service
Guardian hôte (HGS) généralement constitué d’un cluster de trois nœuds, d’un ou
plusieurs hôtes protégés et d’un ensemble de machines virtuelles dotées d’une
protection maximale.

） Important

Vérifiez que vous avez installé la dernière mise à jour cumulative avant de déployer
des machines virtuelles protégées en production.

Vidéos, blog et rubrique de vue d’ensemble sur

les infrastructures protégées et les machines
virtuelles protégées
Vidéo : Comment protéger votre infrastructure de virtualisation contre les menaces
internes avec Windows Server 2019
Vidéo : Présentation des machines virtuelle protégées dans Windows Server 2016
Vidéo : Plongez dans les machines virtuelles protégées avec Windows Server 2016
Hyper-V
Vidéo : Déploiement de machines virtuelles protégées et d’une infrastructure
protégée avec Windows Server 2016
Blog : Blog sur la sécurité des centres de données et du cloud privé
Vue d’ensemble : structure protégée et machines virtuelles protégées
Rubriques de planification
Guide de planification pour les hôtes
Guide de planification pour les locataires

Rubriques traitant du déploiement

Guide de déploiement
Démarrage rapide
Déployer SGH
Déployer des hôtes Service Guardian
Configuration de la structure DNS des hôtes qui vont devenir des hôtes
Service Guardian
Déployer un hôte protégé à l’aide du mode AD
Déployer un hôte protégé à l’aide du mode TPM
Confirmer que les hôtes protégés peuvent attester
VM dotées d’une protection maximale : Le fournisseur de services
d’hébergement déploie des hôtes Service Guardian dans VMM
Déployer des machines virtuelles protégées
Créer un modèle de machine virtuelle protégée
Préparer un disque dur virtuel d’assistance de protection des machines
virtuelles
Configurer Windows Azure Pack
Créer un fichier de données de protection
Déployez une machine virtuelle protégée à l’aide de Windows Azure Pack
Déploiement d’une machine virtuelle protégée à l’aide de Virtual Machine
Manager

Rubrique opérations et gestion

Gestion du service Guardian hôte
Vue d’ensemble de la structure protégée
et des machines virtuelles dotées d’une
protection maximale
Article • 11/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

La sécurité de la virtualisation est un secteur d’investissement important dans Hyper-V.

En plus de protéger les hôtes ou d’autres machines virtuelles contre une machine
virtuelle exécutant des logiciels malveillants, nous devons également protéger les
machines virtuelles contre un hôte compromis. Aujourd’hui, c’est un danger
fondamental pour chaque plateforme de virtualisation, que ce soit une plateforme
Hyper-V, VMware ou autre. Si une machine virtuelle sort d’une organisation (à des fins
malveillantes ou accidentellement), elle peut être exécutée sur n’importe quel autre
système. La protection des ressources vitales de votre organisation, comme les
contrôleurs de domaine, les serveurs de fichiers sensibles et les systèmes RH, est une
priorité majeure.

Pour vous aider à vous protéger contre une structure de virtualisation compromise,
Windows Server 2016 Hyper-V propose des machines virtuelles dotées d’une protection
maximale. Une machine virtuelle dotée d’une protection maximale est une machine
virtuelle de génération 2 (prise en charge sur Windows Server 2012 et ultérieur) avec un
module de plateforme sécurisée (TPM) virtuel, chiffrée à l’aide de BitLocker et qui peut
uniquement s’exécuter sur des hôtes intègres et approuvés de la structure. Les machines
virtuelles dotées d’une protection maximale et la structure protégée permettent aux
fournisseurs de services cloud ou aux administrateurs du cloud privé d’entreprise d’offrir
un environnement plus sécurisé pour les machines virtuelles du locataire.

Une structure protégée se compose des éléments suivants :

1 Service Guardian hôte (SGH) (en général, un cluster de 3 nœuds).

1 ou plusieurs hôtes Service Guardian.
Un ensemble de machines virtuelles dotées d’une protection maximale Le
diagramme ci-dessous montre comment le Service Guardian hôte utilise une
attestation pour garantir que seuls les hôtes valides connus peuvent démarrer les
machines virtuelles dotées d’une protection maximale, et la protection de clé pour
libérer en toute sécurité les clés pour les machines virtuelles dotées d’une
protection maximale.
Quand un locataire crée des machines virtuelles dotées d’une protection maximale qui
s’exécutent sur une structure protégée, les hôtes Hyper-V et les machines virtuelles
dotées d’une protection maximale elles-mêmes sont protégés par le SGH. Le SGH
fournit deux services distincts : l’attestation et la protection de clé. Le service
d’attestation garantit uniquement que les hôtes Hyper-V approuvés peuvent exécuter
des machines virtuelles dotées d’une protection maximale tandis que le service de
protection de clé fournit les clés nécessaires pour les mettre sous tension et les migrer
dynamiquement vers d’autres hôtes Service Guardian.

Pour plus d’informations, consultez cette vidéo sur la présentation des machines
virtuelles dotées d'une protection maximale .

Modes d’attestation de la solution de structure

protégée
Le SGH prend en charge des modes d’attestation différents pour une structure
protégée :

Attestation approuvée par le module de plateforme sécurisée (TPM) (au niveau

matériel)
Attestation de clé d’hôte (basée sur des paires de clés asymétriques)

L’attestation approuvée par le module de plateforme sécurisée (TPM) est recommandée,

car elle offre des garanties renforcées, comme expliqué dans le tableau suivant, mais elle
nécessite que TPM 2.0 soit installé sur vos hôtes Hyper-V. Si vous ne disposez pas
actuellement du module TPM 2.0 ou d’un module TPM, vous pouvez utiliser l’attestation
de clé d’hôte. Si vous décidez de passer à l’attestation approuvée par le module de
plateforme sécurisée (TPM) quand vous achetez du nouveau matériel, vous pouvez
changer de mode d’attestation sur le Service Guardian hôte avec peu ou pas
d’interruption sur votre structure.

Mode d’attestation choisi pour les hôtes Garanties de l’hôte

Attestation approuvée par le module de plateforme Les hôtes Service Guardian sont
sécurisée (TPM) : offre les protections les plus approuvés en fonction de leur identité
renforcées possible, mais nécessite également des TPM, de leur séquence de démarrage
étapes de configuration supplémentaires. Le matériel mesurée et de leurs stratégies
et le microprogramme de l’hôte doivent inclure d’intégrité du code, afin de pouvoir
TPM 2.0 et UEFI 2.3.1 avec le démarrage sécurisé garantir qu’ils exécutent uniquement du
activé. code approuvé.

Attestation de clé d’hôte : destiné à prendre en Les hôtes Service Guardian sont
charge le matériel hôte existant où TPM 2.0 n’est pas approuvés en fonction de la possession
disponible. Nécessite moins d’étapes de configuration de la clé.
et est compatible avec le matériel courant.

Un autre mode appelé Attestation approuvée par l’administrateur est déconseillée à

compter de Windows Server 2019. Ce mode était basé sur l’appartenance à l’hôte
Service Guardian dans un groupe de sécurité Active Directory Domain Services (AD DS)
désigné. L’attestation de la clé d’hôte fournit une identification de l’hôte similaire et est
plus facile à configurer.

Garanties fournies par le Service Guardian hôte

SGH, ainsi que les méthodes de création de machines virtuelles dotées d’une protection
maximale, permettent de fournir les garanties suivantes.

Type de garantie Garanties pour les machines virtuelles dotées d’une protection maximale, à
pour les partir du service de protection de clé et à partir de méthodes de création
machines de machines virtuelles dotées d’une protection maximale
virtuelles

Disques chiffrés Les machines virtuelles dotées d’une protection maximale utilisent BitLocker
par BitLocker pour protéger leurs disques. Les clés BitLocker nécessaires pour démarrer la
(disques de machine virtuelle et déchiffrer les disques sont protégées par le TPM virtuel
système de la machine virtuelle dotée d’une protection maximale à l’aide de
d’exploitation et technologies éprouvées telles que le démarrage mesuré sécurisé. Même si les
disques de machines virtuelles dotées d’une protection maximale chiffrent et protègent
données) automatiquement le disque du système d’exploitation uniquement, vous
pouvez chiffrer les lecteurs de données attachés aux machines virtuelles
dotées d’une protection maximale.
 Type de garantie Garanties pour les machines virtuelles dotées d’une protection maximale, à
pour les partir du service de protection de clé et à partir de méthodes de création
machines de machines virtuelles dotées d’une protection maximale
virtuelles

Déploiement de Lors du déploiement de nouvelles machines virtuelles dotées d’une

nouvelles protection maximale, les locataires peuvent spécifier les disques de modèle
machines qu’ils approuvent. Les disques de modèle protégés ont des signatures qui
virtuelles dotées sont calculées à un instant donné quand leur contenu est jugé digne de
d’une protection confiance. Les signatures de disque sont ensuite stockées dans un catalogue
maximale à partir de signatures, que les locataires fournissent de façon sécurisée à la structure
de lors de la création de machines virtuelles dotées d’une protection maximale.
disques/d’images Pendant la mise en service des machines virtuelles dotées d’une protection
de modèle maximale, la signature du disque est recalculée et comparée aux signatures
« approuvés » approuvées du catalogue. Si les signatures correspondent, la machine
virtuelle dotée d’une protection maximale est déployée. Si les signatures ne
correspondent pas, le disque de modèle protégé est jugé non fiable et le
déploiement échoue.

Protection des Lors de la création de machines virtuelles, il est nécessaire de garantir que les
mots de passe et secrets des machines virtuelles, tels que les signatures de disque approuvées,
autres secrets les certificats RDP et le mot de passe du compte Administrateur local de la
lors de la machine virtuelle, ne sont pas révélés à la structure. Ces secrets sont stockés
création d’une dans un fichier chiffré appelé « fichier de données de protection
machine virtuelle (fichier .PDK), qui est protégé par des clés de locataire et chargé sur la
dotée d’une structure par le locataire. Quand une machine virtuelle dotée d’une
protection protection maximale est créée, le locataire sélectionne les données de
maximale protection à utiliser qui fournissent en toute sécurité ces secrets uniquement
aux composants approuvés dans la structure protégée.

Contrôle du Les données de protection contiennent également une liste de structures

locataire sur protégées sur lesquelles une machine virtuelle dotée d’une protection
lequel la machine maximale particulière est autorisée à s’exécuter. Cela est utile, par exemple,
virtuelle peut dans les cas où une machine virtuelle dotée d’une protection maximale
être démarrée réside dans un cloud privé local, mais doit éventuellement être migrée vers
un autre cloud (public ou privé) pour une reprise d’activité. Le cloud ou la
structure cible doit prendre en charge les machines virtuelles dotées d’une
protection maximale, et celles-ci doivent permettre à cette structure de les
exécuter.

Que sont les données de protection et

pourquoi sont-elles nécessaires ?
Un fichier de données de protection (également appelé « fichier de données
d’approvisionnement » ou « fichier PDK ») est un fichier chiffré créé par un locataire ou
un propriétaire de machine virtuelle pour protéger les informations clés de
configuration de la machine virtuelle, telles que le mot de passe de l’administrateur, les
certificats RDP et autres certificats liés aux identités, les informations d’identification de
jonction de domaine, etc. Un administrateur de structure utilise le fichier de données de
protection lors de la création d’une machine virtuelle dotée d’une protection maximale,
mais ne peut pas afficher ou utiliser les informations qu’il contient.

Les fichiers de données de protection contiennent des secrets, notamment :

Les informations d’identification de l’administrateur

Un fichier de réponses ([Link])
Une stratégie de sécurité qui détermine si les machines virtuelles créées en
utilisant ces données de protection sont configurées avec une protection maximale
ou avec une prise en charge du chiffrement
N’oubliez pas que les machines virtuelles configurées avec une protection
maximale ne sont pas accessibles par les administrateurs de structure tandis
que les machines virtuelles prises en charge par le chiffrement le sont
Un certificat RDP pour sécuriser les communications de bureau à distance avec la
machine virtuelle
Un catalogue des signatures de volume qui contient une liste de signatures de
disques de modèles signés et approuvés à partir desquelles une nouvelle machine
virtuelle est autorisée à être créée
Un protecteur de clé (ou KP) qui définit les structures protégées sur lesquelles une
machine virtuelle dotée d’une protection maximale est autorisée à s’exécuter

Le fichier de données de protection (fichier PDK) garantit que la machine virtuelle est
créée de la manière voulue par le locataire. Par exemple, quand le locataire place un
fichier de réponses ([Link]) dans le fichier de données de protection, puis les
remet au fournisseur d’hébergement, le fournisseur d’hébergement ne peut pas afficher
ou modifier ce fichier de réponses. De même, le fournisseur d’hébergement ne peut pas
remplacer un VHDX différent lors de la création d’une machine virtuelle dotée d’une
protection maximale, car le fichier de données de protection contient les signatures des
disques approuvés à partir desquelles les machines virtuelles dotées d’une protection
maximale peuvent être créées.

L’illustration suivante montre le fichier de données de protection et les éléments de

configuration associés.
 

Quels sont les types de machines virtuelles

qu’une structure protégée peut exécuter ?
Les structures protégées sont capables d’exécuter des machines virtuelles de trois
façons différentes :

1. Une machine virtuelle normale n’offrant aucune protection au-delà des versions
précédentes d’Hyper-V
2. Une machine virtuelle prise en charge par le chiffrement dont les protections
peuvent être configurées par un administrateur de structure
3. Une machine virtuelle dotée d’une protection maximale dont les protections sont
toutes activées et qui ne peuvent pas être désactivées par un administrateur de
structure

Les machines virtuelles prises en charge par le chiffrement sont conçues pour être
utilisées quand les administrateurs de structure sont entièrement fiables. Par exemple,
une entreprise peut déployer une structure protégée afin de s’assurer que les disques de
machines virtuelles sont chiffrés au repos par souci de conformité. Les administrateurs
de structure peuvent continuer à utiliser des fonctionnalités de gestion pratiques, telles
que les connexions à la console de la machine virtuelle, PowerShell Direct et d’autres
outils de gestion et de dépannage courants.
Les machines virtuelles dotées d’une protection maximale sont destinées à être utilisées
dans des structures où les données et l’état de la machine virtuelle doivent être
protégés à la fois contre les administrateurs de structure et contre les logiciels non
approuvés susceptibles de s’exécuter sur les hôtes Hyper-V. Par exemple, les machines
virtuelles dotées d’une protection maximale n’autorisent jamais une connexion à la
console de la machine virtuelle alors qu’un administrateur de structure peut activer ou
désactiver cette protection pour les machines virtuelles prises en charge par le
chiffrement.

Le tableau suivant résume les différences entre les VM avec prise en charge du
chiffrement et des VM dotées d'une protection maximale.

Fonctionnalité Génération 2 Génération 2 dotée d’une protection

prise en charge maximale
par le
chiffrement

Démarrage sécurisé Oui, obligatoire Oui, obligatoire et appliqué

mais
configurable

Module de plateforme sécurisée Oui, obligatoire Oui, obligatoire et appliqué

virtuelle (vTPM) mais
configurable

Chiffrer l’état et le trafic de Oui, obligatoire Oui, obligatoire et appliqué

migration dynamique d’une mais
machine virtuelle configurable

Composants d’intégration Configurable par Certains composants d’intégration

l’administrateur bloqués (par exemple, l’échange de
de structure données, PowerShell Direct)

Connexion à une machine Activé, Activé sur les hôtes à partir de Windows
virtuelle (console), impossible de le Server version 1803 ; Désactivé sur les
périphériques HDI (par exemple, désactiver hôtes utilisant des versions antérieures
clavier, souris)

Ports COM/série Prise en charge Désactivé (ne peut pas être activé)

Attacher un débogueur (au Prise en charge Désactivé (ne peut pas être activé)
processus de la machine
virtuelle)1

1
Les débogueurs traditionnels qui s’attachent directement à un processus, tels que
[Link], sont bloqués pour les machines virtuelles dotées d’une protection
maximale, car le processus Worker de la machine virtuelle ([Link]) est un PPL
(Protected Process Light). Les autres techniques de débogage, telles que celles utilisées
par [Link], ne sont pas bloquées. Contrairement aux machines virtuelles dotées
d’une protection maximale, le processus Worker pour les machines virtuelles prises en
charge par le chiffrement ne s’exécute pas en tant que PPL, de sorte que les débogueurs
traditionnels, comme [Link], continueront à fonctionner normalement.

Les machines virtuelles dotées d’une protection maximale et les machines virtuelles
prises en charge par le chiffrement continuent à prendre en charge les fonctionnalités
de gestion de structure courantes, telles que la migration dynamique, le réplica Hyper-V,
les points de contrôle de la machine virtuelle, etc.

Le Service Guardian hôte en action : comment

une machine virtuelle dotée d’une protection
maximale est mise sous tension

1. VM01 est sous tension. Avant qu’un hôte Service Guardian puisse mettre sous
tension une machine virtuelle dotée d’une protection maximale, il faut d’abord
certifier qu’elle est intègre. Pour prouver qu’elle est intègre, elle doit présenter un
certificat d’intégrité au service de protection de clés (KPS). Le certificat d’intégrité
est obtenu via le processus d’attestation.

2. L’hôte demande une attestation. L’hôte Service Guardian demande une

attestation. Le mode d’attestation est dicté par le Service Guardian hôte :

Attestation approuvée par le module de plateforme sécurisée (TPM) :

L’hôte Hyper-V envoie des informations qui incluent les éléments suivants :

Informations d’identification du module de plateforme sécurisée (TPM) (sa

paire de clés de type EK (Endorsement Key))
 Informations sur les processus qui ont été démarrés pendant la séquence
de démarrage la plus récente (le journal TCG)

Informations sur la stratégie d’intégrité du code qui a été appliquée sur

l’hôte.

L’attestation se produit au démarrage de l’hôte, puis toutes les 8 heures

par la suite. Si, pour une raison quelconque, un hôte ne dispose pas d’un
certificat d’attestation quand une machine virtuelle essaie de démarrer,
cela déclenche également une attestation.

Attestation de clé d’hôte : l’hôte Hyper-V envoie la moitié publique de la

paire de clés. Service Guardian hôte vérifie que la clé d’hôte est inscrite.

Attestation approuvée par l’administrateur : L’hôte Hyper-V envoie un ticket

Kerberos, qui identifie les groupes de sécurité dans lesquels se trouve l’hôte.
SGH valide le fait que l’hôte appartient à un groupe de sécurité qui a été
précédemment configuré par l’administrateur SGH approuvé.

3. L’attestation réussit (ou échoue). Le mode d’attestation détermine les vérifications

nécessaires pour attester que l’hôte est intègre. Avec l’attestation approuvée par
TPM, l’identité TPM de l’hôte, les mesures de démarrage et la stratégie d’intégrité
du code sont validées. Avec l’attestation de clé d’hôte, seule l’inscription de la clé
d’hôte est validée.

4. Le certificat d’attestation est envoyé à l’hôte. En supposant que l’attestation a

réussi, un certificat d’intégrité est envoyé à l’hôte, lequel est considéré comme
« hôte Service Guardian » (autorisé à exécuter des machines virtuelles dotées d’une
protection maximale). L’hôte utilise le certificat d’intégrité pour autoriser le service
de protection de clé à libérer en toute sécurité les clés nécessaires pour travailler
avec des machines virtuelles dotées d’une protection maximale.

5. L’hôte demande une clé de machine virtuelle. L’hôte Service Guardian n’a pas les
clés nécessaires pour mettre sous tension une machine virtuelle dotée d’une
protection maximale (VM01 dans le cas présent). Pour obtenir les clés nécessaires,
l’hôte Service Guardian doit fournir les éléments suivants à KPS :

Le certificat d’intégrité actuel

Un secret chiffré (un protecteur de clé ou KP) qui contient les clés nécessaires
pour mettre sous tension VM01. Le secret est chiffré à l’aide d’autres clés que
seul KPS connaît.

6. Libération de la clé. KPS examine le certificat d’intégrité pour déterminer sa

validité. Le certificat ne doit pas avoir expiré et KPS doit approuver le service
 d’attestation qui l’a émis.

7. La clé est retournée à l’hôte. Si le certificat d’intégrité est valide, KPS tente de
déchiffrer la clé secrète, et de retourner en toute sécurité les clés nécessaires pour
mettre sous tension la machine virtuelle. Les clés sont chiffrées sur la sécurité
basée sur la virtualisation (VBS) de l’hôte Service Guardian.

8. L’hôte met VM01 sous tension.

Glossaire de la structure protégée et des

machines virtuelles dotées d’une protection
maximale
Terme Définition

Service Guardian Rôle Windows Server installé sur un cluster sécurisé de serveurs nus qui
hôte (SGH) est capable de mesurer l’intégrité d’un hôte Hyper-V et de libérer des clés
pour les hôtes Hyper-V intègres lors de la mise sous tension ou de la
migration dynamique de machines virtuelles dotées d’une protection
maximale. Ces deux fonctions sont indispensables pour une solution de
machine virtuelle dotée d’une protection maximale et sont appelées
Service d’attestation et Service de protection de clé, respectivement.

hôte Service Hôte Hyper-V sur lequel les machines virtuelles dotées d’une protection
Guardian maximale peuvent s’exécuter. Un hôte peut être considéré comme hôte
Service Guardian uniquement quand il a été jugé intègre par le service
d’attestation du SHG. Les machines virtuelles dotées d’une protection
maximale ne peuvent pas être mises sous tension ou migrées
dynamiquement vers un hôte Hyper-V qui n’est pas encore attesté ou
dont l’attestation a échoué.

structure protégée Terme générique utilisé pour décrire une structure d’hôtes Hyper-V et leur
Service Guardian hôte qui a la possibilité de gérer et d’exécuter des
machines virtuelles dotées d’une protection maximale.

machine virtuelle Machine virtuelle qui peut s’exécuter uniquement sur des hôtes Service
dotée d’une Guardian et qui est protégée contre l’inspection, la falsification et le vol
protection maximale par des administrateurs de structure malveillants et des programmes
malveillants hôtes.

administrateur de Administrateur de cloud public ou privé qui peut gérer des machines
structure virtuelles. Dans le contexte d’une structure protégée, un administrateur de
structure n’a pas accès aux machines virtuelles dotées d’une protection
maximale ni aux stratégies qui déterminent quelles machines virtuelles
dotées d’une protection maximale peuvent s’exécuter dessus.
Terme Définition

administrateur SGH Administrateur approuvé dans le cloud public ou privé et qui a l’autorité
nécessaire pour gérer les stratégies et le matériel de chiffrement pour les
hôtes Service Guardian, c’est-à-dire les hôtes sur lesquels une machine
virtuelle dotée d’une protection maximale peut s’exécuter.

fichier de données Fichier chiffré qu’un locataire ou un utilisateur crée pour contenir des
d’approvisionnement informations de configuration de machine virtuelle importantes et pour
ou fichier de protéger ces informations contre tout accès par d’autres utilisateurs. Par
données de exemple, un fichier de données de protection peut contenir le mot de
protection passe qui sera affecté au compte Administrateur local lors de la création
(fichier PDK) de la machine virtuelle.

sécurité basée sur la Environnement de traitement et de stockage basé sur Hyper-V auquel les
virtualisation (VBS) administrateurs n’ont pas accès. Le mode sécurisé virtuel fournit au
système la possibilité de stocker les clés de système d’exploitation qui ne
sont pas visibles par un administrateur de système d’exploitation.

module de Version virtualisée d’un module de plateforme sécurisée (TPM). Depuis

plateforme sécurisée Hyper-V dans Windows Server 2016, vous pouvez fournir un périphérique
(TPM) virtuel TPM 2.0 virtuel pour assurer le chiffrement des machines virtuelles, de la
même manière qu’un module de plateforme sécurisée (TPM) physique
permet de chiffrer un ordinateur physique.

Références supplémentaires
Structure protégée et machines virtuelles dotées d’une protection maximale
Blog : Blog sur la sécurité des centres de données et du cloud privé
Vidéo : Présentation des machines virtuelle dotées d'une protection maximale
Vidéo : Plongez dans les machines virtuelles dotées d’une protection maximale
avec Windows Server 2016 Hyper-V
Planification d’une infrastructure
protégée
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Les rubriques suivantes décrivent la planification du déploiement d’une infrastructure

protégée et de machines virtuelles dotées d’une protection maximale :

Guide de planification d’une infrastructure protégée et de machines virtuelles

dotées d’une protection maximale pour les hébergeurs
Matériel compatible avec la protection de l’intégrité du code basée sur la
virtualisation de Windows Server 2016
Guide de planification d’une infrastructure protégée et de machines virtuelles
dotées d’une protection maximale pour les locataires
Guide de planification d’une structure
protégée et de machines virtuelles
protégées pour les hébergeurs
Article • 11/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cette rubrique décrit les décisions de planification qui devront être prises pour
permettre aux machines virtuelles protégées de s’exécuter sur votre infrastructure. Que
vous mettiez à niveau une infrastructure Hyper-V existante ou que vous en créiez une,
l’exécution de machines virtuelles protégées se compose de deux composants
principaux :

Le service Host Guardian (SGH) fournit une attestation et une protection des clés
afin que vous puissiez vous assurer que les machines virtuelles protégées
s’exécuteront uniquement sur des hôtes Hyper-V approuvés et sains.
Les hôtes Hyper-V approuvés et sains sur lesquels les machines virtuelles
protégées (et les machines virtuelles régulières) peuvent s’exécuter sont appelés
hôtes protégés.

Décision #1 : niveau de confiance dans

l’infrastructure
La façon dont vous implémentez le service Host Guardian et les hôtes Hyper-V protégés
dépend principalement de la force de confiance que vous cherchez à obtenir dans votre
infrastructure. La force de confiance est régie par le mode d’attestation. Il existe deux
options qui s’excluent mutuellement :

1. Attestation approuvée par le module de plateforme sécurisée (TPM)

 Si votre objectif est de protéger les machines virtuelles contre les administrateurs
malveillants ou une infrastructure compromise, vous utiliserez l’attestation
approuvée par TPM. Cette option fonctionne bien pour les scénarios
d’hébergement multilocataire ainsi que pour les ressources à valeur élevée dans les
environnements d’entreprise, tels que les contrôleurs de domaine ou les serveurs
de contenu comme SQL ou SharePoint. Les stratégies d’intégrité du code
protégées par l’hyperviseur (HVCI) sont mesurées et leur validité est appliquée par
SGH avant que l’hôte ne soit autorisé à exécuter des machines virtuelles protégées.

2. Attestation de clé d’hôte

Si vos besoins sont principalement déterminés par la conformité qui exige que les
machines virtuelles soient chiffrées au repos et en cours d’exécution, vous utiliserez
l’attestation de clé d’hôte. Cette option fonctionne bien pour les centres de
données à usage général où vous êtes à l’aise avec les administrateurs
d’infrastructure et d’hôte Hyper-V ayant accès aux systèmes d’exploitation invités
des machines virtuelles pour la maintenance et les opérations quotidiennes.

Dans ce mode, l’administrateur d’infrastructure est seul responsable de la garantie

de l’intégrité des hôtes Hyper-V. Étant donné que SGH ne joue aucun rôle dans la
décision de ce qui est ou n’est pas autorisé à s’exécuter, les programmes
malveillants et les débogueurs fonctionnent comme prévu.

Cependant, les débogueurs qui tentent de s’attacher directement à un processus

(tels que [Link]), sont bloqués pour les machines virtuelles protégées, car le
processus Worker de la machine virtuelle ([Link]) est un PPL (Protected
Process Light). Les autres techniques de débogage, telles que celles utilisées par
[Link], ne sont pas bloquées. Contrairement aux machines virtuelles
protégées, le processus de travail pour les machines virtuelles prises en charge par
le chiffrement ne s’exécute pas en tant que PPL, de sorte que les débogueurs
traditionnels comme [Link] continueront à fonctionner normalement.

Un mode d’attestation similaire nommé attestation de confiance Administration

(basé sur Active Directory) est déconseillé à compter de Windows Server 2019.

Le niveau de confiance que vous choisissez détermine la configuration matérielle

requise pour vos hôtes Hyper-V, ainsi que les stratégies que vous appliquez sur
l’infrastructure. Si nécessaire, vous pouvez déployer votre infrastructure protégée à
l’aide du matériel existant et de l’attestation approuvée par l’administrateur, puis la
convertir en attestation approuvée par TPM lorsque le matériel a été mis à niveau et que
vous devez renforcer la sécurité de l’infrastructure.
Décision #2 : infrastructure Hyper-V existante
par rapport à une nouvelle infrastructure
Hyper-V distincte
Si vous disposez d’une infrastructure existante (Hyper-V ou autre), il est très probable
que vous puissiez l’utiliser pour exécuter des machines virtuelles protégées avec des
machines virtuelles régulières. Certains clients choisissent d’intégrer des machines
virtuelles protégées à leurs outils et infrastructures existants, tandis que d’autres les
séparent pour des raisons professionnelles.

Planification de l’administrateur SGH pour le

service Host Guardian
Déployez le service Host Guardian (SGH) dans un environnement hautement sécurisé,
qu’il s’agisse d’un serveur physique dédié, d’une machine virtuelle protégée, d’une
machine virtuelle sur un hôte Hyper-V isolé (séparé de l’infrastructure qu’il protège) ou
d’un autre abonnement Azure.

Domaine Détails

Configuration Un serveur (cluster à trois nœuds recommandé pour la haute

requise disponibilité)
Pour le secours, au moins deux serveurs SGH sont requis
Les serveurs peuvent être virtuels ou physiques (serveur physique avec
TPM 2.0 recommandé ; TPM 1.2 également pris en charge)
Installation de Server Core de Windows Server 2016 ou ultérieure
Ligne de vision réseau vers l’infrastructure permettant la configuration
HTTP ou de secours
Certificat HTTPS recommandé pour la validation d’accès

Dimensionnement Chaque nœud de serveur SGH de taille moyenne (8 cœurs/4 Go) peut gérer
1000 hôtes Hyper-V.

Gestion Désignez des personnes spécifiques qui géreront le SGH. Elles doivent être
séparées des administrateurs d’infrastructure. À titre de comparaison, les
clusters SGH peuvent être considérés de la même manière qu’une autorité
de certification en termes d’isolation administrative, de déploiement
physique et de niveau global de confidentialité de la sécurité.
Domaine Détails

Active Directory Par défaut, SGH installe son propre Active Directory interne pour la gestion. Il
du Service s’agit d’une forêt autonome et autogérée. Il s’agit de la configuration
Guardian hôte recommandée pour vous aider à isoler SGH de votre infrastructure.

Si vous disposez déjà d’une forêt Active Directory hautement privilégiée que
vous utilisez pour l’isolation, vous pouvez utiliser cette forêt au lieu de la
forêt par défaut SGH. Il est important que SGH ne soit pas joint à un
domaine dans la même forêt que les hôtes Hyper-V ou vos outils de gestion
de structure. Cela pourrait permettre à un administrateur d’infrastructure de
prendre le contrôle sur SGH.

Récupération Vous disposez de trois options :

d'urgence
1. Installez un cluster SGH distinct dans chaque centre de données et
autorisez les machines virtuelles protégées à s’exécuter dans les
centres de données principaux et de sauvegarde. Cela évite d’avoir à
étendre le cluster sur un WAN et vous permet d’isoler les machines
virtuelles afin qu’elles s’exécutent uniquement dans leur site désigné.
2. Installez SGH sur un cluster étendu entre deux centres de données (ou
plus). Cela fournit une résilience si le WAN tombe en panne, mais
repousse les limites du clustering de basculement. Vous ne pouvez pas
isoler les charges de travail sur un seul site ; une machine virtuelle
autorisée à s’exécuter dans un site peut s’exécuter sur n’importe quel
autre site.
3. Inscrivez votre hôte Hyper-V auprès d’un autre SGH en tant que
basculement.

Sauvegardez chaque serveur SGH en exportant sa configuration pour

pouvoir toujours effectuer une récupération locale. Pour plus d’informations,
consultez Export-HgsServerState et Import-HgsServerState.
Domaine Détails

Clés Service Un service Host Guardian utilise deux paires de clés asymétriques, une clé de
Guardian hôte chiffrement et une clé de signature, chacune représentée par un certificat
SSL. Il existe deux options pour générer ces clés :

1. Autorité de certification interne : vous pouvez générer ces clés à l’aide

de votre infrastructure PKI interne. Cela convient à un environnement
de centre de données.
2. Autorités de certification approuvées publiquement : utilisez un
ensemble de clés obtenues auprès d’une autorité de certification
approuvée publiquement. Il s’agit de l’option que les hôtes doivent
utiliser.

Notez que s’il est possible d’utiliser des certificats auto-signés, cela n’est pas
recommandé pour les scénarios de déploiement autres que les laboratoires
de preuve de concept.

En plus d’avoir des clés SGH, un hôte peut utiliser « apportez votre propre
clé », où les locataires peuvent fournir leurs propres clés afin que certains (ou
tous) les locataires puissent avoir leur propre clé SGH spécifique. Cette
option convient aux hôtes qui peuvent fournir un processus hors bande
permettant aux locataires de charger leurs clés.

Stockage de clés Pour une sécurité maximale, les clés SGH doivent être créées et stockées
Service Guardian exclusivement dans un module de sécurité matériel (HSM). Si vous n’utilisez
hôte pas de HSM, il est vivement recommandé d’appliquer BitLocker sur les
serveurs SGH.

Planification de l’administrateur
d’infrastructure pour les hôtes protégés
Domaine Détails

Matériel Attestation de clé d’hôte : vous pouvez utiliser n’importe quel matériel
existant en tant qu’hôte protégé. Il existe quelques exceptions (pour vous
assurer que votre hôte peut utiliser de nouveaux mécanismes de sécurité à
partir de Windows Server 2016, consultez Matériel compatible avec
Windows Server 2016 protection de l’intégrité du code basée sur la
virtualisation).
Attestation approuvée par TPM : vous pouvez utiliser n’importe quel
matériel doté de la qualification supplémentaire Hardware Assurance tant
qu’il est configuré de manière appropriée (consultez Configurations de
serveur conformes aux machines virtuelles protégées et protection basée
sur la virtualisation de l’intégrité du code pour la configuration spécifique).
Cela inclut TPM 2.0 et UEFI version 2.3.1c et ultérieures.
Domaine Détails

Système Nous vous recommandons d’utiliser l’option Server Core pour le système
d''exploitation d’exploitation hôte Hyper-V.

Impact sur les En fonction des tests de performances, nous prévoyons une différence de densité
performances d’environ 5 % entre l’exécution de machines virtuelles protégées et de machines
virtuelles non protégées. Cela signifie que si un hôte Hyper-V donné peut
exécuter 20 machines virtuelles non protégées, vous pouvez vous attendre à ce
qu’il puisse exécuter 19 machines virtuelles protégées.

Veillez à vérifier le dimensionnement avec vos charges de travail classiques. Par

exemple, il peut y avoir des valeurs aberrantes avec des charges de travail d’E/S
intensives orientées écriture qui affectent davantage la différence de densité.

Éléments à À partir de Windows Server version 1709, vous pouvez spécifier une URL de
prendre en secours pour un serveur SGH virtualisé qui s’exécute localement en tant que
compte en machine virtuelle protégée dans la filiale. L’URL de secours peut être utilisée à
matière de chaque fois que la filiale perd la connectivité avec les serveurs SGH dans le centre
filiale de données. Sur les versions précédentes de Windows Server, un hôte Hyper-V
s’exécutant dans une filiale a besoin d’une connectivité au service Host Guardian
pour mettre sous tension ou pour migrer en direct des machines virtuelles
protégées. Pour plus d’informations, consultez Considérations relatives aux
filiales.
Matériel compatible avec la protection
de l’intégrité du code basée sur la
virtualisation Windows Server
Article • 28/08/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Windows Server 2016 introduit une nouvelle protection de code basée sur la
virtualisation pour protéger les machines physiques et virtuelles contre les attaques qui
modifient le code système. Pour atteindre ce niveau de protection élevé, Microsoft
travaille en tandem avec les fabricants de matériel informatique (fabricants
d’équipement d’origine ou OEM) pour empêcher les écritures malveillantes dans le code
d’exécution du système. Cette protection peut être appliquée à n’importe quel système
et est utilisée comme l’un des blocs de construction pour l’implémentation de l’intégrité
de l’hôte Hyper-V pour les machines virtuelles protégées.

Comme avec toute protection basée sur le matériel, certains systèmes peuvent ne pas
être conformes en raison de problèmes comme le marquage incorrect des pages
mémoire en tant qu’exécutables ou la tentative de modifier le code au moment de
l’exécution, ce qui peut entraîner des défaillances inattendues, notamment une perte de
données ou une erreur d’écran bleu (également appelée erreur d’arrêt).

Pour être compatibles et prendre entièrement en charge la nouvelle fonctionnalité de

sécurité, les OEM doivent implémenter la table d’adresses mémoire définie dans
UEFI 2.6, qui a été publiée en janvier 2016. L’adoption de la nouvelle norme UEFI prend
du temps. En attendant, pour éviter que les clients rencontrent des problèmes, nous
tenons à fournir des informations sur les systèmes et les configurations avec lesquels
nous avons testé cet ensemble de fonctionnalités, ainsi que sur les systèmes que nous
savons non compatibles.

Systèmes non compatibles

Les configurations suivantes sont connues pour ne pas être compatibles avec la
protection de l’intégrité du code basée sur la virtualisation et ne peuvent pas être
utilisées comme hôte pour les machines virtuelles dotées d’une protection maximale :

Serveurs Dell PowerEdge exécutant des contrôleurs RAID PERC H330 Pour plus
d’informations, consultez l’article suivant du Support Dell H330 – Enabling "Host
 Guardian Hyper-V Support" or "Device Guard" on Win 2016 OS causes OS boot
failure .

Systèmes compatibles
Voici les systèmes que nous et nos partenaires avons testés dans notre environnement.
Vérifiez que le système fonctionne comme prévu dans votre environnement :

Machines virtuelles : vous pouvez activer la protection de l’intégrité du code basée

sur la virtualisation sur les machines virtuelles qui s’exécutent sur un hôte Hyper-V
à partir de Windows Server 2016.
Guide de planification d’une
infrastructure protégée et de machines
virtuelles dotées d’une protection
maximale pour les locataires
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cette rubrique se concentre sur les propriétaires de machines virtuelles qui souhaitent
protéger leurs machines virtuelles à des fins de conformité et de sécurité. Que les
machines virtuelles s’exécutent sur l’infrastructure protégée d’un fournisseur
d’hébergement ou sur une infrastructure protégée privée, les propriétaires de machines
virtuelles doivent contrôler le niveau de sécurité de leurs machines virtuelles dotées
d’une protection maximale, ce qui inclut leur déchiffrement si nécessaire.

Il existe trois domaines à prendre en compte quand vous utilisez des machines virtuelles
dotées d’une protection maximale :

Niveau de sécurité des machines virtuelles

Clés de chiffrement utilisées pour les protéger
Données de protection : informations sensibles utilisées pour créer des machines
virtuelles dotées d’une protection maximale

Niveau de sécurité des machines virtuelles

Durant le déploiement de machines virtuelles dotées d’une protection maximale, l’un
des deux niveaux de sécurité suivants doit être sélectionné :

Protégé
Chiffrement pris en charge

Un module TPM virtuel est attaché aux machines virtuelles dotées d’une protection
maximale et à celles qui prennent en charge le chiffrement. Celles qui exécutent
Windows sont protégées par BitLocker. La principale différence vient du fait que les
machines virtuelles dotées d’une protection maximale bloquent l’accès aux
administrateurs d’infrastructure, alors que les machines virtuelles prenant en charge le
chiffrement offrent aux administrateurs d’infrastructure le même niveau d’accès que
pour une machine virtuelle classique. Pour plus d’informations sur ces différences,
consultez Vue d’ensemble d’une infrastructure protégée et de machines virtuelles
dotées d’une protection maximale.

Choisissez Machines virtuelles dotées d’une protection maximale si vous cherchez à

protéger la machine virtuelle dans le cas d’une infrastructure compromise (ou contre
des administrateurs compromis). Elles doivent être utilisées dans les environnements où
les administrateurs d’infrastructure et l’infrastructure elle-même ne sont pas fiables.
Choisissez Machines virtuelles prenant en charge le chiffrement si vous cherchez à
respecter un seuil de conformité qui peut nécessiter à la fois le chiffrement au repos et
le chiffrement en transit (par exemple durant une migration dynamique) de la machine
virtuelle.

Les machines virtuelles prenant en charge le chiffrement sont idéales dans les
environnements où les administrateurs d’infrastructure sont entièrement fiables, mais où
le chiffrement reste une obligation.

Vous pouvez exécuter un mélange de machines virtuelles classiques, de machines

virtuelles dotées d’une protection maximale et de machines virtuelles prenant en charge
le chiffrement sur une infrastructure protégée, voire sur le même hôte Hyper-V.

Le choix entre une machine virtuelle dotée d’une protection maximale ou une machine
virtuelle prenant en charge le chiffrement est déterminé par les données de protection
sélectionnées au moment de la création de la machine virtuelle. Les propriétaires de
machines virtuelles configurent le niveau de sécurité au moment de la création des
données de protection (consultez la section Données de protection). Notez qu’une fois
ce choix effectué, il ne peut plus être changé tant que la machine virtuelle reste sur
l’infrastructure de virtualisation.

Clés de chiffrement utilisées pour les machines

virtuelles dotées d’une protection maximale
Les machines virtuelles dotées d’une protection maximale sont protégées contre les
vecteurs d’attaque de l’infrastructure de virtualisation à l’aide de disques chiffrés et de
divers autres éléments chiffrés, qui ne peuvent être déchiffrés que par :

Une clé de propriétaire : il s’agit d’une clé de chiffrement conservée par le

propriétaire de la machine virtuelle, qui est généralement utilisée pour une reprise
d’activité de dernier recours ou la résolution des problèmes. Les propriétaires de
machines virtuelles ont la responsabilité de conserver les clés de propriétaire dans
un emplacement sécurisé.
Un ou plusieurs Service Guardian hôtes (clés associées à des Service Guardian
hôtes) : chaque Service Guardian hôte représente une infrastructure de
 virtualisation dans laquelle un propriétaire autorise l’exécution des machines
virtuelles dotées d’une protection maximale. Les entreprises disposent souvent
d’une infrastructure de virtualisation principale et d’une infrastructure de reprise
d’activité après sinistre. Elles autorisent généralement les machines virtuelles
dotées d’une protection maximale à s’exécuter sur ces deux infrastructures. Dans
certains cas, l’infrastructure secondaire (reprise d’activité après sinistre) peut être
hébergé par un fournisseur de cloud public. Les clés privées d’une infrastructure
protégée sont conservées uniquement dans l’infrastructure de virtualisation, alors
que ses clés publiques peuvent être téléchargées et sont contenues dans son
Service Guardian hôte.

Comment créer une clé de propriétaire ? Une clé de propriétaire est représentée par
deux certificats. Un certificat pour le chiffrement et un certificat pour la signature. Vous
pouvez créer ces deux certificats en utilisant votre propre infrastructure PKI, ou obtenir
des certificats SSL auprès d’une autorité de certification (AC) publique. À des fins de test,
vous pouvez également créer un certificat autosigné sur n’importe quel ordinateur à
partir de Windows 10 ou Windows Server 2016.

Combien de clés de propriétaire devez-vous avoir ? Vous pouvez utiliser une seule clé
de propriétaire ou plusieurs clés de propriétaire. Conformément aux bonnes pratiques, il
est recommandé d’utiliser une seule clé de propriétaire pour un groupe de machines
virtuelles partageant le même niveau de sécurité, d’approbation ou de risque ainsi qu’à
des fins de contrôle administratif. Vous pouvez partager une même clé de propriétaire
entre toutes vos machines virtuelles dotées d’une protection maximale, jointes à un
domaine, et confier cette clé de propriétaire à des administrateurs de domaine pour
qu’ils la gèrent.

Puis-je utiliser mes propres clés pour le Service Guardian hôte ? Oui, vous pouvez
« apporter votre propre » clé au fournisseur d’hébergement, et l’utiliser pour vos
machines virtuelles dotées d’une protection maximale. Vous pouvez ainsi utiliser vos
propres clés au lieu de la clé du fournisseur d’hébergement. Cela peut être utile quand
vous avez des règles de sécurité ou des réglementations spécifiques à respecter. Pour
des raisons de sécurité, les clés associées à des Service Guardian hôtes doivent être
différentes de la clé de propriétaire.

Données de protection
Les données de protection contiennent les secrets nécessaires au déploiement de
machines virtuelles dotées d’une protection maximale ou prenant en charge le
chiffrement. Elles sont également utilisées pour la conversion de machines virtuelles
classiques en machines virtuelles dotées d’une protection maximale.
Les données de protection sont créées à l’aide de l’Assistant Fichier de données de
protection, et sont stockées dans des fichiers PDK que les propriétaires de machines
virtuelles chargent dans l’infrastructure protégée.

Les machines virtuelles dotées d’une protection maximale permettent de renforcer la

protection contre les attaques provenant d’une infrastructure de virtualisation
compromise. Nous avons donc besoin d’un mécanisme sécurisé pour passer les
données d’initialisation sensibles, par exemple le mot de passe de l’administrateur, les
informations d’identification de jonction de domaine ou les certificats RDP, sans les
révéler à l’infrastructure de virtualisation elle-même ou à ses administrateurs. De plus,
les données de protection contiennent les éléments suivants :

1. Niveau de sécurité : protection maximale ou prise en charge du chiffrement

2. Propriétaire et liste des Service Guardian hôtes approuvés, où la machine virtuelle
peut s’exécuter
3. Données d’initialisation de la machine virtuelle ([Link], certificat RDP)
4. Liste des disques de modèle signés et approuvés pour la création de la machine
virtuelle dans l’environnement de virtualisation

Au moment de la création d’une machine virtuelle dotée d’une protection maximale ou

prenant en charge le chiffrement, ou de la conversion d’une machine virtuelle existante,
vous êtes invité à sélectionner les données de protection au lieu d’entrer les
informations sensibles.

De combien de fichiers de données de protection ai-je besoin ? Un seul fichier de

données de protection peut être utilisé pour créer chaque machine virtuelle dotée d’une
protection maximale. Toutefois, si une machine virtuelle dotée d’une protection
maximale impose un changement de l’un des quatre éléments, un fichier de données de
protection supplémentaire est nécessaire. Par exemple, vous pouvez avoir un fichier de
données de protection pour votre service informatique et un autre fichier de données
de protection pour le service des ressources humaines (RH), car leur mot de passe
d’administrateur initial et leurs certificats RDP diffèrent.

Bien qu’il soit possible d’utiliser des fichiers de données de protection distincts pour
chaque machine virtuelle dotée d’une protection maximale, ce choix n’est pas forcément
optimal et doit reposer sur de bonnes raisons. Par exemple, si chaque machine virtuelle
dotée d’une protection maximale doit avoir un mot de passe d’administrateur distinct,
utilisez plutôt un service ou un outil de gestion des mots de passe tel que LAPS
(solution de mot de passe d’administrateur local) de Microsoft .
Création d’une machine virtuelle dotée d’une
protection maximale sur une infrastructure de
virtualisation
Il existe plusieurs options pour créer une machine virtuelle dotée d’une protection
maximale sur une infrastructure de virtualisation (ce qui suit s’applique à la fois aux
machines virtuelles dotées d’une protection maximale et aux machines virtuelles prenant
en charge le chiffrement) :

1. Créer une machine virtuelle dotée d’une protection maximale dans votre
environnement, et la charger dans l’infrastructure de virtualisation
2. Créer une machine virtuelle dotée d’une protection maximale à partir d’un modèle
signé dans l’infrastructure de virtualisation
3. Doter une machine virtuelle existante d’une protection maximale (la machine
virtuelle existante doit être de génération 2 et doit exécuter Windows Server 2012
ou une version ultérieure)

La création de machines virtuelles à partir d’un modèle est une pratique normale.
Toutefois, dans la mesure où le disque de modèle utilisé pour créer une machine
virtuelle dotée d’une protection maximale réside sur l’infrastructure de virtualisation, des
mesures supplémentaires sont nécessaires pour vérifier qu’il n’a pas été falsifié par un
administrateur d’infrastructure malveillant ou par un programme malveillant s’exécutant
sur l’infrastructure. Ce problème est résolu à l’aide des disques de modèle signés. Les
disques de modèle signés et les signatures de disque correspondantes sont créés par
des administrateurs fiables ou par le propriétaire de la machine virtuelle. Quand une
machine virtuelle dotée d’une protection maximale est créée, la signature du disque de
modèle est comparée aux signatures contenues dans le fichier de données de
protection spécifié. Si l’une des signatures du fichier de données de protection
correspond à la signature du disque de modèle, le processus de déploiement se
poursuit. Si aucune correspondance n’est trouvée, le processus de déploiement est
abandonné, ce qui permet de garantir que les secrets de machine virtuelle ne seront pas
compromis en raison d’un disque de modèle non fiable.

Quand vous utilisez des disques de modèle signés pour créer des machines virtuelles
dotées d’une protection maximale, vous disposez de deux options :

1. Utiliser un disque de modèle signé existant, fourni par votre fournisseur de

virtualisation. Dans ce cas, le fournisseur de virtualisation conserve les disques de
modèle signés.
2. Charger un disque de modèle signé dans l’infrastructure de virtualisation. Le
propriétaire de la machine virtuelle est responsable de la conservation des disques
de modèle signés.
Déploiement du service Guardian hôte
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

L’un des objectifs les plus importants de la fourniture d’un environnement hébergé est
de garantir la sécurité des machines virtuelles s’exécutant dans l’environnement. En tant
que fournisseur de services cloud ou administrateur d’un cloud privé d’entreprise, vous
pouvez utiliser une structure protégée pour offrir un environnement plus sécurisé pour
les machines virtuelles. Une structure Service Guardian se compose d’un Service
Guardian hôte (HGS) généralement constitué d’un cluster de trois nœuds, d’un ou
plusieurs hôtes protégés et d’un ensemble de machines virtuelles dotées d’une
protection maximale.

Vidéo : Déploiement d’une infrastructure

protégée
[Link]
9576da38d9f1?autoplay=false&postJsllMsg=true&autoCaptions=fr-fr

Tâches de déploiement pour les infrastructures

protégées et les machines virtuelles dotées
d’une protection maximale
Le tableau suivant décompose les tâches de déploiement d’une infrastructure protégée
et de création de machines virtuelles dotées d’une protection maximale en fonction des
différents rôles d’administrateur. Notez qu’à partir du moment où l’administrateur SGH
configure SGH avec des hôtes Hyper-V autorisés, un administrateur d’infrastructure
collecte et fournit les informations d’identification relatives aux hôtes en même temps.

Étape et lien vers le contenu Image

1 - Vérifier les prérequis pour SGH

2 - Configurer le premier nœud SGH

Étape et lien vers le contenu Image

3 - Configurer des nœuds SGH supplémentaires

4 - Configurer le DNS de l’infrastructure

5 - Vérifier les prérequis de l’hôte (clé) et Vérifier les prérequis de l’hôte (TPM)

6 - Créer une clé d’hôte (clé) et Collecter les informations relatives à l’hôte (TPM)

7 - Configurer SGH avec les informations relatives à l’hôte

8 - Confirmer la capacité d’attestation des hôtes

9 - Configurer VMM (facultatif)

10 - Créer des disques de modèle

11 - Créer un disque d’assistance relatif à la protection maximale des machines

virtuelles pour VMM (facultatif)

12 - Configurer Windows Azure Pack (facultatif)

13 - Créer un fichier de données de protection

14 - Créer des machines virtuelles dotées d’une protection maximale à l’aide de

Windows Azure Pack

15 - Créer des machines virtuelles dotées d’une protection maximale à l’aide de VMM

Références supplémentaires
Structure protégée et machines virtuelles dotées d’une protection maximale
Démarrage rapide pour le déploiement
d’une protégée
Article • 11/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cette rubrique explique ce qu’est une structure protégée, ce que sont ses exigences et
donne un résumé du processus de déploiement. Pour plus d’informations sur les étapes
de déploiement, consultez Déploiement du Service Guardian hôte pour les hôtes Service
Guardian et les machines virtuelles dotées d’une protection maximale.

Vous préférez la vidéo ? Consultez le cours Microsoft Virtual Academy Déploiement de

machines virtuelles dotées d’une protection maximale et d’une structure protégée avec
Windows Server 2016 .

Qu’est-ce qu’une structure protégée

Une structure protégée est une structure Hyper-V Windows Server 2016 capable de
protéger les charges de travail des locataires contre l’inspection, le vol et la falsification
de la part de programmes malveillants en cours d’exécution sur l’hôte, ainsi que des
administrateurs système. Ces charges de travail de locataire virtualisées, protégées à la
fois au repos et en cours d’exécution, sont appelées machines virtuelles dotées d’une
protection maximale.

Quelles sont les exigences pour une structure

protégée
Les exigences pour une structure protégée sont les suivantes :

Un endroit où exécuter des machines virtuelles dotées d’une protection

maximale et exemptes de logiciels malveillants.

Il s’agit d’hôtes Service Guardian. Les hôtes Service Guardian sont des hôtes Hyper-
V édition Windows Server 2016 Datacenter qui ne peuvent exécuter des machines
virtuelles dotées d’une protection maximale que s’ils peuvent prouver qu’ils
s’exécutent dans un état connu et approuvé auprès d’une autorité externe appelée
Service Guardian hôte (SGH). Le SGH est un nouveau rôle de serveur dans
 Windows Server 2016 et est généralement déployé en tant que cluster à trois
nœuds.

Un moyen de vérifier qu’un hôte est sain.

Le SGH effectue l’attestation, où il mesure l’intégrité des hôtes Service Guardian.

Processus permettant de libérer de manière sécurisée des clés sur des hôtes
sains.

Le SGH assure la protection des clés et la libération des clés, où il libère les clés pour
les hôtes sains.

Outils de gestion pour automatiser l’approvisionnement et l’hébergement

sécurisés de machines virtuelles dotées d’une protection maximale.

Si vous le souhaitez, vous pouvez ajouter ces outils de gestion à une structure
protégée :
System Center 2016 – Virtual Machine Manager (VMM). Le VMM est
recommandé, car il fournit des outils de gestion supplémentaires au-delà de ce
que vous obtenez en utilisant uniquement les applets de commande PowerShell
fournies avec Hyper-V et les charges de travail d’une structure protégée).
System Center 2016 Service Provider Foundation (SPF). Il s’agit d’une API entre
Windows Azure Pack et VMM, et une condition préalable à l’utilisation de
Windows Azure Pack.
Windows Azure Pack fournit une bonne interface graphique Web pour gérer
une structure protégée et des machines virtuelles dotées d’une protection
maximale.

Dans la pratique, une décision doit être prise à l’avance : le mode d’attestation utilisé
par la structure protégée. Il existe deux moyens (deux modes mutuellement exclusifs)
permettant à SGH de mesurer qu’un hôte Hyper-V est sain. Lorsque vous initialisez SGH,
vous devez choisir le mode :

Attestation de clé d’hôte, ou mode clé, est moins sécurisée, mais plus facile à
adopter
Attestation basée sur le TPM, ou mode TPM, est plus sécurisée, mais nécessite
davantage de configuration et un matériel spécifique

Si nécessaire, vous pouvez déployer en mode clé à l’aide d’hôtes Hyper-V existants qui
ont été mis à niveau vers l’édition Windows Server 2019 Datacenter, puis convertir en
mode TPM plus sécurisé lorsque la prise en charge du matériel serveur (y compris TPM
2.0) est disponible.
Maintenant que vous savez quels sont les éléments, passons en revue un exemple de
modèle de déploiement.

Comment passer de l’actuelle structure Hyper-V

à une structure protégée
Imaginons ce scénario : vous disposez d’une structure Hyper-V existante, comme
[Link] dans l’image suivante, et vous souhaitez créer une structure protégée
Windows Server 2016.

Étape 1 : Déployer les hôtes Hyper-V exécutant

Windows Server 2016
Les hôtes Hyper-V doivent exécuter l’édition Windows Server 2016 Datacenter ou
ultérieure. Si vous mettez à niveau des hôtes, vous pouvez effectuer une mise à niveau
de l’édition Standard vers l’édition Datacenter.
Étape 2 : Déployer le Service Guardian hôte
(SGH)
Installez ensuite le rôle serveur SGH et déployez-le en tant que cluster à trois nœuds,
comme l’exemple [Link] dans l’image suivante. Cela nécessite trois applets de
commande PowerShell :

Pour ajouter le rôle SGH, utilisez Install-WindowsFeature

Pour installer le SGH, utilisez Install-HgsServer
Pour initialiser le SGH avec le mode d’attestation choisi, utilisez Initialize-
HgsServer

Si vos serveurs Hyper-V existants ne remplissent pas les conditions préalables requises
pour le mode TPM (par exemple, ils n’ont pas de TPM 2.0), vous pouvez initialiser SGH à
l’aide d’une attestation de l’administrateur (mode AD), ce qui nécessite une approbation
Active Directory avec le domaine de structure.
Dans notre exemple, supposons que Contoso déploie initialement en mode AD afin de
répondre immédiatement aux exigences de conformité et qu’il prévoit de convertir en
attestation TPM plus sécurisée une fois que le matériel serveur approprié peut être
acheté.

Étape 3 : Extraire les identités, les bases de

référence matérielles et les stratégies
d’intégrité du code
Le processus d’extraction des identités des hôtes Hyper-V dépend du mode
d’attestation utilisé.

Pour le mode AD, l’ID de l’hôte est le compte d’ordinateur qu’il a joint au domaine, qui
doit être membre d’un groupe de sécurité désigné dans le domaine de structure.
L’appartenance au groupe désigné est la seule façon de déterminer si l’hôte est sain ou
non.

Dans ce mode, l’administrateur de structure est le seul responsable de la garantie de

l’intégrité des hôtes Hyper-V. Étant donné que SGH ne joue aucun rôle dans la décision
de ce qui est ou n’est pas autorisé à s’exécuter, les programmes malveillants et les
débogueurs fonctionnent comme prévu.

Cependant, les débogueurs qui tentent de se joindre directement à un processus (tels

que [Link]), sont bloqués pour les machines virtuelles dotées d’une protection
maximale, car le processus de travail de la machine virtuelle ([Link]) est un PPL
(Protected Process Light). Les autres techniques de débogage, telles que celles utilisées
par [Link], ne sont pas bloquées. Contrairement aux machines virtuelles protégées,
le processus de travail pour les machines virtuelles prises en charge par le chiffrement
ne s’exécute pas en tant que PPL, de sorte que les débogueurs traditionnels comme
[Link] continueront à fonctionner normalement.

Autrement dit, les étapes de validation rigoureuses utilisées pour le mode TPM ne sont
en aucun cas utilisées pour le mode AD.

Pour le mode TPM, trois éléments sont requis :

1. Une clé publique de type EK (ou EKpub) du module TPM 2.0 sur chaque hôte
Hyper-V. Pour capturer l’EKpub, utilisez Get-PlatformIdentifier .
2. Base de référence matérielle. Si chacun de vos hôtes Hyper-V est identique, vous
avez besoin d’une base de référence unique. Si ce n’est pas le cas, vous en aurez
besoin pour chaque classe de matériel. La base de référence se présente sous la
forme d’un fichier journal de groupe d’informatique digne de confiance, ou
TCGlog. Le TCGlog contient tout ce que l’hôte a fait, du microprogramme UEFI au
noyau jusqu’à l’emplacement où l’hôte est entièrement démarré. Pour capturer la
base de référence matérielle, installez le rôle Hyper-V et la fonctionnalité de prise
en charge Hyper-V de Host Guardian et utilisez Get-HgsAttestationBaselinePolicy .
3. Stratégie d’intégrité du code. Si chacun de vos hôtes Hyper-V est identique, une
seule stratégie d’intégrité du code (ou stratégie CI) est tout ce dont vous avez
besoin. Si ce n’est pas le cas, vous en aurez besoin pour chaque classe de matériel.
Windows Server 2016 et Windows 10 ont tous deux une nouvelle forme
d’application des stratégies CI, appelée Intégrité du code appliquée par l’hyperviseur
(HVCI). HVCI fournit une application forte et garantit qu’un hôte n’est autorisé à
exécuter que des fichiers binaires qu’un administrateur approuvé lui a autorisés à
exécuter. Ces instructions sont incluses dans une stratégie CI ajoutée au SGH. Le
SGH mesure la stratégie CI de chaque hôte avant qu’il ne soit autorisé à exécuter
des machines virtuelles dotées d’une protection maximale. Pour capturer une
stratégie CI, utilisez New-CIPolicy . La stratégie doit ensuite être convertie dans sa
forme binaire à l’aide de ConvertFrom-CIPolicy .
C’est tout : la structure protégée est créée, en termes de structure pour l’exécuter. Vous
pouvez désormais créer un disque de modèle de machines virtuelles dotées d’une
protection maximale et un fichier de données de protection afin que les machines
virtuelles dotées d’une protection maximale puissent être approvisionnées simplement
et en toute sécurité.

Étape 4 : Créer un modèle pour les machines

virtuelles dotées d’une protection maximale
Un modèle de machine virtuelle dotée d’une protection maximale protège les disques
de modèle en créant une signature du disque à un point fiable connu dans le temps. Si
le disque de modèle est ultérieurement infecté par un programme malveillant, sa
signature diffère du modèle d’origine qui sera détecté par le processus
d’approvisionnement de machines virtuelles sécurisées dotées d’une protection
maximale. Les disques de modèle protégés sont créés en exécutant l’Assistant de
création de disques de modèle protégé ou Protect-TemplateDisk sur un disque de
modèle normal.

Chacun d’eux est inclus avec la fonctionnalité Outils de machine virtuelle dotée d’une
protection maximale dans les Outils d’administration de serveur distant pour
Windows 10 . Après avoir téléchargé les outils d’administration de serveur distant,
exécutez cette commande pour installer la fonctionnalité Outils de machine virtuelle
dotée d’une protection maximale :

PowerShell

Install-WindowsFeature RSAT-Shielded-VM-Tools -Restart

Un administrateur fiable, tel que l’administrateur de structure ou le propriétaire de la
machine virtuelle, aura besoin d’un certificat (souvent délivré par un fournisseur de
services d’hébergement) pour signer le disque de modèle VHDX.

La signature de disque est calculée sur la partition du système d’exploitation du disque

virtuel. Si quelque chose change sur la partition du système d’exploitation, la signature
change également. Cela permet aux utilisateurs d’identifier fortement les disques
auxquels ils font confiance en spécifiant la signature appropriée.

Avant de commencer, passez en revue les exigences du disque du modèle.

Étape 5 : Créer un fichier de données de

protection
Un fichier de données de protection, également appelé fichier .pdk, capture des
informations sensibles sur la machine virtuelle, telles que le mot de passe
administrateur.
Le fichier de données de protection inclut également le paramètre de stratégie de
sécurité pour la machine virtuelle dotée d’une protection maximale. Vous devez choisir
l’une des deux stratégies de sécurité lorsque vous créez un fichier de données de
protection :

Protégé

L’option la plus sécurisée, qui élimine de nombreux vecteurs d’attaque

administratifs.

Chiffrement pris en charge

Un niveau de protection moindre qui offre toujours les avantages de conformité

de la possibilité de chiffrer une machine virtuelle, mais permet aux administrateurs
Hyper-V d’effectuer des opérations telles que l’utilisation de la connexion à la
console de machine virtuelle et de PowerShell Direct.
Vous pouvez ajouter des éléments de gestion facultatifs tels que VMM ou Windows
Azure Pack. Si vous souhaitez créer une machine virtuelle sans installer ces éléments,
consultez Étape par étape : création de machines virtuelles dotées d’une protection
maximale sans VMM.

Étape 6 : Créer une machine virtuelle dotée

d’une protection maximale
La création de machines virtuelles dotées d’une protection maximale diffère très peu des
machines virtuelles normales. Dans Windows Azure Pack, l’expérience est encore plus
facile que pour la création d’une machine virtuelle normale, car vous devez uniquement
fournir un nom, protéger le fichier de données (contenant le reste des informations de
spécialisation) et le réseau de machines virtuelles.
Étape suivante
Prérequis SGH
Déployer le service Guardian hôte (HGS)
Article • 11/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Pour déployer le SGH, effectuez les tâches suivantes :

Préparer le déploiement du service Guardian hôte

Installer SGH
Initialiser SGH
Configurer Https (facultatif)
Ajouter des nœuds

Références supplémentaires
Déploiement du Service Guardian hôte pour les hôtes Service Guardian et les VM
dotées d’une protection maximale
Étapes de configuration des hôtes Hyper-V qui vont devenir des hôtes Service
Guardian
Passer en revue les prérequis de Service
Guardian hôte
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cette rubrique décrit les prérequis de SGH et les étapes initiales de préparation du
déploiement de SGH.

Prérequis
Matériel : SGH peut être exécuté sur des machines physiques ou virtuelles, mais les
machines physiques sont recommandées.

Si vous souhaitez exécuter SGH en tant que cluster physique à trois nœuds (pour
des raisons de disponibilité), vous devez disposer de trois serveurs physiques.
(Conformément aux bonnes pratiques du clustering, les trois serveurs doivent avoir
un matériel très similaire.)

Système d’exploitation : L’attestation de clé d’hôte nécessite l’édition Standard ou

Datacenter de Windows Server 2019 combinée à l’attestation v2. Pour l’attestation
basée sur le module TPM, le serveur SGH peut exécuter les éditions Standard ou
Datacenter de Windows Server 2019 ou Windows Server 2016.

Rôles serveur : Service Guardian hôte et rôles serveur de prise en charge.

Autorisations/privilèges de configuration pour le domaine de l’infrastructure

(hôte) : Vous devez configurer le transfert DNS entre le domaine de l’infrastructure
(hôte) et le domaine SGH.

Mise à niveau de SGH

Si vous avez déjà déployé SGH et si vous souhaitez mettre à niveau son système
d’exploitation, suivez les conseils d’aide pour la mise à niveau afin de mettre à niveau
vos serveurs SGH et Hyper-V vers l’OS le plus récent.

Étape suivante
Obtenir des certificats pour SGH
Obtenir des certificats pour SGH
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Lorsque vous déployez SGH, vous êtes invité à fournir des certificats de signature et de
chiffrement qui seront utilisés pour protéger les informations sensibles nécessaires au
démarrage d’une machine virtuelle dotée d'une protection maximale. Ces certificats ne
quittent jamais SGH. Ils sont utilisés pour déchiffrer les clés de machine virtuelle dotée
d’une protection maximale uniquement quand l’hôte sur lequel ils s’exécutent a prouvé
qu’il est sain. Les locataires (propriétaires de machines virtuelles) utilisent la moitié
publique des certificats pour autoriser votre centre de données à exécuter leurs
machines virtuelles dotées d’une protection maximale. Cette section décrit les étapes
nécessaires à l’obtention de certificats de signature et de chiffrement compatibles pour
SGH.

Demander des certificats à votre autorité de

certification
Bien que cela ne soit pas obligatoire, il est vivement recommandé d’obtenir vos
certificats auprès d’une autorité de certification approuvée. Cela permet aux
propriétaires de machines virtuelles de vérifier qu’ils autorisent le serveur SGH approprié
(c’est-à-dire le fournisseur de services ou le centre de données) à exécuter leurs
machines virtuelles dotées d’une protection maximale. Dans un scénario d’entreprise,
vous pouvez choisir d’utiliser votre propre AC d’entreprise pour émettre ces certificats.
Les hébergeurs et les fournisseurs de services doivent utiliser à la place une autorité de
certification publique bien connue.

Les certificats de signature et de chiffrement doivent être émis avec les propriétés de
certificat suivantes (sauf si celles-ci portent la mention « recommandée ») :

Propriété de Valeur requise

modèle de
certificat

Fournisseur de N’importe quel fournisseur de stockage de clés (KSP). Les fournisseurs de

chiffrement services de chiffrement hérités ne sont pas pris en charge.

Algorithme de RSA
clé
 Propriété de Valeur requise
modèle de
certificat

Taille de clé 2 048 bits

minimale

Algorithme de Recommandé : SHA256

signature

Utilisation de la Signature numérique et chiffrement des données

clé

Utilisation Authentification du serveur

améliorée de la
clé

Stratégie de Le renouvellement doit être effectué avec la même clé. Le renouvellement des
renouvellement certificats SGH avec des clés distinctes empêche le démarrage des machines
des clés virtuelles dotées d’une protection maximale.

Nom d'objet Recommandé : nom ou adresse web de votre entreprise. Ces informations sont
affichées à l’intention des propriétaires de machines virtuelles dans l’Assistant
Fichier de données de protection.

Ces impératifs s’appliquent, que vous utilisiez des certificats basés sur du matériel ou un
logiciel. Pour des raisons de sécurité, il est recommandé de créer vos clés SGH dans un
module HSM (module de sécurité matériel) pour empêcher la copie des clés privées en
dehors du système. Suivez les conseils d’aide de votre fournisseur HSM pour demander
des certificats avec les attributs ci-dessus. Veillez à installer et autoriser le fournisseur de
stockage de clés (KSP) lié au module HSM sur chaque nœud SGH.

Chaque nœud SGH doit avoir accès aux mêmes certificats de signature et de
chiffrement. Si vous utilisez des certificats basés sur un logiciel, vous pouvez les exporter
vers un fichier PFX avec un mot de passe, et permettre à SGH de gérer les certificats à
votre place. Vous pouvez également choisir d’installer les certificats dans le magasin de
certificats de la machine locale sur chaque nœud SGH, et fournir l’empreinte numérique
à SGH. Les deux options sont expliquées dans la rubrique Initialiser le cluster SGH.

Créer des certificats autosignés pour des

scénarios de test
Si vous créez un environnement de labo SGH, et si vous ne disposez pas ou ne souhaitez
pas utiliser d’autorité de certification, vous pouvez créer des certificats autosignés. Vous
recevrez un avertissement au moment de l’importation des informations de certificat
dans l’Assistant Fichier de données de protection, mais toutes les fonctionnalités
resteront les mêmes.

Pour créer des certificats autosignés et les exporter vers un fichier PFX, exécutez les
commandes suivantes dans PowerShell :

PowerShell

$certificatePassword = Read-Host -AsSecureString -Prompt 'Enter a password

for the PFX file'

$signCert = New-SelfSignedCertificate -Subject 'CN=HGS Signing Certificate'

-KeyUsage DataEncipherment, DigitalSignature
Export-PfxCertificate -FilePath '.\[Link]' -Password
$certificatePassword -Cert $signCert

# Remove the certificate from "Personal" container

Remove-Item $[Link]
# Remove the certificate from "Intermediate certification authorities"
container
Remove-Item -Path "Cert:\LocalMachine\CA\$($[Link])"

$encCert = New-SelfSignedCertificate -Subject 'CN=HGS Encryption

Certificate' -KeyUsage DataEncipherment, DigitalSignature
Export-PfxCertificate -FilePath '.\[Link]' -Password
$certificatePassword -Cert $encCert

# Remove the certificate from "Personal" container

Remove-Item $[Link]
# Remove the certificate from "Intermediate certification authorities"
container
Remove-Item -Path "Cert:\LocalMachine\CA\$($[Link])"

Demander un certificat SSL

Toutes les clés et les informations sensibles transmises entre les hôtes Hyper-V et SGH
sont chiffrées au niveau du message. En d’autres termes, les informations sont chiffrées
à l’aide de clés connues de SGH ou d’Hyper-V. Ainsi, personne ne peut renifler votre
trafic réseau pour voler les clés de vos machines virtuelles. Toutefois, si vous avez des
impératifs de conformité, ou si vous préférez simplement chiffrer toutes les
communications entre Hyper-V et SGH, vous pouvez configurer SGH avec un certificat
SSL, qui chiffrera toutes les données au niveau du transport.

Les hôtes Hyper-V et les nœuds SGH doivent approuver le certificat SSL que vous
fournissez. Il est donc recommandé de demander le certificat SSL à votre autorité de
certification d’entreprise. Quand vous demandez le certificat, veillez à spécifier les
éléments suivants :
 Propriété Valeur requise
du
certificat
SSL

Nom Adresse utilisée par les clients SGH (autrement dit, les hôtes Service Guardian) pour
d'objet accéder au serveur SGH. Il s’agit généralement de l’adresse DNS de votre cluster SGH,
que l’on appelle nom de réseau distribué ou objet d’ordinateur virtuel (VCO). Il s’agit
de la concaténation de votre nom de service SGH fourni à Initialize-HgsServer et
de votre nom de domaine SGH.

Autre Si vous utilisez un autre nom DNS pour atteindre votre cluster SGH (par exemple s’il
nom de se trouve derrière un équilibreur de charge, ou si vous utilisez des adresses
l'objet différentes pour un sous-ensemble de nœuds dans une topologie complexe), veillez
à inclure ces noms DNS dans le champ SAN de votre demande de certificat. Notez
que si l’extension SAN est renseignée, le nom de sujet est ignoré. Le SAN doit donc
inclure toutes les valeurs, notamment celle que vous placez normalement dans le
nom de sujet.

Les options permettant de spécifier ce certificat au moment de l’initialisation du serveur

SGH sont décrites dans Configurer le premier nœud SGH. Vous pouvez également
ajouter ou changer le certificat SSL plus tard à l’aide de l’applet de commande Set-
HgsServer.

Étape suivante
Installer SGH
Choisir d’installer SGH dans sa propre
forêt dédiée ou dans une forêt bastion
existante
Article • 09/03/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

La forêt Active Directory pour SGH est sensible, car ses administrateurs ont accès aux
clés qui contrôlent les machines virtuelles dotées d’une protection maximale.
L’installation par défaut configure une nouvelle forêt dédiée pour SGH ainsi que d’autres
dépendances. Cette option est recommandée, car l’environnement est autonome et
connu pour être sécurisé au moment de sa création.

La seule exigence technique pour installer SGH dans une forêt existante est qu’elle soit
ajoutée au domaine racine. Les domaines non-racine ne sont pas pris en charge.
Toutefois, il y a aussi des exigences opérationnelles et des bonnes pratiques liées à la
sécurité pour l’utilisation d’une forêt existante. Les forêts candidates sont conçues pour
servir une fonction sensible, comme la forêt utilisée par Gestion des accès privilégiés
pour AD DS ou une forêt d’environnement administratif avec sécurité renforcée (ESAE).
Ces forêts présentent généralement les caractéristiques suivantes :

Elles ont peu d’administrateurs (distincts des administrateurs de structure)

Elles ont un petit nombre de connexions
Elles ne sont pas à usage général par nature

Les forêts à usage général comme les forêts de production ne peuvent pas être utilisées
par SGH. Les forêts de structure ne conviennent pas non plus, car SGH doit être isolé
des administrateurs de structure.

Étape suivante
Choisissez l’option d’installation qui convient le mieux à votre environnement :

Installer SGH dans sa propre forêt dédiée

Installer SGH dans une forêt bastion existante
Installer SGH dans une nouvelle forêt
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Ajouter le rôle serveur SGH

Exécutez les commandes suivantes dans une session PowerShell avec élévation de
privilèges pour ajouter le rôle serveur SGH et installer SGH.

Ajoutez le rôle Host Guardian Service en exécutant la commande suivante :

PowerShell

Install-WindowsFeature -Name HostGuardianServiceRole -IncludeManagementTools

-Restart

Installer SGH
Le service Guardian hôte doit être installé dans une forêt Active Directory distincte.
Assurez-vous que l’ordinateur SGH n’est pas joint à un domaine avant de démarrer et
de vous connecter en tant qu’administrateur de l’ordinateur local.

Exécutez les commandes suivantes pour installer le service Guardian hôte et configurer
son domaine. Le mot de passe que vous spécifiez ici s’applique uniquement au mode de
réparation des services d’annuaire pour Active Directory ; il ne modifie pas le mot de
passe de connexion de votre compte d’administrateur. Vous pouvez spécifier le nom de
domaine de votre choix pour - HgsDomainName.

PowerShell

$adminPassword = ConvertTo-SecureString -AsPlainText '<password>' -Force

Install-HgsServer -HgsDomainName '[Link]' -

SafeModeAdministratorPassword $adminPassword -Restart

Étapes suivantes
Pour connaître les étapes suivantes de configuration de l’attestation basée sur
TPM, consultez Initialiser le cluster SGH à l’aide du mode TPM dans une nouvelle
 forêt dédiée (valeur par défaut).
Pour connaître les étapes suivantes de configuration de l’attestation de clé d’hôte,
consultez Initialiser le cluster SGH à l’aide du mode clé dans une nouvelle forêt
dédiée (valeur par défaut).
Pour connaître les étapes suivantes de configuration de l’attestation basée sur
administration (déconseillée dans Windows Server 2019), consultez Initialiser le
cluster SGH à l’aide du mode AD dans une nouvelle forêt dédiée (par défaut).

Étape suivante
Initialiser SGH
Installer SGH dans une forêt bastion
existante
Article • 12/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Joindre le serveur SGH au domaine racine

Dans une forêt bastion existante, SGH doit être ajouté au domaine racine. Utilisez
Gestionnaire de serveur ou Add-Computer pour joindre votre serveur SGH au domaine
racine.

Ajouter le rôle serveur SGH

Exécutez toutes les commandes de cette rubrique dans une session PowerShell avec
élévation de privilèges.

Ajoutez le rôle Host Guardian Service en exécutant la commande suivante :

PowerShell

Install-WindowsFeature -Name HostGuardianServiceRole -IncludeManagementTools

-Restart

Si votre centre de données dispose d’une forêt bastion sécurisée dans laquelle vous
souhaitez joindre des nœuds SGH, procédez comme suit. Vous pouvez également
utiliser ces étapes pour configurer au moins 2 clusters SGH indépendants qui sont joints
au même domaine.

Joignez le serveur SGH au domaine souhaité

Utilisez Gestionnaire de serveur ou Add-Computer pour joindre les serveurs SGH au
domaine souhaité.

Préparer des objets Active Directory

Créez un compte de service managé de groupe et 2 groupes de sécurité. Vous pouvez
également précéder les objets de cluster si le compte avec lequel vous initialisez SGH
n’est pas autorisé à créer des objets ordinateur dans le domaine.

Compte de service géré de groupe

Le compte de service managé de groupe (gMSA) est l’identité utilisée par SGH pour
récupérer et utiliser ses certificats. Utilisez New-ADServiceAccount pour créer un compte
gMSA. S’il s’agit du premier compte gMSA dans le domaine, vous devez ajouter une clé
racine du service de distribution de clés.

Chaque nœud SGH doit être autorisé à accéder au mot de passe gMSA. Le moyen le
plus simple de configurer cela consiste à créer un groupe de sécurité qui contient tous
vos nœuds SGH et à accorder à ce groupe de sécurité l’accès pour récupérer le mot de
passe gMSA.

Vous devez redémarrer votre serveur SGH après l’avoir ajouté à un groupe de sécurité
pour vous assurer qu’il obtienne sa nouvelle appartenance au groupe.

PowerShell

# Check if the KDS root key has been set up

if (-not (Get-KdsRootKey)) {
# Adds a KDS root key effective immediately (ignores normal 10 hour
waiting period)
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))
}

# Create a security group for HGS nodes

$hgsNodes = New-ADGroup -Name 'HgsServers' -GroupScope DomainLocal -PassThru

# Add your HGS nodes to this group

# If your HGS server object is under an organizational unit, provide the
full distinguished name instead of "HGS01"
Add-ADGroupMember -Identity $hgsNodes -Members "HGS01"

# Create the gMSA

New-ADServiceAccount -Name 'HGSgMSA' -DnsHostName '[Link]' -
PrincipalsAllowedToRetrieveManagedPassword $hgsNodes

Le gMSA nécessite le droit de générer des événements dans le journal de sécurité sur
chaque serveur SGH. Si vous utilisez stratégie de groupe pour configurer l’attribution
des droits utilisateur, assurez-vous que le compte gMSA dispose du privilège Générer
des événements d’audit sur vos serveurs SGH.

７ Notes
 Les comptes de service managés de groupe sont disponibles à partir du schéma
Active Directory Windows Server 2012. Pour plus d’informations, consultez
Exigences des comptes de service managés de groupe.

Groupes de sécurité JEA

Lorsque vous configurez SGH, un point de terminaison PowerShell JEA (Just Enough
Administration) est configuré pour permettre aux administrateurs de gérer SGH sans
avoir besoin de privilèges d’administrateur local complets. Vous n’êtes pas obligé
d’utiliser JEA pour gérer SGH, mais il doit toujours être configuré lors de l’exécution de
Initialize-HgsServer. La configuration du point de terminaison JEA consiste à désigner 2
groupes de sécurité qui contiennent vos administrateurs SGH et les réviseurs SGH. Les
utilisateurs qui appartiennent au groupe d’administration peuvent ajouter, modifier ou
supprimer des stratégies sur SGH ; les réviseurs peuvent uniquement afficher la
configuration actuelle.

Créez 2 groupes de sécurité pour ces groupes JEA à l’aide des outils d’administration
Active Directory ou de New-ADGroup.

PowerShell

New-ADGroup -Name 'HgsJeaReviewers' -GroupScope DomainLocal

New-ADGroup -Name 'HgsJeaAdmins' -GroupScope DomainLocal

Objets de cluster
Si le compte que vous utilisez pour configurer SGH n’a pas l’autorisation de créer de
nouveaux objets ordinateur dans le domaine, vous devez précéder les objets de cluster.
Ces étapes sont expliquées dans Prestage Cluster Computer Objects in Active Directory
Domain Services.

Pour configurer votre premier nœud SGH, vous devez créer un objet de nom de cluster
(CNO) et un objet d’ordinateur virtuel (VCO). Le CNO représente le nom du cluster et est
principalement utilisé en interne par le clustering de basculement. Le VCO représente le
service SGH qui réside au-dessus du cluster et sera le nom inscrit auprès du serveur
DNS.

） Important
 L’utilisateur qui s’exécutera Initialize-HgsServer nécessite un contrôle total sur
les objets CNO et VCO dans Active Directory.

Pour préparer rapidement votre CNO et votre VCO, faites exécuter les commandes
PowerShell suivantes par un administrateur Active Directory :

PowerShell

# Create the CNO

$cno = New-ADComputer -Name 'HgsCluster' -Description 'HGS CNO' -Enabled
$false -Passthru

# Create the VCO

$vco = New-ADComputer -Name 'HgsService' -Description 'HGS VCO' -Passthru

# Give the CNO full control over the VCO

$vcoPath = Join-Path "AD:\" $[Link]
$acl = Get-Acl $vcoPath
$ace = New-Object [Link]
$[Link], "GenericAll", "Allow"
$[Link]($ace)
Set-Acl -Path $vcoPath -AclObject $acl

# Allow time for your new CNO and VCO to replicate to your other Domain
Controllers before continuing

Exceptions de base de référence de sécurité

Si vous déployez SGH dans un environnement hautement verrouillé, certains paramètres
stratégie de groupe peuvent empêcher SGH de fonctionner normalement. Vérifiez vos
objets stratégie de groupe pour les paramètres suivants et suivez les instructions si vous
êtes affecté :

Ouverture de session réseau

Chemin d’accès stratégie : Configuration ordinateur\Paramètres Windows\Paramètres
de sécurité\Stratégies locales\Attribution des droits utilisateur.

Nom de stratégie : interdire l’accès à cet ordinateur à partir du réseau

Valeur requise : vérifiez que la valeur ne bloque pas les connexions réseau pour tous les
comptes locaux. Toutefois, vous pouvez bloquer en toute sécurité les comptes
d’administrateur local.
Raison: le clustering de basculement s’appuie sur un compte local non administrateur
appelé CLIUSR pour gérer les nœuds de cluster. Le blocage de l’ouverture de session
réseau pour cet utilisateur empêche le cluster de fonctionner correctement.

Chiffrement Kerberos
Chemin d’accès stratégie : Configuration ordinateur\Paramètres Windows\Paramètres
de sécurité\Stratégies locales\Options de sécurité

Nom de stratégie : sécurité réseau : configurer les types de chiffrement autorisés pour
Kerberos

Action : si cette stratégie est configurée, vous devez mettre à jour le compte gMSA avec
Set-ADServiceAccount pour utiliser uniquement les types de chiffrement pris en charge
dans cette stratégie. Par exemple, si votre stratégie autorise uniquement
AES128_HMAC_SHA1 et AES256_HMAC_SHA1, vous devez exécuter Set-
ADServiceAccount -Identity HGSgMSA -KerberosEncryptionType AES128,AES256 .

Étapes suivantes
Pour connaître les étapes suivantes de configuration de l’attestation basée sur
TPM, consultez Initialiser le cluster SGH à l’aide du mode TPM dans une forêt
bastion existante.
Pour connaître les étapes suivantes de configuration de l’attestation de clé d’hôte,
consultez Initialiser le cluster SGH à l’aide du mode clé dans une forêt bastion
existante.
Pour connaître les étapes suivantes de configuration de l’attestation basée sur
administration (déconseillée dans Windows Server 2019), consultez Initialiser le
cluster SGH à l’aide du mode AD dans une forêt bastion existante.
Initialiser le Service Guardian hôte
(SGH)
Article • 09/03/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Lorsque vous initialisez SGH, vous spécifiez le mode que SGH utilisera pour mesurer
l’intégrité des hôtes protégés. Il existe deux options qui s’excluent mutuellement. Pour
obtenir des informations générales sur le mode à choisir, consultez le Guide de
planification de l’infrastructure protégée et des machines virtuelles dotées d’une
protection maximale pour les hôtes.

Les rubriques suivantes couvrent les étapes de déploiement pour chaque mode :

Attestation approuvée par TPM (mode TPM)

Attestation de clé d’hôte (mode clé)
Attestation approuvée par l’administrateur (basée sur AD)

Vous devez effectuer ces étapes sur un serveur physique.

Initialiser SGH (Service Guardian hôte) à
l’aide d’une attestation approuvée par le
module de plateforme sécurisée (TPM)
Article • 11/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Ces étapes varient selon que vous initialisez SGH dans une nouvelle forêt ou une forêt
bastion existante :

1. Initialiser le cluster SGH dans une nouvelle forêt (par défaut)

-Ou-

Initialiser le cluster SGH dans une forêt bastion existante

2. Installer des certificats racines TPM approuvés

3. Configurer la structure DNS

Initialiser le cluster SGH avec le mode
TPM dans une nouvelle forêt dédiée
(par défaut)
Article • 09/03/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

1. Les clients peuvent facilement contacter n’importe quel nœud SGH en utilisant le
nom de réseau distribué (DNN) du clustering de basculement. Vous devez choisir
un DNN. Ce nom est inscrit dans le service DNS SGH. Par exemple, si vous avez
3 nœuds SGH avec les noms d’hôte HGS01, HGS02 et HGS03, vous pouvez choisir
« hgs » ou « HgsCluster » pour le DNN.

2. Recherchez vos certificats gardiens SGH. Vous avez besoin d’un certificat de
signature et d’un certificat de chiffrement pour initialiser le cluster SGH. Le moyen
le plus simple de fournir des certificats à SGH est de créer un fichier PFX protégé
par mot de passe pour chaque certificat qui contient les clés publiques et privées.
Si vous utilisez des clés HSM ou d’autres certificats non exportables, vérifiez que le
certificat est installé dans le magasin de certificats de l’ordinateur local avant de
continuer. Pour plus d’informations sur les certificats à utiliser, consultez Obtenir
des certificats pour SGH.

3. Exécutez Initialize-HgsServer dans une fenêtre PowerShell avec élévation de

privilèges sur le premier nœud SGH. La syntaxe de cette applet de commande
prend en charge de nombreuses entrées différentes, mais les 2 appels les plus
courants sont les suivants :

Si vous utilisez des fichiers PFX pour vos certificats de signature et de

chiffrement, exécutez les commandes suivantes :

PowerShell

$signingCertPass = Read-Host -AsSecureString -Prompt "Signing

certificate password"
$encryptionCertPass = Read-Host -AsSecureString -Prompt
"Encryption certificate password"

Initialize-HgsServer -HgsServiceName 'MyHgsDNN' -

SigningCertificatePath '.\[Link]' -
SigningCertificatePassword $signingCertPass -
EncryptionCertificatePath '.\[Link]' -
EncryptionCertificatePassword $encryptionCertPass -TrustTpm
 Si vous utilisez des certificats non exportables installés dans le magasin de
certificats local, exécutez la commande suivante. Si vous ne connaissez pas
les empreintes de vos certificats, vous pouvez lister les certificats disponibles
en exécutant Get-ChildItem Cert:\LocalMachine\My .

PowerShell

Initialize-HgsServer -HgsServiceName 'MyHgsDNN' -

SigningCertificateThumbprint '1A2B3C4D5E6F...' -
EncryptionCertificateThumbprint '0F9E8D7C6B5A...' -TrustTpm

4. Si vous avez fourni des certificats à SGH en utilisant des empreintes, vous êtes
invité à accorder à SGH un accès en lecture sur la clé privée de ces certificats. Sur
un serveur avec l’Expérience utilisateur installée, effectuez les étapes suivantes :
a. Ouvrez le gestionnaire de certificats de l’ordinateur local ([Link])
b. Recherchez le ou les certificats > cliquez avec le bouton droit > toutes les
tâches > gérer les clés privées
c. Cliquez sur Ajouter
d. Dans la fenêtre du sélecteur d’objets, cliquez sur Types d’objets et activez
Comptes de service
e. Entrez le nom du compte de service mentionné dans le texte d’avertissement de
Initialize-HgsServer

f. Vérifiez que le gMSA a l’accès « Lire » sur la clé privée.

Sur Server Core, vous devez télécharger un module PowerShell pour vous aider à
définir les autorisations de clé privée.

a. Exécutez Install-Module GuardedFabricTools sur le serveur SGH s’il a une

connectivité Internet, ou exécutez Save-Module GuardedFabricTools sur un autre
ordinateur et copiez le module sur le serveur SGH.

b. Exécutez Import-Module GuardedFabricTools . Cela ajoute des propriétés

supplémentaires aux objets de certificat trouvés dans PowerShell.

c. Recherchez votre empreinte de certificat dans PowerShell avec Get-ChildItem

Cert:\LocalMachine\My

d. Mettez à jour la liste ACL, en remplaçant l’empreinte par la vôtre, et le compte

gMSA dans le code ci-dessous par le compte listé dans le texte d’avertissement
de Initialize-HgsServer .

PowerShell
 $certificate = Get-Item "Cert:\LocalMachine\1A2B3C..."
$[Link] = $[Link] | Add-AccessRule "HgsSvc_1A2B3C"
Read Allow

Si vous utilisez des certificats HSM ou des certificats stockés dans un fournisseur
de stockage de clés tiers, ces étapes ne s’appliquent peut-être pas. Consultez la
documentation de votre fournisseur de stockage de clés pour savoir comment
gérer les autorisations sur votre clé privée. Dans certains cas, il n’y a pas
d’autorisation ou une autorisation est fournie à tout l’ordinateur quand le certificat
est installé.

5. Et voilà ! Dans un environnement de production, vous devez continuer à ajouter

des nœuds SGH supplémentaires à votre cluster.

Étape suivante
Installer des certificats racine TPM
Initialiser le cluster SGH à l’aide du
mode TPM dans une forêt bastion
existante
Article • 09/03/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Pour initialiser le cluster HGS à l’aide du mode TPM dans une forêt bastion existante,
suivez les étapes ci-dessous. services de domaine Active Directory seront installés sur
l’ordinateur, mais ne doivent pas être configurés.

Recherchez vos certificats gardiens SGH. Vous avez besoin d’un certificat de signature et
d’un certificat de chiffrement pour initialiser le cluster SGH. Le moyen le plus simple de
fournir des certificats à SGH est de créer un fichier PFX protégé par mot de passe pour
chaque certificat qui contient les clés publiques et privées. Si vous utilisez des clés HSM
ou d’autres certificats non exportables, vérifiez que le certificat est installé dans le
magasin de certificats de l’ordinateur local avant de continuer. Pour plus d’informations
sur les certificats à utiliser, consultez Obtenir des certificats pour SGH.

Avant de continuer, vérifiez que vous avez préparé vos objets de cluster pour le service
Guardian hôte et accordé à l’utilisateur connecté un contrôle total sur les objets VCO et
CNO dans Active Directory. Le nom de l’objet d’ordinateur virtuel doit être passé au
paramètre -HgsServiceName et le nom du cluster au paramètre -ClusterName .

 Conseil

Vérifiez bien vos contrôleurs de domaine AD pour vous assurer que vos objets de
cluster ont été répliqués sur tous les contrôleurs de domaine avant de continuer.

Si vous utilisez des certificats PFX, exécutez les commandes suivantes sur le serveur SGH
:

PowerShell

$signingCertPass = Read-Host -AsSecureString -Prompt "Signing certificate

password"
$encryptionCertPass = Read-Host -AsSecureString -Prompt "Encryption
certificate password"

Install-ADServiceAccount -Identity 'HGSgMSA'

 Initialize-HgsServer -UseExistingDomain -ServiceAccount 'HGSgMSA' -
JeaReviewersGroup 'HgsJeaReviewers' -JeaAdministratorsGroup 'HgsJeaAdmins' -
HgsServiceName 'HgsService' -SigningCertificatePath '.\[Link]' -
SigningCertificatePassword $signPass -EncryptionCertificatePath
'.\[Link]' -EncryptionCertificatePassword $encryptionCertPass -TrustTpm

Si vous utilisez des certificats installés sur l’ordinateur local (tels que des certificats HSM
et des certificats non exportables), utilisez les paramètres -
SigningCertificateThumbprint et -EncryptionCertificateThumbprint à la place.

Dans un environnement de production, vous devez continuer à ajouter des nœuds SGH
supplémentaires à votre cluster.

Étape suivante
Installer des certificats racine TPM
Installer des certificats racines TPM
approuvés
Article • 11/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Lorsque vous configurez SGH pour utiliser l’attestation TPM, vous devez également
configurer SGH pour approuver les fournisseurs des modules TPM sur vos serveurs. Ce
processus de vérification supplémentaire garantit que seuls des TPM authentiques et
dignes de confiance sont en mesure d’attester avec votre SGH. Si vous essayez d’inscrire
un TPM non approuvé auprès de Add-HgsAttestationTpmHost , vous recevez une erreur
indiquant que le fournisseur de TPM n’est pas approuvé.

Pour faire confiance à vos TPM, les certificats de signature racine et intermédiaire utilisés
pour signer la clé d’approbation dans les TPM de vos serveurs doivent être installés sur
SGH. Si vous utilisez plusieurs modèles de TPM dans votre centre de données, vous
devrez peut-être installer des certificats différents pour chaque modèle. SGH recherche
les certificats du fournisseur dans les magasins de certificats « TrustedTPM_RootCA » et
« TrustedTPM_IntermediateCA ».

７ Notes

Les certificats de fournisseur de TPM sont différents de ceux installés par défaut
dans Windows et représentent les certificats racine et intermédiaires spécifiques
utilisés par les fournisseurs de TPM.

Une collection de certificats racine et intermédiaires TPM approuvés est publiée par
Microsoft pour votre commodité. Vous pouvez utiliser les étapes ci-dessous pour
installer ces certificats. Si vos certificats TPM ne sont pas inclus dans le package ci-
dessous, contactez votre fournisseur de TPM ou l’OEM de votre serveur pour obtenir les
certificats racine et intermédiaire pour votre modèle TPM spécifique.

Répétez les étapes suivantes sur chaque serveur SGH :

1. Téléchargez le dernier package à partir de [Link]

linkid=2097925 .

2. Vérifiez que la signature du fichier CAB est authentique. Ne continuez pas si la

signature n’est pas valide.
 PowerShell

Get-AuthenticodeSignature .\[Link]

Voici un exemple de sortie :

Directory: C:\Users\Administrator\Downloads

SignerCertificate Status
Path
----------------- ------
----
0DD6D4D4F46C0C7C2671962C4D361D607E370940 Valid
[Link]

3. Développez le fichier cab.

mkdir .\TrustedTPM
[Link] -F:* <[Link]> .\TrustedTPM

4. Par défaut, le script de configuration installe des certificats pour chaque

fournisseur de TPM. Si vous souhaitez importer uniquement des certificats pour
votre fournisseur de TPM spécifique, supprimez les dossiers des fournisseurs de
TPM non approuvés par votre organisation.

5. Installez le package de certification de confiance en exécutant le script

d’installation dans le dossier développé.

cd .\TrustedTPM
.\[Link]

Pour ajouter de nouveaux certificats ou ceux intentionnellement ignorés lors d’une

installation antérieure, répétez simplement les étapes ci-dessus sur chaque nœud de
votre cluster SGH. Les certificats existants resteront approuvés, mais les nouveaux
certificats trouvés dans le fichier cab développé seront ajoutés aux magasins de TPM
approuvés.

Étape suivante
Configurer une structure DNS
Étape suivante
Article • 28/08/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Il existe de nombreuses façons de configurer la résolution de noms pour le domaine de

l’infrastructure. Une méthode simple consiste à configurer une zone de redirecteur
conditionnel dans DNS pour l’infrastructure. Pour configurer cette zone, exécutez les
commandes suivantes dans une console Windows PowerShell avec élévation de
privilèges sur un serveur DNS d’infrastructure. Remplacez les noms et adresses dans la
syntaxe Windows PowerShell ci-dessous en fonction de votre environnement. Ajoutez
des serveurs maîtres pour les nœuds SGH supplémentaires.

Add-DnsServerConditionalForwarderZone -Name '[Link]' -

ReplicationScope "Forest" -MasterServers <IP addresses of HGS server>

Configurer HTTPS

Références supplémentaires
Étapes de configuration des hôtes Hyper-V qui vont devenir des hôtes Service
Guardian
Tâches de déploiement pour les infrastructures protégées et les machines virtuelles
dotées d’une protection maximale
Initialiser SGH à l’aide de l’attestation de
clé d’hôte
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019

Cette étape varie selon que vous initialisez SGH dans une nouvelle forêt ou une forêt
bastion existante :

Initialiser le cluster SGH dans une nouvelle forêt (par défaut)

-Ou-

Initialiser le cluster SGH dans une forêt bastion existante

Initialiser le cluster SGH avec le mode
de clé dans une nouvelle forêt dédiée
(par défaut)
Article • 09/03/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

1. Les clients peuvent facilement contacter n’importe quel nœud SGH en utilisant le
nom de réseau distribué (DNN) du clustering de basculement. Vous devez choisir
un DNN. Ce nom est inscrit dans le service DNS SGH. Par exemple, si vous avez
3 nœuds SGH avec les noms d’hôte HGS01, HGS02 et HGS03, vous pouvez choisir
« hgs » ou « HgsCluster » pour le DNN.

2. Recherchez vos certificats gardiens SGH. Vous avez besoin d’un certificat de
signature et d’un certificat de chiffrement pour initialiser le cluster SGH. Le moyen
le plus simple de fournir des certificats à SGH est de créer un fichier PFX protégé
par mot de passe pour chaque certificat qui contient les clés publiques et privées.
Si vous utilisez des clés HSM ou d’autres certificats non exportables, vérifiez que le
certificat est installé dans le magasin de certificats de l’ordinateur local avant de
continuer. Pour plus d’informations sur les certificats à utiliser, consultez Obtenir
des certificats pour SGH.

3. Exécutez Initialize-HgsServer dans une fenêtre PowerShell avec élévation de

privilèges sur le premier nœud SGH. La syntaxe de cette applet de commande
prend en charge de nombreuses entrées différentes, mais les 2 appels les plus
courants sont les suivants :

Si vous utilisez des fichiers PFX pour vos certificats de signature et de

chiffrement, exécutez les commandes suivantes :

PowerShell

$signingCertPass = Read-Host -AsSecureString -Prompt "Signing

certificate password"
$encryptionCertPass = Read-Host -AsSecureString -Prompt
"Encryption certificate password"

Initialize-HgsServer -HgsServiceName 'MyHgsDNN' -

SigningCertificatePath '.\[Link]' -
SigningCertificatePassword $signingCertPass -
EncryptionCertificatePath '.\[Link]' -
EncryptionCertificatePassword $encryptionCertPass -TrustHostkey
 Si vous utilisez des certificats non exportables installés dans le magasin de
certificats local, exécutez la commande suivante. Si vous ne connaissez pas
les empreintes de vos certificats, vous pouvez lister les certificats disponibles
en exécutant Get-ChildItem Cert:\LocalMachine\My .

PowerShell

Initialize-HgsServer -HgsServiceName 'MyHgsDNN' -

SigningCertificateThumbprint '1A2B3C4D5E6F...' -
EncryptionCertificateThumbprint '0F9E8D7C6B5A...' --TrustHostKey

4. Si vous avez fourni des certificats à SGH en utilisant des empreintes, vous êtes
invité à accorder à SGH un accès en lecture sur la clé privée de ces certificats. Sur
un serveur avec l’Expérience utilisateur installée, effectuez les étapes suivantes :
a. Ouvrez le gestionnaire de certificats de l’ordinateur local ([Link])
b. Recherchez le ou les certificats > cliquez avec le bouton droit > toutes les
tâches > gérer les clés privées
c. Cliquez sur Ajouter
d. Dans la fenêtre du sélecteur d’objets, cliquez sur Types d’objets et activez
Comptes de service
e. Entrez le nom du compte de service mentionné dans le texte d’avertissement de
Initialize-HgsServer

f. Vérifiez que le gMSA a l’accès « Lire » sur la clé privée.

Sur Server Core, vous devez télécharger un module PowerShell pour vous aider à
définir les autorisations de clé privée.

a. Exécutez Install-Module GuardedFabricTools sur le serveur SGH s’il a une

connectivité Internet, ou exécutez Save-Module GuardedFabricTools sur un autre
ordinateur et copiez le module sur le serveur SGH.

b. Exécutez Import-Module GuardedFabricTools . Cela ajoute des propriétés

supplémentaires aux objets de certificat trouvés dans PowerShell.

c. Recherchez votre empreinte de certificat dans PowerShell avec Get-ChildItem

Cert:\LocalMachine\My

d. Mettez à jour la liste ACL, en remplaçant l’empreinte par la vôtre, et le compte

gMSA dans le code ci-dessous par le compte listé dans le texte d’avertissement
de Initialize-HgsServer .

PowerShell
 $certificate = Get-Item "Cert:\LocalMachine\1A2B3C..."
$[Link] = $[Link] | Add-AccessRule "HgsSvc_1A2B3C"
Read Allow

Si vous utilisez des certificats HSM ou des certificats stockés dans un fournisseur
de stockage de clés tiers, ces étapes ne s’appliquent peut-être pas. Consultez la
documentation de votre fournisseur de stockage de clés pour savoir comment
gérer les autorisations sur votre clé privée. Dans certains cas, il n’y a pas
d’autorisation ou une autorisation est fournie à tout l’ordinateur quand le certificat
est installé.

5. Et voilà ! Dans un environnement de production, vous devez continuer à ajouter

des nœuds SGH supplémentaires à votre cluster.

Étape suivante
Créer une clé d’hôte
Initialiser le cluster SGH à l’aide du
mode clé dans une forêt bastion
existante
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019

« Installer SGH dans une nouvelle forêt Créer une clé hôte »

services de domaine Active Directory seront installés sur l’ordinateur, mais ne doivent
pas être configurés.

Recherchez vos certificats gardiens SGH. Vous avez besoin d’un certificat de signature et
d’un certificat de chiffrement pour initialiser le cluster SGH. Le moyen le plus simple de
fournir des certificats à SGH est de créer un fichier PFX protégé par mot de passe pour
chaque certificat qui contient les clés publiques et privées. Si vous utilisez des clés HSM
ou d’autres certificats non exportables, vérifiez que le certificat est installé dans le
magasin de certificats de l’ordinateur local avant de continuer. Pour plus d’informations
sur les certificats à utiliser, consultez Obtenir des certificats pour SGH.

Avant de continuer, vérifiez que vous avez préparé vos objets de cluster pour le service
Guardian hôte et accordé à l’utilisateur connecté un contrôle total sur les objets VCO et
CNO dans Active Directory. Le nom de l’objet d’ordinateur virtuel doit être passé au
paramètre -HgsServiceName et le nom du cluster au paramètre -ClusterName .

 Conseil

Vérifiez bien vos contrôleurs de domaine AD pour vous assurer que vos objets de
cluster ont été répliqués sur tous les contrôleurs de domaine avant de continuer.

Si vous utilisez des certificats PFX, exécutez les commandes suivantes sur le serveur SGH
:

PowerShell

$signingCertPass = Read-Host -AsSecureString -Prompt "Signing certificate

password"
$encryptionCertPass = Read-Host -AsSecureString -Prompt "Encryption
certificate password"
 Install-ADServiceAccount -Identity 'HGSgMSA'

Initialize-HgsServer -UseExistingDomain -ServiceAccount 'HGSgMSA' -

JeaReviewersGroup 'HgsJeaReviewers' -JeaAdministratorsGroup 'HgsJeaAdmins' -
HgsServiceName 'HgsService' -ClusterName 'HgsCluster' -
SigningCertificatePath '.\[Link]' -SigningCertificatePassword
$signPass -EncryptionCertificatePath '.\[Link]' -
EncryptionCertificatePassword $encryptionCertPass -TrustHostKey

Si vous utilisez des certificats installés sur l’ordinateur local (tels que des certificats HSM
et des certificats non exportables), utilisez les paramètres -
SigningCertificateThumbprint et -EncryptionCertificateThumbprint à la place.
Initialiser SGH (Service Guardian hôte) à
l’aide d’une attestation approuvée par
l’administrateur
Article • 11/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

） Important

L’attestation approuvée par l’administrateur (mode AD) est déconseillée à compter

de Windows Server 2019. Pour les environnements où l’attestation TPM n’est pas
possible, configurez l’attestation de clé d’hôte. L’attestation de clé d’hôte fournit
une assurance similaire au mode AD et est plus simple à configurer.

Ces étapes varient selon que vous initialisez SGH dans une nouvelle forêt ou une forêt
bastion existante :

1. Initialiser le cluster SGH dans une nouvelle forêt (par défaut)

-Ou-

Initialiser le cluster SGH dans une forêt bastion existante

2. Configurer le transfert DNS dans le domaine de structure

3. Configurer le transfert DNS et une approbation à sens unique dans le domaine

SGH
Initialiser le cluster SGH avec le mode
AD dans une nouvelle forêt dédiée (par
défaut)
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

） Important

L’attestation approuvée par Administration (mode AD) est déconseillée à compter

de Windows Server 2019. Pour les environnements où l’attestation TPM n’est pas
possible, configurez l’attestation de clé d’hôte. L’attestation de clé d’hôte fournit
une assurance similaire au mode AD et est plus simple à configurer.

1. Les clients peuvent facilement contacter n’importe quel nœud SGH en utilisant le
nom de réseau distribué (DNN) du clustering de basculement. Vous devez choisir
un DNN. Ce nom est inscrit dans le service DNS SGH. Par exemple, si vous avez
3 nœuds SGH avec les noms d’hôte HGS01, HGS02 et HGS03, vous pouvez choisir
« hgs » ou « HgsCluster » pour le DNN.

2. Recherchez vos certificats gardiens SGH. Vous avez besoin d’un certificat de
signature et d’un certificat de chiffrement pour initialiser le cluster SGH. Le moyen
le plus simple de fournir des certificats à SGH est de créer un fichier PFX protégé
par mot de passe pour chaque certificat qui contient les clés publiques et privées.
Si vous utilisez des clés HSM ou d’autres certificats non exportables, vérifiez que le
certificat est installé dans le magasin de certificats de l’ordinateur local avant de
continuer. Pour plus d’informations sur les certificats à utiliser, consultez Obtenir
des certificats pour SGH.

3. Exécutez Initialize-HgsServer dans une fenêtre PowerShell avec élévation de

privilèges sur le premier nœud SGH. La syntaxe de cette applet de commande
prend en charge de nombreuses entrées différentes, mais les 2 appels les plus
courants sont les suivants :

Si vous utilisez des fichiers PFX pour vos certificats de signature et de

chiffrement, exécutez les commandes suivantes :

PowerShell
 $signingCertPass = Read-Host -AsSecureString -Prompt "Signing
certificate password"
$encryptionCertPass = Read-Host -AsSecureString -Prompt
"Encryption certificate password"

Initialize-HgsServer -HgsServiceName 'MyHgsDNN' -

SigningCertificatePath '.\[Link]' -
SigningCertificatePassword $signingCertPass -
EncryptionCertificatePath '.\[Link]' -
EncryptionCertificatePassword $encryptionCertPass -
TrustActiveDirectory

Si vous utilisez des certificats non exportables installés dans le magasin de

certificats local, exécutez la commande suivante. Si vous ne connaissez pas
les empreintes de vos certificats, vous pouvez lister les certificats disponibles
en exécutant Get-ChildItem Cert:\LocalMachine\My .

PowerShell

Initialize-HgsServer -HgsServiceName 'MyHgsDNN' -

SigningCertificateThumbprint '1A2B3C4D5E6F...' -
EncryptionCertificateThumbprint '0F9E8D7C6B5A...' --
TrustActiveDirectory

4. Si vous avez fourni des certificats à SGH en utilisant des empreintes, vous êtes
invité à accorder à SGH un accès en lecture sur la clé privée de ces certificats. Sur
un serveur avec l’Expérience utilisateur installée, effectuez les étapes suivantes :
a. Ouvrez le gestionnaire de certificats de l’ordinateur local ([Link])
b. Recherchez le ou les certificats > cliquez avec le bouton droit > toutes les
tâches > gérer les clés privées
c. Cliquez sur Ajouter
d. Dans la fenêtre du sélecteur d’objets, cliquez sur Types d’objets et activez
Comptes de service
e. Entrez le nom du compte de service mentionné dans le texte d’avertissement de
Initialize-HgsServer

f. Vérifiez que le gMSA a l’accès « Lire » sur la clé privée.

Sur Server Core, vous devez télécharger un module PowerShell pour vous aider à
définir les autorisations de clé privée.

a. Exécutez Install-Module GuardedFabricTools sur le serveur SGH s’il a une

connectivité Internet, ou exécutez Save-Module GuardedFabricTools sur un autre
ordinateur et copiez le module sur le serveur SGH.
 b. Exécutez Import-Module GuardedFabricTools . Cela ajoute des propriétés
supplémentaires aux objets de certificat trouvés dans PowerShell.

c. Recherchez votre empreinte de certificat dans PowerShell avec Get-ChildItem

Cert:\LocalMachine\My

d. Mettez à jour la liste ACL, en remplaçant l’empreinte par la vôtre, et le compte

gMSA dans le code ci-dessous par le compte listé dans le texte d’avertissement
de Initialize-HgsServer .

PowerShell

$certificate = Get-Item "Cert:\LocalMachine\1A2B3C..."

$[Link] = $[Link] | Add-AccessRule "HgsSvc_1A2B3C"
Read Allow

Si vous utilisez des certificats HSM ou des certificats stockés dans un fournisseur
de stockage de clés tiers, ces étapes ne s’appliquent peut-être pas. Consultez la
documentation de votre fournisseur de stockage de clés pour savoir comment
gérer les autorisations sur votre clé privée. Dans certains cas, il n’y a pas
d’autorisation ou une autorisation est fournie à tout l’ordinateur quand le certificat
est installé.

5. Et voilà ! Dans un environnement de production, vous devez continuer à ajouter

des nœuds SGH supplémentaires à votre cluster.

Étape suivante
Configurer une structure DNS
Initialiser le cluster HGS à l’aide du
mode AD dans une forêt bastion
existante
Article • 28/08/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

） Important

L’attestation approuvée par l’administrateur (mode AD) est déconseillée à compter

de Windows Server 2019. Pour les environnements où l’attestation TPM n’est pas
possible, configurez l’attestation de clé d’hôte. L’attestation de clé d’hôte fournit
une assurance similaire au mode AD et est plus simple à configurer.

services de domaine Active Directory seront installés sur l’ordinateur, mais ne doivent
pas être configurés.

Recherchez vos certificats gardiens SGH. Vous avez besoin d’un certificat de signature et
d’un certificat de chiffrement pour initialiser le cluster SGH. Le moyen le plus simple de
fournir des certificats à SGH est de créer un fichier PFX protégé par mot de passe pour
chaque certificat qui contient les clés publiques et privées. Si vous utilisez des clés HSM
ou d’autres certificats non exportables, vérifiez que le certificat est installé dans le
magasin de certificats de l’ordinateur local avant de continuer. Pour plus d’informations
sur les certificats à utiliser, consultez Obtenir des certificats pour SGH.

Avant de continuer, vérifiez que vous avez préparé vos objets de cluster pour le service
Guardian hôte et accordé à l’utilisateur connecté un contrôle total sur les objets VCO et
CNO dans Active Directory. Le nom de l’objet d’ordinateur virtuel doit être passé au
paramètre -HgsServiceName et le nom du cluster au paramètre -ClusterName .

 Conseil

Vérifiez bien vos contrôleurs de domaine AD pour vous assurer que vos objets de
cluster ont été répliqués sur tous les contrôleurs de domaine avant de continuer.

Si vous utilisez des certificats PFX, exécutez les commandes suivantes sur le serveur SGH
:
 PowerShell

$signingCertPass = Read-Host -AsSecureString -Prompt "Signing certificate

password"
$encryptionCertPass = Read-Host -AsSecureString -Prompt "Encryption
certificate password"

Install-ADServiceAccount -Identity 'HGSgMSA'

Initialize-HgsServer -UseExistingDomain -ServiceAccount 'HGSgMSA' -

JeaReviewersGroup 'HgsJeaReviewers' -JeaAdministratorsGroup 'HgsJeaAdmins' -
HgsServiceName 'HgsService' -ClusterName 'HgsCluster' -
SigningCertificatePath '.\[Link]' -SigningCertificatePassword
$signPass -EncryptionCertificatePath '.\[Link]' -
EncryptionCertificatePassword $encryptionCertPass -TrustActiveDirectory

Si vous utilisez des certificats installés sur l’ordinateur local (tels que des certificats HSM
et des certificats non exportables), utilisez les paramètres -
SigningCertificateThumbprint et -EncryptionCertificateThumbprint à la place.

Étape suivante
Configurer une structure DNS
Configurer le DNS d’infrastructure pour
les hôtes Service Guardian (AD)
Article • 28/08/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

） Important

Le mode AD est déconseillé à compter de Windows Server 2019. Pour les

environnements où l’attestation TPM n’est pas possible, configurez l’attestation de
clé d’hôte. L’attestation de clé d’hôte fournit une assurance similaire au mode AD
et est plus simple à configurer.

Un administrateur d’infrastructure doit configurer les prises DNS de l’infrastructure pour

permettre aux hôtes Service Guardian de résoudre le cluster SGH. Le cluster SGH doit
déjà être configuré par l’administrateur SGH.

Il existe de nombreuses façons de configurer la résolution de noms pour le domaine

d’infrastructure. Une méthode simple consiste à configurer une zone de redirecteur
conditionnel dans DNS pour l’infrastructure. Pour configurer cette zone, exécutez les
commandes suivantes dans une console Windows PowerShell avec élévation de
privilèges sur un serveur DNS d’infrastructure. Remplacez les noms et adresses dans la
syntaxe Windows PowerShell ci-dessous en fonction de votre environnement. Ajoutez
des serveurs maîtres pour les nœuds SGH supplémentaires.

Add-DnsServerConditionalForwarderZone -Name '[Link]' -

ReplicationScope "Forest" -MasterServers <IP addresses of HGS server>

Étape suivante
Configurer SGH DNS et une approbation à sens unique
Configurer le transfert DNS dans le
domaine SGH et une approbation
unidirectionnelle avec le domaine
d’infrastructure
Article • 11/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

） Important

Le mode AD est déconseillé à compter de Windows Server 2019. Pour les

environnements où l’attestation TPM n’est pas possible, configurez l’attestation de
clé d’hôte. L’attestation de clé d’hôte fournit une assurance similaire au mode AD
et est plus simple à configurer.

Utilisez les étapes suivantes pour configurer le transfert DNS et établir une approbation
unidirectionnelle avec le domaine d’infrastructure. Ces étapes permettent au SGH de
localiser les contrôleurs de domaine d’infrastructure et de valider l’appartenance au
groupe des hôtes Hyper-V.

1. Exécutez la commande suivante dans une session PowerShell avec élévation de

privilèges pour configurer le transfert DNS. Remplacez [Link] par le nom du
domaine d’infrastructure et tapez les adresses IP des serveurs DNS dans le
domaine d’infrastructure. Pour une disponibilité plus élevée, pointez sur plusieurs
serveurs DNS.

PowerShell

Add-DnsServerConditionalForwarderZone -Name "[Link]" -

ReplicationScope "Forest" -MasterServers <DNSserverAddress1>,
<DNSserverAddress2>

2. Pour créer une approbation de forêt unidirectionnelle, exécutez la commande

suivante dans une invite de commandes avec élévation de privilèges :

Remplacez [Link] par le nom du domaine SGH et [Link] par le

nom du domaine d’infrastructure. Indiquez le mot de passe d’un administrateur du
domaine d’infrastructure.
 PowerShell

netdom trust [Link] /domain:[Link]

/userD:[Link]\Administrator /passwordD:<password> /add

Étape suivante
Configurer HTTPS
Configurer SGH pour les
communications HTTPS
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Par défaut, quand vous initialisez le serveur SGH, il configure les sites web IIS pour les
communications HTTP uniquement. Tout le contenu sensible transmis depuis et vers
SGH est toujours chiffré à l’aide du chiffrement au niveau du message. Toutefois, si vous
souhaitez un niveau de sécurité plus élevé, vous pouvez également activer HTTPS en
configurant SGH avec un certificat SSL.

Commencez par obtenir un certificat SSL pour SGH auprès de votre autorité de
certification. Chaque machine hôte doit approuver le certificat SSL. Il est donc
recommandé d’émettre le certificat SSL à partir de l’infrastructure à clé publique de
votre entreprise ou d’une autorité de certification tierce. Tout certificat SSL pris en
charge par IIS est pris en charge par SGH. Toutefois, le nom de sujet qui figure sur le
certificat doit correspondre au nom complet du service SGH (nom de réseau distribué
du cluster). Par exemple, si le domaine SGH est « [Link] » et si le nom de votre
service SGH est « hgs », votre certificat SSL doit être émis pour « [Link] ».
Vous pouvez ajouter des noms DNS supplémentaires au champ d’autre nom de sujet du
certificat, si nécessaire.

Une fois que vous disposez du certificat SSL, ouvrez une session PowerShell avec
élévation de privilèges, puis indiquez le chemin du certificat quand vous exécutez Set-
HgsServer :

PowerShell

$sslPassword = Read-Host -AsSecureString -Prompt "SSL Certificate Password"

Set-HgsServer -Http -Https -HttpsCertificatePath
'C:\temp\[Link]' -HttpsCertificatePassword $sslPassword

Sinon, si vous avez déjà installé le certificat dans le magasin de certificats local, vous
pouvez le référencer en fonction de l’empreinte numérique :

PowerShell

Set-HgsServer -Http -Https -HttpsCertificateThumbprint 'A1B2C3D4E5F6...'

） Important

La configuration de SGH avec un certificat SSL n’entraîne pas la désactivation du

point de terminaison HTTP. Si vous souhaitez autoriser uniquement l’utilisation du
point de terminaison HTTPS, configurez le Pare-feu Windows pour bloquer les
connexions entrantes sur le port 80. Ne modifiez pas les liaisons IIS des sites web
SGH pour supprimer le point de terminaison HTTP. Cette opération n’est pas prise
en charge.
Configurer des nœuds SGH
supplémentaires
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Dans les environnements de production, SGH doit être configuré dans un cluster à
haute disponibilité pour s’assurer que les machines virtuelles dotées d’une protection
maximale peuvent être mises sous tension, même en cas de défaillance d’un nœud SGH.
Pour les environnements de test, les nœuds SGH secondaires ne sont pas nécessaires.

Utilisez l’une de ces méthodes pour ajouter des nœuds SGH, en fonction de ce qui
convient le mieux à votre environnement.

Environnement Option 1 : Option 2 :

Nouvelle forêt SGH Utilisation de fichiers Utilisation d’empreintes numériques de

PFX certificat

Forêt bastion Utilisation de fichiers Utilisation d’empreintes numériques de

existante PFX certificat

Prérequis
Vérifiez que chaque nœud supplémentaire :

A la même configuration matérielle et logicielle que le nœud principal

Est connecté au même réseau que les autres serveurs SGH
Peut résoudre les autres serveurs SGH en fonction de leurs noms DNS

Forêt SGH dédiée avec des certificats PFX

1. Promouvoir le nœud SGH en contrôleur de domaine
2. Initialiser le serveur SGH

Promouvoir le nœud SGH en contrôleur de domaine

1. Exécutez Install-HgsServer pour joindre le domaine, et promouvoir le nœud en
contrôleur de domaine.
 PowerShell

$adSafeModePassword = ConvertTo-SecureString -AsPlainText '<password>'

-Force

$cred = Get-Credential 'relecloud\Administrator'

Install-HgsServer -HgsDomainName '[Link]' -HgsDomainCredential

$cred -SafeModeAdministratorPassword $adSafeModePassword -Restart

2. Une fois que le serveur a redémarré, connectez-vous avec un compte

Administrateur de domaine.

Initialiser le serveur SGH

Exécutez la commande suivante pour rejoindre le cluster SGH existant.

PowerShell

Initialize-HgsServer -HgsServerIPAddress <IP address of first HGS Server>

Forêt SGH dédiée avec empreintes numériques

de certificat
1. Promouvoir le nœud SGH en contrôleur de domaine
2. Initialiser le serveur SGH
3. Installer les clés privées des certificats

Promouvoir le nœud SGH en contrôleur de domaine

1. Exécutez Install-HgsServer pour joindre le domaine, et promouvoir le nœud en
contrôleur de domaine.

PowerShell

$adSafeModePassword = ConvertTo-SecureString -AsPlainText '<password>'

-Force

$cred = Get-Credential 'relecloud\Administrator'

Install-HgsServer -HgsDomainName '[Link]' -HgsDomainCredential

$cred -SafeModeAdministratorPassword $adSafeModePassword -Restart
 2. Une fois que le serveur a redémarré, connectez-vous avec un compte
Administrateur de domaine.

Initialiser le serveur SGH

Exécutez la commande suivante pour rejoindre le cluster SGH existant.

PowerShell

Initialize-HgsServer -HgsServerIPAddress <IP address of first HGS Server>

Installer les clés privées des certificats

Si vous n’avez pas fourni de fichier PFX pour les certificats de chiffrement ou de
signature sur le premier serveur SGH, seule la clé publique est répliquée sur ce serveur.
Vous devez installer la clé privée en important un fichier PFX contenant la clé privée
dans le magasin de certificats local ou, dans le cas des clés basées sur un module HSM,
en configurant le fournisseur de stockage de clés et en l’associant à vos certificats
conformément aux instructions du fabricant de votre module HSM.

Forêt bastion existante avec des certificats PFX

1. Joindre le nœud au domaine existant
2. Octroyer à la machine les droits nécessaires pour récupérer le mot de passe gMSA
et exécuter Install-ADServiceAccount
3. Initialiser le serveur SGH

Joindre le nœud au domaine existant

1. Vérifiez qu’au moins une carte d’interface réseau sur le nœud est configurée pour
utiliser le serveur DNS sur votre premier serveur SGH.
2. Joignez le nouveau nœud SGH au même domaine que votre premier nœud SGH.

Octroyer à la machine les droits nécessaires pour

récupérer le mot de passe gMSA et exécuter Install-
ADServiceAccount
1. Demandez à un administrateur des services d’annuaire d’ajouter le compte
d’ordinateur de votre nouveau nœud au groupe de sécurité contenant tous les
 serveurs SGH autorisés à permettre à ces serveurs d’utiliser le compte gMSA SGH.

2. Redémarrez le nouveau nœud pour obtenir un nouveau ticket Kerberos qui inclut
l’appartenance de l’ordinateur à ce groupe de sécurité. Une fois le redémarrage
effectué, connectez-vous avec une identité de domaine appartenant au groupe
Administrateurs local de l’ordinateur.

3. Installez le compte de service administré par le groupe SGH sur le nœud.

PowerShell

Install-ADServiceAccount -Identity <HGSgMSAAccount>

Initialiser le serveur SGH

Exécutez la commande suivante pour rejoindre le cluster SGH existant.

PowerShell

Initialize-HgsServer -HgsServerIPAddress <IP address of first HGS Server>

Forêt bastion existante avec des empreintes

numériques de certificat
1. Joindre le nœud au domaine existant
2. Octroyer à la machine les droits nécessaires pour récupérer le mot de passe gMSA
et exécuter Install-ADServiceAccount
3. Initialiser le serveur SGH
4. Installer les clés privées des certificats

Joindre le nœud au domaine existant

1. Vérifiez qu’au moins une carte d’interface réseau sur le nœud est configurée pour
utiliser le serveur DNS sur votre premier serveur SGH.
2. Joignez le nouveau nœud SGH au même domaine que votre premier nœud SGH.

Octroyer à la machine les droits nécessaires pour

récupérer le mot de passe gMSA et exécuter Install-
ADServiceAccount
 1. Demandez à un administrateur des services d’annuaire d’ajouter le compte
d’ordinateur de votre nouveau nœud au groupe de sécurité contenant tous les
serveurs SGH autorisés à permettre à ces serveurs d’utiliser le compte gMSA SGH.

2. Redémarrez le nouveau nœud pour obtenir un nouveau ticket Kerberos qui inclut
l’appartenance de l’ordinateur à ce groupe de sécurité. Une fois le redémarrage
effectué, connectez-vous avec une identité de domaine appartenant au groupe
Administrateurs local de l’ordinateur.

3. Installez le compte de service administré par le groupe SGH sur le nœud.

PowerShell

Install-ADServiceAccount -Identity <HGSgMSAAccount>

Initialiser le serveur SGH

Exécutez la commande suivante pour rejoindre le cluster SGH existant.

PowerShell

Initialize-HgsServer -HgsServerIPAddress <IP address of first HGS Server>

La réplication des certificats de chiffrement et de signature du premier serveur SGH sur

ce nœud peut prendre jusqu’à 10 minutes.

Installer les clés privées des certificats

Si vous n’avez pas fourni de fichier PFX pour les certificats de chiffrement ou de
signature sur le premier serveur SGH, seule la clé publique est répliquée sur ce serveur.
Vous devez installer la clé privée en important un fichier PFX contenant la clé privée
dans le magasin de certificats local ou, dans le cas des clés basées sur un module HSM,
en configurant le fournisseur de stockage de clés et en l’associant à vos certificats
conformément aux instructions du fabricant de votre module HSM.

Configurer SGH pour les communications

HTTPS
Si vous souhaitez sécuriser des points de terminaison SGH avec un certificat SSL, vous
devez configurer le certificat SSL sur ce nœud ainsi que sur tous les autres nœuds du
cluster SGH. Les certificats SSL ne sont pas répliqués par SGH et n’ont pas besoin
d’utiliser les mêmes clés pour chaque nœud (autrement dit, vous pouvez avoir différents
certificats SSL pour chaque nœud).

Quand vous demandez un certificat SSL, vérifiez que le nom de domaine complet du
cluster (comme le montre la sortie de Get-HgsServer ) correspond au nom commun de
sujet du certificat, ou qu’il est inclus en tant qu’autre nom DNS de sujet. Une fois que
vous avez obtenu un certificat auprès de votre autorité de certification, vous pouvez
configurer SGH pour l’utiliser avec Set-HgsServer.

PowerShell

$sslPassword = Read-Host -AsSecureString -Prompt "SSL Certificate Password"

Set-HgsServer -Http -Https -HttpsCertificatePath
'C:\temp\[Link]' -HttpsCertificatePassword $sslPassword

Si vous avez déjà installé le certificat dans le magasin de certificats local et si vous
souhaitez le référencer en fonction de l’empreinte numérique, exécutez la commande
suivante à la place :

PowerShell

Set-HgsServer -Http -Https -HttpsCertificateThumbprint 'A1B2C3D4E5F6...'

SGH expose toujours les ports HTTP et HTTPS pour la communication. La suppression
de la liaison HTTP dans IIS n’est pas prise en charge. Toutefois, vous pouvez utiliser le
Pare-feu Windows ou d’autres technologies de pare-feu réseau pour bloquer les
communications sur le port 80.

Désactiver un nœud SGH

Pour désactiver un nœud SGH :

1. Effacez la configuration SGH.

Cela permet de supprimer le nœud du cluster, et de désinstaller les services

d’attestation et de protection de clé. S’il s’agit du dernier nœud du cluster, vous
devez utiliser l’option -Force pour indiquer que vous souhaitez supprimer le
dernier nœud et détruire le cluster dans Active Directory.

Si SGH est déployé dans une forêt bastion (par défaut), il s’agit de la seule étape.
Vous pouvez éventuellement annuler la jonction de la machine au domaine, et
supprimer le compte gMSA d’Active Directory.
2. Si SGH a créé son propre domaine, vous devez également désinstaller SGH pour
annuler la jonction au domaine et rétrograder le contrôleur de domaine.
Déployer des hôtes Service Guardian
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Les rubriques de cette section décrivent les étapes qu’un administrateur d’infrastructure
doit effectuer pour configurer les hôtes Hyper-V afin qu’ils fonctionnent avec SGH
(Service Guardian hôte). Pour pouvoir démarrer ces étapes, vous devez configurer au
moins un nœud du cluster SGH.

Pour l’attestation approuvée par un TPM :

1. Configurer le DNS de l’infrastructure : indique comment configurer un redirecteur

DNS du domaine de l’infrastructure vers le domaine SGH.
2. Capturer les informations nécessaires à SGH : indique comment capturer les
identificateurs TPM (également appelés identificateurs de plateforme), créer une
stratégie d’intégrité du code et créer une base de référence du TPM. Vous devez
ensuite fournir ces informations à l’administrateur SGH pour qu’il configure
l’attestation.
3. Confirmer que les hôtes Service Guardian peuvent attester

Pour l’attestation de clé d’hôte :

1. Créer une clé d’hôte : indique comment configurer un redirecteur DNS du domaine
de l’infrastructure vers le domaine SGH.
2. Ajouter la clé d’hôte au service d’attestation : indique comment configurer un
groupe de sécurité Active Directory dans le domaine de l’infrastructure, ajouter des
hôtes Service Guardian en tant que membres de ce groupe, et fournir cet
identificateur de groupe à l’administrateur SGH.
3. Confirmer que les hôtes Service Guardian peuvent attester

Pour l’attestation approuvée par un administrateur :

1. Configurer le DNS de l’infrastructure : indique comment configurer un redirecteur

DNS du domaine de l’infrastructure vers le domaine SGH.
2. Créer un groupe de sécurité : indique comment configurer un groupe de sécurité
Active Directory dans le domaine de l’infrastructure, ajouter des hôtes Service
Guardian en tant que membres de ce groupe, et fournir cet identificateur de
groupe à l’administrateur SGH.
3. Confirmer que les hôtes Service Guardian peuvent attester
Références supplémentaires
Tâches de déploiement pour les infrastructures protégées et les machines virtuelles
dotées d’une protection maximale
Conditions préalables pour les hôtes
Service Guardian
Article • 17/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Passez en revue les conditions préalables de l’hôte pour le mode d’attestation que vous
avez choisi, puis cliquez sur l’étape suivante pour ajouter des hôtes Service Guardian.

Attestation approuvée par le module de

plateforme sécurisée (TPM)
Les hôtes Service Guardian utilisant le mode TPM doivent respecter les conditions
préalables suivantes :

Matériel : un hôte est requis pour le déploiement initial. Pour tester la migration
dynamique Hyper-V pour les machines virtuelles dotées d’une protection
maximale, vous devez disposer d’au moins deux hôtes.

Les hôtes doivent avoir :

IOMMU et traduction d’adresse de second niveau (SLAT, Second Level Address
Translation)
TPM 2.0
UEFI 2.3.1 ou version ultérieure
Configuration pour démarrer en mode UEFI (pas BIOS ou en mode « hérité »)
Démarrage sécurisé activé

Système d’exploitation : Windows Server 2016 édition Datacenter ou version

ultérieure

） Important

Veillez à installer la dernière mise à jour cumulative .

Rôle et fonctionnalités : rôle Hyper-V et fonctionnalité de prise en charge Hyper-V

du service Guardian hôte. La fonctionnalité de prise en charge Hyper-V du service
Guardian hôte est uniquement disponible sur les éditions Datacenter de
Windows Server.
 ２ Avertissement

La fonctionnalité de prise en charge Hyper-V du service Guardian hôte permet une

protection de l’intégrité du code basée sur la virtualisation qui peut être
incompatible avec certains appareils. Nous vous recommandons vivement de tester
cette configuration dans votre laboratoire avant d’activer cette fonctionnalité. Dans
le cas contraire, cela risque d’entraîner des échecs inattendus pouvant aller jusqu'à
la perte de données ou un écran bleu d’erreur (également appelé erreur d’arrêt).
Pour plus d’informations, consultez Matériel compatible avec la protection de
l’intégrité du code basée sur la virtualisation Windows Server.

Étape suivante :

Capturer les informations du module de plateforme sécurisée (TPM)

Attestation de clé d’hôte

Les hôtes Service Guardian utilisant l’attestation de clé d’hôte doivent respecter les
conditions préalables suivantes :

Matériel : tout serveur capable d’exécuter Hyper-V à partir de

Windows Server 2019
Système d’exploitation : Windows Server 2019 édition Datacenter
Rôle et fonctionnalités : rôle Hyper-V et fonctionnalité de prise en charge Hyper-V
du service Guardian hôte

L’hôte peut être joint à un domaine ou à un groupe de travail.

Pour l’attestation de clé hôte, le service Guardian hôte (SGH) doit exécuter
Windows Server 2019 et fonctionner avec l’attestation v2. Pour plus d’informations,
consultez les prérequis SGH.

Étape suivante :

Créer une paire de clés

Attestation approuvée par l’administrateur

） Important
 L’attestation approuvée par l’administrateur (mode AD) est déconseillée à compter
de Windows Server 2019. Pour les environnements où l’attestation TPM n’est pas
possible, configurez l’attestation de clé d’hôte. L’attestation de clé d’hôte fournit
une assurance similaire au mode AD et est plus simple à configurer.

Les hôtes Hyper-V doivent remplir les conditions préalables suivantes pour le mode AD :

Matériel : tout serveur capable d’exécuter Hyper-V à partir de

Windows Server 2016. Un hôte est requis pour le déploiement initial. Pour tester la
migration dynamique Hyper-V pour les machines virtuelles dotées d’une
protection maximale, vous avez besoin d’au moins deux hôtes.

Système d’exploitation : Windows Server 2016 édition Datacenter

） Important

Installez la dernière mise à jour cumulative .

Rôle et fonctionnalités : rôle Hyper-V et fonctionnalité de prise en charge Hyper-V

du service Guardian hôte, qui est uniquement disponible dans
Windows Server 2016 édition Datacenter.

２ Avertissement

La fonctionnalité de prise en charge Hyper-V du service Guardian hôte permet une

protection de l’intégrité du code basée sur la virtualisation qui peut être
incompatible avec certains appareils. Nous vous recommandons vivement de tester
cette configuration dans votre laboratoire avant d’activer cette fonctionnalité. Dans
le cas contraire, cela risque d’entraîner des échecs inattendus pouvant aller jusqu'à
la perte de données ou un écran bleu d’erreur (également appelé erreur d’arrêt).
Pour plus d’informations, consultez Matériel compatible avec la protection de
l’intégrité du code basée sur la virtualisation Windows Server 2016.

Étape suivante :

Placer les hôtes Service Guardian dans un groupe de sécurité

Autoriser des hôtes protégés à l’aide
d’une attestation TPM
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Le mode TPM utilise un identificateur TPM (également appelé identificateur de

plateforme ou clé d’approbation [EKpub]) pour commencer à déterminer si un hôte
particulier est autorisé comme « protégé ». Ce mode d’attestation utilise le démarrage
sécurisé et les mesures d’intégrité du code pour garantir qu’un hôte Hyper-V donné est
dans un état intègre et exécute uniquement du code approuvé. Pour que l’attestation
comprenne ce qui est intègre et non intègre, vous devez capturer les artefacts suivants :

1. Identificateur TPM (EKpub)

Ces informations sont propres à chaque hôte Hyper-V

2. Base de référence de TPM (mesures de démarrage)

Cela s’applique à tous les hôtes Hyper-V qui s’exécutent sur la même classe
de matériel

3. Stratégie d’intégrité du code (liste d’autorisation des fichiers binaires autorisés)

Cela s’applique à tous les hôtes Hyper-V qui partagent du matériel et des
logiciels communs

Nous vous recommandons de capturer la ligne de base et la stratégie CI à partir d’un «

hôte de référence » représentatif de chaque classe unique de configuration matérielle
Hyper-V au sein de votre centre de données. À compter de Windows Server version
1709, les exemples de stratégies CI sont inclus dans
C:\Windows\schemas\CodeIntegrity\ExamplePolicies.

Stratégies d’attestation avec version

Windows Server 2019 introduit une nouvelle méthode d’attestation, appelée attestation
v2, dans laquelle un certificat TPM doit être présent pour ajouter l’EKPub à SGH. La
méthode d’attestation v1 utilisée dans Windows Server 2016 vous a permis de
remplacer cette vérification de sécurité en spécifiant l’indicateur -Force lorsque vous
exécutez Add-HgsAttestationTpmHost ou d’autres applets de commande d’attestation
TPM pour capturer les artefacts. À compter de Windows Server 2019, l’attestation v2 est
utilisée par défaut et vous devez spécifier l’indicateur -PolicyVersion v1 lorsque vous
exécutez Add-HgsAttestationTpmHost si vous devez inscrire un TPM sans certificat.
L’indicateur -Force ne fonctionne pas avec l’attestation v2.

Un hôte ne peut attester que si tous les artefacts (EKPub + base de référence TPM +
stratégie CI) utilisent la même version de l’attestation. L’attestation V2 est d’abord
essayée, et en cas d’échec, l’attestation v1 est utilisée. Cela signifie que si vous devez
inscrire un identificateur TPM à l’aide de l’attestation v1, vous devez également spécifier
l’indicateur -PolicyVersion v1 pour utiliser l’attestation v1 lorsque vous capturez la base
de référence TPM et créez la stratégie CI. Si la base de référence TPM et la stratégie CI
ont été créées à l’aide de l’attestation v2, puis que vous devez ajouter un hôte protégé
sans certificat TPM, vous devez recréer chaque artefact avec l’indicateur -PolicyVersion
v1.

Capturer l’identificateur TPM (identificateur de

plateforme ou EKpub) pour chaque hôte
1. Dans le domaine de la structure, assurez-vous que le TPM sur chaque hôte est prêt
à être utilisé, c’est-à-dire que le module de plateforme sécurisée est initialisé et
que la propriété est obtenue. Vous pouvez vérifier l’état du TPM en ouvrant la
console de gestion de TPM ([Link]) ou en exécutant Get-Tpm dans une fenêtre
de Windows PowerShell avec élévation de privilèges. Si votre TPM n’est pas à l’état
Prêt , vous devez l’initialiser et définir sa propriété. Vous pouvez le faire dans la
console de gestion du TPM ou en exécutant Initialize-Tpm.

2. Sur chaque hôte protégé, exécutez la commande suivante dans une console
Windows PowerShell avec élévation de privilèges pour obtenir son EKpub. Pour
<HostName> , remplacez le nom d’hôte unique par un élément approprié pour

identifier cet hôte, il peut s’agir de son nom d’hôte ou du nom utilisé par un
service d’inventaire d’infrastructure (le cas échéant). À titre de commodité,
nommez le fichier de sortie en utilisant le nom de l’hôte.

PowerShell

(Get-PlatformIdentifier -Name '<HostName>').InnerXml | Out-file <Path>

<HostName>.xml -Encoding UTF8

3. Répétez les étapes précédentes pour chaque hôte qui deviendra un hôte protégé,
en veillant à donner à chaque fichier XML un nom unique.

4. Fournissez les fichiers XML obtenus à l’administrateur SGH.

 5. Dans le domaine SGH, ouvrez une console de Windows PowerShell avec élévation
de privilèges sur un serveur SGH et exécutez la commande suivante. Répétez la
commande pour chacun des fichiers XML.

PowerShell

Add-HgsAttestationTpmHost -Path <Path><Filename>.xml -Name <HostName>

７ Notes

Si vous rencontrez une erreur lors de l’ajout d’un identificateur TPM

concernant un certificat de clé d’approbation (EKCert) non approuvé, vérifiez
que les certificats racines TPM approuvés ont été ajoutés au nœud SGH. En
outre, certains fournisseurs TPM n’utilisent pas de certificats EK. Vous pouvez
vérifier si un EKCert est manquant en ouvrant le fichier XML dans un éditeur
comme le Bloc-notes et en recherchant un message d’erreur indiquant
qu’aucun certificat EKCert n’a été trouvé. Si c’est le cas et que vous êtes sûr
que le TPM de votre ordinateur est authentique, vous pouvez utiliser le
paramètre -Force pour ajouter l’identificateur de l’hôte à SGH. Dans Windows
Server 2019, vous devez également utiliser le paramètre -PolicyVersion v1
lors de l’utilisation de -Force . Cela crée une stratégie cohérente avec le
comportement Windows Server 2016 et vous oblige à utiliser -PolicyVersion
v1 lors de l’inscription de la stratégie CI et de la base de référence TPM.

Créer et appliquer une stratégie d'intégrité du

code
Une stratégie d’intégrité du code permet de s’assurer que seuls les exécutables que
vous approuvez pour s’exécuter sur un hôte sont autorisés à s’exécuter. Les programmes
malveillants et autres exécutables en dehors des exécutables approuvés ne peuvent pas
s’exécuter.

Chaque hôte protégé doit avoir une stratégie d’intégrité du code appliquée pour
exécuter des machines virtuelles protégées en mode TPM. Vous spécifiez les stratégies
d’intégrité du code exactes que vous approuvez en les ajoutant à SGH. Les stratégies
d’intégrité du code peuvent être configurées pour appliquer la stratégie, bloquer les
logiciels qui ne sont pas conformes à la stratégie ou simplement auditer (journaliser un
événement lorsque le logiciel non défini dans la stratégie est exécuté).
À compter de Windows Server version 1709, les stratégies d’intégrité de code
échantillon sont inclus dans C:\Windows\schemas\CodeIntegrity\ExamplePolicies. Deux
stratégies sont recommandées pour Windows Server :

AllowMicrosoft : autorise tous les fichiers signés par Microsoft. Cette stratégie est
recommandée pour les applications serveur telles que SQL ou Exchange, ou si le
serveur est surveillé par des agents publiés par Microsoft.
DefaultWindows_Enforced : autorise uniquement les fichiers fournis dans
Windows et n’autorise pas les autres applications publiées par Microsoft, telles
qu’Office. Cette stratégie est recommandée pour les serveurs qui exécutent
uniquement des rôles serveur intégrés et des fonctionnalités telles qu’Hyper-V.

Il est recommandé de créer d’abord la stratégie CI en mode audit (journalisation) pour

voir s’il manque quelque chose, puis d’appliquer la stratégie pour les charges de travail
de production de l’hôte.

Si vous utilisez l’applet de commande New-CIPolicy pour générer votre propre stratégie
d’intégrité du code, vous devez décider des niveaux de règle à utiliser. Nous
recommandons un niveau principal de Publisher avec secours vers Hash, qui permet de
mettre à jour la plupart des logiciels signés numériquement sans modifier la stratégie CI.
Les nouveaux logiciels écrits par le même éditeur peuvent également être installés sur le
serveur sans modifier la stratégie CI. Les exécutables qui ne sont pas signés
numériquement sont hachés. Mettre à jour à ces fichiers vous obligera à créer une
stratégie CI. Pour plus d’informations sur les niveaux de règle de stratégie CI
disponibles, consultez Déployer des stratégies d’intégrité du code : règles de stratégie et
règles de fichier et aide sur les applets de commande.

1. Sur l’hôte de référence, générez une nouvelle stratégie d’intégrité du code. Les
commandes suivantes créent une stratégie au niveau de l’Éditeurs avec secours au
hachage. Ensuite le fichier XML est converti au format de fichier binaire. Puis
Windows et SGH doivent appliquer et mesurer la stratégie CI, respectivement.

PowerShell

New-CIPolicy -Level Publisher -Fallback Hash -FilePath

'C:\temp\[Link]' -UserPEs

ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\[Link]' -

BinaryFilePath 'C:\temp\HW1CodeIntegrity.p7b'

７ Notes
 La commande ci-dessus crée une stratégie CI en mode audit uniquement. Elle
n’empêche pas l’exécution des fichiers binaires non autorisés sur l’hôte. Vous
devez uniquement utiliser des stratégies appliquées en production.

2. Conservez votre fichier de stratégie d’intégrité du code (fichier XML) où vous

pouvez facilement le trouver. Vous devrez modifier ce fichier ultérieurement pour
appliquer la stratégie CI ou fusionner les modifications à partir des futures mises à
jour apportées au système.

3. Appliquez la stratégie CI à votre hôte de référence :

a. Exécutez la commande suivante pour configurer la machine afin qu’elle utilise

votre stratégie CI. Vous pouvez également déployer la stratégie CI avec
stratégie de groupe ou System Center Virtual Machine Manager.

PowerShell

Invoke-CimMethod -Namespace root/Microsoft/Windows/CI -ClassName

PS_UpdateAndCompareCIPolicy -MethodName Update -Arguments @{
FilePath = "C:\temp\HW1CodeIntegrity.p7b" }

b. Redémarrez l’hôte pour appliquer la stratégie.

4. Testez la stratégie d’intégrité du code en exécutant une charge de travail classique.

Cela peut inclure des machines virtuelles en cours d’exécution, des agents de
gestion de l’infrastructure, des agents de sauvegarde ou des outils de résolution
des problèmes sur l’ordinateur. Vérifiez s’il existe des violations de l’intégrité du
code et mettez à jour votre stratégie CI si nécessaire.

5. Modifiez votre stratégie CI en mode appliqué en exécutant les commandes

suivantes sur votre fichier XML de stratégie CI mis à jour.

PowerShell

Set-RuleOption -FilePath 'C:\temp\[Link]' -Option 3 -

Delete

ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\[Link]' -

BinaryFilePath 'C:\temp\HW1CodeIntegrity_enforced.p7b'

6. Appliquez la stratégie CI à tous vos hôtes (avec une configuration matérielle et

logicielle identique) à l’aide des commandes suivantes :

PowerShell
 Invoke-CimMethod -Namespace root/Microsoft/Windows/CI -ClassName
PS_UpdateAndCompareCIPolicy -MethodName Update -Arguments @{ FilePath =
"C:\temp\HW1CodeIntegrity.p7b" }

Restart-Computer

７ Notes

Faites attention lorsque vous appliquez des stratégies d’intégration continue

aux hôtes et lors de la mise à jour de logiciels sur ces machines. Tous les
pilotes en mode noyau qui ne sont pas conformes à la stratégie CI peuvent
empêcher le démarrage de l’ordinateur.

7. Fournissez le fichier binaire (dans cet exemple, HW1CodeIntegrity_enforced.p7b) à

l’administrateur SGH.

8. Dans le domaine SGH, copiez la stratégie d’intégrité du code sur un serveur SGH et
exécutez la commande suivante.

Pour <PolicyName> , spécifiez un nom pour la stratégie CI qui décrit le type d’hôte
auquel elle s’applique. Une bonne pratique consiste à le nommer d’après la
marque/le modèle de votre machine et toute configuration logicielle spéciale
exécutée dessus. Pour <Path> , spécifiez le chemin d’accès et le nom de fichier de la
stratégie d’intégrité du code.

PowerShell

Add-HgsAttestationCIPolicy -Path <Path> -Name '<PolicyName>'

７ Notes

Si vous utilisez une stratégie d’intégrité du code signée, inscrivez une copie
non signée de la même stratégie auprès de SGH. La signature sur les
stratégies d’intégrité du code est utilisée pour contrôler les mises à jour de la
stratégie, mais n’est pas mesurée dans le TPM hôte et ne peut donc pas être
attestée par SGH.

Capturer la base de référence TPM pour chaque

classe unique de matériel
Une base de référence TPM est requise pour chaque classe unique de matériel dans
votre infrastructure de centre de données. Utilisez à nouveau un « hôte de référence ».

1. Sur l’hôte de référence, assurez-vous que le rôle Hyper-V et la fonctionnalité

Support Hyper-V pour Host Guardian sont installés.

２ Avertissement

La fonctionnalité de prise en charge Hyper-V de Guardian hôte permet une

protection basée sur la virtualisation de l’intégrité du code qui peut être
incompatible avec certains appareils. Nous vous recommandons vivement de
tester cette configuration dans votre laboratoire avant d'activer cette
fonctionnalité. Dans le cas contraire, cela risque d’entraîner des échecs
inattendus pouvant aller jusqu'à la perte de données ou un écran bleu
d’erreur (également appelé erreur d’arrêt).

PowerShell

Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -

Restart

2. Pour capturer la stratégie de base de référence, exécutez la commande suivante

dans une console Windows PowerShell avec élévation de privilèges.

PowerShell

Get-HgsAttestationBaselinePolicy -Path '[Link]'

７ Notes

Vous devez utiliser l’indicateur -SkipValidation si le démarrage sécurisé de

l’hôte de référence n’est pas activé, si l’outil IOMMU est présent, si la sécurité
basée sur la virtualisation est activée et en cours d’exécution, ou si une
stratégie d’intégrité du code est appliquée. Ces validations sont conçues pour
vous informer des exigences minimales de l’exécution d’une machine virtuelle
protégée sur l’hôte. L’utilisation de l’indicateur -SkipValidation ne modifie pas
la sortie de l’applet de commande ; il réduit simplement au silence les erreurs.

3. Fournissez la base de référence TPM (fichier TCGlog) à l’administrateur SGH.

 4. Dans le domaine SGH, copiez le fichier TCGlog sur un serveur SGH et exécutez la
commande suivante. En règle générale, vous nommez la stratégie d’après la classe
de matériel qu’elle représente (par exemple, « Révision du modèle fabricant »).

PowerShell

Add-HgsAttestationTpmPolicy -Path <Filename>.tcglog -Name

'<PolicyName>'

Étape suivante
Confirmer l’attestation
Créer une clé d’hôte et l’ajouter à SGH
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019

Cette rubrique explique comment préparer les hôtes Hyper-V à devenir des hôtes
Service Guardian à l’aide de l’attestation de clé d’hôte (mode clé). Vous allez créer une
paire de clés d’hôte (ou utiliser un certificat existant), puis ajouter la moitié publique de
la clé à SGH.

Créer une clé d’hôte

1. Installez Windows Server 2019 sur votre machine hôte Hyper-V.

2. Installez les fonctionnalités de prise en charge d’Hyper-V et de Service Guardian

hôte pour Hyper-V :

PowerShell

Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -

Restart

3. Générez automatiquement une clé d’hôte, ou sélectionnez un certificat existant. Si

vous utilisez un certificat personnalisé, il doit avoir au moins une clé RSA de
2 048 bits, disposer d’une valeur d’utilisation améliorée de la clé pour
l’authentification client, et servir de clé de signature numérique.

PowerShell

Set-HgsClientHostKey

Vous pouvez également spécifier une empreinte numérique si vous souhaitez

utiliser votre propre certificat. Cela peut être utile si vous souhaitez partager un
certificat entre plusieurs machines, ou utiliser un certificat lié à un module TPM ou
HSM. Voici un exemple de création de certificat lié à un module TPM (qui empêche
le vol et l’utilisation de la clé privée sur une autre machine, et nécessite
uniquement un module TPM 1.2) :

PowerShell
 $tpmBoundCert = New-SelfSignedCertificate -Subject "Host Key
Attestation ($env:computername)" -Provider "Microsoft Platform Crypto
Provider"
Set-HgsClientHostKey -Thumbprint $[Link]

4. Obtenez la moitié publique de la clé à fournir au serveur SGH. Vous pouvez utiliser
l’applet de commande suivante ou, si le certificat est stocké ailleurs, vous pouvez
fournir un fichier .cer contenant la moitié publique de la clé. Notez que nous
stockons et validons uniquement la clé publique sur SGH. Nous ne conservons
aucune information relative au certificat, et nous ne validons pas la chaîne de
certificats ni la date d’expiration.

PowerShell

Get-HgsClientHostKey -Path "C:\temp\$env:[Link]"

5. Copiez le fichier .cer sur votre serveur SGH.

Ajouter la clé d’hôte au service d’attestation

Cette étape est effectuée sur le serveur SGH et permet à l’hôte d’exécuter des machines
virtuelles dotées d’une protection maximale. Il est recommandé d’affecter à ce nom le
FQDN ou l’identificateur de ressource de la machine hôte pour pouvoir facilement faire
référence à l’hôte sur lequel la clé est installée.

PowerShell

Add-HgsAttestationHostKey -Name MyHost01 -Path "C:\temp\MyHost01-

[Link]"

Étape suivante
Configuration d’une structure protégée : Vérification de l’attestation sur les hôtes

Références supplémentaires
Déploiement du Service Guardian hôte pour les hôtes Service Guardian et les VM
dotées d’une protection maximale
Créer un groupe de sécurité pour les
hôtes protégés et inscrire le groupe
auprès de SGH
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

） Important

Le mode AD est déconseillé à compter de Windows Server 2019. Pour les

environnements où l’attestation TPM n’est pas possible, configurez l’attestation de
clé d’hôte. L’attestation de clé d’hôte fournit une assurance similaire au mode AD
et est plus simple à configurer.

Cette rubrique décrit les étapes intermédiaires pour préparer les hôtes Hyper-V à
devenir des hôtes protégés à l’aide de l’attestation approuvée par l’administrateur
(mode AD). Avant d’effectuer ces étapes, réalisez les étapes décrites dans Configuration
du DNS d’infrastructure pour les hôtes qui deviendront des hôtes protégés.

Créer un groupe de sécurité et ajouter des

hôtes
1. Créez un groupe de sécurité GLOBAL dans le domaine d’infrastructure et ajoutez
des hôtes Hyper-V qui exécuteront des machines virtuelles dotées d’une
protection maximale. Redémarrez les hôtes pour mettre à jour leur appartenance
au groupe.

2. Utilisez Get-ADGroup pour obtenir l’identificateur de sécurité (SID) du groupe de

sécurité et le fournir à l’administrateur SGH.

PowerShell

Get-ADGroup "Guarded Hosts"

Inscrivez le SID du groupe de sécurité auprès
de SGH
1. Sur un serveur SGH, exécutez la commande suivante pour inscrire le groupe de
sécurité auprès de SGH. Réexécutez la commande si nécessaire pour des groupes
supplémentaires. Fournir un nom convivial pour le groupe. Il n’a pas besoin de
correspondre au nom du groupe de sécurité Active Directory.

PowerShell

Add-HgsAttestationHostGroup -Name "<GuardedHostGroup>" -Identifier "

<SID>"

2. Pour vérifier que le groupe a été ajouté, exécutez Get-HgsAttestationHostGroup.

Étape suivante
Confirmer l’attestation

Références supplémentaires
Déploiement du Service Guardian hôte pour les hôtes Service Guardian et les VM
dotées d’une protection maximale
Confirmer que les hôtes Service
Guardian peuvent attester
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Un administrateur de structure doit confirmer que les hôtes Hyper-V peuvent s’exécuter
en tant qu’hôtes Service Guardian. Effectuez les étapes suivantes sur au moins un hôte
Service Guardian :

1. Si vous n’avez pas encore installé le rôle Hyper-V et la fonctionnalité de support

Host Guardian Hyper-V, installez-les avec la commande suivante :

PowerShell

Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -

Restart

2. Assurez-vous que l’hôte Hyper-V peut résoudre le nom DNS HGS et dispose d’une
connectivité réseau pour atteindre le port 80 (ou 443 si vous avez configuré
HTTPS) sur le serveur HGS.

3. Configurez les URL de protection de clé d’attestation de l’hôte :

Via Windows PowerShell : vous pouvez configurer les RL de protection de clé

d’attestation en exécutant la commande suivante dans une console Windows
PowerShell avec élévation de privilèges. Pour <FQDN>, utilisez le nom de
domaine complet (FQDN) de votre cluster HGS (par exemple,
[Link], ou demandez à l’administrateur HGS d’exécuter l’applet de
commande Get-HgsServer sur le serveur HGS pour récupérer les URL).

PowerShell

Set-HgsClientConfiguration -AttestationServerUrl
'[Link] -KeyProtectionServerUrl
'[Link]

Pour configurer un serveur HGS de secours, répétez cette commande et

spécifiez les URL de secours pour les services Protection de clé et Attestation.
Pour plus d’informations, voir Configuration de secours.
 Via VMM : si vous utilisez System Center Virtual Machine Manager (VMM),
vous pouvez configurer des URL d’attestation et de protection de clé dans
VMM. Pour plus d’informations, consultez Configurer les paramètres HGS
globaux dans Provisionner des hôtes Service Guardian dans VMM.

Remarques

Si l’administrateur HGS a activé HTTPS sur le serveur HGS, commencez les

URL par https:// .
Si l’administrateur HGS a activé HTTPS sur le serveur HGS et utilisé un
certificat auto-signé, vous devez importer le certificat dans le magasin
d’autorités de certification racines approuvées sur chaque hôte. Pour cela,
exécutez la commande suivante sur chaque hôte : PowerShell Import-
Certificate -FilePath "C:\temp\[Link]" -
CertStoreLocation Cert:\LocalMachine\Root

Si vous avez configuré le client HGS pour utiliser HTTPS et que vous avez
désactivé TLS 1.0 à l’échelle du système, consultez nos instructions TLS
modernes

4. Pour lancer une tentative d’attestation sur l’hôte et afficher l’état de l’attestation,
exécutez la commande suivante :

PowerShell

Get-HgsClientConfiguration

La sortie de la commande indique si l’hôte a passé l’attestation et s’il est désormais

protégé. Si IsHostGuarded ne retourne pas True, vous pouvez exécuter l’outil de
diagnostic HGS, Get-HgsTrace, pour enquêter. Pour exécuter des diagnostics,
entrez la commande suivante dans une invite de Windows PowerShell avec
élévation de privilèges sur l’hôte :

PowerShell

Get-HgsTrace -RunDiagnostics -Detailed

） Important

Si vous utilisez Windows Server 2019 ou Windows 10, version 1809 ou version
ultérieure et que vous utilisez des stratégies d’intégrité du code, Get-HgsTrace
retourne un échec pour le diagnostic actif de la stratégie d’intégrité du code.
 Vous pouvez ignorer ce résultat en toute sécurité lorsqu’il s’agit du seul
diagnostic défaillant.

Étape suivante
Déployer des machines virtuelles protégées

Références supplémentaires
Déployer le service Guardian hôte (HGS)
Déployer des machines virtuelles protégées
Provisionner des hôtes protégés dans
VMM
Article • 17/07/2024

Cet article explique comment déployer des hôtes Hyper-V protégés dans une
infrastructure de calcul System Center Virtual Machine Manager (VMM). En savoir plus
sur l’infrastructure protégée.

Il existe plusieurs façons de configurer des hôtes Hyper-V protégés dans une
infrastructure VMM.

Configurez un hôte existant pour qu’il soit un hôte protégé : vous pouvez
configurer un hôte existant pour exécuter des machines virtuelles dotées d’une
protection maximale.
Ajouter ou provisionner un nouvel hôte protégé : cet hôte peut être :
Un ordinateur Windows Server existant (avec ou sans le rôle Hyper-V)
Un ordinateur nu

Vous configurez des hôtes protégés dans l’infrastructure VMM comme suit :

1. Configurez les paramètres SGH globaux : VMM connecte tous les hôtes protégés
au même serveur du service guardian hôte (SGH) afin de pouvoir migrer
correctement les machines virtuelles protégées entre les hôtes. Vous spécifiez les
paramètres SGH globaux qui s’appliquent à tous les hôtes protégés, et vous
pouvez spécifier les paramètres spécifiques à l’hôte qui remplacent les paramètres
globaux. Paramètres :

URL d’attestation : URL que l’hôte utilise pour se connecter au service

d’attestation SGH. Ce service autorise un hôte à exécuter des machines
virtuelles dotées d’une protection maximale.
URL du serveur de protection de clé : URL utilisée par l’hôte pour récupérer la
clé nécessaire pour déchiffrer les machines virtuelles. L’hôte doit passer
l’attestation pour récupérer des clés.
Stratégies d’intégrité du code : une stratégie d’intégrité du code restreint le
logiciel qui peut s’exécuter sur un hôte protégé. Lorsque HGS est configuré
pour utiliser l’attestation TPM, les hôtes protégés doivent être configurés
pour utiliser une stratégie d’intégrité du code autorisée par le serveur HGS.
Vous pouvez spécifier l’emplacement des stratégies d’intégrité du code dans
VMM et les déployer sur vos hôtes. Cela est facultatif et n’est pas nécessaire
pour gérer une structure protégée.
 Disque dur virtuel de protection des machines virtuelles : disque dur virtuel
spécialement préparé qui est utilisé pour convertir les machines virtuelles
existantes en machines virtuelles protégées. Vous devez configurer ce
paramètre si vous souhaitez protéger les machines virtuelles existantes.

2. Configurez le cloud : si l’hôte protégé sera inclus dans un cloud VMM, vous devez
activer le cloud pour prendre en charge les machines virtuelles protégées.

Avant de commencer
Vérifiez que vous avez déployé et configuré le service Guardian hôte avant de continuer.
En savoir plus sur la configuration de SGH dans la documentation Windows Server.

En outre, assurez-vous que tous les hôtes qui deviendront des hôtes protégés
répondent aux conditions préalables requises pour l’hôte protégé :

Système d’exploitation : les serveurs hôtes doivent exécuter Windows Server

Datacenter. Il est recommandé d’utiliser Server Core pour les hôtes protégés.
Rôle et fonctionnalités : les serveurs hôtes doivent exécuter le rôle Hyper-V et la
fonctionnalité de support Hyper-V guardian hôte. La prise en charge d’Host
Guardian Hyper-V permet à l’hôte de communiquer avec HGS pour attester de son
intégrité et demander des clés pour les machines virtuelles protégées. Si votre
hôte exécute Nano Server, les packages Compute, SCVMM-Package, SCVMM-
Compute, SecureStartup et ShieldedVM doivent être installés.
Attestation TPM : si votre SGH est configuré pour utiliser l’attestation TPM, les
serveurs hôtes doivent :
Utiliser UEFI 2.3.1c et un module TPM 2.0
Démarrage en mode UEFI (pas bios ou mode hérité )
Activer le démarrage sécurisé
Inscription de SGH : les hôtes Hyper-V doivent être inscrits auprès de SGH. La
façon dont ils sont inscrits dépend de l’utilisation d’une attestation AD ou TPM. En
savoir plus
Migration dynamique : si vous souhaitez migrer en direct des machines virtuelles
dotées d’une protection maximale, vous devez déployer deux hôtes protégés ou
plus.
Domaine : les hôtes protégés et le serveur VMM doivent se trouver dans le même
domaine ou dans les domaines avec une approbation bidirectionnelle.

Configurer les paramètres globaux du SGH

Avant de pouvoir ajouter des hôtes protégés à votre infrastructure de calcul VMM, vous
devez configurer VMM avec des informations sur le SGH pour l’infrastructure. Le même
SGH sera utilisé pour tous les hôtes protégés gérés par VMM.

1. Obtenez les URL d’attestation et de protection de clé pour votre infrastructure

auprès de votre administrateur SGH.

2. Dans la console VMM, sélectionnez Paramètres>du service Guardian de l’hôte

des paramètres.

3. Entrez les URL d’attestation et de protection de clé dans les champs respectifs.
Pour l’instant, vous n’avez pas besoin de configurer les stratégies d’intégrité du
code et les sections du disque dur virtuel de protection des machines virtuelles.

4. Sélectionnez Terminer pour enregistrer la configuration.

Ajouter ou provisionner un nouvel hôte
protégé
1. Ajoutez l’hôte :

Si vous souhaitez ajouter un serveur existant exécutant Windows Server en

tant qu’hôte Hyper-V protégé, ajoutez-le à l’infrastructure.
Si vous souhaitez approvisionner un hôte Hyper-V à partir d’un ordinateur
nu, suivez ces conditions préalables et instructions.

７ Notes

Vous pouvez déployer l’hôte en tant qu’hôte protégé lorsque vous

l’approvisionnez (Ajouter les paramètres>du système d’exploitation de
l’Assistant >Ressource configurés en tant qu’hôte protégé).

2. Passez à la section suivante pour configurer l’hôte en tant qu’hôte protégé.

Configurer un hôte existant pour qu’il soit un

hôte protégé
Pour configurer un hôte Hyper-V existant géré par VMM pour qu’il soit un hôte protégé,
procédez comme suit :

1. Placez l’hôte en mode maintenance.

2. Dans Tous les hôtes, cliquez avec le bouton droit sur l’hôte >Propriétés>Service
Guardian hôte.
3. Sélectionnez cette option pour activer la fonctionnalité de support Hyper-V
Guardian hôte et configurer l’hôte.

７ Notes

Les URL globales d’attestation et de serveur de protection de clé sont

définies sur l’hôte.
Si vous modifiez ces URL en dehors de la console VMM, vous devez
également les mettre à jour dans VMM. Si ce n’est pas le cas, VMM
n’place pas de machines virtuelles protégées sur l’hôte tant que les URL
ne correspondent pas à nouveau. Vous pouvez également décocher et
réactiver la case Activer pour reconfigurer l’hôte avec les URL
configurées dans VMM.

4. Si vous utilisez VMM pour gérer les stratégies d’intégrité du code, vous pouvez
activer la deuxième case à cocher et sélectionner la stratégie appropriée pour le
système.

5. Sélectionnez OK pour mettre à jour la configuration de l’hôte.

6. Retirez l’hôte du mode maintenance.

VMM vérifie que l’hôte passe l’attestation lorsque vous l’ajoutez et chaque fois que l’état
de l’hôte est actualisé. VMM déploie et migre uniquement les machines virtuelles dotées
d’une protection maximale sur les hôtes qui ont passé l’attestation. Vous pouvez vérifier
l’état d’attestation d’un hôte dans le client HGS État>des propriétés>dans l’ensemble.

Activer les hôtes protégés sur un cloud VMM

Activez un cloud pour prendre en charge les hôtes protégés :

1. Dans la console VMM, sélectionnez machines virtuelles et clouds de services>.

Cliquez avec le bouton droit sur le nom du cloud >Propriétés.
2. Dans la prise en charge générale>des machines virtuelles dotées d’une
protection maximale, sélectionnez Prise en charge sur ce cloud privé.

Gérer et déployer des stratégies d’intégrité du

code avec VMM
Dans les structures protégées configurées pour utiliser l’attestation TPM, chaque hôte
doit être configuré avec une stratégie d’intégrité du code approuvée par le service
Guardian hôte. Pour faciliter la gestion des stratégies d’intégrité du code, vous pouvez
éventuellement utiliser VMM pour déployer des stratégies nouvelles ou mises à jour sur
vos hôtes protégés.

Pour déployer une stratégie d’intégrité du code sur un hôte protégé géré par VMM,
procédez comme suit :

1. Créez une stratégie d’intégrité du code pour chaque hôte de référence dans votre
environnement. Vous avez besoin d’une stratégie CI différente pour chaque
configuration matérielle et logicielle unique de vos hôtes protégés.
2. Stockez les stratégies CI dans un partage de fichiers sécurisé. Les comptes
d’ordinateur pour chaque hôte protégé nécessitent un accès en lecture au partage.
Seuls les administrateurs approuvés doivent avoir un accès en écriture.
3. Dans la console VMM, sélectionnez Paramètres>du service Guardian de l’hôte
des paramètres.
4. Dans la section Stratégies d’intégrité du code, sélectionnez Ajouter et spécifier un
nom convivial et le chemin d’accès à une stratégie CI. Répétez cette étape pour
chaque stratégie CI unique. Veillez à nommer vos stratégies d’une manière qui
 vous aidera à identifier la stratégie à appliquer aux hôtes.

5. Sélectionnez Terminer pour enregistrer la configuration.

À présent, pour chaque hôte protégé, effectuez les étapes suivantes pour appliquer une
stratégie d’intégrité du code :

1. Placez l’hôte en mode maintenance.

2. Dans Tous les hôtes, cliquez avec le bouton droit sur l’hôte >Propriétés>Service
Guardian hôte.
 3. Sélectionnez cette option pour configurer l’hôte avec une stratégie d’intégrité du
code. Sélectionnez ensuite la stratégie appropriée pour le système.

4. Sélectionnez OK pour appliquer la modification de configuration. L’hôte peut

redémarrer pour appliquer la nouvelle stratégie.

5. Retirez l’hôte du mode maintenance.

２ Avertissement

Vérifiez que vous sélectionnez la stratégie d’intégrité du code correcte pour l’hôte.
Si une stratégie incompatible est appliquée à l’hôte, certaines applications, pilotes
ou composants du système d’exploitation peuvent ne plus fonctionner.

Si vous mettez à jour la stratégie d’intégrité du code dans le partage de fichiers et que
vous souhaitez également mettre à jour les hôtes protégés, vous pouvez le faire en
effectuant les étapes suivantes :

1. Placez l’hôte en mode maintenance.

2. Dans Tous les hôtes, cliquez avec le bouton droit sur l’hôte >Appliquer la dernière
stratégie d’intégrité du code.
3. Retirez l’hôte du mode maintenance.
Étapes suivantes
Configurez un disque de modèle protégé, un disque utilitaire et un modèle de
machine virtuelle.

Commentaires
Cette page a-t-elle été utile ?  Yes  No

Indiquer des commentaires sur le produit | Obtenir de l’aide sur Microsoft Q&A
Déployer des machines virtuelles
protégées
Article • 11/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Les rubriques suivantes décrivent comment un locataire peut utiliser des machines
virtuelles dotées d’une protection maximale.

1. (Facultatif) Créer un disque de modèle Windows ou créer un disque de modèle

Linux. Le disque de modèle peut être créé par le locataire ou le fournisseur de
services d’hébergement.

2. (Facultatif) Convertir une machine virtuelle Windows existante en machine virtuelle

dotée d’une protection maximale.

3. Créer des données de protection pour définir une machine virtuelle dotée d’une
protection maximale.

Pour obtenir la description et le diagramme d’un fichier de données de protection,

consultez En quoi consistent les données de protection et pourquoi sont-elles
nécessaires ?

Pour plus d’informations sur la création d’un fichier de réponses à inclure dans un
fichier de données protégé, consultez Machines virtuelles dotées d’une protection
maximale - Générer un fichier de réponses à l’aide de la fonction New-
ShieldingDataAnswerFile.

4. Créer une machine virtuelle dotée d’une protection maximale :

Utilisation de Windows Azure Pack : Déployer une VM dotée d’une

protection maximale à l’aide de Windows Azure Pack

Utilisation de Virtual Machine Manager : Déployer une machine virtuelle

protégée à l’aide de Virtual Machine Manager

Étape suivante
Créer un modèle de machine virtuelle protégée
Références supplémentaires
Structure protégée et machines virtuelles dotées d’une protection maximale
Créer un disque de modèle de machine
virtuelle dotée d’une protection
maximale Windows
Article • 11/04/2023

S’applique à : Windows Server 2022, Windows Server 2016, Windows Server 2019

Comme avec les machines virtuelles standard, vous pouvez créer un modèle de machine
virtuelle (par exemple, un modèle de machine virtuelle dans Virtual Machine Manager
(VMM)) pour faciliter le déploiement de nouvelles machines virtuelles sur l’infrastructure
à l’aide d’un disque de modèle pour les locataires et les administrateurs. Étant donné
que les machines virtuelles dotées d’une protection maximale sont des ressources
sensibles, il existe des étapes supplémentaires pour créer un modèle de machine
virtuelle prenant en charge la protection. Cette rubrique décrit les étapes de création
d’un disque de modèle protégé et d’un modèle de machine virtuelle dans VMM.

Pour comprendre comment cette rubrique s’intègre dans le processus global de

déploiement de machines virtuelles dotées d’une protection maximale, consultez Étapes
de configuration du fournisseur de services d’hébergement pour les hôtes protégés et
les machines virtuelles dotées d’une protection maximale.

Préparer un VHDX de système d’exploitation

Préparez d’abord un disque de système d’exploitation que vous exécuterez ensuite via
l’Assistant de création de disque de modèle protégé. Ce disque sera utilisé comme
disque de système d’exploitation dans les machines virtuelles de votre locataire. Vous
pouvez utiliser n’importe quel outil existant pour créer ce disque, comme Microsoft
Desktop Image Service Manager (DISM), ou configurer manuellement une machine
virtuelle avec un VHDX vide et installer le système d’exploitation sur ce disque. Lors de la
configuration du disque, il doit respecter les exigences suivantes spécifiques aux
machines virtuelles de génération 2 et/ou dotées d’une protection maximale :

Configuration requise pour VHDX Motif

Doit être un disque de table de partition GUID (GPT) Nécessaire pour les
machines virtuelles de
génération 2 pour prendre
en charge UEFI
 Configuration requise pour VHDX Motif

Le type de disque doit être De base et non Dynamique. BitLocker ne prend PAS en
Remarque : Cela fait référence au type de disque logique, et non à charge les disques
la fonctionnalité VHDX d’« expansion dynamique » prise en dynamiques.
charge par Hyper-V.

Le disque comporte au moins deux partitions. Une partition doit Nécessaire pour BitLocker
inclure le lecteur sur lequel Windows est installé. Il s’agit du
lecteur que BitLocker chiffrera. L’autre partition est la partition
active, qui contient le chargeur de démarrage et reste non chiffrée
afin que l’ordinateur puisse démarrer.

Le système de fichiers est NTFS Nécessaire pour BitLocker

Le système d’exploitation installé sur le VHDX est l’un des Nécessaire pour prendre en
suivants : charge les machines
- Windows Server 2019, Windows Server 2016, Windows Server virtuelles de génération 2 et
2012 R2 ou Windows Server 2012 le modèle de démarrage
- Windows 10, Windows 8.1, Windows 8 sécurisé Microsoft

Le système d’exploitation doit être généralisé (exécutez L’approvisionnement de

[Link]) modèles implique la
spécialisation des machines
virtuelles pour la charge de
travail d’un locataire
spécifique

７ Notes

Si vous utilisez VMM, ne copiez pas le disque de modèle dans la bibliothèque VMM
à ce stade.

Exécutez Windows Update sur le système

d’exploitation du modèle
Sur le disque du modèle, vérifiez que toutes les dernières mises à jour de Windows sont
installées dans le système d’exploitation. Les mises à jour publiées récemment
améliorent la fiabilité du processus de protection de bout en bout, processus qui peut
échouer si le système d’exploitation du modèle n’est pas à jour.

Préparer et protéger le VHDX avec l’Assistant

Disque de modèle
Pour utiliser un disque de modèle avec des machines virtuelles dotées d’une protection
maximale, le disque doit être préparé et chiffré avec BitLocker à l’aide de l’Assistant de
création du disque de modèle doté d’une protection maximale. Cet assistant génère un
hachage pour le disque et l’ajoute à un catalogue de signatures de volume (VSC). Le
VSC est signé à l’aide d’un certificat que vous spécifiez et il est utilisé pendant le
processus de configuration pour garantir que le disque en cours de déploiement pour
un locataire n’a pas été modifié ou remplacé par un disque qui n’est pas approuvé par le
locataire. Enfin, BitLocker est installé sur le système d’exploitation du disque (s’il ne l’est
pas déjà) pour préparer le disque pour le chiffrement pendant l’approvisionnement de la
machine virtuelle.

７ Notes

L’Assistant Disque de modèle modifie le disque de modèle que vous spécifiez sur
place. Vous pouvez effectuer une copie du VHDX non protégé avant d’exécuter
l’Assistant pour effectuer des mises à jour sur le disque ultérieurement. Vous ne
pourrez pas modifier un disque qui a été protégé avec l’Assistant Disque de
modèle.

Effectuez les étapes suivantes sur un ordinateur exécutant Windows Server 2016,
Windows 10 (avec outils d’administration de serveur distant, RSAT installé) ou version
ultérieure (il n’a pas besoin d’être un hôte Service Guardian ou un serveur VMM) :

1. Copiez le VHDX généralisé créé dans Préparer un VHDX de système d’exploitation

sur le serveur, s’il n’y est pas déjà.

2. Pour administrer le serveur localement, installez la fonctionnalité Outils de

machine virtuelle dotée d’une protection maximale à partir des Outils
d’administration de serveur distant sur le serveur.

Install-WindowsFeature RSAT-Shielded-VM-Tools -Restart

Vous pouvez également administrer le serveur à partir d’un ordinateur client sur
lequel vous avez installé le les Outils d’administration de serveur distant
Windows 10 .

3. Obtenez ou créez un certificat pour signer le VSC pour le VHDX qui deviendra le
modèle de disque pour les nouvelles machines virtuelles dotées d’une protection
maximale. Les détails de ce certificat seront affichés aux locataires lorsqu’ils créent
leurs fichiers de données de protection et autorisent les disques auxquels ils font
 confiance. Par conséquent, il est important d’obtenir ce certificat auprès d’une
autorité de certification mutuellement approuvée par vous et vos locataires. Dans
les scénarios d’entreprise où vous êtes à la fois l’hôte et le locataire, vous pouvez
envisager d’émettre ce certificat à partir de votre PKI.

Si vous configurez un environnement de test et que vous souhaitez simplement

utiliser un certificat auto-signé pour préparer votre disque de modèle, exécutez
une commande similaire à la suivante :

New-SelfSignedCertificate -DnsName [Link]

4. Démarrez l’Assistant Disque de modèle à partir du dossier Outils d’administration

du menu Démarrer ou en tapant [Link] dans une invite de
commandes.

5. Dans la page Certificat, cliquez sur Parcourir pour afficher une liste de certificats.
Sélectionnez le certificat avec lequel préparer le modèle de disque. Cliquez sur OK,
puis sur Suivant.

6. Dans la page Disque virtuel, cliquez sur Parcourir pour sélectionner le VHDX que
vous avez préparé, puis cliquez sur Suivant.

7. Dans la page Catalogue de signatures, indiquez un nom de disque convivial et une

version. Ces champs sont présents pour vous aider à identifier le disque une fois
qu’il a été préparé.

Par exemple, pour le nom de disque, vous pouvez taper WS2016 et pour version,
[Link]

8. Passez en revue vos sélections dans la page Vérifier les paramètres de l’Assistant.
Lorsque vous cliquez sur Générer, l’Assistant active BitLocker sur le disque du
modèle, calcule le hachage du disque et crée le catalogue de signature de volume,
qui est stocké dans les métadonnées VHDX.

Attendez que le processus de préparation soit terminé avant d’essayer de monter

ou de déplacer le disque de modèle. Ce processus peut prendre un certain temps,
en fonction de la taille de votre disque.

） Important

Les disques de modèle ne peuvent être utilisés qu’avec le processus

d’approvisionnement sécurisé des machines virtuelles dotées d’une protection
 maximale. La tentative de démarrage d’une machine virtuelle standard (non
protégée) à l’aide d’un disque de modèle entraînerait probablement une
erreur d’arrêt (écran bleu) et n’est pas prise en charge.

9. Dans la page Résumé, des informations sur le modèle de disque, le certificat utilisé
pour signer le VSC et l’émetteur du certificat s’affichent. Cliquez sur Fermer pour
quitter l’Assistant.

Si vous utilisez VMM, suivez les étapes décrites dans les sections restantes de cette
rubrique pour incorporer un disque de modèle dans un modèle de machine virtuelle
dotée d’une protection maximale dans VMM.

Copiez le disque de modèle dans la

bibliothèque VMM
Si vous utilisez VMM, après avoir créé un disque de modèle, vous devez le copier dans
un partage de bibliothèque VMM afin que les hôtes puissent télécharger et utiliser le
disque lors de l’approvisionnement de nouvelles machines virtuelles. Utilisez la
procédure suivante pour copier le disque de modèle dans la bibliothèque VMM, puis
actualisez la bibliothèque.

1. Copiez le fichier VHDX dans le dossier de partage de bibliothèque VMM. Si vous

avez utilisé la configuration VMM par défaut, copiez le disque de modèle dans \
<\vmmserver>\MSSCVMMLibrary\VHDs.

2. Actualisez le serveur de bibliothèque. Ouvrez l’espace de travail Bibliothèque,

développez Serveurs de bibliothèque, cliquez avec le bouton droit sur le serveur
de bibliothèque que vous souhaitez actualiser, puis cliquez sur Actualiser.

3. Ensuite, fournissez à VMM des informations sur le système d’exploitation installé

sur le disque du modèle :

a. Recherchez votre disque de modèle nouvellement importé sur votre serveur de

bibliothèque dans l’espace de travail Bibliothèque.

b. Cliquez avec le bouton droit sur le disque, puis cliquez sur Propriétés.

c. Pour système d’exploitation, développez la liste et sélectionnez le système

d’exploitation installé sur le disque. La sélection d’un système d’exploitation
indique à VMM que le VHDX n’est pas vide.

d. Lorsque vous avez mis à jour les propriétés, cliquez sur OK.
La petite icône de bouclier située à côté du nom du disque indique qu’il s’agit d’un
disque modèle préparé pour les machines virtuelles dotées d’une protection maximale.
Vous pouvez également cliquer avec le bouton droit sur les en-têtes de colonne et
activer la colonne Protection maximale pour afficher une représentation textuelle
indiquant si un disque est destiné aux déploiements de machines virtuelles standard ou
dotées d’une protection maximale.

Créer le modèle de machine virtuelle dotée

d’une protection maximale dans VMM à l’aide
du disque de modèle préparé
Avec un disque de modèle préparé dans votre bibliothèque VMM, vous êtes prêt à créer
un modèle de machine virtuelle pour les machines virtuelles dotées d’une protection
maximale. Les modèles de machine virtuelle pour les machines virtuelles dotées d’une
protection maximale diffèrent légèrement des modèles de machine virtuelle
traditionnels en cela que certains paramètres sont fixes (machine virtuelle de
génération 2, UEFI et démarrage sécurisé activés, etc.) et que d’autres ne sont pas
disponibles (la personnalisation du locataire est limitée à une poignée de propriétés de
la machine virtuelle). Pour créer le modèle de machine virtuelle, effectuez les étapes
suivantes :

1. Dans l’espace de travail Bibliothèque, cliquez sur Créer un modèle de machine

virtuelle sous l’onglet Accueil en haut.

2. Dans la page Sélectionner une source, cliquez sur Utiliser un modèle d'ordinateur
virtuel existant ou un disque dur virtuel stocké dans la bibliothèque, puis cliquez
sur Parcourir.
 3. Dans la fenêtre qui s’affiche, sélectionnez un disque de modèle préparé à partir de
la bibliothèque VMM. Pour identifier plus facilement les disques préparés, cliquez
avec le bouton droit sur un en-tête de colonne et activez la colonne Protection
maximale. Cliquez sur OK, puis sur Suivant.

4. Spécifiez un nom pour de modèle de machine virtuelle, et éventuellement une

description, puis cliquez sur Suivant.

5. Dans la page Configurer le matériel, spécifiez les fonctionnalités des machines

virtuelles créées à partir de ce modèle. Vérifiez qu’au moins une carte réseau est
disponible et configurée sur le modèle de machine virtuelle. La seule façon pour
un locataire de se connecter à une machine virtuelle dotée d’une protection
maximale consiste à utiliser la connexion Bureau à distance, la gestion à distance
Windows ou d’autres outils d’administration à distance préconfigurés qui
fonctionnent sur des protocoles réseau.

Si vous choisissez de tirer parti des pools d’adresses IP statiques dans VMM au lieu
d’exécuter un serveur DHCP sur le réseau du locataire, vous devez avertir vos
locataires de cette configuration. Lorsqu’un locataire fournit son fichier de données
de protection, qui contient le fichier sans assistance pour VMM, il doit fournir des
valeurs d’espace réservé spéciales pour les informations du pool d’adresses IP
statiques. Pour plus d’informations sur les espaces réservés VMM dans les fichiers
sans assistance de locataire, consultez Créer un fichier de réponses.

6. Dans la page Configurer le système d’exploitation, VMM affiche uniquement

quelques options pour les machines virtuelles dotées d’une protection maximale,
notamment la clé de produit, le fuseau horaire et le nom de l’ordinateur. Certaines
informations sécurisées, comme le mot de passe administrateur et le nom de
domaine, sont spécifiées par le locataire via un fichier de données de protection
(fichier .PDK).

７ Notes

Si vous choisissez de spécifier une clé de produit sur cette page, vérifiez
qu’elle est valide pour le système d’exploitation sur le disque du modèle. Si
une clé de produit incorrecte est utilisée, la création de la machine virtuelle
échoue.

Une fois le modèle créé, les locataires peuvent l’utiliser pour créer de nouvelles
machines virtuelles. Vous devez vérifier que le modèle de machine virtuelle est l’une des
ressources disponibles pour le rôle d’utilisateur Administrateur de locataire (dans VMM,
les rôles d’utilisateur se trouvent dans l’espace de travail Paramètres).
Préparer et protéger le VHDX à l’aide de
PowerShell
En guise d’alternative à l’exécution de l’Assistant Disque de modèle, vous pouvez copier
votre disque et votre certificat de modèle sur un ordinateur exécutant RSAT, et exécuter
Protect-TemplateDisk pour lancer le processus de signature. L’exemple suivant utilise les
informations de nom et de version spécifiées par les paramètres TemplateName et
Version. Le disque dur virtuel que vous fournissez au paramètre -Path sera remplacé par
le disque de modèle mis à jour. Veillez donc à effectuer une copie avant d’exécuter la
commande.

PowerShell

# Replace "THUMBPRINT" with the thumbprint of your template disk signing

certificate in the line below
$certificate = Get-Item Cert:\LocalMachine\My\THUMBPRINT

Protect-TemplateDisk -Certificate $certificate -Path "WindowsServer2019-

[Link]" -TemplateName "Windows Server 2019" -Version [Link]

Votre disque de modèle est maintenant prêt à être utilisé pour approvisionner des
machines virtuelles dotées d’une protection maximale. Si vous utilisez System Center
Virtual Machine Manager pour déployer votre machine virtuelle, vous pouvez
maintenant copier le VHDX dans votre bibliothèque VMM.

Vous pouvez également extraire le catalogue de signatures de volume du VHDX. Ce

fichier est utilisé pour fournir des informations sur le certificat de signature, le nom du
disque et la version aux propriétaires de machines virtuelles qui souhaitent utiliser votre
modèle. Ils doivent importer ce fichier dans l’Assistant Fichier de données de protection
pour vous autoriser, l’auteur du modèle en possession du certificat de signature, à créer
ce modèle et les disques de modèle futurs.

Pour extraire le catalogue de signatures de volume, exécutez la commande suivante

dans PowerShell :

PowerShell

Save-VolumeSignatureCatalog -TemplateDiskPath 'C:\temp\[Link]'

-VolumeSignatureCatalogPath 'C:\temp\[Link]'

Étape suivante
Créer un fichier de données de protection

Références supplémentaires
Étapes de configuration du fournisseur de services d’hébergement pour les hôtes
Service Guardian et les machines virtuelles dotées d’une protection maximale
Structure protégée et machines virtuelles dotées d’une protection maximale
Créer un disque de modèle de machine
virtuelle dotée d’une protection
maximale Linux
Article • 12/04/2023

S’applique à : Windows Server 2022, Windows Server 2019

Cette rubrique explique comment préparer un disque de modèle pour des machines
virtuelles protégées Linux qui peuvent être utilisées pour instancier une ou plusieurs
machines virtuelles clientes.

Prérequis
Pour préparer et tester une machine virtuelle protégée Linux, vous aurez besoin des
ressources suivantes disponibles :

Un serveur avec des capacités de virtualisation exécutant Windows Server, version

1709 ou ultérieure
Un deuxième ordinateur (Windows 10 ou Windows Server 2016) capable
d’exécuter le Gestionnaire Hyper-V pour se connecter à la console de la machine
virtuelle en cours d’exécution
Image ISO pour l’un des systèmes d’exploitation de machines virtuelles linux
protégés pris en charge :
Ubuntu 16.04 LTS avec le noyau 4.4
Red Hat Enterprise Linux 7.3
SUSE Linux Enterprise Server 12 avec Service Pack 2
Accès Internet pour télécharger le package lsvmtools et les mises à jour du
système d’exploitation

） Important

Les versions plus récentes des systèmes d’exploitation Linux précédents peuvent
inclure un bogue de pilote TPM connu qui les empêchera de s’approvisionner
correctement en tant que machines virtuelles protégées. Il n’est pas recommandé
de mettre à jour vos modèles ou machines virtuelles protégées vers une version
plus récente tant qu’un correctif n’est pas disponible. La liste des systèmes
d’exploitation pris en charge ci-dessus sera mise à jour lorsque les mises à jour
seront rendues publiques.
Préparer une machine virtuelle Linux
Les Machines virtuelles dotées d’une protection maximale sont créées à l’aide de
disques de modèle sécurisés. Les disques de modèle contiennent le système
d’exploitation de la machine virtuelle et les métadonnées, y compris une signature
numérique des partitions /boot et /root, pour garantir que les composants principaux
du système d’exploitation ne sont pas modifiés avant le déploiement.

Pour créer un disque de modèle, vous devez d’abord créer une machine virtuelle
standard (non protégée) que vous allez préparer comme image de base pour les futures
machines virtuelles protégées. Les logiciels que vous installez et les modifications de
configuration que vous apportez à cette machine virtuelle s’appliqueront à toutes les
machines virtuelles protégées créées à partir de ce disque de modèle. Ces étapes vous
guident à travers la configuration minimale requise pour préparer une machine virtuelle
Linux pour la modélisation.

７ Notes

Le chiffrement de disque Linux est configuré lorsque le disque est partitionné. Cela
signifie que vous devez créer une machine virtuelle pré-chiffrée à l’aide de dm-
crypt pour créer un disque de modèle de machine virtuelle protégé Linux.

1. Sur le serveur de virtualisation, vérifiez que les fonctionnalités de prise en charge

Hyper-V et Host Guardian Hyper-V sont installées en exécutant les commandes
suivantes dans une console PowerShell avec élévation de privilèges :

PowerShell

Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -

Restart

2. Téléchargez l’image ISO à partir d’une source fiable et stockez-la sur votre serveur
de virtualisation ou sur un partage de fichiers accessible à votre serveur de
virtualisation.

3. Sur votre ordinateur d’administration exécutant Windows Server version 1709,

installez les Outils d’administration de serveur distant de machine virtuelle
protégée en exécutant la commande suivante :

PowerShell
 Install-WindowsFeature RSAT-Shielded-VM-Tools

4. Ouvrez le Gestionnaire Hyper-V sur votre ordinateur de gestion et connectez-vous

à votre serveur de virtualisation. Pour ce faire, cliquez sur « Se connecter au
serveur... » dans le volet Actions ou en cliquant avec le bouton droit sur le
Gestionnaire Hyper-V et en choisissant « Se connecter au serveur... » Indiquez le
nom DNS de votre serveur Hyper-V et, si nécessaire, les informations
d’identification nécessaires pour s’y connecter.

5. À l’aide du Gestionnaire Hyper-V, configurez un commutateur externe sur votre

serveur de virtualisation afin que la machine virtuelle Linux puisse accéder à
Internet pour obtenir des mises à jour.

6. Ensuite, créez une machine virtuelle sur laquelle installer le système d’exploitation
Linux. Dans le volet Actions, cliquez sur Nouvelle>machine virtuelle pour afficher
l’Assistant. Fournissez un nom convivial pour votre machine virtuelle, par exemple
« Linux pré-modélisé », puis cliquez sur Suivant.

7. Dans la deuxième page de l’Assistant, sélectionnez Génération 2 pour vous assurer

que la machine virtuelle est approvisionnée avec un profil de microprogramme
basé sur UEFI.

8. Complétez la suite de l'assistant en fonction de vos préférences. N’utilisez pas de

disque de différenciation pour cette machine virtuelle ; Les disques de modèle de
machine virtuelle protégés ne peuvent pas utiliser de disques de différenciation.
Enfin, connectez l’image ISO que vous avez téléchargée précédemment au lecteur
DVD virtuel de cette machine virtuelle afin de pouvoir installer le système
d’exploitation.

9. Dans le Gestionnaire Hyper-V, sélectionnez votre machine virtuelle nouvellement

créée, puis cliquez sur Se connecter... dans le volet Actions pour l’attacher à une
console virtuelle de la machine virtuelle. Dans la fenêtre qui s’affiche, cliquez sur
Démarrer pour activer la machine virtuelle.

10. Passez au processus d’installation de la distribution Linux sélectionnée. Bien que

chaque distribution Linux utilise un Assistant d’installation différent, les conditions
suivantes doivent être remplies pour les machines virtuelles qui deviendront des
disques de modèle de machine virtuelle protégée Linux :

Le disque doit être partitionné à l’aide de la disposition GUID Paritioning

Table (GPT)
La partition racine doit être chiffrée avec dm-crypt. La phrase secrète doit
être définie sur la phrase secrète (tout en minuscules). Cette phrase secrète
 est aléatoire et la partition rechiffrée lorsqu’une machine virtuelle protégée
est provisionnée.
La partition de démarrage doit utiliser le système de fichiers ext2

11. Une fois que votre système d’exploitation Linux a entièrement démarré et que
vous vous êtes connecté, il est recommandé d’installer le noyau virtuel linux et les
packages de services d’intégration Hyper-V associés. En outre, vous souhaiterez
installer un serveur SSH ou un autre outil de gestion à distance pour accéder à la
machine virtuelle une fois qu’elle est protégée.

Sur Ubuntu, exécutez la commande suivante pour installer ces composants :

Bash

sudo apt-get install linux-virtual linux-tools-virtual linux-cloud-

tools-virtual linux-image-extra-virtual openssh-server

Sur RHEL, exécutez la commande suivante à la place :

Bash

sudo yum install hyperv-daemons openssh-server

sudo service sshd start

Pour SLES, exécutez la commande suivante :

Bash

sudo zypper install hyper-v

sudo chkconfig hv_kvp_daemon on
sudo systemctl enable sshd

12. Configurez votre système d’exploitation Linux comme vous le souhaitez. Tous les
logiciels que vous installez, les comptes d’utilisateur que vous ajoutez et les
modifications de configuration à l’échelle du système que vous apportez
s’appliquent à toutes les futures machines virtuelles créées à partir de ce disque de
modèle. Vous devez éviter d’enregistrer des secrets ou des packages inutiles sur le
disque.

13. Si vous envisagez d’utiliser System Center Virtual Machine Manager pour déployer
vos machines virtuelles, installez l’agent invité VMM pour permettre à VMM de
spécialiser votre système d’exploitation pendant l’approvisionnement de machines
virtuelles. La spécialisation permet à chaque machine virtuelle d’être configurée de
manière sécurisée avec différents utilisateurs et clés SSH, configurations réseau et
 étapes d’installation personnalisées. Découvrez comment obtenir et installer
l’agent invité VMM dans la documentation VMM.

14. Ensuite, ajoutez le référentiel de logiciels Microsoft Linux à votre gestionnaire de

package.

15. À l’aide de votre gestionnaire de package, installez le package lsvmtools qui

contient le shim du chargeur de démarrage de machine virtuelle protégé Linux, les
composants d’approvisionnement et l’outil de préparation du disque.

Bash

# Ubuntu 16.04
sudo apt-get install lsvmtools

# SLES 12 SP2
sudo zypper install lsvmtools

# RHEL 7.3
sudo yum install lsvmtools

16. Lorsque vous avez terminé de personnaliser le système d’exploitation Linux,

recherchez le programme d’installation lsvmprep sur votre système et exécutez-le.

Bash

# The path below may change based on the version of lsvmprep installed
# Run "find /opt -name lsvmprep" to locate the lsvmprep executable
sudo /opt/lsvmtools-1.0.0-x86-64/lsvmprep

17. Arrêtez votre machine virtuelle.

18. Si vous avez pris des points de contrôle de votre machine virtuelle (y compris des
points de contrôle automatiques créés par Hyper-V avec le Windows 10 Fall
Creators Update), veillez à les supprimer avant de continuer. Les points de contrôle
créent des disques de différenciation (.avhdx) qui ne sont pas pris en charge par
l’Assistant Modèle de disque.

Pour supprimer des points de contrôle, ouvrez le Gestionnaire Hyper-V,

sélectionnez votre machine virtuelle, cliquez avec le bouton droit sur le point de
contrôle le plus haut dans le volet Points de contrôle, puis cliquez sur Supprimer la
sous-arborescence du point de contrôle.
Protéger le disque de modèle
La machine virtuelle que vous avez préparée dans la section précédente est presque
prête à être utilisée en tant que disque de modèle de machine virtuelle protégé Linux. La
dernière étape consiste à exécuter le disque via l’Assistant Modèle de disque, qui
effectuera un hachage et signera numériquement l’état actuel des partitions racine et de
démarrage. Le hachage et la signature numérique sont vérifiés lorsqu’une machine
virtuelle protégée est provisionnée pour s’assurer qu’aucune modification non autorisée
n’a été apportée aux deux partitions entre la création et le déploiement du modèle.

Obtenir un certificat pour signer le disque

Pour signer numériquement les mesures de disque, vous devez obtenir un certificat sur
l’ordinateur sur lequel vous allez exécuter l’Assistant Modèle de disque. Le certificat doit
répondre aux exigences suivantes :

Propriété du certificat Valeur requise

Algorithme de clé RSA

Taille de clé minimale 2 048 bits

Algorithme de signature SHA256 (recommandé)

Utilisation de la clé Signature numérique

Les détails de ce certificat seront affichés aux locataires lorsqu’ils créent leurs fichiers de
données de protection et autorisent les disques auxquels ils font confiance. Par
conséquent, il est important d’obtenir ce certificat auprès d’une autorité de certification
mutuellement approuvée par vous et vos locataires. Dans les scénarios d’entreprise où
vous êtes à la fois l’hôte et le locataire, vous pouvez envisager d’émettre ce certificat à
partir de votre autorité de certification d’entreprise. Protégez ce certificat avec soin, car
toute personne en possession de ce certificat peut créer de nouveaux disques de
modèle qui sont approuvés de la même façon que votre disque authentique.

Dans un environnement de laboratoire de test, vous pouvez créer un certificat auto-

signé avec la commande PowerShell suivante :

PowerShell

New-SelfSignedCertificate -Subject "CN=Linux Shielded VM Template Disk

Signing Certificate"

Traiter le disque avec l’applet de commande De l’Assistant

Disque de modèle
Copiez le disque et le certificat de votre modèle sur un ordinateur exécutant Windows
Server, version 1709, puis exécutez les commandes suivantes pour lancer le processus
de signature. Le disque dur virtuel que vous fournissez au paramètre -Path sera
remplacé par le disque de modèle mis à jour. Veillez donc à effectuer une copie avant
d’exécuter la commande.

） Important

Les outils d’administration de serveur distant disponibles sur Windows Server 2016
ou Windows 10 ne peuvent pas être utilisés pour préparer un disque de modèle de
machine virtuelle protégé Linux. Utilisez uniquement l’applet de commande
Protect-TemplateDisk disponible sur Windows Server, version 1709 ou les outils
d’administration de serveur distant disponibles sur Windows Server 2019 pour
préparer un disque de modèle de machine virtuelle protégée Linux.

PowerShell

# Replace "THUMBPRINT" with the thumbprint of your template disk signing

certificate in the line below
$certificate = Get-Item Cert:\LocalMachine\My\THUMBPRINT

Protect-TemplateDisk -Path 'C:\temp\[Link]' -TemplateName

'Ubuntu 16.04' -Version [Link] -Certificate $certificate -
ProtectedTemplateTargetDiskType PreprocessedLinux

Votre disque de modèle est maintenant prêt à être utilisé pour approvisionner des
machines virtuelles dotées d’une protection maximale. Si vous utilisez System Center
Virtual Machine Manager pour déployer votre machine virtuelle, vous pouvez
maintenant copier le VHDX dans votre bibliothèque VMM.

Vous pouvez également extraire le catalogue de signatures de volume du VHDX. Ce

fichier est utilisé pour fournir des informations sur le certificat de signature, le nom du
disque et la version aux propriétaires de machines virtuelles qui souhaitent utiliser votre
modèle. Ils doivent importer ce fichier dans l’Assistant Fichier de données de protection
pour vous autoriser, l’auteur du modèle en possession du certificat de signature, à créer
ce modèle et les disques de modèle futurs.

Pour extraire le catalogue de signatures de volume, exécutez la commande suivante

dans PowerShell :

PowerShell

Save-VolumeSignatureCatalog -TemplateDiskPath 'C:\temp\[Link]'

-VolumeSignatureCatalogPath 'C:\temp\[Link]'
VM dotées d’une protection maximale :
Le fournisseur de services
d’hébergement configure Windows
Azure Pack
Article • 11/04/2023

Cette rubrique décrit comment un fournisseur de services d’hébergement peut

configurer Windows Azure Pack afin que les locataires puissent l’utiliser pour déployer
des machines virtuelles protégées. Windows Azure Pack est un portail web qui étend les
fonctionnalités de System Center Virtual Machine Manager pour permettre aux
locataires de déployer et de gérer leurs propres machines virtuelles via une interface
web simple. Windows Azure Pack prend entièrement en charge les machines virtuelles
protégées et facilite la création et la gestion de leurs fichiers de données de protection.

Pour comprendre comment cette rubrique s’intègre dans le processus global de

déploiement de machines virtuelles dotées d’une protection maximale, consultez Étapes
de configuration du fournisseur de services d’hébergement pour les hôtes protégés et
les machines virtuelles dotées d’une protection maximale.

Configurer Windows Azure Pack

Vous allez effectuer les tâches suivantes pour configurer Windows Azure Pack dans votre
environnement :

1. Configuration complète de System Center 2016 - Virtual Machine Manager (VMM)

pour votre infrastructure d’hébergement. Cela inclut la configuration des modèles
de machine virtuelle et un cloud de machine virtuelle, qui seront exposés via
Windows Azure Pack :

Scénario : Déployer des hôtes Service Guardian et des machines virtuelles

protégées dans VMM

2. Installez et configurez System Center 2016 - Service Provider Foundation (SPF). Ce

logiciel permet à Windows Azure Pack de communiquer avec vos serveurs VMM :

Déploiement de Service Provider Foundation - SPF

3. Installez Windows Azure Pack et configurez-le pour communiquer avec SPF :

Installer Windows Azure Pack (dans cette rubrique)

 Configurer Windows Azure Pack (dans cette rubrique)

4. Créez un ou plusieurs plans d’hébergement dans Windows Azure Pack pour

permettre aux locataires d’accéder à vos clouds de machine virtuelle :

Créer un plan dans Windows Azure Pack (dans cette rubrique)

Installer Microsoft Azure Pack

Installez et configurez Windows Azure Pack (WAP) sur l’ordinateur où vous souhaitez
héberger le portail web pour vos locataires. Cette machine doit être en mesure
d’atteindre le serveur SPF et d’être accessible par vos locataires.

1. Passez en revue la configuration système requise pour WAP et installez le logiciel

requis.

2. Téléchargez et exécutez Web Platform Installer . Si l’ordinateur n’est pas connecté

à Internet, suivez les instructions d’installation hors connexion.

3. Ouvrez web Platform Installer et recherchez Windows Azure Pack : Portal et API
Express sous l’onglet Produits. Cliquez sur Ajouter, puis sur Installer en bas de la
fenêtre.

4. Procédez à l’installation. Une fois l’installation terminée, le site de configuration

([Link] s’ouvre dans votre navigateur web. Sur ce site web,
fournissez des informations sur votre serveur SQL et terminez la configuration de
WAP.

Pour obtenir de l’aide sur la configuration de Windows Azure Pack, consultez Installer un
déploiement express de Windows Azure Pack.

７ Notes

Si vous exécutez déjà Windows Azure Pack dans votre environnement, vous pouvez
utiliser votre installation existante. Pour utiliser les dernières fonctionnalités de
machine virtuelle protégée, vous devez mettre à niveau votre installation vers au
moins Update Rollup 10.

Configurer Windows Azure Pack

Avant d’utiliser Windows Azure Pack, vous devez déjà l’installer et le configurer pour
votre infrastructure.
 1. Accédez au portail d’administration Windows Azure Pack sur [Link]
wapserver>:30091, puis connectez-vous à l’aide de vos informations
d’identification d’administrateur.

2. Dans le volet gauche, cliquez sur Options VM.

3. Connectez Windows Azure Pack à l’instance Service Provider Foundation en

cliquant sur Inscrire System Center Service Provider Foundation. Vous devez
spécifier l’URL de Service Provider Foundation, ainsi qu’un nom d’utilisateur et un
mot de passe.

4. Une fois terminé, vous devez être en mesure de voir les clouds de machines
virtuelles configurés dans votre environnement VMM. Assurez-vous d’avoir au
moins un cloud de machine virtuelle qui prend en charge les machines virtuelles
protégées disponibles pour WAP avant de continuer.

Créer un plan dans Windows Azure Pack

Pour permettre aux locataires de créer des machines virtuelles dans WAP, vous devez
d’abord créer un plan d’hébergement auquel les locataires peuvent s’abonner. Les plans
définissent les clouds de machines virtuelles, les modèles, les réseaux et les entités de
facturation autorisés pour vos locataires.

1. Dans le volet inférieur du portail, cliquez sur +NOUVEAU>PLAN>CRÉER UN

PLAN.

2. Dans la première étape de l’Assistant, choisissez un nom pour votre plan. Il s’agit
du nom que vos locataires verront lors de l’inscription.

3. Dans la deuxième étape, sélectionnez CLOUDS DE MACHINE VIRTUELLE comme

l’un des services à offrir dans le plan.

4. Ignorez l’étape sur la sélection des modules complémentaires pour le plan.

5. Cliquez sur OK (coché) pour créer le plan. Bien que cela crée le plan, il n’est pas
encore dans un état configuré.

6. Pour commencer à configurer le plan, cliquez sur son nom.

7. Dans la page suivante, sous Services de plan, cliquez sur Clouds de machine
virtuelle. Cette opération ouvre la page dans laquelle vous pouvez configurer des
quotas pour ce plan.

8. Sous De base, sélectionnez le serveur d’administration VMM et le cloud de

machine virtuelle que vous souhaitez offrir à vos locataires. Les clouds qui peuvent
offrir des machines virtuelles protégées s’affichent avec (protection prise en
charge) en regard de leur nom.

9. Sélectionnez les quotas que vous souhaitez appliquer dans ce plan. (Par exemple,
les limites relatives à l’utilisation du cœur du processeur et de la RAM). Veillez à ce
que la case Autoriser les Machines Virtuelles à être protégées soit sélectionnée.
10. Faites défiler jusqu’à la section intitulée Modèles, puis sélectionnez un ou plusieurs
modèles à proposer à vos locataires. Vous pouvez offrir des modèles protégés et
non protégés aux locataires, mais un modèle protégé doit être proposé pour
donner aux locataires des garanties de bout en bout sur l’intégrité de la machine
virtuelle et de leurs secrets.

11. Dans la section Réseaux, ajoutez un ou plusieurs réseaux pour vos locataires.

12. Après avoir défini d’autres paramètres ou quotas pour le plan, cliquez sur
Enregistrer en bas.

13. En haut à gauche de l’écran, cliquez sur la flèche pour revenir à la page Plan.

14. En bas de l’écran, remplacez le plan de Privé par Public afin que les locataires
puissent s’y abonner.

À ce stade, Windows Azure Pack est configuré et les locataires peuvent s’abonner
au plan que vous venez de créer et déployer des machines virtuelles protégées.
Pour connaître les étapes supplémentaires que les locataires doivent effectuer,
consultez Machines virtuelles protégées pour les locataires - Déploiement d’une
machine virtuelle protégée à l’aide de Windows Azure Pack.
Références supplémentaires
Étapes de configuration du fournisseur de services d’hébergement pour les hôtes
Service Guardian et les machines virtuelles dotées d’une protection maximale
Structure protégée et machines virtuelles dotées d’une protection maximale
Créer un fichier de réponses de
spécialisation du système d’exploitation
Article • 12/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

En préparation du déploiement de machines virtuelles dotées d’une protection

maximale, vous devrez peut-être créer un fichier de réponses de spécialisation du
système d’exploitation. Sur Windows, il s’agit généralement du fichier « [Link] ».
La fonction New-ShieldingDataAnswerFile de Windows PowerShell vous aide à
effectuer cette opération. Vous pouvez ensuite utiliser le fichier de réponses lorsque
vous créez des machines virtuelles dotées d’une protection maximale à partir d’un
modèle à l’aide de System Center Virtual Machine Manager (ou d’un autre contrôleur de
structure).

Pour obtenir des instructions générales sur les fichiers sans assistance pour les machines
virtuelles dotées d’une protection maximale, consultez Créer un fichier de réponses.

Téléchargement de la fonction New-

ShieldingDataAnswerFile
Vous pouvez obtenir la fonction New-ShieldingDataAnswerFile à partir de PowerShell
Gallery . Si votre ordinateur dispose d’une connectivité Internet, vous pouvez l’installer
à partir de PowerShell avec la commande suivante :

PowerShell

Install-Module GuardedFabricTools -Repository PSGallery -MinimumVersion

1.0.0

La sortie [Link] peut être empaquetée dans les données de protection, ainsi que
d’autres artefacts, afin qu’elle puisse être utilisée pour créer des machines virtuelles
protégées à partir de modèles.

Les sections suivantes montrent comment utiliser les paramètres de fonction pour un
fichier [Link] contenant différentes options :

Fichier de réponses Windows de base

Fichier de réponses Windows avec jointure de domaine
 Fichier de réponses Windows avec des adresses IPv4 statiques
Fichier de réponses Windows avec des paramètres régionaux personnalisés
Fichier de réponses Linux de base

Fichier de réponses Windows de base

Les commandes suivantes créent un fichier de réponses Windows qui définit
simplement le mot de passe et le nom d’hôte du compte d’administrateur. Les cartes
réseau de machine virtuelle utilisent DHCP pour obtenir des adresses IP et la machine
virtuelle ne sera pas jointe à un domaine Active Directory. Lorsque vous êtes invité à
entrer des informations d’identification d’administrateur, spécifiez le nom d’utilisateur et
le mot de passe souhaités. Utilisez « Administrateur » pour le nom d’utilisateur si vous
souhaitez configurer le compte Administrateur intégré.

PowerShell

$adminCred = Get-Credential -Message "Local administrator account"

New-ShieldingDataAnswerFile -Path '.\[Link]' -

AdminCredentials $adminCred

Fichier de réponses Windows avec jointure de

domaine
Les commandes suivantes créent un fichier de réponses Windows qui joint la machine
virtuelle protégée à un domaine Active Directory. Les cartes réseau de machine virtuelle
utilisent DHCP pour obtenir des adresses IP.

La première invite d’informations d’identification demande les informations du compte

d’administrateur local. Utilisez « Administrateur » pour le nom d’utilisateur si vous
souhaitez configurer le compte Administrateur intégré.

La deuxième invite d’informations d’identification demande des informations

d’identification qui ont l’autorisation de joindre l’ordinateur au domaine Active
Directory.

Veillez à remplacer la valeur du paramètre « -DomainName » par le nom de domaine

complet de votre domaine Active Directory.

PowerShell
 $adminCred = Get-Credential -Message "Local administrator account"
$domainCred = Get-Credential -Message "Domain join credentials"

New-ShieldingDataAnswerFile -Path '.\[Link]' -

AdminCredentials $adminCred -DomainName '[Link]' -
DomainJoinCredentials $domainCred

Fichier de réponses Windows avec des adresses

IPv4 statiques
Les commandes suivantes créent un fichier de réponses Windows qui utilise des
adresses IP statiques fournies au moment du déploiement par le gestionnaire de
structure, comme System Center Virtual Machine Manager.

Virtual Machine Manager fournit trois composants à l’adresse IP statique à l’aide d’un
pool d’adresses IP : adresse IPv4, adresse IPv6, adresse de passerelle et adresse DNS. Si
vous souhaitez inclure des champs supplémentaires ou exiger une configuration réseau
personnalisée, vous devez modifier manuellement le fichier de réponses produit par le
script.

Les captures d’écran suivantes montrent les pools IP que vous pouvez configurer dans
Virtual Machine Manager. Ces pools sont nécessaires si vous souhaitez utiliser une
adresse IP statique.

Actuellement, la fonction ne prend en charge qu’un seul serveur DNS. Voici à quoi
ressemblent vos paramètres DNS :
Voici à quoi ressemble votre résumé pour la création du pool d’adresses IP statiques. En
bref, vous ne devez avoir qu’une seule route réseau, une passerelle et un serveur DNS,
et vous devez spécifier votre adresse IP.
Vous devez configurer votre carte réseau pour votre machine virtuelle. La capture
d’écran suivante montre où définir cette configuration et comment la basculer vers une
adresse IP statique.
Ensuite, vous pouvez utiliser le paramètre -StaticIPPool pour inclure les éléments IP
statiques dans le fichier de réponses. Les paramètres @IPAddr-1@ , @NextHop-1-1@ et
@DNSAddr-1-1@ dans le fichier de réponses sont ensuite remplacés par les valeurs réelles

que vous avez spécifiées dans Virtual Machine Manager au moment du déploiement.

PowerShell

$adminCred = Get-Credential -Message "Local administrator account"

New-ShieldingDataAnswerFile -Path '.\[Link]' -

AdminCredentials $adminCred -StaticIPPool IPv4Address

Fichier de réponses Windows avec des

paramètres régionaux personnalisés
Les commandes suivantes créent un fichier de réponses Windows avec des paramètres
régionaux personnalisés.

Lorsque vous êtes invité à entrer des informations d’identification d’administrateur,

spécifiez le nom d’utilisateur et le mot de passe souhaités. Utilisez « Administrateur »
pour le nom d’utilisateur si vous souhaitez configurer le compte Administrateur intégré.

PowerShell

$adminCred = Get-Credential -Message "Local administrator account"

$domainCred = Get-Credential -Message "Domain join credentials"

New-ShieldingDataAnswerFile -Path '.\[Link]' -

AdminCredentials $adminCred -Locale es-ES

Fichier de réponses Linux de base

À compter de Windows Server version 1709, vous pouvez exécuter certains systèmes
d’exploitation invités Linux dans des machines virtuelles dotées d’une protection
maximale. Si vous utilisez l’agent Linux System Center Virtual Machine Manager pour
spécialiser ces machines virtuelles, le cmdlet de New-ShieldingDataAnswerFile peut
créer des fichiers de réponses compatibles pour celui-ci.

Dans un fichier de réponses Linux, vous incluez généralement le mot de passe racine, la
clé SSH racine et éventuellement les informations de pool IP statiques. Remplacez le
chemin d’accès à la moitié publique de votre clé SSH avant d’exécuter le script ci-
dessous.

PowerShell

$rootPassword = Read-Host -Prompt "Root password" -AsSecureString

New-ShieldingDataAnswerFile -Path '.\[Link]' -RootPassword

$rootPassword -RootSshKey '~\.ssh\id_rsa.pub'

Références supplémentaires
Déployer des machines virtuelles protégées
Structure protégée et machines virtuelles dotées d’une protection maximale
Machines virtuelles dotées d’une
protection maximale pour les locataires
- Création de données de protection
maximale pour définir une VM dotée
d’une protection maximale
Article • 09/03/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Un fichier de données de protection (également appelé « fichier de données

d’approvisionnement » ou « fichier PDK ») est un fichier chiffré créé par un locataire ou
un propriétaire de machine virtuelle pour protéger les informations clés de
configuration de la machine virtuelle, telles que le mot de passe de l’administrateur, les
certificats RDP et autres certificats liés aux identités, les informations d’identification de
jonction de domaine, etc. Cette rubrique fournit des informations sur la création d’un
fichier de données de protection. Avant de pouvoir créer le fichier, vous devez obtenir
un disque de modèle auprès de votre fournisseur de services d’hébergement, ou créer
un disque de modèle comme décrit dans Machines virtuelles dotées d’une protection
maximale pour les locataires - Création d’un disque de modèle (facultatif).

Pour obtenir la liste et le diagramme du contenu d’un fichier de données de protection,

consultez En quoi consistent les données de protection et pourquoi sont-elles
nécessaires ?.

） Important

Les étapes de cette section doivent être effectuées sur une machine de confiance
séparée, en dehors de la structure de protection maximale. En règle générale, le
propriétaire VM (locataire) crée les données de protection pour ses machines
virtuelles, et non les administrateurs de structure.

Pour préparer la création d’un fichier de données de protection, effectuez les étapes
suivantes :

Obtenir un certificat pour la connexion Bureau à distance

Créer un fichier de réponses
Obtenir le fichier du catalogue de signatures de volume
 Sélectionner des structures approuvées

Vous pouvez ensuite créer le fichier de données de protection :

Créer un fichier de données de protection et ajouter des gardiens

(Facultatif) Obtenir un certificat pour la

connexion Bureau à distance
Comme les locataires peuvent uniquement se connecter à leurs machines virtuelles
dotées d’une protection maximale en utilisant une connexion Bureau à distance ou
d’autres outils de gestion à distance, les locataires doivent pouvoir vérifier qu’ils se
connectent au bon point de terminaison (autrement dit, qu’il n’y a pas de « man in the
middle » interceptant la connexion).

Pour vérifier que vous vous connectez au serveur prévu, vous pouvez installer et
configurer un certificat que les services Bureau à distance doivent présenter quand vous
lancez une connexion. La machine cliente qui se connecte au serveur vérifie si elle
approuve le certificat et affiche un avertissement si ce n’est pas le cas. En règle générale,
pour que le client qui se connecte approuve le certificat, des certificats RDP sont émis à
partir de l’infrastructure PKI du locataire. Plus d’informations sur l’utilisation de
certificats dans les services Bureau à distance sont disponibles sur TechNet.

Pour vous aider à savoir si vous avez besoin d’un certificat RDP personnalisé, tenez
compte des éléments suivants :

Si vous testez simplement les machines virtuelles dotées d’une protection

maximale dans un environnement lab, vous n’avez pas besoin d’un certificat RDP
personnalisé.
Si votre machine virtuelle est configurée pour rejoindre un domaine Active
Directory, un certificat d’ordinateur est généralement émis automatiquement par
l’autorité de certification de votre organisation et utilisé pour identifier l’ordinateur
pendant les connexions RDP. Vous n’avez pas besoin d’un certificat RDP
personnalisé.
Si votre machine virtuelle n’est pas jointe à un domaine, mais que vous voulez un
moyen de vérifier que vous vous connectez à la machine appropriée quand vous
utilisez les services Bureau à distance, vous devez utiliser des certificats RDP
personnalisés.

 Conseil
 Quand vous sélectionnez un certificat RDP à ajouter à votre fichier de données de
protection, veillez à utiliser un certificat générique. Avec un seul fichier de données
de protection, vous pouvez créer un nombre illimité de machines virtuelles. Comme
chaque machine virtuelle partage le même certificat, un certificat générique
garantit la validité du certificat, quel que soit le nom d’hôte de la machine virtuelle.

Créer un fichier de réponses

Comme le disque de modèle signé dans VMM est généralisé, les locataires doivent
fournir un fichier de réponses pour spécialiser leurs machines virtuelles dotées d’une
protection maximale pendant le processus de provisionnement. Le fichier de réponses
(souvent appelé fichier d’installation sans assistance) peut configurer la machine
virtuelle pour son rôle prévu, c’est-à-dire installer des fonctionnalités Windows, inscrire
le certificat RDP créé à l’étape précédente et effectuer d’autres actions personnalisées. Il
fournit également les informations nécessaires pour la configuration de Windows,
notamment le mot de passe de l’administrateur par défaut et la clé de produit.

Pour plus d’informations sur l’obtention et l’utilisation de la fonction New-

ShieldingDataAnswerFile afin de générer un fichier de réponses (fichier [Link])
permettant de créer des machines virtuelles dotées d’une protection maximale,
consultez Générer un fichier de réponses en utilisant la fonction New-
ShieldingDataAnswerFile. Avec la fonction, vous pouvez générer plus facilement un
fichier de réponses qui reflète les choix suivants :

La machine virtuelle sera-t-elle jointe à un domaine à la fin du processus

d’initialisation ?
Utiliserez-vous une licence en volume ou une clé de produit spécifique par
machine virtuelle ?
Utilisez-vous DHCP ou une IP statique ?
Utiliserez-vous un certificat RDP (Remote Desktop Protocol) personnalisé pour
prouver que la machine virtuelle appartient à votre organisation ?
Voulez-vous exécuter un script à la fin de l’initialisation ?

Les fichiers de réponses utilisés dans les fichiers de données de protection sont utilisés
sur chaque machine virtuelle créée à partir de ce fichier de données de protection. Par
conséquent, vous devez veiller à ne coder en dur aucune information propre à la
machine virtuelle dans le fichier de réponses. VMM prend en charge certaines chaînes
de substitution (voir le tableau ci-dessous) dans le fichier d’installation sans assistance
pour gérer les valeurs de spécialisation qui peuvent changer d’une machine virtuelle à
l’autre. Vous n’êtes pas obligé de vous en servir. Toutefois, si elles sont présentes, VMM
les utilise.
Pendant la création d’un fichier [Link] pour les machines virtuelles dotées d’une
protection maximale, gardez à l’esprit les restrictions suivantes :

Si vous utilisez VMM pour gérer votre centre de données, le fichier d’installation
sans assistance doit entraîner la désactivation de la machine virtuelle après sa
configuration. Cela doit permettre à VMM de savoir quand il doit signaler au
locataire que le provisionnement de la machine virtuelle est terminé et qu’il peut
l’utiliser. VMM réactive automatiquement la machine virtuelle dès qu’il détecte
qu’elle a été désactivée pendant le provisionnement.

Veillez à activer RDP et la règle de pare-feu correspondante afin de pouvoir

accéder à la machine virtuelle une fois qu’elle a été configurée. Vous ne pouvez
pas utiliser la console VMM pour accéder aux machines virtuelles dotées d’une
protection maximale. Vous avez donc besoin de RDP pour vous connecter à votre
machine virtuelle. Si vous préférez gérer vos systèmes avec l’accès à distance
Windows PowerShell, vérifiez que WinRM est également activé.

Les seules chaînes de substitution prises en charge dans les fichiers d’installation
sans assistance de machine virtuelle dotée d’une protection maximale sont les
suivantes :

Élément remplaçable Chaîne de substitution

ComputerName @ComputerName@

TimeZone @TimeZone@

ProductKey @ProductKey@

IPAddr4-1 @IP4Addr-1@

IPAddr6-1 @IP6Addr-1@

MACAddr-1 @MACAddr-1@

Prefix-1-1 @Prefix-1-1@

NextHop-1-1 @NextHop-1-1@

Prefix-1-2 @Prefix-1-2@

NextHop-1-2 @NextHop-1-2@

Si vous avez plusieurs cartes réseau, vous pouvez ajouter plusieurs chaînes de
substitution pour la configuration IP en incrémentant le premier chiffre. Par
exemple, pour définir l’adresse IPv4, le sous-réseau et la passerelle pour 2 cartes
réseau, vous devez utiliser les chaînes de substitution suivantes :
 Chaîne de substitution Exemple de substitution

@IP4Addr-1@ [Link]/24

@MACAddr-1@ Ethernet

@Prefix-1-1@ 24

@NextHop-1-1@ [Link]

@IP4Addr-2@ [Link]/24

@MACAddr-2@ Ethernet 2

@Prefix-2-1@ 24

@NextHop-2-1@ [Link]

Quand vous utilisez des chaînes de substitution, vérifiez que les chaînes sont remplies
pendant le processus de provisionnement VM. Si une chaîne comme @ProductKey@
n’est pas fournie au moment du déploiement, laissant le nœud <ProductKey> vide dans
le fichier d’installation sans assistance, le processus de spécialisation échoue et vous ne
pouvez pas vous connecter à votre machine virtuelle.

Notez également que les chaînes de substitution liées au réseau à la fin du tableau sont
utilisées seulement si vous utilisez des pools d’adresses IP statiques VMM. Votre
fournisseur de services d’hébergement doit être en mesure de vous indiquer si ces
chaînes de substitution sont nécessaires. Pour plus d’informations sur les adresses IP
statiques dans les modèles VMM, consultez les éléments suivants dans la
documentation VMM :

Instructions pour les pools d’adresses IP

Configurer des pools d’adresses IP statiques dans l’infrastructure VMM

Enfin, notez que le processus de déploiement de machine virtuelle dotée d’une

protection maximale chiffre uniquement le lecteur de système d’exploitation. Si vous
déployez une machine virtuelle dotée d’une protection maximale avec un ou plusieurs
lecteurs de données, nous vous recommandons vivement d’ajouter une commande
d’installation sans assistance ou un paramètre de stratégie de groupe dans le domaine
du locataire pour chiffrer automatiquement les lecteurs de données.

Obtenir le fichier du catalogue de signatures de

volume
Les fichiers de données de protection contiennent également des informations sur les
disques de modèle auxquels un locataire fait confiance. Les locataires acquièrent les
signatures de disque des disques de modèle approuvés sous la forme d’un fichier VSC
(Volume Signature Catalog). Ces signatures sont ensuite validées quand une nouvelle
machine virtuelle est déployée. Si aucune des signatures du fichier de données de
protection ne correspond au disque de modèle qui tente d’être déployé avec la machine
virtuelle (c’est-à-dire qu’il a été modifié ou échangé avec un autre disque
potentiellement malveillant), le processus de provisionnement échoue.

） Important

Bien que le fichier VSC garantisse qu’un disque n’a pas été falsifié, le locataire doit
toujours approuver le disque en premier lieu. Si vous êtes le locataire et que le
disque de modèle est fourni par votre hébergeur, déployez une machine virtuelle
de test en utilisant ce disque de modèle et exécutez vos propres outils (antivirus,
analyseurs de vulnérabilité, etc.) pour vérifier que le disque est, effectivement, dans
un état fiable.

Il existe deux façons d’acquérir le VSC d’un disque de modèle :

1. L’hébergeur (ou le locataire, s’il a accès à VMM) utilise les applets de commande
PowerShell VMM pour enregistrer le VSC et le donne au locataire. Cette opération
peut être effectuée sur n’importe quelle machine où la console VMM est installée
et configurée pour gérer l’environnement VMM de la structure d’hébergement. Les
applets de commande PowerShell pour enregistrer le VSC sont les suivantes :

PowerShell

$disk = Get-SCVirtualHardDisk -Name "[Link]"

$vsc = Get-SCVolumeSignatureCatalog -VirtualHardDisk $disk

$[Link](".\[Link]")

2. Le locataire a accès au fichier de disque de modèle. Cela peut être le cas si le

locataire crée un disque de modèle pour le charger vers un fournisseur de services
d’hébergement ou si le locataire peut télécharger le disque de modèle de
l’hébergeur. Dans ce cas, sans VMM dans le paysage, le locataire exécute l’applet
de commande suivante (installée avec la fonctionnalité Outils de machine virtuelle
dotée d’une protection maximale, qui fait partie des Outils d’administration de
serveur distant) :
 PowerShell

Save-VolumeSignatureCatalog -TemplateDiskPath [Link] -

VolumeSignatureCatalogPath [Link]

Sélectionner des structures approuvées

Le dernier composant du fichier de données de protection concerne le propriétaire et
les gardiens d’une machine virtuelle. Les gardiens sont utilisés pour désigner à la fois le
propriétaire d’une machine virtuelle dotée d’une protection maximale et les structures
protégées sur lesquelles elle est autorisée à s’exécuter.

Pour autoriser une structure d’hébergement à exécuter une machine virtuelle dotée
d’une protection maximale, vous devez obtenir les métadonnées du gardien sur le
service Guardian hôte du fournisseur de services d’hébergement. Souvent, le fournisseur
de services d’hébergement vous fournit ces métadonnées par le biais de ses outils de
gestion. Dans un scénario d’entreprise, vous pouvez avoir un accès direct pour obtenir
vous-même les métadonnées.

Vous ou votre fournisseur de services d’hébergement pouvez obtenir les métadonnées

du gardien sur SGH en effectuant une des actions suivantes :

Pour obtenir les métadonnées du gardien directement sur SGH, exécutez la

commande Windows PowerShell suivante, ou accédez au site web et enregistrez le
fichier XML qui s’affiche :

PowerShell

Invoke-WebRequest
'[Link]
07/[Link]' -OutFile .\[Link]

Obtenez les métadonnées du gardien dans VMM avec les applets de commande
VMM PowerShell :

PowerShell

$relecloudmetadata = Get-SCGuardianConfiguration
$[Link] | Out-File .\[Link] -
Encoding UTF8

Obtenez les fichiers de métadonnées du gardien pour chaque structure protégée sur
laquelle vous voulez autoriser l’exécution de vos machines virtuelles dotées d’une
protection maximale avant de continuer.

Créer un fichier de données de protection et

ajouter des gardiens avec l’Assistant Fichier de
données de protection
Exécutez l’Assistant Fichier de données de protection pour créer un fichier de données
de protection (PDK). Ici, vous ajoutez le certificat RDP, le fichier d’installation sans
assistance, les catalogues de signatures de volume, le gardien propriétaire et les
métadonnées de gardien téléchargées obtenues à l’étape précédente.

1. Installez Outils d’administration de serveur distant> Outils d’administration des

fonctionnalités > Outils de machine virtuelle dotée d’une protection maximale
sur votre machine en utilisant le Gestionnaire de serveur ou la commande
Windows PowerShell suivante :

PowerShell

Install-WindowsFeature RSAT-Shielded-VM-Tools

2. Ouvrez l’Assistant Fichier de données de protection à partir de la section Outils

d’administration de votre menu Démarrer ou lancez l’exécutable suivant
C:\Windows\System32\[Link].

3. Dans la première page, utilisez la deuxième zone de sélection de fichier pour

choisir un emplacement et un nom de fichier pour votre fichier de données de
protection. Normalement, vous devez nommer le fichier de données de protection
à partir du nom de l’entité qui possède toutes les machines virtuelles créées avec
ces données de protection (par exemple, HR, IT, Finance) et du rôle de charge de
travail qu’elle exécute (par exemple, serveur de fichiers, serveur web ou tout autre
élément configuré par le fichier d’installation sans assistance). Laissez la case
d’option définie sur Données de protection pour les modèles avec protection
maximale.

７ Notes

Dans l’Assistant Fichier de données de protection, vous pouvez voir les deux
options ci-dessous :

Données de protection pour les modèles avec protection maximale

 Données de protection pour les machines virtuelles existantes et les
modèles sans protection maximale
La première option est utilisée pour créer des machines virtuelles dotées
d’une protection maximale à partir de modèles avec protection
maximale. La deuxième option vous permet de créer des données de
protection qui peuvent seulement être utilisées en cas de conversion de
machines virtuelles existantes ou de création de machines virtuelles
dotées d’une protection maximale à partir de modèles sans protection
maximale.

Par ailleurs, vous devez choisir si les machines virtuelles créées à partir de ce fichier
de données de protection ont réellement une protection maximale ou sont
configurées en mode « chiffrement pris en charge ». Pour plus d’informations sur
ces deux options, consultez Quels sont les types de machine virtuelle qu’une
structure protégée peut exécuter ?.

） Important

Portez une attention particulière à l’étape suivante, car elle définit le

propriétaire de vos machines virtuelles dotées d’une protection maximale et
les structures sur lesquelles elles sont autorisées à s’exécuter.
 La possession du gardien propriétaire est nécessaire pour passer par la suite
une machine virtuelle existante dotée d’une protection maximale de l’état
Protection maximale à Chiffrement pris en charge ou vice-versa.

4. Votre objectif dans cette étape est double :

Créer ou sélectionner un gardien propriétaire qui vous représente en tant que

propriétaire de la machine virtuelle

Importer le gardien que vous avez téléchargé à partir du service Guardian

hôte du fournisseur d’hébergement (ou le vôtre) à l’étape précédente

Pour désigner un gardien propriétaire existant, sélectionnez le gardien approprié

dans le menu déroulant. Seuls les gardiens installés sur votre machine locale avec
les clés privées intactes s’affichent dans cette liste. Pour créer votre propre gardien
propriétaire, sélectionnez Gérer les gardiens locaux en bas à droite, puis cliquez
sur Créer et terminez l’Assistant.

Ensuite, nous réimportons les métadonnées du gardien téléchargées

précédemment en utilisant la page Propriétaire et gardiens. Sélectionnez Gérer les
gardiens locaux en bas à droite. Utilisez la fonctionnalité Importer pour importer
le fichier de métadonnées du gardien. Cliquez sur OK dès que vous avez importé
ou ajouté tous les gardiens nécessaires. Une bonne pratique est de nommer les
gardiens à partir du nom du fournisseur de services d’hébergement ou du centre
de données d’entreprise qu’ils représentent. Enfin, sélectionnez tous les gardiens
qui représentent les centres de données dans lesquels votre machine virtuelle
dotée d’une protection maximale est autorisée à s’exécuter. Vous n’avez pas
besoin de resélectionner le gardien propriétaire. Cliquez sur Suivant une fois que
vous avez terminé.

5. Dans la page Qualificateurs d’ID de volume, cliquez sur Ajouter pour autoriser un
disque de modèle signé dans votre fichier de données de protection. Quand vous
sélectionnez un VSC dans la boîte de dialogue, il affiche des informations sur le
 nom de ce disque, sa version et le certificat utilisé pour le signer. Répétez ce
processus pour chaque disque de modèle que vous souhaitez autoriser.

6. Dans la page Valeurs de spécialisation, cliquez sur Parcourir pour sélectionner

votre fichier [Link] utilisé pour spécialiser vos machines virtuelles.

Utilisez le bouton Ajouter en bas pour ajouter au fichier PDK les fichiers
supplémentaires nécessaires pendant le processus de spécialisation. Par exemple,
si votre fichier d’installation sans assistance installe un certificat RDP sur la machine
virtuelle (comme décrit dans Générer un fichier de réponses en utilisant la fonction
New-ShieldingDataAnswerFile), vous devez ajouter ici le fichier PFX du certificat
RDP et le script RDPCertificateConfig.ps1. Notez que tous les fichiers que vous
spécifiez ici sont automatiquement copiés dans C:\temp\ sur la machine virtuelle
créée. Votre fichier d’installation sans assistance suppose que les fichiers se
trouvent dans ce dossier quand il les référence par leur chemin.

7. Passez en revue vos sélections dans la page suivante, puis cliquez sur Générer.

8. Fermez l’Assistant une fois qu’il est terminé.

Créer un fichier de données de protection et

ajouter des gardiens en utilisant PowerShell
Au lieu d’utiliser l’Assistant Fichier de données de protection, vous pouvez exécuter
New-ShieldingDataFile pour créer un fichier de données de protection.

Tous les fichiers de données de protection doivent être configurés avec les certificats de
propriétaire et de gardien appropriés afin d’autoriser l’exécution de vos machines
virtuelles dotées d’une protection maximale sur une structure protégée. Vous pouvez
vérifier si des gardiens sont installés localement en exécutant Get-HgsGuardian. Les
gardiens propriétaires ont des clés privées, contrairement aux gardiens de votre centre
de données.

Si vous devez créer un gardien propriétaire, exécutez la commande suivante :

PowerShell

New-HgsGuardian -Name "Owner" -GenerateCertificates

Cette commande crée une paire de certificats de signature et de chiffrement dans le

magasin de certificats de l’ordinateur local sous le dossier « Certificats locaux de
machine virtuelle dotée d’une protection maximale ». Vous avez besoin des certificats de
propriétaire et de leurs clés privées correspondantes pour annuler la protection
maximale d’une machine virtuelle. Vérifiez donc que ces certificats sont sauvegardés et
protégés contre le vol. Un attaquant ayant accès aux certificats de propriétaire peut les
utiliser pour démarrer votre machine virtuelle dotée d’une protection maximale ou
changer sa configuration de sécurité.

Si vous avez besoin d’importer des informations de gardien à partir d’une structure
protégée où vous souhaitez exécuter votre machine virtuelle (centre de données
principal, centres de données de sauvegarde, etc.), exécutez la commande suivante pour
chaque fichier de métadonnées récupéré à partir de vos structures protégées.

PowerShell

Import-HgsGuardian -Name 'EAST-US Datacenter' -Path '.\[Link]'

 Conseil

Si vous avez utilisé des certificats auto-signés ou que les certificats inscrits sur SGH
ont expiré, vous devez peut-être utiliser les indicateurs -AllowUntrustedRoot et/ou
-AllowExpired avec la commande Import-HgsGuardian pour contourner les

vérifications de sécurité.

Vous devez également obtenir un catalogue de signatures de volume pour chaque

disque de modèle que vous souhaitez utiliser avec ce fichier de données de protection,
et un fichier de réponses de données de protection pour permettre au système
d’exploitation d’effectuer automatiquement ses tâches de spécialisation. Enfin, décidez
si vous souhaitez que votre machine virtuelle soit dotée d’une protection maximale ou
uniquement sécurisée avec vTPM. Utilisez -Policy Shielded pour une machine virtuelle
dotée d’une protection maximale ou -Policy EncryptionSupported pour une machine
virtuelle sécurisée avec vTPM qui autorise les connexions de console de base et
PowerShell Direct.

Une fois que tout est prêt, exécutez la commande suivante pour créer votre fichier de
données de protection :

PowerShell

$viq = New-VolumeIDQualifier -VolumeSignatureCatalogFilePath

'C:\temp\[Link]' -VersionRule Equals
New-ShieldingDataFile -ShieldingDataFilePath "C:\temp\[Link]" -
Policy EncryptionSupported -Owner 'Owner' -Guardian 'EAST-US Datacenter' -
VolumeIDQualifier $viq -AnswerFile 'C:\temp\[Link]'
  Conseil

Si vous utilisez un certificat RDP personnalisé, des clés SSH ou d’autres fichiers qui
doivent être ajoutés à votre fichier de données de protection, utilisez le paramètre
-OtherFile pour les ajouter. Vous pouvez fournir une liste de chemins de fichier
séparés par des virgules, par exemple, -OtherFile "C:\source\[Link]",
"C:\source\RDPCertificateConfig.ps1"

Dans la commande ci-dessus, le gardien nommé « Owner » (obtenu à partir de Get-

HgsGuardian) peut changer la configuration de sécurité de la machine virtuelle par la
suite, tandis que « EAST-US Datacenter » peut exécuter la machine virtuelle, mais pas
changer ses paramètres. Si vous avez plusieurs gardiens, séparez leurs noms par des
virgules, par exemple, 'EAST-US Datacenter', 'EMEA Datacenter' . Le qualificateur d’ID
de volume spécifie si vous approuvez uniquement la version exacte (Equals) du disque
de modèle ou les versions futures (GreaterThanOrEquals) également. Le nom du disque
et le certificat de signature doivent correspondre exactement pour que la comparaison
de versions soit prise en compte au moment du déploiement. Vous pouvez approuver
plusieurs disques de modèle en fournissant au paramètre -VolumeIDQualifier une liste
séparée par des virgules de qualificateurs d’ID de volume. Enfin, si vous avez d’autres
fichiers qui doivent accompagner le fichier de réponses avec la machine virtuelle, utilisez
le paramètre -OtherFile et fournissez la liste des chemins de fichier séparés par des
virgules.

Consultez la documentation sur les applets de commande New-ShieldingDataFile et

New-VolumeIDQualifier pour en savoir plus sur les autres façons de configurer votre
fichier de données de protection.

Références supplémentaires
Déployer des machines virtuelles protégées
Structure protégée et machines virtuelles dotées d’une protection maximale
Créer une machine virtuelle dotée d’une
protection maximale à l’aide de
PowerShell
Article • 11/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

En production, vous utilisez généralement un gestionnaire d’infrastructure (par exemple,

VMM) pour déployer des machines virtuelles dotées d’une protection maximale.
Toutefois, les étapes illustrées ci-dessous vous permettent de déployer et de valider
l’ensemble du scénario sans gestionnaire de structure.

En résumé, vous allez créer un disque de modèle, un fichier de données de protection,

un fichier de réponses d’installation sans assistance et d’autres artefacts de sécurité sur
n’importe quelle machine, puis copier ces fichiers sur un hôte Service Guardian et
approvisionner la machine virtuelle dotée d’une protection maximale.

Créer un disque modèle signé

Pour créer une machine virtuelle dotée d’une protection maximale, vous avez d’abord
besoin d’un disque de modèle de machine virtuelle dotée d’une protection maximale
préchiffré avec son volume de système d’exploitation (ou ses partitions de démarrage et
racine sur Linux) signé. Suivez les liens ci-dessous pour plus d’informations sur la
création d’un disque de modèle.

Préparer un disque de modèle Windows

Préparer un disque de modèle Linux

Vous aurez également besoin d’une copie du catalogue de signatures de volume du

disque pour créer le fichier de données de protection. Pour enregistrer ce fichier,
exécutez la commande suivante sur l’ordinateur sur lequel vous avez créé le disque de
modèle :

PowerShell

Save-VolumeSignatureCatalog -TemplateDiskPath "C:\temp\[Link]"

-VolumeSignatureCatalogPath "C:\temp\[Link]"
Télécharger les métadonnées de Guardian
Pour chacune des infrastructures de virtualisation sur lesquelles vous souhaitez exécuter
votre machine virtuelle dotée d’une protection maximale, vous devez obtenir les
métadonnées de Guardian pour les clusters SGH de l’infrastructure. Votre fournisseur
d’hébergement devrait être en mesure de vous fournir ces informations.

Si vous êtes dans un environnement d’entreprise et que vous pouvez communiquer

avec le serveur SGH, les métadonnées du Guardian sont disponibles sur
[Link]

Créer un fichier PDK (données de protection)

Les données de protection sont créées et détenues par les propriétaires de machines
virtuelles client et contiennent les secrets nécessaires pour créer des machines virtuelles
dotées d’une protection maximale qui doivent être protégées par l’administrateur de
l’infrastructure, comme le mot de passe administrateur de la machine virtuelle dotée
d’une protection maximale. La protection des données est chiffrée de telle sorte que
seuls les serveurs SGH et le locataire peuvent les déchiffrer. Une fois créé par le
locataire/propriétaire de la machine virtuelle, le fichier PDK résultant doit être copié
dans l’infrastructure protégée. Pour plus d’informations, consultez Qu’est-ce que la
protection des données et pourquoi est-elle nécessaire ?.

En outre, vous aurez besoin d’un fichier de réponses d’installation sans assistance
([Link] pour Windows, varie pour Linux). Consultez Créer un fichier de réponses
pour obtenir des conseils sur les éléments à inclure dans le fichier de réponses.

Exécutez les cmdlets suivantes sur une machine sur laquelle les outils d’administration
de serveur distant pour machines virtuelles dotées d’une protection maximale sont
installés. Si vous créez un PDK pour une machine virtuelle Linux, vous devez le faire sur
un serveur exécutant Windows Server, version 1709 ou ultérieure.

PowerShell

# Create owner certificate, don't lose this!

# The certificate is stored at Cert:\LocalMachine\Shielded VM Local
Certificates
$Owner = New-HgsGuardian –Name 'Owner' –GenerateCertificates

# Import the HGS guardian for each fabric you want to run your shielded VM
$Guardian = Import-HgsGuardian -Path C:\[Link] -Name 'TestFabric'

# Create the PDK file

# The "Policy" parameter describes whether the admin can see the VM's
 console or not
# Use "EncryptionSupported" if you are testing out shielded VMs and want to
debug any issues during the specialization process
New-ShieldingDataFile -ShieldingDataFilePath 'C:\temp\[Link]' -Owner
$Owner –Guardian $guardian –VolumeIDQualifier (New-VolumeIDQualifier -
VolumeSignatureCatalogFilePath 'C:\temp\[Link]' -
VersionRule Equals) -WindowsUnattendFile 'C:\[Link]' -Policy Shielded

Provisionner une machine virtuelle dotée d’une

protection maximale sur un hôte Service
Guardian
Sur un hôte qui exécute Windows Server 2016, vous pouvez surveiller l’arrêt de la
machine virtuelle pour signaler l’achèvement de la tâche d’approvisionnement et
consulter les journaux des événements Hyper-V pour obtenir des informations sur les
erreurs si l’approvisionnement échoue.

Vous pouvez également créer un nouveau disque de modèle chaque fois avant de créer
une machine virtuelle dotée d’une protection maximale.

Copiez le fichier de disque du modèle ([Link]) et le fichier PDK ([Link])

sur l’hôte Service Guardian pour vous préparer au déploiement.

Sur l’hôte Service Guardian, installez le module PowerShell Guarded Fabric Tools, qui
contient la cmdlet New-ShieldedVM pour simplifier le processus d’approvisionnement.
Si votre hôte Service Guardian a accès à Internet, exécutez la commande suivante :

PowerShell

Install-Module GuardedFabricTools -Repository PSGallery -MinimumVersion

1.0.0

Vous pouvez également télécharger le module sur un autre ordinateur disposant d’un
accès à Internet et copier le module résultant dans C:\Program
Files\WindowsPowerShell\Modules sur l’hôte Service Guardian.

PowerShell

Save-Module GuardedFabricTools -Repository PSGallery -MinimumVersion 1.0.0 -

Path C:\temp\

Une fois le module installé, vous êtes prêt à approvisionner votre machine virtuelle
dotée d’une protection maximale.
 PowerShell

New-ShieldedVM -Name 'MyShieldedVM' -TemplateDiskPath

'C:\temp\[Link]' -ShieldingDataFilePath 'C:\temp\[Link]' -
Wait

Si votre fichier de réponses aux données de protection inclut des valeurs de

spécialisation, vous pouvez fournir les valeurs de remplacement à New-ShieldedVM.
Dans cet exemple, le fichier de réponses est configuré avec des valeurs d’espace réservé
pour une adresse IPv4 statique.

PowerShell

$specializationValues = @{
"@IP4Addr-1@" = "[Link]/24"
"@MacAddr-1@" = "Ethernet"
"@Prefix-1-1@" = "24"
"@NextHop-1-1@" = "[Link]"
}
New-ShieldedVM -Name 'MyStaticIPVM' -TemplateDiskPath
'C:\temp\[Link]' -ShieldingDataFilePath 'C:\temp\[Link]' -
SpecializationValues $specializationValues -Wait

Si votre disque de modèle contient un système d’exploitation Linux, incluez l’indicateur

-Linux lors de l’exécution de la commande :

PowerShell

New-ShieldedVM -Name 'MyLinuxVM' -TemplateDiskPath

'C:\temp\[Link]' -ShieldingDataFilePath 'C:\temp\[Link]' -
Wait -Linux

Consultez le contenu d’aide avec Get-Help New-ShieldedVM -Full pour en savoir plus sur
les autres options que vous pouvez passer à la cmdlet.

Une fois l’approvisionnement terminé, la machine virtuelle entre dans la phase de

spécialisation spécifique au système d’exploitation, après quoi elle est prête à être
utilisée. Veillez à connecter la machine virtuelle à un réseau valide afin de pouvoir vous y
connecter une fois qu’elle est en cours d’exécution (à l’aide de RDP, PowerShell, SSH ou
de votre outil de gestion préféré).

Exécution de machines virtuelles dotées d’une

protection maximale sur un cluster Hyper-V
Si vous essayez de déployer des machines virtuelles dotées d’une protection maximale
sur des hôtes protégés en cluster (à l’aide d’un cluster de basculement Windows), vous
pouvez configurer la machine virtuelle dotée d’une protection maximale pour qu’elle
soit hautement disponible à l’aide de la cmdlet suivante :

PowerShell

Add-ClusterVirtualMachineRole -VMName 'MyShieldedVM' -Cluster <Hyper-V

cluster name>

La machine virtuelle dotée d’une protection maximale peut désormais être migrée en
direct au sein du cluster.

Étape suivante
Déployer une machine virtuelle dotée d’une protection maximale à l’aide de VMM
Machines virtuelles dotées d’une
protection maximale pour les locataires
- Déploiement d’une machine virtuelle
dotée d’une protection maximale avec
Virtual Machine Manager
Article • 09/03/2023

Si vous avez accès à System Center 2016 - Virtual Machine Manager (VMM), vous
pouvez déployer une machine virtuelle dotée d’une protection maximale pour laquelle
un modèle de machine virtuelle dotée d’une protection maximale a déjà été créé.

Pour déployer une machine virtuelle dotée d’une protection maximale dans VMM,
utilisez les instructions de Provisionner une nouvelle machine virtuelle dotée d’une
protection maximale.

Références supplémentaires
Déployer des machines virtuelles protégées
Structure protégée et machines virtuelles dotées d’une protection maximale
Machines virtuelles dotées d’une
protection maximale pour les locataires
- Déploiement d’une machine virtuelle
dotée d’une protection maximale avec
Windows Azure Pack
Article • 11/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Si votre fournisseur de services d’hébergement le prend en charge, vous pouvez utiliser

Windows Azure Pack pour déployer une machine virtuelle protégée.

Suivez les étapes ci-dessous :

1. Abonnez-vous à un ou plusieurs plans proposés dans Windows Azure Pack.

2. Créez une machine virtuelle dotée d’une protection maximale à l’aide de Windows
Azure Pack.

Utilisez des machines virtuelles protégées, qui sont décrites dans les rubriques
suivantes :

Créez des données de protection (et chargez le fichier de données de

protection, comme décrit dans la deuxième procédure de la rubrique).

７ Notes

Dans le cadre de la création de données de protection, vous allez

télécharger votre fichier de clé Guardian, qui sera un fichier XML au
format UTF-8. Ne remplacez pas le fichier par UTF-16.

Créez une machine virtuelle protégée avec création rapide, via un modèle
protégé ou un modèle standard.

２ Avertissement

Si vous créez une machine virtuelle protégée à l’aide d’un modèle

standard, il est important de noter que la machine virtuelle est
 provisionnée sans protection. Cela signifie que le disque de modèle n’est
pas vérifié par rapport à la liste des disques approuvés dans votre fichier
de données de protection, et que les secrets de votre fichier de données
de protection ne sont pas utilisés pour approvisionner la machine
virtuelle. Si un modèle protégé est disponible, il est préférable de
déployer une machine virtuelle protégée avec un modèle protégé pour
fournir une protection de bout en bout de vos secrets.

Convertir une machine virtuelle de génération 2 en machine virtuelle

protégée

７ Notes

Si vous convertissez une machine virtuelle en machine virtuelle dotée

d’une protection maximale, les points de contrôle et les sauvegardes
existants ne seront pas chiffrés. Vous devez supprimer les anciens points
de contrôle lorsque cela est possible pour empêcher l’accès à vos
anciennes données déchiffrées.

Références supplémentaires
Étapes de configuration du fournisseur de services d’hébergement pour les hôtes
Service Guardian et les machines virtuelles dotées d’une protection maximale
Structure protégée et machines virtuelles dotées d’une protection maximale
Machines virtuelles dotées d’une
protection maximale : Préparation d’un
VHD d’assistance de protection de
machine virtuelle
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

） Important

Avant de commencer ces procédures, vérifiez que vous avez installé la dernière
mise à jour cumulative pour Windows Server 2016 ou que vous utilisez les derniers
Outils d’administration de serveur distant Windows 10. Sinon, les procédures ne
fonctionneront pas.

Cette section décrit les étapes effectuées par un fournisseur de services d’hébergement
pour activer la prise en charge de la conversion de machines virtuelles existantes en
machines virtuelles dotées d’une protection maximale.

Pour comprendre comment cette rubrique s’intègre dans le processus global de

déploiement de machines virtuelles dotées d’une protection maximale, consultez Étapes
de configuration du fournisseur de services d’hébergement pour les hôtes protégés et
les machines virtuelles dotées d’une protection maximale.

Quelles machines virtuelles peuvent être

protégées ?
Le processus de protection pour les machines virtuelles existantes est disponible
uniquement pour les machines virtuelles qui répondent aux conditions préalables
suivantes :

Le système d’exploitation invité est Windows Server 2012, 2012 R2, 2016 ou une
version Canal semi-annuel. Les machines virtuelles Linux existantes ne peuvent pas
être converties en machines virtuelles dotées d’une protection maximale.
La machine virtuelle est une machine virtuelle de génération 2 (microprogramme
UEFI)
 La machine virtuelle n’utilise pas de disques de différenciation pour son volume de
système d’exploitation.

Préparer le disque dur virtuel d’assistance

1. Sur un ordinateur sur lequel Hyper-V et la fonctionnalité Outils d’administration de
serveur distant sont installés, créez une machine virtuelle de nouvelle génération 2
avec un VHDX vide et installez-y Windows Server 2016 à l’aide du support
d’installation ISO de Windows Server. Cette machine virtuelle ne doit pas être
protégée et doit exécuter Server Core ou Server avec Expérience utilisateur.

） Important

Le disque dur virtuel d’assistance de protection de machine virtuelle ne doit

pas être lié aux disques de modèle que vous avez créés dans le Fournisseur
de services d’hébergement crée un modèle de machine virtuelle dotée
d'une protection maximale. Si vous réutilisez un disque de modèle, il y aura
une collision de signature de disque pendant le processus de protection, car
les deux disques auront le même identificateur de disque GPT. Vous pouvez
éviter cela en créant un disque dur virtuel (vide) et en y installant Windows
Server 2016 à l’aide de votre support d’installation ISO.

2. Démarrez la machine virtuelle, effectuez toutes les étapes d’installation et

connectez-vous au bureau. Une fois que vous avez vérifié que la machine virtuelle
est dans un état opérationnel, arrêtez la machine virtuelle.

3. Dans une fenêtre de Windows PowerShell avec élévation de privilèges, exécutez la

commande suivante pour préparer le VHDX créé précédemment pour devenir un
disque d’assistance de protection de la machine virtuelle. Mettez à jour le chemin
par le chemin correct pour votre projet.

PowerShell

Initialize-VMShieldingHelperVHD -Path 'C:\VHD\[Link]'

4. Une fois la commande terminée, copiez le VHDX dans votre partage de

bibliothèque VMM. Ne démarrez pas la machine virtuelle à partir de l’étape 1. Cela
endommagera le disque d’assistance.

5. Vous pouvez maintenant supprimer la machine virtuelle de l’étape 1 dans Hyper-V.

Configurer les paramètres du serveur Guardian
hôte VMM
Dans la console VMM, ouvrez le volet Paramètres, puis Paramètres de Service Guardian
hôte sous Général. En bas de cette fenêtre, un champ permet de configurer
l’emplacement de votre disque dur virtuel d’assistance. Utilisez le bouton Parcourir pour
sélectionner le disque dur virtuel à partir de votre partage de bibliothèque. Si vous ne
voyez pas votre disque dans le partage, vous devrez peut-être actualiser manuellement
la bibliothèque dans VMM pour qu’elle s’affiche.

Références supplémentaires
Étapes de configuration du fournisseur de services d’hébergement pour les hôtes
Service Guardian et les machines virtuelles dotées d’une protection maximale
Structure protégée et machines virtuelles dotées d’une protection maximale
Gestion d’une infrastructure protégée
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Les rubriques suivantes expliquent comment gérer une infrastructure protégée.

Gérer le Service Guardian hôte

Éléments à prendre en compte en matière de filiale

Références supplémentaires
Déploiement d’une infrastructure protégée
Configuration du service Guardian hôte
Article • 12/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Le service Guardian hôte (SGH) est la pièce centrale de la solution de structure protégée.
Il est chargé de s’assurer que les hôtes Hyper-V dans l’infrastructure sont connus de
l’hébergeur ou de l’entreprise et qu’ils exécutent des logiciels approuvés. Ils sont
également chargés de la gestion des clés utilisées pour démarrer des machines virtuelles
dotées d’une protection maximale. Lorsqu’un locataire décide de vous approuver pour
héberger ses machines virtuelles dotées d’une protection maximale, il fait confiance à
votre configuration et à la gestion du SGH. Par conséquent, il est très important de
suivre les meilleures pratiques lors de la gestion du SGH de sorte à garantir la sécurité,
la disponibilité et la fiabilité de votre structure protégée. Les conseils présentés dans les
sections suivantes traitent des problèmes opérationnels les plus courants auxquels sont
confrontés les administrateurs de SGH.

Limitation de l’accès administrateur au SGH

En raison de la nature sensible à la sécurité du SGH, il est important de s’assurer que ses
administrateurs sont des membres hautement approuvés de votre organisation et, dans
l’idéal, distincts des administrateurs de vos ressources de structure. En outre, il est
recommandé de gérer uniquement SGH à partir de stations de travail sécurisées à l’aide
de protocoles de communication sécurisés, tels que WinRM pour HTTPS.

Séparation des tâches

Lors de la configuration du SGH, vous avez la possibilité de créer une forêt
Active Directory isolée uniquement pour SGH ou de joindre le SGH à un domaine
approuvé existant. Cette décision, ainsi que les rôles que vous attribuez aux
administrateurs de votre organisation, déterminent la limite d’approbation pour le SGH.
Toute personne disposant d’un accès au SGH, que ce soit directement en tant
qu’administrateur ou indirectement en tant qu’administrateur d’un autre élément (p. ex.,
Active Directory) qui peut influencer le SGH, a le contrôle sur votre structure protégée.
Les administrateurs SGH choisissent quels hôtes Hyper-V sont autorisés à exécuter des
machines virtuelles dotées d’une protection maximale et à gérer les certificats
nécessaires au démarrage des machines virtuelles dotées d’une protection maximale. Un
attaquant ou un administrateur malveillant qui a accès au SGH peut utiliser cette
puissance pour autoriser des hôtes compromis à exécuter des machines virtuelles
dotées d’une protection maximale, lancer une attaque par déni de service en
supprimant des éléments de clé, etc.

Pour éviter ce risque, il est vivement recommandé de limiter le chevauchement entre les
administrateurs de votre SGH (y compris le domaine auquel SGH est joint) et les
environnements Hyper-V. En s’assurant qu’aucun administrateur n’a accès aux
deux systèmes, un attaquant devra compromettre deux comptes différents de
deux personnes pour modifier les stratégies SGH. Cela signifie également que les
administrateurs de domaine et d’entreprise pour les deux environnements
Active Directory ne doivent pas être la même personne et que SGH ne doit pas utiliser la
même forêt Active Directory que vos hôtes Hyper-V. Toute personne qui peut s’accorder
l’accès à davantage de ressources présente un risque pour la sécurité.

Utilisation de Just Enough Administration

SGH est fourni avec des rôles JEA (Just Enough Administration) intégrés pour vous aider
à le gérer de manière plus sécurisée. JEA vous permet de déléguer des tâches
d’administration à des utilisateurs qui ne sont pas administrateurs, ce qui signifie que les
personnes qui gèrent les stratégies SGH n’ont pas besoin d’être des administrateurs de
l’ensemble de la machine ou du domaine. JEA fonctionne en limitant les commandes
qu’un utilisateur peut exécuter dans une session PowerShell et en utilisant un compte
local temporaire en arrière-plan (unique pour chaque session utilisateur) pour exécuter
les commandes qui nécessitent normalement une élévation.

SGH est fourni avec les deux rôles JEA préconfigurés ci-dessous :

Administrateur SGH qui permet aux utilisateurs de gérer toutes les stratégies SGH,
y compris l’autorisation des nouveaux hôtes à exécuter des machines virtuelles
dotées d’une protection maximale.
Réviseur SGH qui autorise uniquement les utilisateurs à auditer les stratégies
existantes. Ils ne peuvent pas modifier la configuration de SGH.

Pour utiliser JEA, vous devez d’abord créer un utilisateur standard et en faire un membre
du groupe d’administrateurs ou de réviseurs SGH. Si vous avez l’habitude Install-
HgsServer de configurer une nouvelle forêt pour SGH, ces groupes sont nommés

respectivement « administrateurs nom_service » et « réviseurs nom_service », où

nom_service est le nom réseau du cluster SGH. Si vous avez joint SGH à un domaine
existant, vous devez faire référence aux noms de groupe que vous avez spécifiés dans
Initialize-HgsServer .

Création d’utilisateurs standard pour les rôles d’administrateur et de réviseur SGH

 PowerShell

$hgsServiceName = (Get-ClusterResource HgsClusterResource | Get-

ClusterParameter DnsName).Value
$adminGroup = $hgsServiceName + "Administrators"
$reviewerGroup = $hgsServiceName + "Reviewers"

New-ADUser -Name 'hgsadmin01' -AccountPassword (Read-Host -AsSecureString -

Prompt 'HGS Admin Password') -ChangePasswordAtLogon $false -Enabled $true
Add-ADGroupMember -Identity $adminGroup -Members 'hgsadmin01'

New-ADUser -Name 'hgsreviewer01' -AccountPassword (Read-Host -AsSecureString

-Prompt 'HGS Reviewer Password') -ChangePasswordAtLogon $false -Enabled
$true
Add-ADGroupMember -Identity $reviewerGroup -Members 'hgsreviewer01'

Audit des stratégies avec le rôle de réviseur

Sur une machine distante qui dispose d’une connectivité réseau au SGH, exécutez les
commandes suivantes dans PowerShell pour entrer la session JEA avec les informations
d’identification du réviseur. Il est important de noter que, étant donné que le compte
réviseur n’est qu’un utilisateur standard, il ne peut pas être utilisé pour la
communication à distance Windows PowerShell standard, l’accès Bureau à distance au
SGH, etc.

PowerShell

Enter-PSSession -ComputerName <hgsnode> -Credential

'<hgsdomain>\hgsreviewer01' -ConfigurationName '[Link]'

Vous pouvez ensuite vérifier les commandes autorisées dans la session avec Get-
Command et exécuter toutes les commandes autorisées pour auditer la configuration.

Dans l’exemple ci-dessous, nous vérifions quelles stratégies sont activées sur SGH.

PowerShell

Get-Command

Get-HgsAttestationPolicy

Saisissez la commande Exit-PSSession ou son alias, exit , lorsque vous avez terminé
d’utiliser la session JEA.

Ajout d’une nouvelle stratégie à SGH à l’aide du rôle administrateur

Pour modifier réellement une stratégie, vous devez vous connecter au point de
terminaison JEA avec une identité qui appartient au groupe « AdministrateursSGH ».
Dans l’exemple ci-dessous, nous montrons comment copier une nouvelle stratégie
d’intégrité du code dans SGH et l’inscrire à l’aide de JEA. La syntaxe peut être différente
de celle dont vous avez l’habitude. Cela permet de s’adapter à certaines des restrictions
de JEA, comme le fait de ne pas avoir accès au système de fichiers complet.

PowerShell

$cipolicy = Get-Item "C:\temp\cipolicy.p7b"

$session = New-PSSession -ComputerName <hgsnode> -Credential
'<hgsdomain>\hgsadmin01' -ConfigurationName '[Link]'
Copy-Item -Path $cipolicy -Destination 'User:' -ToSession $session

# Now that the file is copied, we enter the interactive session to register
it with HGS
Enter-PSSession -Session $session
Add-HgsAttestationCiPolicy -Name 'New CI Policy via JEA' -Path
'User:\cipolicy.p7b'

# Confirm it was added successfully

Get-HgsAttestationPolicy -PolicyType CiPolicy

# Finally, remove the PSSession since it is no longer needed

Exit-PSSession
Remove-PSSession -Session $session

Surveillance de SGH

Sources d’événements et transfert

Les événements de SGH s’affichent dans le journal des événements Windows sous
deux sources :

HostGuardianService-Attestation
HostGuardianService-KeyProtection

Vous pouvez afficher ces événements en ouvrant l’observateur d'événements et en

accédant à Microsoft-Windows-HostGuardianService-Attestation et Microsoft-Windows-
HostGuardianService-KeyProtection.

Dans un environnement volumineux, il est souvent préférable de transférer des

événements à un collecteur d’événements Windows central pour faciliter l’analyse des
événements. Pour plus d’informations, consultez la documentation sur le transfert
d’événements Windows.
Utilisation de System Center Operations Manager
Vous pouvez également utiliser System Center 2016 - Operations Manager pour
surveiller SGH et vos hôtes protégés. Le pack d’administration d’infrastructure protégée
dispose d’analyses d’événements pour vérifier les mauvaises configurations courantes
pouvant entraîner un temps d’arrêt du centre de données, y compris les hôtes ne
transmettant pas l’attestation et les serveurs SGH signalant des erreurs.

Pour commencer, installez et configurez SCOM 2016 et téléchargez le pack

d’administration d’infrastructure protégée . Le guide du pack d’administration inclus
explique comment configurer le pack d’administration et comprendre l’étendue de ses
moniteurs.

Sauvegarde et restauration de SGH

Planification de la récupération d’urgence

Lors de la rédaction de vos plans de récupération d’urgence, il est important de prendre
en compte les exigences uniques du service Guardian hôte dans votre infrastructure
protégée. Si vous perdez certains ou tous vos nœuds SGH, vous pouvez rencontrer des
problèmes de disponibilité immédiats qui empêchent les utilisateurs de démarrer leurs
machines virtuelles dotées d’une protection maximale. Dans un scénario où vous perdez
l’intégralité de votre cluster SGH, vous devez disposer de sauvegardes complètes de la
configuration SGH pour restaurer votre cluster SGH et reprendre les opérations
normales. Cette section décrit les étapes nécessaires à la préparation d’un tel scénario.

Tout d’abord, il est essentiel de comprendre ce qu’il est important de sauvegarder avec
SGH. SGH conserve plusieurs informations qui l’aident à déterminer quels hôtes sont
autorisés à exécuter des machines virtuelles dotées d’une protection maximale.
notamment :

1. Identificateurs de sécurité Active Directory pour les groupes contenant des hôtes
approuvés (lors de l’utilisation de l’attestation Active Directory)
2. Identificateurs de module de plateforme sécurisée (TPM) uniques pour chaque
hôte de votre environnement
3. Stratégies TPM pour chaque configuration unique de l’hôte
4. Stratégies d’intégrité du code qui déterminent les logiciels autorisés à s’exécuter
sur vos hôtes.

Ces artefacts d’attestation nécessitent une coordination avec les administrateurs de

votre infrastructure d’hébergement, ce qui peut compliquer l’obtention de ces
informations après un sinistre.

En outre, SGH nécessite l’accès à deux certificats ou plus utilisés pour chiffrer et signer
les informations nécessaires au démarrage d’une machine virtuelle dotée d’une
protection maximale (le protecteur de clé). Ces certificats sont bien connus (utilisés par
les propriétaires de machines virtuelles dotées d’une protection maximale pour autoriser
votre infrastructure à exécuter leurs machines virtuelles) et doivent être restaurés après
un sinistre pour une expérience de récupération transparente. Si vous ne restaurez pas
SGH avec les mêmes certificats après un sinistre, chaque machine virtuelle doit être mise
à jour pour autoriser vos nouvelles clés à déchiffrer leurs informations. Pour des raisons
de sécurité, seul le propriétaire de la machine virtuelle peut mettre à jour la
configuration de cette dernière pour autoriser ces nouvelles clés, ce qui signifie que
l’échec de la restauration de vos clés après un sinistre entraîne la nécessité pour chaque
propriétaire de machine virtuelle de prendre des mesures pour que leurs machines
virtuelles s’exécutent à nouveau.

Se préparer au pire

Pour vous préparer à une perte complète de SGH, vous devez suivre ces deux étapes :

1. Sauvegarder les stratégies d’attestation SGH

2. Sauvegarder les clés SGH

Des conseils sur la méthode d’exécution de ces deux étapes sont fournis dans la section
Sauvegarde de SGH.

Il est également recommandé, mais pas obligatoire, de sauvegarder la liste des

utilisateurs autorisés à gérer SGH dans son domaine Active Directory ou Active Directory
lui-même.

Les sauvegardes doivent être effectuées régulièrement pour s’assurer que les
informations sont à jour et stockées de manière sécurisée afin d’éviter toute falsification
ou vol.

Il n’est pas recommandé de sauvegarder ou de tenter de restaurer une image système

entière d’un nœud SGH. Si vous avez perdu l’intégralité de votre cluster, la meilleure
pratique consiste à configurer un nouveau nœud SGH et à restaurer uniquement
l’état SGH, et non l’ensemble du système d’exploitation du serveur.

Récupération après la perte d’un nœud

Si vous perdez un ou plusieurs nœuds (mais pas tous les nœuds) dans votre cluster SGH,
vous pouvez simplement ajouter des nœuds à votre cluster en suivant les instructions
du guide de déploiement. Les stratégies d’attestation sont synchronisées
automatiquement, tout comme tous les certificats fournis à SGH en tant que fichiers PFX
avec mots de passe associés. Pour les certificats ajoutés à SGH à l’aide d’une empreinte
(certificats non exportables et matériels, généralement), vous devez vous assurer que
chaque nouveau nœud a accès à la clé privée de chaque certificat.

Récupération après la perte de l’ensemble du cluster

Si l’ensemble de votre cluster SGH tombe en panne et que vous ne parvenez pas à le
remettre en ligne, vous devez restaurer SGH à partir d’une sauvegarde. La restauration
de SGH à partir d’une sauvegarde implique d’abord la configuration d’un nouveau
cluster SGH conformément aux instructions du guide de déploiement. Il est fortement
recommandé, mais pas obligatoire, d’utiliser le même nom de cluster lors de la
configuration de l’environnement SGH de récupération pour faciliter la résolution de
noms à partir d’hôtes. L’utilisation du même nom évite d’avoir à reconfigurer les hôtes
avec de nouvelles URL d’attestation et de protection de clé. Si vous avez restauré des
objets dans le domaine Active Directory qui sauvegarde SGH, il est recommandé de
supprimer les objets représentant le cluster SGH, les ordinateurs, le compte de service et
les groupes JEA avant d’initialiser le serveur SGH.

Une fois que vous avez configuré votre premier nœud SGH (p. ex., il a été installé et
initialisé), suivez les procédures sous Restaurer SGH à partir d’une sauvegarde pour
restaurer les stratégies d’attestation et les moitiés publiques des certificats de protection
de clé. Vous devez restaurer manuellement les clés privées de vos certificats selon les
instructions de votre fournisseur de certificats (p. ex., importer le certificat dans
Windows ou configurer l’accès aux certificats HSM). Une fois le premier nœud configuré,
vous pouvez continuer à installer des nœuds supplémentaires sur le cluster jusqu’à ce
que vous ayez atteint la capacité et la résilience souhaitées.

Sauvegarde de SGH
L’administrateur SGH doit être responsable de la sauvegarde de SGH sur une base
régulière. Une sauvegarde complète contient du matériel de clé sensible qui doit être
correctement sécurisé. Si une entité non approuvée accède à ces clés, elle peut utiliser
ce matériel pour configurer un environnement SGH malveillant dans le but de
compromettre les machines virtuelles dotées d’une protection maximale.

Sauvegarde des stratégies d’attestation Pour sauvegarder les stratégies

d’attestation SGH, exécutez la commande suivante sur n’importe quel nœud de
serveur SGH opérationnel. Vous serez invité à fournir un mot de passe pour cet
utilisateur. Ce mot de passe est utilisé pour chiffrer tous les certificats ajoutés à SGH à
l’aide d’un fichier PFX (au lieu d’une empreinte de certificat).

PowerShell

Export-HgsServerState -Path C:\temp\[Link]

７ Notes

Si vous utilisez l’attestation approuvée par l’administrateur, vous devez sauvegarder

séparément l’appartenance aux groupes de sécurité utilisés par SGH pour autoriser
les hôtes protégés. SGH sauvegarde uniquement le SID des groupes de sécurité, et
non l’appartenance à ceux-ci. Si ces groupes sont perdus lors d’un sinistre, vous
devez recréer le ou les groupes et y ajouter à nouveau chaque hôte protégé.

Sauvegarde de certificats

La commande Export-HgsServerState sauvegardera tous les certificats PFX ajoutés à

SGH au moment de l’exécution de la commande. Si vous avez ajouté des certificats à
SGH à l’aide d’une empreinte (généralement pour les certificats non exportables et
matériels), vous devrez sauvegarder manuellement les clés privées de vos certificats.
Pour identifier les certificats inscrits auprès de SGH et qui doivent être sauvegardés
manuellement, exécutez la commande PowerShell suivante sur n’importe quel nœud
serveur SGH opérationnel.

PowerShell

Get-HgsKeyProtectionCertificate | Where-Object {
$_.[Link]().Name -eq 'CertificateReference' } | Format-
Table Thumbprint, @{ Label = 'Subject'; Expression = {
$_.[Link] } }

Pour chacun des certificats répertoriés, vous devez sauvegarder manuellement la clé
privée. Si vous utilisez un certificat logiciel non exportable, contactez votre autorité de
certification pour vous assurer qu’elle dispose d’une sauvegarde de votre certificat et/ou
peut le réémettre à la demande. Pour les certificats créés et stockés dans des modules
de sécurité matériels, vous devez consulter la documentation de votre appareil pour
obtenir des conseils sur la planification de la récupération d’urgence.

Vous devez stocker les sauvegardes de certificat en même temps que vos sauvegardes
de stratégie d’attestation dans un emplacement sécurisé afin que les deux éléments
puissent être restaurés ensemble.
Configuration supplémentaire à sauvegarder

L’état du serveur SGH sauvegardé n’inclut pas le nom de votre cluster SGH, les
informations d’Active Directory ou les certificats SSL utilisés pour sécuriser les
communications avec les API SGH. Ces paramètres sont importants pour la cohérence,
mais pas pour que votre cluster SGH soit de nouveau en ligne après un sinistre.

Pour capturer le nom du service SGH, exécutez Get-HgsServer et notez le nom plat dans
les URL d’attestation et de protection de clé. Par exemple, si l’URL d’attestation est
« [Link] », « SGH » est le nom du service SGH.

Le domaine Active Directory utilisé par SGH doit être géré comme n’importe quel autre
domaine Active Directory. Lors de la restauration du SGH après un sinistre, vous n’aurez
pas nécessairement besoin de recréer les objets exacts présents dans le domaine actuel.
Toutefois, la récupération sera plus facile si vous sauvegardez Active Directory et
conservez une liste des utilisateurs JEA autorisés à gérer le système, ainsi que
l’appartenance à tous les groupes de sécurité utilisés par l’attestation approuvée par
l’administrateur pour autoriser les hôtes protégés.

Pour identifier l’empreinte des certificats SSL configurés pour SGH, exécutez la
commande suivante dans PowerShell. Vous pouvez ensuite sauvegarder ces
certificats SSL en fonction des instructions de votre fournisseur de certificats.

PowerShell

Get-WebBinding -Protocol https | Select-Object certificateHash

Restauration de SGH à partir d’une sauvegarde

Les étapes suivantes décrivent comment restaurer les paramètres SGH à partir d’une
sauvegarde. Les étapes sont pertinentes pour les deux situations où vous essayez
d’annuler les modifications apportées à vos instances SGH déjà en cours d’exécution et
lorsque vous mettez en place un tout nouveau cluster SGH après une perte complète de
votre précédent.

Configurer un cluster SGH de remplacement

Avant de pouvoir restaurer SGH, vous devez disposer d’un cluster SGH initialisé sur
lequel vous pouvez restaurer la configuration. Si vous importez simplement des
paramètres qui ont été accidentellement supprimés dans un cluster existant (en cours
d’exécution), vous pouvez ignorer cette étape. Si vous récupérez après une perte
complète de SGH, vous devez installer et initialiser au moins un nœud SGH en suivant
les instructions du guide de déploiement.

Plus précisément, vous devez :

1. Configurer le domaine SGH ou joindre SGH à un domaine existant

2. Initialiser le serveur SGH à l’aide de vos clés existantes ou d’un ensemble de clés
temporaires. Vous pouvez supprimer les clés temporaires après avoir importé vos
clés réelles à partir des fichiers de sauvegarde SGH.
3. Importer les paramètres SGH à partir de votre sauvegarde pour restaurer les
groupes hôtes approuvés, les stratégies d’intégrité du code, les bases de
référence TPM et les identificateurs TPM approuvés

 Conseil

Le nouveau cluster SGH n’a pas besoin d’utiliser les mêmes certificats, le même
nom de service ou de domaine que l’instance SGH à partir de laquelle votre fichier
de sauvegarde a été exporté.

Importation des paramètres à partir d’une sauvegarde

Pour restaurer des stratégies d’attestation, des certificats PFX et les clés publiques des
certificats non PFX sur votre nœud SGH à partir d’un fichier de sauvegarde, exécutez la
commande suivante sur un nœud serveur SGH initialisé. Vous serez invité à saisir le mot
de passe que vous avez spécifié lors de la création de la sauvegarde.

PowerShell

Import-HgsServerState -Path C:\Temp\[Link]

Si vous souhaitez uniquement importer des stratégies d’attestation approuvées par

l’administrateur ou des stratégies d’attestation approuvées par TPM, vous pouvez le
faire en spécifiant les indicateurs -ImportActiveDirectoryModeState ou -
ImportTpmModeState dans Import-HgsServerState.

Vérifiez que la dernière mise à jour cumulative pour Windows Server 2016 est installée
avant d’exécuter Import-HgsServerState . Si vous ne le faites pas, une erreur
d’importation peut se produire.

７ Notes
 Si vous restaurez des stratégies sur un nœud SGH existant sur lequel une ou
plusieurs de ces stratégies sont déjà installées, la commande d’importation affiche
une erreur pour chaque stratégie en double. Il s’agit d’un comportement attendu
qui peut être ignoré en toute sécurité dans la plupart des cas.

Réinstallation des clés privées pour les certificats

Si l’un des certificats utilisés sur le SGH à partir duquel la sauvegarde a été créée a été
ajouté à l’aide d’empreintes numériques, seule la clé publique de ces certificats sera
incluse dans le fichier de sauvegarde. Cela signifie que vous devez installer
manuellement et/ou accorder l’accès aux clés privées pour chacun de ces certificats
avant que SGH puisse traiter les demandes provenant d’hôtes Hyper-V. Les actions
nécessaires pour effectuer cette étape varient en fonction de la façon dont votre
certificat a été émis à l’origine. Pour les certificats logiciels émis par une autorité de
certification, vous devez contacter votre autorité de certification pour obtenir la clé
privée et l’installer sur chaque nœud SGH en fonction de leurs instructions. De même, si
vos certificats sont sauvegardés sur le matériel, vous devez consulter la documentation
du fournisseur de votre module de sécurité matérielle pour installer le ou les pilotes
nécessaires sur chaque nœud SGH pour vous connecter au HSM et accorder à chaque
machine l’accès à la clé privée.

Pour rappel, les certificats ajoutés à SGH à l’aide d’empreintes nécessitent une
réplication manuelle des clés privées sur chaque nœud. Vous devez répéter cette étape
sur chaque nœud supplémentaire que vous ajoutez au cluster SGH restauré.

Passage en revue des stratégies d’attestation importées

Une fois que vous avez importé vos paramètres à partir d’une sauvegarde, il est
recommandé d’examiner attentivement toutes les stratégies importées à l’aide de Get-
HgsAttestationPolicy pour vous assurer que seuls les hôtes auxquels vous faites

confiance pour exécuter des machines virtuelles dotées d’une protection maximale
seront en mesure d’attester avec succès. Si vous trouvez des stratégies qui ne
correspondent plus à votre posture de sécurité, vous pouvez les désactiver ou les
supprimer.

Exécution des diagnostics pour vérifier l’état du système

Une fois que vous avez terminé la configuration et la restauration de l’état de votre
nœud SGH, vous devez exécuter l’outil de diagnostic SGH pour vérifier l’état du système.
Pour ce faire, exécutez la commande suivante sur le nœud SGH où vous avez restauré la
configuration :

PowerShell

Get-HgsTrace -RunDiagnostics

Si le « Résultat global » n’est pas « Pass », des étapes supplémentaires sont nécessaires
pour terminer la configuration du système. Pour plus d’informations, vérifiez les
messages signalés dans les sous-tests qui ont échoué.

Mise à jour corrective de SGH

Il est important de maintenir vos nœuds du service Guardian hôte à jour en installant la
dernière mise à jour cumulative lors de sa sortie. Si vous configurez un nouveau
nœud SGH, il est vivement recommandé d’installer toutes les mises à jour disponibles
avant d’installer le rôle SGH ou de le configurer. Cela garantit que toutes les
fonctionnalités nouvelles ou modifiées prendront effet immédiatement.

Lors de la mise à jour corrective de votre infrastructure protégée, il est fortement

recommandé de commencer par mettre à niveau tous les hôtes Hyper-V avant de
mettre à niveau SGH. Cela permet de s’assurer que toutes les modifications apportées
aux stratégies d’attestation sur SGH sont effectuées une fois que les hôtes Hyper-V ont
été mis à jour afin de fournir les informations nécessaires pour eux. Si une mise à jour
change le comportement des stratégies, elles ne sont pas automatiquement activées
pour éviter d’interrompre votre infrastructure. Ces mises à jour nécessitent que vous
suiviez les instructions de la section suivante pour activer les stratégies d’attestation
nouvelles ou modifiées. Nous vous encourageons à lire les notes de publication de
Windows Server et les mises à jour cumulatives que vous installez pour vérifier si les
mises à jour de stratégie sont requises.

Mises à jour nécessitant l’activation de la stratégie

Si une mise à jour pour SGH introduit ou modifie de manière significative le
comportement d’une stratégie d’attestation, une étape supplémentaire est nécessaire
pour activer la stratégie modifiée. Les modifications de stratégie ne sont appliquées
qu’après l’exportation et l’importation de l’état SGH. Vous ne devez activer les stratégies
nouvelles ou modifiées qu’après avoir appliqué la mise à jour cumulative à tous les
hôtes et à tous les nœuds SGH de votre environnement. Une fois que chaque ordinateur
a été mis à jour, exécutez les commandes suivantes sur n’importe quel nœud SGH pour
déclencher le processus de mise à niveau :
 PowerShell

$password = Read-Host -AsSecureString -Prompt "Enter a temporary password"

Export-HgsServerState -Path .\[Link] -Password $password
Import-HgsServerState -Path .\[Link] -Password $password

Si une nouvelle stratégie a été introduite, elle est désactivée par défaut. Pour activer la
nouvelle stratégie, recherchez-la d’abord dans la liste des stratégies Microsoft (avec le
préfixe « SGH_ ») puis activez-la à l’aide des commandes suivantes :

PowerShell

Get-HgsAttestationPolicy

Enable-HgsAttestationPolicy -Name <Hgs_NewPolicyName>

Gestion des stratégies d’attestation

SGH gère plusieurs stratégies d’attestation qui définissent l’ensemble minimal de
conditions requises qu’un hôte doit respecter pour être considéré comme « sain » et
autorisé à exécuter des machines virtuelles dotées d’une protection maximale. Certaines
de ces stratégies sont définies par Microsoft, d’autres sont ajoutées par vous pour
définir les stratégies d’intégrité du code autorisées, les bases de référence TPM et les
hôtes dans votre environnement. Une maintenance régulière de ces stratégies est
nécessaire pour s’assurer que les hôtes peuvent continuer à attester correctement à
mesure que vous les mettez à jour et les remplacez, et pour garantir que les hôtes ou
configurations non approuvés ne sont pas autorisés à attester correctement.

Pour l’attestation approuvée par l’administrateur, il n’existe qu’une seule stratégie qui
détermine si un hôte est sain, à savoir, l’appartenance à un groupe de sécurité connu et
approuvé. L’attestation TPM est plus compliquée et implique différentes stratégies pour
mesurer le code et la configuration d’un système avant de déterminer s’il est sain.

Un SGH unique peut être configuré à la fois avec des stratégies Active Directory et TPM,
mais le service vérifie uniquement les stratégies pour le mode actuel pour lequel il est
configuré lorsqu’un hôte tente d’attester. Pour vérifier le mode de votre serveur SGH,
exécutez Get-HgsServer .

Stratégies par défaut

Pour l’attestation approuvée par TPM, plusieurs stratégies intégrées sont configurées sur
SGH. Certaines de ces stratégies sont « verrouillées », ce qui signifie qu’elles ne peuvent
pas être désactivées pour des raisons de sécurité. Le tableau ci-dessous explique
l’objectif de chaque stratégie par défaut.

Nom de la stratégie Objectif

Hgs_SecureBootEnabled Nécessite que le démarrage sécurisé soit activé sur les hôtes.
Cela est nécessaire pour mesurer les fichiers binaires de
démarrage et d’autres paramètres verrouillés par UEFI.

Hgs_UefiDebugDisabled Garantit que les hôtes n’ont pas de débogueur de noyau

activé. Les débogueurs en mode utilisateur sont bloqués avec
des stratégies d’intégrité du code.

Hgs_SecureBootSettings Stratégie négative pour s’assurer que les hôtes correspondent

à au moins une base de référence TPM (définie par
l’administrateur).

Hgs_CiPolicy Stratégie négative pour garantir que les hôtes utilisent l’une
des stratégies CI définies par l’administrateur.

Hgs_HypervisorEnforcedCiPolicy Nécessite que la stratégie d’intégrité du code soit appliquée

par l’hyperviseur. La désactivation de cette stratégie affaiblit
vos protections contre les attaques de stratégie d’intégrité du
code en mode noyau.

Hgs_FullBoot Garantit que l’hôte n’a pas repris de veille ou de mise en veille
prolongée. Les hôtes doivent être correctement redémarrés ou
arrêtés pour passer cette stratégie.

Hgs_VsmIdkPresent Nécessite l’exécution de la sécurité basée sur la virtualisation

sur l’hôte. L’IDK représente la clé nécessaire pour chiffrer les
informations renvoyées à l’espace mémoire sécurisé de l’hôte.

Hgs_PageFileEncryptionEnabled Nécessite que les fichiers de page soient chiffrés sur l’hôte. La
désactivation de cette stratégie peut entraîner une exposition
d’informations si un fichier de page non chiffré est inspecté à la
recherche de secrets de locataire.

Hgs_BitLockerEnabled Nécessite que BitLocker soit activé sur l’hôte Hyper-V. Cette
stratégie est désactivée par défaut pour des raisons de
performances et il n’est pas recommandé d’activer cette
stratégie. Cette stratégie n’a aucune incidence sur le
chiffrement des machines virtuelles dotées d’une protection
maximale.

Hgs_IommuEnabled Nécessite que l’hôte dispose d’un appareil IOMMU en cours

d’utilisation pour empêcher les attaques d’accès direct à la
mémoire. La désactivation de cette stratégie et l’utilisation
d’hôtes sans IOMMU activé peuvent exposer des secrets de
machine virtuelle client à des attaques de mémoire directes.
 Nom de la stratégie Objectif

Hgs_NoHibernation Nécessite la désactivation de la mise en veille prolongée sur

l’hôte Hyper-V. La désactivation de cette stratégie peut
permettre aux hôtes d’enregistrer la mémoire de machine
virtuelle protégée dans un fichier de mise en veille prolongée
non chiffré.

Hgs_NoDumps Nécessite que les vidages de mémoire soient désactivés sur

l’hôte Hyper-V. Si vous désactivez cette stratégie, il est
recommandé de configurer le chiffrement de vidage pour
empêcher l’enregistrement de la mémoire de machine virtuelle
protégée dans des fichiers de vidage sur incident non chiffrés.

Hgs_DumpEncryption Nécessite que les vidages de mémoire, s’ils sont activés sur
l’hôte Hyper-V, soient chiffrés avec une clé de chiffrement
approuvée par SGH. Cette stratégie ne s’applique pas si les
vidages ne sont pas activés sur l’hôte. Si cette stratégie et
Hgs_NoDumps sont tous les deux désactivés, la mémoire de
machine virtuelle protégée peut être enregistrée dans un
fichier de vidage non chiffré.

Hgs_DumpEncryptionKey Stratégie négative pour s’assurer que les hôtes configurés pour
autoriser les vidages de mémoire utilisent une clé de
chiffrement de fichier de vidage définie par l’administrateur
connue de SGH. Cette stratégie ne s’applique pas lorsque
Hgs_DumpEncryption est désactivé.

Autorisation de nouveaux hôtes protégés

Pour autoriser un nouvel hôte à devenir un hôte protégé (par exemple, attester avec
succès), SGH doit approuver l’hôte et (lorsqu’il est configuré pour utiliser l’attestation
approuvée par le module de plateforme sécurisée) le logiciel qui s’exécute sur celui-ci.
Les étapes d’autorisation d’un nouvel hôte diffèrent en fonction du mode d’attestation
pour lequel SGH est actuellement configuré. Pour vérifier le mode d’attestation de votre
infrastructure protégée, exécutez Get-HgsServer sur n’importe quel nœud SGH.

Configuration logicielle
Sur le nouvel hôte Hyper-V, vérifiez que Windows Server 2016 édition Datacenter est
installée. Windows Server 2016 Standard ne peut pas exécuter de machines virtuelles
dotées d’une protection maximale dans une infrastructure protégée. L’hôte peut être
installé Expérience utilisateur ou Server Core.
Sur le serveur avec expérience de bureau et Server Core, vous devez installer les rôles
serveur de support Hyper-V et Host Guardian Hyper-V :

PowerShell

Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -

Restart

Attestation approuvée par l’administrateur

Pour inscrire un nouvel hôte dans SGH lors de l’utilisation de l’attestation approuvée par
l’administrateur, vous devez d’abord ajouter l’hôte à un groupe de sécurité dans le
domaine auquel il est joint. En règle générale, chaque domaine a un groupe de sécurité
pour les hôtes protégés. Si vous avez déjà inscrit ce groupe auprès de SGH, la seule
action que vous devez effectuer consiste à redémarrer l’hôte pour actualiser son
appartenance au groupe.

Vous pouvez vérifier les groupes de sécurité approuvés par SGH en exécutant la
commande suivante :

PowerShell

Get-HgsAttestationHostGroup

Pour inscrire un nouveau groupe de sécurité auprès de SGH, commencez par capturer
l’identificateur de sécurité (SID) du groupe dans le domaine de l’hôte, puis inscrivez-le
auprès de SGH.

PowerShell

Add-HgsAttestationHostGroup -Name "Contoso Guarded Hosts" -Identifier "S-1-

5-21-3623811015-3361044348-30300820-1013"

Des instructions relatives à la manière de configurer l’approbation entre le domaine

hôte et SGH sont disponibles dans le guide de déploiement.

Attestation approuvée par le module de plateforme sécurisée

(TPM)
Lorsque SGH est configuré en mode TPM, les hôtes doivent passer toutes les stratégies
verrouillées et les stratégies « activées » avec le préfixe « SGH_ », ainsi qu’au moins une
ligne de base de module de plateforme sécurisée, un identificateur TPM et une stratégie
d’intégrité du code. Chaque fois que vous ajoutez un nouvel hôte, vous devez inscrire le
nouvel identificateur TPM auprès de SGH. Tant que l’hôte exécute le même logiciel (et a
la même stratégie d’intégrité du code appliquée) et la même base de référence TPM
qu’un autre hôte dans votre environnement, vous n’avez pas besoin d’ajouter de
nouvelles stratégies d’intégration continue ou de nouvelles bases de référence.

Ajout de l’identificateur TPM pour un nouvel hôte Sur le nouvel hôte, exécutez la
commande suivante pour capturer l’identificateur TPM. Veillez à spécifier un nom
unique pour l’hôte qui vous aidera à le rechercher sur SGH. Vous aurez besoin de ces
informations si vous désaffectez l’hôte ou si vous souhaitez l’empêcher d’exécuter des
machines virtuelles dotées d’une protection maximale dans SGH.

PowerShell

(Get-PlatformIdentifier -Name "Host01").InnerXml | Out-File

C:\temp\[Link] -Encoding UTF8

Copiez ce fichier sur votre serveur SGH, puis exécutez la commande suivante pour
inscrire l’hôte auprès de SGH.

PowerShell

Add-HgsAttestationTpmHost -Name 'Host01' -Path C:\temp\[Link]

Ajout d’une nouvelle ligne de base de plateforme sécurisée (TPM) Si le nouvel hôte
exécute une nouvelle configuration de matériel ou de microprogramme pour votre
environnement, vous devrez peut-être utiliser une nouvelle base de référence TPM. Pour
cela, exécutez la commande suivante sur chaque hôte :

PowerShell

Get-HgsAttestationBaselinePolicy -Path 'C:\temp\[Link]'

７ Notes

Si vous recevez une erreur indiquant que votre hôte n’a pas réussi la validation et
n’atteste pas correctement, ne vous inquiétez pas. Il s’agit d’une vérification des
prérequis pour vous assurer que votre hôte peut exécuter des machines virtuelles
dotées d’une protection maximale, ce qui signifie probablement que vous n’avez
pas encore appliqué de stratégie d’intégrité du code ou d’autre paramètre requis.
Lisez le message d’erreur, apportez les modifications suggérées par celui-ci, puis
 réessayez. Vous pouvez également ignorer la validation à ce stade en ajoutant
l’indicateur -SkipValidation à la commande.

Copiez la base de référence TPM sur votre serveur SGH, puis inscrivez-la avec la
commande suivante. Nous vous encourageons à utiliser une convention d’affectation de
noms qui vous aide à comprendre la configuration du matériel et du microprogramme
de cette classe d’hôte Hyper-V.

PowerShell

Add-HgsAttestationTpmPolicy -Name 'HardwareConfig01' -Path

'C:\temp\[Link]'

Ajout d’une nouvelle stratégie d’intégrité du code Si vous avez modifié la stratégie
d’intégrité du code en cours d’exécution sur vos hôtes Hyper-V, vous devez inscrire la
nouvelle stratégie auprès de SGH pour que ces hôtes puissent attester correctement.
Sur un hôte de référence, qui sert d’image maître pour les machines Hyper-V
approuvées dans votre environnement, capturez une nouvelle stratégie CI à l’aide de la
commande New-CIPolicy . Nous vous encourageons à utiliser le niveau FilePublisher et
le hachage de secours pour les stratégies CI de l’hôte Hyper-V. Vous devez d’abord
créer une stratégie CI en mode audit pour vous assurer que tout fonctionne comme
prévu. Après avoir validé un exemple de charge de travail sur le système, vous pouvez
appliquer la stratégie et copier la version appliquée dans SGH. Pour obtenir la liste
complète des options de configuration de la stratégie d’intégrité du code, consultez la
documentation Device Guard.

PowerShell

# Capture a new CI policy with the FilePublisher primary level and Hash
fallback and enable user mode code integrity protections
New-CIPolicy -FilePath 'C:\temp\[Link]' -Level
FilePublisher -Fallback Hash -UserPEs

# Apply the CI policy to the system

ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\[Link]' -
BinaryFilePath 'C:\temp\ws2016-hardware01-ci.p7b'
Copy-Item 'C:\temp\ws2016-hardware01-ci.p7b'
'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'
Restart-Computer

# Check the event log for any untrusted binaries and update the policy if
necessary
# Consult the Device Guard documentation for more details

# Change the policy to be in enforced mode

Set-RuleOption -FilePath 'C:\temp\[Link]' -Option 3 -Delete
 # Apply the enforced CI policy on the system
ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\[Link]' -
BinaryFilePath 'C:\temp\ws2016-hardware01-ci.p7b'
Copy-Item 'C:\temp\ws2016-hardware01-ci.p7b'
'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'
Restart-Computer

Une fois votre stratégie créée, testée et appliquée, copiez le fichier binaire (.p7b) sur
votre serveur SGH et inscrivez la stratégie.

PowerShell

Add-HgsAttestationCiPolicy -Name 'WS2016-Hardware01' -Path 'C:\temp\ws2016-

hardware01-ci.p7b'

Ajout d’une clé de chiffrement de vidage de mémoire

Lorsque la stratégie Hgs_NoDumps est désactivée et que la stratégie

Hgs_DumpEncryption est activée, les hôtes protégés sont autorisés à avoir des vidages
de mémoire (y compris les vidages sur incident) à activer tant que ces vidages sont
chiffrés. Les hôtes protégés ne passent l’attestation que s’ils ont des vidages de
mémoire désactivés ou s’ils les chiffrent avec une clé connue de SGH. Par défaut, aucune
clé de chiffrement de vidage n’est configurée sur SGH.

Pour ajouter une clé de chiffrement de vidage à SGH, utilisez l’applet de commande
Add-HgsAttestationDumpPolicy pour fournir à SGH le hachage de votre clé de
chiffrement de vidage. Si vous capturez un planning de référence TPM sur un
hôte Hyper-V configuré avec le chiffrement de vidage, le hachage est inclus dans le
tcglog et peut être fourni à l’applet de commande Add-HgsAttestationDumpPolicy .

PowerShell

Add-HgsAttestationDumpPolicy -Name 'DumpEncryptionKey01' -Path

'C:\temp\[Link]'

Vous pouvez également fournir directement la représentation sous forme de chaîne du

hachage à l’applet de commande.

PowerShell

Add-HgsAttestationDumpPolicy -Name 'DumpEncryptionKey02' -PublicKeyHash

'<paste your hash here>'
Veillez à ajouter chaque clé de chiffrement de vidage unique à SGH si vous choisissez
d’utiliser différentes clés dans votre infrastructure protégée. Les hôtes qui chiffrent des
vidages de mémoire avec une clé non connue de SGH ne passeront pas l’attestation.

Pour plus d’informations sur la configuration du chiffrement de vidage sur les hôtes,
consultez la documentation Hyper-V.

Vérifier si le système a réussi l’attestation

Après avoir inscrit les informations nécessaires auprès de SGH, vous devez vérifier si
l’hôte réussit l’attestation. Sur l’hôte Hyper-V nouvellement ajouté, exécutez Set-
HgsClientConfiguration et fournissez les URL appropriées pour votre cluster SGH. Ces
URL peuvent être obtenues en exécutant Get-HgsServer sur n’importe quel nœud SGH.

PowerShell

Set-HgsClientConfiguration -KeyProtectionServerUrl
'[Link] -AttestationServerUrl
'[Link]

Si l’état résultant n’indique pas « IsHostGuarded : True », vous devez résoudre les
problèmes de configuration. Sur l’hôte qui a échoué à l’attestation, exécutez la
commande suivante pour obtenir un rapport détaillé sur les problèmes qui peuvent
vous aider à résoudre l’attestation ayant échoué.

PowerShell

Get-HgsTrace -RunDiagnostics -Detailed

） Important

Si vous utilisez Windows Server 2019 ou Windows 10, version 1809 et que vous
utilisez des stratégies d’intégrité du code, Get-HgsTrace peut renvoyer un échec
pour le diagnostic actif de la stratégie d’intégrité du code. Vous pouvez ignorer ce
résultat en toute sécurité lorsqu’il s’agit du seul diagnostic défaillant.

Passer en revue les stratégies d’attestation

Pour passer en revue l’état actuel des stratégies configurées sur SGH, exécutez les
commandes suivantes sur n’importe quel nœud SGH :
 PowerShell

# List all trusted security groups for admin-trusted attestation

Get-HgsAttestationHostGroup

# List all policies configured for TPM-trusted attestation

Get-HgsAttestationPolicy

Si vous trouvez une stratégie activée qui ne répond plus à vos exigences de sécurité
(p. ex., une ancienne stratégie d’intégrité du code qui est désormais considérée comme
non sécurisée), vous pouvez la désactiver en remplaçant le nom de la stratégie dans la
commande suivante :

PowerShell

Disable-HgsAttestationPolicy -Name 'PolicyName'

De même, vous pouvez utiliser Enable-HgsAttestationPolicy pour réactiver une

stratégie.

Si vous n’avez plus besoin d’une stratégie et que vous souhaitez la supprimer de tous
les nœuds SGH, exécutez Remove-HgsAttestationPolicy -Name 'PolicyName' pour
supprimer définitivement la stratégie.

Modification des modes d’attestation

Si vous avez démarré votre infrastructure protégée à l’aide d’une attestation approuvée
par l’administrateur, vous voudrez probablement effectuer une mise à niveau vers le
mode d’attestation TPM beaucoup plus puissant dès que vous avez suffisamment
d’hôtes compatibles avec TPM 2.0 dans votre environnement. Lorsque vous êtes prêt à
basculer, vous pouvez précharger tous les artefacts d’attestation (stratégies CI, lignes de
base TPM et identificateurs TPM) dans SGH tout en continuant à exécuter SGH avec une
attestation approuvée par l’administrateur. Pour ce faire, suivez simplement les
instructions de la section autoriser un nouvel hôte protégé.

Une fois que vous avez ajouté toutes vos stratégies à SGH, l’étape suivante consiste à
exécuter une tentative d’attestation synthétique sur vos hôtes pour voir s’ils réussissent
l’attestation en mode TPM. Cela n’affecte pas l’état opérationnel actuel de SGH. Les
commandes ci-dessous doivent être exécutées sur une machine qui a accès à tous les
hôtes de l’environnement et à au moins un nœud SGH. Si votre pare-feu ou d’autres
stratégies de sécurité empêchent cela, vous pouvez ignorer cette étape. Lorsque cela est
possible, nous vous recommandons d’exécuter l’attestation synthétique pour vous
indiquer si le basculement vers le mode TPM entraîne un temps d’arrêt pour vos
machines virtuelles.

PowerShell

# Get information for each host in your environment

$hostNames = '[Link]', '[Link]',
'[Link]'
$credential = Get-Credential -Message 'Enter a credential with admin
privileges on each host'
$targets = @()
$hostNames | ForEach-Object { $targets += New-HgsTraceTarget -Credential
$credential -Role GuardedHost -HostName $_ }

$hgsCredential = Get-Credential -Message 'Enter an admin credential for HGS'

$targets += New-HgsTraceTarget -Credential $hgsCredential -Role
HostGuardianService -HostName '[Link]'

# Initiate the synthetic attestation attempt

Get-HgsTrace -RunDiagnostics -Target $targets -Diagnostic
GuardedFabricTpmMode

Une fois les diagnostics terminés, passez en revue les informations sorties pour
déterminer si des hôtes auraient échoué à l’attestation en mode TPM. Réexécutez les
diagnostics jusqu’à ce que chaque hôte réussisse, puis passez le mode SGH en
mode TPM.

Le passage au mode TPM ne prend qu’une seconde. Exécutez la commande suivante

sur n’importe quel nœud SGH pour mettre à jour le mode d’attestation.

PowerShell

Set-HgsServer -TrustTpm

Si vous rencontrez des problèmes et que vous devez revenir en mode Active Directory,
vous pouvez le faire en exécutant Set-HgsServer -TrustActiveDirectory .

Une fois que vous avez confirmé que tout fonctionne comme prévu, vous devez
supprimer tous les groupes hôtes Active Directory approuvés de SGH et supprimer
l’approbation entre les domaines SGH et de la structure. Si vous laissez l’approbation
Active Directory en place,il se peut que quelqu’un réactive l’approbation et bascule SGH
en mode Active Directory, ce qui peut permettre au code non approuvé de s’exécuter
sans avoir été coché sur vos hôtes protégés.

Gestion des clés

La solution de structure protégée utilise plusieurs paires de clés publiques/privées pour
valider l’intégrité des différents composants de la solution et chiffrer les secrets de
locataire. Le service Guardian hôte est configuré avec au moins deux certificats (avec des
clés publiques et privées), qui sont utilisés pour signer et chiffrer les clés utilisées pour
démarrer des machines virtuelles protégées. Ces clés doivent être gérées avec soin. Si la
clé privée est acquise par un adversaire, il sera en mesure de déjouer les machines
virtuelles en cours d’exécution sur votre infrastructure ou de configurer un cluster SGH
imposteur qui utilise des stratégies d’attestation plus faibles pour contourner les
protections que vous mettez en place. Si vous perdez les clés privées lors d’un sinistre et
que vous ne les trouvez pas dans une sauvegarde, vous devez configurer une nouvelle
paire de clés et recréer chaque machine virtuelle pour autoriser vos nouveaux certificats.

Cette section traite des rubriques générales sur la gestion des clés pour vous aider à
configurer vos clés afin qu’elles soient fonctionnelles et sécurisées.

Ajout de nouvelles clés

Bien que SGH soit initialisé avec un ensemble de clés, vous pouvez ajouter plusieurs clés
de chiffrement et de signature. Les deux raisons les plus courantes pour lesquelles vous
ajoutez de nouvelles clés à SGH sont les suivantes :

1. Pour prendre en charge les scénarios « apportez votre propre clé » où les
locataires copient leurs clés privées dans votre module de sécurité matérielle et
autorisent uniquement leurs clés à démarrer leurs machines virtuelles protégées.
2. Pour remplacer les clés existantes pour SGH en ajoutant d’abord les nouvelles clés
et en conservant les deux ensembles de clés jusqu’à ce que chaque configuration
de machine virtuelle ait été mise à jour pour utiliser les nouvelles clés.

Le processus d’ajout de vos nouvelles clés diffère en fonction du type de certificat que
vous utilisez.

Option 1 : ajout d’un certificat stocké dans un HSM

Notre approche recommandée pour sécuriser les clés SGH consiste à utiliser des
certificats créés dans un module de sécurité matériel (HSM). Les HSM garantissent que
l’utilisation de vos clés est liée à l’accès physique à un appareil sensible à la sécurité
dans votre centre de données. Chaque HSM est différent et a un processus unique pour
créer des certificats et les inscrire auprès de SGH. Les étapes ci-dessous sont destinées à
fournir des conseils approximatifs pour l’utilisation de certificats sauvegardés dans un
HSM. Consultez la documentation de votre fournisseur de HSM pour connaître les
étapes et les fonctionnalités exactes.
 1. Installez le logiciel HSM sur chaque nœud SGH dans votre cluster. Selon que vous
disposez d’un réseau ou d’un appareil HSM local, vous devrez peut-être configurer
le HSM pour accorder à votre ordinateur l’accès à son magasin de clés.

2. Créer deux certificats dans le HSM avec des clés RSA 2 048 bits pour le
chiffrement et la signature
a. Créer un certificat de chiffrement avec la propriété d’utilisation de la clé de
chiffrement des données dans votre HSM
b. Créer un certificat de signature avec la propriété d’utilisation de la clé signature
numérique dans votre HSM

3. Installez les certificats dans le magasin de certificats local de chaque nœud SGH
conformément aux instructions de votre fournisseur HSM.

4. Si votre HSM utilise des autorisations granulaires pour accorder des applications
ou des utilisateurs spécifiques à l’utilisation de la clé privée, vous devez accorder à
votre compte de service managé de groupe SGH l’accès au certificat. Vous pouvez
trouver le nom du compte gMSA SGH en exécutant (Get-IISAppPool -Name
KeyProtection).[Link]

5. Ajoutez les certificats de signature et de chiffrement à SGH en remplaçant les

empreintes par celles de vos certificats dans les commandes suivantes :

PowerShell

Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint

"AABBCCDDEEFF00112233445566778899"
Add-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint
"99887766554433221100FFEEDDCCBBAA"

Option 2 : Ajout de certificats logiciels non exportables

Si vous disposez d’un certificat logiciel émis par l’autorité de certification de votre
entreprise ou par une autorité de certification publique disposant d’une clé privée non
exportable, vous devez ajouter votre certificat à SGH à l’aide de son empreinte
numérique.

1. Installez le certificat sur votre ordinateur en fonction des instructions de votre

autorité de certification.

2. Accordez au compte de service managé de groupe SGH un accès en lecture à la clé

privée du certificat. Vous pouvez trouver le nom du compte gMSA SGH en
exécutant (Get-IISAppPool -Name KeyProtection).[Link]
 3. Inscrivez le certificat auprès de SGH à l’aide de la commande suivante et en
remplaçant dans l’empreinte numérique de votre certificat (remplacez Chiffrement
par Signature pour la signature des certificats) :

PowerShell

Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint

"AABBCCDDEEFF00112233445566778899"

） Important

Vous devez installer manuellement la clé privée et accorder l’accès en lecture au

compte gMSA sur chaque nœud SGH. SGH ne peut pas répliquer automatiquement
les clés privées pour n’importe quel certificat inscrit par son empreinte numérique.

Option 3 : Ajout de certificats stockés dans des fichiers PFX

Si vous disposez d’un certificat logiciel avec une clé privée exportable qui peut être
stockée au format de fichier PFX et sécurisée avec un mot de passe, SGH peut gérer
automatiquement vos certificats pour vous. Les certificats ajoutés avec les fichiers PFX
sont répliqués automatiquement sur chaque nœud de votre cluster SGH qui sécurise
l’accès aux clés privées. Pour ajouter un nouveau certificat à l’aide d’un fichier PFX,
exécutez les commandes suivantes sur n’importe quel nœud SGH (remplacez
Chiffrement par Signature pour la signature des certificats) :

PowerShell

$certPassword = Read-Host -AsSecureString -Prompt "Provide the PFX file

password"
Add-HgsKeyProtectionCertificate -CertificateType Encryption -CertificatePath
"C:\temp\[Link]" -CertificatePassword $certPassword

Identification et modification des certificats principaux Bien que SGH puisse prendre
en charge plusieurs certificats de signature et de chiffrement, il utilise une paire comme
certificats « principaux ». Il s’agit des certificats qui seront utilisés si quelqu’un
télécharge les métadonnées du tuteur pour ce cluster SGH. Pour vérifier quels certificats
sont actuellement marqués comme certificats principaux, exécutez la commande
suivante :

PowerShell

Get-HgsKeyProtectionCertificate -IsPrimary $true

Pour définir un nouveau certificat de chiffrement ou de signature principal, recherchez
l’empreinte du certificat souhaité et marquez-le comme principal à l’aide des
commandes suivantes :

PowerShell

Get-HgsKeyProtectionCertificate
Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint
"AABBCCDDEEFF00112233445566778899" -IsPrimary
Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint
"99887766554433221100FFEEDDCCBBAA" -IsPrimary

Renouvellement ou remplacement de clés

Lorsque vous créez les certificats utilisés par SGH, une date d’expiration est attribuée
aux certificats en fonction de la stratégie de votre autorité de certification et de vos
informations de demande. Normalement, dans les scénarios où la validité du certificat
est importante, comme la sécurisation des communications HTTP, les certificats doivent
être renouvelés avant leur expiration pour éviter une interruption de service ou un
message d’erreur inquiétant. SGH n’utilise pas de certificats dans ce sens. SGH utilise
simplement des certificats comme moyen pratique de créer et de stocker une paire de
clés asymétriques. Un certificat de chiffrement ou de signature expiré sur SGH n’indique
pas une faiblesse ou une perte de protection pour les machines virtuelles protégées. En
outre, les vérifications de révocation de certificat ne sont pas effectuées par SGH. Si un
certificat SGH ou le certificat de l’autorité émettrice est révoqué, cela n’aura pas
d’impact sur l’utilisation du certificat par SGH.

La seule fois où vous devez vous soucier d’un certificat SGH est si vous avez des raisons
de croire que sa clé privée a été volée. Dans ce cas, l’intégrité de vos machines virtuelles
protégées est menacée, car la possession de la moitié privée de la paire de clés de
chiffrement et de signature SGH suffit à supprimer les protections sur une machine
virtuelle ou à mettre en place un serveur SGH factice qui a des stratégies d’attestation
plus faibles.

Si vous vous trouvez dans cette situation ou si les normes de conformité vous obligent à
actualiser régulièrement les clés de certificat, les étapes suivantes décrivent le processus
de modification des clés sur un serveur SGH. Notez que les conseils suivants
représentent une entreprise importante qui entraînera une interruption du service de
chaque machine virtuelle desservie par le cluster SGH. La planification appropriée de la
modification des clés SGH est nécessaire pour réduire les interruptions de service et
garantir la sécurité des machines virtuelles clientes.
Sur un nœud SGH, procédez comme suit pour inscrire une nouvelle paire de certificats
de chiffrement et de signature. Consultez la section sur l’ajout de nouvelles clés pour
obtenir des informations détaillées sur les différentes façons d’ajouter de nouvelles clés
à SGH.

1. Créez une paire de certificats de chiffrement et de signature pour votre

serveur SGH. Dans l’idéal, ceux-ci seront créés dans un module de sécurité
matérielle.

2. Inscrire les nouveaux certificats de chiffrement et de signature avec Add-

HgsKeyProtectionCertificate

PowerShell

Add-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint

<Thumbprint>
Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint
<Thumbprint>

3. Si vous avez utilisé des empreintes numériques, vous devez accéder à chaque
nœud du cluster pour installer la clé privée et accorder à SGH gMSA l’accès à la
clé.

4. Faire des nouveaux certificats les certificats par défaut dans SGH

PowerShell

Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint

<Thumbprint> -IsPrimary
Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint
<Thumbprint> -IsPrimary

À ce stade, la protection des données créées avec des métadonnées obtenues à partir
du nœud SGH utilisera les nouveaux certificats, mais les machines virtuelles existantes
continueront de fonctionner, car les anciens certificats sont toujours présents.

Pour vous assurer que toutes les machines virtuelles existantes fonctionneront avec les
nouvelles clés, vous devez mettre à jour le protecteur de clés sur chaque machine
virtuelle.

Il s’agit d’une action qui nécessite que le propriétaire de la machine virtuelle (personne
ou entité en possession du tuteur « propriétaire ») soit impliqué. Pour chaque machine
virtuelle protégée, effectuez les étapes suivantes :
1. Arrêtez la machine virtuelle. La machine virtuelle ne peut pas être réactivée tant
que les étapes restantes ne sont pas terminées, sinon vous devrez recommencer le
processus.

2. Enregistrez le protecteur de clé actuel dans un fichier : Get-VMKeyProtector -VMName

'VM001' | Out-File '.\[Link]'

3. Transférez le KP au propriétaire de la machine virtuelle

4. Chargez le propriétaire de télécharger les informations du tuteur mises à jour à

partir de SGH et de les importer sur son système local

5. Lisez le KP actuel en mémoire, accordez au nouveau gardien l’accès au KP et

enregistrez-le dans un nouveau fichier en exécutant les commandes suivantes :

PowerShell

$kpraw = Get-Content -Path .\[Link]

$kp = ConvertTo-HgsKeyProtector -Bytes $kpraw
$newGuardian = Get-HgsGuardian -Name 'UpdatedHgsGuardian'
$updatedKP = Grant-HgsKeyProtectorAccess -KeyProtector $kp -Guardian
$newGuardian
$[Link] | Out-File .\[Link]

6. Copiez le KP mis à jour dans l’infrastructure d’hébergement.

7. Appliquez le KP à la machine virtuelle d’origine :

PowerShell

$updatedKP = Get-Content -Path .\[Link]

Set-VMKeyProtector -VMName VM001 -KeyProtector $updatedKP

8. Enfin, démarrez la machine virtuelle et vérifiez qu’elle s’exécute correctement.

７ Notes

Si le propriétaire de la machine virtuelle définit un protecteur de clé incorrect

sur la machine virtuelle et n’autorise pas votre infrastructure à exécuter la
machine virtuelle, vous ne pourrez pas démarrer la machine virtuelle
protégée. Pour revenir au dernier protecteur de clé correct connu, exécutez
Set-VMKeyProtector -RestoreLastKnownGoodKeyProtector
 Une fois que toutes les machines virtuelles ont été mises à jour pour autoriser les
nouvelles clés de tuteur, vous pouvez désactiver et supprimer les anciennes clés.

9. Obtenez les empreintes des anciens certificats à partir de Get-

HgsKeyProtectionCertificate -IsPrimary $false

10. Désactivez chaque certificat en exécutant les commandes suivantes :

PowerShell

Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint

<Thumbprint> -IsEnabled $false
Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint
<Thumbprint> -IsEnabled $false

11. Après avoir vérifié que les machines virtuelles sont toujours en mesure de
démarrer avec les certificats désactivés, supprimez les certificats de SGH en
exécutant les commandes suivantes :

PowerShell

Remove-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint

<Thumbprint>`
Remove-HgsKeyProtectionCertificate -CertificateType Encryption -
Thumbprint <Thumbprint>`

） Important

Les sauvegardes de machine virtuelle contiennent d’anciennes informations de

protection de clé qui permettent d’utiliser les anciens certificats pour démarrer la
machine virtuelle. Si vous savez que votre clé privée a été compromise, vous devez
supposer que les sauvegardes de machine virtuelle peuvent également être
compromises et prendre les mesures appropriées. La destruction de la
configuration de la machine virtuelle à partir des sauvegardes (.vmcx) supprime les
protecteurs de clés, au prix de la nécessité d’utiliser le mot de passe de
récupération BitLocker pour démarrer la machine virtuelle la prochaine fois.

Réplication de clé entre nœuds

Chaque nœud du cluster SGH doit être configuré avec les mêmes certificats de
chiffrement, de signature et SSL (lorsqu’ils sont configurés). Cela est nécessaire pour
garantir que les hôtes Hyper-V qui atteignent n’importe quel nœud du cluster peuvent
avoir leurs demandes correctement traitées.

Si vous avez initialisé le serveur SGH avec des certificats PFX, alors SGH répliquera
automatiquement la clé publique et privée de ces certificats sur chaque nœud du
cluster. Il vous suffit d’ajouter les clés sur un seul nœud.

Si vous avez initialisé le serveur SGH avec des références de certificat ou des
empreintes, SGH répliquera uniquement la clé publique dans le certificat sur chaque
nœud. En outre, SGH ne peut pas s’accorder l’accès à la clé privée sur n’importe quel
nœud dans ce scénario. Par conséquent, il vous incombe de réaliser les actions
suivantes :

1. Installez la clé privée sur chaque nœud SGH

2. Accordez au compte de service managé de groupe SGH (gMSA) l’accès à la clé
privée sur chaque nœud. Ces tâches ajoutent une charge opérationnelle
supplémentaire, mais elles sont requises pour les clés et certificats HSM avec des
clés privées non exportables.

Les certificats SSL ne sont jamais répliqués sous quelque forme que ce soit. Il vous
incombe d’initialiser chaque serveur SGH avec le même certificat SSL et de mettre à jour
chaque serveur chaque fois que vous choisissez de renouveler ou de remplacer le
certificat SSL. Lorsque vous remplacez le certificat SSL, il est recommandé de le faire à
l’aide de l’applet de commande Set-HgsServer.

Annulation de la configuration SGH

Si vous devez désactiver ou reconfigurer de manière significative un serveur SGH, vous
pouvez le faire à l’aide des applets de commande Clear-HgsServer ou Uninstall-
HgsServer.

Suppression de la configuration SGH

Pour supprimer un nœud du cluster SGH, utilisez l’applet de commande Clear-
HgsServer. Cette applet de commande apporte les modifications suivantes sur le serveur
sur lequel elle est exécutée :

Annulation de l’inscription des services d’attestation et de protection des clés

Suppression du point de terminaison de gestion JEA « [Link] »
Suppression de l’ordinateur local du cluster de basculement SGH
Si le serveur est le dernier nœud SGH du cluster, le cluster et sa ressource de nom de
réseau distribué correspondante sont également détruits.

PowerShell

# Removes the local computer from the HGS cluster

Clear-HgsServer

Une fois l’opération de suppression terminée, le serveur SGH peut être réinitialisé avec
Initialize-HgsServer. Si vous avez utilisé Install-HgsServer pour configurer un domaine
Active Directory Domain Services, ce domaine restera configuré et opérationnel après
l’opération de suppression.

Désinstallation de SGH
Si vous souhaitez supprimer un nœud du cluster SGH et rétrograder le contrôleur
domaine Active Directory qui s’exécute sur celui-ci, utilisez l’applet de commande
Uninstall-HgsServer. Cette applet de commande apporte les modifications suivantes sur
le serveur sur lequel elle est exécutée :

Annulation de l’inscription des services d’attestation et de protection des clés

Suppression du point de terminaison de gestion JEA « [Link] »
Suppression de l’ordinateur local du cluster de basculement SGH
Rétrogradation du contrôleur de domaine Active Directory, s’il est configuré

Si le serveur est le dernier nœud SGH du cluster, le domaine, le cluster de basculement

et la ressource nom du réseau distribué du cluster sont également détruits.

PowerShell

# Removes the local computer from the HGS cluster and demotes the ADDC
(restart required)
$newLocalAdminPassword = Read-Host -AsSecureString -Prompt "Enter a new
password for the local administrator account"
Uninstall-HgsServer -LocalAdministratorPassword $newLocalAdminPassword -
Restart

Une fois l’opération de désinstallation terminée et l’ordinateur redémarré, vous pouvez

réinstaller ADDC et SGH à l’aide de Install-HgsServer ou joindre l’ordinateur à un
domaine et initialiser le serveur SGH dans ce domaine avec Initialize-HgsServer.

Si vous n’avez plus l’intention d’utiliser l’ordinateur comme nœud SGH, vous pouvez
supprimer le rôle de Windows.
PowerShell

Uninstall-WindowsFeature HostGuardianServiceRole
Éléments à prendre en compte en
matière de filiale
Article • 11/04/2023

S’applique à : Windows Server 2022, Windows Server 2019

Cet article décrit les bonnes pratiques pour l’exécution de machines virtuelles dotées
d’une protection maximale dans des filiales et d’autres scénarios à distance où les hôtes
Hyper-V peuvent avoir des périodes de connectivité limitée à HGS.

Configuration de secours
À partir de Windows Server version 1709, vous pouvez configurer un ensemble
supplémentaire d’URL du service Guardian hôte sur les hôtes Hyper-V pour une
utilisation lorsque votre SGH principal ne répond pas. Cela vous permet d’exécuter un
cluster SGH local qui est utilisé comme serveur principal pour de meilleures
performances avec la possibilité de revenir au SGH de votre centre de données
d’entreprise si les serveurs locaux sont en panne.

Pour utiliser l’option de secours, vous devez configurer deux serveurs SGH. Ils peuvent
exécuter Windows Server 2019 ou Windows Server 2016 et faire partie de clusters
identiques ou différents. S’il s’agit de clusters différents, vous devez établir des pratiques
opérationnelles pour vous assurer que les stratégies d’attestation sont synchronisées
entre les deux serveurs. Ils doivent tous deux être en mesure d’autoriser correctement
l’hôte Hyper-V à exécuter des machines virtuelles protégées et disposer du matériel clé
nécessaire pour démarrer les machines virtuelles dotées d’une protection maximale.
Vous pouvez choisir d’avoir une paire de certificats de chiffrement et de signature
partagés entre les deux clusters, ou d’utiliser des certificats distincts et de configurer la
machine virtuelle protégée par SGH pour autoriser les deux Guardians (paires de
certificats de chiffrement/signature) dans le fichier de données de protection.

Ensuite, mettez à niveau vos hôtes Hyper-V vers Windows Server version 1709 ou
Windows Server 2019 et exécutez la commande suivante :

PowerShell

# Replace [Link] and [Link] with your own

domain names and protocols
Set-HgsClientConfiguration -KeyProtectionServerUrl
'[Link] -AttestationServerUrl
'[Link] -FallbackKeyProtectionServerUrl
 '[Link] -FallbackAttestationServerUrl
'[Link]

Pour annuler la configuration d’un serveur de secours, omettez simplement les deux
paramètres de secours :

PowerShell

Set-HgsClientConfiguration -KeyProtectionServerUrl
'[Link] -AttestationServerUrl
'[Link]

Pour que l’hôte Hyper-V passe l’attestation avec les serveurs principal et de secours,
vous devez vous assurer que vos informations d’attestation sont à jour avec les deux
clusters SGH. En outre, les certificats utilisés pour déchiffrer le module TPM de la
machine virtuelle doivent être disponibles dans les deux clusters SGH. Vous pouvez
configurer chaque SGH avec des certificats différents et configurer la machine virtuelle
pour qu’elle approuve les deux, ou ajouter un ensemble partagé de certificats aux deux
clusters SGH.

Pour plus d’informations sur la configuration de SGH dans une filiale à l’aide d’URL de
secours, consultez le billet de blog Amélioration de la prise en charge des filiales pour
les machines virtuelles dotées d’une protection maximale dans Windows Server,
version 1709.

Mode hors connexion

Le mode hors connexion permet à votre machine virtuelle dotée d’une protection
maximale de s’activer lorsque SGH n’est pas accessible, tant que la configuration de
sécurité de votre hôte Hyper-V n’a pas changé. Le mode hors connexion fonctionne en
mettant en cache une version spéciale du protecteur de clé TPM de machine virtuelle
sur l’hôte Hyper-V. Le logiciel de protection de clé est chiffré dans la configuration de
sécurité actuelle de l’hôte (à l’aide de la clé d’identité de sécurité basée sur la
virtualisation). Si votre hôte ne parvient pas à communiquer avec SGH et que sa
configuration de sécurité n’a pas changé, il peut utiliser le protecteur de clé mis en
cache pour démarrer la machine virtuelle dotée d’une protection maximale. Lorsque les
paramètres de sécurité changent sur le système, comme lors de l’application d’une
nouvelle stratégie d’intégrité du code ou de la désactivation du démarrage sécurisé, les
protecteurs de clés mis en cache sont invalidés et l’hôte doit attester auprès d’un SGH
avant que les machines virtuelles dotées d’une protection maximale puissent être
redémarrées hors connexion.
Le mode hors connexion nécessite la build 17609 ou ultérieure de Windows Server
Insider Preview pour le cluster Service Guardian hôte et l’hôte Hyper-V. Il est contrôlé
par une stratégie sur SGH, qui est désactivée par défaut. Pour activer la prise en charge
du mode hors connexion, exécutez la commande suivante sur un nœud SGH :

PowerShell

Set-HgsKeyProtectionConfiguration -AllowKeyMaterialCaching:$true

Étant donné que les protecteurs de clés pouvant être mis en cache sont propres à
chaque machine virtuelle dotée d’une protection maximale, vous devez arrêter
complètement (et non redémarrer) et démarrer vos machines virtuelles dotées d’une
protection maximale pour obtenir un protecteur de clé pouvant être mis en cache une
fois que ce paramètre est activé sur SGH. Si votre machine virtuelle dotée d’une
protection maximale migre vers un hôte Hyper-V exécutant une version antérieure de
Windows Server ou obtient un nouveau protecteur de clés à partir d’une version
antérieure de SGH, elle ne pourra pas démarrer elle-même en mode hors connexion,
mais pourra continuer à s’exécuter en mode en ligne lorsque l’accès à SGH est
disponible.
Mise à niveau d’une structure protégée
vers Windows Server 2019
Article • 17/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cet article décrit les étapes nécessaires pour mettre à niveau une structure protégée
existante de Windows Server 2016, Windows Server version 1709 ou Windows Server
version 1803 vers Windows Server 2019.

Nouveautés de Windows Server 2019

Lorsque vous exécutez une structure protégée sur Windows Server 2019, vous pouvez
tirer parti de plusieurs nouvelles fonctionnalités :

L’attestation de clé d’hôte est notre mode d’attestation le plus récent. Il est conçu pour
faciliter l’exécution de machines virtuelles dotées d’une protection maximale lorsque vos
hôtes Hyper-V ne disposent pas d’appareils TPM 2.0 disponibles pour l’attestation TPM.
L’attestation de clé d’hôte utilise des paires de clés pour authentifier les hôtes auprès de
SGH, en supprimant l’obligation de joindre les hôtes à un domaine Active Directory, en
éliminant l’approbation AD entre SGH et la forêt d’entreprise et en réduisant le nombre
de ports de pare-feu ouverts. L’attestation de clé d’hôte remplace l’attestation
Active Directory, qui est déconseillée dans Windows Server 2019.

Version de l’attestation v2 : pour prendre en charge l’attestation de clé d’hôte et les

nouvelles fonctionnalités à venir, nous avons introduit le contrôle de version dans SGH.
Une nouvelle installation de SGH sur Windows Server 2019 entraîne l’utilisation de
l’attestation v2 par le serveur, ce qui signifie qu’il peut prendre en charge l’attestation de
clé d’hôte pour les hôtes Windows Server 2019 tout en prenant en charge les hôtes v1
sur Windows Server 2016. Les mises à niveau sur place vers Windows Server 2019
restent à la version 1 jusqu’à ce que vous activiez manuellement la version 2. La plupart
des applets de commande possèdent désormais un paramètre -HgsVersion qui vous
permet d’indiquer si vous souhaitez utiliser des stratégies d’attestation héritées ou
modernes.

Prise en charge des machines virtuelles Linux dotées d’une protection maximale : les
hôtes Hyper-V exécutant Windows Server 2019 peuvent exécuter des machines
virtuelles Linux dotées d’une protection maximale. Bien que les machines virtuelles Linux
dotées d’une protection maximale soient présentes depuis Windows Server
version 1709, Windows Server 2019 est la première version du canal de maintenance à
long terme qui les prend en charge.

Améliorations apportées aux succursales : nous avons facilité l’exécution de machines

virtuelles dotées d’une protection maximale dans les succursales avec la prise en charge
de ces machines virtuelles hors connexion, ainsi que des configurations de secours sur
les hôtes Hyper-V.

Liaison d’hôte TPM : pour les charges de travail les plus sécurisées, où vous souhaitez
qu’une machine virtuelle dotée d’une protection maximale s’exécute uniquement sur le
premier hôte sur lequel elle a été créée, mais pas sur un autre, vous pouvez maintenant
lier la machine virtuelle à cet hôte à l’aide du module TPM de l’hôte. Il est préférable de
l’utiliser pour les succursales et les stations de travail à accès privilégié, plutôt que pour
les charges de travail de centre de données générales qui doivent migrer d’un hôte à un
autre.

Matrice de compatibilité
Avant de mettre à niveau votre structure protégée vers Windows Server 2019, passez en
revue la matrice de compatibilité suivante pour déterminer si votre configuration est
prise en charge.

SGH WS2016 SGH WS2019

Hôte Hyper-V WS2016 Prise en charge Pris en charge1

Hôte Hyper-V WS2019 Non pris en charge2 Prise en charge

1
L’attestation des hôtes Windows Server 2016 peut uniquement se faire auprès de
serveurs SGH Windows Server 2019 à l’aide du protocole d’attestation v1. Les nouvelles
fonctionnalités qui sont exclusivement disponibles dans le protocole d’attestation v2, y
compris l’attestation de clé d’hôte, ne sont pas prises en charge pour les hôtes
Windows Server 2016.

2
Microsoft a connaissance d’un problème empêchant l’attestation auprès d’un serveur
SGH Windows Server 2016 des hôtes Windows Server 2019 utilisant l’attestation TPM.
Ce problème sera résolu dans une mise à jour ultérieure pour Windows Server 2016.

Mise à niveau de SGH vers Windows

Server 2019
Nous vous recommandons de mettre à niveau votre cluster SGH vers
Windows Server 2019 avant de mettre à niveau vos hôtes Hyper-V afin de vous assurer
que l’attestation de tous les hôtes, qu’ils exécutent Windows Server 2016 ou 2019,
puisse continuer à se faire avec succès.

La mise à niveau de votre cluster SGH vous oblige à supprimer temporairement un

nœud du cluster à la fois pendant la mise à niveau. Cela réduit la capacité de votre
cluster à répondre aux demandes de vos hôtes Hyper-V et peut entraîner des temps de
réponse lents ou des pannes de service pour vos locataires. Vérifiez que vous disposez
d’une capacité suffisante pour gérer vos demandes d’attestation et de mise en
production de clé avant de mettre à niveau un serveur SGH.

Pour mettre à niveau votre cluster SGH, procédez comme suit sur chaque nœud de
votre cluster, un nœud à la fois :

1. Supprimez le serveur SGH de votre cluster en exécutant Clear-HgsServer dans une

invite PowerShell avec élévation de privilèges. Cet applet de commande supprime
le magasin SGH répliqué, les sites web SGH et le nœud du cluster de basculement.
2. Si votre serveur SGH est un contrôleur de domaine (configuration par défaut), vous
devez exécuter adprep /forestprep et adprep /domainprep sur le premier nœud
mis à niveau pour préparer le domaine à une mise à niveau du système
d’exploitation. Pour plus d’informations, voir la documentation sur la mise à niveau
d’Active Directory Domain Services (AD DS).
3. Effectuez une mise à niveau sur place vers Windows Server 2019.
4. Exécutez Initialize-HgsServer pour joindre à nouveau le nœud au cluster.

Une fois que tous les nœuds ont été mis à niveau vers Windows Server 2019, vous
pouvez éventuellement mettre à niveau SGH vers la version 2 pour prendre en charge
de nouvelles fonctionnalités telles que l’attestation de clé d’hôte.

PowerShell

Set-HgsServerVersion v2

Mettre à niveau des hôtes Hyper-V vers

Windows Server 2019
Avant de mettre à niveau vos hôtes Hyper-V vers Windows Server 2019, vérifiez que
votre cluster SGH est déjà mis à niveau vers Windows Server 2019 et que vous avez
déplacé toutes les machines virtuelles hors du serveur Hyper-V.
 1. Si vous utilisez les stratégies d’intégrité du code de Contrôle d’application
Windows Defender sur votre serveur (c’est toujours le cas lors de l’utilisation de
l’attestation TPM), assurez-vous que la stratégie est en mode audit ou qu’elle est
désactivée avant de tenter de mettre à niveau le serveur. Apprendre à désactiver
une stratégie WDAC
2. Suivez les instructions du contenu de mise à niveau de Windows Server pour
mettre à niveau votre hôte vers Windows Server 2019. Si votre hôte Hyper-V fait
partie d’un cluster de basculement, envisagez une mise à niveau propagée de
système d’exploitation de cluster.
3. Testez et réactivez votre stratégie Contrôle d’application Windows Defender, si
vous en aviez une activée avant la mise à niveau.
4. Exécutez Get-HgsClientConfiguration pour vérifier si IsHostGuarded = True, ce qui
signifie que l’attestation de l’hôte auprès de votre serveur SGH est réussie.
5. Si vous utilisez l’attestation TPM, vous devrez peut-être recréer la base TPM ou la
stratégie d’intégrité du code après la mise à niveau pour réussir l’attestation.
6. Vous pouvez maintenant exécuter à nouveau des machines virtuelles dotées d’une
protection maximale sur l’hôte.

Passer à l’attestation de clé d’hôte

Procédez comme suit si vous exécutez actuellement une attestation basée sur Active
Directory et que vous souhaitez effectuer une mise à niveau vers l’attestation de clé
d’hôte. Notez que l’attestation basée sur Active Directory est déconseillée dans
Windows Server 2019 et qu’elle est susceptible d’être supprimée dans une version
ultérieure.

1. Vérifiez que votre serveur SGH fonctionne en mode d’attestation v2 en exécutant

la commande suivante. L’attestation des hôtes v1 existants continue à se faire,
même lorsque le serveur SGH est mis à niveau vers la version 2.

PowerShell

Set-HgsServerVersion v2

2. Générez des clés d’hôte à partir de chacun de vos hôtes Hyper-V et inscrivez-les
auprès de SGH. Étant donné que SGH fonctionne toujours en mode
Active Directory, vous recevrez un avertissement indiquant que les nouvelles clés
d’hôte ne sont pas immédiatement effectives. Cela est intentionnel. En effet, il est
préférable de ne pas passer en mode de clé d’hôte tant que l’attestation de tous
vos hôtes avec des clés d’hôte n’a pas réussi.
3. Une fois les clés d’hôte inscrites pour chaque hôte, vous pouvez configurer SGH de
façon à utiliser le mode d’attestation de clé d’hôte :

PowerShell

Set-HgsServer -TrustHostKey

Si vous rencontrez des problèmes avec le mode de clé d’hôte et que vous devez
revenir à l’attestation basée sur Active Directory, exécutez la commande suivante
sur SGH :

PowerShell

Set-HgsServer -TrustActiveDirectory
Résoudre les problèmes d’une
infrastructure protégée
Article • 22/08/2024

Les rubriques suivantes expliquent comment résoudre les problèmes liés à une
infrastructure protégée :

Résoudre les problèmes à l’aide de l’outil de diagnostic Guarded Fabric

Résoudre les problèmes liés au service Guardian hôte
Résoudre les problèmes liés aux hôtes protégés
Résoudre les problèmes liés aux machines virtuelles dotées d’une protection
maximale

Références supplémentaires
Déploiement du Service Guardian hôte pour les hôtes Service Guardian et les VM
dotées d’une protection maximale
Gestion d’une infrastructure protégée

Commentaires
Cette page a-t-elle été utile ?  Yes  No

Indiquer des commentaires sur le produit

Résoudre les problèmes à l’aide de
l’outil de diagnostic Guarded Fabric
Article • 22/08/2024

Cet article décrit l’utilisation de l’outil de diagnostic guarded Fabric pour identifier et
corriger les défaillances courantes dans le déploiement, la configuration et le
fonctionnement continu de l’infrastructure de structure protégée. Cela inclut le service
Guardian hôte (SGH), tous les hôtes protégés et les services de prise en charge tels que
DNS et Active Directory.

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

L’outil de diagnostic peut être utilisé pour effectuer une première passe au tri d’une
structure protégée défaillante, fournissant aux administrateurs un point de départ pour
résoudre les pannes et identifier les ressources mal configurées. L’outil n’est pas un
remplacement pour une compréhension sonore de l’exploitation d’une structure
protégée et sert uniquement à vérifier rapidement les problèmes les plus courants
rencontrés pendant les opérations quotidiennes.

Vous trouverez la documentation complète des applets de commande utilisées dans cet
article dans la référence du module HgsDiagnostics.

７ Notes

Lors de l’exécution de l’outil de diagnostic Guarded Fabric (Get-HgsTrace -

RunDiagnostics), un état incorrect peut être retourné, affirmant que la
configuration HTTPS est interrompue lorsqu’elle n’est pas endommagée ou n’est
pas utilisée. Cette erreur peut être retournée quel que soit le mode d’attestation de
SGH. Les causes racines possibles sont les suivantes :

HTTPS est en effet mal configuré/endommagé

Vous utilisez une attestation approuvée par l’administrateur et la relation
d’approbation est rompue. Il s’agit de savoir si HTTPS est configuré
correctement, de manière incorrecte ou non en cours d’utilisation. Notez que
les diagnostics retournent uniquement cet état incorrect lors du ciblage d’un
hôte Hyper-V. Si les diagnostics ciblent le service Guardian hôte, l’état
retourné est correct.
Démarrage rapide
Vous pouvez diagnostiquer un hôte protégé ou un nœud SGH en appelant ce qui suit à
partir d’une session Windows PowerShell avec des privilèges d’administrateur local :

PowerShell

Get-HgsTrace -RunDiagnostics -Detailed

Cela détecte automatiquement le rôle de l’hôte actuel et diagnostique les problèmes

pertinents qui peuvent être détectés automatiquement. Tous les résultats générés
pendant ce processus sont affichés en raison de la présence du commutateur -
Detailed .

Le reste de cette rubrique fournit une procédure pas à pas détaillée sur l’utilisation
avancée de Get-HgsTrace pour effectuer des opérations telles que le diagnostic de
plusieurs hôtes à la fois et la détection d’une configuration complexe entre nœuds.

Vue d’ensemble des diagnostics

Les diagnostics de structure protégée sont disponibles sur n’importe quel hôte sur
lequel les outils et fonctionnalités liés aux machines virtuelles dotées d’une protection
maximale sont installés, y compris les hôtes exécutant Server Core. Actuellement, les
diagnostics sont inclus avec les fonctionnalités/packages suivants :

Rôle Service Guardian hôte

Support Hyper-V pour Guardian hôte
Outils de protection d'ordinateur virtuel pour la gestion d'infrastructure
Outils d’administration de serveur distant (RSAT)

Cela signifie que les outils de diagnostic seront disponibles sur tous les hôtes protégés,
les nœuds SGH, certains serveurs d’administration d’infrastructure et toutes les stations
de travail Windows 10 sur lesquels RSAT est installé. Les diagnostics peuvent être
appelés à partir de l’une des machines ci-dessus avec l’intention de diagnostiquer
n’importe quel hôte ou nœud SGH protégé dans une infrastructure protégée ; à l’aide
de cibles de trace distantes, les diagnostics peuvent localiser et se connecter à des hôtes
autres que l’ordinateur exécutant des diagnostics.

Chaque hôte ciblé par les diagnostics est appelé « cible de trace ». Les cibles de trace
sont identifiées par leurs noms d’hôte et rôles. Les rôles décrivent la fonction qu’une
cible de trace donnée effectue dans une infrastructure protégée. Actuellement, les cibles
de trace prennent en charge les rôles HostGuardianService et GuardedHost . Notez qu’il
est possible qu’un hôte occupe plusieurs rôles à la fois et qu’il soit également pris en
charge par les diagnostics, mais cela ne doit pas être effectué dans les environnements
de production. Les hôtes SGH et Hyper-V doivent être toujours séparés et distincts.

Les administrateurs peuvent commencer toutes les tâches de diagnostic en exécutant

Get-HgsTrace . Cette applet de commande exécute deux fonctions distinctes basées sur

les commutateurs fournis au moment de l’exécution : collecte de traces et diagnostic.

Ces deux ensembles constituent l’intégralité de l’outil de diagnostic de l’infrastructure
protégée. Bien qu’ils ne soient pas explicitement requis, les diagnostics les plus utiles
nécessitent des traces qui ne peuvent être collectées qu’avec des informations
d’identification d’administrateur sur la cible de trace. Si des privilèges insuffisants sont
détenus par l’utilisateur qui exécute la collecte de traces, les traces nécessitant une
élévation échouent tandis que toutes les autres passent. Cela permet un diagnostic
partiel dans le cas où un opérateur sous-privilégié effectue un triage.

Collecte de traces
Par défaut, Get-HgsTrace collecte uniquement les traces et les enregistre dans un
dossier temporaire. Les traces prennent la forme d’un dossier, nommé d’après l’hôte
ciblé, rempli de fichiers spécialement mis en forme qui décrivent comment l’hôte est
configuré. Les traces contiennent également des métadonnées qui décrivent comment
les diagnostics ont été appelés pour collecter les traces. Ces données sont utilisées par
les diagnostics pour réalimenter des informations sur l’hôte lors de l’exécution d’un
diagnostic manuel.

Si nécessaire, les traces peuvent être examinées manuellement. Tous les formats sont
lisibles par l’homme (XML) ou peuvent être facilement inspectés à l’aide d’outils
standard (par exemple, des certificats X509 et des extensions Windows Crypto Shell).
Notez toutefois que les traces ne sont pas conçues pour le diagnostic manuel et qu’il est
toujours plus efficace de traiter les traces avec les installations de diagnostic de Get-
HgsTrace .

Les résultats de l’exécution de la collection de traces ne font aucune indication quant à

l’intégrité d’un hôte donné. Ils indiquent simplement que les traces ont été collectées
avec succès. Il est nécessaire d’utiliser les installations de diagnostic de Get-HgsTrace
déterminer si les traces indiquent un environnement défaillant.

À l’aide du paramètre -Diagnostic , vous pouvez restreindre la collecte de traces

uniquement aux traces requises pour faire fonctionner les diagnostics spécifiés. Cela
réduit la quantité de données collectées, ainsi que les autorisations requises pour
appeler des diagnostics.
Diagnostic
Les traces collectées peuvent être diagnostiquées en fournissant Get-HgsTrace
l’emplacement des traces via le paramètre -Path et en spécifiant le commutateur -
RunDiagnostics . En outre, Get-HgsTrace peut effectuer la collecte et le diagnostic en une

seule passe en fournissant le commutateur -RunDiagnostics et une liste de cibles de

trace. Si aucune cible de trace n’est fournie, l’ordinateur actuel est utilisé comme cible
implicite, son rôle étant déduit en inspectant les modules Windows PowerShell installés.

Le diagnostic fournit des résultats dans un format hiérarchique montrant les cibles de
trace, les jeux de diagnostics et les diagnostics individuels qui sont responsables d’un
échec particulier. Les échecs incluent des recommandations de correction et de
résolution si une décision peut être prise quant à la prochaine action à entreprendre. Par
défaut, les résultats transmis et non pertinents sont masqués. Pour voir tout ce qui est
testé par les diagnostics, spécifiez le commutateur -Detailed . Cela entraîne l’affichage
de tous les résultats indépendamment de leur état.

Il est possible de restreindre l’ensemble des diagnostics exécutés à l’aide du -

Diagnostic paramètre. Cela vous permet de spécifier les classes de diagnostic à exécuter

sur les cibles de trace et de supprimer toutes les autres. Parmi les exemples de classes
de diagnostic disponibles, citons la mise en réseau, les meilleures pratiques et le
matériel client. Consultez la documentation sur les applets de commande pour trouver
une liste à jour des diagnostics disponibles.

２ Avertissement

Les diagnostics ne sont pas un remplacement d’un pipeline de surveillance et de

réponse aux incidents fort. Il existe un package System Center Operations Manager
disponible pour la surveillance des structures protégées, ainsi que différents canaux
du journal des événements qui peuvent être surveillés pour détecter les problèmes
plus tôt. Les diagnostics peuvent ensuite être utilisés pour trier rapidement ces
échecs et établir une ligne de conduite.

Ciblage des diagnostics

Get-HgsTrace fonctionne sur des cibles de trace. Une cible de trace est un objet qui

correspond à un nœud SGH ou à un hôte protégé à l’intérieur d’une infrastructure

protégée. Il peut être considéré comme une extension à un PSSession , qui inclut des
informations requises uniquement par les diagnostics tels que le rôle de l’hôte dans
l’infrastructure. Les cibles peuvent être générées implicitement (par exemple, diagnostic
local ou manuel) ou explicitement avec l’applet de New-HgsTraceTarget commande.

Diagnostic local
Par défaut, Get-HgsTrace cible l’hôte local (c’est-à-dire où l’applet de commande est
appelée). C’est ce qu’on appelle la cible locale implicite. La cible locale implicite est
utilisée uniquement quand aucune cible n’est fournie dans le paramètre -Target et
qu’aucune trace préexistante n’est trouvée dans le -Path .

La cible locale implicite utilise l’inférence de rôle pour déterminer le rôle que joue l’hôte
actuel dans l’infrastructure protégée. Cela est basé sur les modules Windows PowerShell
installés, qui correspondent approximativement aux fonctionnalités installées sur le
système. La présence du HgsServer module entraîne le rôle HostGuardianService de la
cible de trace et la présence du HgsClient module entraîne le rôle GuardedHost de la
cible de trace. Il est possible qu’un hôte donné ait les deux modules présents dans le cas
où il sera traité comme un HostGuardianService et un GuardedHost .

Par conséquent, l’appel par défaut des diagnostics pour collecter des traces localement :

PowerShell

Get-HgsTrace

Cela équivaut à ce qui suit :

PowerShell

New-HgsTraceTarget -Local | Get-HgsTrace

 Conseil

Get-HgsTrace peut accepter des cibles via le pipeline ou directement via le

paramètre -Target . Il n’y a aucune différence entre les deux sur le plan
opérationnel.

Diagnostic à distance à l’aide de cibles de trace

Il est possible de diagnostiquer à distance un hôte en générant des cibles de trace avec
des informations de connexion à distance. Tout ce qui est nécessaire, c’est le nom d’hôte
et un ensemble d’informations d’identification capables de se connecter à l’aide de
Windows PowerShell communication à distance.

PowerShell

$server = New-HgsTraceTarget -HostName "[Link]" -Role

HostGuardianService -Credential (Enter-Credential)
Get-HgsTrace -RunDiagnostics -Target $server

Cet exemple génère une invite pour collecter les informations d’identification de
l’utilisateur distant, puis les diagnostics s’exécutent à l’aide de l’hôte distant pour hgs-
[Link] terminer la collecte de traces. Les traces résultantes sont

téléchargées sur l’hôte local, puis diagnostiquées. Les résultats du diagnostic sont
présentés de la même façon que lors de l’exécution d’un diagnostic local . De même, il
n’est pas nécessaire de spécifier un rôle, car il peut être déduit en fonction des modules
Windows PowerShell installés sur le système distant.

Le diagnostic à distance utilise Windows PowerShell communication à distance pour

tous les accès à l’hôte distant. Par conséquent, il est requis que la cible de trace ait activé
la communication à distance Windows PowerShell (voir Activer PSRemoting) et que
l’hôte local est correctement configuré pour lancer des connexions à la cible.

７ Notes

Dans la plupart des cas, il est nécessaire que le localhost soit une partie de la même
forêt Active Directory et qu’un nom d’hôte DNS valide est utilisé. Si votre
environnement utilise un modèle de fédération plus complexe ou si vous souhaitez
utiliser des adresses IP directes pour la connectivité, vous devrez peut-être
effectuer une configuration supplémentaire, telle que la définition des hôtes
approuvés WinRM.

Vous pouvez vérifier qu’une cible de trace est correctement instanciée et configurée
pour accepter les connexions à l’aide de l’applet de commande Test-HgsTraceTarget :

PowerShell

$server = New-HgsTraceTarget -HostName "[Link]" -Role

HostGuardianService -Credential (Enter-Credential)
$server | Test-HgsTraceTarget

Cette applet de commande retourne $True si et uniquement si elle Get-HgsTrace serait

en mesure d’établir une session de diagnostic à distance avec la cible de trace. En cas
d’échec, cette applet de commande retourne des informations d’état pertinentes pour la
résolution des problèmes supplémentaires de la connexion à distance Windows
PowerShell.

Informations d’identification implicites

Lors de l’exécution d’un diagnostic distant à partir d’un utilisateur disposant de
privilèges suffisants pour se connecter à distance à la cible de trace, il n’est pas
nécessaire de fournir des informations d’identification à New-HgsTraceTarget . L’applet
Get-HgsTrace de commande réutilise automatiquement les informations d’identification

de l’utilisateur qui a appelé l’applet de commande lors de l’ouverture d’une connexion.

２ Avertissement

Certaines restrictions s’appliquent à la réutilisation des informations d’identification,

en particulier lors de l’exécution d’un « deuxième tronçon ». Cela se produit lors de
la tentative de réutilisation des informations d’identification à partir d’une session à
distance vers un autre ordinateur. Il est nécessaire de configurer CredSSP pour
prendre en charge ce scénario, mais cela n’est pas dans l’étendue de la gestion et
de la résolution des problèmes de la structure protégée.

Utilisation de Windows PowerShell Just Enough Administration

(JEA) et de diagnostics
Le diagnostic à distance prend en charge l’utilisation de points de terminaison Windows
PowerShell limités par JEA. Par défaut, les cibles de trace distantes se connectent à l’aide
du point de terminaison par défaut [Link] . Si la cible de trace a le
HostGuardianService rôle, elle tente également d’utiliser le [Link] point

de terminaison, qui est configuré lors de l’installation du SGH.

Si vous souhaitez utiliser un point de terminaison personnalisé, vous devez spécifier le

nom de configuration de session lors de la construction de la cible de trace à l’aide du
paramètre -PSSessionConfigurationName , comme ci-dessous :

PowerShell

New-HgsTraceTarget -HostName "[Link]" -Role

HostGuardianService -Credential (Enter-Credential) -
PSSessionConfigurationName "[Link]"
Diagnostic de plusieurs hôtes
Vous pouvez passer plusieurs cibles de trace à Get-HgsTrace la fois. Cela inclut une
combinaison de cibles locales et distantes. Chaque cible est tracée à son tour, puis les
traces de chaque cible seront diagnostiqués simultanément. L’outil de diagnostic peut
utiliser la connaissance accrue de votre déploiement pour identifier des configurations
complexes entre nœuds qui ne seraient pas détectables. L’utilisation de cette
fonctionnalité nécessite uniquement de fournir des traces à partir de plusieurs hôtes
simultanément (dans le cas d’un diagnostic manuel) ou en ciblant plusieurs hôtes lors de
l’appel Get-HgsTrace (dans le cas d’un diagnostic à distance).

Voici un exemple d’utilisation du diagnostic à distance pour trier une structure

composée de deux nœuds SGH et de deux hôtes protégés, où l’un des hôtes protégés
est utilisé pour lancer Get-HgsTrace .

PowerShell

$hgs01 = New-HgsTraceTarget -HostName "[Link]" -

Credential (Enter-Credential)
$hgs02 = New-HgsTraceTarget -HostName "[Link]" -
Credential (Enter-Credential)
$gh01 = New-HgsTraceTarget -Local
$gh02 = New-HgsTraceTarget -HostName "[Link]"
Get-HgsTrace -Target $hgs01,$hgs02,$gh01,$gh02 -RunDiagnostics

７ Notes

Vous n’avez pas besoin de diagnostiquer l’ensemble de votre structure protégée

lors du diagnostic de plusieurs nœuds. Dans de nombreux cas, il est suffisant
d’inclure tous les nœuds susceptibles d’être impliqués dans une condition d’échec
donnée. Il s’agit généralement d’un sous-ensemble des hôtes protégés et d’un
certain nombre de nœuds du cluster SGH.

Diagnostic manuel à l’aide de traces

enregistrées
Parfois, vous souhaiterez peut-être réexécuter les diagnostics sans collecter de traces, ou
vous n’avez peut-être pas les informations d’identification nécessaires pour
diagnostiquer à distance tous les hôtes de votre infrastructure simultanément. Le
diagnostic manuel est un mécanisme par lequel vous pouvez toujours effectuer un
triage de structure entière à l’aide de Get-HgsTrace , mais sans utiliser la collecte de
traces à distance.

Avant d’effectuer un diagnostic manuel, vous devez vous assurer que les administrateurs
de chaque hôte de l’infrastructure qui seront triés sont prêts et prêts à exécuter des
commandes en votre nom. La sortie de trace de diagnostic n’expose pas d’informations
généralement affichées comme sensibles, mais il incombe à l’utilisateur de déterminer
s’il est sûr d’exposer ces informations à d’autres personnes.

７ Notes

Les traces ne sont pas anonymisées et révèlent la configuration réseau, les

paramètres PKI et d’autres configurations qui sont parfois considérées comme des
informations privées. Par conséquent, les traces ne doivent être transmises qu’aux
entités approuvées au sein d’une organisation et ne doivent jamais être publiées
publiquement.

Les étapes d’exécution d’un diagnostic manuel sont les suivantes :

1. Demandez à chaque administrateur hôte d’exécuter Get-HgsTrace en spécifiant un

diagnostic connu -Path et la liste des diagnostics que vous envisagez d’exécuter
sur les traces résultantes. Par exemple :

PowerShell

Get-HgsTrace -Path C:\Traces -Diagnostic Networking,BestPractices

2. Demandez à chaque administrateur hôte d’empaqueter le dossier de traces

résultant et de vous l’envoyer. Ce processus peut être piloté par courrier
électronique, via des partages de fichiers ou tout autre mécanisme basé sur les
stratégies et procédures d’exploitation établies par votre organisation.

3. Fusionnez toutes les traces reçues dans un dossier unique, sans autre contenu ou
dossier.

Par exemple, supposons que vos administrateurs vous envoient des traces
collectées à partir de quatre machines nommées HGS-01, HGS-02, RR1N2608-12
et RR1N2608-13. Chaque administrateur vous aurait envoyé un dossier du même
nom. Vous devez assembler une structure de répertoires qui apparaît comme suit :

Output
 FabricTraces
|- HGS-01
| |- [Link]
| |- [Link]
| |- [any other trace files for this host]
|- HGS-02
| |- [...]
|- RR1N2608-12
| |- [...]
|- RR1N2608-13
|- [..]

4. Exécutez des diagnostics, en fournissant le chemin d’accès au dossier de traces

assemblés sur le paramètre -Path et en spécifiant le commutateur -
RunDiagnostics ainsi que les diagnostics pour lesquels vous avez demandé à vos

administrateurs de collecter des traces. Les diagnostics supposent qu’il ne peut pas
accéder aux hôtes trouvés à l’intérieur du chemin et tente donc d’utiliser
uniquement les traces précollectées. Si des traces sont manquantes ou
endommagées, les diagnostics échouent uniquement aux tests affectés et se
poursuivent normalement. Par exemple :

PowerShell

Get-HgsTrace -RunDiagnostics -Diagnostic Networking,BestPractices -Path

".\FabricTraces"

Mélange des traces enregistrées avec des cibles

supplémentaires
Dans certains cas, vous pouvez avoir un ensemble de traces précollectées que vous
souhaitez augmenter avec des traces d’hôte supplémentaires. Il est possible de
combiner des traces précollectées avec des cibles supplémentaires qui seront tracées et
diagnostiqués dans un seul appel de diagnostics.

En suivant les instructions pour collecter et assembler un dossier de trace spécifié ci-
dessus, appelez Get-HgsTrace avec des cibles de trace supplémentaires introuvables
dans le dossier de trace précollecté :

PowerShell

$hgs03 = New-HgsTraceTarget -HostName "[Link]" -

Credential (Enter-Credential)
Get-HgsTrace -RunDiagnostics -Target $hgs03 -Path .\FabricTraces
L’applet de commande de diagnostic identifie tous les hôtes précollectés et l’hôte
supplémentaire qui doit toujours être suivi et effectue le suivi nécessaire. La somme de
toutes les traces précollectées et fraîchement collectées sera ensuite diagnostiqué. Le
dossier de traces résultant contient à la fois les anciennes et les nouvelles traces.

Problèmes connus
Le module de diagnostics d’infrastructure protégée présente des limitations connues
lorsqu’il est exécuté sur Windows Server 2019 ou Windows 10, version 1809 et les
versions plus récentes du système d’exploitation. L’utilisation des fonctionnalités
suivantes peut entraîner des résultats erronés :

Attestation de clé d’hôte

Configuration SGH d’attestation uniquement (pour les scénarios de SQL Server
Always Encrypted)
Utilisation d’artefacts de stratégie v1 sur un serveur SGH où la stratégie
d’attestation par défaut est v2

Une défaillance Get-HgsTrace lors de l’utilisation de ces fonctionnalités n’indique pas

nécessairement que le serveur SGH ou l’hôte protégé est mal configuré. Utilisez d’autres
outils de diagnostic, comme Get-HgsClientConfiguration sur un hôte protégé, pour
tester si un hôte a réussi l’attestation.

Commentaires
Cette page a-t-elle été utile ?  Yes  No

Indiquer des commentaires sur le produit

Résoudre les problèmes liés au service
Guardian hôte
Article • 22/08/2024

Cet article décrit la résolution des problèmes courants rencontrés lors du déploiement
ou de l’exploitation d’un serveur SGH (Host Guardian Service) dans une infrastructure
protégée.

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Si vous n’êtes pas sûr de la nature de votre problème, essayez d’abord d’exécuter les
diagnostics de structure protégée sur vos serveurs HGS et les hôtes Hyper-V pour
limiter les causes potentielles .

Certificats
SGH nécessite plusieurs certificats pour fonctionner, notamment le certificat de
chiffrement et de signature configuré par l’administrateur, ainsi qu’un certificat
d’attestation géré par SGH lui-même. Si ces certificats sont configurés de manière
incorrecte, HGS ne peut pas traiter les demandes des hôtes Hyper-V souhaitant attester
ou déverrouiller des protecteurs de clé pour les machines virtuelles protégées. Les
sections suivantes couvrent les problèmes courants liés aux certificats configurés sur
SGH.

Autorisations de certificat
SGH doit être en mesure d’accéder aux clés publiques et privées des certificats de
chiffrement et de signature ajoutés à SGH par l’empreinte numérique du certificat. Plus
précisément, le compte de service managé de groupe (gMSA) qui exécute le service
SGH doit accéder aux clés. Pour rechercher le gMSA utilisé par SGH, exécutez la
commande suivante dans une invite PowerShell avec élévation de privilèges sur votre
serveur SGH :

PowerShell

(Get-IISAppPool -Name KeyProtection).[Link]

La façon dont vous accordez au compte gMSA l’accès à l’utilisation de la clé privée
dépend de l’emplacement où la clé est stockée : sur l’ordinateur en tant que fichier de
certificat local, sur un module de sécurité matériel (HSM) ou à l’aide d’un fournisseur de
stockage de clés tiers personnalisé.

Accorder l’accès aux clés privées sauvegardées par logiciel

Si vous utilisez un certificat auto-signé ou un certificat émis par une autorité de

certification qui n’est pas stockée dans un module de sécurité matériel ou un fournisseur
de stockage de clés personnalisées, vous pouvez modifier les autorisations de clé privée
en effectuant les étapes suivantes :

1. Ouvrez le gestionnaire de certificats local ([Link]).

2. Développez Certificats personnels>et recherchez le certificat de signature ou de
chiffrement que vous souhaitez mettre à jour.
3. Cliquez avec le bouton droit sur le certificat et sélectionnez Toutes les
tâches>gérer les clés privées.
4. Sélectionnez Ajouter pour accorder à un nouvel utilisateur l’accès à la clé privée du
certificat.
5. Dans le sélecteur d’objets, entrez le nom du compte gMSA pour SGH trouvé
précédemment, puis sélectionnez OK.
6. Vérifiez que le gMSA a l’accès Lecture sur la clé privée.
7. Cliquez sur OK pour fermer la fenêtre Autorisations.

Si vous exécutez HGS sur Server Core ou que vous gérez le serveur à distance, vous ne
pourrez pas gérer les clés privées à l’aide du gestionnaire de certificats local. Au lieu de
cela, vous devez télécharger le module PowerShell Outils Guarded Fabric, qui vous
permettra de gérer les autorisations dans PowerShell.

1. Ouvrez une console PowerShell avec élévation de privilèges sur la machine Server
Core ou utilisez la communication à distance PowerShell avec un compte disposant
d’autorisations d’administrateur local sur SGH.
2. Exécutez les commandes suivantes pour installer le module PowerShell Guarded
Fabric Tools et accorder au compte gMSA l’accès à la clé privée.

PowerShell

$certificateThumbprint = '<ENTER CERTIFICATE THUMBPRINT HERE>'

# Install the Guarded Fabric Tools module, if necessary

Install-Module -Name GuardedFabricTools -Repository PSGallery

# Import the module into the current session

Import-Module -Name GuardedFabricTools

# Get the certificate object

$cert = Get-Item "Cert:\LocalMachine\My\$certificateThumbprint"
 # Get the gMSA account name
$gMSA = (Get-IISAppPool -Name KeyProtection).[Link]

# Grant the gMSA read access to the certificate

$[Link] = $[Link] | Add-AccessRule $gMSA Read Allow

Accorder l’accès au HSM ou aux clés privées personnalisées

sauvegardées par un fournisseur

Si les clés privées de votre certificat sont sauvegardées par un module de sécurité
matériel (HSM) ou un fournisseur de stockage de clés personnalisé (KSP), le modèle
d’autorisation dépend de votre fournisseur de logiciels spécifique. Pour obtenir de
meilleurs résultats, consultez la documentation de votre fournisseur ou le site de
support pour plus d’informations sur la façon dont les autorisations de clé privée sont
gérées pour votre appareil/logiciel spécifique. Dans tous les cas, le gMSA utilisé par SGH
nécessite des autorisations de lecture sur les clés privées de chiffrement, de signature et
de certificat de communication afin qu’il puisse effectuer des opérations de signature et
de chiffrement.

Certains modules de sécurité matérielle ne prennent pas en charge l’octroi de comptes

d’utilisateur spécifiques l’accès à une clé privée ; ils autorisent plutôt l’accès au compte
d’ordinateur à toutes les clés d’un jeu de clés spécifique. Pour ces appareils, il est
généralement suffisant de donner à l’ordinateur l’accès à vos clés et HGS est en mesure
de tirer parti de cette connexion.

Conseils pour les HSM

Vous trouverez ci-dessous des options de configuration suggérées pour vous aider à
utiliser correctement les clés HSM avec SGH en fonction des expériences de Microsoft et
de ses partenaires. Ces conseils sont fournis pour votre commodité et ne sont pas
garantis être corrects au moment de la lecture, ni ne sont-ils approuvés par les
fabricants de HSM. Si vous avez d’autres questions, contactez le fabricant de votre HSM
pour obtenir des informations précises sur votre appareil spécifique.

ﾉ Agrandir le tableau

Marque/série Suggestion
HSM

Gemalto Vérifiez que la propriété Utilisation de la clé dans le fichier de demande de

SafeNet certificat est définie sur 0xa0, ce qui permet d’utiliser le certificat pour la
signature et le chiffrement. En outre, vous devez accorder au compte gMSA un
 Marque/série Suggestion
HSM

accès en lecture à la clé privée à l’aide de l’outil gestionnaire de certificats local

(voir les étapes ci-dessus).

nCipher nShield Vérifiez que chaque nœud SGH a accès au monde de la sécurité contenant les
clés de signature et de chiffrement. En outre, vous pourriez avoir besoin
d’accorder au gMSA un accès en lecture à la clé privée à l’aide du gestionnaire
de certificats local (voir les étapes ci-dessus).

Utimaco Vérifiez que la propriété Utilisation de la clé dans le fichier de demande de

CryptoServers certificat est définie sur 0x13, ce qui permet d’utiliser le certificat pour le
chiffrement, le déchiffrement et la signature.

Demandes de certificat
Si vous utilisez une autorité de certification pour émettre vos certificats dans un
environnement PKI (Public Key Infrastructure), vous devez vous assurer que votre
demande de certificat inclut la configuration minimale requise pour l’utilisation de ces
clés par HGS.

Certificats de signature

ﾉ Agrandir le tableau

Propriété CSR Valeur requise

Algorithm RSA

Taille de la clé Au moins 2 048 bits

Utilisation de la clé Signature/Sign/DigitalSignature

Certificats de chiffrement

ﾉ Agrandir le tableau

Propriété CSR Valeur requise

Algorithm RSA

Taille de la clé Au moins 2 048 bits

Utilisation de la clé Chiffrement/Chiffrement/DataEncipherment

Modèles services de certificats Active Directory
Si vous utilisez des modèles de certificat ADCS (Active Directory Certificate Services)
pour créer les certificats, nous vous recommandons d’utiliser un modèle avec les
paramètres suivants :

ﾉ Agrandir le tableau

Propriété de modèle Valeur requise

ADCS

Catégorie de Fournisseur de stockage de clés

fournisseur

Nom de l'algorithme RSA

Taille de clé minimale 2 048

Objectif Signature et chiffrement

Extension d’utilisation Signature numérique, chiffrement de clé, chiffrement des données («

des clés Autoriser le chiffrement des données utilisateur »)

Dérive temporelle
Si le temps de votre serveur a considérablement dérivé de celui d’autres nœuds SGH ou
hôtes Hyper-V dans votre infrastructure protégée, vous pouvez rencontrer des
problèmes avec la validité du certificat du signataire d’attestation. Le certificat de
signataire d’attestation est créé et renouvelé en arrière-plan sur SGH et est utilisé pour
signer les certificats d’intégrité émis aux hôtes protégés par le service d’attestation.

Pour actualiser le certificat du signataire d’attestation, exécutez la commande suivante

dans une invite PowerShell avec élévation de privilèges.

PowerShell

Start-ScheduledTask -TaskPath \Microsoft\Windows\HGSServer -TaskName

AttestationSignerCertRenewalTask

Vous pouvez également exécuter manuellement la tâche planifiée en ouvrant le

planificateur de tâches ([Link]), en accédant à la bibliothèque>du planificateur
de tâches Microsoft>Windows>HGSServer et en exécutant la tâche nommée
AttestationSignerCertRenewalTask.
Basculement des modes d’attestation
Si vous passez SGH du mode TPM au mode Active Directory ou vice versa à l’aide de
l’applet de commande Set-HgsServer , l’application du nouveau mode d’attestation peut
prendre jusqu’à 10 minutes pour chaque nœud de votre cluster SGH.

Il s’agit du comportement normal.

Il est conseillé de ne supprimer aucune stratégie autorisant les hôtes du mode

d’attestation précédent tant que vous n’avez pas vérifié que tous les hôtes sont
attestant correctement à l’aide du nouveau mode d’attestation.

Problème connu lors du passage du mode TPM au mode

AD
Si vous avez initialisé votre cluster SGH en mode TPM et passez ultérieurement en mode
Active Directory, il existe un problème connu qui empêche les autres nœuds de votre
cluster HGS de basculer vers le nouveau mode d’attestation. Pour vous assurer que tous
les serveurs SGH appliquent le mode d’attestation approprié, exécutez Set-HgsServer -
TrustActiveDirectory sur chaque nœud de votre cluster SGH.

Ce problème ne s’applique pas si vous passez du mode TPM au mode AD et que le

cluster a été configuré à l’origine en mode AD.

Vous pouvez vérifier le mode d’attestation de votre serveur SGH en exécutant Get-
HgsServer.

Stratégies de chiffrement du vidage de la

mémoire
Si vous essayez de configurer des stratégies de chiffrement de vidage de mémoire et
que vous ne voyez pas les stratégies de vidage HGS par défaut (Hgs_NoDumps,
Hgs_DumpEncryption et Hgs_DumpEncryptionKey) ou l’applet de commande de
stratégie de vidage ( Add-HgsAttestationDumpPolicy ), il est probable que vous n’ayez pas
la dernière mise à jour cumulative installée.

Pour résoudre ce problème, mettez à jour votre serveur SGH vers la dernière mise à jour
cumulative de Windows et activez les nouvelles stratégies d’attestation.

Veillez à mettre à jour vos hôtes Hyper-V vers la même mise à jour cumulative avant
d’activer les nouvelles stratégies d’attestation, car les hôtes qui n’ont pas les nouvelles
fonctionnalités de chiffrement de vidage installées échoueront probablement une fois la
stratégie SGH activée.

Messages d’erreur de certificat de clé

d’approbation
Lorsque vous inscrivez un hôte à l’aide de l’applet de commande Add-
HgsAttestationTpmHost , deux identificateurs TPM sont extraits du fichier
d’identificateur de plateforme fourni : le certificat de clé d’approbation (EKcert) et la clé
d’approbation publique (EKpub). Le certificat EK identifie le fabricant du module de
plateforme sécurisée, en fournissant des garanties que le module de plateforme
sécurisée est authentique et fabriqué selon la chaîne d’approvisionnement normale.
L’EKpub identifie de manière unique ce TPM spécifique, et c’est l’une des mesures que
SGH utilise pour accorder à un hôte l’accès permettant d’exécuter des machines
virtuelles dotées d’une protection maximale.

Vous recevrez une erreur lorsque vous inscrivez un hôte TPM si l’une des deux
conditions est vraie :

Le fichier d’identificateur de plateforme ne contient pas de certificat de clé

d’approbation.
Le fichier d’identificateur de plateforme contient un certificat de clé d’approbation,
mais ce certificat n’est pas approuvé sur votre système.

Certains fabricants de TPM n’incluent pas de certificats EK dans leurs modules TPM.

Si vous pensez que c’est le cas avec votre module TPM, vérifiez auprès de votre fabricant
d'ordinateurs OEM que vos TPM ne doivent pas avoir de certificat EK et utilisez
l’indicateur -Force pour inscrire manuellement l’hôte auprès de SGH. Si votre module
de plateforme sécurisée doit avoir un certificat EKcert mais qu’un certificat n’a pas été
trouvé dans le fichier d’identificateur de plateforme, vérifiez que vous utilisez une
console PowerShell d’administrateur (avec élévation de privilèges) lors de l’exécution de
Get-PlatformIdentifier sur l’hôte.

Si vous avez reçu l’erreur indiquant que votre certificat EKcert n’est pas approuvé,
vérifiez que vous avez installé le package de certificats racines TPM approuvés sur
chaque serveur SGH et que le certificat racine de votre fournisseur TPM est présent dans
le magasin « TrustedTPM_RootCA » de l’ordinateur local. Tous les certificats
intermédiaires applicables doivent également être installés dans le magasin «
TrustedTPM_IntermediateCA » sur l’ordinateur local. Après avoir installé les certificats
racine et intermédiaire, vous devez être en mesure d’exécuter Add-
HgsAttestationTpmHost correctement.

Privilèges de compte de service administré de

groupe (gMSA)
Le compte de service SGH (gMSA utilisé pour le pool d’applications Key Protection
Service dans IIS) doit recevoir le privilège Générer des audits de sécurité, également
appelé SeAuditPrivilege . Si ce privilège est manquant, la configuration SGH initiale
réussit et IIS démarre, mais le service de protection de clés n’est pas fonctionnel et
retourne l’erreur HTTP 500 (« Erreur du serveur dans l’application /KeyProtection »).
Vous pouvez également observer les messages d’avertissement suivants dans le journal
des événements d’application.

Output

[Link].Win32Exception (0x80004005): A required privilege is

not held by the client
at
[Link]
erAuditSource(String pszSourceName, SafeAuditProviderHandle&
phAuditProvider)
at
[Link]
AuditSource(String sourceName)

or

Output

Failed to register the security event source.

at
[Link](Http
Context context, HttpApplication app)
at [Link](IntPtr
appContext, HttpContext context, MethodInfo[] handlers)
at [Link](HttpApplicationState state,
MethodInfo[] handlers, IntPtr appContext, HttpContext context)
at [Link](IntPtr
appContext, HttpContext context)
at [Link](IntPtr
appContext)

Failed to register the security event source.

at
[Link]
AuditSource(String sourceName)
 at
[Link]
dit(EventLogEntryType eventType, UInt32 eventId, Object[] os)
at
[Link].Application_Start()

A required privilege is not held by the client

at
[Link]
erAuditSource(String pszSourceName, SafeAuditProviderHandle&
phAuditProvider)
at
[Link]
AuditSource(String sourceName)

En outre, vous remarquerez peut-être qu’aucune des applets de commande du service

de protection de clés (par exemple , Get-HgsKeyProtectionCertificate) ne fonctionne et
retourne plutôt des erreurs.

Pour résoudre ce problème, vous devez accorder à gMSA l’option « Générer des audits
de sécurité » ( SeAuditPrivilege ). Pour ce faire, vous pouvez utiliser la stratégie de
sécurité locale [Link] sur chaque nœud du cluster SGH ou la stratégie de groupe.
Vous pouvez également utiliser l’outil [Link] pour exporter la stratégie de sécurité
actuelle, apporter les modifications nécessaires dans le fichier de configuration (qui est
un texte brut), puis l’importer de nouveau.

７ Notes

Lors de la configuration de ce paramètre, la liste des principes de sécurité définis

pour un privilège remplace entièrement les valeurs par défaut (elle ne concatène
pas). Par conséquent, lors de la définition de ce paramètre de stratégie, veillez à
inclure à la fois les titulaires par défaut de ce privilège (service réseau et service
local) en plus du gMSA que vous ajoutez.

Commentaires
Cette page a-t-elle été utile ?  Yes  No

Indiquer des commentaires sur le produit

Résoudre les problèmes liés aux hôtes
protégés
Article • 22/08/2024

Cet article décrit les solutions aux problèmes courants rencontrés lors du déploiement
ou de l’exploitation d’un hôte Hyper-V protégé dans votre infrastructure protégée.

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Si vous n’êtes pas sûr de la nature de votre problème, essayez d’abord d’exécuter les
diagnostics de la structure protégée sur vos hôtes Hyper-V pour limiter les causes
potentielles .

Fonctionnalité de l’hôte protégé

Si vous rencontrez des problèmes avec votre hôte Hyper-V, vérifiez d’abord que la
fonctionnalité de support Hyper-V Guardian de l’hôte est installée. Sans cette
fonctionnalité, l’hôte Hyper-V manque certains paramètres de configuration et logiciels
critiques qui lui permettent de passer l’attestation et de provisionner des machines
virtuelles dotées d’une protection maximale.

Pour vérifier si la fonctionnalité est installée, utilisez Gestionnaire de serveur ou exécutez

l’applet de commande suivante dans une fenêtre PowerShell avec élévation de privilèges
:

PowerShell

Get-WindowsFeature HostGuardian

Si la fonctionnalité n’est pas installée, installez-la avec l’applet de commande PowerShell

suivante :

PowerShell

Install-WindowsFeature HostGuardian -Restart

Échecs d’attestation
Si un hôte ne passe pas d’attestation auprès du service Guardian hôte, il n’est pas en
mesure d’exécuter des machines virtuelles dotées d’une protection maximale. La sortie
de Get-HgsClientConfiguration sur cet hôte affiche des informations sur la raison de
l’échec de l’attestation de cet hôte.

Le tableau ci-dessous explique les valeurs qui peuvent apparaître dans le champ
AttestationStatus et les étapes suivantes potentielles, le cas échéant.

ﾉ Agrandir le tableau

AttestationStatus Explication

Expiré L’hôte a déjà obtenu l’attestation, mais le certificat d’intégrité qu’il a

reçu a expiré. Vérifiez que l’heure de l’hôte et celle du SGH sont
synchronisées.

InsecureHostConfiguration L’hôte n’a pas passé d’attestation, car il n’est pas conforme aux
stratégies d’attestation configurées sur HGS. Pour plus
d’informations, consultez la table AttestationSubStatus.

NotConfigured L’hôte n’est pas configuré pour utiliser un SGH pour l’attestation et
la protection par clé. Il est configuré pour le mode local, à la place. Si
cet hôte se trouve dans une infrastructure protégée, utilisez Set-
HgsClientConfiguration pour lui fournir les URL de votre serveur
SGH.

Passed L’hôte a passé l’attestation.

TransientError La dernière tentative d’attestation a échoué en raison d’une mise en

réseau, d’un service ou d’une autre erreur temporaire. Réessayez
votre dernière opération.

TpmError L’hôte n’a pas pu terminer sa dernière tentative d’attestation en

raison d’une erreur avec votre module de plateforme sécurisée. Pour
plus d’informations, consultez les journaux de votre module TPM.

UnauthorizedHost L’hôte n’a pas passé d’attestation, car il n’a pas été autorisé à
exécuter des machines virtuelles dotées d’une protection maximale.
Vérifiez que l’hôte appartient à un groupe de sécurité approuvé par
SGH pour exécuter des machines virtuelles dotées d’une protection
maximale.

Inconnu L’hôte n’a pas encore tenté d’attester avec HGS.

Lorsque AttestationStatus est signalé comme InsecureHostConfiguration, une ou

plusieurs raisons sont remplies dans le champ AttestationSubStatus . Le tableau ci-
dessous explique les valeurs possibles pour AttestationSubStatus et des conseils sur la
façon de résoudre le problème.

ﾉ Agrandir le tableau
AttestationSubStatus Ce que cela signifie et que faire

BitLocker Le volume du système d’exploitation de l’hôte n’est pas

chiffré par BitLocker. Pour résoudre ce problème, activez
BitLocker sur le volume du système d’exploitation ou
désactivez la stratégie BitLocker sur SGH.

CodeIntegrityPolicy L’hôte n’est pas configuré pour utiliser une stratégie

d’intégrité du code ou n’utilise pas de stratégie
approuvée par le serveur SGH. Vérifiez qu’une stratégie
d’intégrité du code a été configurée, que l’hôte a été
redémarré et que la stratégie est inscrite auprès du
serveur SGH. Pour plus d’informations, consultez Créer
et appliquer une stratégie d’intégrité du code.

DumpsEnabled L’hôte est configuré pour autoriser les vidages sur

incident ou les vidages en mémoire dynamique, ce qui
n’est pas autorisé par vos stratégies HGS. Pour résoudre
ce problème, désactivez les vidages sur l’hôte.

DumpEncryption L’hôte est configuré pour autoriser les vidages sur

incident ou les vidages en mémoire dynamique, mais ne
chiffre pas ces vidages. Désactivez les vidages sur l’hôte
ou configurez le chiffrement de vidage.

DumpEncryptionKey L’hôte est configuré pour autoriser et chiffrer les

vidages, mais n’utilise pas de certificat connu pour le
SGH pour les chiffrer. Pour résoudre ce problème,
mettez à jour la clé de chiffrement de vidage sur l’hôte
ou inscrivez-la auprès de SGH.

FullBoot L’hôte a repris à partir d’un état de veille ou d’une mise

en veille prolongée. Redémarrez l’hôte pour permettre
un démarrage propre et complet.

HibernationEnabled L’hôte est configuré pour autoriser la mise en veille

prolongée sans chiffrer le fichier de mise en veille
prolongée, qui n’est pas autorisé par vos stratégies SGH.
Désactivez la mise en veille prolongée et redémarrez
l’hôte, ou configurez le chiffrement de vidage.

HypervisorEnforcedCodeIntegrityPolicy L’hôte n’est pas configuré pour utiliser une stratégie

d’intégrité du code appliquée à l’hyperviseur. Vérifiez
que l’intégrité du code est activée, configurée et
appliquée par l’hyperviseur. Pour plus d’informations,
consultez le guide de déploiement de Device Guard.

Iommu Les fonctionnalités de sécurité basée sur la virtualisation

de l’hôte ne sont pas configurées pour exiger un
appareil IOMMU pour la protection contre les attaques
d’accès à la mémoire directe, comme requis par vos
AttestationSubStatus Ce que cela signifie et que faire

stratégies SGH. Vérifiez que l’hôte dispose d’un IOMMU,

qu’il est activé et que Device Guard est configuré pour
exiger des protections DMA lors du lancement de VBS.

PagefileEncryption Le chiffrement des fichiers de page n’est pas activé sur

l’hôte. Pour résoudre ce problème, exécutez fsutil
behavior set encryptpagingfile 1 pour activer le
chiffrement des fichiers de page. Pour plus
d’informations, consultez comportement fsutil.

SecureBoot Le démarrage sécurisé n’est pas activé sur cet hôte ou

n’utilise pas le modèle de démarrage sécurisé Microsoft.
Activez le démarrage sécurisé avec le modèle de
démarrage sécurisé Microsoft pour résoudre ce
problème.

SecureBootSettings La base de référence du module TPM sur cet hôte ne

correspond à aucune de celles approuvées par HGS.
Cela peut se produire lorsque vos autorités de
lancement UEFI, votre variable DBX, votre indicateur de
débogage ou vos stratégies de démarrage sécurisé
personnalisées sont modifiées en installant de nouveaux
matériels ou logiciels. Si vous faites confiance à la
configuration actuelle du matériel, du microprogramme
et des logiciels de cette machine, vous pouvez capturer
une nouvelle base de référence TPM et l’inscrire auprès
de SGH.

TcgLogVerification Impossible d’obtenir ou de vérifier le journal TCG (base

de référence TPM). Cela peut indiquer un problème avec
le microprogramme de l’hôte, le module de plateforme
sécurisée ou d’autres composants matériels. Si votre
hôte est configuré pour tenter un démarrage PXE avant
de démarrer Windows, un programme de démarrage
net obsolète peut également provoquer cette erreur.
Vérifiez que tous les PNB sont à jour lorsque le
démarrage PXE est activé.

VirtualSecureMode Les fonctionnalités de sécurité basée sur la virtualisation

ne s’exécutent pas sur l’hôte. Vérifiez que VBS est activé
et que votre système répond aux fonctionnalités de
sécurité de la plateforme configurées. Pour plus
d’informations sur les exigences VBS, consultez la
documentation Device Guard.

Modern TLS
Si vous avez déployé une stratégie de groupe ou configuré votre hôte Hyper-V pour
empêcher l’utilisation de TLS 1.0, vous pouvez rencontrer des erreurs « le client du
service Guardian hôte n’a pas pu désenvelopper un protecteur de clé pour le compte
d’un processus appelant » lors de la tentative de démarrage d’une machine virtuelle
protégée. Cela est dû à un comportement par défaut dans .NET 4.6 où la version TLS par
défaut du système n’est pas prise en compte lors de la négociation des versions TLS
prises en charge avec le serveur SGH.

Pour contourner ce comportement, exécutez les deux commandes suivantes pour

configurer .NET afin d’utiliser les versions TLS par défaut du système pour toutes les
applications .NET.

Console

reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v

SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:64
reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v
SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:32

２ Avertissement

Le paramètre des versions TLS par défaut du système affecte toutes les applications
.NET sur votre ordinateur. Veillez à tester les clés de Registre dans un
environnement isolé avant de les déployer sur vos machines de production.

Pour plus d’informations sur .NET 4.6 et TLS 1.0, consultez Résolution du problème TLS
1.0, 2e édition.

Commentaires
Cette page a-t-elle été utile ?  Yes  No

Indiquer des commentaires sur le produit

Résoudre les problèmes de VM dotées
d'une protection maximale
Article • 22/08/2024

Cet article vous aide à résoudre les problèmes liés aux machines virtuelles dotées d’une
protection maximale.

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

À compter de Windows Server version 1803, le mode de session amélioré de la

connexion de machine virtuelle (VMConnect) et PowerShell Direct sont réactivés pour
les machines virtuelles entièrement protégées. L’administrateur de virtualisation a
toujours besoin des informations d’identification du système invité de machines
virtuelles pour accéder à la machine virtuelle, mais cela permet à un hébergeur de
résoudre plus facilement les problèmes d’une machine virtuelle dotée d’une protection
maximale quand sa configuration réseau est défaillante.

Pour activer VMConnect et PowerShell Direct pour vos machines virtuelles protégées,
déplacez-les vers un hôte Hyper-V qui exécute Windows Server version 1803 ou
ultérieure. Les appareils virtuels autorisant ces fonctionnalités seront réactivés
automatiquement. Si une machine virtuelle protégée se déplace vers un hôte qui
s’exécute et une version antérieure de Windows Server, VMConnect et PowerShell Direct
sont à nouveau désactivés.

Pour les clients très soucieux de la sécurité, qui s’inquiètent de savoir si les hébergeurs
ont accès à la machine virtuelle, et qui souhaitent revenir au comportement d’origine,
les fonctionnalités suivantes doivent être désactivées dans l’OS invité :

Désactivez le service PowerShell Direct sur la machine virtuelle :

PowerShell

Stop-Service vmicvmsession
Set-Service vmicvmsession -StartupType Disabled

Le mode de session étendue VMConnect peut uniquement être désactivé si votre

OS invité correspond au moins à Windows Server 2019 ou Windows 10,
version 1809. Ajoutez la clé de Registre suivante à votre machine virtuelle pour
désactiver les connexions de la console de session étendue VMConnect :

Console
 reg add "HKLM\Software\Microsoft\Virtual Machine\Guest" /v
DisableEnhancedSessionConsoleConnection /t REG_DWORD /d 1

Commentaires
Cette page a-t-elle été utile ?  Yes  No

Indiquer des commentaires sur le produit

Attestation d’intégrité de l’appareil
Article • 12/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Introduite dans Windows 10 version 1507, l’attestation d’intégrité de l’appareil inclut ce

qui suit :

Elle s’intègre à l’infrastructure de gestion des appareils mobiles Windows 10

conformément aux normes Open Mobile Alliance (OMA) .

Elle prend en charge les appareils qui ont un module de plateforme sécurisée
(TPM) configuré dans un microprogramme ou un format discret.

Elle permet aux entreprises d’élever la sécurité de leur organisation au niveau

d’une sécurité attestée et surveillée du matériel, avec un impact minime ou
inexistant sur le coût d’exploitation.

À compter de Windows Server 2016, vous pouvez maintenant exécuter le service

Attestation d’intégrité de l’appareil en tant que rôle serveur au sein de votre
organisation. Utilisez cet article pour savoir comment installer et configurer le rôle
serveur Attestation d’intégrité de l’appareil.

Vue d'ensemble
Vous pouvez utiliser le service Attestation d’intégrité de l’appareil pour évaluer
l’intégrité des appareils suivants :

Appareils Windows 10 et Windows 10 Mobile qui prennent en charge TPM 1.2 ou

2.0.
Appareils locaux gérés à l’aide d’Active Directory avec accès Internet, appareils
gérés à l’aide d’Active Directory sans accès Internet, appareils gérés par un Azure
Active Directory ou un déploiement hybride qui utilise à la fois Active Directory et
Azure Active Directory.

Service Attestation d’intégrité de l’appareil

Le service Attestation d’intégrité de l’appareil valide les journaux TPM et PCR d’un
appareil, puis émet un rapport d’attestation d’intégrité de l’appareil. Microsoft propose
le service Attestation d’intégrité de l’appareil de trois façons :
 Service cloud Attestation d’intégrité de l’appareil. Un service d’attestation
d’intégrité de l’appareil géré par Microsoft qui est gratuit, à charge géo-équilibrée
et optimisé pour l’accès depuis différentes régions du monde.

Service local Attestation d’intégrité de l’appareil. Un nouveau rôle serveur

introduit dans Windows Server 2016. Disponible gratuitement pour les clients qui
possèdent une licence Windows Server 2016.

Service cloud Attestation d’intégrité de l’appareil Azure. Un hôte virtuel dans

Microsoft Azure. Pour cela, vous avez besoin d’un hôte virtuel et de licences pour
le service local Attestation d’intégrité de l’appareil.

Le service Attestation d’intégrité de l’appareil s’intègre aux solutions de gestion des

appareils mobiles et offre ce qui suit :

Il combine les informations qu’elles reçoivent des appareils (par le biais des canaux
de communication de gestion des appareils existants) avec le rapport d’attestation
d’intégrité de l’appareil.
Il permet de prendre une décision en matière de sécurité plus sûre et fiable selon
les données attestées et protégées par le matériel.

Voici un exemple d’utilisation du service Attestation d’intégrité de l’appareil pour élever

le niveau de sécurité des ressources de votre organisation.

1. Vous créez une stratégie qui vérifie la configuration/les attributs de démarrage

suivants :

Démarrage sécurisé
BitLocker
Logiciel anti-programme malveillant à lancement anticipé

2. La solution de gestion des appareils mobiles applique cette stratégie et déclenche

une mesure corrective, selon les données de rapport d’attestation d’intégrité de
l’appareil. Par exemple, elle peut vérifier les points suivants :

Le démarrage sécurisé a été activé, l’appareil a chargé du code de confiance

authentique et le chargeur de démarrage Windows n’était pas falsifié.
Le démarrage sécurisé a correctement vérifié la signature numérique du
noyau Windows et les composants qui ont été chargés pendant le démarrage
de l’appareil.
Le démarrage mesuré a créé une piste d’audit protégée par le module de
plateforme sécurisée qui a pu être vérifiée à distance.
BitLocker a été activé et a protégé les données quand l’appareil s’est éteint.
 Un logiciel anti-programme malveillant à lancement anticipé a été activé dès
les premiers stades du démarrage et il surveille l’exécution.

Service cloud Attestation d’intégrité de l’appareil

Le service cloud Attestation d’intégrité de l’appareil offre les avantages suivants :

Il passe en revue les journaux de démarrage des appareils TCG et PCR qu’il reçoit
d’un appareil inscrit avec une solution de gestion des appareils mobiles.
Il crée un rapport résistant aux falsifications et de mise en évidence des
falsifications (rapport d’attestation d’intégrité de l’appareil) qui décrit le mode de
démarrage de l’appareil en fonction des données collectées et protégées par la
puce du module de plateforme sécurisée (TPM) d’un appareil.
Il remet le rapport d’attestation d’intégrité de l’appareil au serveur de gestion des
appareils mobiles qui l’a demandé dans un canal de communication protégé.

Service local Attestation d’intégrité de l’appareil

Le service local Attestation d’intégrité de l’appareil offre toutes les fonctionnalités
offertes par le service cloud Attestation d’intégrité de l’appareil. Il permet également aux
clients de :

optimiser les performances en exécutant le service Attestation d’intégrité de

l’appareil dans votre propre centre de données,
vérifier que le rapport d’attestation d’intégrité de l’appareil ne quitte pas votre
réseau.

Service cloud Attestation d’intégrité de l’appareil Azure

Ce service fournit les mêmes fonctionnalités que le service local Attestation d’intégrité
de l’appareil, si ce n’est que le service de cloud Attestation d’intégrité de l’appareil Azure
s’exécute en tant qu’hôte virtuel dans Microsoft Azure.

Modes de validation d’attestation d’intégrité de l’appareil

Vous pouvez configurer le service local Attestation d’intégrité de l’appareil pour qu’il
s’exécute en mode de validation EKCert ou AIKCert. Quand le service émet un rapport, il
indique s’il a été émis en mode de validation AIKCert ou EKCert. Les modes de validation
EKCert et AIKCert offrent la même garantie de sécurité tant que la chaîne EKCert de
confiance est tenue à jour.
Mode de validation EKCert
Le mode de validation EKCert est optimisé pour les appareils utilisés dans les
organisations qui ne sont pas connectées à Internet. Les appareils qui se connectent à
un service Attestation d’intégrité de l’appareil s’exécutant en mode de validation EKCert
n’ont pas d’accès direct à Internet.

Quand le service s’exécute en mode de validation EKCert, il s’appuie sur une chaîne
d’approbation gérée par l’entreprise devant être mise à jour régulièrement (entre 5 et
10 fois par an).

Microsoft publie des packages agrégés d’autorités de certification (AC) racines de

confiance et intermédiaires pour les fabricants de TPM approuvés (dès qu’ils sont
disponibles) dans une archive accessible publiquement au format .cab. Vous devez
télécharger le flux, valider son intégrité et l’installer sur le serveur exécutant le service
Attestation d’intégrité de l’appareil.

Une archive d’exemple est [Link] .

Mode de validation AIKCert

Le mode de Validation AIKCert est optimisé pour les environnements d’exploitation qui
ont accès à Internet. Les appareils qui se connectent à un service Attestation d’intégrité
de l’appareil s’exécutant en mode de validation AIKCert doivent avoir un accès direct à
Internet et être en mesure d’obtenir un certificat AIK auprès de Microsoft.

Installer et configurer le service Attestation

d’intégrité de l’appareil sur Windows
Server 2016
Utilisez les sections suivantes pour installer et configurer le service Attestation
d’intégrité de l’appareil sur Windows Server 2016.

Prérequis
Pour configurer et vérifier un service local Attestation d’intégrité de l’appareil, vous avez
besoin de ce qui suit :

Un serveur qui exécute Windows Server 2016.

Un ou plusieurs appareils clients Windows 10 avec un module de plateforme
sécurisée (TPM) (1.2 ou 2.0) qui se trouve dans un état transparent/prêt et qui
 exécute la build la plus récente de Windows Insider.
Déterminez si vous allez exécuter le mode de validation EKCert ou AIKCert.
Les certificats suivants :
Certificat SSL d’attestation d’intégrité de l’appareil. Un certificat SSL x.509 lié à
une racine approuvée d’entreprise avec une clé privée exportable. Ce certificat
protège les communications de données d’attestation d’intégrité de l’appareil
en transit, notamment les communications de serveur à serveur (service
d’attestation d’intégrité de l’appareil et serveur de gestion des appareils
mobiles) et de serveur à client (service d’attestation d’intégrité de l’appareil et
appareil Windows 10).
Certificat de signature d’attestation d’intégrité de l’appareil. Un certificat x.509
lié à une racine approuvée d’entreprise avec une clé privée exportable. Le
service Attestation d’intégrité de l’appareil utilise ce certificat pour la signature
numérique.
Certificat de chiffrement d’attestation d’intégrité de l’appareil. Un certificat
x.509 lié à une racine approuvée d’entreprise avec une clé privée exportable. Le
service Attestation d’intégrité de l’appareil utilise également ce certificat pour le
chiffrement.

Installer Windows Server 2016

Installez Windows Server 2016 en utilisant la méthode d’installation de votre choix,
comme les services de déploiement Windows ou en exécutant le programme
d’installation à partir d’un média de démarrage, d’une clé USB ou du système de fichiers
local. S’il s’agit de la première fois que vous configurez le service local Attestation
d’intégrité de l’appareil, vous devez installer Windows Server 2016 à l’aide de l’option
d’installation Expérience utilisateur.

Ajouter le rôle serveur Attestation d’intégrité de l’appareil

Vous pouvez installer le rôle serveur Attestation d’intégrité de l’appareil et ses
dépendances à l’aide du Gestionnaire de serveur.

Une fois que vous avez installé Windows Server 2016, l’appareil redémarre et ouvre le
Gestionnaire de serveur. Si le Gestionnaire de serveur ne démarre pas automatiquement,
cliquez sur Démarrer, puis sur Gestionnaire de serveur.

1. Cliquez sur Ajouter des rôles et des fonctionnalités.

2. Dans la page Avant de commencer , cliquez sur Suivant.
3. Dans la page Sélectionner le type d’installation, cliquez sur Installation basée sur
un rôle ou une fonctionnalité, puis sur Suivant.
 4. Dans la page Sélectionner le serveur de destination, cliquez sur Sélectionner un
serveur du pool de serveurs, sélectionnez le serveur, puis cliquez sur Suivant.
5. Dans la page Sélectionner des rôles de serveurs, cochez la case Attestation
d’intégrité de l’appareil.
6. Cliquez sur Ajouter des fonctionnalités pour installer d’autres services et
fonctionnalités de rôle requis.
7. Cliquez sur Suivant.
8. Dans la page Sélectionner les composants, cliquez sur Suivant.
9. Dans la page Rôle de serveur web (IIS), cliquez sur Suivant.
10. Dans la page Sélectionner des services de rôle, cliquez sur Suivant.
11. Dans la page Service d’attestation d’intégrité de l’appareil, cliquez sur Suivant.
12. Dans la page Confirmer les sélections d’installation, cliquez sur Installer.
13. Une fois l’installation terminée, cliquez sur Fermer.

Installer les certificats de signature et de chiffrement

Utilisez le script Windows PowerShell suivant pour installer les certificats de signature et
de chiffrement. Pour plus d’informations sur l’empreinte, consultez l’article Comment :
récupérer l’empreinte numérique d’un certificat.

$key = Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Thumbprint -

like "<thumbprint>"}
$keyname = $[Link]
$keypath = $env:ProgramData + "\Microsoft\Crypto\RSA\MachineKeys\" +
$keyname
icacls $keypath /grant <username>`:R

#<thumbprint>: Certificate thumbprint for encryption certificate or signing

certificate
#<username>: Username for web service app pool, by default IIS_IUSRS

Installer le package de certification racine de confiance

TPM
Pour installer le package de certification racine de confiance TPM, vous devez l’extraire,
supprimer toutes les chaînes de confiance qui ne sont pas approuvées par votre
organisation, puis exécuter [Link].

Télécharger le package de certification racine de confiance TPM

Avant d’installer le package de certification, vous pouvez télécharger la dernière liste de
racines de confiance TPM auprès de [Link] .

Important : avant d’installer le package, vérifiez qu’il est signé numériquement par
Microsoft.

Extraire le package de certification de confiance

Extrayez le package de certification de confiance en exécutant les commandes suivantes.

mkdir .\TrustedTpm
expand -F:* .\[Link] .\TrustedTpm

Supprimez les chaînes d’approbation pour les fournisseurs TPM

non approuvés par votre organisation (facultatif).
Supprimez les dossiers des chaînes d’approbation de fournisseurs TPM ne sont pas
approuvées par votre organisation.

Remarque : Si vous utilisez le mode de certificat AIK, le dossier Microsoft est

nécessaire pour valider les certificats AIK émis par Microsoft.

Installer le package de certification de confiance

Installez le package de certification de confiance en exécutant le script d’installation à

partir du fichier .cab.

.\[Link]

Configurer le service Attestation d’intégrité de l’appareil

Vous pouvez utiliser Windows PowerShell pour configurer le service local Attestation
d’intégrité de l’appareil.

Install-DeviceHealthAttestation -EncryptionCertificateThumbprint
<encryption> -SigningCertificateThumbprint <signing> -
 SslCertificateStoreName My -SslCertificateThumbprint <ssl> -
SupportedAuthenticationSchema "<schema>"

#<encryption>: Thumbprint of the encryption certificate

#<signing>: Thumbprint of the signing certificate
#<ssl>: Thumbprint of the SSL certificate
#<schema>: Comma-delimited list of supported schemas including
AikCertificate, EkCertificate, and AikPub

Configurer la stratégie de chaînes de certificats

Configurez la stratégie de chaînes de certificats en exécutant le script Windows
PowerShell suivant :

$policy = Get-DHASCertificateChainPolicy
$[Link] = "NoCheck"
Set-DHASCertificateChainPolicy -CertificateChainPolicy $policy

Commandes de gestion d’attestation

d’intégrité de l’appareil
Voici quelques exemples Windows PowerShell pour vous aider à gérer le service
Attestation d’intégrité de l’appareil.

Configurer le service Attestation d’intégrité de l’appareil

pour la première fois

Install-DeviceHealthAttestation -SigningCertificateThumbprint "<HEX>" -

EncryptionCertificateThumbprint "<HEX>" -SslCertificateThumbprint "<HEX>" -
Force

Supprimer la configuration du service Attestation

d’intégrité de l’appareil

Uninstall-DeviceHealthAttestation -RemoveSslBinding -Force

Obtenir le certificat de signature actif

Get-DHASActiveSigningCertificate

Définir le certificat de signature actif

Set-DHASActiveSigningCertificate -Thumbprint "<hex>" -Force

Remarque : Ce certificat doit être déployé sur le serveur exécutant le service

Attestation d’intégrité de l’appareil dans le magasin de certificats LocalMachine\My.
Quand le certificat de signature actif est défini, le certificat de signature actif existant
est déplacé vers la liste des certificats de signature inactifs.

Répertorier les certificats de signature inactifs

Get-DHASInactiveSigningCertificate

Supprimer tous les certificats de signature inactifs

Remove-DHASInactiveSigningCertificate -Force
Remove-DHASInactiveSigningCertificate -Thumbprint "<hex>" -Force

Remarque : À tout moment, un seul certificat inactif (de n’importe quel type) peut
exister dans le service. Les certificats doivent être supprimés de la liste de certificats
inactifs une fois qu’ils sont devenus inutiles.

Obtenir le certificat de chiffrement actif

Get-DHASActiveEncryptionCertificate
Définir le certificat de chiffrement actif

Set-DHASActiveEncryptionCertificate -Thumbprint "<hex>" -Force

Le certificat doit être déployé sur l’appareil dans le magasin de certificats

LocalMachine\My.

Quand le certificat de chiffrement actif est défini, le certificat de chiffrement actif

existant est déplacé vers la liste des certificats de chiffrement inactif.

Répertorier les certificats de chiffrement inactifs

Get-DHASInactiveEncryptionCertificate

Supprimer tous les certificats de chiffrement inactifs

Remove-DHASInactiveEncryptionCertificate -Force
Remove-DHASInactiveEncryptionCertificate -Thumbprint "<hex>" -Force

Obtenir la configuration X509ChainPolicy

Get-DHASCertificateChainPolicy

Modifier la configuration X509ChainPolicy

$certificateChainPolicy = Get-DHASInactiveEncryptionCertificate
$[Link] = <X509RevocationFlag>
$[Link] = <X509RevocationMode>
$[Link] = <X509VerificationFlags>
$[Link] = <TimeSpan>
Set-DHASCertificateChainPolicy = $certificateChainPolicy
Rapports du service Attestation d’intégrité de
l’appareil
Voici la liste des messages qui sont signalés par le service Attestation d’intégrité de
l’appareil à la solution de gestion des appareils mobiles :

200 HTTP OK. Le certificat est renvoyé.

400 Requête incorrecte. Format de requête non valide, certificat d’intégrité non
valide, la signature de certificat ne correspond pas, objet blob d’attestation
d’intégrité non valide ou objet blob d’état d’intégrité non valide. La réponse
contient également un message, comme décrit par le schéma de réponse, avec un
code d’erreur et un message d’erreur utilisables à des fins de diagnostic.
500 Erreur de serveur interne. Cette erreur peut se produire s’il existe des
problèmes qui empêchent le service d’émettre des certificats.
503 La limitation rejette des requêtes pour éviter une surcharge du serveur.
Conseils sur la désactivation des
services système sous Windows
Server 2016 avec Expérience utilisateur
Article • 27/03/2023

S’applique à : Windows Server 2016 uniquement, en cas d’utilisation avec l’option

d’installation Expérience utilisateur

Le système d'exploitation Windows comprend de nombreux services système offrant

d'importantes fonctionnalités. Ces services présentent différentes stratégies de
démarrage par défaut : certains sont démarrés par défaut (automatiquement) ou si
nécessaire (manuellement), et d'autres sont désactivés par défaut et doivent être
explicitement activés pour être exécutés. Ces paramètres par défaut ont été
soigneusement sélectionnés pour chaque service à des fins d'équilibre des
performances, des fonctionnalités et de la sécurité pour les clients types.

Toutefois, certains clients d'entreprise peuvent préférer un équilibre plus centré sur la
sécurité de leurs PC et serveurs Windows, réduisant ainsi leur surface d’attaque au strict
minimum, et peuvent alors souhaiter désactiver complètement tous les services inutiles
dans leurs environnements spécifiques. Microsoft® fournit à ces clients les instructions
correspondantes pour leur permettre de connaître les services qui peuvent être
désactivés en toute sécurité.

Ces instructions sont réservées à Windows Server 2016 avec Expérience utilisateur (sauf
utilisé en tant que remplacement de bureau pour les utilisateurs finaux). À partir de
Windows Server 2019, ces instructions sont configurées par défaut. Chaque service
présent sur le système est catégorisé comme suit :

Doit être désactivé : Une entreprise centrée sur la sécurité préférera très
certainement désactiver ce service et renoncer à ses fonctionnalités (voir détails
supplémentaires ci-dessous).
Possibilité de désactivation : Ce service fournit des fonctionnalités utiles à
certaines entreprises. Les entreprises centrées sur la sécurité qui ne s’en servent
pas peuvent les désactiver en toute sécurité.
Ne pas désactiver : La désactivation de ce service a un impact sur les
fonctionnalités essentielles ou empêche le bon fonctionnement de certains rôles
ou fonctionnalités. Dès lors, il ne doit pas être désactivé.
(Pas de recommandations) : L’impact d'une désactivation de ces services n’a pas
été entièrement évalué. Dès lors, la configuration par défaut de ces services ne doit
 pas être modifiée.

Les clients peuvent configurer leurs PC et serveurs Windows de manière à désactiver les
services sélectionnés à l'aide des modèles de sécurité de leurs stratégies de groupe ou à
l'aide de l'automatisation PowerShell. Dans certains cas, les instructions incluent des
paramètres de stratégie de groupe spécifiques qui désactivent directement la
fonctionnalité du service, au lieu de désactiver le service lui-même.

Microsoft recommande aux clients de désactiver les services suivants et leurs tâches
planifiées respectives sur Windows Server 2016 avec Expérience utilisateur :

Services :

1. Gestionnaire d'authentification Xbox Live

2. Jeu sauvegardé sur Xbox Live

Tâches planifiées :

1. \Microsoft\XblGameSave\XblGameSaveTask
2. \Microsoft\XblGameSave\XblGameSaveTaskLogon

Désactivation de services non installés par défaut

Microsoft recommande de ne pas appliquer de stratégies pour désactiver les services
qui ne sont pas installés par défaut.

Le service est généralement nécessaire si la fonctionnalité est installée.

L’installation du service ou de la fonctionnalité requiert des droits d’administration.
Interdisez l'installation de la fonctionnalité, pas le démarrage du service.
Le blocage du service Microsoft Windows n’empêche pas un administrateur (ou un
non-administrateur dans certains cas) d’installer un équivalent tiers similaire,
pouvant présenter un risque de sécurité plus élevé.
Une ligne de base ou un point de référence désactivant un service Windows autre
que par défaut (W3SVC, par exemple) donnera à certains auditeurs la fausse
impression que la technologie (par exemple, IIS) est intrinsèquement non sécurisée
et ne doit jamais être utilisée.
Si la fonctionnalité (et le service) n'est jamais installée, cela ne fait qu'ajouter un
encombrement inutile à la ligne de base et au travail de vérification.

Pour tous les services système répertoriés dans ce document, les deux tableaux suivants
fournissent une explication des colonnes et les recommandations de Microsoft pour
activer et désactiver des services système dans Windows Server 2016 avec Expérience
utilisateur :
Explication des colonnes

Nom Description

Nom du service Nom de la clé (interne) du service

Description Description du service, à partir de [Link] qdescription.

Installation Toujours installé : Le service est installé sur Windows Server 2016 Core et
Windows Server 2016 avec Expérience utilisateur. Avec Expérience utilisateur
uniquement : Le service est installé sur Windows Server 2016 avec Expérience
utilisateur, mais pas sur Server Core.

Type de Type de démarrage du service sur Windows Server 2016

démarrage

Recommandation Recommandation/Conseil de Microsoft concernant la désactivation de ce

service sous Windows Server 2016 dans un déploiement d'entreprise
classique bien géré et lorsque le serveur n'est pas utilisé en tant que
remplacement de bureau de l'utilisateur final.

Commentaires Explication supplémentaire

Explication des recommandations de Microsoft

Nom Description

Ne pas désactiver Le service ne doit pas être désactivé

Possibilité de Ce service peut être désactivé si la fonctionnalité qu'il prend en charge

désactivation n’est pas utilisée.

Déjà désactivé Ce service est désactivé par défaut et il n'est pas nécessaire d’appliquer
la stratégie

Doit être désactivé Ce service ne doit jamais être activé sur un système d’entreprise bien
géré.

Les tableaux suivants présentent des conseils Microsoft en matière de désactivation des
services système sous Windows Server 2016 avec Expérience utilisateur :

Programme d'installation ActiveX (AxInstSV)

Nom Description

Nom du service AxInstSV

Nom Description

Description Valide le contrôle de compte d’utilisateur pour l’installation des contrôles

ActiveX depuis Internet et permet de gérer leur installation d’après les
paramètres de la stratégie de groupe. Ce service est démarré à la demande
et, s’il est désactivé, l’installation des contrôles ActiveX se comporte
conformément aux paramètres par défaut du navigateur.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Possibilité de désactiver la fonctionnalité, si inutile

Service de routeur AllJoyn

Nom Description

Nom du service AJRouter

Description Achemine les messages AllJoyn pour les clients AllJoyn locaux. Si ce service
est arrêté, les clients AllJoyn ne possédant pas leur propre routeur groupé ne
peuvent pas s'exécuter.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Préparation des applications

Nom Description

Nom du service AppReadiness

Description Prépare les applications pour la première connexion d’un utilisateur sur cet
ordinateur et lors de l’ajout de nouvelles applications.

Installation Avec Expérience utilisateur uniquement

Nom Description

Type de Manuelle
démarrage

Recommandation Ne pas désactiver

Commentaires Aucun

Identité de l'application
Nom Description

Nom du service AppIDSvc

Description Détermine et vérifie l’identité d’une application. La désactivation de ce

service empêchera l’application d’AppLocker.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Informations sur l'application

Nom Description

Nom du service Appinfo

Description Permet d’exécuter les applications interactives avec des privilèges

administratifs supplémentaires. Si ce service est arrêté, les utilisateurs ne
pourront pas lancer les applications avec les privilèges administratifs
supplémentaires nécessaires pour effectuer les tâches utilisateur souhaitées.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Prend en charge une élévation de même bureau UAC

Service de passerelle de la couche Application
Nom Description

Nom du service ALG

Description Fournit la prise en charge de plug-ins de protocole tiers pour le partage de

connexion Internet

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Gestion des applications

Nom Description

Nom du service AppMgmt

Description Traite les demandes d’installation, de suppression et d’énumération pour le

logiciel déployé au moyen de la stratégie de groupe. Si le service est
désactivé, les utilisateurs ne pourront pas installer, supprimer ou énumérer le
logiciel déployé au moyen de la stratégie de groupe. Si ce service est
désactivé, le démarrage de tout service qui en dépend explicitement
échouera.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service de déploiement AppX (AppXSVC)

Nom Description

Nom du service AppXSvc

Nom Description

Description Assure la prise en charge de l’infrastructure pour le déploiement

d’applications du Microsoft Store. Ce service démarre à la demande. S’il est
désactivé, les applications du Microsoft Store ne sont pas déployées sur le
système et peuvent ne pas fonctionner correctement.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Programme de mise à jour automatique du

fuseau horaire
Nom Description

Nom du service tzautoupdate

Description Définit automatiquement le fuseau horaire système.

Installation Avec Expérience utilisateur uniquement

Type de démarrage Désactivé

Recommandation Déjà désactivé

Commentaires Aucun

Service de transfert intelligent en arrière-plan

(BITS)
Nom Description

Nom du service BITS

Description Transfère des fichiers en arrière-plan en utilisant la bande passante réseau

inactive. Si le service est désactivé, toutes les applications dépendant du
service de transfert intelligent en arrière-plan, telles que Windows Update ou
MSN Explorer, ne pourront plus télécharger des programmes ni d’autres
informations.
Nom Description

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service d’infrastructure des tâches en arrière-

plan
Nom Description

Nom du service BrokerInfrastructure

Description Service d’infrastructure Windows qui contrôle les tâches en arrière-plan qui
peuvent s’exécuter sur le système.

Installation Avec Expérience utilisateur uniquement

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Moteur de filtrage de base

Nom Description

Nom du service BFE

Description Le moteur de filtrage de base est un service qui gère les stratégies de pare-
feu et de sécurité IP (IPsec), et qui implémente le filtrage en mode utilisateur.
L’arrêt ou la désactivation du service Moteur de filtrage de base diminue
significativement la sécurité du système. Cela aboutit également à un
fonctionnement imprévisible des applications de gestion et de pare-feu
IPsec.

Installation Toujours installé

Type de Automatique
démarrage
Nom Description

Recommandation Pas de recommandations

Commentaires Aucun

Service de prise en charge Bluetooth

Nom Description

Nom du service bthserv

Description Le service Bluetooth prend en charge la découverte et l’association

d’appareils Bluetooth distants. L’arrêt ou la désactivation de ce service peut
entraîner un dysfonctionnement des appareils Bluetooth déjà installés et
peut empêcher la découverte et l’association de nouveaux appareils.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Possibilité de désactivation, s'il n'est pas utilisé. Autre mécanisme de

désactivation : Désactivation du Bluetooth et du faisceau infrarouge

CDPUserSvc
Nom Description

Nom du service CDPUserSvc

Description Ce service utilisateur est utilisé pour les scénarios de plateforme d’appareils
connectés

Installation Avec Expérience utilisateur uniquement

Type de Automatique
démarrage

Recommandation Possibilité de désactivation

Commentaires Modèle de service utilisateur

Propagation du certificat
Nom Description

Nom du service CertPropSvc

Description Copie des certificats utilisateur et des certificats racines à partir de cartes à
puce dans le magasin de certificats de l’utilisateur actuel, détecte quand une
carte à puce est insérée dans un lecteur de cartes à puce, et, si nécessaire,
installe le minipilote Plug and Play de cartes à puce.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service de licences de client (ClipSVC)

Nom Description

Nom du service ClipSVC

Description Permet la prise en charge de l'infrastructure du Microsoft Store. Ce service

démarre à la demande. S'il est désactivé, les applications achetées via le
Microsoft Store ne se comportent pas correctement.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Isolation de clé CNG

Nom Description

Nom du service KeyIso

Nom Description

Description Le service d’isolation de clé CNG est hébergé dans le processus LSA. Le
service fournit une isolation de processus de clé aux clés privés et aux
opérations de chiffrement associées, conformément aux critères communs.
Le service stocke et utilise des clés à long terme dans le cadre d’un processus
sécurisé répondant aux exigences des critères communs.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Système d’événement COM+

Nom Description

Nom du service EventSystem

Description Prend en charge le service de notification d’événements système (SENS,

System Event Notification Service), qui fournit une distribution automatique
d’événements aux composants COM (Component Object Model) abonnés. Si
le service est arrêté, SENS sera fermé et ne pourra fournir de notifications
d’ouverture et de fermeture de session. Si ce service est désactivé, le
démarrage de tout service qui en dépend explicitement échouera.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Application système COM+

Nom Description

Nom du service COMSysApp

Nom Description

Description Gère la configuration et le suivi des composants de base COM+ (Component

Object Model). Si le service est arrêté, la plupart des composants de base
COM+ ne fonctionneront pas correctement. Si ce service est désactivé, le
démarrage de tout service qui en dépend explicitement échouera.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Explorateur d’ordinateurs
Nom Description

Nom du service Navigateur

Description Tient à jour une liste des ordinateurs présents sur le réseau et fournit cette
liste aux ordinateurs désignés comme navigateurs. Si ce service est arrêté, la
liste ne sera pas mise ou tenue à jour. Si ce service est désactivé, le
démarrage de tout service qui en dépend explicitement échouera.

Installation Toujours installé

Type de Désactivé
démarrage

Recommandation Déjà désactivé

Commentaires Aucun

Service de plateforme des appareils connectés

Nom Description

Nom du service CDPSvc

Description Ce service est utilisé pour les appareils connectés et les scénarios Universal
Glass

Installation Avec Expérience utilisateur uniquement

Nom Description

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Expériences des utilisateurs connectés et

télémétrie
Nom Description

Nom du service DiagTrack

Description Le service d'expériences des utilisateurs connectés et de télémétrie offre des

fonctionnalités qui prennent en charge les expériences des utilisateurs
connectés et in-app. En outre, ce service gère la collecte et la transmission
des informations de diagnostic et d'utilisation en fonction des événements
(afin d'améliorer l'expérience et la qualité de la plateforme Windows) lorsque
les paramètres des options de confidentialité des diagnostics et de
l'utilisation sont activés sous Commentaires et Diagnostics.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Données des contacts

Nom Description

Nom du service PimIndexMaintenanceSvc

Description Indexe les données des contacts pour la recherche rapide des contacts. Si
vous arrêtez ou désactivez ce service, des contacts risquent de manquer dans
vos résultats de recherche.

Installation Avec Expérience utilisateur uniquement

Nom Description

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Modèle de service utilisateur

CoreMessaging
Nom Description

Nom du service CoreMessagingRegistrar

Description Gère la communication entre les composants système.

Installation Toujours installé

Type de démarrage Automatique

Recommandation Pas de recommandations

Commentaires Aucun

Gestionnaire d’informations d’identification

Nom Description

Nom du service VaultSvc

Description Offre un service de stockage et de récupération sécurisé des informations

d’identification pour les utilisateurs, les applications et les packages de
services de sécurité.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

services de chiffrement
Nom Description

Nom du service CryptSvc

Description Fournit trois services de gestion : le service de base de données de

catalogues, qui confirme les signatures des fichiers Windows et autorise
l’installation de nouveaux programmes, le service de racine protégée, qui
ajoute et supprime les certificats d’autorité de certification racine de
confiance sur cet ordinateur, et le service de mise à jour de certificats racines
automatique, qui extrait les certificats racines à partir de Windows Update et
autorise les scénarios tels que SSL. Si ce service est arrêté, ces services de
gestion ne fonctionneront pas correctement. Si ce service est désactivé, le
démarrage de tout service qui en dépend explicitement échouera.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service de partage des données

Nom Description

Nom du service DsSvc

Description Fournit l'intermédiation des données entre les applications.

Installation Avec Expérience utilisateur uniquement

Type de démarrage Manuelle

Recommandation Pas de recommandations

Commentaires Aucun

DataCollectionPublishingService
Nom Description

Nom du service DcpSvc

Description Le service DCP (Data Collection and Publishing) prend en charge les
applications internes pour charger des données dans le cloud.
Nom Description

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Lanceur de processus serveur DCOM

Nom Description

Nom du service DcomLaunch

Description Le service DCOMLAUNCH lance les serveurs COM et DCOM en réponse aux
demandes d’activation d’objets. Si ce service est arrêté ou désactivé, les
programmes qui utilisent COM ou DCOM ne fonctionnent pas correctement.
Il est fortement recommandé d’exécuter le service DCOMLAUNCH.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service d’association d'appareil

Nom Description

Nom du service DeviceAssociationService

Description Permet de coupler des appareils câblés ou sans fil au système.

Installation Avec Expérience utilisateur uniquement

Type de démarrage Manuelle

Recommandation Pas de recommandations

Commentaires Aucun
Service d’installation d'appareil
Nom Description

Nom du service DeviceInstall

Description Permet à l’ordinateur de reconnaître et d’adapter les modifications

matérielles avec peu ou pas du tout d’intervention de l’utilisateur. Arrêter ou
désactiver ce service provoque une instabilité du système.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service d'inscription de la gestion des appareils

Nom Description

Nom du service DmEnrollmentSvc

Description Assure les activités d'inscription d'appareils pour la gestion des appareils

Installation Avec Expérience utilisateur uniquement

Type de démarrage Manuelle

Recommandation Pas de recommandations

Commentaires Aucun

Gestionnaire d’installation d'appareil

Nom Description

Nom du service DsmSvc

Description Active la détection, le téléchargement et l’installation du logiciel associé à

l'appareil. Si ce service est désactivé, les appareils risquent d’être configurés
avec un logiciel obsolète et de ne pas fonctionner correctement.

Installation Avec Expérience utilisateur uniquement

Nom Description

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service Broker de découverte en arrière-plan

DevQuery
Nom Description

Nom du service DevQueryBroker

Description Permet aux applications de découvrir les appareils avec une tâche en arrière-
plan

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Client DHCP
Nom Description

Nom du service Dhcp

Description Inscrit et met à jour les adresses IP et les enregistrements DNS pour cet
ordinateur. Si ce service est arrêté, cet ordinateur ne recevra pas d’adresses IP
et de mises à jour DNS dynamiques. Si ce service est désactivé, le démarrage
de tout service qui en dépend explicitement échouera.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun
Service de stratégie de diagnostic
Nom Description

Nom du service DPS

Description Le service de stratégie de diagnostic permet la détection, le dépannage et la

résolution de problèmes pour les composants de Windows. Si ce service est
arrêté, les diagnostics ne fonctionnent plus.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service hôte WDIServiceHost

Nom Description

Nom du service WdiServiceHost

Description Le service hôte WDIServiceHost est utilisé par le Service de stratégie de

diagnostics pour héberger les diagnostics qui doivent être exécutés dans un
contexte de service local. Si ce service est arrêté, tous les diagnostics qui en
dépendent ne fonctionneront plus.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Hôte système de diagnostics

Nom Description

Nom du service WdiSystemHost

Nom Description

Description Le service Hôte système de diagnostics est utilisé par le service de stratégie
de diagnostic pour héberger les diagnostics qui doivent être exécutés dans
un contexte de système local. Si ce service est arrêté, tous les diagnostics qui
en dépendent ne fonctionneront plus.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Client de suivi de liaisons distribuées

Nom Description

Nom du service TrkWks

Description Conserve les liaisons entre des fichiers NTFS au sein d’un ordinateur ou d’un
ensemble d’ordinateurs en réseau.

Installation Avec Expérience utilisateur uniquement

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Distributed Transaction Coordinator

Nom Description

Nom du service MSDTC

Description Coordonne les transactions qui comportent plusieurs gestionnaires de

ressources, tels que des bases de données, des files d’attente de messages et
des systèmes de fichiers. Si ce service est arrêté, ces transactions échoueront.
Si ce service est désactivé, le démarrage de tout service qui en dépend
explicitement échouera.

Installation Toujours installé

Nom Description

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

dmwappushsvc
Nom Description

Nom du service dmwappushservice

Description Service de routage de notification Push WAP

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Service requis sur les appareils clients pour Intune, GPM et les technologies
de gestion similaires, ainsi que pour le Filtre d'écriture unifié. Non requis
pour le serveur.

Client DNS
Nom Description

Nom du service Dnscache

Description Le service Client DNS (dnscache) met en cache les noms DNS (Domain Name
System) et inscrit le nom complet de cet ordinateur. Si le service est arrêté, la
résolution des noms DNS se poursuit. Toutefois, les résultats des requêtes de
nom DNS ne sont pas mis en cache et le nom des ordinateurs n'est pas
inscrit. Si le service est désactivé, le démarrage des services qui en dépendent
de façon explicite échoue.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Nom Description

Commentaires Aucun

Gestionnaire des cartes téléchargées

Nom Description

Nom du service MapsBroker

Description Service Windows pour l’accès des applications à des cartes téléchargées. Ce
service est démarré à la demande par les applications accédant à des cartes
téléchargées. La désactivation de ce service empêche les applications
d’accéder à des cartes.

Installation Avec Expérience utilisateur uniquement

Type de Automatique
démarrage

Recommandation Possibilité de désactivation

Commentaires La désactivation compromet les applications qui utilisent le service ;

possibilité de désactivation si les applications ne l'utilisent pas

Mode incorporé
Nom Description

Nom du service embeddedmode

Description Le service Mode incorporé active les scénarios associés aux applications
d’arrière-plan. La désactivation de ce service empêche l’activation de ces
applications d'arrière-plan.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun
Système de fichiers EFS (Encrypting File
System)
Nom Description

Nom du service EFS

Description Fournit la technologie de chiffrement des fichiers de base utilisée pour

stocker les fichiers chiffrés sur les volumes NTFS. Si ce service est arrêté ou
désactivé, les applications n’auront pas accès aux fichiers chiffrés.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service de gestion des applications d'entreprise

Nom Description

Nom du service EntAppSvc

Description Permet la gestion des applications d'entreprise.

Installation Avec Expérience utilisateur uniquement

Type de démarrage Manuelle

Recommandation Pas de recommandations

Commentaires Aucun

Protocole EAP (Extensible Authentication

Protocol)
Nom Description

Nom du service EapHost

Nom Description

Description Le service EAP (Extensible Authentication Protocol) permet d’authentifier le

réseau dans des scénarios tels que des réseaux câblés et sans fil 802.1x, des
réseaux privés virtuels et NAP (Network Access Protection). Ce service fournit
également des API qui sont utilisées par les clients d’accès à distance,
notamment les clients sans fil et VPN, lors de l’authentification. Si vous
désactivez ce service, cet ordinateur ne pourra pas accéder aux réseaux qui
nécessitent l’authentification EAP.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Hôte du fournisseur de découverte de

fonctions
Nom Description

Nom du service fdPHost

Description Le service FDPHOST héberge les fournisseurs de découverte de réseau de

découverte de fonction (FD). Ces fournisseurs de découverte de fonction
fournissent des services de découverte de réseau pour les protocoles SSDP
(Simple Services Discovery Protocol) et WS-D (Web Services - Discovery).
L’arrêt ou la désactivation du service FDPHOST désactivera la découverte de
réseau pour ces protocoles lors de l’utilisation de la découverte de fonction.
Lorsque ce service n’est pas disponible, les services réseau qui utilisent la
découverte de fonction et qui dépendent de ces protocoles de découverte ne
pourront pas trouver des appareils ou des ressources réseau.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun
Publication des ressources de découverte de
fonctions
Nom Description

Nom du service FDResPub

Description Publie cet ordinateur et les ressources qui y sont attachées, de façon à ce que
leur découverte soit possible sur le réseau. Si ce service est arrêté, les
ressources réseau ne sont plus publiées et ne seront donc pas découvertes
par les autres ordinateurs du réseau.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service de géolocalisation
Nom Description

Nom du service lfsvc

Description Ce service surveille l'emplacement actuel du système et gère les limites

géographiques (un emplacement géographique accompagné d'événements
associés). Si vous désactivez ce service, les applications ne pourront pas
utiliser ni recevoir de notification pour la géolocalisation ou des limites
géographiques.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires La désactivation compromet les applications qui utilisent le service ;

possibilité de désactivation si les applications ne l'utilisent pas

Client de stratégie de groupe

Nom Description
Nom Description

Nom du service gpsvc

Description Le service est responsable de l’application des paramètres configurés par les
administrateurs pour l’ordinateur et pour les utilisateurs via le composant de
stratégie de groupe. Si le service est désactivé, les paramètres ne seront pas
appliqués, et les applications et les composants ne seront pas gérables par la
stratégie de groupe. Tout composant ou application qui dépend du
composant de stratégie de groupe risque de ne pas fonctionner si le service
est désactivé.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service du périphérique d’interface utilisateur

Nom Description

Nom du service hidserv

Description Active et maintient l’utilisation des boutons actifs sur le clavier, les contrôles
à distance et d’autres périphériques multimédias. Nous vous recommandons
de veiller à ce que ce service soit constamment en cours d’exécution.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service d'hôte HV
Nom Description

Nom du service HvHost

Nom Description

Description Propose une interface pour l’hyperviseur Hyper-V afin de fournir des
compteurs de performance par partition au système d’exploitation hôte.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Ne pas désactiver

Commentaires Optimiseurs de niveau de performance pour les machines virtuelles invitées.

Non utilisé aujourd'hui, sauf pour les machines virtuelles explicitement
remplies, mais utilisé dans Application Guard

Service Échange de données Microsoft Hyper-V

Nom Description

Nom du service vmickvpexchange

Description Propose un mécanisme d’échange de données entre l’ordinateur virtuel et le

système d’exploitation exécuté sur l’ordinateur physique.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Ne pas désactiver

Commentaires Voir HvHost

Interface de services d’invité Hyper-V

Nom Description

Nom du service vmicguestinterface

Description Fournit une interface à l’hôte Hyper-V afin qu’il puisse interagir avec des
services spécifiques s’exécutant sur la machine virtuelle.

Installation Toujours installé

Type de Manuelle
démarrage
Nom Description

Recommandation Ne pas désactiver

Commentaires Voir HvHost

Service Arrêt de l’invité Microsoft Hyper-V

Nom Description

Nom du service vmicshutdown

Description Propose un mécanisme permettant d’arrêter le système d’exploitation de cet

ordinateur virtuel à partir des interfaces de gestion de l’ordinateur physique.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Ne pas désactiver

Commentaires Voir HvHost

Service Pulsation Microsoft Hyper-V

Nom Description

Nom du service vmicheartbeat

Description Surveille l‘état de cet ordinateur virtuel en émettant une pulsation à

intervalles réguliers. Ce service vous permet d’identifier les ordinateurs
virtuels en cours d’exécution qui ne répondent plus.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Ne pas désactiver

Commentaires Voir HvHost

Service PowerShell Direct Hyper-V

Nom Description

Nom du service vmicvmsession

Description Fournit un mécanisme de gestion des machines virtuelles avec PowerShell via
une session de machine virtuelle sans réseau virtuel.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Ne pas désactiver

Commentaires Voir HvHost

Service de virtualisation Bureau à distance

Hyper-V
Nom Description

Nom du service vmicrdv

Description Fournit une plateforme pour la communication entre l’ordinateur virtuel et le

système d’exploitation exécuté sur l’ordinateur physique.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Ne pas désactiver

Commentaires Voir HvHost

Service Synchronisation date/heure Microsoft

Hyper-V
Nom Description

Nom du service vmictimesync

Description Synchronise l’heure système de cet ordinateur virtuel avec l’heure système de
l’ordinateur physique.

Installation Toujours installé

Nom Description

Type de Manuelle
démarrage

Recommandation Ne pas désactiver

Commentaires Voir HvHost

Requête du service VSS Microsoft Hyper-V

Nom Description

Nom du service vmicvss

Description Coordonne les communications nécessaires à l’utilisation du service VSS afin

de sauvegarder les applications et les données de cet ordinateur virtuel à
partir du système d’exploitation de l’ordinateur physique.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Ne pas désactiver

Commentaires Voir HvHost

Modules de génération de clés IKE et AuthIP

Nom Description

Nom du service IKEEXT

Description Le service IKEEXT héberge les modules de génération de clés IKE (Internet
Key Exchange) et AuthIP (Authenticated Internet Protocol). Ces modules de
génération de clés sont utilisés pour l’authentification et l’échange de clés
dans la sécurité IP (IPsec). L’arrêt ou la désactivation du service IKEEXT
entraînera la désactivation de l’échange de clés IKE et AuthIP avec des
ordinateurs homologues. IPsec est généralement configuré pour utiliser IKE
ou AuthIP ; par conséquent, l’arrêt ou la désactivation du service IKEEXT
risque de conduire à la défaillance d’IPsec et de compromettre la sécurité du
système. Il est fortement recommandé d’activer l’exécution du service IKEEXT.

Installation Toujours installé

Nom Description

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Détection de services interactifs

Nom Description

Nom du service UI0Detect

Description Active la notification des entrées utilisateur pour les services interactifs, qui
active l’accès aux boîtes de dialogue créées par les services interactifs
lorsqu’elles apparaissent. Si ce service est arrêté, les notifications de
nouvelles boîtes de dialogue de services interactifs ne fonctionneront plus et
l’accès aux boîtes de dialogue des services interactifs sera peut-être perdu. Si
ce service est désactivé, les notifications des nouvelles boîtes de dialogue de
services interactifs ainsi que leur accès ne fonctionneront plus.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Partage de connexion Internet (ICS)

Nom Description

Nom du service SharedAccess

Description Assure la traduction d’adresses de réseau, l’adressage, les services de

résolution de noms et/ou les services de prévention d’intrusion pour un
réseau de petite entreprise ou un réseau domestique.

Installation Toujours installé

Type de Manuelle
démarrage
Nom Description

Recommandation Possibilité de désactivation

Commentaires Requis pour les clients utilisés comme points d’accès WiFi, de même qu'aux
deux extrémités de la projection Miracast. Le partage de connexion Internet
peut être bloqué avec le paramètre de stratégie de groupe, « Interdire
l’utilisation du partage de connexion Internet sur votre réseau de domaine
DNS »

Assistance IP
Nom Description

Nom du service iphlpsvc

Description Fournit une connectivité de tunnel à l’aide des technologies de transition

IPv6 (6to4, ISATAP, Proxy de port et Teredo) et IP-HTTPS. Si ce service est
arrêté, l’ordinateur ne disposera pas des avantages de la connectivité
améliorée offerts par ces technologies.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Agent de stratégie IPSec

Nom Description

Nom du service PolicyAgent

Description La sécurité du protocole Internet (IPSec) prend en charge l’authentification

de l’homologue réseau, l’authentification de l’origine des données, l’intégrité
des données, la confidentialité des données (chiffrement) et la protection de
la relecture. Ce service met en œuvre des stratégies IPSec créées via le
composant logiciel enfichable Stratégies de sécurité IP ou l’outil de ligne de
commande « netsh ipsec ». Si vous arrêtez ce service, vous pourrez
rencontrer des problèmes de connectivité réseau si votre stratégie nécessite
des connexions IPSec. En outre, la gestion à distance du Pare-feu Windows
n’est pas disponible lorsque ce service est arrêté.

Installation Toujours installé

Nom Description

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service Serveur proxy KDC

Nom Description

Nom du service KPSSVC

Description Le service Serveur proxy KDC s’exécute sur les serveurs Edge pour permettre
la redirection via proxy des messages du protocole Kerberos vers les
contrôleurs de domaine sur le réseau de l’entreprise.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service KtmRm pour Distributed Transaction

Coordinator
Nom Description

Nom du service KtmRm

Description Coordonne les transactions entre Distributed Transaction Coordinator

(MSDTC) et le gestionnaire de transactions du noyau (KTN). S’il n’est pas
requis, il est recommandé que ce service reste arrêté. S’il est requis, MSDTC
et KTM démarrent ce service automatiquement. Si ce service est désactivé,
toute transaction MSDTC interagissant avec un gestionnaire de transactions
du noyau échoue et tout service qui en dépend de façon explicite ne parvient
pas à démarrer.

Installation Toujours installé

Nom Description

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Mappage de découverte de topologie de la

couche de liaison
Nom Description

Nom du service lltdsvc

Description Crée un mappage réseau, consistant en informations sur la topologie des

ordinateurs et des appareils (connectivité) et en métadonnées décrivant
chaque ordinateur et chaque appareil. Si ce service est désactivé, le mappage
réseau ne fonctionne pas correctement.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Possibilité de désactivation en l'absence de dépendance sur le mappage

réseau

Gestionnaire de session locale

Nom Description

Nom du service LSM

Description Service Windows de base gérant les sessions locales utilisateur. Arrêter ou
désactiver ce service provoque une instabilité du système.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Nom Description

Commentaires Aucun

Service Collecteur standard du concentrateur

de diagnostic Microsoft (R)
Nom Description

Nom du service [Link]

Description Service Collecteur standard du concentrateur de diagnostic Microsoft. Lors

de son exécution, ce service collecte les événements ETW en temps réel en
vue de les traiter.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Assistant Connexion avec un compte Microsoft

Nom Description

Nom du service wlidsvc

Description Autorise la connexion des utilisateurs par le biais des services d’identité de
compte Microsoft. Si ce service est arrêté, les utilisateurs ne pourront pas
ouvrir une session sur l’ordinateur avec leur compte Microsoft.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Les comptes Microsoft sont sans objet sur Windows Server

Client Microsoft App-V

Nom Description

Nom du service AppVClient

Description Gère les utilisateurs App-V et les applications virtuelles

Installation Avec Expérience utilisateur uniquement

Type de démarrage Désactivé

Recommandation Déjà désactivé

Commentaires Aucun

Service Initiateur iSCSI de Microsoft

Nom Description

Nom du service MSiSCSI

Description Gère les sessions iSCSI (Internet SCSI) à partir de cet ordinateur sur les
appareils cibles iSCSI distants. Si ce service est arrêté, l’ordinateur ne pourra
plus ouvrir de session sur les cibles iSCSI ni y accéder. Si ce service est
désactivé, le démarrage de tout service qui en dépend explicitement
échouera.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Ne pas désactiver

Commentaires Nos données de diagnostic indiquent une utilisation sur le client, ainsi que
sur le serveur. Il n'est pas utile de désactiver ce service.

Microsoft Passport
Nom Description

Nom du service NgcSvc

Nom Description

Description Assure l'isolation des processus pour les clés de chiffrement servant à
l'authentification auprès des fournisseurs d'identité associés à un utilisateur.
Si ce service est désactivé, les fonctions d'utilisation et de gestion de ces clés,
telles que l'ouverture de session et l'authentification unique pour les
applications et les sites web, ne seront pas disponibles. Ce service démarre et
s'arrête automatiquement. Nous vous recommandons de ne pas reconfigurer
ce service.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Requis pour les ouvertures de session PIN/Hello non prises en charge sur le
serveur

Conteneur Microsoft Passport

Nom Description

Nom du service NgcCtnrSvc

Description Gère les clés d'identité d'utilisateur local servant à authentifier l'utilisateur
auprès des fournisseurs d'identité, ainsi que les cartes à puce virtuelles du
module de plateforme sécurisée (TPM). Si ce service est désactivé, les clés
d'identité d'utilisateur local et les cartes à puce virtuelles TPM ne seront pas
accessibles. Nous vous recommandons de ne pas reconfigurer ce service.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Aucun

Fournisseur de cliché instantané de logiciel

Microsoft
Nom Description
Nom Description

Nom du service swprv

Description Gère les copies logicielles de clichés instantanés de volumes créés par le
service de cliché instantané de volumes. Si ce service est arrêté, les copies
logicielles de clichés instantanés ne peuvent pas être gérées. Si ce service est
désactivé, le démarrage de tout service qui en dépend explicitement
échouera.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

SMP de l’Espace de stockages Microsoft

Nom Description

Nom du service smphost

Description Service hôte du fournisseur de gestion de l’Espace de stockages Microsoft. Si

ce service est arrêté ou désactivé, l’Espace de stockages ne peut pas être
géré.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Ne pas désactiver

Commentaires Sans ce service, les API de gestion du stockage échouent. Exemple : « Get-
WmiObject -class MSFT_Disk -Namespace
Root\Microsoft\Windows\Storage ».

Service Partage de port [Link]

Nom Description

Nom du service NetTcpPortSharing

Description Permet de partager des ports TCP sur le protocole [Link].

Nom Description

Installation Toujours installé

Type de démarrage Désactivé

Recommandation Déjà désactivé

Commentaires Aucun

Netlogon
Nom Description

Nom du service Netlogon

Description Maintient un canal sécurisé entre cet ordinateur et le contrôleur de domaine

pour authentifier les utilisateurs et les services. Si ce service est arrêté,
l’ordinateur peut ne pas authentifier les utilisateurs et les services et le
contrôleur de domaine ne peut pas inscrire les enregistrements DNS. Si ce
service est désactivé, le démarrage de tout service qui en dépend
explicitement échouera.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service Broker pour les connexions réseau

Nom Description

Nom du service NcbService

Description Connexions du service Broker qui permettent aux applications du Microsoft

Store de recevoir des notifications d’Internet.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Nom Description

Commentaires Aucun

Connexions réseau
Nom Description

Nom du service Netman

Description Prend en charge les objets dans le dossier Connexions réseau et accès à
distance, dans lequel vous pouvez afficher à la fois les connexions du réseau
local et les connexions à distance.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Assistant Connectivité réseau

Nom Description

Nom du service NcaSvc

Description Fournit la notification du statut DirectAccess aux composants de l’interface

utilisateur

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service Liste des réseaux

Nom Description

Nom du service netprofm

Nom Description

Description Identifie les réseaux auxquels l’ordinateur s’est connecté, collecte et stocke
les propriétés de ces réseaux, et signale aux applications toute modification
des propriétés.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Connaissance des emplacements réseau

Nom Description

Nom du service NlaSvc

Description Collecte et stocke les informations de configuration du réseau, puis notifie les
programmes en cas de modification de ces informations. Si ce service est
arrêté, les informations de configuration risquent de ne pas être disponibles.
Si ce service est désactivé, le démarrage de tout service qui en dépend
explicitement échouera.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service Configuration du réseau

Nom Description

Nom du service NetSetupSvc

Description Le service Configuration du réseau gère l'installation des pilotes réseau et

autorise la configuration de paramètres réseau de bas niveau. Si ce service
est interrompu, il se peut que les installations de pilote en cours soient
annulées.
Nom Description

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service Interface du magasin réseau

Nom Description

Nom du service nsi

Description Ce service fournit des notifications réseau (ajout/suppression d’interface, etc.)

aux clients en mode utilisateur. L’arrêt de ce service entraîne la perte de la
connectivité réseau. Si ce service est désactivé, les autres services qui en
dépendent explicitement ne pourront pas démarrer.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Fichiers hors connexion

Nom Description

Nom du service CscService

Description Le service Fichiers hors connexion effectue des activités de maintenance sur
le cache Fichiers hors connexion, répond aux événements d’ouverture et de
fermeture de session des utilisateurs, implémente les données internes de
l’API public, et distribue aux utilisateurs intéressés les événements pertinents
relatifs aux activités Fichiers hors connexion et aux modifications apportées
en mémoire cache.

Installation Avec Expérience utilisateur uniquement

Nom Description

Type de Désactivé
démarrage

Recommandation Déjà désactivé

Commentaires Aucun

Optimiser les lecteurs

Nom Description

Nom du service defragsvc

Description Permet à l’ordinateur de fonctionner plus efficacement en optimisant les

fichiers sur les lecteurs de stockage.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Hôte de DLL de compteur de performance

Nom Description

Nom du service PerfHost

Description Permet aux utilisateurs à distances et aux processus 64 bits d’interroger les
compteurs de performances fournis par des DLL 32 bits. Si ce service est
arrêté, seuls les utilisateurs locaux et les processus 32 bits peuvent interroger
les compteurs fournis par des DLL 32 bits.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun
Journaux et alertes de performance
Nom Description

Nom du service pla

Description Le service des journaux et des alertes de performance collecte des données
de performance sur des ordinateurs locaux ou distants, en se basant sur des
paramètres de planification préconfigurés, puis écrit ces données dans un
journal ou déclenche une alerte. Si ce service est arrêté, les informations de
performance ne seront plus collectées. Si ce service est désactivé, le
démarrage de tout service qui en dépend explicitement échouera.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service téléphonique
Nom Description

Nom du service PhoneSvc

Description Gère l'état de téléphonie de l'appareil

Installation Avec Expérience utilisateur uniquement

Type de démarrage Manuelle

Recommandation Possibilité de désactivation

Commentaires Utilisé par les applications VoIP modernes

Plug-and-play
Nom Description

Nom du service PlugPlay

Description Permet à l’ordinateur de reconnaître et d’adapter les modifications

matérielles avec peu ou pas du tout d’intervention de l’utilisateur. Arrêter ou
désactiver ce service provoque une instabilité du système.
Nom Description

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service Énumérateur d’appareil mobile

Nom Description

Nom du service WPDBusEnum

Description Met en place une stratégie de groupe pour les dispositifs de stockage de
masse amovibles. Permet à des applications telles que le Lecteur Windows
Media et l’Assistant Importation d’images de transférer et de synchroniser du
contenu à l’aide de dispositifs de stockage de masse amovibles.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Power
Nom Description

Nom du service Avancé

Description Gère la stratégie d’alimentation et la remise de notification de stratégie

d’alimentation.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun
Spouleur d’impression
Nom Description

Nom du service Spouleur

Description Ce service met en spoule les travaux d’impression et gère l’interaction avec
l’imprimante. Si vous désactivez ce service, vous ne pourrez plus imprimer ni
voir vos imprimantes.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Possibilité de désactivation s'il ne s'agit pas d'un serveur d'impression ou

d'un contrôleur de domaine

Commentaires Sur un contrôleur de domaine, l’installation du rôle de contrôleur de

domaine ajoute un thread au service de spouleur chargé d’effectuer le
nettoyage de l’impression – suppression des objets obsolètes de la file
d'attente à l'impression dans Active Directory. Si le service de spouleur n’est
pas en cours d’exécution sur au moins un contrôleur de domaine dans
chaque site, Active Directory n'est pas en mesure de supprimer les files
d’attente qui n’existent plus. « Disabling Unnecessary Services? A Word to the
Wise » - Microsoft Tech Community - Blog Ask The Performance Team .

Extensions et notifications des imprimantes

Nom Description

Nom du service PrintNotify

Description Ce service ouvre les boîtes de dialogue d’impression personnalisée et gère

les notifications d’une imprimante ou d’un serveur d’impression distant. Si
vous désactivez ce service, vous ne pourrez plus voir les extensions ou
notifications relatives aux imprimantes.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation s'il ne s'agit pas d'un serveur d’impression

Commentaires Aucun
Prise en charge de l’application Rapports et
solutions aux problèmes du Panneau de
configuration
Nom Description

Nom du service wercplsupport

Description Ce service prend en charge l’affichage, l’envoi et la suppression des rapports

à l’échelle du système pour l’application Rapports et solutions aux problèmes
du Panneau de configuration.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service de l’Assistant Compatibilité des

programmes
Nom Description

Nom du service PcaSvc

Description Ce service fournit une prise en charge de l’Assistant Compatibilité des

programmes. Cet Assistant surveille les programmes installés et exécutés par
l’utilisateur et détecte les problèmes de compatibilité connus. Si ce service
est arrêté, cet Assistant ne fonctionnera pas correctement.

Installation Avec Expérience utilisateur uniquement

Type de Automatique
démarrage

Recommandation Possibilité de désactivation

Commentaires Aucun

Expérience audio-vidéo haute qualité Windows

Nom Description

Nom du service QWAVE

Description qWave (Quality Windows Audio Video Experience) est une plateforme réseau
destinée aux applications de diffusion en continu AV (Audio Video) sur des
réseaux domestiques IP. qWave améliore les performances et la fiabilité des
flux AV en assurant la qualité de service (QoS) sur le réseau des applications
AV. Cette plateforme fournit des mécanismes concernant le contrôle
d’admission, l’analyse et la mise en œuvre du temps d'exécution, la
rétroaction des applications et la définition des priorités du trafic.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Service QoS côté client

Service de gestion radio

Nom Description

Nom du service RmSvc

Description Service de gestion radio et de mode Avion

Installation Avec Expérience utilisateur uniquement

Type de démarrage Manuelle

Recommandation Possibilité de désactivation

Commentaires Aucun

Gestionnaire des connexions automatiques

d’accès à distance
Nom Description

Nom du service RasAuto

Description Crée une connexion vers un réseau distant à chaque fois qu’un programme
référence un nom ou une adresse DNS ou NetBIOS distant.
Nom Description

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Gestionnaire des connexions d’accès à distance

Nom Description

Nom du service RasMan

Description Gère les connexions d’accès à distance et les connexions de réseau privé
virtuel (VPN) entre cet ordinateur et Internet ou d’autres réseaux distants. Si
ce service est désactivé, le démarrage de tout service qui en dépend
explicitement échouera.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Configuration du Bureau à distance

Nom Description

Nom du service SessionEnv

Description Le service Configuration des services Bureau à distance (RDCS) est

responsable de toutes les activités de maintenance de session et de
configuration du Bureau à distance et des services Bureau à distance
nécessitant un contexte SYSTEM. Il faut y inclure les dossiers temporaires par
session, ainsi que les thèmes et certificats des services Bureau à distance.

Installation Toujours installé

Type de Manuelle
démarrage
Nom Description

Recommandation Ne pas désactiver

Commentaires Aucun

Services Bureau à distance

Nom Description

Nom du service TermService

Description Autorise les utilisateurs à se connecter de manière interactive à un ordinateur

distant. Le Bureau à distance et le serveur hôte de session Bureau à distance
dépendent de ce service. Pour empêcher l’utilisation à distance de cet
ordinateur, désactivez les cases à cocher situées sous l’onglet Utilisation à
distance des Propriétés système via l’élément Système du Panneau de
configuration.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Ne pas désactiver

Commentaires Aucun

Redirecteur de port du mode utilisateur des

services Bureau à distance
Nom Description

Nom du service UmRdpService

Description Permet la redirection des imprimantes/lecteurs/ports pour les connexions

RDP

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Ne pas désactiver

Commentaires Prend en charge les redirections côté serveur de la connexion.

Appel de procédure distante (RPC)
Nom Description

Nom du service RpcSs

Description Le service RPCSS est le Gestionnaire de contrôle des services pour les
serveurs COM et DCOM. Il traite les demandes d’activation d’objets, les
résolutions d’exportateur d’objets et le nettoyage de la mémoire distribuée
pour les serveurs COM et DCOM. Si ce service est arrêté ou désactivé, les
programmes qui utilisent COM ou DCOM ne fonctionnent pas correctement.
Il est fortement recommandé d’exécuter le service RPCSS.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Localisateur d’appels de procédure distante

(RPC)
Nom Description

Nom du service RpcLocator

Description Dans Windows 2003 et les versions antérieures de Windows, le service

Localisateur d’appels de procédure distante (RPC) gère la base de données
du service de nom RPC. Dans Windows Vista et les versions ultérieures de
Windows, ce service ne fournit aucune fonctionnalité et est présent à des fins
de compatibilité applicative.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Accès à distance au Registre

Nom Description

Nom du service RemoteRegistry

Description Permet aux utilisateurs à distance de modifier les paramètres du Registre sur
cet ordinateur. Si ce service est arrêté, le Registre ne pourra être modifié que
par les utilisateurs de cet ordinateur. Si ce service est désactivé, le démarrage
de tout service qui en dépend explicitement échouera.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Ne pas désactiver

Commentaires Aucun

Fournisseur d’un jeu de stratégie résultant

Nom Description

Nom du service RSoPProv

Description Fournit un service réseau qui traite les demandes pour simuler l’application
des paramètres de stratégie de groupe à un utilisateur ou un ordinateur cible
dans différentes situations et qui calcule les paramètres du jeu de stratégie
résultant.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Routage et accès à distance

Nom Description

Nom du service RemoteAccess

Description Offre aux entreprises des services de routage dans les environnements de
réseau local ou étendu.

Installation Toujours installé

Nom Description

Type de Désactivé
démarrage

Recommandation Déjà désactivé

Commentaires Déjà désactivé

Mappeur de point de terminaison RPC

Nom Description

Nom du service RpcEptMapper

Description Résout les identificateurs des interfaces RPC en points de terminaison de

transport. Si ce service est arrêté ou désactivé, les programmes utilisant des
services d’appel de procédure distante (RPC) ne fonctionneront pas
correctement.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Ouverture de session secondaire

Nom Description

Nom du service seclogon

Description Permet le démarrage des processus sous d’autres informations

d’identification. Si ce service est arrêté, ce type d’ouverture de session sera
indisponible. Si ce service est désactivé, le démarrage de tout service qui en
dépend explicitement échouera.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun
Service SSTP (Secure Socket Tunneling
Protocol)
Nom Description

Nom du service SstpSvc

Description Prend en charge la connexion par le protocole SSTP (Secure Socket

Tunneling Protocol) à des ordinateurs distants via un réseau VPN. Si ce
service est désactivé, les utilisateurs ne peuvent pas utiliser le protocole SSTP
pour accéder à des serveurs distants.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Ne pas désactiver

Commentaires La désactivation compromet le RRAS

Gestionnaire de comptes de sécurité

Nom Description

Nom du service SamSs

Description Le démarrage de ce service signale à d’autres services que le Gestionnaire de

comptes de sécurité est prêt à accepter des demandes. La désactivation de
ce service empêchera d’autres services dans le système d’être prévenus
lorsque le Gestionnaire de comptes de sécurité sera prêt, ce qui pourrait
provoquer le démarrage incorrect de ces services. Ce service ne doit pas être
désactivé.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Ne pas désactiver

Commentaires Aucun

Service Données de capteur

Nom Description
Nom Description

Nom du service SensorDataService

Description Fournit les données d'une variété de capteurs

Installation Avec Expérience utilisateur uniquement

Type de démarrage Manuelle

Recommandation Possibilité de désactivation

Commentaires Aucun

Service de surveillance des capteurs

Nom Description

Nom du service SensrSvc

Description Surveille plusieurs capteurs pour exposer les données et s’adapter aux divers
états utilisateur et du système. Si le service est arrêté ou désactivé, la
luminosité de l’affichage ne s’adaptera pas aux conditions d’éclairage. L’arrêt
de ce service peut également affecter d’autres fonctionnalités du système.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Aucun

Service de capteur
Nom Description

Nom du service SensorService

Description Service pour les capteurs qui gère les fonctionnalités des différents capteurs.
Gère l’Orientation de périphérique simple (SDO) et l’historique pour les
capteurs. Charge le capteur d'orientation de périphérique simple rapportant
les changements d'orientation du périphérique. Si le service est arrêté ou
désactivé, le capteur d'orientation de périphérique simple ne sera pas chargé
et la rotation automatique n'aura pas lieu. La collecte d'historiques des
capteurs sera également arrêtée.
Nom Description

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Aucun

Serveur
Nom Description

Nom du service LanmanServer

Description Prend en charge le partage de fichiers, d’impression et des canaux nommés

via le réseau pour cet ordinateur. Si ce service est arrêté, ces fonctions ne
seront pas disponibles. Si ce service est désactivé, le démarrage de tout
service qui en dépend explicitement échouera.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Ne pas désactiver

Commentaires Requis pour la gestion à distance, IPC$, le partage de fichiers SMB

Détection matériel noyau

Nom Description

Nom du service ShellHWDetection

Description Fournit des notifications à des événements matériels de lecture

automatique.

Installation Avec Expérience utilisateur uniquement

Type de Automatique
démarrage

Recommandation Possibilité de désactivation

Commentaires Aucun
Carte à puce
Nom Description

Nom du service SCardSvr

Description Gère l’accès aux cartes à puce lues par cet ordinateur. Si ce service est arrêté,
cet ordinateur ne pourra plus lire de cartes à puces. Si ce service est
désactivé, le démarrage de tout service qui en dépend explicitement
échouera.

Installation Toujours installé

Type de Désactivé
démarrage

Recommandation Déjà désactivé

Commentaires Aucun

Service d’énumération de périphériques de

carte à puce
Nom Description

Nom du service ScDeviceEnum

Description Crée des nœuds de périphériques logiciels pour tous les lecteurs de cartes à
puce accessibles à une session donnée. Si ce service est désactivé, les API
WinRT ne peuvent pas énumérer les lecteurs de cartes à puce.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Requis presque exclusivement pour les applications WinRT

Stratégie de retrait de la carte à puce

Nom Description

Nom du service SCPolicySvc

Nom Description

Description Autorise la configuration du système pour verrouiller le Bureau de l’utilisateur

au moment du retrait de la carte à puce.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Interruption SNMP
Nom Description

Nom du service SNMPTRAP

Description Reçoit les messages d’interception générés par les agents SNMP (Simple
Network Management Protocol) locaux ou distants et transmet les messages
aux programmes de gestion SNMP s’exécutant sur cet ordinateur. Si ce
service est arrêté, les programmes à base SNMP sur cet ordinateur ne
recevront pas les messages d’interception SNMP. Si ce service est désactivé,
le démarrage de tout service qui en dépend explicitement échouera.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Protection logicielle
Nom Description

Nom du service sppsvc

Description Permet le téléchargement, l’installation et l’application de licences

numériques pour Windows et des applications Windows. Si le service est
désactivé, le système d’exploitation et les applications sous licence peuvent
s’exécuter dans un mode de notification. Il est vivement recommandé de ne
pas désactiver le service de protection logicielle.
Nom Description

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Application d’assistance de la Console

d’administration spéciale
Nom Description

Nom du service sacsvr

Description Permet aux administrateurs d’accéder à distance à une invite de commandes

en utilisant les services de gestion d’urgence.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Vérificateur de points
Nom Description

Nom du service svsvc

Description Vérifie l'altération potentielle du système de fichiers.

Installation Toujours installé

Type de démarrage Manuelle

Recommandation Pas de recommandations

Commentaires Aucun
Découverte SSDP
Nom Description

Nom du service SSDPSRV

Description Découvre les périphériques et services en réseau qui utilisent le protocole de

découverte SSDP, tels que les périphériques UPnP. Annonce également les
périphériques et services SSDP exécutés sur l’ordinateur local. Si ce service
est arrêté, les périphériques SSDP ne seront pas découverts. Si ce service est
désactivé, le démarrage de tout service qui en dépend explicitement
échouera.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Aucun

Service State Repository

Nom Description

Nom du service StateRepository

Description Fournit la prise en charge d'infrastructure nécessaire au modèle

d'application.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Événements d’acquisition d’images fixes

Nom Description

Nom du service WiaRpc

Nom Description

Description Lance les applications associées aux événements d’acquisition d’images

fixes.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Aucun

Service de stockage
Nom Description

Nom du service StorSvc

Description Fournit des services d'activation pour les paramètres de stockage et

l'extension de stockage externe

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Gestion des niveaux de stockage

Nom Description

Nom du service TieringEngineService

Description Optimise le placement des données dans les niveaux de stockage de tous les
espaces de stockage hiérarchisé sur le système.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Nom Description

Commentaires Aucun

Superfetch
Nom Description

Nom du service SysMain

Description Gère et améliore le niveau de performance du système dans le temps.

Installation Toujours installé

Type de démarrage Manuelle

Recommandation Pas de recommandations

Commentaires Aucun

Hôte de synchronisation
Nom Description

Nom du service OneSyncSvc

Description Ce service synchronise la messagerie, les contacts, le calendrier et diverses

autres données utilisateur. La messagerie et d'autres applications
dépendantes de cette fonctionnalité ne fonctionnent pas correctement
lorsque ce service n'est pas exécuté.

Installation Avec Expérience utilisateur uniquement

Type de Automatique
démarrage

Recommandation Possibilité de désactivation

Commentaires Modèle de service utilisateur

Service de notification d’événements système

Nom Description

Nom du service SENS

Nom Description

Description Analyse les événements système et notifie leur existence aux abonnés du
système d’événements COM+.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service Broker pour les événements système

Nom Description

Nom du service SystemEventsBroker

Description Coordonne l’exécution de travail en arrière-plan pour l’application WinRT. Si

ce service est arrêté ou désactivé, le travail en arrière-plan risque de ne pas
être déclenché.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Ne pas désactiver

Commentaires Bien que sa description implique uniquement les applications WinRT, il est
requis pour le planificateur de tâches, service Broker d’infrastructure et
d’autres composants internes.

Planificateur de tâches
Nom Description

Nom du service Planification

Description Permet à un utilisateur de configurer et de planifier des tâches automatisées

sur cet ordinateur. Le service héberge également plusieurs tâches critiques
du système Windows. Si ce service est arrêté ou désactivé, ces tâches ne
seront pas exécutées à l’heure prévue. Si ce service est désactivé, le
démarrage de tout service qui en dépend explicitement échouera.
Nom Description

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Assistance NetBIOS sur TCP/IP

Nom Description

Nom du service lmhosts

Description Prend en charge le service NetBIOS sur TCP/IP (NetBT) et la résolution de

noms NetBIOS pour les clients présents sur le réseau, ce qui permet aux
utilisateurs de partager des fichiers, d’imprimer et d’ouvrir des sessions sur le
réseau. Si ce service est arrêté, ces fonctions risquent de ne pas être
disponibles. Si ce service est désactivé, le démarrage de tout service qui en
dépend explicitement échouera.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Telephony
Nom Description

Nom du service TapiSrv

Description Prend en charge l’interface TAPI (Telephony API) pour les programmes qui
contrôlent les périphériques de téléphonie sur l’ordinateur local et, via le
réseau local (LAN), sur les serveurs qui exécutent également le service.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage
Nom Description

Recommandation Ne pas désactiver

Commentaires La désactivation compromet le RRAS

Thèmes
Nom Description

Nom du service Thèmes

Description Fournit un système de gestion de thème de l’expérience utilisateur.

Installation Avec Expérience utilisateur uniquement

Type de Automatique
démarrage

Recommandation Ne pas désactiver

Commentaires Il est impossible de définir des thèmes d’accessibilité si ce service est

désactivé

Serveur de modèles de données de vignette

Nom Description

Nom du service tiledatamodelsvc

Description Serveur de vignettes pour la mise à jour des vignettes.

Installation Avec Expérience utilisateur uniquement

Type de démarrage Automatique

Recommandation Ne pas désactiver

Commentaires Le menu Démarrer est compromis si ce service est désactivé

Service Broker pour les événements horaires

Nom Description

Nom du service TimeBrokerSvc

Nom Description

Description Coordonne l’exécution de travail en arrière-plan pour l’application WinRT. Si

ce service est arrêté ou désactivé, le travail en arrière-plan risque de ne pas
être déclenché.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Ne pas désactiver

Commentaires Bien que sa description implique uniquement les applications WinRT, il est
requis pour le planificateur de tâches, service Broker d’infrastructure et
d’autres composants internes.

Service du clavier tactile et du volet d’écriture

manuscrite
Nom Description

Nom du service TabletInputService

Description Active les fonctionnalités de stylet et d’entrée manuscrite du clavier tactile et

du volet d’écriture manuscrite

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Aucun

Service Update Orchestrator pour Windows

Update
Nom Description

Nom du service UsoSvc

Description Gère les mises à jour Windows. S'il est arrêté, vos appareils ne seront pas en
mesure de télécharger et d'installer les dernières mises à jour.
Nom Description

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Ne pas désactiver

Commentaires La description du service était absente dans v1607 ; Windows Update (y

compris WSUS) dépend de ce service.

Hôte de périphérique UPnP

Nom Description

Nom du service upnphost

Description Autorise l’hébergement des périphériques UPnP sur cet ordinateur. Si ce

service est arrêté, tous les périphériques UPnP hébergés cesseront de
fonctionner et aucun autre périphérique hébergé ne pourra être ajouté. Si ce
service est désactivé, le démarrage de tout service qui en dépend
explicitement échouera.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Aucun

Service de journalisation des accès utilisateur

Nom Description

Nom du service UALSVC

Nom Description

Description Ce service consigne les demandes d’accès de chaque client, sous forme
d’adresses IP et de noms d’utilisateur, des produits et rôles installés sur le
serveur local. Ces informations peuvent être obtenues via des requêtes
PowerShell par les administrateurs qui ont besoin de quantifier les demandes
clients en logiciels serveur pour la gestion des licences d’accès client (CAL)
hors connexion. Si le service est désactivé, les demandes des clients ne sont
pas consignées et ne pourront pas être extraites via des requêtes PowerShell.
L’arrêt du service n’affectera pas l’interrogation des données de l’historique
(voir la documentation correspondante pour connaître les étapes nécessaires
à la suppression des données de l’historique). L’administrateur système local
doit consulter les termes du contrat de licence Windows Server pour
déterminer le nombre de CAL nécessaires pour que la licence du logiciel
serveur soit correcte ; l’utilisation du service et des données UAL ne décharge
pas de cette obligation.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Accès aux données utilisateur

Nom Description

Nom du service UserDataSvc

Description Fournit l’accès des applications aux données utilisateur structurées,

notamment aux coordonnées, calendriers, messages et autres éléments de
contenu. Si vous arrêtez ou désactivez ce service, les applications qui utilisent
ces données risquent de ne pas fonctionner correctement.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Modèle de service utilisateur

Stockage des données utilisateur

Nom Description

Nom du service UnistoreSvc

Description Gère le stockage des données utilisateur structurées, notamment les

coordonnées, les calendriers, les messages et d’autres éléments de contenu.
Si vous arrêtez ou désactivez ce service, les applications qui utilisent ces
données risquent de ne pas fonctionner correctement.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Modèle de service utilisateur

Service User Experience Virtualization

Nom Description

Nom du service UevAgentService

Description Assure la prise en charge de l’itinérance des paramètres d’application et de

système d’exploitation

Installation Avec Expérience utilisateur uniquement

Type de Désactivé
démarrage

Recommandation Déjà désactivé

Commentaires Aucun

Gestionnaire des utilisateurs

Nom Description

Nom du service UserManager

Description Le Gestionnaire des utilisateurs fournit les composants d'exécution requis

pour une interaction multi-utilisateur. Si ce service est arrêté, certaines
applications risquent de ne pas fonctionner correctement.

Installation Toujours installé

Nom Description

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service de profil utilisateur

Nom Description

Nom du service ProfSvc

Description Ce service est responsable du chargement et du déchargement des profils

utilisateur. Si ce service est arrêté ou désactivé, les utilisateurs ne pourront
plus se connecter ou se déconnecter, les applications pourront avoir des
problèmes pour obtenir les données des utilisateurs, et les composants
inscrits pour recevoir les notifications d’événements de profils ne les
recevront pas.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Disque virtuel
Nom Description

Nom du service vds

Description Fournit des services de gestion des disques, des volumes, des systèmes de
fichiers et des groupes de stockage.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun
Cliché instantané des volumes
Nom Description

Nom du service VSS

Description Gère et implémente les clichés instantanés de volumes pour les sauvegardes
et autres utilisations. Si ce service est arrêté, les clichés instantanés ne seront
pas disponibles pour la sauvegarde et la sauvegarde échouera. Si ce service
est désactivé, le démarrage de tout service qui en dépend explicitement
échouera.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

WalletService
Nom Description

Nom du service WalletService

Description Objets d'hôtes utilisés par les clients du portefeuille

Installation Avec Expérience utilisateur uniquement

Type de démarrage Manuelle

Recommandation Possibilité de désactivation

Commentaires Aucun

Audio Windows
Nom Description

Nom du service Audiosrv

Description Gère les périphériques audio pour les programmes compatibles Windows. Si
ce service est arrêté, les périphériques et les effets audio ne fonctionneront
pas correctement. S’il est désactivé, les services qui en dépendent
explicitement ne démarreront pas
Nom Description

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Aucun

Générateur de points de terminaison du service

Audio Windows
Nom Description

Nom du service AudioEndpointBuilder

Description Gère les périphériques audio pour le service Audio Windows. Si ce service est
arrêté, les périphériques et les effets audio ne fonctionneront pas
correctement. S’il est désactivé, les services qui en dépendent explicitement
ne démarreront pas

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Aucun

Service de biométrie Windows

Nom Description

Nom du service WbioSrvc

Description Le service de biométrie Windows permet aux applications clientes de

capturer, de comparer, de manipuler et de stocker des données biométriques
sans avoir directement accès au matériel ou aux échantillons biométriques.
Le service est hébergé dans un processus SVCHOST privilégié.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage
Nom Description

Recommandation Pas de recommandations

Commentaires Aucun

Serveur de trame de la Caméra Windows

Nom Description

Nom du service FrameServer

Description Permet à plusieurs clients d’accéder aux trames vidéo des appareils photo.

Installation Avec Expérience utilisateur uniquement

Type de démarrage Manuelle

Recommandation Possibilité de désactivation

Commentaires Aucun

Gestionnaire de connexions Windows

Nom Description

Nom du service Wcmsvc

Description Prend des décisions automatiques de connexion/déconnexion en fonction

des options de connectivité réseau actuellement disponibles à l’ordinateur, et
active la gestion de la connectivité réseau en fonction des paramètres de la
stratégie de groupe.

Installation Avec Expérience utilisateur uniquement

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service Inspection du réseau Windows

Defender
Nom Description

Nom du service WdNisSvc

Description Empêche les tentatives d’intrusion ciblant les vulnérabilités connues et

nouvellement découvertes des protocoles réseau

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service Windows Defender

Nom Description

Nom du service WinDefend

Description Protège les utilisateurs contre les logiciels malveillants et les autres logiciels
potentiellement indésirables

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Windows Driver Foundation - Infrastructure de

pilote mode-utilisateur
Nom Description

Nom du service wudfsvc

Description Crée et gère les processus de pilote en mode utilisateur. Ce service ne peut
pas être arrêté.

Installation Toujours installé

Nom Description

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service hôte du fournisseur de chiffrement

Windows
Nom Description

Nom du service WEPHOSTSVC

Description Le service hôte du fournisseur de chiffrement Windows négocie les

fonctionnalités liées au chiffrement avec les fournisseurs de chiffrement tiers
pour les processus qui ont besoin d’évaluer et d’appliquer des stratégies EAS.
L’arrêt de cette activité compromettra les vérifications de conformité EAS qui
ont été établies par les comptes de messagerie connectés

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service de rapport d'erreurs Windows

Nom Description

Nom du service WerSvc

Description Permet le signalement des erreurs quand des programmes cessent de

fonctionner ou de répondre, et permet de délivrer des solutions existantes.
Permet également la génération des journaux pour les services de diagnostic
et de réparation. Si ce service est arrêté, le signalement des erreurs risque de
ne pas fonctionner correctement ; par ailleurs, les résultats des services de
diagnostic et de réparation risquent de ne pas s’afficher.

Installation Toujours installé

Nom Description

Type de Manuelle
démarrage

Recommandation Ne pas désactiver

Commentaires Collecte et envoie les données d’incident et de blocage utilisées par les
éditeurs de logiciels indépendants et fabricants de matériel MS et tiers. Les
données sont utilisées pour diagnostiquer les bogues à l'origine des
incidents, ce qui peut inclure des bogues de sécurité. Également requis pour
les rapports d’erreurs d’entreprise

Collecteur d'événements de Windows

Nom Description

Nom du service Wecsvc

Description Ce service gère des abonnements persistants à des événements de sources

distantes prenant en charge le protocole Gestion de services Web. Cela inclut
les journaux d’événements de Windows Vista, les sources d’événements
matériels et IPMI. Le service stocke les événements transférés dans un journal
d’événements local. Si ce service est arrêté ou désactivé, des abonnements
aux événements ne peuvent pas être créés et les événements transférés ne
peuvent pas être acceptés.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Ne pas désactiver

Commentaires Collecte les événements ETW (y compris les événements de sécurité) pour
faciliter la gestion, les diagnostics. Un grand nombre de fonctionnalités et
d'outils tiers s’appuient sur ce service, y compris des outils d’audit de sécurité

Journal des événements Windows

Nom Description

Nom du service EventLog

Nom Description

Description Ce service gère les événements et les journaux d’événements. Il prend en

charge l’enregistrement des événements, les requêtes sur les événements,
l’abonnement aux événements, l’archivage des journaux d’événements et la
gestion des métadonnées d’événements. Il peut afficher des événements en
XML et en format de texte brut. L’arrêt de ce service peut compromettre la
sécurité et la fiabilité du système.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Pare-feu Windows
Nom Description

Nom du service MpsSvc

Description Le Pare-feu Windows vous aide à protéger votre ordinateur en empêchant

les utilisateurs non autorisés d'accéder à votre ordinateur via Internet ou un
réseau.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service de cache de polices Windows

Nom Description

Nom du service FontCache

Nom Description

Description Optimise le niveau de performance des applications en mettant en cache les

données des polices communément utilisées. Les applications démarrent ce
service s’il n’est pas déjà en fonctionnement. Il peut être désactivé ; il en
résulte cependant une dégradation du niveau de performance des
applications.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Acquisition d’image Windows (WIA)

Nom Description

Nom du service stisvc

Description Fournit des services d’acquisition d’images pour les scanneurs et les appareils
photo

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Aucun

Service Windows Insider

Nom Description

Nom du service wisvc

Description wisvc

Installation Toujours installé

Type de Manuelle
démarrage
Nom Description

Recommandation Possibilité de désactivation

Commentaires Server ne prend pas en charge la distribution de version d'évaluation et dès

lors, il n'est pas opérationnel sur Server. Ce service peut aussi être désactivé
via la stratégie de groupe.

Windows Installer
Nom Description

Nom du service msiserver

Description Ajoute, modifie et supprime des applications fournies en tant que package
Windows Installer (*.msi, *.msp). Si ce service est désactivé, le démarrage de
tout service qui en dépend explicitement échouera.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Serveur Gestionnaire de licences Windows

Nom Description

Nom du service LicenseManager

Description Permet la prise en charge de l'infrastructure du Microsoft Store. Ce service

démarre à la demande. S'il est désactivé, le contenu acheté via le Microsoft
Store ne se comporte pas correctement.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun
Windows Management Instrumentation
Nom Description

Nom du service Winmgmt

Description Fournit une interface commune et un modèle objet pour accéder aux
informations de gestion du système d’exploitation, des périphériques, des
applications et des services. Si ce service est arrêté, la plupart des logiciels sur
base Windows ne fonctionneront pas correctement. Si ce service est
désactivé, le démarrage de tout service qui en dépend explicitement
échouera.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service Point d'accès sans fil mobile Windows

Nom Description

Nom du service icssvc

Description Permet de partager une connexion de données cellulaires avec un autre

appareil.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Aucun

Programme d’installation pour les modules

Windows
Nom Description

Nom du service TrustedInstaller

Nom Description

Description Permet l’installation, la modification et la suppression de composants

facultatifs et de mises à jour Windows. Si ce service est désactivé,
l’installation ou la désinstallation de mises à jour Windows peut échouer pour
cet ordinateur.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service du système de notifications Push

Windows
Nom Description

Nom du service WpnService

Description Ce service s’exécute dans la session 0 et héberge la plateforme de

notification et le fournisseur de connexion qui gère la connexion entre
l’appareil et le serveur WNS.

Installation Avec Expérience utilisateur uniquement

Type de Automatique
démarrage

Recommandation Possibilité de désactivation

Commentaires Requis pour les vignettes dynamiques et autres fonctionnalités

Service utilisateur de notifications Push

Windows
Nom Description

Nom du service WpnUserService

Description Ce service héberge la plateforme de notification Windows qui fournit la prise

en charge des notifications locales et Push. Les notifications prises en charge
sont tile, toast et raw.
Nom Description

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Possibilité de désactivation

Commentaires Modèle de service utilisateur

Windows Remote Management (WS-

Management)
Nom Description

Nom du service WinRM

Description Le service Gestion à distance de Windows (WinRM) implémente le protocole

WS-Management pour la gestion à distance. WS-Management est un
protocole des services web standard utilisé pour la gestion à distance de
logiciels et de matériel. Le service Gestion à distance de Windows écoute sur
le réseau les demandes WS-Management et les traite. Ce service doit être
configuré avec un écouteur à l'aide de l'outil en ligne de commande
[Link] ou via la stratégie de groupe de façon à ce qu'il puisse être à
l'écoute. Il permet d'accéder aux données WMI et de collecter des
événements. La collecte d'événements et l'abonnement à des événements
nécessitent que le service soit en cours d'exécution. Les messages du service
Gestion à distance de Windows utilisent HTTP et HTTPS comme transport. Le
service Gestion à distance de Windows ne dépend pas d'IIS mais il est
préconfiguré pour partager un port avec IIS sur le même ordinateur. Le
service Gestion à distance de Windows réserve le préfixe d'URL /wsman. Pour
éviter les conflits avec IIS, les administrateurs doivent vérifier que les sites
web hébergés sur IIS n'utilisent pas le préfixe d'URL /wsman.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Ne pas désactiver

Commentaires Requis pour la gestion à distance

Windows Search
Nom Description

Nom du service WSearch

Description Fournit des fonctionnalités d’indexation de contenu, de mise en cache des

propriétés, de résultats de recherche pour les fichiers, les messages
électroniques et autres contenus.

Installation Avec Expérience utilisateur uniquement

Type de Désactivé
démarrage

Recommandation Déjà désactivé

Commentaires Aucun

Horloge Windows
Nom Description

Nom du service W32Time

Description Assure la synchronisation de la date et de l’heure sur tous les clients et

serveurs sur le réseau. Si ce service est arrêté, la synchronisation de la date et
de l’heure sera indisponible. Si ce service est désactivé, le démarrage de tout
service qui en dépend explicitement échouera.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Windows Update
Nom Description

Nom du service wuauserv

Nom Description

Description Active la détection, le téléchargement et l’installation des mises à jour de

Windows et d’autres programmes. Si ce service est désactivé, les utilisateurs
de cet ordinateur ne pourront pas utiliser Windows Update ou sa
fonctionnalité de mise à jour automatique, et les programmes ne pourront
pas utiliser l’API de l’Agent de mise à jour automatique Windows Update
(WUA).

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Service de découverte automatique de Proxy

Web pour les services HTTP Windows
Nom Description

Nom du service WinHttpAutoProxySvc

Description WinHTTP implémente la pile HTTP du client et fournit aux développeurs une
API Win32 et un composant d’automatisation COM pour l’envoi des
demandes HTTP et la réception des réponses. En outre, WinHTTP prend en
charge la découverte automatique d’une configuration de proxy via son
implémentation du protocole WPAD (Web Proxy Auto-Discovery).

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Ne pas désactiver

Commentaires Tous les éléments utilisant la pile réseau peut dépendre de ce service. De
nombreuses organisations l'utilisent pour configurer le routage de proxy
HTTP de leurs réseaux internes. Sans ce service, les connexions HTTP internes
vers Internet échouent.

Service de configuration automatique de

réseau câblé
Nom Description

Nom du service dot3svc

Description Le service Wired AutoConfig (DOT3SVC) est responsable de l’exécution de

l’authentification IEEE 802.1X sur les interfaces Ethernet. Si votre déploiement
de réseau câblé actuel applique l’authentification 802.1X, le service DOT3SVC
doit être configuré de façon à s’exécuter pour l’établissement de la
connectivité de Couche 2 et/ou fournir l’accès aux ressources réseau. Les
réseaux câblés qui n’appliquent pas l’authentification 802.1X ne sont pas
concernés par le service DOT3SVC.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Carte adaptateur de performance WMI

Nom Description

Nom du service wmiApSrv

Description Fournit des informations concernant la bibliothèque de performance à partir

des fournisseurs WMI (Windows Management Instrumentation) à des clients
sur le réseau. Ce service s’exécute uniquement quand l’assistant de
performance des données est activé.

Installation Toujours installé

Type de Manuelle
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Station de travail
Nom Description

Nom du service LanmanWorkstation

Nom Description

Description Crée et maintient des connexions réseau client à des serveurs distants à l’aide
du protocole SMB. Si ce service est arrêté, ces connexions ne seront pas
disponibles. Si ce service est désactivé, le démarrage de tout service qui en
dépend explicitement échouera.

Installation Toujours installé

Type de Automatique
démarrage

Recommandation Pas de recommandations

Commentaires Aucun

Gestionnaire d'authentification Xbox Live

Nom Description

Nom du service XblAuthManager

Description Fournit des services d'authentification et d'autorisation pour interagir avec

Xbox Live. Si ce service est arrêté, certaines applications risquent de ne pas
fonctionner correctement.

Installation Avec Expérience utilisateur uniquement

Type de Manuelle
démarrage

Recommandation Doit être désactivé

Commentaires Aucun

Jeu sauvegardé sur Xbox Live

Nom Description

Nom du service XblGameSave

Description Ce service synchronise les données enregistrées pour les jeux dont la
sauvegarde sur Xbox Live est activée. Si ce service est arrêté, les données
enregistrées des jeux ne seront téléchargées ni vers, ni depuis Xbox Live.

Installation Avec Expérience utilisateur uniquement

Nom Description

Type de Manuelle
démarrage

Recommandation Doit être désactivé

Commentaires Ce service synchronise les données enregistrées pour les jeux dont la
sauvegarde sur Xbox Live est activée. Si ce service est arrêté, les données
enregistrées des jeux ne seront téléchargées ni vers, ni depuis Xbox Live.
Services par utilisateur dans Windows
Article • 26/12/2023 • S’applique à: ✅ Windows 11, ✅ Windows 10, ✅ Windows Server

Lorsqu’un utilisateur se connecte à Windows, le système d’exploitation crée des services par
utilisateur. Lorsque l’utilisateur se déconnecte, ces services sont arrêtés et supprimés. Ils s’exécutent
dans le contexte de sécurité du compte d’utilisateur au lieu d’un principal de sécurité intégré. Ce
comportement offre une meilleure gestion des ressources que l’approche précédente consistant à
exécuter ces services associés à un compte préconfiguré ou en tant que tâches.

７ Notes

Les services par utilisateur ne sont disponibles dans Windows Server que si vous installez
l’Expérience utilisateur. Pour plus d’informations, consultez Server Core et Server with
Desktop Experience install options.

Windows crée ces services par utilisateur en fonction de modèles définis dans le Registre. Si vous
avez besoin de gérer ou de contrôler les comportements de ces services, vous pouvez ajuster le
modèle. Par exemple, vous pouvez définir le type de démarrage d’un service de modèle sur
Désactivé. Dans cet exemple, Windows crée le service par utilisateur dans un état arrêté et
désactivé.

） Important

Testez soigneusement les modifications apportées à la configuration du service de modèle

avant de les déployer à grande échelle dans un environnement de production.

Utilisez les informations de cet article pour comprendre les services par utilisateur, configurer des
modèles de service utilisateur et gérer les services par utilisateur via des modèles de stratégie de
groupe et de sécurité.

Liste des services par utilisateur

Le tableau suivant répertorie les services par utilisateur dans la version actuelle de Windows. Les
autres versions de Windows 10/11 peuvent ne pas avoir les mêmes services disponibles.

Avant de reconfigurer l’un de ces services, passez en revue ces informations pour comprendre les
implications. Par exemple, si vous désactivez le service par utilisateur, il peut y avoir des
applications dépendantes qui ne fonctionnent pas correctement.

ﾉ Agrandir le tableau
Nom Nom du service Type de Dépendances Description
d’affichage démarrage
par défaut

Runtime AarSvc Manual Runtime pour l’activation

d’activation de des applications d’agent
l’agent conversationnel.

Service de BluetoothUserService Manual Prend en charge les

support fonctionnalités Bluetooth
utilisateur appropriées pour chaque
Bluetooth session utilisateur.

OneCore CaptureService Manual Active la fonctionnalité de

Capture Service capture d’écran facultative
pour les applications qui
appellent des API de
capture d’écran de
l’espace de noms
[Link]
.

Service cbdhsvc Automatisé Windows utilise ce service

utilisateur du (démarrage utilisateur pour les
Presse-papiers différé) scénarios du Presse-
papiers. Par exemple,
l’historique du Presse-
papiers ou la
synchronisation entre les
appareils. Pour plus
d’informations, consultez
Presse-papiers dans
Windows .

Service de CloudBackupRestoreSvc Manual Surveille le système pour

sauvegarde et les modifications
de restauration apportées aux états de
cloud l’application et des
paramètres. Si nécessaire,
ce service effectue des
opérations de sauvegarde
et de restauration cloud.

Service CDPUserSvc Automatique - Répartiteur Ce service permet à

utilisateur de la de l’utilisateur de connecter,
plateforme connexions de gérer et de contrôler
d’appareils réseau - les appareils connectés.
connectés Appel de Ces appareils connectés
procédure incluent les appareils
distante (RPC) mobiles, Xbox, HoloLens
- Pilote de ou intelligents/IoT. Pour
protocole obtenir un exemple
TCP/IP spécifique, consultez
Partager des éléments
avec des appareils à
Nom Nom du service Type de Dépendances Description
d’affichage démarrage
par défaut

proximité dans
Windows .

Service ConsentUxUserSvc Manual Permet au système de

utilisateur demander le
utilisateur de consentement de
consentement l’utilisateur pour autoriser
les applications à accéder
à des ressources sensibles
et à des informations
telles que l’emplacement
de l’appareil.

Données de PimIndexMaintenanceSvc Manual UnistoreSvc Indexe les données de

contact contact pour une
recherche rapide des
contacts. Si vous arrêtez
ou désactivez ce service, il
se peut que les contacts
soient manquants dans
vos résultats de recherche.

Gestionnaire CredentialEnrollmentManagerUserSvc Manual Ce service prend en

d’inscription charge le stockage
des sécurisé et la récupération
informations des informations
d’identification d’identification de
l’utilisateur. Par exemple,
les jetons pour les sites
web, les connexions
Bureau à distance ou
d’autres applications.

Répartiteur DeviceAssociationBrokerSvc Manual - DevicePicker Prend en charge le

d’association - Expérience jumelage dans
d’appareils utilisateur du l’application et les
jumelage vérifications d’accès pour
d’interpréteur les nouveaux scénarios
de d’appareil.
commandes

Sélecteur DevicePickerUserSvc Manual Windows utilise ce service

d’appareils utilisateur pour gérer les
expériences Miracast,
DLNA (Digital Living
Network Alliance) et Dial
(Discovery and Launch).

Flux d’appareils DevicesFlowUserSvc Manual Permet à l’interface

utilisateur Connecter et à
l’application Paramètres
de se connecter à des
Nom Nom du service Type de Dépendances Description
d’affichage démarrage
par défaut

écrans Wi-Fi et à des

appareils Bluetooth et de
les associer.

Jeu DVR et BcastDVRUserService Manual Windows utilise ce service

service utilisateur pour les
utilisateur de enregistrements de jeux et
diffusion les diffusions en direct.

Service de Service de messagerie Manual Ce service prend en

messagerie charge la messagerie texte
et les fonctionnalités
associées.

En cours de NPSMSvc Manual Le service gestionnaire de

lecture dans le session en lecture (NPSM)
Gestionnaire de gère les sessions
session multimédias en cours
d’exécution sur l’appareil.

Service P9RdrService Manual Active les serveurs de

redirecteur fichiers plan9 de
plan 9 démarrage du
déclencheur, qui sont pris
en charge par Sous-
système Windows pour
Linux. Pour plus
d’informations, consultez
Plan 9 de Bell Labs .

Service de PenService Manual Lorsque vous appuyez sur

stylet le bouton de fin sur un
périphérique d’entrée de
stylet, ce service répond à
ces actions. Il peut lancer
des applications ou
effectuer une autre action
que vous personnalisez
dans Paramètres. Pour
plus d’informations,
consultez la
documentation de
l’utilisateur sur l’utilisation
de votre stylet Surface
ou de la documentation
du développeur matériel
sur les appareils stylet.

Flux de travail PrintWorkflowUserSvc Manual Fournit la prise en charge

d’impression des applications de flux de
travail d’impression . Si
vous désactivez ce service,
Nom Nom du service Type de Dépendances Description
d’affichage démarrage
par défaut

certaines fonctions
d’impression risquent de
ne pas fonctionner
correctement.

Hôte de OneSyncSvc Automatisé Ce service synchronise la

synchronisation (démarrage messagerie, les contacts,
différé) le calendrier et d’autres
données utilisateur.
Lorsque ce service est
arrêté, la messagerie et les
autres applications
dépendantes de cette
fonctionnalité ne
fonctionnent pas
correctement.

Service UdkUserSvc Manual Windows utilise ce service

utilisateur UDK pour coordonner les
expériences de
l’interpréteur de
commandes.

Accès aux UserDataSvc Manual UnistoreSvc Fournit aux applications

données l’accès aux données
utilisateur utilisateur structurées, y
compris les informations
de contact, les calendriers,
les messages et d’autres
contenus. Si vous arrêtez
ou désactivez ce service,
les applications qui
utilisent ces données
risquent de ne pas
fonctionner correctement.

Stockage des UnistoreSvc Manual Gère le stockage des

données données utilisateur
utilisateur structurées, notamment
les informations de
contact, les calendriers, les
messages et d’autres
contenus. Si vous arrêtez
ou désactivez ce service,
les applications qui
utilisent ces données
risquent de ne pas
fonctionner correctement.

Service webthreatdefusersvc Automatique Ce service permet de

utilisateur de protéger votre ordinateur
défense contre en avertissant l’utilisateur
 Nom Nom du service Type de Dépendances Description
d’affichage démarrage
par défaut

les menaces lorsque des entités non

web autorisées tentent
d’accéder à leurs
informations
d’identification.

Service WpnUserService Automatique Ce service héberge la

utilisateur de plateforme WNS (
notifications Windows Push
Push Windows Notification Services ), qui
prend en charge les
notifications Push locales
et push. Les notifications
prises en charge sont des
vignettes, des toasts et
des notifications brutes.

Afficher les services par utilisateur

Vous ne pouvez pas afficher les modèles de service utilisateur en dehors du Registre Windows,
mais vous pouvez voir les services par utilisateur spécifiques à l’utilisateur. Windows affiche ces
services au format suivant : <service name>_LUID où <service name> est le nom complet du service
utilisateur et LUID est un identificateur local unique pour le contexte utilisateur.

Par exemple, vous pouvez voir les noms de service par utilisateur suivants :

Contact Data_443f50
Sync Host_443f50

User Data Access_443f50

User Data Storage_443f50

７ Notes

Le nom d’affichage et le nom du service pour tous les services par utilisateur incluent le même
suffixe LUID.

Afficher les services par utilisateur dans la console Des services

Windows
Lorsque vous vous connectez à Windows, exécutez [Link] pour ouvrir la console Services.
Lorsque vous affichez l’ordinateur local, vous pouvez voir ces services pour votre compte
d’utilisateur.
Afficher les services par utilisateur à l’aide de Windows
PowerShell
Le script PowerShell suivant montre comment interroger des services par utilisateur. Il interroge les
valeurs de type de service qui incluent la valeur de 64 bits.

PowerShell

# Define the bit value for per-user services in the ServiceType property of a service
object
$flag = 64

# Define an empty array to store the resulting services that match the criteria
$serviceList = @()

# Get all services on the computer and store them in the variable
$services = Get-Service

# Loop through each service in the array of services.

foreach ( $service in $services ) {
# For each specific service, check if the service type property includes the 64 bit
using the bitwise AND operator (-band).
# If the result equals the flag value, then the service is a per-user service.
if ( ( $[Link] -band $flag ) -eq $flag ) {
# When a per-user service is found, then add that service object to the results
array.
$serviceList += $service
}
}

# Display the results array, sorted by display name, in a table format with the
specified properties.
$serviceList | Sort-Object DisplayName | Format-Table DisplayName, Name, StartType,
ServiceType

Afficher les services par utilisateur à partir de la ligne de

commande
Exécutez [Link] pour ouvrir une invite de commandes Windows. Utilisez la sc qc commande
pour interroger ces services. La valeur Type indique si le service est un modèle de service utilisateur
ou un instance de service utilisateur.

L’exemple suivant interroge le modèle et les instance spécifiques à l’utilisateur du service DVR
game et Broadcast User Service ( BcastDVRUserService ) :

Invite de commandes Windows

sc qc BcastDVRUserService
sc qc BcastDVRUserService_18f113
Comment désactiver les services par utilisateur
Les modèles des services utilisateur ne sont pas affichés dans la console Services ([Link]).
Pour désactiver un service par utilisateur, vous devez modifier directement le Registre, à l’aide
d’une stratégie de groupe ou d’une solution scriptée. Les modèles se trouvent dans le Registre à
l’adresse HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services .

７ Notes

Lorsque vous désactivez un service par utilisateur, Windows le crée quand l’utilisateur se
connecte, mais dans un état arrêté et désactivé. Lorsque l’utilisateur se déconnecte, Windows
supprime le service par utilisateur.

Vous ne pouvez pas gérer tous les modèles de service par utilisateur à l’aide des méthodes
normales de gestion des stratégies de groupe. Étant donné que les services par utilisateur ne sont
pas affichés dans le console de gestion Services, ils ne sont pas non plus affichés dans l’éditeur de
stratégie des services de stratégie de groupe.

En outre, il existe quatre services utilisateur que vous ne pouvez pas gérer avec un modèle de
sécurité :

PimIndexMaintenanceSvc
UnistoreSvc
UserDataSvc
WpnUserService

Avec ces restrictions, vous pouvez utiliser les méthodes suivantes pour gérer les modèles de service
par utilisateur :
 Combinaison d’un modèle de sécurité et d’un script, ou d’une stratégie de registre des
préférences de stratégie de groupe.
Préférences de stratégie de groupe pour tous les services.
Script pour tous les services.

Gérer les services de modèle à l’aide d’un modèle de sécurité

Vous pouvez gérer les services CDPUserSvc et OneSyncSvc par utilisateur avec un modèle de
sécurité.

Par exemple :

ini

[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
[Service General Setting]
"CDPUserSVC".4,""

Utiliser un script pour gérer les services par utilisateur

Vous pouvez créer un script pour modifier le type de démarrage des services par utilisateur. Utilisez
ensuite une stratégie de groupe ou une autre solution de gestion telle que Microsoft Configuration
Manager pour déployer le script sur des appareils ciblés.

Exemple 1 : Utiliser l’applet de Set-Service commande PowerShell

L’exemple de script suivant utilise l’applet de commande PowerShell Set-Service pour configurer le
type de démarrage du service PimIndexMaintenanceSvc sur désactivé :

PowerShell

Set-Service -Name PimIndexMaintenanceSvc -StartupType Disabled

Exemple 2 : Utiliser la ligne de [Link] config commande

L’exemple de script suivant utilise [Link] config pour configurer le type de démarrage du service
PimIndexMaintenanceSvc sur désactivé :

Invite de commandes Windows

[Link] configure PimIndexMaintenanceSvc start= disabled

 ７ Notes

L’espace après = est intentionnel.

Gérer les services de modèle à l’aide des préférences de stratégie

de groupe
Si vous ne pouvez pas désactiver un service par utilisateur avec le modèle de sécurité, utilisez les
préférences de stratégie de groupe.

1. Ouvrez la console de gestion stratégie de groupe ([Link]).

2. Créez un objet de stratégie de groupe (GPO) ou utilisez un objet de stratégie de groupe

existant.

3. Modifiez l’objet de stratégie de groupe pour lancer l’éditeur d’objet de stratégie de groupe.

4. Selon la façon dont vous souhaitez cibler la stratégie de groupe, sous Configuration de
l’ordinateur ou Configuration de l’utilisateur , accédez à Préférences, Paramètres Windows,
puis sélectionnez Registre.

5. Accédez au menu Action , sélectionnez Nouveau, puis Élément de Registre.

6. Pour Hive , sélectionnez HKEY_LOCAL_MACHINE .

7. Sélectionnez les points de suspension ( ... ) en regard de Chemin de la clé. Accédez à
System\CurrentControlSet\Services , puis sélectionnez le modèle de service utilisateur.

Exemple : PimIndexMaintenanceSvc . Dans la liste des valeurs, mettez en surbrillance Démarrer

et sélectionnez Sélectionner.
 8. Dans la fenêtre Propriétés de démarrage , modifiez les données de valeur de 00000003 à
00000004 et sélectionnez OK. Notez que les données de valeur sont 4 = désactivées.

７ Notes

La valeur 4 de début du service est Désactivé.

9. Pour ajouter les autres services qui ne peuvent pas être gérés avec des modèles de stratégie
de groupe, modifiez la stratégie et répétez les étapes précédentes.

Gestion des modèles de service utilisateur avec le Registre

Windows
Si vous ne pouvez pas utiliser les préférences de stratégie de groupe pour gérer les services par
utilisateur, vous pouvez modifier le Registre Windows. Pour désactiver un modèle de service
utilisateur, remplacez le type de démarrage de chaque service par 4 , ce qui est Désactivé.

Ｕ Attention

Ne modifiez pas directement le Registre, sauf s’il n’existe aucune autre alternative. L’Éditeur du
Registre ou Windows ne valident pas ces modifications manuelles du Registre. Des valeurs
incorrectes peuvent être stockées, ce qui peut entraîner des erreurs irrécupérables dans le
système. Si possible, au lieu de modifier directement le Registre, utilisez une stratégie de
groupe ou d’autres outils Windows pris en charge pour accomplir ces tâches. Si vous devez
modifier le registre, faites preuve d’une extrême prudence.
Exemple 1 : Utiliser la commande de ligne de [Link] commande pour
modifier le Registre
1. En tant qu’administrateur, exécutez [Link] pour ouvrir une invite de commandes Windows.

2. L’exemple suivant inclut plusieurs commandes qui désactivent les services Windows spécifiés
en remplaçant leur valeur de démarrage dans le Registre Windows par 4 :

Invite de commandes Windows

[Link] ADD HKLM\System\CurrentControlSet\Services\CDPUserSvc /v Start /t REG_DWORD /d

4 /f
[Link] ADD HKLM\System\CurrentControlSet\Services\OneSyncSvc /v Start /t REG_DWORD /d
4 /f
[Link] ADD HKLM\System\CurrentControlSet\Services\PimIndexMaintenanceSvc /v Start /t
REG_DWORD /d 4 /f
[Link] ADD HKLM\System\CurrentControlSet\Services\UnistoreSvc /v Start /t REG_DWORD
/d 4 /f
[Link] ADD HKLM\System\CurrentControlSet\Services\UserDataSvc /v Start /t REG_DWORD
/d 4 /f
[Link] ADD HKLM\System\CurrentControlSet\Services\WpnUserService /v Start /t
REG_DWORD /d 4 /f

Exemple 2 : Utiliser l’interface utilisateur de l’Éditeur du Registre pour

modifier le Registre

1. En tant qu’administrateur, exécutez [Link] pour ouvrir l’Éditeur du Registre.

2. Accédez à HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services , puis sélectionnez le

modèle de service utilisateur. Exemple : CDPSvc .

3. Dans la liste des valeurs, ouvrez la valeur de début .

4. Remplacez les données de valeur par 4 .

Exemple 3 : Empêcher la création de services par utilisateur

Vous pouvez empêcher Windows de créer un service par utilisateur lorsqu’un utilisateur se
connecte. Dans le même nœud de modèle de service du Registre, définissez sur
UserServiceFlags 0 .

Étapes suivantes
Pour plus d’informations sur la désactivation des services système pour Windows Server, consultez
Conseils sur la désactivation des services système sur Windows Server avec expérience utilisateur.

Commentaires
Cette page a-t-elle été utile ?  Yes  No

Indiquer des commentaires sur le produit

Vue d’ensemble de l’authentification
Windows
Article • 13/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cette rubrique de navigation pour les professionnels de l’informatique répertorie des

ressources de documentation pour l’authentification Windows et les technologies
d’ouverture de session qui comprennent l’évaluation du produit, les guides de prise en
main, les procédures, les guides de conception et de déploiement, les références
techniques et les références des commandes.

Description de la fonctionnalité
L’authentification est un processus de vérification de l’identité d’un objet, d’un service
ou d’une personne. Lorsque vous authentifiez un objet, l’objectif est de vérifier que
celui-ci est authentique. Lorsque vous authentifiez un service ou une personne, l’objectif
est de vérifier que les informations d’identification présentées sont authentiques.

Dans un contexte de réseau, l’authentification est le fait de prouver une identité à une
application ou une ressource réseau. En général, l’identité est prouvée par une opération
de chiffrement qui utilise soit une clé connue uniquement par l’utilisateur (comme avec
le chiffrement à clé publique), soit une clé partagée. Le côté serveur de l’échange
d’authentification compare les données signées avec une clé de chiffrement connue
pour valider la tentative d’authentification.

Le stockage des clés de chiffrement dans un emplacement centralisé sécurisé rend le

processus d’authentification évolutif et facile à gérer. Les services de domaine
Active Directory représentent la technologie par défaut et recommandée pour le
stockage d’informations d’identité (notamment les clés de chiffrement qui constituent
les informations d’identification de l’utilisateur). Active Directory est requis pour les
implémentations NTLM et Kerberos par défaut.

Les techniques d’authentification vont d’une simple ouverture de session, qui identifie
les utilisateurs en fonction d’une information que seul l’utilisateur connaît, comme un
mot de passe, à des mécanismes de sécurité plus puissants qui utilisent des éléments
dont dispose l’utilisateur, comme les jetons, les certificats de clé publique et la
biométrie. Dans un environnement d’entreprise, les services ou les utilisateurs peuvent
accéder à plusieurs applications ou ressources sur plusieurs types de serveurs dans un
même emplacement ou dans plusieurs emplacements. C’est pourquoi l’authentification
doit prendre en charge des environnements pour d’autres plateformes et pour d’autres
systèmes d’exploitation Windows.

Le système d’exploitation Windows implémente un ensemble par défaut de protocoles

d’authentification, notamment Kerberos, NTLM, TLS/SSL (Transport Layer
Security/Secure Sockets Layer) et Digest, dans une architecture extensible. En outre,
certains protocoles sont combinés en packages d’authentification, par exemple
Negotiate et CredSSP (Credential Security Support Provider). Ces protocoles et packages
permettent l’authentification des utilisateurs, des ordinateurs et des services ; le
processus d’authentification permet à son tour aux utilisateurs et services autorisés
d’accéder aux ressources de façon sécurisée.

Pour plus d’informations sur l’authentification Windows, notamment :

Concepts de l’authentification Windows

Scénarios d’ouverture de session Windows

Architecture d’authentification Windows

Architecture de l’interface du fournisseur SSP (Security Support Provider)

Processus des informations d’identification dans l’authentification Windows

Paramètres de stratégie de groupe utilisés dans l’authentification Windows

voir Vue d’ensemble technique de l’authentification Windows.

Cas pratiques
L’authentification Windows est utilisée pour vérifier que les informations proviennent
d’une source approuvée, qu’il s’agisse d’une personne ou d’un objet ordinateur, tel
qu’un autre ordinateur. Windows offre de nombreuses méthodes différentes pour y
parvenir, comme indiqué ci-dessous.

À... Fonctionnalité Description

À... Fonctionnalité Description

S’authentifier Kerberos Les systèmes d’exploitation Microsoft Windows Server

dans un implémentent le protocole d’authentification Kerberos
domaine Active version 5 et des extensions pour l’authentification des clés
Directory publiques. Le client d’authentification Kerberos est
implémenté en tant que fournisseur SSP (Security Support
Provider) et il est accessible par le biais de l’interface SSPI
(Security Support Provider Interface). L’authentification
utilisateur initiale est intégrée à l’architecture à
authentification unique Winlogon. Le centre de distribution
de clés Kerberos est intégré à d’autres services de sécurité
Windows Server qui s’exécutent sur le contrôleur de
domaine. Le centre de distribution de clés Kerberos utilise
la base de données du service d’annuaire Active Directory
du domaine en tant que base de données de son compte
de sécurité. Active Directory est requis pour les
implémentations Kerberos par défaut.
Pour obtenir des ressources supplémentaires, voir Vue
d’ensemble de l’authentification Kerberos.

Authentification TLS/SSL tel Le protocole TLS (Transport Layer Security) versions 1.0, 1.1
sécurisée sur le qu’implémenté et 1.2, le protocole SSL (Secure Sockets Layer) versions 2.0
Web dans le et 3.0, le protocole DTLS (Datagram Transport Layer
fournisseur SSP Security) version 1.0 et le protocole PCT (Private
Schannel Communications Transport) version 1.0 sont basés sur le
chiffrement à clé publique. La suite de protocoles
d’authentification SSP Schannel fournit ces protocoles.
Tous les protocoles Schannel utilisent un modèle client et
serveur.
Pour obtenir des ressources supplémentaires, consultez
TLS - Vue d’ensemble du protocole SSL (SSP Schannel).

S’authentifier Authentification Pour obtenir des ressources supplémentaires, voir

sur un service Windows Authentification Windows intégrée, Authentification Digest
Web ou une intégrée et Authentification Digest avancée.
application Authentification
Digest

S’authentifier NTLM NTLM est un protocole d’authentification de style

sur des stimulation-réponse. Outre l’authentification, le protocole
applications NTLM offre éventuellement la sécurité de session, et en
héritées particulier l’intégrité et la confidentialité des messages via
des fonctions de signature et de scellement dans NTLM.
Pour obtenir des ressources supplémentaires, voir Vue
d’ensemble de NTLM.
 À... Fonctionnalité Description

Tirer parti de Prise en charge Les cartes à puce représentent un moyen résistant aux
l’authentification des cartes à falsifications et portable permettant d’offrir des solutions
multifacteur puce de sécurité pour des tâches telles que l’authentification des
Prise en charge clients, la connexion aux domaines, la signature du code et
de la biométrie la sécurisation des messages électroniques.
Elle consiste à mesurer une caractéristique physique
inaltérable d’une personne pour identifier celle-ci de façon
unique. Les empreintes digitales font partie des
caractéristiques biométriques les plus utilisées, notamment
avec les millions de lecteurs d’empreintes digitales intégrés
aux ordinateurs personnels et aux périphériques.

Pour obtenir des ressources supplémentaires, consultez

Informations techniques de référence sur les cartes à puce.

Assurer la Gestion des La gestion des informations d’identification dans Windows

gestion locale, le informations garantit le stockage sécurisé des informations
stockage et la d’identification d’identification. Les informations d’identification sont
réutilisation des Autorité de collectées sur le Bureau sécurisé (pour un accès local ou au
informations sécurité locale domaine) par le biais d’applications ou de sites Web afin
d’identification que les informations d’identification correctes soient
Mots de passe présentées lors de chaque accès à une ressource.

Étendre la Protection Cette fonctionnalité améliore la protection et le traitement

protection de étendue de des informations d’identification lors de l’authentification
l’authentification l'authentification des connexions réseau à l’aide de l’authentification
moderne à des Windows intégrée.
systèmes hérités

Configuration logicielle requise

L’authentification Windows est conçue pour être compatible avec les précédentes
versions du système d’exploitation Windows. Cependant, les améliorations apportées à
chaque version ne sont pas nécessairement applicables aux versions précédentes. Pour
plus d’informations, reportez-vous à la documentation relative à des fonctionnalités
spécifiques.

Informations sur le Gestionnaire de serveur

De nombreuses fonctionnalités d’authentification peuvent être configurées à l’aide
d’une stratégie de groupe, laquelle peut être installée avec le Gestionnaire de serveur.
Les fonctionnalités Windows Biometric Framework sont installées à l’aide du
Gestionnaire de serveur. D’autres rôles de serveur qui dépendent des méthodes
d’authentification, tels que les rôles de serveur Web (IIS) et de services de domaine
Active Directory, peuvent également être installés à l’aide du Gestionnaire de serveur.

Ressources associées
Technologies Ressources
d’authentification

Authentification Vue d’ensemble technique de l’authentification Windows

Windows Inclut des rubriques traitant des différences entre les versions, des concepts
d’authentification généraux, des scénarios de connexion, des architectures
pour les versions prises en charge et des paramètres applicables.

Kerberos Vue d’ensemble de l’authentification Kerberos

Vue d’ensemble de la délégation Kerberos contrainte

Référence technique de l’authentification Kerberos(2003)

Forum Kerberos

TLS/SSL et DTLS Vue d’ensemble de TLS/SSL (SSP Schannel)

(fournisseur SSP
Schannel) Informations techniques de référence sur le fournisseur SSP (Security
Support Provider) Schannel

Authentification Référence technique de l’authentification Digest(2003)

Digest

NTLM NTLM Overview

Contient des liens vers des ressources actuelles et anciennes

PKU2U Présentation de PKU2U dans Windows

Carte à puce Informations techniques de référence sur les cartes à puce

Informations Gestion et protection des informations d’identification

d'identification Contient des liens vers des ressources actuelles et anciennes

Vue d’ensemble sur les mots de passe

Contient des liens vers des ressources actuelles et anciennes
Vue d’ensemble technique de
l’authentification Windows
Article • 11/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cette rubrique destinée aux professionnels de l’informatique fournit des liens vers des
rubriques pour la vue d’ensemble technique de l’authentification Windows.
L’authentification Windows est le processus permettant de prouver l’authenticité d’un
utilisateur ou d’un service qui tente d’accéder à Windows.

Cette collection de rubriques décrit l’architecture de l’authentification Windows et ses

composants.

Pour enregistrer ou imprimer numériquement des pages de cette bibliothèque, cliquez

sur Exporter (en haut à droite de la page), puis suivez les instructions.

Différences dans l’authentification Windows entre les systèmes d’exploitation

Windows

Décrit les différences significatives dans l’architecture et les processus

d’authentification.

Concepts de l’authentification Windows

Décrit les concepts sur lesquels l’authentification Windows est basée.

Scénarios d’authentification de connexion Windows

Résume les différents scénarios d’ouverture de session.

Architecture d’authentification Windows

Décrit les différences significatives dans l’architecture et les processus

d’authentification pour les systèmes d’exploitation Windows.

Architecture de l’interface du fournisseur SSP (Security Support Provider)

Décrit l’architecture SSPI.

Processus des informations d’identification dans l’authentification Windows

Décrit les différents processus de gestion des informations d’identification.

 Stratégies de groupe utilisées dans l’authentification Windows

Décrit l’utilisation et l’impact des stratégies de groupe dans le processus

d’authentification.

Sujets non couverts

Cette collection de rubriques ne couvre pas les procédures de conception,
d’implémentation ou de surveillance de vos technologies d’authentification dans un
environnement Windows.

Pour plus d’informations sur la conception des stratégies d’autorisation Windows,

consultez Conception d’une stratégie d’autorisation des ressources.

Pour plus d’informations sur la conception de stratégies d’authentification

Windows, consultez Conception d’une stratégie d’authentification.

Pour plus d’informations sur la conception de stratégies d’implémentation

d’infrastructure à clé publique Windows, consultez Conception d’une infrastructure
à clé publique.

Pour la configuration et la surveillance de la sécurité, y compris l’authentification,

dans votre environnement Windows, consultez :

Base de référence de la sécurité Windows Vista

Base de référence de la sécurité Windows Server 2003 et Guide des menaces et

contre-mesures

Base de référence de la sécurité Windows Server 2008 R2

Pour plus d’informations sur l’audit des événements d’authentification et

d’ouverture de session dans Windows, consultez Audit des événements de
sécurité.
Concepts de l’authentification Windows
Article • 24/09/2024

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cette rubrique de référence décrit les concepts sur lesquels repose l'authentification
Windows.

L’authentification est un processus de vérification de l’identité d’un objet ou d’une

personne. Lorsque vous authentifiez un objet, l’objectif est de vérifier que celui-ci est
authentique. Lorsque vous authentifiez une personne, l’objectif est de vérifier qu’il ne
s’agit pas d’un imposteur.

Dans un contexte de réseau, l’authentification est le fait de prouver une identité à une
application ou une ressource réseau. En général, l’identité est prouvée par une opération
de chiffrement qui utilise soit une clé connue uniquement par l’utilisateur (comme avec
le chiffrement à clé publique), soit une clé partagée. Le côté serveur de l’échange
d’authentification compare les données signées avec une clé de chiffrement connue
pour valider la tentative d’authentification.

Le stockage des clés de chiffrement dans un emplacement centralisé sécurisé rend le

processus d’authentification évolutif et facile à gérer. Active Directory est la technologie
recommandée et par défaut pour stocker les informations relatives à l'identité,
notamment les clés de chiffrement qui constituent les informations d'identification de
l'utilisateur. Active Directory est requis pour les implémentations NTLM et Kerberos
par défaut.

Les techniques d'authentification vont de la simple connexion à un système

d'exploitation ou à un service ou une application, qui identifie les utilisateurs sur la base
d'un élément que seul l'utilisateur connaît, comme un mot de passe, à des mécanismes
de sécurité plus puissants qui utilisent un élément que l'utilisateur possède, comme des
jetons, des certificats de clé publique, des images ou des attributs biologiques. Dans un
environnement d’entreprise, les utilisateurs peuvent accéder à plusieurs applications sur
plusieurs types de serveurs dans un même emplacement ou dans plusieurs
emplacements. C’est pourquoi l’authentification doit prendre en charge des
environnements pour d’autres plateformes et pour d’autres systèmes d’exploitation
Windows.
Authentification et autorisation : une analogie
de voyage
Une analogie de voyage peut aider à expliquer le fonctionnement de l'authentification.
Quelques tâches préparatoires sont généralement nécessaires pour commencer le
voyage. Le voyageur doit prouver sa véritable identité aux autorités de son pays
d'accueil. Cette preuve peut prendre la forme d'une preuve de citoyenneté, du lieu de
naissance, d'une pièce justificative personnelle, de photographies ou de tout autre
document exigé par la législation du pays d'accueil. L'identité du voyageur est validée
par la délivrance d'un passeport, qui est analogue à un compte système délivré et
administré par une organisation - le principal responsable de la sécurité. Le passeport et
la destination prévue sont basés sur un ensemble de règles et de règlements émis par
l’autorité gouvernementale.

Le voyage

Lorsque le voyageur arrive à la frontière internationale, un garde-frontière lui demande

ses coordonnées et le voyageur présente son passeport. Le processus est double :

Le garde authentifie le passeport en vérifiant qu'il a été délivré par une autorité de
sécurité à laquelle le gouvernement local fait confiance (au moins pour la
délivrance des passeports) et en vérifiant que le passeport n'a pas été modifié.

Le garde authentifie le voyageur en vérifiant que le visage correspond à celui de la

personne figurant sur le passeport et que les autres documents requis sont en
règle.

Si le passeport s'avère valide et que le voyageur prouve qu'il en est le propriétaire,

l'authentification est réussie et le voyageur peut être autorisé à franchir la frontière.

L’approbation transitive entre les autorités de sécurité est le fondement de

l'authentification ; le type d'authentification qui a lieu à une frontière internationale est
basé sur l’approbation. Le gouvernement local ne connaît pas le voyageur, mais il fait
confiance au gouvernement hôte. Lorsque le gouvernement hôte a émis le passeport, il
ne connaissait pas non plus le voyageur. Il fait confiance à l'organisme qui a délivré
l'acte de naissance ou d'autres documents. L'organisme qui a délivré l'acte de naissance
a, quant à lui, fait confiance au médecin qui a signé l'acte. Le médecin a assisté à la
naissance du voyageur et a apposé sur le certificat une preuve directe de l'identité, en
l'occurrence l'empreinte du nouveau-né. La confiance ainsi transférée, par le biais
d'intermédiaires de confiance, est transitive.

L’approbation transitive est la base de la sécurité réseau dans l’architecture

client/serveur Windows. Une relation d’approbation s'étend sur un ensemble de
domaines, comme une arborescence de domaine, et forme une relation entre un
domaine et tous les domaines qui lui accordent leur approbation. Par exemple, si le
domaine A a une approbation transitive avec le domaine B, et si le domaine B approuve
le domaine C, le domaine A approuve le domaine C.

Il existe une différence entre l’authentification et l’autorisation. Avec l'authentification, le

système prouve que vous êtes bien celui que vous prétendez être. Avec l'autorisation, le
système vérifie que vous avez le droit de faire ce que vous voulez faire. Pour poursuivre
l'analogie avec les frontières, le simple fait d'authentifier que le voyageur est bien le
propriétaire d'un passeport valide ne l'autorise pas nécessairement à entrer dans un
pays. Les résidents d'un pays donné ne sont autorisés à entrer dans un autre pays sur
simple présentation d'un passeport que dans les cas où le pays dans lequel ils entrent
accorde une autorisation illimitée d'entrée à tous les citoyens de ce pays.

De même, vous pouvez accorder à tous les utilisateurs d'un certain domaine des
autorisations d'accès à une ressource. Tout utilisateur appartenant à ce domaine a accès
à la ressource, tout comme le Canada permet aux citoyens américains d'entrer sur son
territoire. Toutefois, les citoyens américains qui tentent d'entrer au Brésil ou en Inde
constatent qu'ils ne peuvent pas entrer dans ces pays en présentant simplement un
passeport, car ces deux pays exigent des citoyens américains en visite qu'ils soient en
possession d'un visa valide. L'authentification ne garantit donc pas l'accès aux
ressources ni l'autorisation de les utiliser.

Informations d'identification

Ｕ Attention

Lorsque l’utilisateur effectue une connexion locale, ses informations d’identification

sont vérifiées localement par rapport à une copie mise en cache avant d’être
authentifiées avec un fournisseur d’identité via le réseau. Si la vérification du cache
est réussie, l’utilisateur accède au bureau même si l’appareil est hors ligne.
Cependant, si l’utilisateur modifie son mot de passe dans le cloud, le vérificateur
mis en cache n’est pas mis à jour, ce qui signifie qu’il peut toujours accéder à sa
machine locale en utilisant son ancien mot de passe.

Un passeport et, le cas échéant, les visas qui y sont associés sont les documents
acceptés pour un voyageur. Toutefois, ces informations d'identification ne permettent
pas toujours au voyageur d'accéder à toutes les ressources d'un pays. Par exemple, des
accréditations supplémentaires sont nécessaires pour assister à une conférence. Dans
Windows, les informations d'identification peuvent être gérées de manière à permettre
aux titulaires de comptes d'accéder à des ressources sur le réseau sans avoir à fournir à
plusieurs reprises leurs informations d'identification. Ce type d'accès permet aux
utilisateurs d'être authentifiés une seule fois par le système pour accéder à toutes les
applications et sources de données qu'ils sont autorisés à utiliser sans avoir à saisir un
autre identifiant de compte ou un autre mot de passe. La plateforme Windows tire parti
de la possibilité d'utiliser une seule identité d'utilisateur (gérée par Active Directory) sur
l'ensemble du réseau en mettant en cache localement les informations d'identification
de l'utilisateur dans l'autorité de sécurité locale (LSA) du système d'exploitation.
Lorsqu'un utilisateur se connecte au domaine, les packages d'authentification Windows
utilisent de manière transparente les informations d'identification pour fournir une
signature unique lors de l'authentification des informations d'identification aux
ressources du réseau. Pour plus d’informations sur les informations d’identification,
consultez l’article Processus d’informations d’identification dans l’authentification
Windows.

Une forme d'authentification multifacteur pour le voyageur pourrait être l'obligation de

porter et de présenter plusieurs documents pour authentifier son identité, tels qu'un
passeport et les informations relatives à l'inscription à la conférence. Windows
implémente ce formulaire ou cette authentification par le biais de cartes à puce, de
cartes à puce virtuelles et de technologies biométriques.

Principaux de sécurité et comptes

Dans Windows, tout utilisateur, service, groupe ou ordinateur qui peut lancer une action
est un principal de sécurité. Les principaux de sécurité ont des comptes, qui peuvent
être locaux à un ordinateur ou être basés sur un domaine. Par exemple, les ordinateurs
joints à un domaine client Windows peuvent participer à un domaine réseau en
communiquant avec un contrôleur de domaine même lorsqu’aucun utilisateur humain
n’est connecté. Pour lancer des communications, l’ordinateur doit avoir un compte actif
dans le domaine. Avant d’accepter les communications de l’ordinateur, l’autorité de
sécurité locale sur le contrôleur de domaine authentifie l’identité de l’ordinateur, puis
définit le contexte de sécurité de l’ordinateur comme il le ferait pour un principal de
sécurité humain. Ce contexte de sécurité définit l'identité et les capacités d'un utilisateur
ou d'un service sur un ordinateur particulier ou d'un utilisateur, d'un service, d'un
groupe ou d'un ordinateur sur un réseau. Par exemple, il définit les ressources, telles
qu'un partage de fichiers ou une imprimante, auxquelles il est possible d'accéder et les
actions, telles que Lire, Écrire ou Modifier, qui peuvent être effectuées par un utilisateur,
un service ou un ordinateur sur cette ressource. Pour plus d’informations, consultez
l’article Principaux de sécurité.
Un compte est un moyen d'identifier un demandeur (l'utilisateur humain ou le service)
qui demande un accès ou des ressources. Le voyageur qui détient le passeport
authentique possède un compte dans le pays d'accueil. Les utilisateurs, les groupes
d'utilisateurs, les objets et les services peuvent tous disposer de comptes individuels ou
de comptes partagés. Les comptes peuvent être membres de groupes et se voir
attribuer des droits et des autorisations spécifiques. Les comptes peuvent être limités à
l’ordinateur local, au groupe de travail, au réseau ou à l’appartenance à un domaine.

Les comptes intégrés et les groupes de sécurité, dont ils sont membres, sont définis sur
chaque version de Windows. En utilisant des groupes de sécurité, vous pouvez attribuer
les mêmes autorisations de sécurité à de nombreux utilisateurs qui sont correctement
authentifiés, ce qui simplifie l’administration de l’accès. Les règles de délivrance des
passeports peuvent exiger que le voyageur soit classé dans certains groupes, tels que
professionnel, touristique ou gouvernemental. Ce processus garantit des autorisations
de sécurité cohérentes pour tous les membres d'un groupe. L’utilisation de groupes de
sécurité pour attribuer des autorisations signifie que le contrôle d’accès des ressources
reste constant et facile à gérer et à auditer. En ajoutant et en supprimant les utilisateurs
qui ont besoin d'accéder aux groupes de sécurité appropriés, vous pouvez réduire la
fréquence des modifications apportées aux listes de contrôle d'accès (ACL).

Les comptes de service managés autonomes et les comptes virtuels ont été introduits
dans Windows Server 2008 R2 et Windows 7 pour fournir aux applications nécessaires,
telles que Microsoft Exchange Server et Internet Information Services (IIS), l'isolation de
leurs propres comptes de domaine, tout en éliminant la nécessité pour un
administrateur de gérer manuellement le nom de principal de service (SPN) et les
informations d'identification pour ces comptes. Les comptes de service managé de
groupe ont été introduits dans Windows Server 2012 et fournissent la même
fonctionnalité au sein du domaine, mais étend également cette fonctionnalité sur
plusieurs serveurs. Lors de la connexion à un service hébergé sur une batterie de
serveurs, tel que le service Équilibrage de la charge réseau, les protocoles
d’authentification prenant en charge l’authentification mutuelle exigent que toutes les
instances des services utilisent le même principal.

Pour plus d'informations sur les comptes, voir :

Comptes Active Directory

Groupes de sécurité Active Directory

Comptes locaux

Comptes Microsoft

Comptes de service
 Identités spéciales

Authentification déléguée
Pour reprendre l'analogie avec les voyages, les pays pourraient accorder le même accès
à tous les membres d'une délégation gouvernementale officielle, à condition que les
délégués soient bien connus. Cette délégation permet à un membre d'agir sous
l'autorité d'un autre membre. Dans Windows, l'authentification déléguée se produit
lorsqu'un service réseau accepte une demande d'authentification de la part d'un
utilisateur et assume l'identité de cet utilisateur afin d'établir une nouvelle connexion
avec un second service réseau. Pour prendre en charge l'authentification déléguée, vous
devez établir des serveurs frontaux ou de premier niveau, tels que les serveurs web, qui
sont chargés de traiter les demandes d'authentification des clients, et des serveurs back-
end ou n-tiers, tels que les grandes bases de données, qui sont chargés de stocker les
informations. Vous pouvez déléguer le droit de configurer l'authentification déléguée à
des utilisateurs de votre organisation afin de réduire la charge administrative de vos
administrateurs.

En établissant un service ou un ordinateur comme fiable pour la délégation, vous

permettez à ce service ou à cet ordinateur d'effectuer l'authentification déléguée, de
recevoir un ticket pour l'utilisateur qui fait la demande, puis d'accéder aux informations
pour cet utilisateur. Ce modèle limite l’accès aux données sur les serveurs principaux
uniquement à ceux qui présentent des informations d’identification avec les jetons de
contrôle d’accès corrects. En outre, il permet de réaliser des audits d'accès à ces
ressources back-end. En exigeant que toutes les données soient accessibles au moyen
d'informations d'identification déléguées au serveur pour être utilisées au nom du client,
vous vous assurez que le serveur ne peut pas être compromis et que vous pouvez
accéder à des informations sensibles stockées sur d'autres serveurs. L'authentification
déléguée est utile pour les applications multi-niveaux qui sont conçues pour utiliser des
fonctionnalités d'authentification unique sur plusieurs ordinateurs.

Authentification dans les relations d’approbation entre

domaines
La plupart des organisations qui ont plusieurs domaines ont un besoin légitime pour les
utilisateurs d’accéder aux ressources partagées situées dans un autre domaine, tout
comme le voyageur est autorisé à voyager dans différentes régions du pays. Le contrôle
de cet accès nécessite que les utilisateurs d’un domaine puissent également être
authentifiés et autorisés à utiliser des ressources dans un autre domaine. Pour fournir
des capacités d'authentification et d'autorisation entre des clients et des serveurs dans
des domaines différents, il doit y avoir une approbation entre les deux domaines. Les
approbations sont la technologie sous-jacente par laquelle les communications Active
Directory sécurisées se produisent et constituent un composant de sécurité intégral de
l’architecture réseau Windows Server.

Lorsqu’une approbation existe entre deux domaines, les mécanismes d’authentification

pour chaque domaine approuvent les authentifications provenant de l’autre domaine.
Les approbations permettent de contrôler l'accès aux ressources partagées dans un
domaine de ressources (le domaine approbateur) en vérifiant que les demandes
d'authentification entrantes proviennent d'une autorité de confiance (le domaine
approuvé). De cette façon, les approbations agissent comme des ponts qui permettent
uniquement aux demandes d’authentification validées de se déplacer entre les
domaines.

La façon dont une approbation passe les demandes d’authentification dépend de la

façon dont elle est configurée. Les relations d’approbation peuvent être
unidirectionnelles, en fournissant l’accès à partir du domaine approuvé aux ressources
du domaine d’approbation, ou bidirectionnelle, en fournissant l’accès de chaque
domaine aux ressources de l’autre domaine. Les approbations sont également soit non-
transitives, auquel cas l'approbation n'existe qu'entre les deux domaines des partenaires
de l'approbation, soit transitives, auquel cas l'approbation s'étend automatiquement à
tous les autres domaines auxquels l'un ou l'autre des partenaires accorde son
approbation.

Pour plus d’informations sur le fonctionnement d’une approbation, consultez l’article

Fonctionnement des approbations de domaine et de forêt.

Transition de protocole
La transition de protocole aide les concepteurs d'applications en leur permettant de
prendre en charge différents mécanismes d'authentification au niveau de
l'authentification de l'utilisateur et en passant au protocole Kerberos pour les fonctions
de sécurité, telles que l'authentification mutuelle et la délégation contrainte, dans les
niveaux d'application suivants.

Pour plus d’informations sur la transition de protocole, consultez l’article Transition du

protocole Kerberos et délégation contrainte.

Délégation contrainte
La délégation contrainte permet aux administrateurs de spécifier et de faire respecter les
limites de confiance des applications en limitant le champ d'action des services
d'application au nom d'un utilisateur. Vous pouvez spécifier des services particuliers à
partir desquels un ordinateur approuvé pour la délégation peut demander des
ressources. La flexibilité de limiter les droits d’autorisation pour les services permet
d’améliorer la conception de la sécurité des applications en réduisant les opportunités
de compromission par les services non approuvés.

Pour plus d'informations sur la délégation contrainte, consultez l’article Vue d'ensemble
de la délégation contrainte de Kerberos.

Références supplémentaires
Vue d'ensemble technique de la connexion et de l'authentification Windows

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Scénarios d’ouverture de session
Windows
Article • 24/09/2024

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cette rubrique de référence pour le professionnel de l’informatique récapitule les

scénarios courants d’ouverture de session et de connexion Windows.

Les systèmes d’exploitation Windows exigent que tous les utilisateurs se connectent à
l’ordinateur avec un compte valide pour accéder aux ressources locales et réseau. Les
ordinateurs Windows sécurisent les ressources en implémentant le processus
d’ouverture de session, dans lequel les utilisateurs sont authentifiés. Après avoir
authentifié un utilisateur, les technologies d’autorisation et de contrôle d’accès mettent
en œuvre la deuxième phase de protection des ressources, qui consiste à vérifier si cet
utilisateur authentifié a les autorisations suffisantes pour accéder à une ressource.

Cette rubrique s’applique aux versions des systèmes d’exploitation Windows figurant
dans la liste S’applique à présente au début de cette page.

En outre, les applications et les services peuvent exiger que les utilisateurs se connectent
pour accéder aux ressources proposées par l’application ou le service. Le processus de
connexion est similaire au processus d’ouverture de session, car un compte valide et des
informations d’identification correctes sont nécessaires, mais les informations
d’ouverture de session sont stockées dans la base de données du Gestionnaire de
comptes de sécurité (SAM) sur l’ordinateur local et dans Active Directory, le cas échéant.
Le compte de connexion et les informations d’identification sont gérés par l’application
ou le service et peuvent éventuellement être stockés localement dans Credential Locker.

Pour comprendre le fonctionnement de l’authentification, consultez Concepts

d’authentification Windows.

Cette rubrique explique les scénarios suivants :

Ouverture de session interactive

Ouverture de session réseau

Ouverture de session par carte à puce

Ouverture de session biométrique

 Ｕ Attention

Lorsque l’utilisateur effectue une connexion locale, ses informations d’identification

sont vérifiées localement par rapport à une copie mise en cache avant d’être
authentifiées avec un fournisseur d’identité via le réseau. Si la vérification du cache
est réussie, l’utilisateur accède au bureau même si l’appareil est hors ligne.
Cependant, si l’utilisateur modifie son mot de passe dans le cloud, le vérificateur
mis en cache n’est pas mis à jour, ce qui signifie qu’il peut toujours accéder à sa
machine locale en utilisant son ancien mot de passe.

Ouverture de session interactive

Le processus d’ouverture de session commence soit lorsqu’un utilisateur entre des
informations d’identification dans la boîte de dialogue d’entrée d’informations
d’identification, soit quand l’utilisateur insère une carte à puce dans le lecteur de carte à
puce, soit quand l’utilisateur interagit avec un appareil biométrique. Les utilisateurs
peuvent effectuer une ouverture de session interactive à l’aide d’un compte utilisateur
local ou d’un compte de domaine pour se connecter à un ordinateur.

Le diagramme suivant montre les éléments d’ouverture de session interactifs et le

processus d’ouverture de session.
Architecture d’authentification du client Windows

Ouverture de session locale et au domaine

Les informations d’identification que l’utilisateur présente pour une ouverture de session
de domaine contiennent tous les éléments nécessaires pour une ouverture de session
locale, tels que le nom de compte et le mot de passe ou le certificat, et les informations
de domaine Active Directory. Le processus confirme l’identification de l’utilisateur à la
base de données de sécurité sur l’ordinateur local de l’utilisateur ou dans un domaine
Active Directory. Ce processus d’ouverture de session obligatoire ne peut pas être
désactivé pour les utilisateurs d’un domaine.

Les utilisateurs peuvent effectuer une ouverture de session interactive à un ordinateur

de deux manières :
 Localement, lorsque l’utilisateur dispose d’un accès physique direct à l’ordinateur,
ou lorsque l’ordinateur fait partie d’un réseau d’ordinateurs.

Une ouverture de session locale accorde à un utilisateur l’autorisation d’accéder

aux ressources Windows sur l’ordinateur local. Une ouverture de session locale
nécessite que l’utilisateur dispose d’un compte d’utilisateur dans le Gestionnaire
des comptes de sécurité (SAM) sur l’ordinateur local. SAM protège et gère les
informations d’utilisateur et de groupe sous la forme de comptes de sécurité
stockés dans le registre des ordinateurs locaux. L’ordinateur peut disposer d’un
accès réseau, mais ce n’est pas obligatoire. Les informations de compte
d’utilisateur local et d’appartenance au groupe sont utilisées pour gérer l’accès aux
ressources locales.

Une ouverture de session réseau accorde à un utilisateur l’autorisation d’accéder

aux ressources Windows sur l’ordinateur local en plus de toutes les ressources sur
les ordinateurs en réseau, telles que définies par le jeton d’accès des informations
d’identification. Une ouverture de session locale et en réseau nécessite que
l’utilisateur dispose d’un compte d’utilisateur dans le Gestionnaire des comptes de
sécurité (SAM) sur l’ordinateur local. Les informations de compte d’utilisateur local
et d’appartenance au groupe sont utilisées pour gérer l’accès aux ressources
locales, et le jeton d’accès de l’utilisateur définit les ressources accessibles sur les
ordinateurs en réseau.

Une ouverture de session locale et une ouverture de session réseau ne sont pas
suffisantes pour accorder à l’utilisateur et à l’ordinateur l’autorisation d’accéder et
d’utiliser des ressources de domaine.

À distance, par le biais des services Terminal Server ou des services Bureau à
distance (RDS), auquel cas l’ouverture de session est qualifiée d’interactive à
distance.

Après une ouverture de session interactive, Windows exécute des applications pour le
compte de l’utilisateur et l’utilisateur peut interagir avec ces applications.

Une ouverture de session locale accorde à un utilisateur l’autorisation d’accéder aux

ressources sur l’ordinateur local ou aux ressources sur les ordinateurs en réseau. Si
l’ordinateur est joint à un domaine, la fonctionnalité Winlogon tente de se connecter à
ce domaine.

Une ouverture de session de domaine accorde à un utilisateur l’autorisation d’accéder

aux ressources locales et de domaine. Une ouverture de session au domaine nécessite
que l’utilisateur dispose d’un compte d’utilisateur dans Active Directory. L’ordinateur
doit avoir un compte dans le domaine Active Directory et être physiquement connecté
au réseau. Les utilisateurs doivent également disposer des droits d’utilisateur
nécessaires pour se connecter à un ordinateur local ou à un domaine. Les informations
de compte d’utilisateur de domaine et les informations d’appartenance aux groupes
sont utilisées pour gérer l’accès aux ressources de domaine et locales.

Ouverture de session à distance

Dans Windows, l’accès à un autre ordinateur par le biais d’une ouverture de session à
distance s’appuie sur le protocole RDP (Remote Desktop Protocol). Étant donné que
l’utilisateur doit déjà s’être connecté à l’ordinateur client avant d’essayer une connexion
à distance, les processus d’ouverture de session interactifs se sont terminés avec succès.

RDP gère les informations d’identification que l’utilisateur entre à l’aide du client Bureau
à distance. Ces informations d’identification sont destinées à l’ordinateur cible et
l’utilisateur doit disposer d’un compte sur cet ordinateur cible. En outre, l’ordinateur
cible doit être configuré pour accepter une connexion à distance. Les informations
d’identification de l’ordinateur cible sont envoyées pour tenter d’effectuer le processus
d’authentification. Si l’authentification réussit, l’utilisateur est connecté aux ressources
locales et réseau accessibles à l’aide des informations d’identification fournies.

Ouverture de session réseau

Une ouverture de session réseau ne peut être utilisée qu’après l’authentification de
l’utilisateur, du service ou de l’ordinateur. Pendant l’ouverture de session réseau, le
processus n’utilise pas les boîtes de dialogue d’entrée d’informations d’identification
pour collecter des données. Au lieu de cela, des informations d’identification
précédemment établies ou une autre méthode de collecte d’informations
d’identification sont utilisées. Ce processus confirme l’identité de l’utilisateur auprès de
n’importe quel service réseau auquel l’utilisateur tente d’accéder. Ce processus est
généralement invisible pour l’utilisateur, sauf si d’autres informations d’identification
doivent être fournies.

Pour fournir ce type d’authentification, le système de sécurité inclut les mécanismes

d’authentification suivants :

Protocole Kerberos version 5

Certificats à clé publique

Secure Sockets Layer/Transport Layer Security (SSL/TLS)

Digest
 NTLM, pour la compatibilité avec les systèmes Basés sur Microsoft Windows NT 4.0

Pour plus d’informations sur les éléments et les processus, consultez le diagramme
d’ouverture de session interactif ci-dessus.

Ouverture de session par carte à puce

Les cartes à puce permettent de se connecter aux comptes de domaine uniquement et
non aux comptes locaux. L’authentification par carte à puce nécessite l’utilisation du
protocole d’authentification Kerberos. Introduite dans Windows 2000 Server, dans les
systèmes d’exploitation Windows, une extension de clé publique à la demande
d’authentification initiale du protocole Kerberos est implémentée. Contrairement au
chiffrement à clé secrète partagée, le chiffrement à clé publique est asymétrique, c’est-
à-dire que deux clés différentes sont nécessaires : l’une pour chiffrer, l’autre pour
déchiffrer. Ensemble, les clés requises pour effectuer les deux opérations constituent
une paire de clés privée/publique.

Pour lancer une session d’ouverture de session classique, un utilisateur doit prouver son
identité en fournissant des informations connues uniquement de l’utilisateur et de
l’infrastructure de protocole Kerberos sous-jacente. Les informations secrètes sont une
clé de chiffrement partagée dérivée du mot de passe de l’utilisateur. Une clé secrète
partagée est symétrique, ce qui signifie que la même clé est utilisée à la fois pour le
chiffrement et le déchiffrement.

Le diagramme suivant montre les éléments et les processus requis pour l’ouverture de
session par carte à puce.
Architecture du fournisseur d’informations d’identification par carte à puce

Lorsqu’une carte à puce est utilisée au lieu d’un mot de passe, une paire de clés
privée/publique stockée sur la carte à puce de l’utilisateur est remplacée pour la clé
secrète partagée qui est dérivée du mot de passe de l’utilisateur. La clé privée est
stockée uniquement sur la carte à puce. La clé publique peut être mise à la disposition
de toute personne avec laquelle le propriétaire souhaite échanger des informations
confidentielles.

Pour plus d’informations sur le processus d’ouverture de session par carte à puce dans
Windows, consultez Fonctionnement de la connexion par carte à puce dans Windows.

Ouverture de session biométrique

Un appareil est utilisé pour capturer et créer une caractéristique numérique d’un
artefact, comme une empreinte digitale. Cette représentation numérique est ensuite
comparée à un exemple du même artefact et, lorsque les deux sont correctement
comparés, l’authentification peut se produire. Les ordinateurs exécutant l’un des
systèmes d’exploitation désignés dans la liste S’applique à au début de cette rubrique
peuvent être configurés pour accepter cette forme d’ouverture de session. Toutefois, si
l’ouverture de session biométrique est configurée uniquement pour l’ouverture de
session locale, l’utilisateur doit présenter des informations d’identification de domaine
lors de l’accès à un domaine Active Directory.

Ressources supplémentaires
Pour plus d’informations sur la façon dont Windows gère les informations
d’identification envoyées pendant le processus d’ouverture de session, consultez
Gestion des informations d’identification dans l’authentification Windows.

Vue d’ensemble technique de l’authentification Windows

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Architecture d’authentification Windows
Article • 05/10/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cette rubrique de présentation destinée aux professionnels de l’informatique explique le

schéma architectural de base pour Authentification Windows.

L’authentification est le processus par lequel le système valide les informations

d’ouverture de session ou de connexion d’un utilisateur. Le nom et le mot de passe d’un
utilisateur sont comparés à une liste autorisée, et si le système détecte une
correspondance, l’accès est accordé dans la mesure spécifiée dans la liste d’autorisations
pour cet utilisateur.

Dans le cadre d’une architecture extensible, les systèmes d’exploitation Windows Server
implémentent un ensemble par défaut de fournisseurs de prise en charge de la sécurité
de l’authentification, notamment Negotiate, le protocole Kerberos, NTLM, Schannel
(canal sécurisé) et Digest. Les protocoles utilisés par ces fournisseurs permettent
l’authentification des utilisateurs, des ordinateurs et des services ; le processus
d’authentification permet à son tour aux utilisateurs et services autorisés d’accéder aux
ressources de façon sécurisée.

Dans Windows Server, les applications authentifient les utilisateurs à l’aide de SSPI pour
extraire les appels d’authentification. Par conséquent, les développeurs n’ont pas besoin
de comprendre les complexités de protocoles d’authentification spécifiques ou de créer
des protocoles d’authentification dans leurs applications.

Les systèmes d’exploitation Windows Server incluent un ensemble de composants de

sécurité qui composent le modèle de sécurité Windows. Ces composants garantissent
que les applications ne peuvent pas accéder aux ressources sans authentification et
autorisation. Les sections suivantes décrivent les éléments de l’architecture
d’authentification.

Autorité de sécurité locale

L’autorité de sécurité locale (LSA) est un sous-système protégé qui authentifie et
connecte les utilisateurs à l’ordinateur local. En outre, LSA conserve des informations sur
tous les aspects de la sécurité locale sur un ordinateur (ces aspects sont collectivement
appelés stratégie de sécurité locale). Il fournit également différents services de
traduction entre les noms et les identificateurs de sécurité (SID).
Le sous-système de sécurité effectue le suivi des stratégies de sécurité et des comptes
qui se trouvent sur un système informatique. Dans le cas d’un contrôleur de domaine,
ces stratégies et comptes sont ceux qui sont en vigueur pour le domaine dans lequel se
trouve le contrôleur de domaine. Ces stratégies et comptes sont stockés dans Active
Directory. Le sous-système LSA fournit des services de validation d’accès aux objets, de
vérification des droits utilisateurs et de génération de messages d’audit.

interface du fournisseur de la prise en charge de la

sécurité (Security Support Provider Interface ou SSPI)
L’interface SSPI (Security Support Provider Interface) est l’API qui obtient des services de
sécurité intégrés pour l’authentification, l’intégrité des messages, la confidentialité des
messages et la qualité de service de sécurité pour tout protocole d’application distribué.

L’interface SSPI correspond à l’implémentation de l’API de service de sécurité générique

(GSSAPI). SSPI fournit un mécanisme par lequel une application distribuée peut appeler
l’un des différents fournisseurs de sécurité pour obtenir une connexion authentifiée sans
connaître les détails du protocole de sécurité.

Références supplémentaires
Architecture de l’interface du fournisseur SSP (Security Support Provider)

Processus des informations d’identification dans l’authentification Windows

Vue d’ensemble technique de l’authentification Windows

Architecture de l’interface du
fournisseur SSP (Security Support
Provider)
Article • 05/10/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cette rubrique de référence destinée aux professionnels de l’informatique décrit les

protocoles d’authentification Windows utilisés dans le cadre de l’architecture SSPI
(Security Support Provider Interface).

L’interface SSPI (Security Support Provider Interface) de Microsoft constitue la base de

l’authentification Windows. Les applications et services d’infrastructure qui requièrent
une authentification utilisent l’interface SSPI pour la fournir.

L’interface SSPI correspond à l’implémentation de l’API de service de sécurité générique

(GSSAPI) dans les systèmes d’exploitation Windows Server. Pour plus d’informations sur
GSSAPI, consultez les documents RFC 2743 et RFC 2744 dans la base de données RFC de
l’IETF.

Les fournisseurs SSP (Security Support Providers) par défaut qui appellent des
protocoles d’authentification spécifiques dans Windows sont incorporés dans le SSPI en
tant que DLL. Ces fournisseurs SSP par défaut sont décrits dans les sections suivantes.
D’autres fournisseurs SSP peuvent être incorporés s’ils peuvent fonctionner avec la SSPI.

Comme illustré dans l’image suivante, l’interface SSPI dans Windows fournit un
mécanisme qui transporte des jetons d’authentification sur le canal de communication
existant entre l’ordinateur client et le serveur. Lorsque deux ordinateurs ou
périphériques doivent être authentifiés afin de pouvoir communiquer en toute sécurité,
les demandes d’authentification sont acheminées vers l’interface SSPI, qui achève le
processus d’authentification, quel que soit le protocole réseau en cours d’utilisation.
L’interface SSPI renvoie des objets binaires volumineux transparents. Ceux-ci sont
transmis entre les applications, à ce moment-là, ils peuvent être transmis à la couche
SSPI. Ainsi, l’interface SSPI permet à une application d’utiliser différents modèles de
sécurité disponibles sur un ordinateur ou réseau sans modifier l’interface du système de
sécurité.
Les sections suivantes décrivent les fournisseurs SSP par défaut qui interagissent avec
l’interface SSPI. Les fournisseurs SSP sont utilisés de différentes manières dans les
systèmes d’exploitation Windows pour promouvoir une communication sécurisée dans
un environnement réseau non sécurisé.

Fournisseur SSP (Security Support Provider) Kerberos

Fournisseur SSP (Security Support Provider) NTLM

Fournisseur SSP (Security Support Provider) Digest

Fournisseur SSP (Security Support Provider) Schannel

Fournisseur SSP (Security Support Provider) Negotiate

Protocole CredSSP (Credential Security Support Provider)

Fournisseur SSP (Security Support Provider) des extensions Negotiate

Fournisseur SSP (Security Support Provider) PKU2U

Également inclus dans cette rubrique :

Sélection du fournisseur SSP (Security Support Provider)

Fournisseur SSP (Security Support Provider) Kerberos
Ce fournisseur SSP utilise uniquement le protocole Kerberos version 5 implémenté par
Microsoft. Ce protocole est basé sur la RFC 4120 du Groupe de travail du réseau et sur
les ébauches de révisions. Il s’agit d’un protocole standard du secteur qui est utilisé avec
un mot de passe ou une carte à puce pour une ouverture de session interactive. Il s’agit
également de la méthode d’authentification préférée des services dans Windows.

Étant donné que le protocole Kerberos est le protocole d’authentification par défaut
depuis Windows 2000, tous les services de domaine prennent en charge le fournisseur
SSP Kerberos. Ces services comprennent :

Requêtes Active Directory qui utilisent le protocole LDAP

Gestion de serveur ou de station de travail distants utilisant le service d’appel de

procédure distante

Services d’impression

Authentification client-serveur

Accès aux fichiers distants utilisant le protocole SMB (également appelé Common
Internet File System ou CIFS)

Gestion et référence du système de fichiers distribués

Authentification intranet auprès d’Internet Information Services (IIS)

Authentification de l’autorité de sécurité pour la sécurité du protocole Internet

(IPsec)

Demandes de certificat adressées aux services de certificats Active Directory pour

les utilisateurs et les ordinateurs du domaine

Location: %Windir%\System32\[Link]

Ce fournisseur est inclus par défaut dans les versions désignées dans la liste S’applique
à au début de cette rubrique, ainsi que Windows Server 2003 et Windows XP.

Ressources supplémentaires pour le protocole Kerberos et le fournisseur SSP

Kerberos

Microsoft Kerberos (Windows)

[MS-KILE] : extensions du protocole Kerberos

 [MS-SFU] : extensions du protocole Kerberos : spécification du protocole de service
pour l’utilisateur et de délégation contrainte

SSP/AP Kerberos (Windows)

Améliorations Kerberos pour Windows Vista

Modifications apportées à l’authentification Kerberos pour Windows 7

Référence technique de l’authentification Kerberos

Fournisseur SSP (Security Support Provider) NTLM

Le fournisseur SSP NTLM est un protocole de messagerie binaire utilisé par l’interface
SSPI pour permettre l’authentification de la demande-réponse NTLM et pour négocier
des options d’intégrité et de confidentialité. NTLM est utilisé partout où
l’authentification SSPI est utilisée, notamment pour l’authentification du protocole SMB
ou CIFS, l’authentification HTTP Negotiate (par exemple, l’authentification Web Internet)
et le service d’appel de procédure distante. Le fournisseur SSP NTLM inclut les
protocoles d’authentification NTLM et NTLM version 2 (NTLMv2).

Les systèmes d’exploitation Windows pris en charge peuvent utiliser le fournisseur SSP
NTLM pour les éléments suivants :

Authentification client/serveur

Services d’impression

Accès aux fichiers à l’aide de CIFS (SMB)

Service d’appel de procédure distante sécurisée ou service DCOM

Location: %Windir%\System32\msv1_0.dll

Ce fournisseur est inclus par défaut dans les versions désignées dans la liste S’applique
à au début de cette rubrique, ainsi que Windows Server 2003 et Windows XP.

Ressources supplémentaires pour le protocole NTLM et le fournisseur SSP NTLM

Package d’authentification MSV1_0 (Windows)

Modifications apportées à l’authentification NTLM dans Windows 7

Microsoft NTLM (Windows)

Guide relatif à l’audit et à la restriction de l’utilisation du protocole NTLM

Fournisseur SSP (Security Support Provider) Digest
L’authentification Digest est une norme du secteur utilisée pour le protocole LDAP et
l’authentification web. L’authentification Digest transmet les informations
d’identification sur le réseau sous forme de hachage MD5 ou de synthèse de message.

Le fournisseur SSP Digest ([Link]) est utilisé pour les éléments suivants :

Accès Internet Explorer et Internet Information Services (IIS)

Requêtes LDAP

Location: %Windir%\System32\[Link]

Ce fournisseur est inclus par défaut dans les versions désignées dans la liste S’applique
à au début de cette rubrique, ainsi que Windows Server 2003 et Windows XP.

Ressources supplémentaires pour le protocole Digest et le fournisseur SSP Digest

Authentification Microsoft Digest (Windows)

[MS-DPSP] : Extensions du protocole Digest

Fournisseur SSP (Security Support Provider) Schannel

Le canal sécurisé (Schannel) est utilisé pour l’authentification de serveur web, par
exemple, lorsqu’un utilisateur tente d’accéder à un serveur web sécurisé.

Les protocoles TLS, SSL, PCT (Technologie des communications privées) et DTLS
(Protocole de la couche de transport de datagrammes) sont basés sur le chiffrement à
clé publique. Schannel fournit tous ces protocoles. Tous les protocoles Schannel utilisent
un modèle client/serveur. Le SSP Schannel utilise des certificats de clé publique pour
authentifier les tiers. Lors de l’authentification des parties, le fournisseur SSP Schannel
sélectionne un protocole selon l’ordre de préférence suivant :

Protocole TLS (Transport Layer Security) version 1.0

Protocole TLS (Transport Layer Security) version 1.1

Protocole TLS (Transport Layer Security) version 1.2

SSL (Secure Socket Layer) version 2.0

SSL (Secure Socket Layer) version 3.0

Technologie des communications privées (PCT)

 Note La PCT est désactivée par défaut.

Le protocole sélectionné est le protocole d’authentification préféré que le client et le

serveur peuvent prendre en charge. Par exemple, si un serveur prend en charge tous les
protocoles Schannel et que le client prend uniquement en charge SSL 3.0 et SSL 2.0, le
processus d’authentification utilise SSL 3.0.

Le protocole DTLS est utilisé quand l’application l’appelle explicitement. Pour plus
d’informations sur DTLS et les autres protocoles utilisés par le fournisseur Schannel,
consultez Référence technique du fournisseur de support de sécurité Schannel.

Emplacement : %Windir%\System32\[Link]

Ce fournisseur est inclus par défaut dans les versions désignées dans la liste S’applique
à au début de cette rubrique, ainsi que Windows Server 2003 et Windows XP.

７ Notes

Le protocole TLS 1.2 a été introduit dans ce fournisseur dans Windows Server 2008
R2 et Windows 7. Le protocole DTLS a été introduit dans ce fournisseur dans
Windows Server 2012 et Windows 8.

Ressources supplémentaires pour les protocoles TLS et SSL et le fournisseur SSP

Schannel

Canal sécurisé (Windows)

Référence technique de TLS/SSL

[MS-TLSP] : Profil TLS (Transport Layer Security)

Fournisseur SSP (Security Support Provider) Negotiate

Le mécanisme de négociation DSGS-API simple et protégé (SPNEGO) constitue la base
du SSP Negotiate, qui peut être utilisé pour négocier un protocole d’authentification
spécifique. Lorsqu'une application appelle un SSPI à se connecter à un réseau, il peut
spécifier un SSP pour traiter la demande. Si l’application spécifie le fournisseur SSP
Negotiate, elle analyse la demande et choisit le fournisseur approprié pour gérer la
demande, en fonction des stratégies de sécurité configurées par client.

Le mécanisme SPNEGO est spécifié dans RFC 2478.

Dans les versions prises en charge des systèmes d’exploitation Windows, le fournisseur
SSP Negotiate sélectionne entre le protocole Kerberos et NTLM. Negotiate sélectionne
le protocole Kerberos par défaut, sauf si celui-ci ne peut pas être utilisé par l’un des
systèmes impliqués dans l’authentification ou que l’application appelante n’a pas fourni
des informations suffisantes pour utiliser le protocole Kerberos.

Location: %Windir%\System32\[Link]

Ce fournisseur est inclus par défaut dans les versions désignées dans la liste S’applique
à au début de cette rubrique, ainsi que Windows Server 2003 et Windows XP.

Ressources supplémentaires pour le SSP Negotiate

Microsoft Negotiate (Windows)

[MS-SPNG] : extensions du mécanisme de négociation GSS-API simple et protégé

(SPNEGO)

[MS-N2HT] : spécification du protocole d’authentification HTTP Negotiate et

Nego2

Protocole CredSSP (Credential Security Support Provider)

Le fournisseur CredSSP (Credential Security Service Provider) fournit une expérience
utilisateur d’authentification unique (SSO) lors du démarrage de nouvelles sessions des
Services Terminal Server et des Services Bureau à distance. CredSSP permet aux
applications de déléguer les informations d’identification des utilisateurs de l’ordinateur
client (à l’aide du fournisseur SSP côté client) au serveur cible (via le fournisseur SSP côté
serveur), en fonction des stratégies du client. Les stratégies CredSSP sont configurées à
l’aide d’une stratégie de groupe, et la délégation des informations d’identification est
désactivée par défaut.

Location: %Windir%\System32\[Link]

Ce fournisseur est inclus par défaut dans les versions désignées dans la liste S’applique
à au début de cette rubrique.

Ressources supplémentaires pour le fournisseur SSP d’informations d’identification

[MS-CSSP] : spécification du protocole CredSSP (Credential Security Support

Provider)

Fournisseur SSP des informations d’identification et d’authentification unique pour

l’ouverture de session des services Terminal Server

Fournisseur SSP des extensions Negotiate

Negotiate Extensions (NegoExts) est un package d’authentification qui négocie
l’utilisation des SSP, autres que NTLM ou le protocole Kerberos, pour les applications et
les scénarios implémentés par Microsoft et d’autres éditeurs de logiciels.

Cette extension au package Negotiate favorise les scénarios suivants :

Disponibilité de clients riches au sein d’un système fédéré. Les documents sont
accessibles sur des sites SharePoint et peuvent être modifiés à l’aide d’une
application Microsoft Office complète.

Prise en charge des clients riches pour les services Microsoft Office. Les
utilisateurs peuvent se connecter aux services Microsoft Office et utiliser une
application Microsoft Office complète.

Microsoft Exchange Server et Outlook hébergés. Aucune approbation de

domaine n’est établie, car Exchange Server est hébergé sur le web. Outlook utilise
le service Windows Live pour authentifier les utilisateurs.

Disponibilité de clients riches entre les ordinateurs clients et les serveurs. Les
composants de mise en réseau et d’authentification du système d’exploitation sont
utilisés.

Le package Windows Negotiate traite le fournisseur SSP NegoExts de la même manière

que Kerberos et NTLM. [Link] est chargé dans l’autorité système locale (LSA) au
démarrage. Lorsqu’une demande d’authentification est reçue, NegoExts négocie entre
les fournisseurs SSP pris en charge en fonction de la source de la demande. Il collecte
les informations d’identification et les stratégies, les chiffre et envoie ces informations au
fournisseur dSSP, où le jeton de sécurité est créé.

Les SSP pris en charge par NegoExts ne sont pas des SSP autonomes tels que Kerberos
et NTLM. Par conséquent, dans le fournisseur SSP NegoExts, lorsque la méthode
d’authentification échoue pour une raison quelconque, un message d’échec
d’authentification s’affiche ou est journalisé. Aucune méthode d’authentification de
renégociation ou de secours n’est possible.

Location: %Windir%\System32\[Link]

Ce fournisseur est inclus par défaut dans les versions désignées dans la liste S’applique
à au début de cette rubrique, sauf en ce qui concerne Windows Server 2008 et
Windows XP.

Fournisseur SSP (Security Support Provider) PKU2U

Le protocole PKU2U a été introduit et implémenté en tant que fournisseur SSP dans
Windows 7 et Windows Server 2008 R2. Ce fournisseur SSP permet l’authentification de
pair à pair, en particulier par le biais de la fonctionnalité de partage de fichiers et de
médias appelée Groupement résidentiel, qui a été introduite dans Windows 7. Cette
fonctionnalité permet les partages entre des ordinateurs qui ne sont pas membres d’un
domaine.

Location: %Windir%\System32\[Link]

Ce fournisseur est inclus par défaut dans les versions désignées dans la liste S’applique
à au début de cette rubrique, sauf en ce qui concerne Windows Server 2008 et
Windows XP.

Ressources supplémentaires pour le protocole PKU2U et le fournisseur SSP PKU2U

Présentation de l’intégration des identités en ligne

Sélection du fournisseur SSP (Security Support

Provider)
La SSPI Windows peut utiliser n’importe quel protocole pris en charge par le biais des
fournisseurs SSP installés. Toutefois, étant donné que tous les systèmes d’exploitation ne
prennent pas en charge les mêmes packages SSP que n’importe quel ordinateur
exécutant Windows Server, les clients et les serveurs doivent négocier pour utiliser un
protocole pris en charge par les deux parties. Windows Server préfère que les
ordinateurs clients et les applications utilisent le protocole Kerberos, un protocole fort
basé sur des normes, lorsque cela est possible, mais le système d’exploitation continue
d’autoriser l’authentification des ordinateurs clients et les applications clientes qui ne
prennent pas en charge le protocole Kerberos.

Avant que l’authentification puisse avoir lieu, les deux ordinateurs qui communiquent
doivent convenir d’un protocole qu’ils peuvent tous les deux prendre en charge. Pour
que n’importe quel protocole soit utilisable via l’interface SSPI, chaque ordinateur doit
disposer du fournisseur SSP approprié. Par exemple, pour qu’un ordinateur client et un
serveur utilisent le protocole d’authentification Kerberos, ils doivent tous deux prendre
en charge Kerberos v5. Windows Server utilise la fonction EnumerateSecurityPackages
pour identifier les fournisseurs SSP pris en charge sur un ordinateur et leurs
fonctionnalités.

La sélection d’un protocole d’authentification peut être gérée de l’une des deux
manières suivantes :
 1. Protocole d’authentification unique

2. Option de négociation

Protocole d’authentification unique

Lorsqu’un seul protocole acceptable est spécifié sur le serveur, l’ordinateur client doit
prendre en charge le protocole spécifié ou la communication échoue. Lorsqu’un seul
protocole acceptable est spécifié, l’échange d’authentification s’effectue comme suit :

1. L’ordinateur client demande l’accès à un service.

2. Le serveur répond à la demande et spécifie le protocole qui sera utilisé.

3. L’ordinateur client examine le contenu de la réponse et vérifie s’il prend en charge

le protocole spécifié. Si l’ordinateur client prend en charge le protocole spécifié,
l’authentification continue. Si l’ordinateur client ne prend pas en charge le
protocole, l’authentification échoue, que l’ordinateur client soit autorisé ou non à
accéder à la ressource.

Option de négociation
L’option de négociation peut être utilisée pour permettre au client et au serveur de
tenter de trouver un protocole acceptable. Elle est basée sur le mécanisme de
négociation GSS-API simple et protégé (SPNEGO). Lorsque l’authentification commence
par l’option de négociation d’un protocole d’authentification, l’échange SPNEGO
s’effectue comme suit :

1. L’ordinateur client demande l’accès à un service.

2. Le serveur répond par une liste de protocoles d’authentification qu’il peut prendre
en charge et un test d’authentification ou une réponse, en fonction du protocole
qui constitue son premier choix. Par exemple, le serveur peut répertorier le
protocole Kerberos et NTLM, et envoyer une réponse d’authentification Kerberos.

3. L’ordinateur client examine le contenu de la réponse et vérifie s’il prend en charge

les protocoles spécifiés.

Si l’ordinateur client prend en charge le protocole préféré, l’authentification

continue.

Si l’ordinateur client ne prend pas en charge le protocole préféré, mais qu’il

prend en charge l’un des autres protocoles répertoriés par le serveur,
 l’ordinateur client indique au serveur quel protocole d’authentification il
prend en charge et l’authentification continue.

Si l’ordinateur client ne prend en charge aucun des protocoles répertoriés,

l’échange d’authentification échoue.

Références supplémentaires
Architecture d’authentification Windows
Processus des informations
d’identification dans l’authentification
Windows
Article • 13/09/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cette rubrique de référence pour les professionnels de l’informatique décrit comment

Authentification Windows traite les informations d’identification.

La gestion des informations d’identification Windows est le processus par lequel le

système d’exploitation reçoit les informations d’identification du service ou de
l’utilisateur et sécurise ces informations pour une présentation ultérieure à la cible
d’authentification. Dans le cas d’un ordinateur joint à un domaine, la cible
d’authentification est le contrôleur de domaine. Les informations d’identification
utilisées dans l’authentification sont des documents numériques qui associent l’identité
de l’utilisateur à une forme de preuve d’authenticité, telle qu’un certificat, un mot de
passe ou un code confidentiel.

Par défaut, les informations d’identification Windows sont validées par rapport à la base
de données du Gestionnaire des comptes de sécurité (SAM) sur l’ordinateur local ou à
Active Directory sur un ordinateur joint à un domaine, via le service Winlogon. Les
informations d’identification sont collectées via une entrée utilisateur sur l’interface
utilisateur d’ouverture de session ou par programmation via l’interface de
programmation d’application (API) à présenter à la cible d’authentification.

Les informations de sécurité locales sont stockées dans le registre sous

HKEY_LOCAL_MACHINE\SECURITY. Les informations stockées incluent les paramètres
de stratégie, les valeurs de sécurité par défaut et les informations de compte, telles que
les informations d’identification d’ouverture de session mises en cache. Une copie de la
base de données SAM est également stockée ici, bien qu’elle soit protégée en écriture.

Le diagramme suivant montre les composants requis et les chemins d’accès que les
informations d’identification prennent via le système pour authentifier l’utilisateur ou le
processus pour une ouverture de session réussie.
Le tableau suivant décrit chaque composant qui gère les informations d’identification
dans le processus d’authentification au point d’ouverture de session.

Composants d’authentification pour tous les systèmes

Composant Description

Ouverture de [Link] est le fichier exécutable responsable de la gestion des

session de interactions utilisateur sécurisées. Le service Winlogon lance le processus
l’utilisateur d’ouverture de session pour les systèmes d’exploitation Windows en
transmettant les informations d’identification collectées par l’action de
l’utilisateur sur le bureau sécurisé (interface utilisateur d’ouverture de session)
à l’autorité de sécurité locale (LSA) via [Link].

Ouverture de Ouvertures de session d’application ou de service qui ne nécessitent pas

session d’ouverture de session interactive. La plupart des processus lancés par
d’application l’utilisateur s’exécutent en mode utilisateur à l’aide de [Link] tandis que
 Composant Description

les processus lancés au démarrage, tels que les services, s’exécutent en mode
noyau à l’aide de [Link].
Pour plus d’informations sur le mode utilisateur et le mode noyau, consultez
Applications et Mode utilisateur ou Services et Mode noyau dans cette
rubrique.

[Link] Les fournisseurs d’authentification multiples qui constituent la base du

processus d’authentification.

[Link] Le processus LSASS applique les stratégies de sécurité et agit comme le

Gestionnaire de package de sécurité pour l’autorité de sécurité locale. Le LSA
contient la fonction Negotiate, qui sélectionne le protocole NTLM ou Kerberos
après avoir déterminé quel protocole doit réussir.

Fournisseurs de Ensemble de fournisseurs qui peuvent appeler individuellement un ou

support de plusieurs protocoles d’authentification. L’ensemble de fournisseurs par défaut
sécurité peut changer avec chaque version du système d’exploitation Windows, et les
fournisseurs personnalisés peuvent être écrits.

[Link] Les services que le service Net Logon effectue sont les suivants :
- Maintient le canal sécurisé de l’ordinateur (à ne pas confondre avec Schannel)
vers un contrôleur de domaine.
- Transmet les informations d’identification de l’utilisateur via un canal sécurisé
au contrôleur de domaine et retourne les identificateurs de sécurité de
domaine (SID) et les droits utilisateur pour l’utilisateur.
- Publie des enregistrements de ressources de service dans le système DNS
(Domain Name System) et utilise DNS pour résoudre les noms des adresses IP
(Internet Protocol) des contrôleurs de domaine.
- Implémente le protocole de réplication basé sur l’appel de procédure
distante (RPC) pour la synchronisation des contrôleurs de domaine principaux
(PDC) et des contrôleurs de domaine de sauvegarde (BDC).

[Link] Le Gestionnaire des comptes de sécurité (SAM), qui stocke les comptes de
sécurité locaux, applique des stratégies stockées localement et prend en
charge les API.

Registre Le Registre contient une copie de la base de données SAM, des paramètres de
stratégie de sécurité locale, des valeurs de sécurité par défaut et des
informations de compte accessibles uniquement au système.

Cette rubrique contient les sections suivantes :

Entrée d’informations d’identification pour l’ouverture de session de l’utilisateur

Entrée d’informations d’identification pour l’ouverture de session d’application et

de service

Autorité de sécurité locale

 Validation et informations d’identification mises en cache

Stockage et validation des informations d’identification

Base de données SAM (du Gestionnaire des comptes de sécurité)

Domaines locaux et domaines approuvés

Certificats dans Authentification Windows

Entrée d’informations d’identification pour

l’ouverture de session de l’utilisateur
Dans Windows Server 2008 et Windows Vista, l’architecture GINA (Graphical
Identification and Authentication) a été remplacée par un modèle de fournisseur
d’informations d’identification, ce qui a permis d’énumérer différents types d’ouverture
de session à l’aide de vignettes d’ouverture de session. Les deux modèles sont décrits ci-
dessous.

Architecture graphique d’identification et d’authentification

L’architecture d’identification graphique et d’authentification (GINA) s’applique aux

systèmes d’exploitation Windows Server 2003, Microsoft Windows 2000 Server,
Windows XP et Windows 2000 Professionnel. Dans ces systèmes, chaque session
d’ouverture de session interactive crée une instance distincte du service Winlogon.
L’architecture GINA est chargée dans l’espace de processus utilisé par Winlogon, reçoit
et traite les informations d’identification et effectue les appels aux interfaces
d’authentification via LSALogonUser.

Les instances de Winlogon pour une ouverture de session interactive s’exécutent dans la
session 0. La session 0 héberge les services système et d’autres processus critiques, y
compris le processus de l’autorité de sécurité locale (LSA).

Le diagramme suivant montre le processus d’informations d’identification pour

Windows Server 2003, Microsoft Windows 2000 Server, Windows XP et Microsoft
Windows 2000 Professionnel.
Architecture du fournisseur d'informations d'identification

L’architecture du fournisseur d’informations d’identification s’applique aux versions

désignées dans la liste S’applique à au début de cette rubrique. Dans ces systèmes,
l’architecture d’entrée des informations d’identification est passée à une conception
extensible à l’aide de fournisseurs d’informations d’identification. Ces fournisseurs sont
représentés par les différentes vignettes d’ouverture de session sur le bureau sécurisé
qui autorisent un nombre quelconque de scénarios d’ouverture de session : différents
comptes pour le même utilisateur et différentes méthodes d’authentification, telles que
le mot de passe, la carte à puce et la biométrie.

Avec l’architecture du fournisseur d’informations d’identification, Winlogon démarre

toujours l’interface utilisateur d’ouverture de session après avoir reçu un événement de
séquence d’attention sécurisée. L’interface utilisateur d’ouverture de session interroge
chaque fournisseur d’informations d’identification pour connaître le nombre de types
d’informations d’identification différents que le fournisseur est configuré pour
énumérer. Les fournisseurs d’informations d’identification ont la possibilité de spécifier
l’une de ces vignettes comme vignette par défaut. Une fois que tous les fournisseurs ont
énuméré leurs vignettes, l’interface utilisateur d’ouverture de session les affiche à
l’utilisateur. L’utilisateur interagit avec une vignette pour fournir ses informations
d’identification. L’interface utilisateur d’ouverture de session envoie ces informations
d’identification pour l’authentification.
Les fournisseurs d’informations d’identification ne sont pas des mécanismes
d’application. Ils sont utilisés pour collecter et sérialiser des informations d’identification.
L’autorité de sécurité locale et les packages d’authentification appliquent la sécurité.

Les fournisseurs d’informations d’identification sont inscrits sur l’ordinateur et sont

responsables des éléments suivants :

Description des informations d’identification requises pour l’authentification.

Gestion de la communication et de la logique avec les autorités d’authentification

externes.

Empaquetage des informations d’identification pour l’ouverture de session

interactive et réseau.

L’empaquetage des informations d’identification pour l’ouverture de session interactive

et réseau inclut le processus de sérialisation. En sérialisant les informations
d’identification, plusieurs vignettes d’ouverture de session peuvent être affichées dans
l’interface utilisateur d’ouverture de session. Par conséquent, votre organisation peut
contrôler l’affichage de l’ouverture de session, par exemple les utilisateurs, les systèmes
cibles pour l’ouverture de session, l’accès préalable au réseau et les stratégies de
verrouillage/déverrouillage de station de travail, à l’aide de fournisseurs d’informations
d’identification personnalisés. Plusieurs fournisseurs d’informations d’identification
peuvent coexister sur le même ordinateur.

Les fournisseurs d’authentification unique (SSO) peuvent être développés en tant que
fournisseur d’informations d’identification standard ou en tant que fournisseur d’accès
pré-ouverture de session.

Chaque version de Windows contient un fournisseur d’informations d’identification par

défaut et un fournisseur d’accès pré-ouverture de session (Pre-Logon-Access Provider),
également appelé fournisseur d’authentification unique. Le fournisseur
d’authentification unique permet aux utilisateurs d’établir une connexion à un réseau
avant de se connecter à l’ordinateur local. Lorsque ce fournisseur est implémenté, le
fournisseur n’énumère pas les vignettes dans l’interface utilisateur d’ouverture de
session.

Un fournisseur d’authentification unique est destiné à être utilisé dans les scénarios
suivants :

L’authentification réseau et l’ouverture de session de l’ordinateur sont gérées par

différents fournisseurs d’informations d’identification. Les variantes de ce
scénario sont les suivantes :
 Un utilisateur a la possibilité de se connecter à un réseau, par exemple à un
réseau privé virtuel (VPN), avant de se connecter à l’ordinateur, mais il n’est pas
obligatoire d’établir cette connexion.

L’authentification réseau est nécessaire pour récupérer les informations utilisées

lors de l’authentification interactive sur l’ordinateur local.

Plusieurs authentifications réseau sont suivies de l’un des autres scénarios. Par
exemple, un utilisateur s’authentifie auprès d’un fournisseur de services Internet
(ISP), s’authentifie auprès d’un VPN, puis utilise ses informations d’identification
de compte d’utilisateur pour se connecter localement.

Les informations d’identification mises en cache sont désactivées et une

connexion aux services d’accès à distance via VPN est requise avant l’ouverture
de session locale pour authentifier l’utilisateur.

Un utilisateur de domaine n’a pas de compte local configuré sur un ordinateur

joint à un domaine et doit établir une connexion aux services d’accès à distance
via une connexion VPN avant de terminer l’ouverture de session interactive.

L’authentification réseau et l’ouverture de session de l’ordinateur sont gérées par

différents fournisseurs d’informations d’identification. Dans ce scénario,
l’utilisateur doit se connecter au réseau avant de se connecter à l’ordinateur.

Énumération de vignettes d’ouverture de session

Le fournisseur d’informations d’identification énumère les vignettes d’ouverture de

session dans les instances suivantes :

Pour les systèmes d’exploitation répertoriés dans la liste S’applique à figurant au

début de cette rubrique.

Le fournisseur d’informations d’identification énumère les vignettes pour

l’ouverture de session de station de travail. Le fournisseur d’informations
d’identification sérialise généralement les informations d’identification pour
l’authentification auprès de l’autorité de sécurité locale. Ce processus affiche des
vignettes spécifiques à chaque utilisateur et spécifiques aux systèmes cibles de
chaque utilisateur.

L’architecture d’ouverture de session et d’authentification permet à un utilisateur

d’utiliser des vignettes énumérées par le fournisseur d’informations d’identification
pour déverrouiller une station de travail. En règle générale, l’utilisateur
actuellement connecté est la vignette par défaut, mais si plusieurs utilisateurs sont
connectés, de nombreuses vignettes s’affichent.
 Le fournisseur d’informations d’identification énumère les vignettes en réponse à
une demande d’utilisateur de modifier son mot de passe ou d’autres informations
privées, telles qu’un code confidentiel. En règle générale, l’utilisateur actuellement
connecté est la vignette par défaut ; cependant si plusieurs utilisateurs sont
connectés, de nombreuses vignettes s’affichent.

Le fournisseur d’informations d’identification énumère les vignettes en fonction

des informations d’identification sérialisées à utiliser pour l’authentification sur les
ordinateurs distants. L’interface utilisateur des informations d’identification n’utilise
pas la même instance du fournisseur que l’interface utilisateur d’ouverture de
session, déverrouiller la station de travail ou modifier le mot de passe. Par
conséquent, les informations d’état ne peuvent pas être conservées dans le
fournisseur entre les instances de l’interface utilisateur des informations
d’identification. Cette structure génère une vignette pour chaque ouverture de
session d’ordinateur distant, en supposant que les informations d’identification ont
été correctement sérialisées. Ce scénario est également utilisé dans le contrôle de
compte d’utilisateur (UAC), qui peut aider à empêcher les modifications non
autorisées d’un ordinateur en invitant l’utilisateur à fournir une autorisation ou un
mot de passe administrateur avant d’autoriser des actions susceptibles d’affecter le
fonctionnement de l’ordinateur ou de modifier les paramètres qui affectent
d’autres utilisateurs de l’ordinateur.

Le diagramme suivant montre le processus d’informations d’identification pour les

systèmes d’exploitation désignés dans la liste S’applique à au début de cette rubrique.
Entrée d’informations d’identification pour
l’ouverture de session d’application et de
service
Authentification Windows est conçu pour gérer les informations d’identification pour les
applications ou les services qui ne nécessitent pas d’interaction utilisateur. Les
applications en mode utilisateur sont limitées en termes de ressources système
auxquelles elles ont accès, tandis que les services peuvent avoir un accès illimité à la
mémoire système et aux appareils externes.

Les services système et les applications au niveau du transport accèdent à un

fournisseur de support de sécurité (SSP) via l’interface SSPI (Security Support Provider
Interface) dans Windows, qui fournit des fonctions permettant d’énumérer les packages
de sécurité disponibles sur un système, de sélectionner un package et d’utiliser ce
package pour obtenir une connexion authentifiée.
Lorsqu’une connexion client/serveur est authentifiée :

L’application côté client de la connexion envoie des informations d’identification

au serveur à l’aide de la fonction SSPI InitializeSecurityContext (General) .

L’application côté serveur de la connexion répond avec la fonction

SSPI AcceptSecurityContext (General) .

Les fonctions SSPI InitializeSecurityContext (General) et AcceptSecurityContext

(General) sont répétées jusqu’à ce que tous les messages d’authentification

nécessaires aient été échangés pour réussir ou échouer l’authentification.

Une fois la connexion authentifiée, la LSA sur le serveur utilise les informations du
client pour générer le contexte de sécurité, qui contient un jeton d’accès.

Le serveur peut ensuite appeler la fonction SSPI ImpersonateSecurityContext pour

attacher le jeton d’accès à un thread d’emprunt d’identité pour le service.

Applications et mode utilisateur

Dans Windows, le mode utilisateur est composé de deux systèmes capables de

transmettre des demandes d’E/S aux pilotes appropriés en mode noyau : le système
d’environnement, qui exécute des applications écrites pour de nombreux types de
systèmes d’exploitation différents, et le système intégral, qui opère des fonctions
spécifiques au système pour le compte du système d’environnement.

Le système intégral gère les fonctions spécifiques du système d’exploitation pour le

compte du système d’environnement et se compose d’un processus de système de
sécurité (LSA), d’un service de station de travail et d’un service serveur. Le processus du
système de sécurité traite des jetons de sécurité, accorde ou refuse des autorisations
d’accès aux comptes d’utilisateur en fonction des autorisations de ressources, gère les
demandes d’ouverture de session et lance l’authentification d’ouverture de session, et
détermine les ressources système dont le système d’exploitation a besoin pour l’audit.

Les applications peuvent s’exécuter en mode utilisateur où l’application peut s’exécuter

en tant que n’importe quel principal, y compris dans le contexte de sécurité du système
local (SYSTEM). Les applications peuvent également s’exécuter en mode noyau, où
l’application peut s’exécuter dans le contexte de sécurité du système local (SYSTEM).

SSPI est disponible via le module [Link], qui est une API utilisée pour obtenir des
services de sécurité intégrés pour l’authentification, l’intégrité des messages et la
confidentialité des messages. Il fournit une couche d’abstraction entre les protocoles au
niveau de l’application et les protocoles de sécurité. Étant donné que les différentes
applications nécessitent différentes méthodes d’identification ou d’authentification des
utilisateurs et différentes façons de chiffrer les données à mesure qu’elles transitent sur
un réseau, SSPI offre un moyen d’accéder aux bibliothèques de liens dynamiques (DLL)
qui contiennent différentes fonctions d’authentification et de chiffrement. Ces DLL sont
appelées fournisseurs de support de sécurité (SSP).

Les comptes de service managés et les comptes virtuels ont été introduits dans
Windows Server 2008 R2 et Windows 7 pour fournir des applications cruciales, telles que
Microsoft SQL Server et Internet Information Services (IIS), avec l’isolation de leurs
propres comptes de domaine, tout en éliminant la nécessité pour un administrateur
d’administrer manuellement le nom du principal du service (SPN) et les informations
d’identification de ces comptes. Pour plus d’informations sur ces fonctionnalités et leur
rôle dans l’authentification, consultez La documentation des comptes de service gérés
pour Windows 7 et Windows Server 2008 R2 et Vue d’ensemble des comptes de service
gérés de groupe.

Services et mode noyau

Même si la plupart des applications Windows s’exécutent dans le contexte de sécurité

de l’utilisateur qui les démarre, cela n’est pas vrai pour les services. De nombreux
services Windows, tels que les services réseau et d’impression, sont démarrés par le
contrôleur de service lorsque l’utilisateur démarre l’ordinateur. Ces services peuvent
s’exécuter en tant que service local ou système local et peuvent continuer à s’exécuter
après la connexion du dernier utilisateur humain.

７ Notes

Les services s’exécutent normalement dans des contextes de sécurité appelés

Système local (SYSTEM), Service réseau ou Service local. Windows Server 2008 R2 a
introduit des services qui s’exécutent sous un compte de service géré, qui sont des
principaux de domaine.

Avant de démarrer un service, le contrôleur de service se connecte à l’aide du compte

désigné pour le service, puis présente les informations d’identification du service pour
l’authentification par l’agent LSA. Le service Windows implémente une interface
programmatique que le gestionnaire du contrôleur de service peut utiliser pour
contrôler le service. Un service Windows peut être démarré automatiquement au
démarrage du système ou manuellement avec un programme de contrôle de service.
Par exemple, lorsqu’un ordinateur client Windows joint un domaine, le service
messenger sur l’ordinateur se connecte à un contrôleur de domaine et lui ouvre un
canal sécurisé. Pour obtenir une connexion authentifiée, le service doit avoir des
informations d’identification approuvées par l’autorité de sécurité locale (LSA) de
l’ordinateur distant. Lors de la communication avec d’autres ordinateurs du réseau, LSA
utilise les informations d’identification pour le compte de domaine de l’ordinateur local,
comme tous les autres services exécutés dans le contexte de sécurité du système local
et du service réseau. Les services sur l’ordinateur local s’exécutent en tant que SYSTEM.
Les informations d’identification n’ont donc pas besoin d’être présentées à LSA.

Le fichier [Link] gère et chiffre ces informations d’identification et utilise un appel

de procédure locale dans la LSA. Le type de fichier est DRV (pilote) et est connu sous le
nom de fournisseur de support de sécurité (SSP) en mode noyau et, dans les versions
désignées dans la liste S’applique à au début de cette rubrique, est conforme à FIPS
140-2 niveau 1.

Le mode noyau a un accès complet aux ressources matérielles et système de

l’ordinateur. Le mode noyau empêche les services et applications en mode utilisateur
d’accéder aux zones critiques du système d’exploitation auxquelles ils ne doivent pas
avoir accès.

Autorité de sécurité locale

L’autorité de sécurité locale (LSA) est un sous-système protégé qui authentifie et
connecte les utilisateurs à l’ordinateur local. En outre, LSA conserve des informations sur
tous les aspects de la sécurité locale sur un ordinateur (ces aspects sont collectivement
appelés stratégie de sécurité locale) et fournit différents services de traduction entre les
noms et les identificateurs de sécurité (SID). Le processus du système de sécurité, le
service LSASS (Local Security Authority Server Service), effectue le suivi des stratégies de
sécurité et des comptes en vigueur sur un système informatique.

La LSA valide l’identité d’un utilisateur en fonction de laquelle des deux entités suivantes
a émis le compte de l’utilisateur :

Autorité de sécurité locale La LSA peut valider les informations utilisateur en

vérifiant la base de données du Gestionnaire des comptes de sécurité (SAM) située
sur le même ordinateur. N’importe quelle station de travail ou serveur membre
peut stocker des comptes d’utilisateurs locaux et des informations sur les groupes
locaux. Toutefois, ces comptes peuvent être utilisés pour accéder uniquement à
cette station de travail ou ordinateur.

Autorité de sécurité pour le domaine local ou pour un domaine approuvé. LSA

contacte l’entité qui a émis le compte et demande la vérification que le compte est
valide et que la demande provient du titulaire du compte.
Le service LSASS (Local Security Authority Subsystem Service) stocke en mémoire les
informations d'identification pour le compte des utilisateurs avec les sessions Windows
actives. Ceci permet aux utilisateurs d'accéder de façon transparente aux ressources
réseau, tels qu'aux partages de fichiers, boîtes aux lettres Exchange Server et sites
SharePoint, sans qu'ils soient tenus d'entrer de nouveau leurs informations
d'identification pour chaque service distant.

Le service LSASS peut stocker les informations d'identification sous des formes
multiples, dont notamment :

Texte en clair chiffré réversible

Tickets Kerberos (tickets d’octroi de tickets (TTT), tickets de service)

Hachage NT

Hachage LM (LAN Manager)

Si l'utilisateur ouvre une session Windows à l'aide d'une carte à puce, le service LSASS
ne stocke pas de mot de passe en clair mais il stocke la valeur de hachage NT
correspondante pour le compte et le code confidentiel en texte en clair pour la carte à
puce. Si l'attribut de compte est activé pour une carte à puce requise pour une
ouverture de session interactive, une valeur de hachage NT aléatoire est générée
automatiquement pour le compte à la place du hachage de mot de passe d'origine. Le
hachage de mot de passe généré automatiquement quand l'attribut est défini ne
change pas.

Si un utilisateur ouvre une session Windows avec un mot de passe compatible avec les
hachages LM, cet authentificateur sera présent dans la mémoire.

Le stockage des informations d'identification en texte en clair dans la mémoire ne peut

pas être désactivé, même si les fournisseurs d'informations d'identification qui en ont
besoin sont désactivés.

Les informations d'identification stockées sont directement associées aux sessions

LSASS ouvertes depuis le dernier redémarrage et qui n'ont pas été fermées. Par
exemple, des sessions LSA sont créées avec des informations d'identification LSA
stockées lorsqu'un utilisateur effectue l'une des opérations suivantes :

Ouverture d'une session locale ou RDP sur l'ordinateur

Exécution d'une tâche en utilisant l'option RunAs

Exécution d'un service Windows actif sur l'ordinateur

 Exécution d'une tâche planifiée ou d'un traitement par lots planifié

Exécution d'une tâche sur l'ordinateur local à l'aide d'un outil d'administration à
distance

Dans certains cas, les secrets LSA, qui sont des éléments secrets de données accessibles
uniquement aux processus de compte SYSTÈME, sont stockés sur le disque dur. Certains
de ces secrets sont des informations d'identification qui doivent être conservées après le
redémarrage. Ils sont stockés sous forme chiffrée sur le lecteur de disque dur. Les
informations d'identification stockées en tant que secrets LSA peuvent inclure les
éléments suivants :

Mot de passe du compte de services de domaine Active Directory (AD DS) de

l’ordinateur

Mots de passe de compte utilisés pour les services Windows configurés sur
l'ordinateur

Mots de passe de compte utilisés pour les tâches planifiées configurées

Mots de passe de compte utilisés pour les sites web et les pools d'applications IIS

Mots de passe pour les comptes Microsoft

Introduit dans Windows 8.1, le système d’exploitation client offre une protection
supplémentaire pour l’autorité LSA pour empêcher une lecture de la mémoire et une
injection de code par des processus non protégés. Cette protection augmente la
sécurité des informations d’identification stockées et gérées par l’autorité LSA.

Pour plus d’informations sur ces protections supplémentaires, consultez Configuration

d’une protection LSA supplémentaire.

Validation et informations d’identification

mises en cache
Les mécanismes de validation s’appuient sur la présentation des informations
d’identification au moment de l’ouverture de session. Toutefois, lorsque l’ordinateur est
déconnecté d’un contrôleur de domaine et que l’utilisateur présente des informations
d’identification de domaine, Windows utilise le processus des informations
d’identification mises en cache dans le mécanisme de validation.

Chaque fois qu’un utilisateur se connecte à un domaine, Windows met en cache les
informations d’identification fournies et les stocke dans la ruche de sécurité dans le
registre du système d’exploitation.

Avec les informations d’identification mises en cache, l’utilisateur peut se connecter à un

membre de domaine sans être connecté à un contrôleur de domaine au sein de ce
domaine.

Stockage et validation des informations

d’identification
Il n’est pas toujours souhaitable d’utiliser un ensemble d’informations d’identification
pour accéder à différentes ressources. Par exemple, un administrateur peut souhaiter
utiliser des informations d’identification administratives plutôt que des informations
d’identification utilisateur lors de l’accès à un serveur distant. De même, si un utilisateur
accède à des ressources externes, telles qu’un compte bancaire, il ne peut utiliser que
des informations d’identification différentes de celles de son domaine. Les sections
suivantes décrivent les différences de gestion des informations d’identification entre les
versions actuelles des systèmes d’exploitation Windows et les systèmes d’exploitation
Windows Vista et Windows XP.

Processus d’informations d’identification d’ouverture de

session à distance
Le protocole RDP (Remote Desktop Protocol) gère les informations d’identification de
l’utilisateur qui se connecte à un ordinateur distant à l’aide du client Bureau à distance,
qui a été introduit dans Windows 8. Les informations d’identification en texte clair sont
envoyées à l’hôte cible où l’hôte tente d’effectuer le processus d’authentification et, en
cas de réussite, connecte l’utilisateur aux ressources autorisées. RDP ne stocke pas les
informations d’identification sur le client, mais les informations d’identification de
domaine de l’utilisateur sont stockées dans le LSASS.

Introduit dans Windows Server 2012 R2 et Windows 8.1, le mode Administration

restreint offre une sécurité supplémentaire aux scénarios d’ouverture de session à
distance. Ce mode du Bureau à distance oblige l’application cliente à effectuer une
demande d’ouverture de session réseau avec la fonction unidirectionnel NT (NTOWF) ou
à utiliser un ticket de service Kerberos lors de l’authentification auprès de l’hôte distant.
Une fois l’administrateur authentifié, il ne dispose pas des informations d’identification
de compte respectives dans LSASS, car elles n’ont pas été fournies à l’hôte distant. Au
lieu de cela, l’administrateur dispose des informations d’identification du compte
d’ordinateur pour la session. Les informations d’identification de l’administrateur ne sont
pas fournies à l’hôte distant. Les actions sont donc effectuées en tant que compte
d’ordinateur. Les ressources sont également limitées au compte d’ordinateur, et
l’administrateur ne peut pas accéder aux ressources avec son propre compte.

Processus d’informations d’identification de redémarrage

automatique
Lorsqu’un utilisateur se connecte sur un appareil Windows 8.1, l’autorité de sécurité
locale enregistre les informations d’identification de l’utilisateur dans une mémoire
chiffrée accessible uniquement par [Link]. Lorsque Windows Update lance un
redémarrage automatique sans présence de l’utilisateur, ces informations
d’identification sont utilisées pour configurer l’ouverture de session automatique pour
l’utilisateur.

Au redémarrage, l’utilisateur est automatiquement connecté via le mécanisme de

connexion automatique, puis l’ordinateur est également verrouillé pour protéger la
session de l’utilisateur. Le verrouillage est lancé par l’intermédiaire de Winlogon, tandis
que la gestion des informations d’identification est effectuée par l’autorité de sécurité
locale. Grâce à la connexion automatique et au verrouillage de l’utilisateur sur la
console, les applications d’écran de verrouillage de l’utilisateur sont redémarrées et
deviennent disponibles.

Pour plus d’informations sur ARSO, consultez Winlogon Automatic Restart Sign-On
(ARSO).

Noms d’utilisateur et mots de passe stockés dans

Windows Vista et Windows XP
Dans Windows Server 2008 , Windows Server 2003, Windows Vista et Windows XP, les
noms d’utilisateur et mots de passe stockés dans Panneau de configuration simplifient
la gestion et l’utilisation de plusieurs ensembles d’informations d’identification
d’ouverture de session, y compris les certificats X.509 utilisés avec les cartes à puce et
les informations d’identification Windows Live (désormais appelées compte Microsoft).
Les informations d’identification, qui font partie du profil de l’utilisateur, sont stockées
jusqu’à ce que vous en ayez besoin. Cette action peut augmenter la sécurité par
ressource en garantissant que si un mot de passe est compromis, il ne compromet pas
toute la sécurité.

Après qu’un utilisateur se connecte à des ressources protégées par mot de passe
supplémentaires et tente d’accéder à des ressources protégées par mot de passe
supplémentaires, telles qu’un partage sur un serveur, et si les informations
d’identification d’ouverture de session par défaut de l’utilisateur ne sont pas suffisantes
pour obtenir l’accès, les noms d’utilisateur et mots de passe stockés sont interrogés. Si
d’autres informations d’identification avec les informations d’ouverture de session
correctes ont été enregistrées dans noms d’utilisateur et mots de passe stockés, ces
informations d’identification sont utilisées pour obtenir l’accès. Sinon, l’utilisateur est
invité à fournir de nouvelles informations d’identification, qui peuvent ensuite être
enregistrées pour réutilisation, soit plus tard dans la session d’ouverture de session, soit
pendant une session ultérieure.

Les restrictions suivantes s’appliquent :

Si les noms d’utilisateur et mots de passe stockés contiennent des informations

d’identification non valides ou incorrectes pour une ressource spécifique, l’accès à
la ressource est refusé et la boîte de dialogue Noms d’utilisateur et mots de passe
stockés n’apparaît pas.

Les noms d’utilisateur et mots de passe stockés stockent les informations

d’identification uniquement pour l’authentification NTLM, le protocole Kerberos, le
compte Microsoft (anciennement Windows Live ID) et l’authentification SSL
(Secure Sockets Layer). Certaines versions d’Internet Explorer conservent leur
propre cache pour l’authentification de base.

Ces informations d’identification deviennent une partie chiffrée du profil local d’un
utilisateur dans le répertoire \Documents and Settings\Username\Application
Data\Microsoft\Credentials. Par conséquent, ces informations d’identification peuvent
être itinérantes avec l’utilisateur si la stratégie réseau de l’utilisateur prend en charge les
profils utilisateur itinérants. Toutefois, si l’utilisateur dispose de copies des noms
d’utilisateur et mots de passe stockés sur deux ordinateurs différents et modifie les
informations d’identification associées à la ressource sur l’un de ces ordinateurs, la
modification n’est pas propagée aux noms d’utilisateur et mots de passe stockés sur le
deuxième ordinateur.

Coffre Windows et Gestionnaire d’informations

d’identification
Le Gestionnaire d’informations d’identification a été introduit dans Windows Server
2008 R2 et Windows 7 en tant que fonctionnalité Panneau de configuration pour stocker
et gérer les noms d’utilisateur et les mots de passe. Le Gestionnaire d’informations
d’identification permet aux utilisateurs de stocker les informations d’identification
pertinentes pour d’autres systèmes et sites web dans le coffre Windows sécurisé.
Certaines versions d’Internet Explorer utilisent cette fonctionnalité pour l’authentification
auprès des sites web.
La gestion des informations d’identification à l’aide du Gestionnaire d’informations
d’identification est contrôlée par l’utilisateur sur l’ordinateur local. Les utilisateurs
peuvent enregistrer et stocker des informations d’identification à partir des navigateurs
et des applications Windows pris en charge de manière à ce qu’il leur soit plus simple de
se connecter à ces ressources. Les informations d’identification sont enregistrées dans
des dossiers chiffrés spéciaux sur l’ordinateur sous le profil de l’utilisateur. Les
applications qui prennent en charge cette fonctionnalité (via l’utilisation des API du
Gestionnaire d’informations d’identification), tels que les navigateurs Web et les
applications peuvent présenter des informations d’identification correctes à d’autres
ordinateurs et sites Web durant le processus de connexion.

Lorsqu’un site web, une application ou un autre ordinateur demande une

authentification via NTLM ou le protocole Kerberos, une boîte de dialogue s’affiche dans
laquelle vous activez la case à cocher Mettre à jour les informations d’identification par
défaut ou Enregistrer le mot de passe . Cette boîte de dialogue qui permet à un
utilisateur d’enregistrer les informations d’identification localement est générée par une
application qui prend en charge les API du Gestionnaire d’informations d’identification.
Si l’utilisateur active la case à cocher Enregistrer le mot de passe, le Gestionnaire
d’informations d’identification effectue le suivi de son nom d’utilisateur, de son mot de
passe et des informations associées pour le service d’authentification utilisé.

À l’utilisation suivante du service, le Gestionnaire d’informations d’identification fournit

automatiquement les informations d’identification qui se trouvent dans le coffre
Windows. Si ces informations sont refusées, l’utilisateur est invité à fournir les
informations d’accès correctes. Si l’accès est accordé avec ces nouvelles informations
d’identification, le Gestionnaire d’informations d’identification remplace les informations
précédentes par les plus récentes, puis les enregistre dans le coffre Windows.

Base de données SAM (du Gestionnaire des

comptes de sécurité)
Le Gestionnaire des comptes de sécurité (SAM) est une base de données qui stocke les
groupes et les comptes d’utilisateurs locaux. Il est présent dans chaque système
d’exploitation Windows ; Toutefois, lorsqu’un ordinateur est joint à un domaine, Active
Directory gère les comptes de domaine dans les domaines Active Directory.

Par exemple, les ordinateurs clients exécutant un système d’exploitation Windows

participent à un domaine réseau en communiquant avec un contrôleur de domaine
même quand aucun utilisateur humain n’est connecté. Pour lancer des communications,
l’ordinateur doit avoir un compte actif dans le domaine. Avant d’accepter les
communications en provenance de l’ordinateur, l’autorité de sécurité locale sur le
contrôleur de domaine authentifie l’identité de l’ordinateur, puis définit le contexte de
sécurité de l’ordinateur comme elle le ferait pour le principal de sécurité d’un utilisateur.
Ce contexte de sécurité définit l’identité et les fonctionnalités d’un utilisateur ou d’un
service sur un ordinateur particulier, ou d’un utilisateur, service, groupe ou ordinateur
sur un réseau. Par exemple, le jeton d’accès contenu dans le contexte de sécurité définit
les ressources (telles qu’un partage de fichiers ou une imprimante) accessibles et les
actions (telles que lecture, écriture ou modification) qui peuvent être effectuées par ce
principal (un utilisateur, un ordinateur ou un service sur cette ressource).

Le contexte de sécurité d’un utilisateur ou d’un ordinateur peut varier d’un ordinateur à
l’autre, par exemple lorsqu’un utilisateur s’authentifie auprès d’un serveur ou d’une
station de travail autre que sa station de travail principale. Il peut également varier d’une
session à l’autre, par exemple lorsqu’un administrateur modifie les droits et autorisations
de l’utilisateur. En outre, le contexte de sécurité est généralement différent lorsqu’un
utilisateur ou un ordinateur fonctionne de manière autonome, dans un réseau ou dans
le cadre d’un domaine Active Directory.

Domaines locaux et domaines approuvés

Lorsqu’une approbation existe entre deux domaines, les mécanismes d’authentification
de chaque domaine reposent sur la validité des authentifications provenant de l’autre
domaine. Les approbations permettent d’obtenir un accès contrôlé aux ressources
partagées dans un domaine de ressources (le domaine approbateur) en vérifiant que les
demandes d’authentification entrantes proviennent d’une autorité approuvée (le
domaine approuvé). De cette façon, les approbations agissent comme des ponts qui
permettent uniquement aux demandes d’authentification validées de voyager entre les
domaines.

La façon dont une approbation passe les demandes d’authentification dépend de la

façon dont elle est configurée. Les relations d’approbation peuvent être
unidirectionnelles, en fournissant un accès à partir du domaine approuvé aux ressources
du domaine d’approbation, ou bidirectionnelle, en fournissant un accès à partir de
chaque domaine aux ressources de l’autre domaine. Les approbations sont également
soit nontransitives, auquel cas une approbation existe uniquement entre les deux
domaines partenaires d’approbation, soit transitives, auquel cas une approbation
s’étend automatiquement à tous les autres domaines auxquels l’un des partenaires fait
confiance.

Pour plus d’informations sur les relations d’approbation de domaine et de forêt

concernant l’authentification, consultez Authentification déléguée et relations
d’approbation.
Certificats dans Authentification Windows
Une infrastructure à clé publique (PKI) est une combinaison de logiciels, de technologies
de chiffrement, de processus et de services qui permet à une organisation de sécuriser
ses communications et ses transactions commerciales. La capacité d’une infrastructure à
clé publique à sécuriser les communications et les transactions commerciales est basée
sur l’échange de certificats numériques entre des utilisateurs authentifiés et des
ressources approuvées.

Un certificat numérique est un document électronique qui contient des informations sur
l’entité à laquelle il appartient, l’entité par laquelle il a été émis, un numéro de série
unique ou une autre identification unique, des dates d’émission et d’expiration, ainsi
qu’une empreinte digitale numérique.

L’authentification est le processus qui consiste à déterminer si un hôte distant peut être
approuvé. Pour établir sa fiabilité, l’hôte distant doit fournir un certificat
d’authentification acceptable.

Les hôtes distants établissent leur fiabilité en obtenant un certificat auprès d’une
autorité de certification. L’autorité de certification peut, à son tour, obtenir la
certification d’une autorité supérieure, ce qui crée une chaîne d’approbation. Pour
déterminer si un certificat est fiable, une application doit déterminer l’identité de
l’autorité de certification racine, puis déterminer si elle est fiable.

De même, l’hôte distant ou l’ordinateur local doit déterminer si le certificat présenté par
l’utilisateur ou l’application est authentique. L’authenticité du certificat présenté par
l’utilisateur via LSA et SSPI est évaluée sur l’ordinateur local pour l’ouverture de session
locale, sur le réseau ou sur le domaine via les magasins de certificats dans Active
Directory.

Pour produire un certificat, les données d’authentification passent par des algorithmes
de hachage, tels que SHA1 (Secure Hash Algorithm 1), pour produire une synthèse de
message. La synthèse de message est ensuite signée numériquement à l’aide de la clé
privée de l’expéditeur pour prouver que la synthèse de message a été produite par
l’expéditeur.

７ Notes

SHA1 est la valeur par défaut dans Windows 7 et Windows Vista, mais a été
remplacé par SHA2 dans Windows 8.

Authentification par carte à puce

La technologie de carte à puce est un exemple d’authentification par certificat. La
connexion à un réseau avec une carte à puce fournit une forme d’authentification forte,
car elle utilise une identification basée sur le chiffrement et une preuve de possession
lors de l’authentification d’un utilisateur auprès d’un domaine. Les services de certificats
Active Directory (AD CS) fournissent l’identification par chiffrement via l’émission d’un
certificat d’ouverture de session pour chaque carte à puce.

Pour plus d’informations sur l’authentification par carte à puce, consultez les
informations techniques de référence sur les cartes à puce Windows.

La technologie de carte à puce virtuelle a été introduite dans Windows 8. Elle stocke le
certificat de la carte à puce dans le PC, puis le protège à l’aide de la puce de sécurité du
module de plateforme sécurisée (TPM) de l’appareil. De cette façon, le PC devient en fait
la carte à puce qui doit recevoir le code confidentiel de l’utilisateur pour être authentifié.

Authentification à distance et sans fil

L’authentification réseau à distance et sans fil est une autre technologie qui utilise des
certificats pour l’authentification. Le service d’authentification Internet (IAS) et les
serveurs de réseau privé virtuel utilisent l’authentification extensible Protocol-Transport
niveau sécurité (EAP-TLS), le protocole PEAP (Protected Extensible Authentication
Protocol) ou la sécurité du protocole Internet (IPsec) pour effectuer l’authentification
basée sur les certificats pour de nombreux types d’accès réseau, y compris le réseau
privé virtuel (VPN) et les connexions sans fil.

Pour plus d’informations sur l’authentification basée sur les certificats dans le réseau,
consultez Authentification et certificats d’accès réseau.

Voir aussi
Concepts de l’authentification Windows
Paramètres de stratégie de groupe
utilisés dans l’authentification Windows
Article • 05/10/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cette rubrique de référence pour les professionnels de l’informatique décrit l’utilisation

et l’impact des paramètres de stratégie de groupe dans le processus d’authentification.

Vous pouvez gérer l’authentification dans les systèmes d’exploitation Windows en

ajoutant des comptes d’utilisateur, d’ordinateur et de service à des groupes, puis en
appliquant des stratégies d’authentification à ces groupes. Ces stratégies sont définies
en tant que stratégies de sécurité locales et en tant que modèles d’administration,
également appelés paramètres stratégie de groupe. Les deux ensembles peuvent être
configurés et distribués au sein de votre organisation à l’aide de stratégie de groupe.

７ Notes

Les fonctionnalités introduites dans Windows Server 2012 R2 vous permettent de

configurer des stratégies d’authentification pour des services ou applications ciblés,
communément appelés silos d’authentification, à l’aide de comptes protégés. Pour
plus d’informations sur la procédure à suivre dans Active Directory, consultez
Comment configurer des comptes protégés.

Par exemple, vous pouvez appliquer les stratégies suivantes aux groupes, en fonction de
leur fonction dans l’organisation :

Se connecter localement ou à un domaine

Se connecter sur un réseau

Réinitialiser des comptes

Création de comptes

Le tableau suivant répertorie les groupes de stratégies pertinents pour l’authentification

et fournit des liens vers la documentation qui peut vous aider à configurer ces
stratégies.
Stratégie de Emplacement Description
groupe

Stratégie de mot Stratégie de l’ordinateur local\ Les stratégies de mot de passe

de passe Configuration ordinateur\Paramètres affectent les caractéristiques et le
Windows\ Paramètres de comportement des mots de passe.
sécurité\Stratégies de compte Les stratégies de mot de passe
sont utilisées pour les comptes de
domaine ou les comptes
d’utilisateur locaux. Elles
déterminent les paramètres des
mots de passe, tels que
l’application et la durée de vie.
Pour plus d’informations sur des
paramètres spécifiques, consultez
Stratégie de mot de passe.

Stratégie de Stratégie de l’ordinateur local\ Les options de stratégie de

verrouillage de Configuration ordinateur\Paramètres verrouillage de compte
compte Windows\ Paramètres de désactivent les comptes après un
sécurité\Stratégies de compte nombre défini de tentatives
d’ouverture de session ayant
échoué. L’utilisation de ces
options peut vous aider à détecter
et à bloquer les tentatives
d’interruption des mots de passe.
Pour plus d’informations sur les
options de stratégie de
verrouillage de compte, consultez
Stratégie de verrouillage de
compte.

Stratégie Stratégie de l’ordinateur local\ Les paramètres liés à Kerberos

Kerberos Configuration ordinateur\Paramètres incluent la durée de vie du ticket
Windows\ Paramètres de et les règles d’application. La
sécurité\Stratégies de compte stratégie Kerberos ne s’applique
pas aux bases de données de
comptes locaux, car le protocole
d’authentification Kerberos n’est
pas utilisé pour authentifier les
comptes locaux. Par conséquent,
les paramètres de stratégie
Kerberos ne peuvent être
configurés qu’au moyen du
domaine d’objet de stratégie de
groupe (GPO) par défaut, où il
affecte les ouvertures de session
au domaine.
Pour plus d’informations sur les
options de stratégie Kerberos
Stratégie de Emplacement Description
groupe

pour le contrôleur de domaine,

consultez Stratégie Kerberos.

Stratégie d’audit Stratégie de l’ordinateur local\ La stratégie d’audit vous permet

Configuration ordinateur\Paramètres de contrôler et de comprendre
Windows\ Paramètres de l’accès aux objets, tels que les
sécurité\Stratégies locales\Stratégie fichiers et dossiers, et de gérer les
d’audit comptes d’utilisateur et de
groupe, ainsi que les ouvertures
de session et fermetures de
session d’utilisateurs. Les
stratégies d’audit peuvent
spécifier les catégories
d’événements que vous souhaitez
auditer, définir la taille et le
comportement du journal de
sécurité, et déterminer sur quels
objets vous souhaitez surveiller
l’accès et quel type d’accès vous
souhaitez surveiller.

Attribution des Stratégie d’ordinateur Les droits utilisateur sont

droits utilisateur local\Configuration généralement attribués sur la base
ordinateur\Paramètres des groupes de sécurité auxquels
Windows\Paramètres de appartient un utilisateur, tels que
sécurité\Stratégies locales\Attribution Administrateurs, Utilisateurs avec
des droits utilisateur pouvoir ou Utilisateurs. Les
paramètres de stratégie de cette
catégorie sont généralement
utilisés pour accorder ou refuser
l’autorisation d’accéder à un
ordinateur en fonction de la
méthode d’accès et des
appartenances aux groupes de
sécurité.

Options de Stratégie de l’ordinateur local\ Les stratégies pertinentes pour

sécurité Configuration ordinateur\Paramètres l’authentification sont les
Windows\ Paramètres de suivantes :
sécurité\Stratégies locales\Options de - Appareils
sécurité - Contrôleur de domaine
- Membre de domaine
- Ouverture de session interactive
- Serveur réseau Microsoft
- Accès réseau
- Sécurité réseau
Stratégie de Emplacement Description
groupe

- Console de récupération
- Arrêt

Délégation des Configuration ordinateur\Modèles La délégation des informations

informations d’administration\Système\Délégation d’identification est un mécanisme
d’identification d’identifiants qui permet d’utiliser des
informations d’identification
locales sur d’autres systèmes,
notamment sur les serveurs
membres et les contrôleurs de
domaine au sein d’un domaine.
Ces paramètres s’appliquent aux
applications à l’aide du
fournisseur de support de sécurité
des informations d’identification
(Cred SSP). La connexion Bureau à
distance en est un exemple.

Contrôleur de Configuration de l'ordinateur\Modèles Ces paramètres de stratégie

domaine d'administration\Système\KDC affectent la façon dont le centre
Kerberos (KDC) de distribution de clés (KDC), qui
est un service sur le contrôleur de
domaine, gère les demandes
d’authentification Kerberos.

Kerberos Configuration de l'ordinateur\Modèles Ces paramètres de stratégie

d'administration\Système\Kerberos affectent la façon dont Kerberos
est configuré pour gérer la prise
en charge des revendications, le
blindage Kerberos,
l’authentification composée,
l’identification des serveurs proxy
et d’autres configurations.

Ouverture de Configuration de l'ordinateur\Modèles Ces paramètres de stratégie

session d'administration\Système\Ouverture de contrôlent la façon dont le
session système présente l’expérience
d’ouverture de session aux
utilisateurs.

Net Logon Configuration de l'ordinateur\Modèles Ces paramètres de stratégie

d'administration\Système\Ouverture de contrôlent la façon dont le
session net système gère les demandes
d’ouverture de session réseau,
notamment le comportement du
localisateur de contrôleur de
domaine.
Stratégie de Emplacement Description
groupe

Pour plus d’informations sur la

façon dont le localisateur de
contrôleur de domaine s’intègre
aux processus de réplication,
consultez Présentation de la
réplication entre sites.

Biométrie Configuration de l'ordinateur\Modèles Ces paramètres de stratégie

d'administration\Composants autorisent généralement ou
Windows\Biométrie refusent l’utilisation de la
biométrie comme méthode
d’authentification.
Pour plus d’informations sur
l’implémentation Windows de la
biométrie, consultez Vue
d’ensemble de Windows
Biometric Framework.

Interface Configuration de l’ordinateur\Modèles Ces paramètres de stratégie

utilisateur des d’administration\Composants contrôlent la façon dont les
identifiants Windows\Interface utilisateur identifiants sont gérés au point
d’identification d’entrée.

Synchronisation Configuration ordinateur\Modèles Ces paramètres de stratégie

de mot de passe d’administration\Composants déterminent la façon dont le
Windows\Synchronisation de mot de système gère la synchronisation
passe des mots de passe entre les
systèmes d’exploitation Windows
et UNIX.
Pour plus d'informations,
consultez Synchronisation de mot
de passe.

Carte à puce Configuration de l'ordinateur\Modèles Ces paramètres de stratégie

d'administration\Composants contrôlent la façon dont le
Windows\Carte à puce système gère les ouvertures de
session de carte à puce.

Options Configuration de l’ordinateur\Modèles Ces paramètres de stratégie

d’ouverture de d’administration\Composants Windows\ contrôlent quand et comment les
session Options d’ouverture de session Windows opportunités d’ouverture de
Windows session sont disponibles.

Options Configuration de l’ordinateur\Modèles Ces paramètres de stratégie

Ctrl+Alt+Del d’administration\Composants Windows\ affectent l’apparence et
Options Ctrl+Alt+Del l’accessibilité des fonctionnalités
de l’interface utilisateur
d’ouverture de session (Secure
 Stratégie de Emplacement Description
groupe

Desktop), telles que le

Gestionnaire des tâches et le
verrou clavier de l’ordinateur.

Ouverture de Configuration de l'ordinateur\Modèles Ces paramètres de stratégie

session d'administration\Composants déterminent si ou quels processus
Windows\Ouverture de session peuvent s’exécuter lorsque
l’utilisateur se connecte.

Références supplémentaires
Vue d’ensemble technique de l’authentification Windows
Gestion et protection des informations
d’identification
Article • 11/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cette rubrique destinée aux professionnels de l'informatique traite des fonctionnalités et

des méthodes introduites dans Windows Server 2012 R2 et Windows 8.1 en matière de
protection des informations d'identification et de contrôle d'authentification de
domaine pour réduire le vol d'informations d'identification.

Mode d'administration restreinte pour la connexion

Bureau à distance
Le mode d'administration restreinte permet de se connecter de manière interactive à un
serveur hôte distant sans lui transmettre ses informations d'identification. Cela empêche
la collecte de vos informations d'identification durant le processus de connexion initial,
si la sécurité du serveur est compromise.

En utilisant ce mode avec des informations d'identification d'administrateur, le client

Bureau à distance tente de se connecter de manière interactive à un hôte qui prend
également ce mode en charge, sans envoyer d'informations d'identification. Quand
l'hôte vérifie que le compte d'utilisateur qui se connecte dispose de droits
d'administrateur et qu'il prend en charge le mode d'administration restreinte, la
connexion réussit. Sinon, la tentative de connexion échoue. À aucun moment, le mode
d'administration restreinte n'envoie d'informations d'identification en texte brut ou sous
une autre forme réutilisable aux ordinateurs distants.

Protection LSA
L'autorité de sécurité locale (LSA, Local Security Authority), qui est incluse dans le
processus LSASS (Local Security Authority Security Service), valide les utilisateurs pour
les connexions locales et à distance, et applique les stratégies de sécurité locales. Le
système d’exploitation de Windows 8.1 offre une protection supplémentaire pour
l’autorité LSA en empêchant l’injection de code par des processus non protégés. La
sécurité des informations d’identification stockées et gérées par l’autorité LSA est ainsi
renforcée. Ce paramètre de processus protégé pour LSA peut être configuré dans
Windows 8.1. Toutefois, il est activé par défaut dans Windows RT 8.1 et ne peut pas être
changé.

Pour plus d’informations sur la configuration de la protection LSA, consultez Configuring

Additional LSA Protection.

Groupe de sécurité Utilisateurs protégés

Ce nouveau groupe global de domaine déclenche une nouvelle protection non
configurable sur les appareils et ordinateurs hôtes qui exécutent Windows
Server 2012 R2 et Windows 8.1. Le groupe Utilisateurs protégés active des protections
supplémentaires pour les contrôleurs de domaine et les domaines dans Windows
Server 2012 R2. Cela réduit considérablement les types d'informations d'identification
disponibles quand les utilisateurs sont connectés aux ordinateurs du réseau à partir d'un
ordinateur non compromis.

En outre, les membres du groupe Utilisateurs protégés sont limités par les méthodes
d'authentification suivantes :

Un membre du groupe Utilisateurs protégés ne peut se connecter qu'à l'aide du

protocole Kerberos. Le compte ne peut pas s'authentifier à l'aide des protocoles
NTLM, Digest Authentication ou CredSSP. Sur un périphérique qui exécute
Windows 8.1, les mots de passe ne sont pas mis en cache et le périphérique qui
utilise l'un des fournisseurs SSP (Security Support Provider) ne peut donc pas
s'authentifier auprès d'un domaine quand le compte est membre du groupe
Utilisateurs protégés.

Le protocole Kerberos n'utilise pas les types de chiffrement DES et RC4 plus faibles
dans le processus de pré-authentification. Cela signifie que le domaine doit être
configuré pour prendre en charge au moins la suite de chiffrement AES.

Le compte de l'utilisateur ne peut pas être délégué via la délégation contrainte ou

non contrainte Kerberos. Cela signifie que les anciennes connexions aux autres
systèmes peuvent échouer si l'utilisateur est membre du groupe Utilisateurs
protégés.

Le paramètre de durée de vie TGT (Ticket Granting Ticket) Kerberos par défaut de
quatre heures est configurable à l'aide des silos et stratégies d'authentification,
accessibles via le Centre d'administration Active Directory. Cela signifie qu'après
quatre heures l'utilisateur doit s'authentifier de nouveau.

２ Avertissement
 Les comptes de services et d'ordinateurs ne doivent pas être membres du groupe
Utilisateurs protégés. Ce groupe n'offre pas de protection locale, car le mot de
passe ou le certificat est toujours disponible sur l'hôte. L’authentification échoue
avec l’erreur « Le nom d'utilisateur ou le mot de passe est incorrect » pour tout
service ou ordinateur ajouté au groupe Utilisateurs protégés.

Pour plus d'informations sur ce groupe, voir Groupe de sécurité Utilisateurs protégés.

Stratégie d'authentification et silos de stratégies

d'authentification
Les stratégies Active Directory basées sur une forêt sont introduites et peuvent être
appliquées aux comptes d'un domaine dont le niveau fonctionnel est Windows
Server 2012 R2. Ces stratégies d’authentification peuvent contrôler les hôtes dont peut
se servir un utilisateur pour se connecter. Elles fonctionnent en collaboration avec le
groupe de sécurité Utilisateurs protégés. En outre, les administrateurs peuvent appliquer
des conditions de contrôle d’accès pour l’authentification aux comptes. Ces stratégies
d'authentification isolent les comptes connexes pour limiter la portée d'un réseau.

La nouvelle classe d'objets Active Directory, Stratégie d'authentification, vous permet

d'appliquer une configuration d'authentification à des classes de compte dans les
domaines dont le niveau fonctionnel est Windows Server 2012 R2. Les stratégies
d'authentification sont appliquées pendant l'échange du service d'authentification (AS)
ou du service d'accord de tickets (TGS) Kerberos. Les classes de compte Active Directory
sont les suivantes :

Utilisateur

Computer

Compte de service administré

Compte de service administré de groupe

Pour plus d'informations, voir Stratégies d'authentification et silos de stratégies

d'authentification.

Pour plus d'informations sur la configuration des comptes protégés, voir Comment
configurer des comptes protégés.

Références supplémentaires
Pour plus d’informations sur l’autorité LSA et le processus LSASS, consultez la Vue
d’ensemble technique de l’authentification et de l’ouverture de session Windows.
Configurer une protection LSA renforcée
Article • 07/10/2023

Cet article explique comment configurer une protection renforcée pour le processus de
l’autorité de sécurité locale (LSA) afin d’empêcher toute injection de code qui pourrait
compromettre les informations d’identification.

L’autorité LSA, qui comprend le processus LSASS (Local Security Authority Server Service),
valide les utilisateurs pour les connexions locales et à distance, et applique les stratégies de
sécurité locales. À compter de Windows 8.1 et ultérieur, une protection renforcée pour
l’autorité LSA est fournie pour empêcher une lecture de la mémoire et une injection de code
par des processus non protégés. Cette fonctionnalité renforce la sécurité des informations
d’identification stockées et gérées par l’autorité LSA. Une plus grande protection est
appliquée lors de l’utilisation du verrou UEFI et du démarrage sécurisé, car la désactivation
de la clé de Registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa n’a
aucun effet.

Exigences spécifiques au processus protégé pour

les plug-ins ou pilotes
Pour qu’un plug-in ou pilote LSA soit correctement chargé en tant que processus protégé, il
doit répondre aux critères suivants :

Vérification de signature
Le mode protégé exige que tout plug-in chargé dans l’autorité LSA soit signé
numériquement avec une signature Microsoft. Tout plug-in sans signature ou non signé avec
une signature Microsoft ne pourra pas être chargé dans l’autorité LSA. Entre autres exemples
de plug-in, citons les pilotes de cartes à puce, les plug-ins de chiffrement et les filtres de
mots de passe.

Les plug-ins LSA qui sont des pilotes, tels que les pilotes de cartes à puce, doivent être
signés à l’aide de la certification WHQL. Pour plus d’informations, consultez Signature
de version WHQL.
Les plug-ins LSA sans processus de certification WHQL doivent être signés à l’aide du
service de signature de fichiers pour LSA.

Respect du guide de processus Microsoft Security

Development Lifecycle (SDL)
 Tous les plug-ins doivent être conformes au guide de processus SDL applicable. Pour
plus d’informations, consultez Microsoft Security Development Lifecycle (SDL) – Guide
de processus.
Même si les plug-ins sont correctement signés avec une signature Microsoft, la non-
conformité avec le processus SDL peut aboutir à l’échec du chargement d’un plug-in.

Pratiques recommandées
Utilisez la liste suivante pour vérifier soigneusement que la protection LSA est activée avant
de procéder à un vaste déploiement de la fonctionnalité :

Identifiez tous les plug-ins et pilotes LSA que votre organisation utilise. Incluez les
pilotes ou plug-ins non-Microsoft, tels que les pilotes de cartes à puce et les plug-ins
de chiffrement, ainsi que tout logiciel développé en interne qui est utilisé pour
appliquer des filtres de mots de passe ou des notifications de changement de mot de
passe.
Vérifiez que tous les plug-ins LSA sont signés numériquement avec un certificat
Microsoft pour éviter que leur chargement échoue sous la protection LSA.
Vérifiez que tous les plug-ins correctement signés peuvent être chargés dans l’autorité
LSA et qu’ils fonctionnent comme prévu.
Utilisez les journaux d’audit pour identifier les plug-ins et pilotes LSA dont l’exécution
en tant que processus protégé échoue.

Limitations de l’activation de la protection LSA

Si une protection LSA renforcée est activée, vous ne pouvez pas déboguer un plug-in LSA
personnalisé. Vous ne pouvez pas attacher un débogueur à LSASS quand il s’agit d’un
processus protégé. En général, il n’existe aucun moyen pris en charge pour déboguer un
processus protégé en cours d’exécution.

Auditer les plug-ins et les pilotes LSA qui ne

seront pas chargés en tant que processus
protégé
Avant d’activer la protection LSA, utilisez le mode audit pour identifier les plug-ins et pilotes
LSA dont le chargement échouera en mode protégé LSA. En mode audit, le système génère
des journaux des événements qui identifient tous les plug-ins et pilotes qui ne peuvent pas
être chargés sous LSA si la protection LSA est activée. Les messages sont journalisés sans
bloquer les plug-ins et les pilotes, en fait.

Les événements décrits dans cette section figurent dans l’observateur d’événements dans le
Journal des opérations sous Journaux des applications et des
services>Microsoft>Windows>CodeIntegrity. Ces événements peuvent vous aider à
identifier les plug-ins et pilotes LSA dont le chargement échoue pour des raisons de
signature. Pour gérer ces événements, vous pouvez utiliser l'outil en ligne de commande
wevtutil. Pour plus d'informations sur cet outil, voir Wevtutil.

） Important

Les événements d’audit ne sont pas générés si Smart App Control est activé sur un
appareil. Pour vérifier ou changer l’état d’activation de Smart App Control, ouvrez
l’application Sécurité Windows et accédez à la page Contrôle Applications et
navigateur . Sélectionnez Paramètres Smart App Control pour vérifier l’état d’activation
et définissez la configuration sur Désactivé si vous essayez d’auditer une protection LSA
renforcée.

７ Notes

Le mode audit pour une protection LSA renforcée est activé par défaut sur les appareils
exécutant Windows 11 version 22H2 et ultérieure. Si votre appareil exécute cette build
ou une version ultérieure, aucune autre action n’est nécessaire pour auditer la
protection LSA renforcée.

Activer le mode audit pour [Link] sur un seul

ordinateur
1. Ouvrez l’Éditeur du Registre ([Link]) et accédez à la clé de Registre sur
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image
File Execution Options\[Link].
2. Affectez la valeur AuditLevel=dword:00000008 à la clé de Registre.
3. Redémarrez l'ordinateur.

Après avoir effectué ces étapes, analysez les résultats de l’événement 3065 et de
l’événement 3066. Dans l’observateur d’événements, recherchez ces événements dans le
Journal des opérations sous Journaux des applications et des
services>Microsoft>Windows>CodeIntegrity.

L’événement 3065 signale qu’une vérification de l’intégrité du code a déterminé qu’un

processus, généralement [Link], a tenté de charger un pilote qui ne répondait pas
aux conditions requises en matière de sécurité pour les sections partagées. Toutefois,
en raison de la stratégie système actuellement définie, le chargement de l’image a été
autorisé.
L’événement 3066 signale qu’une vérification de l’intégrité du code a déterminé qu’un
processus, généralement [Link], a tenté de charger un pilote qui ne répondait pas
 aux conditions requises en matière de niveau de signature Microsoft. Toutefois, en
raison de la stratégie système actuellement définie, le chargement de l’image a été
autorisé.

Si un plug-in ou pilote contient des sections partagées, l’événement 3066 est consigné avec
l’événement 3065. La suppression des sections partagées doit empêcher les deux
événements de se produire, à moins que le plug-in ne respecte pas le niveau de signature
Microsoft requis.

） Important

Ces événements opérationnels ne sont pas générés lorsqu’un débogueur du noyau est
attaché et activé sur un système.

Activer le mode audit pour [Link] sur plusieurs

ordinateurs
Pour activer le mode audit pour plusieurs ordinateurs d’un domaine, vous pouvez utiliser
l’extension de Registre côté client pour la stratégie de groupe afin de déployer la valeur du
Registre de niveau d’audit [Link]. Vous devez modifier la clé de Registre
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File
Execution Options\[Link].

1. Ouvrez la Console de gestion des stratégies de groupe (GPMC) en entrant [Link]

dans la boîte de dialogue Exécuter ou en sélectionnant la Console de gestion des
stratégies de groupe à partir du menu Démarrer.
2. Créez un objet de stratégie de groupe (GPO, group policy object) qui est lié au niveau
du domaine ou qui est lié à l’unité d’organisation qui contient vos comptes
d’ordinateur. Ou sélectionnez un objet GPO qui est déjà déployé.
3. Cliquez avec le bouton droit sur l’objet de stratégie de groupe, puis sélectionnez
Modifier pour ouvrir l’Éditeur de gestion des stratégies de groupe.
4. Développez Configuration ordinateur>Préférences>Paramètres Windows.
5. Cliquez avec le bouton droit sur Registre, pointez sur Nouveau, puis sélectionnez
Élément Registre. La boîte de dialogue Nouvelles propriétés de Registre s'affiche.
6. Dans la liste Ruche, sélectionnez HKEY_LOCAL_MACHINE.
7. Dans la liste Chemin d'accès à la clé, recherchez SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Image File Execution Options\[Link].
8. Dans la zone Nom de la valeur, tapez AuditLevel.
9. Dans la zone Type de la valeur, sélectionnez REG_DWORD.
10. Dans la zone Données de la valeur, tapez 00000008.
11. Sélectionnez OK.
 ７ Notes

Pour que l’objet GPO entre en vigueur, la modification qui lui est apportée doit être
répliquée sur tous les contrôleurs du domaine.

Pour opter pour une protection LSA renforcée sur plusieurs ordinateurs, vous pouvez utiliser
l’extension de Registre côté client pour la stratégie de groupe afin de modifier
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa. Pour obtenir des
instructions, consultez Configurer la protection renforcée des informations d’identification
LSA plus loin dans cet article.

Identifier les plug-ins et les pilotes que [Link] ne

parvient pas à charger
Lorsque la protection LSA est activée, le système génère des journaux des événements qui
identifient tous les plug-ins et pilotes dont le chargement échoue sous LSA. Une fois que
vous avez opté pour la protection LSA renforcée, vous pouvez utiliser le journal des
événements pour identifier les plug-ins et pilotes LSA dont le chargement a échoué en mode
de protection LSA.

Recherchez les événements suivants dans l’observateur d’événements dans Journaux des
applications et des services>Microsoft>Windows>CodeIntegrity>Opérationnel :

L’événement 3033 signale qu’une vérification de l’intégrité du code a déterminé qu’un

processus, généralement [Link], a tenté de charger un pilote qui ne répondait pas
aux conditions requises en matière de niveau de signature Microsoft.
L’événement 3063 signale qu’une vérification de l’intégrité du code a déterminé qu’un
processus, généralement [Link], a tenté de charger un pilote qui ne répondait pas
aux conditions requises en matière de sécurité pour les sections partagées.

Les sections partagées sont généralement le résultat de techniques de programmation qui

permettent aux données d’instance d’interagir avec d’autres processus qui utilisent le même
contexte de sécurité, ce qui peut créer des vulnérabilités de sécurité.

Activer et configurer la protection renforcée des

informations d’identification LSA
Vous pouvez configurer la protection LSA renforcée pour les appareils exécutant
Windows 8.1 ou ultérieur, ou Windows Server 2012 R2 ou ultérieur, à l’aide des procédures
décrites dans cette section.
Appareils qui utilisent le démarrage sécurisé et UEFI
Lorsque vous activez la protection LSA sur des appareils x86 ou x64 qui utilisent le
démarrage sécurisé ou UEFI, vous pouvez stocker une variable UEFI dans le microprogramme
UEFI à l’aide d’une clé de Registre ou d’une stratégie. Lorsqu’il est activé avec le verrou UEFI,
LSASS s’exécute en tant que processus protégé et ce paramètre est stocké dans une variable
UEFI dans le microprogramme.

Quand le paramètre est stocké dans le microprogramme, la variable UEFI ne peut pas être
supprimée ou changée pour configurer la protection LSA renforcée en modifiant le Registre
ou en utilisant une stratégie. La variable UEFI doit être réinitialisée à l’aide des instructions
dans Supprimer la variable UEFI de protection LSA.

Lorsqu’il est activé sans verrou UEFI, LSASS s’exécute en tant que processus protégé et ce
paramètre n’est pas stocké dans une variable UEFI. Ce paramètre est appliqué par défaut sur
les appareils avec une nouvelle installation de Windows 11 version 22H2 ou ultérieure.

Sur les appareils x86 ou x64 qui ne prennent pas en charge UEFI ou sur lesquels le
démarrage sécurisé est désactivé, vous ne pouvez pas stocker la configuration pour la
protection LSA dans le microprogramme. Ces appareils comptent uniquement sur la
présence de la clé de Registre. Dans ce scénario, il est possible de désactiver la protection
LSA en utilisant l’accès à distance à l’appareil. La désactivation de la protection LSA n’entre
en vigueur qu’au redémarrage de l’appareil.

Activation automatique
Pour les appareils clients exécutant Windows 11 version 22H2 et ultérieure, une protection
LSA renforcée est activée par défaut si les critères suivants sont remplis :

L’appareil est une nouvelle installation de Windows 11 version 22H2 ou ultérieure, non
mise à niveau à partir d’une version précédente.
L'appareil est relié à l'entreprise (domaine Active Directory, domaine Microsoft Entra ou
domaine Microsoft Entra hybride).
L’appareil prend en charge HVCI (intégrité du code protégée par l’hyperviseur).

L’activation automatique de la protection LSA renforcée sur Windows 11 version 22H2 et

ultérieure ne définit pas de variable UEFI pour la fonctionnalité. Si vous souhaitez définir une
variable UEFI, vous pouvez utiliser une stratégie ou une configuration de Registre.

７ Notes

Pour les appareils exécutant Windows RT 8.1, la protection LSA renforcée est toujours
activée et ne peut pas être désactivée.
Activer la protection LSA sur un seul ordinateur
Vous pouvez activer la protection LSA sur un seul ordinateur à l’aide du Registre ou d’une
stratégie de groupe locale.

Activer en utilisant le Registre

1. Ouvrez l’Éditeur du Registre [Link] et accédez à la clé de Registre
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
2. Affectez la valeur suivante à la clé de Registre :

"RunAsPPL"=dword:00000001 pour configurer la fonctionnalité avec une variable

UEFI.
"RunAsPPL"=dword:00000002 pour configurer la fonctionnalité sans variable
UEFI, uniquement appliquée sur Windows 11 build 22H2 et ultérieure.

3. Redémarrez l'ordinateur.

Activer à l’aide d’une stratégie de groupe locale sur Windows 11

version 22H2 et ultérieure
1. Ouvrez l’Éditeur de stratégie de groupe locale en entrant [Link].
2. Développez Configuration ordinateur>Modèles d’administration>Système>Autorité
de sécurité locale.
3. Ouvrez la stratégie Configurer LSASS pour qu’il s’exécute en tant que processus
protégé.
4. Définissez la stratégie sur Activé.
5. Sous Options, sélectionnez l’une des options suivantes.

Activé avec verrou UEFI pour configurer la fonctionnalité avec une variable UEFI.
Activé sans verrou UEFI pour configurer la fonctionnalité sans variable UEFI.

6. Sélectionnez OK.
7. Redémarrez l’ordinateur.

Activer la protection LSA à l’aide d’une stratégie de groupe

1. Ouvrez la Console GPMC en entrant [Link] dans la boîte de dialogue Exécuter ou en
sélectionnant la Console de gestion des stratégies de groupe à partir du menu
Démarrer.
2. Créez un objet de stratégie de groupe qui est lié au niveau du domaine ou à l’unité
d’organisation qui contient vos comptes d’ordinateur. Ou sélectionnez un objet GPO
qui est déjà déployé.
 3. Cliquez avec le bouton droit sur l’objet de stratégie de groupe, puis sélectionnez
Modifier pour ouvrir l’Éditeur de gestion des stratégies de groupe.
4. Développez Configuration ordinateur>Préférences>Paramètres Windows.
5. Cliquez avec le bouton droit sur Registre, pointez sur Nouveau, puis sélectionnez
Élément Registre. La boîte de dialogue Nouvelles propriétés de Registre s'affiche.
6. Dans la liste Ruche, sélectionnez HKEY_LOCAL_MACHINE.
7. Dans la liste Chemin d’accès à la clé , recherchez
SYSTEM\CurrentControlSet\Control\Lsa.
8. Dans la zone Nom de la valeur, tapez RunAsPPL.
9. Dans la zone Type de la valeur, sélectionnez REG_DWORD.
10. Dans la zone Données de la valeur, tapez :

00000001 pour activer la protection LSA avec une variable UEFI.

00000002 pour activer la protection LSA sans variable UEFI, appliquée
uniquement sur Windows 11 version 22H2 et ultérieure.

11. Sélectionnez OK.

Activer la protection LSA en créant un profil de

configuration d’appareil personnalisé
Pour les appareils exécutant Windows 11 version 22H2 et ultérieure, vous pouvez activer et
configurer la protection LSA en créant un profil de configuration d’appareil personnalisé
dans le Centre d’administration Microsoft Intune .

1. Dans le Centre d’administration Intune, accédez à Appareils>Windows>Profils de

configuration et sélectionnez Créer un profil.
2. Dans l’écran Créer un profil, sélectionnez les options suivantes :

Plateforme : Windows 10 et ultérieur

Type de profil : Sélectionnez Modèles, puis Personnalisé.

3. Cliquez sur Créer.

4. Dans l’écran Informations de base, entrez un Nom et une Description facultative pour
le profil, puis sélectionnez Suivant.
5. Dans l’écran Paramètres de configuration, sélectionnez Ajouter.
6. Dans l’écran Ajouter une ligne, fournissez les informations suivantes :

Nom : Fournissez un nom pour le paramètre OMA-URI.

OMA-URI : Entrez
./Device/Vendor/MSFT/Policy/Config/LocalSecurityAuthority/ConfigureLsaProtectedProcess.
Type de données : Sélectionnez Entier.
Valeur : Entrez 1 pour configurer LSASS de sorte qu’il s’exécute en tant que
processus protégé avec le verrou UEFI, ou 2 pour configurer LSASS de sorte qu’il
 s’exécute en tant que processus protégé sans verrou UEFI.
7. Sélectionnez Enregistrer, puis sélectionnez Suivant.
8. Dans la page Affectations, configurez les affectations et sélectionnez Suivant.
9. Dans la page Règles d’applicabilité, configurez toutes les règles d’applicabilité et
sélectionnez Suivant.
10. Dans la page Vérifier + créer, vérifiez la configuration et sélectionnez Créer.
11. Redémarrez l'ordinateur.

Pour plus d’informations sur ce fournisseur de service de configuration de stratégie,

consultez LocalSecurityAuthority - ConfigureLsaProtectedProcess.

Désactiver la protection LSA

Vous pouvez désactiver la protection LSA à l’aide du Registre ou d’une stratégie de groupe
locale. Si l’appareil utilise le démarrage sécurisé et que vous définissez la variable UEFI de la
protection LSA dans le microprogramme, vous pouvez utiliser un outil pour supprimer la
variable UEFI.

Désactiver en utilisant le Registre

1. Ouvrez l’Éditeur du Registre [Link] et accédez à la clé de Registre
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
2. Affectez la valeur "RunAsPPL"=dword:00000000 à la clé de Registre ou supprimez le
DWORD.
3. Si PPL a été activé avec une variable UEFI, utilisez l’outil d’exclusion de processus
protégé LSA pour supprimer la variable UEFI.
4. Redémarrez l'ordinateur.

Désactiver à l’aide d’une stratégie locale sur Windows 11

version 22H2 et ultérieure
1. Ouvrez l’Éditeur de stratégie de groupe locale en entrant [Link].
2. Développez Configuration ordinateur>Modèles d’administration>Système>Autorité
de sécurité locale.
3. Ouvrez la stratégie Configurer LSASS pour qu’il s’exécute en tant que processus
protégé.
4. Définissez la stratégie sur Activé.
5. Sous Options, sélectionnez Désactivé.
6. Sélectionnez OK.
7. Redémarrez l'ordinateur.

７ Notes
 Si vous définissez cette stratégie sur Non configuré et que la stratégie était activée, le
paramétrage antérieur reste en vigueur. Vous devez définir la stratégie sur Désactivé
sous la liste déroulante Options pour désactiver la fonctionnalité.

Supprimer la variable UEFI de la protection LSA

Vous pouvez utiliser l’outil de désactivation du processus protégé LSA (Local Security
Authority) (LSAPPLConfig) du Centre de téléchargement Microsoft pour supprimer la
variable UEFI si l’appareil utilise le démarrage sécurisé.

７ Notes

Le Centre de téléchargement propose deux fichiers nommés [Link]. Le fichier

plus petit est destiné aux systèmes x86, tandis que le fichier plus grand est destiné aux
systèmes x64.

Pour plus d'informations sur la gestion du démarrage sécurisé, voir Microprogramme UEFI.

Ｕ Attention

Lorsque le démarrage sécurisé est désactivé, toutes les configurations liées au

démarrage sécurisé et à UEFI sont réinitialisées. Vous ne devez désactiver le démarrage
sécurisé que lorsque tous les autres moyens de désactivation de la protection LSA ont
échoué.

Vérifier la protection LSA

Pour déterminer si LSA a démarré en mode protégé lors du démarrage de Windows,
recherchez dans l’observateur d’événements dans les Journaux Windows>Système
l’événement WinInit suivant :

12 : [Link] a démarré en tant que processus protégé avec le niveau : 4

LSA et Credential Guard

La protection LSA est une fonctionnalité de sécurité qui défend les informations sensibles
telles que les informations d’identification contre le vol en bloquant l’injection de code LSA
non approuvée et le vidage de la mémoire. La protection LSA s’exécute en arrière-plan en
isolant le processus LSA dans un conteneur et en empêchant d’autres processus, tels que les
applications ou les acteurs malveillants, d’accéder à la fonctionnalité. Avec cette isolation, la
protection LSA devient une fonctionnalité de sécurité vitale, c’est pourquoi elle est activée
par défaut dans Windows 11.

À compter de Windows 10, Credential Guard permet aussi d’empêcher les vols
d’informations d’identification en protégeant les hachages de mot de passe NTLM, les
tickets TGT (Ticket Granting Ticket) Kerberos et les informations d’identification stockées par
les applications en tant qu’informations d’identification de domaine. Kerberos, NTLM et le
Gestionnaire d’informations d’identification isolent les secrets à l’aide de la sécurité basée sur
la virtualisation (VBS).

Avec Credential Guard activé, le processus LSA communique avec un composant appelé
« processus LSA isolé », ou [Link], qui stocke et protège les secrets. Les données
stockées par le processus LSA isolé sont protégées à l’aide de VBS et ne sont pas accessibles
au reste du système d’exploitation. L’autorité de sécurité locale utilise des appels de
procédure distante pour communiquer avec le processus LSA isolé.

À compter de Windows 11 version 22H2, VBS et Credential Guard sont activés par défaut sur
tous les appareils qui répondent à la configuration système requise. Credential Guard est pris
en charge sur les appareils avec démarrage sécurisé 64 bits uniquement. La protection LSA et
Credential Guard sont complémentaires, et les systèmes qui prennent en charge Credential
Guard ou qui l’ont activé par défaut peuvent également activer et utiliser la protection LSA.
Pour plus d’informations sur Credential Guard, consultez Vue d’ensemble de Credential
Guard.

Plus de ressources
Gestion et protection des informations d’identification
Espace partenaires pour le matériel Windows

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Nouveautés de Windows Server 2016
Article • 05/08/2024

Cet article décrit les nouvelles fonctionnalités de Windows Server 2016 qui sont
susceptibles d'avoir l'impact le plus important lorsque vous utilisez cette version.

Calcul
La zone Virtualisation contient des fonctionnalités et produits de virtualisation que les
professionnels de l’informatique peuvent utiliser pour la conception, le déploiement et
la maintenance de Windows Server.

Général
Les machines physiques et virtuelles bénéficient d’une plus grande précision du temps
en raison des améliorations apportées aux services Synchronisation date/heure de
Hyper-V et de Win32. Windows Server peut désormais héberger des services qui sont
conformes aux réglementations à venir qui exigent une précision égale à 1 ms en ce qui
concerne l’heure UTC.

Hyper-V
La virtualisation du réseau Hyper-V (HNV) est un élément fondamental de la nouvelle
solution SDN (Software Defined Networking) de Microsoft et est entièrement intégrée
dans la pile SDN. Windows Server 2016 inclut les changements suivants pour Hyper-V :

Windows Server 2016 inclut désormais un commutateur Hyper-V programmable.

Le contrôleur de réseau de Microsoft pousse les stratégies HNV vers le bas jusqu'à
un agent d'hôte qui s'exécute sur chaque hôte en utilisant le protocole de gestion
de base de données Open vSwitch (OVSDB) en tant qu'interface SouthBound
(SBI). L’agent hôte stocke cette stratégie à l’aide d’une personnalisation du schéma
VTEP et programme des règles de flux complexes dans un moteur de flux
performant dans le commutateur Hyper-V. Le moteur de flux du commutateur
Hyper-V est le même que celui utilisé par Azure. L'ensemble de la pile SDN
jusqu'au contrôleur de réseau et au fournisseur de ressources réseau est
également conforme à Azure, ce qui rend ses performances comparables à celles
du cloud public Azure. Dans le moteur de flux de Microsoft, le commutateur
Hyper-V est équipé pour gérer les règles de flux avec et sans état par le biais d'un
simple mécanisme de correspondance qui définit comment les paquets doivent
être traités dans le commutateur.

HNV prend désormais en charge l'encapsulation du protocole Virtual eXtensible

Local Area Network (VXLAN) . HNV utilise le protocole VXLAN en mode de
distribution MAC par l'intermédiaire du contrôleur de réseau Microsoft pour
mapper les adresses IP du réseau global du locataire aux adresses IP du réseau
physique sous-jacent. Les décharges de tâches NVGRE et VXLAN prennent en
charge des pilotes tiers pour améliorer les performances.

Windows Server 2016 inclut un équilibreur de charge logiciel (SLB) avec une prise
en charge complète du trafic de réseau virtuel et une interaction transparente avec
HNV. Le moteur de flux performant met en œuvre le SLB dans le v-Switch du plan
de données, puis le contrôleur de réseau le contrôle pour les mappages IP virtuels
(VIP) ou IP dynamiques (DIP).

HNV implémente des en-têtes Ethernet L2 corrects pour garantir l’interopérabilité

avec des appliances virtuelles et physiques tierces qui dépendent de protocoles
standard du secteur. Microsoft s'assure que tous les paquets transmis ont des
valeurs conformes dans tous les champs pour garantir l'interopérabilité. HNV
nécessite la prise en charge des trames Jumbo (MTU > 1780) dans le réseau
physique L2 pour tenir compte de la surcharge des paquets introduite par les
protocoles d'encapsulation tels que NVGRE et VXLAN. La prise en charge des
trames Jumbo garantit que les machines virtuelles invitées attachées à un réseau
virtuel HNV conservent une MTU de 1514.

La prise en charge des conteneurs Windows ajoute des améliorations de

performance, une gestion simplifiée du réseau et une prise en charge des
conteneurs Windows sur Windows 10. Pour plus d'informations, consultez notre
documentation sur les conteneurs Windows et les conteneurs : Docker, Windows
et les tendances .

Hyper-V est désormais compatible avec Connected Standby. Lorsque vous installez
le rôle Hyper-V sur un ordinateur qui utilise le modèle d'alimentation Always
On/Always Connected (AOAC), vous pouvez désormais le configurer pour qu'il
utilise l'état d'alimentation Connected Standby.

L'attribution de périphériques discrets vous permet de donner à une machine

virtuelle (VM) un accès direct et exclusif à certains périphériques matériels PCIe.
Cette fonctionnalité contourne la pile de virtualisation Hyper-V, ce qui permet un
accès plus rapide. Pour plus d'informations, voir Affectation de périphériques
discrets et Affectation de périphériques discrets - Description et contexte .
Hyper-V prend désormais en charge le chiffrement BitLocker des disques du
système d'exploitation dans les machines virtuelles de génération 1. Cette
méthode de protection remplace les modules TPM (Trusted Platform Modules)
virtuels, qui ne sont disponibles que dans les machines virtuelles de génération 2.
Pour décrypter le disque et démarrer la VM, l'hôte Hyper-V doit soit faire partie
d'une structure surveillée autorisée, soit disposer de la clé privée de l'un des
gardiens de la VM. Le stockage des clés nécessite une VM version 8. Pour plus
d'informations, reportez-vous à la section Mise à niveau de la version de la
machine virtuelle dans Hyper-V sur Windows ou Windows Server.

La protection des ressources de l'hôte empêche les machines virtuelles d'utiliser

trop de ressources système en surveillant les niveaux d'activité excessifs. Lorsque la
surveillance détecte un niveau d'activité anormalement élevé dans une VM, elle
limite la quantité de ressources consommées par la VM. Vous pouvez activer cette
fonctionnalité en exécutant la cmdlet Set-VMProcessor dans PowerShell.

Vous pouvez désormais utiliser l'ajout ou la suppression à chaud pour ajouter ou

supprimer des adaptateurs réseau pendant que la VM est en cours d'exécution,
sans temps d'arrêt, dans les VM de génération 2 exécutant les systèmes
d'exploitation Linux ou Windows. Vous pouvez également ajuster la quantité de
mémoire attribuée à une VM en cours d'exécution, même si vous n'avez pas activé
la mémoire dynamique sur les VM de génération 1 et 2 exécutant Windows Server
2016 et versions ultérieures ou Windows 10 et versions ultérieures.

Hyper-V Manager prend désormais en charge les fonctionnalités suivantes :

Les informations d'identification alternatives, qui vous permettent d'utiliser un

ensemble différent d'informations d'identification dans Hyper-V Manager lors
de la connexion à un autre hôte distant Windows Server 2016 ou Windows 10.
Vous pouvez également enregistrer ces informations d'identification pour
faciliter la connexion.

Vous pouvez désormais gérer Hyper-V sur des machines exécutant Windows
Server 2012 R2, Windows Server 2012, Windows 8.1 et Windows 8.

Hyper-V Manager communique désormais avec les hôtes Hyper-V distants à

l'aide du protocole WS-MAN, qui permet l'authentification CredSSP, Kerberos et
NTLM. Lorsque vous utilisez CredSSP pour vous connecter à un hôte Hyper-V
distant, vous pouvez effectuer une migration en direct sans activer la délégation
restreinte dans Active Directory. WS-MAN facilite également l'activation des
hôtes pour la gestion à distance. WS-MAN se connecte par le biais du port 80
qui est ouvert par défaut.
Les mises à jour des services d'intégration pour les invités Windows sont
désormais distribuées via Windows Update. Les fournisseurs de services et les
hôtes de nuages privés peuvent donner aux locataires qui possèdent les machines
virtuelles le contrôle de l'application des mises à jour. Les locataires Windows
peuvent désormais mettre à jour leurs machines virtuelles avec toutes les dernières
mises à jour par le biais d'une méthode unique. Pour plus d'informations sur la
façon dont les locataires Linux peuvent utiliser les services d'intégration, consultez
Machines virtuelles Linux et FreeBSD prises en charge pour Hyper-V sur Windows
Server et Windows.

） Important

Hyper-V pour Windows Server 2016 n'inclut plus le fichier image [Link]
car il n'est plus nécessaire.

Les systèmes d'exploitation Linux exécutés sur des VM de génération 2 peuvent

désormais démarrer avec l'option Secure Boot activée. Les systèmes d'exploitation
qui prennent en charge Secure Boot sur les hôtes Windows Server 2016
comprennent Ubuntu 14.04 et versions ultérieures, SUSE Linux Enterprise Server 12
et versions ultérieures, Red Hat Enterprise Linux 7.0 et versions ultérieures, et
CentOS 7.0 et versions ultérieures. Avant de démarrer la VM pour la première fois,
vous devez la configurer pour qu'elle utilise l'autorité de certification Microsoft
UEFI dans Hyper-V Manager, Virtual Machine Manager ou en exécutant la cmdlet
Set-VMFirmware dans PowerShell.

Les machines virtuelles et les hôtes Hyper-V de génération 2 peuvent désormais

utiliser beaucoup plus de mémoire et de processeurs virtuels. Vous pouvez
également configurer les hôtes avec plus de mémoire et de processeurs virtuels
que les versions précédentes. Ces modifications prennent en charge des scénarios
tels que l'exécution de grandes bases de données en mémoire pour le traitement
des transactions en ligne (OLTP) et l'entreposage de données (DW) pour le
commerce électronique. Pour plus d'informations, consultez les performances des
VM Windows Server 2016 Hyper-V à grande échelle pour le traitement des
transactions en mémoire . Pour en savoir plus sur la compatibilité des versions et
les configurations maximales prises en charge, consultez Mise à niveau de la
version de la machine virtuelle dans Hyper-V sur Windows ou Windows Server et
Planification de l'évolutivité d'Hyper-V dans Windows Server.

La fonction de virtualisation imbriquée vous permet d'utiliser une VM comme hôte

Hyper-V et de créer des VM au sein de l'hôte virtualisé. Vous pouvez utiliser cette
fonctionnalité pour créer des environnements de développement et de test
exécutant au moins Windows Server 2016 ou Windows 10 avec un processeur
compatible Intel VT-x. Pour plus d'informations, consultez la section Qu'est-ce que
la virtualisation imbriquée ?

Vous pouvez désormais configurer des points de contrôle de production pour vous
conformer aux politiques de support des VM exécutant des charges de travail de
production. Ces points de contrôle s'exécutent sur la technologie de sauvegarde à
l'intérieur du périphérique invité au lieu d'un état sauvegardé. Les machines
virtuelles Windows utilisent le service de cliché instantané de volume (VSS), tandis
que les machines virtuelles Linux rincent les tampons du système de fichiers pour
créer des points de contrôle cohérents avec le système de fichiers. Vous pouvez
toujours utiliser des points de contrôle basés sur des états sauvegardés en utilisant
des points de contrôle standard à la place. Pour plus d'informations, voir Choisir
entre les points de contrôle standard ou de production dans Hyper-V.

） Important

Les nouvelles machines virtuelles utilisent les points de contrôle de

production par défaut.

Vous pouvez désormais redimensionner les disques durs virtuels partagés (fichiers
.vhdx ) pour le clustering invité sans temps d'arrêt. Vous pouvez également utiliser

les clusters invités pour protéger les disques durs virtuels partagés en utilisant
Hyper-V Replica pour la reprise après sinistre. Vous ne pouvez utiliser cette
fonctionnalité que sur les collections d'un cluster invité pour lequel vous avez
activé la réplication via Windows Management Instrumentation (WMI). Pour plus
d'informations, voir la classe Msvm_CollectionReplicationService et la présentation
du partage des disques durs virtuels.

７ Notes

La gestion de la réplication d'une collection n'est pas possible via les cmdlets
PowerShell ou l'interface WMI.

Lors de la sauvegarde d'une seule machine virtuelle, nous ne recommandons pas

l'utilisation d'un groupe de VM ou d'une collection d'instantanés, que l'hôte soit en
cluster ou non. Ces options sont destinées à la sauvegarde de clusters d'invités qui
utilisent un vhdx partagé. Nous vous recommandons plutôt de prendre un
instantané à l'aide du fournisseur Hyper-V WMI (V2).
Vous pouvez désormais créer des VM Hyper-V protégées qui incluent des
fonctionnalités empêchant les administrateurs Hyper-V sur l'hôte ou les logiciels
malveillants d'inspecter, d'altérer ou de voler les données de l'état de la VM
protégée. Les données et l'état sont cryptés afin que les administrateurs Hyper-V
ne puissent pas voir la sortie vidéo et les disques disponibles. Vous pouvez
également limiter l'exécution des machines virtuelles aux hôtes dont un serveur
Host Guardian a déterminé qu'ils sont sains et dignes de confiance. Pour plus
d’informations, consultez Présentation de l’infrastructure protégée et des machines
virtuelles dotées d’une protection maximale.

７ Notes

Les machines virtuelles blindées sont compatibles avec Hyper-V Replica. Pour
répliquer une machine virtuelle blindée, vous devez autoriser l'hôte que vous
souhaitez répliquer à exécuter cette VM blindée.

La fonction de priorité de l'ordre de démarrage des machines virtuelles en grappe

vous permet de mieux contrôler les VM en grappe qui démarrent ou redémarrent
en premier. La priorité de l'ordre de démarrage vous permet de démarrer les
machines virtuelles qui fournissent des services avant les machines virtuelles qui
utilisent ces services. Vous pouvez définir des ensembles, ajouter des machines
virtuelles aux ensembles et spécifier des dépendances à l'aide de cmdlets
PowerShell telles que New-ClusterGroupSet, Get-ClusterGroupSet et Add-
ClusterGroupSetDependency.

Les fichiers de configuration de la machine virtuelle utilisent désormais le format

d'extension de fichier .vmcx tandis que les fichiers de données d'état d'exécution
utilisent le format d'extension de fichier .vmrs . Ces nouveaux formats de fichiers
sont conçus pour permettre une lecture et une écriture plus efficaces. Ils réduisent
également la probabilité de corruption des données en cas de défaillance du
stockage.

） Important

L'extension du nom de fichier .vmcx indique qu'il s'agit d'un fichier binaire.
Hyper-V pour Windows Server 2016 ne prend pas en charge la modification
des fichiers .vmcx ou .vmrs .

Nous avons mis à jour la compatibilité de la version avec les VM de la version 5.

Ces VM sont compatibles avec Windows Server 2012 R2 et Windows Server 2016.
 Cependant, les VM de la version 5 compatibles avec Windows Server 2019 ne
peuvent s'exécuter que sur Windows Server 2016, et non sur Windows Server 2012
R2. Si vous déplacez ou importez une VM Windows Server 2012 R2 vers un serveur
exécutant une version ultérieure de Windows Server, vous devez mettre à jour
manuellement la configuration de la VM pour utiliser les fonctionnalités des
versions ultérieures de Windows Server. Pour plus d'informations sur la
compatibilité des versions et les fonctionnalités mises à jour, voir Mise à niveau de
la version de la machine virtuelle dans Hyper-V sur Windows ou Windows Server.

Vous pouvez désormais utiliser les fonctions de sécurité basées sur la virtualisation
pour les machines virtuelles de génération 2, telles que Device Guard et Credential
Guard, afin de protéger votre système d'exploitation contre les exploits de logiciels
malveillants. Ces fonctionnalités sont disponibles dans les machines virtuelles
exécutant la version 8 ou une version ultérieure. Pour plus d'informations,
reportez-vous à la section Mise à niveau de la version de la machine virtuelle dans
Hyper-V sur Windows ou Windows Server.

Vous pouvez désormais exécuter des cmdlets à l'aide de Windows PowerShell

Direct pour configurer votre VM à partir de la machine hôte, ce qui constitue une
alternative à VMConnect ou Remote PowerShell. Vous n'avez pas besoin de
répondre à des exigences en matière de réseau ou de pare-feu, ni de disposer
d'une configuration spéciale de gestion à distance pour commencer à l'utiliser.
Pour plus d'informations, voir Gérer les machines virtuelles Windows avec
PowerShell Direct.

Nano Server
Nano Server possède maintenant un module mis à jour pour la création d’images Nano
Server, et propose notamment une plus grande séparation des fonctionnalités de l’hôte
physique et de la machine virtuelle invitée, ainsi que la prise en charge de différentes
éditions de Windows Server. Pour plus d'informations, voir Installer Nano Server.

Des améliorations ont également été apportées à la console de récupération,

notamment la séparation des règles de pare-feu entrantes et sortantes ainsi que la
possibilité de réparer la configuration de WinRM.

Machines virtuelles dotées d’une protection maximale

Windows Server 2016 fournit une nouvelle machine virtuelle Hyper-V dotée d’une
protection maximale, pour protéger une machine virtuelle de deuxième génération
contre une structure compromise. Les fonctionnalités introduites dans Windows
Server 2016 sont les suivantes :

Un nouveau mode Chiffrement pris en charge qui offre plus de protections que
pour une machine virtuelle ordinaire, mais moins que le mode Protection
maximale, tout en prenant toujours en charge le module de plateforme sécurisée
(TPM) virtuel, le chiffrement de disque, le chiffrement de trafic de migration
dynamique et d'autres fonctionnalités, notamment les avantages d'administration
de structure directe tels que les connexions de console de machine virtuelle et
PowerShell Direct.

Prise en charge complète de la conversion de machines virtuelles de génération 2

non protégées existantes en machines virtuelles dotées d’une protection maximale,
dont le chiffrement automatique du disque.

Hyper-V Virtual Machine Manager peut désormais afficher les structures sur
lesquelles une machine virtuelle dotée d’une protection maximale peut s’exécuter,
ce qui permet à l’administrateur de la structure d’ouvrir le protecteur de clé d’une
machine virtuelle dotée d’une protection maximale et d’afficher les structures sur
lesquelles l’exécution est autorisée.

Vous pouvez changer de mode d’attestation sur un service Guardian hôte en cours
d’exécution. Vous pouvez maintenant basculer sur-le-champ entre l’attestation
Active Directory moins sécurisée, mais plus simple, et l’attestation basée sur le
module de plateforme sécurisée.

Des outils de diagnostic de bout en bout basés sur Windows PowerShell qui sont
en mesure de détecter des problèmes de configuration ou des erreurs à la fois
dans les hôtes Hyper-V protégés et le service Guardian hôte.

Un environnement de récupération qui offre un moyen de résoudre les problèmes

des machines virtuelles dotées d’une protection maximale et de les réparer en
toute sécurité au sein de la structure dans laquelle elles s’exécutent normalement
tout en offrant le même niveau de protection que la machine virtuelle dotée d’une
protection maximale elle-même.

Le service Guardian hôte prend en charge une instance Active Directory sécurisée :
vous pouvez demander au service Guardian hôte d’utiliser une forêt Active
Directory comme la sienne au lieu de créer sa propre instance Active Directory.

Pour plus d’informations et d’instructions sur l’utilisation des machines virtuelles dotées
d’une protection maximale, consultez Structure protégée et machines virtuelles dotées
d’une protection maximale.
Identité et accès
De nouvelles fonctionnalités d'identité améliorent la capacité des organisations à
sécuriser les environnements Active Directory et leur permettent de migrer vers les
déploiements de cloud uniquement et les déploiements hybrides, où certains services et
applications sont hébergés dans le cloud et d'autres en local.

Services de certificats Active Directory

Les services de certificats Active Directory (AD CS) dans Windows Server 2016
améliorent la prise en charge de l’attestation de clé de module de plateforme sécurisée
(TPM) : vous pouvez maintenant utiliser le fournisseur de stockage de clés de carte à
puce pour l’attestation de clé, et les appareils qui ne sont pas joints au domaine peuvent
maintenant utiliser l’inscription NDES pour obtenir des certificats qui peuvent être
attestés pour des clés présentes dans un module de plateforme sécurisée (TPM).

Gestion des accès privilégiés

La gestion des accès privilégiés (PAM) permet d’atténuer les problèmes de sécurité dans
les environnements Active Directory qui sont causés par des techniques de vol
d’informations d’identification telles que le hachage, le hameçonnage de lance, etc. Vous
pouvez configurer cette nouvelle solution d’accès administratif à l’aide de Microsoft
Identity Manager (MIM). Elle présente les fonctionnalités suivantes :

La forêt bastion Active Directory, approvisionnée par MIM, a une relation

d’approbation spéciale PAM avec une forêt existante. Les forêts bastion constituent
un nouveau type d’environnement Active Directory, à l’abri de toute activité
malveillante, car elles sont isolées des forêts existantes et n’autorisent l’accès
qu’aux comptes privilégiés.

Nouveaux processus dans MIM pour demander des privilèges administratifs, y

compris de nouveaux flux de travail pour l’approbation des requêtes.

Nouveaux principaux de sécurité d’ombre (ou groupes) approvisionnés dans la

forêt bastion par MIM en réponse aux demandes de privilèges d’administration.
Les groupes de sécurité fantôme ont un attribut qui fait référence au SID d’un
groupe d’administration dans une forêt existante. Cela permet au groupe d’ombres
d’accéder aux ressources dans des forêts existantes sans modifier les listes de
contrôle d’accès.

Une fonctionnalité de liaisons arrivant à expiration, qui permet l’appartenance

limitée dans le temps dans un groupe d’ombres. Vous pouvez ajouter des
 utilisateurs au groupe pendant une durée définie pour leur permettre d’effectuer
des tâches administratives. L’appartenance limitée dans le temps est configurée
par une valeur de durée de vie propagée à une durée de vie de ticket Kerberos.

７ Notes

Les liens arrivant à expiration sont disponibles sur tous les attributs liés.
Toutefois, seule la relation d’attribut lié member/memberOF entre un groupe
et un utilisateur est préconfigurée avec PAM pour utiliser la fonctionnalité de
liens arrivant à expiration.

Les améliorations de contrôleur de domaine Kerberos (KDC) intégrées aux

contrôleurs de domaine Active Directory pour limiter la durée de vie des tickets
Kerberos à la valeur de durée de vie la plus faible possible lorsque les utilisateurs
ont plusieurs appartenances limitées dans le temps dans des groupes
d’administration. Par exemple, si vous appartenez à un groupe A limité dans le
temps, lorsque vous vous authentifiez, la durée de vie du ticket TGT (Ticket-
granting ticket) Kerberos est égale au temps qu’il vous reste dans le groupe A. Si
vous rejoignez également un autre groupe B limité dans le temps, dont la durée de
vie est inférieure à celle du groupe A, la durée de vie du TGT est égale au temps
qu’il vous reste dans le groupe B.

De nouvelles fonctionnalités de surveillance vous permettent d’identifier les

utilisateurs qui ont demandé un accès, les accès que les administrateurs leur ont
accordés et les activités qu’ils ont effectuées lorsqu’ils étaient connectés.

Pour en savoir plus sur les PAM, consultez Privileged Access Management for Active
Directory Domain Services.

Jonction Microsoft Entra

La jonction Microsoft Entra améliore les expériences d’identité pour les clients de
l’entreprise, du commerce et de l’éducation, et inclut des fonctionnalités améliorées
pour les appareils professionnels et personnels.

Les paramètres modernes sont désormais disponibles sur les appareils Windows
appartenant à l’entreprise. Les fonctionnalités de Core Windows ne nécessitent
plus de compte Microsoft personnel : elles s’exécutent désormais à partir des
comptes professionnels existants des utilisateurs pour garantir la conformité. Ces
services fonctionnent sur les PC qui sont joints à un domaine Windows local, ainsi
 que les appareils qui sont « joints » à Microsoft Entra. Il s’agit notamment des
paramètres suivants :

Itinérance ou personnalisation, paramètres d’accessibilité et informations

d’identification

Sauvegarde et restauration

Accès au Microsoft Store avec votre compte professionnel

Vignettes dynamiques et notifications

Accès aux ressources organisationnelles sur des appareils mobiles, notamment des
téléphones et des tablettes, qui ne peuvent pas être joints à un domaine Windows,
qu’ils appartiennent à une entreprise ou qu’ils soient BYOD.

Utilisez une authentification unique (SSO) pour Office 365 et d’autres applications,
sites web et ressources de l’organisation.

Sur les appareils BYOD, ajoutez un compte professionnel à partir d’un domaine
local ou d’Azure AD à un appareil appartenant à un utilisateur. Vous pouvez utiliser
le SSO pour accéder aux ressources professionnelles, via les applications et sur le
Web, de manière à garantir la conformité avec les nouvelles fonctionnalités telles
que le contrôle de compte conditionnel et l’attestation d’intégrité de l’appareil.

L’intégration de la gestion des appareils mobiles (MDM) vous permet d’inscrire

automatiquement des appareils à votre outil de gestion des appareils mobiles
(MDM) (Microsoft Intune ou tiers).

Configurer le mode « kiosque » et les appareils partagés pour plusieurs utilisateurs

de votre organisation.

L’expérience des développeurs vous permet de créer des applications qui

s’adressent aux contextes d’entreprise et personnels avec une pile de
programmation partagée.

L’option d’acquisition d’images vous permet de choisir entre la création d’images

et permettre à vos utilisateurs de configurer des appareils appartenant à
l’entreprise directement pendant l’expérience de première exécution.

Windows Hello Entreprise

Windows Hello Entreprise est une approche d’authentification basée sur la clé pour les
organisations et les consommateurs qui ne nécessite pas de passer par un mot de passe.
Cette forme d’authentification repose sur les informations d’identification contre les
violations, le vol et le hameçonnage.

L’utilisateur se connecte à l’appareil à l’aide d’un identifiant biométrique ou d’un code

PIN lié à un certificat ou à une paire de clés asymétriques. Les fournisseurs d’identité
valident l’utilisateur en mappant sa clé publique à IDlocker et fournissent des
informations de connexion via un mécanisme de notification tel que le mot de passe à
usage unique ou téléphone, entre autres.

Pour plus d'informations, voir Windows Hello for Business.

Dépréciation des niveaux fonctionnels du service de réplication de

fichiers (FRS) et de Windows Server 2003

Bien que le service de réplication de fichiers et les niveaux fonctionnels de Windows

Server 2003 soient déconseillés dans les versions précédentes de Windows Server, nous
souhaitons vous rappeler qu’AD DS ne prend plus en charge le système d’exploitation
Windows Server 2003. Vous devez donc supprimer du domaine tous les contrôleurs de
domaine qui exécutent Windows Server 2003. Vous devez également élever le niveau
fonctionnel du domaine et de la forêt au moins à Windows Server 2008.

Aux niveaux fonctionnels de domaine Windows Server 2008 et supérieurs, AD DS utilise

la réplication DFS (Distributed File Service) pour répliquer le contenu du dossier SYSVOL
entre les contrôleurs de domaine. Si vous créez un domaine au niveau fonctionnel de
domaine Windows Server 2008 ou supérieur, la réplication DFS réplique
automatiquement le dossier SYSVOL. Si vous avez créé le domaine à un niveau
fonctionnel inférieur, vous devez passer de l’utilisation de FRS à la réplication DFS pour
le fichier SYSVOL. Pour obtenir des étapes de migration plus détaillées, consultez
Installer, mettre à niveau ou migrer vers Windows Server.

Pour plus d’informations, consultez les ressources suivantes :

Présentation des niveaux fonctionnels des services de domaine Active Directory

(AD DS)
Comment élever les niveaux fonctionnels de domaine et de forêt Active Directory

Services de fédération Active Directory (AD FS)

Les services AD FS de Windows Server 2016 incluent de nouvelles fonctionnalités qui
vous permettent de configurer AD FS pour authentifier les utilisateurs stockés dans les
annuaires LDAP (Lightweight Directory Access Protocol).
Proxy d'application web
La dernière version du Proxy d'application Web se concentre sur les nouvelles
fonctionnalités qui permettent la publication et la préauthentification d'applications
supplémentaires et améliorent l'expérience utilisateur. Consultez la liste complète des
nouvelles fonctionnalités qui inclut la préauthentification des applications clientes riches
comme Exchange ActiveSync et les domaines avec caractères génériques pour une
publication plus facile des applications SharePoint. Pour plus d’informations, consultez
Proxy d’application web dans Windows Server 2016.

Administration
La section Gestion et automatisation fournit des informations sur les outils et références
pour les professionnels de l'informatique qui souhaitent exécuter et gérer Windows
Server 2016, dont Windows PowerShell.

Windows PowerShell 5.1 contient de nouvelles fonctionnalités importantes, notamment

la prise en charge du développement avec les classes, et de nouvelles fonctionnalités de
sécurité, qui étendent son utilisation, améliorent sa convivialité, et vous permettent de
contrôler et de gérer des environnements Windows de façon plus simple et plus
complète. Pour plus d’informations, consultez Nouveaux scénarios et nouvelles
fonctionnalités dans WMF 5.1.

Les nouveautés de Windows Server 2016 incluent la possibilité d’exécuter

[Link] localement sur Nano Server (et non plus seulement à distance), de
nouvelles applets de commande Utilisateurs et groupes locaux pour remplacer
l’interface utilisateur graphique, la prise en charge du débogage de PowerShell et la
prise en charge de Nano Server pour la transcription et la journalisation de la sécurité,
ainsi que JEA.&&

Voici d’autres nouvelles fonctionnalités d’administration :

Configuration d’état souhaité Windows PowerShell (DSC)

dans Windows Management Framework (WMF) 5
Windows Management Framework 5 inclut des mises à jour de configuration d’état
souhaité Windows PowerShell (DSC), Windows Remote Management (WinRM) et
Windows Management Instrumentation (WMI).

Pour plus d’informations sur le test des fonctionnalités DSC de Windows Management
Framework 5, consultez la série de billets de blog mentionnés dans Valider les
fonctionnalités de PowerShell DSC . Pour effectuer le téléchargement, consultez
Windows Management Framework 5.1.

Gestion unifiée des packages PackageManagement pour

la détection, l’installation et l’inventaire des logiciels
Windows Server 2016 et Windows 10 incluent une nouvelle fonctionnalité
PackageManagement (auparavant appelée OneGet) qui permet aux professionnels de
l’informatique ou développeurs d’automatiser la détection, l’installation et l’inventaire
des logiciels, localement ou à distance, quels que soient la technologie d’installation
utilisée et l’emplacement des logiciels.

Pour en savoir plus, voir [Link] .

Améliorations de PowerShell pour faciliter la forensique

numérique et aider à réduire les violations de sécurité
Pour aider l’équipe responsable de l’examen des systèmes compromis, parfois appelée
« l’équipe bleue », nous avons ajouté des fonctionnalités d’investigation numérique et
de journalisation PowerShell supplémentaires ainsi que des fonctionnalités destinées à
réduire les vulnérabilités dans les scripts, comme PowerShell limité et à sécuriser les API
CodeGeneration.

Pour plus d'informations, consultez le billet de blog PowerShell ♥ the Blue Team .

Réseau
La section Mise en réseau décrit les fonctionnalités et produits de mise en réseau que
les professionnels de l'informatique peuvent utiliser pour la conception, le déploiement
et la maintenance de Windows Server 2016.

Mise en réseau définie par logiciel

La mise en réseau définie par logiciel (SDN) est une nouvelle solution SDDC (Centre de
données définis par logiciel) qui inclut les fonctionnalités suivantes :

Contrôleur de réseau, qui vous permet d’automatiser la configuration de

l’infrastructure réseau au lieu d’effectuer une configuration manuelle des services
et appareils réseau. Le contrôleur de réseau utilise Representational State Transfer
(REST) sur son interface direction nord avec des charges utiles
JavaScript Object Notation (JSON). L’interface direction sud du contrôleur de
réseau utilise le protocole OVSDB (Open vSwitch Database Management).

Nouvelles fonctionnalités pour Hyper-V :

Commutateur virtuel Hyper-V, qui vous permet de créer une commutation et un

routage distribués, ainsi qu’une couche d’application de stratégie alignée et
compatible avec Microsoft Azure. Pour en savoir plus, consultez Commutateur
virtuel Hyper-V.

Accès direct à la mémoire à distance (RDMA) et switch-embedded teaming

(SET) lorsque vous créez des commutateurs virtuels. Vous pouvez configurer
RDMA sur les adaptateurs réseau liés à un commutateur virtuel Hyper-V, que
vous utilisiez ou non SET. SET peut donner à vos commutateurs virtuels des
capacités similaires à celles du teaming NIC. Pour plus de détails, voir
Configuration requise du réseau hôte pour Azure Stack HCI.

Les files d'attente multiples de machines virtuelles (VMMQ) améliorent le

rendement des VMQ en allouant plusieurs files d'attente matérielles par VM. La
file d'attente par défaut devient un ensemble de files d'attente pour une VM et
répartit le trafic entre les files d'attente.

La qualité de service (QoS) pour les réseaux définis par logiciel gère la classe de
trafic par défaut via le commutateur virtuel dans la bande passante de la classe
par défaut.

La virtualisation des fonctions réseau (NFV), qui vous permet de mettre en miroir
ou d’acheminer des fonctions réseau exécutées par des appareils matériels vers
des appareils virtuels, tels que des équilibreurs de charge, des pare-feu, des
routeurs, des commutateurs, etc. Vous pouvez également déployer et gérer toute
votre pile SDN à l’aide de System Center Virtual Machine Manager. Vous pouvez
utiliser Docker pour gérer la mise en réseau de conteneurs Windows Server et
associer des stratégies de mise en réseau SDN à des machines virtuelles et à des
conteneurs.

Un pare-feu de centre de données qui fournit des listes de contrôle d’accès (ACL)
granulaires, ce qui vous permet d’appliquer des stratégies de pare-feu au niveau
de l’interface de la machine virtuelle ou du sous-réseau. Pour en savoir plus,
consultez Qu’est-ce que le pare-feu de centre de données ?

Passerelle RAS, qui vous permet d’acheminer le trafic entre des réseaux virtuels et
des réseaux physiques, y compris les connexions VPN de site à site entre votre
centre de données dans le cloud et les sites distants de vos locataires. Le protocole
Border Gateway Protocol (BGP) vous permet de déployer et de fournir un routage
 dynamique entre les réseaux pour tous les scénarios de passerelles, y compris les
réseaux privés virtuels (VPN) de site à site IKEv2 (Internet Key Exchange version 2),
les VPN de couche 3 (L3) et les passerelles GRE (Generic Routing Encapsulation).
Les passerelles prennent désormais également en charge les pools de passerelles
et la redondance M+N. Pour en savoir plus, consultez Qu’est-ce qu’une passerelle
de service d’accès à distance (RAS) pour une mise en réseau définie par logiciel ?

L’équilibreur de charge logicielle (SLB) et la traduction d’adresses réseau (NAT)

améliorent le débit en prenant en charge le retour direct du serveur. Ainsi, le trafic
de retour du réseau peut contourner le multiplexeur d’équilibrage de charge et
peut être réalisé à l’aide d’un équilibreur de charge de couche 4 nord-sud et est-
ouest, et d’une NAT. Pour en savoir plus, consultez Qu’est-ce qu’un équilibreur de
charge logicielle (SLB) pour SDN ? et la virtualisation de fonction réseau.

Des technologies d’encapsulation flexibles qui fonctionnent au niveau du plan de

données et prennent en charge à la fois Virtual Extensible LAN (VxLAN) et Network
Virtualization Generic Routing Encapsulation (NVGRE).

Pour plus d’informations, consultez Planifier une mise en réseau SDN (Software Defined
Networking).

Principes de base de la mise à l’échelle cloud

Windows Server 2016 inclut les éléments fondamentaux suivants à l’échelle du cloud :

Carte d’interface réseau (NIC) convergée, qui vous permet d’utiliser une seule carte
réseau pour la gestion, le stockage compatible RDMA (Remote Direct Memory
Access) et le trafic de locataires. Une carte d’interface réseau convergée réduit le
coût de chaque serveur de votre centre de données, car elle nécessite moins de
cartes réseau pour gérer différents types de trafic par serveur.

Packet Direct fournit une infrastructure de traitement des paquets à faible latence
et à débit de trafic réseau élevé.

Switch Embedded Teaming (SET) est une solution d’association de cartes réseau
intégrée au commutateur virtuel Hyper-V. SET permet d’associer jusqu’à huit cartes
d’interface réseau physiques en une seule association SET, ce qui améliore la
disponibilité et assure le basculement. Dans Windows Server 2016, vous pouvez
créer des associations SET qui sont limitées à l’utilisation de Server Message Block
(SMB) et RDMA. Vous pouvez également utiliser des associations SET pour répartir
le trafic réseau pour la virtualisation de réseau Hyper-V. Pour en savoir plus,
consultez Exigences du réseau hôte pour Azure Stack HCI.
Améliorations des performances de TCP
La fenêtre de congestion initiale par défaut a été augmentée de 4 à 10 et TCP Fast Open
(TFO) a été implémenté. TFO réduit le temps nécessaire pour établir une connexion TCP
et la nouvelle fenêtre de congestion initiale permet de transférer des objets plus
volumineux dans la rafale initiale. Cette combinaison réduit considérablement le temps
nécessaire pour transférer un objet Internet entre le client et le cloud.

Pour améliorer le comportement de TCP en cas de récupération suite à une perte de

paquets, nous avons implémenté TCP TLP (Tail Loss Probe) et RACK (Recent
Acknowledgment). TLP permet de convertir des délais de retransmission en
récupérations rapides, et RACK réduit le temps nécessaire à une récupération rapide
pour retransmettre un paquet perdu.

Protocole DHCP (Dynamic Host Configuration Protocol)

Le protocole DHCP (Dynamic Host Configuration Protocol) présente les changements
suivants dans Windows Server 2016 :

À partir d Windows 10, version 2004, lorsque vous exécutez un client Windows et
que vous vous connectez à Internet à l’aide d’un appareil Android en partage de
connexion, les connexions sont désormais étiquetées comme mesurées. Le nom du
fournisseur client traditionnel qui s’affichait comme MSFT 5.0 sur certains appareils
Windows est maintenant MSFT 5.0 XBOX.

À compter de Windows 10, version 1803, le client DHCP peut désormais lire et
appliquer l’option 119, l’option de recherche de domaine, à partir du serveur DHCP
auquel votre système se connecte. L’option de recherche de domaine fournit
également des suffixes DNS (Domain Name Services) pour les recherches DNS de
noms courts. Pour plus d’informations, consultez RFC 3397 .

DHCP prend désormais en charge l’option 82 (sous-option 5). Vous pouvez utiliser
cette option pour autoriser les clients proxy DHCP et les agents de relais à
demander une adresse IP pour un sous-réseau spécifique. Si vous utilisez un agent
de relais DHCP configuré avec l’option DHCP 82 (sous-option 5), l’agent de relais
peut demander un bail d’adresse IP pour les clients DHCP à partir d’une plage
d’adresses IP spécifique. Pour plus d’informations, consultez Options de sélection
de sous-réseau DHCP.

Nouveaux événements de journalisation pour les cas où les inscriptions

d’enregistrements DNS échouent sur le serveur DNS. Pour en savoir plus, consultez
Événements de journalisation DHCP pour les inscriptions DNS.
 Le rôle de serveur DHCP ne prend plus en charge la protection d’accès réseau
(NAP). Les serveurs DHCP n’appliquent pas de stratégies NAP et les étendues
DHCP ne peuvent pas être activées pour NAP. Les ordinateurs clients DHCP qui
sont également des clients NAP envoient une instruction d’intégrité (SoH) avec la
requête DHCP. Si le serveur DHCP exécute Windows Server 2016, ces requêtes sont
traitées comme si aucun SoH n’était présent. Le serveur DHCP accorde un bail
DHCP normal au client. Si les serveurs qui exécutent Windows Server 2016 sont
des proxys RADIUS (Remote Authentication Dial-In User Service) qui transmettent
les demandes d’authentification à un serveur de stratégie réseau (NPS) qui prend
en charge NAP, le NPS évalue ces clients comme n’étant pas compatibles NAP, ce
qui entraîne l’échec du traitement NAP. Pour en savoir plus sur NAP et son
obsolescence, consultez Fonctionnalités supprimées ou obsolètes dans Windows
Server 2012 R2.

Tunneling GRE
La passerelle RAS prend désormais en charge les tunnels Generic Routing Encapsulation
(GRE) à haute disponibilité pour les connexions de site à site et la redondance M+N des
passerelles. GRE est un protocole de tunneling léger qui encapsule une grande variété
de protocoles de la couche réseau dans les liaisons point à point virtuelles sur un réseau
d’interconnexion IP. Pour plus d’informations, consultez Tunneling GRE dans
Windows Server 2016.

Gestion des adresses IP (IPAM)

L’IPAM présente les mises à jour suivantes :

Gestion des adresses IP améliorée L’IPAM a amélioré les capacités pour des
scénarios tels que la gestion des sous-réseaux IPv4 /32 et IPv6 /128 et la recherche
de sous-réseaux et de plages d’adresses IP libres dans un bloc d’adresses IP.

Vous pouvez maintenant exécuter l’applet de commande Find-IpamFreeSubnet

pour rechercher les sous-réseaux disponibles pour l’allocation. Cette fonction
n’alloue pas les sous-réseaux, mais signale uniquement leur disponibilité. Toutefois,
vous pouvez diriger la sortie de l’applet de commande vers l’applet de commande
Add-IpamSubnet pour créer un sous-réseau. Pour plus d'informations, consultez

Find-IpamFreeSubnet.

Vous pouvez maintenant exécuter l’applet de commande Find-IpamFreeRange pour

rechercher les plages d’adresses IP disponibles dans un bloc IP, une longueur de
préfixe et un nombre de sous-réseaux demandés. Cette applet de commande
n’alloue pas la plage d’adresses IP, signale uniquement leur disponibilité. Toutefois,
vous pouvez diriger la sortie vers l’applet de commande AddIpamRange pour créer
la plage. Pour plus d'informations, consultez Find-IpamFreeRange.

Gestion des services DNS améliorée :

Collection d’enregistrements de ressources DNS pour les serveurs DNS non

DNSSEC.

Configuration des propriétés et des opérations sur tous les types

d’enregistrements de ressources non DNSSEC.

Gestion des zones DNS pour les serveurs DNS intégrés dans Active Directory et
les serveurs DNS adossés à des fichiers. Vous pouvez gérer tous les types de
zones DNS, notamment les zones principales, secondaires et de stub.

Déclenchez des tâches sur les zones secondaires et Stub, qu'il s'agisse de zones
de recherche directe ou inversée.

Contrôle d’accès basé sur les rôles pour les configurations DNS prises en charge
pour les enregistrements et les zones.

Redirecteurs conditionnels

Gestion intégrée du service DNS, du protocole DHCP et des adresses IP (DDI). Vous
pouvez maintenant afficher tous les enregistrements de ressources DNS associés à
une adresse IP dans l’inventaire des adresses IP. Vous pouvez également conserver
automatiquement les enregistrements de pointeurs (PTR) des adresses IP et gérer
les cycles de vie des adresses IP pour les opérations DNS et DHCP.

Support pour plusieurs forêts Active Directory. Vous pouvez utiliser l’IPAM pour
gérer les serveurs DNS et DHCP de plusieurs forêts Active Directory lorsqu’il existe
une relation d’approbation bidirectionnelle entre la forêt dans laquelle vous avez
installé l’IPAM et chacune des forêts distantes. Pour en savoir plus, consultez Gérer
les ressources dans plusieurs forêts Active Directory.

La fonctionnalité « Supprimer définitivement les données d’utilisation » vous

permet de réduire la taille de la base de données IPAM en supprimant les
anciennes données d’utilisation IP. Spécifiez simplement une date et l’IPAM
supprime toutes les entrées de base de données antérieures ou égales à la date
que vous avez entrée. Pour plus d'informations, consultez Purger les données
d'utilisation.

Vous pouvez désormais utiliser le contrôle d’accès en fonction du rôle (RBAC) pour
définir des étendues d’accès pour les objets IPAM dans PowerShell. Pour plus
 d'informations, consultez Gérer le contrôle d'accès basé sur les rôles avec Windows
PowerShell et des applets de commande de serveur de gestion des adresses IP
(IPAM) dans Windows PowerShell.

Pour plus d’informations, consultez Gérer IPAM.

Sécurité et assurance
La section Sécurité et assurance contient des fonctionnalités et solutions de sécurité
pour professionnels de l'informatique à déployer dans votre environnement de centre
de données et cloud. Pour plus d’informations générales sur la sécurité dans Windows
Server 2016, consultez Sécurité et assurance.

Administration suffisante
Dans Windows Server 2016, Just Enough Administration est une technologie de sécurité
qui permet de déléguer l’administration de tout ce qui peut être géré avec Windows
PowerShell. Les fonctionnalités disponibles incluent la prise en charge de l’exécution
sous une identité réseau, la connexion par le biais PowerShell Direct, la copie de manière
sécurisée de fichiers vers/depuis des points de terminaison JEA (Just Enough
Administration) et la configuration de la console PowerShell pour un lancement dans un
contexte JEA par défaut. Pour en savoir plus, consultez JEA sur GitHub .

Protection des informations d’identification

La protection des informations d’identification utilise une sécurité basée sur la
virtualisation pour isoler les secrets, afin que seuls les logiciels système privilégiés
puissent y accéder. Pour plus d’informations, consultez la section Protéger les
informations d’identification de domaine dérivées avec Credential Guard.

Credential Guard pour Windows Server 2016 inclut les mises à jour suivantes pour les
sessions utilisateur connectées :

Kerberos et New Technology LAN Manager (NTLM) utilisent la sécurité basée sur la
virtualisation pour protéger les secrets Kerberos et NTLM pour les sessions
utilisateur connectées.

Credential Manager protège les identifiants de domaine enregistrés à l’aide d’une

sécurité basée sur la virtualisation. Les informations d’identification signées et les
informations d’identification de domaine enregistrées ne sont pas transmises aux
hôtes distants utilisant Remote Desktop.
 Vous pouvez activer Credential Guard sans verrou UEFI (Unified Extensible
Firmware Interface).

Credential Guard à distance

Protection des informations d’identification prend en charge les sessions RDP afin que
les informations d’identification de l’utilisateur restent côté client et ne soient pas
exposées côté serveur. Il fournit également l’authentification unique pour Bureau à
distance. Pour plus d’informations, consultez Protéger les informations d’identification
de domaine dérivées avec Windows Defender Credential Guard.

Remote Credential Guard pour Windows Server 2016 inclut les mises à jour suivantes
pour les utilisateurs connectés :

Remote Credential Guard conserve les secrets Kerberos et NTLM des informations
d’identification de l’utilisateur connecté sur l’appareil client. Toute requête
d’authentification de l’hôte distant pour évaluer les ressources du réseau en tant
qu’utilisateur nécessite que l’appareil client utilise les secrets.

Remote Credential Guard protège les informations d’identification fournies par

l’utilisateur lors de l’utilisation du bureau à distance.

Protections de domaine
Les protections de domaine nécessitent désormais un domaine Active Directory.

Prise en charge de l’extension PKInit Freshness

Les clients Kerberos tentent désormais d’utiliser l’extension de fraîcheur PKInit pour les
signatures basées sur les clés publiques.

Les KDC prennent désormais en charge l’extension de fraîcheur PKInit. Cependant, ils ne
proposent pas l’extension de fraîcheur PKInit par défaut.

Pour plus d’informations, consultez Prise en charge du client Kerberos et du centre de

distribution de clés pour l’extension RFC 8070 PKInit Freshness.

Clés publiques propagées uniquement les secrets NTLM

de l’utilisateur
À partir du niveau fonctionnel de domaine (DFL) de Windows Server 2016, les DC
prennent désormais en charge le roulement des secrets NTLM d’un utilisateur à clé
publique uniquement. Cette fonctionnalité n’est pas disponible dans les niveaux de
fonctionnement des domaines inférieurs (DFL).

２ Avertissement

L’ajout d’un DC activé avant la mise à jour du 8 novembre 2016 à un domaine qui
prend en charge les secrets NTLM roulants peut entraîner le plantage du DC.

Pour les nouveaux domaines, cette fonctionnalité est activée par défaut. Pour les
domaines existants, vous devez le configurer dans le Centre administratif Active
Directory.

Dans le Centre administratif Active Directory, cliquez avec le bouton droit de la souris
sur le domaine dans le volet gauche et sélectionnez Propriétés. Cochez la case Activer
le renouvellement des secrets NTLM expirés lors de l’ouverture de session pour les
utilisateurs qui doivent utiliser Windows Hello for Business ou une carte à puce pour
l’ouverture de session interactive. Ensuite, sélectionnez OK pour appliquer cette
modification.

L’autorisation de réseau NTLM lorsqu’un utilisateur est

limité à certains appareils associés à un domaine
Les DC peuvent désormais prendre en charge l’autorisation de NTLM réseau lorsqu’un
utilisateur est limité à des appareils spécifiques joints à un domaine dans la LDF
Windows Server 2016 et les versions ultérieures. Cette fonctionnalité n’est pas
disponible dans les LDF exécutant un système d’exploitation antérieur à Windows Server
2016.

Pour configurer ce paramètre, dans la stratégie d’authentification, sélectionnez

Autoriser l’authentification réseau NTLM lorsque l’utilisateur est limité aux appareils
sélectionnés.

Pour plus d’informations, voir Stratégies d’authentification et silos de stratégies

d’authentification.

Protection de périphérique (intégrité du code)

Protection de périphérique assure l’intégrité du code en mode noyau (KMCI) et en mode
utilisateur (UMCI), en créant des stratégies qui spécifient le code exécutable sur le
serveur. Consultez Introduction à Windows Defender Device Guard : Stratégies
d’intégrité du code et de sécurité basée sur la virtualisation.
Windows Defender
Windows Defender Overview for Windows Server 2016 (Présentation de Windows
Defender pour Windows Server 2016. Windows Server Antimalware est installé et activé
par défaut dans Windows Server 2016, mais pas son interface utilisateur. Toutefois,
Windows Server Antimalware va mettre à jour les définitions de logiciel anti-programme
malveillant et protéger l'ordinateur sans l'interface utilisateur. Si vous avez besoin de
l'interface utilisateur pour Windows Server Antimalware, vous pouvez l'installer après
l'installation du système d'exploitation à l'aide de l'Assistant Ajout de rôles et de
fonctionnalités.

Control Flow Guard

Protection de flux de contrôle est une fonctionnalité de sécurité de plateforme qui a été
créée pour lutter contre les risques de corruption de mémoire. Pour plus d’informations,
consultez Control Flow Guard (Protection du flux de contrôle).

Stockage
Le stockage dans Windows Server 2016 comprend de nouvelles fonctionnalités et
améliorations pour le stockage défini par logiciel et les serveurs de fichiers traditionnels.

Espaces de stockage directs

Les espaces de stockage direct permettent de créer un stockage à haute disponibilité et
scalable en utilisant des serveurs avec un stockage local. Il simplifie le déploiement et la
gestion des systèmes de stockage définis par logiciel et vous permet d'utiliser de
nouvelles classes de périphériques de disque, telles que les disques SSD SATA et les
périphériques de disque NVMe, qui n'étaient pas disponibles auparavant avec les
espaces de stockage en cluster avec des disques partagés.

Pour plus de détails, voir Storage Spaces Direct.

Réplica de stockage
Storage Replica permet une réplication synchrone au niveau des blocs, indépendante du
stockage, entre les serveurs ou les clusters pour la reprise après sinistre, et vous permet
d'étendre un cluster de basculement entre les sites. La réplication synchrone permet la
mise en miroir des données dans des sites physiques avec des volumes cohérents en cas
d’incident, ce qui garantit aucune perte de données au niveau du système de fichiers. La
réplication asynchrone permet l’extension de site au-delà de plages métropolitaines
avec la possibilité de perte de données.

Pour plus d’informations, consultez Storage Replica overview (Présentation du réplica de

stockage).

Qualité de service de stockage

Vous pouvez maintenant utiliser la qualité de service (QoS) de stockage pour analyser
de manière centralisée les performances de stockage de bout en bout et créer des
stratégies de gestion avec Hyper-V et des clusters CSV dans Windows Server 2016.

Pour plus d’informations, consultez Storage Quality of Service (Qualité de service de

stockage).

Déduplication des données

Windows Server 2016 inclut les nouvelles fonctionnalités suivantes pour la déduplication
des données.

Prise en charge de volumes importants

À compter de Windows Server 2016, le pipeline de la tâche de déduplication de

données peut exécuter plusieurs threads en parallèle en utilisant plusieurs files d’attente
d’E/S pour chaque volume. Cette modification permet d’atteindre des niveaux de
performance auparavant uniquement possibles en divisant les données en plusieurs
volumes de taille plus réduite. Ces optimisations s’appliquent à tous les travaux de
déduplication des données, et non uniquement au travail d’optimisation. Le schéma
suivant montre comment le pipeline a changé entre les versions de Windows Server.
Grâce à l’amélioration des performances, sur Windows Server 2016, la déduplication des
données offre des performances élevées sur les volumes jusqu’à 64 To.

Prise en charge des fichiers de grande taille

À compter de Windows Server 2016, la déduplication des données utilise des structures
de mappage de flux et d’autres améliorations pour augmenter les performances de
débit et d’accès de l’optimisation. Le pipeline de traitement de déduplication peut
également reprendre l’optimisation après Des scénarios de basculement au lieu de
recommencer à partir du début. Cette modification améliore les performances des
fichiers jusqu’à 1 To, ce qui permet aux administrateurs d’appliquer des économies de
déduplication à un plus grand nombre de charges de travail, notamment les fichiers
volumineux associés aux charges de travail de sauvegarde.

Prise en charge de Nano Server

Nano Server est une option de déploiement sans affichage dans Windows Server 2016,
qui présente un encombrement des ressources système très faible, démarre beaucoup
plus rapidement et nécessite moins de mises à jour et de redémarrages que l’option de
déploiement de Windows Server principal. De plus, Nano Server prend entièrement en
charge la déduplication des données. Pour en savoir plus sur Nano Server, consultez
Images de base de conteneur.

Configuration simplifiée pour les applications de sauvegarde

virtualisées
À compter de Windows Server 2016, les scénarios de déduplication des données pour
les applications de sauvegarde virtualisées sont considérablement simplifiés. Ce scénario
est désormais une option de type d’utilisation prédéfinie. Vous n’avez plus besoin de
paramétrer manuellement la déduplication, il vous suffit de l’activer pour un volume,
comme vous le feriez pour le serveur de fichiers à usage général et l’infrastructure VDI
(Virtual Desktop Infrastructure).

Prise en charge de la mise à niveau propagée du système

d’exploitation de cluster

Les clusters de basculement Windows Server exécutant la déduplication des données

peuvent comporter un mélange de nœuds qui exécutent des versions de Windows
Server 2012 R2 et de Windows Server 2016 de la déduplication des données. Cette
fonctionnalité de cluster en mode mixte offre un accès complet aux données de tous les
volumes dédupliqués pendant les mises à niveau propagées de cluster. Vous pouvez
désormais déployer progressivement des versions ultérieures des déduplications de
données sur des clusters exécutant des versions antérieures de Windows Server sans
temps d’arrêt.

Vous pouvez également utiliser les mises à jour en continu sur Hyper-V. Avec la mise à
niveau continue d'un cluster Hyper-V, vous pouvez désormais ajouter un nœud
exécutant Windows Server 2019 ou Windows Server 2016 à un cluster Hyper-V avec des
nœuds exécutant Windows Server 2012 R2. Après avoir ajouté le nœud exécutant la
version la plus récente de Windows Server, vous pouvez mettre à niveau le reste du
cluster sans interruption de service. Le cluster s'exécute à un niveau de fonctionnalité
Windows Server 2012 R2 jusqu'à ce que vous mettiez à niveau tous les nœuds du cluster
et que vous exécutiez Update-ClusterFunctionalLevel dans PowerShell pour mettre à
jour le niveau de fonctionnement du cluster. Pour des instructions plus détaillées sur le
fonctionnement du processus de mise à niveau continue, voir Mise à niveau continue du
système d'exploitation de cluster.

７ Notes

Hyper-V sur Windows 10 ne prend pas en charge le clustering de basculement.

Améliorations de la sécurisation renforcée SMB pour les

connexions SYSVOL et NETLOGON
Dans Windows 10 et Windows Server 2016, les connexions des clients aux services de
domaine Active Directory utilisaient par défaut les partages SYSVOL et NETLOGON sur
les contrôleurs de domaine. Désormais, ces connexions nécessitent une signature SMB
et une authentification mutuelle à l'aide de services tels que Kerberos. Si la signature
SMB et l’authentification mutuelle ne sont pas disponibles, un ordinateur Windows 10
ou Windows Server 2016 ne peut pas traiter les scripts ni la stratégie de groupe basés
sur un domaine. Cette modification protège les périphériques contre les attaques de
type "adversary-in-the-middle".

７ Notes

Les valeurs de registre pour ces paramètres ne sont pas présentes par défaut, mais
les règles de durcissement s'appliquent toujours jusqu'à ce que vous les remplaciez
en modifiant la stratégie de groupe ou d'autres valeurs de registre.

Pour plus d'informations sur ces améliorations de sécurité, voir MS15-011 : Vulnérabilité
dans la stratégie de groupe et MS15-011 & MS15-014 : Durcissement de la stratégie
de groupe .

Dossiers de travail
Windows Server 2016 propose une notification de changement améliorée lorsque le
serveur Work Folders exécute Windows Server 2016 et que le client Work Folders est
Windows 10. Lorsque des modifications de fichiers se synchronisent sur le serveur Work
Folders, le serveur en informe désormais immédiatement les clients Windows 10, puis
synchronise les modifications de fichiers.

ReFS
La nouvelle version de ReFS permet de réaliser des déploiements de stockage à grande
échelle avec diverses charges de travail, offrant ainsi plus de fiabilité, de résilience et
d'extensibilité pour vos données.

ReFS offre les améliorations suivantes :

Nouvelle fonctionnalité de niveau de stockage, offrant des performances plus

rapides et une capacité de stockage accrue, notamment les éléments suivants :

Plusieurs types de résilience sur le même disque virtuel en utilisant la mise en

miroir dans le niveau de performance et la parité dans le niveau de capacité.

Meilleure réactivité pour les dérives de plages de travail.

 Introduit le clonage de blocs pour améliorer les performances des opérations de
machines virtuelles, telles que les opérations de fusion de points de contrôle
.vhdx .

Un nouvel outil d'analyse ReFS qui peut vous aider à récupérer les espaces de
stockage perdus et à sauver les données des corruptions critiques.

Clustering de basculement
Windows Server 2016 inclut de nombreuses nouvelles fonctionnalités et améliorations
pour plusieurs serveurs regroupés dans un cluster à tolérance de panne, à l’aide de la
fonctionnalité Clustering avec basculement.

Mise à niveau propagée de système d’exploitation de

cluster
La mise à niveau propagée de système d’exploitation de cluster permet à un
administrateur de mettre à niveau le système d’exploitation des nœuds de cluster
Windows Server 2012 R2 vers Windows Server 2016, sans arrêter les charges de travail
du serveur de fichiers avec scale-out ni Hyper-V. Vous pouvez utiliser cette
fonctionnalité pour éviter les pénalités de temps d’arrêt sur les contrats de niveau de
service (SLA).

Pour plus d’informations, consultez Mise à niveau propagée du système d’exploitation

de cluster.

Témoin cloud
Dans Windows Server 2016, Témoin cloud est un nouveau type de témoin de quorum de
cluster avec basculement, qui utilise Microsoft Azure comme point d’arbitrage. Comme
n’importe quel autre témoin de quorum, le témoin cloud obtient un vote et peut être
utilisé dans les calculs de quorum. Vous pouvez le configurer comme témoin de quorum
à l’aide de l’Assistant Configuration de quorum du cluster.

Pour plus d’informations, consultez Déployer un témoin de cloud pour un cluster de

basculement.

Résilience des machines virtuelles

Windows Server 2016 inclut une résilience de calcul accrue des machines virtuelles (VM)
pour réduire les problèmes de communication intracluster dans votre cluster de calcul.
Cette résilience accrue comprend les mises à jour suivantes :

Vous pouvez désormais configurer les options suivantes pour définir la façon dont
les machines virtuelles doivent se comporter pendant les défaillances temporaires :

Le niveau de résilience définit la façon dont votre déploiement doit gérer les
défaillances temporaires.

La période de résilience définit la durée pendant laquelle toutes les machines

virtuelles sont autorisées à s’exécuter de manière isolée.

Les nœuds non sains sont mis en quarantaine et ne sont plus autorisés à rejoindre
le cluster. Cette fonctionnalité empêche les nœuds non sains d’affecter
négativement les autres nœuds et l’ensemble du cluster.

Pour en savoir plus sur les fonctionnalités de résilience de calcul, consultez Résilience de
calcul des machines virtuelles dans Windows Server 2016 .

Les machines virtuelles Windows Server 2016 incluent également de nouvelles

fonctionnalités de résilience de stockage pour gérer les défaillances de stockage
temporaires. L’amélioration de la résilience permet de préserver les états de session de
la machine virtuelle du locataire en cas d’interruption du stockage. Lorsqu’une machine
virtuelle se déconnecte de son stockage sous-jacent, elle se met en pause et attend le
rétablissement du stockage. Pendant qu’elle est en pause, la machine virtuelle conserve
le contexte des applications qui s’y exécutaient au moment de la défaillance du
stockage. Lorsque la connexion entre la machine virtuelle et le stockage est restaurée, la
machine virtuelle retourne à son état d’exécution. Par conséquent, l’état de session de la
machine du locataire est conservé pendant la récupération.

Les nouvelles fonctionnalités de résilience du stockage s’appliquent également aux

clusters invités.

Améliorations apportées au diagnostic

Pour vous aider à diagnostiquer les problèmes liés aux clusters de basculement,
Windows Server 2016 comprend les éléments suivants :

Plusieurs améliorations apportées aux fichiers journaux du cluster, comme les

informations sur le fuseau horaire et le journal DiagnosticVerbose, facilitent la
résolution des problèmes de clustering de basculement. Pour plus d’informations,
consultez Windows Server 2016 Failover Cluster Troubleshooting Enhancements -
Cluster Log .
 Un nouveau type de vidage de mémoire active filtre la plupart des pages de la
mémoire allouées aux machines virtuelles, ce qui réduit considérablement la taille
du fichier [Link] et facilite son enregistrement ou sa copie. Pour plus
d’informations, consultez Windows Server 2016 Failover Cluster Troubleshooting
Enhancements - Active Dump .

Clusters de basculement reconnaissant les sites

Windows Server 2016 inclut des clusters de basculement reconnaissant les sites qui
activent les nœuds de groupe dans les clusters étendus en fonction de leur
emplacement physique ou du site. La reconnaissance des sites par les clusters améliore
les opérations clés pendant le cycle de vie du cluster, comme le comportement de
basculement, les stratégies de placement, les pulsations entre les nœuds et le
comportement du quorum. Pour plus d’informations, consultez Site-aware Failover
Clusters in Windows Server 2016 .

Clusters de groupes de travail et à domaines multiples

Dans Windows Server 2012 R2 et les versions antérieures, un cluster peut uniquement
être créé entre des nœuds membres joints au même domaine. Windows Server 2016
déjoue cet obstacle en introduisant la possibilité de créer un cluster de basculement
sans dépendances Active Directory. Vous pouvez maintenant créer des clusters de
basculement dans les configurations suivantes :

Clusters à domaine unique, dont tous leurs nœuds sont rattachés au même
domaine.

Clusters à domaines multiples, dont les nœuds appartiennent à différents

domaines.

Clusters de groupe de travail, dont les nœuds sont des serveurs membres ou des
groupes de travail qui ne sont pas rattachés à un domaine.

Pour plus d’informations, consultez Workgroup and Multi-domain clusters in Windows

Server 2016

Équilibrage de charge des machines virtuelles

L’équilibrage de charge de machine virtuelle est une nouvelle fonctionnalité du
clustering de basculement qui équilibre de manière transparente la charge des machines
virtuelles sur les nœuds d’un cluster. La fonctionnalité identifie les nœuds trop sollicités
en fonction de la mémoire de la machine virtuelle et de l’utilisation du processeur sur le
nœud. Elle migre ensuite les machines virtuelles du nœud trop sollicité vers des nœuds
avec une bande passante disponible. Vous pouvez ajuster le degré auquel la
fonctionnalité équilibre les nœuds pour garantir des performances et une utilisation
optimales du cluster. L’équilibrage de charge est activé par défaut dans la préversion
technique de Windows Server 2016. Toutefois, l’équilibrage de charge est désactivé
quand l’optimisation dynamique SCVMM est activée.

Ordre de démarrage des machines virtuelles

L’ordre de démarrage de la machine virtuelle est une nouvelle fonctionnalité du
clustering de basculement qui introduit l’orchestration de l’ordre de démarrage pour les
machines virtuelles et les autres groupes d’un cluster. Vous pouvez désormais regrouper
des machines virtuelles en niveaux, puis créer des dépendances d’ordre de démarrage
entre différents niveaux. Ces dépendances garantissent que les machines virtuelles les
plus importantes, telles que les contrôleurs de domaine ou les machines virtuelles
d’utilitaire, démarrent en premier. Les machines virtuelles de niveau de priorité inférieur
ne démarrent qu’après le démarrage des machines virtuelles dont elles dépendent.

Réseaux de clusters à plusieurs cartes réseau et SMB

Multichannel simplifiés
Les réseaux de cluster de basculement ne sont plus limités à une seule carte d’interface
réseau (NIC) par sous-réseau ou réseau. Avec les réseaux de clusters simplifiés Server
Message Block (SMB) multicanaux et multi-NIC, la configuration du réseau est
automatique et chaque NIC du sous-réseau peut être utilisée pour le trafic des clusters
et des charges de travail. Cette amélioration permet aux clients d’optimiser le débit
réseau pour l’instance de cluster de basculement SQL Server, Hyper-V et d’autres
charges de travail SMB.

Pour plus d’informations, consultez Réseaux de cluster SMB Multichannel et multi-carte

réseau simplifiés.

Développement d’applications

Services IIS (Internet Information Services) 10.0

Les nouvelles fonctionnalités fournies par le serveur web IIS 10.0 dans Windows
Server 2016 sont notamment les suivantes :
 Prise en charge du protocole HTTP/2 dans la pile Gestion de réseau et intégration
à IIS 10.0, ce qui permet aux sites web IIS 10.0 de traiter automatiquement les
requêtes HTTP/2 pour les configurations prises en charge. Cette évolution apporte
de nombreuses améliorations comparé à HTTP/1.1, comme une réutilisation plus
efficace des connexions et une moindre latence, ce qui améliore les temps de
chargement des pages web.
Possibilité d’exécuter et de gérer IIS 10.0 dans Nano Server. Consultez IIS sur
Nano Server.
Prise en charge des en-têtes d’hôte génériques, permettant aux administrateurs de
configurer un serveur web pour un domaine de manière à ce qu’il traite les
requêtes de tout sous-domaine.
Un nouveau module PowerShell (IISAdministration) pour la gestion des services IIS.

Pour plus d'informations, consultez IIS .

Distributed Transaction Coordinator (MSDTC)

Trois nouvelles fonctionnalités ont été ajoutées dans Microsoft Windows 10 et Windows
Server 2016 :

Une nouvelle interface pour la méthode Rejoin de Resource Manager peut être
utilisée par un gestionnaire de ressources pour déterminer le résultat d’une
transaction incertaine après le redémarrage d’une base de données en raison
d’une erreur. Pour plus d’informations, consultez
IResourceManagerRejoinable::Rejoin.

La limite des noms de source de données (DSN) a été étendue de 256 octets à
3 072 octets. Pour plus d’informations, consultez IDtcToXaHelperFactory::Create,
IDtcToXaHelperSinglePipe::XARMCreate ou
IDtcToXaMapper::RequestNewResourceManager.

Suivi amélioré, qui vous permet de définir une clé de Registre de manière à inclure
un chemin de fichier image dans le nom de fichier Tracelog pour simplifier
l’identification du Tracelog à vérifier. Pour plus d’informations sur la configuration
du suivi pour MSDTC, consultez Guide pratique pour activer le suivi de diagnostic
pour MSDTC sur un ordinateur Windows .

Serveur DNS
Windows Server 2016 contient les mises à jour suivantes pour le serveur DNS (Domain
Name System).
Stratégies DNS
Vous pouvez configurer des stratégies DNS pour spécifier la façon dont un serveur DNS
répond aux requêtes DNS. Vous pouvez configurer les réponses DNS en fonction de
l’adresse IP du client, de l’heure de la journée et de plusieurs autres paramètres. Les
stratégies DNS peuvent activer le DNS qui prend en charge la géolocalisation, la gestion
du trafic, l’équilibrage de charge, le DNS split-brain et d’autres scénarios. Pour plus
d’informations, consultez le Guide de scénario de stratégie DNS.

RRL
Vous pouvez activer la limitation du taux de réponse (RRL) sur vos serveurs DNS pour
empêcher les systèmes malveillants de les utiliser pour lancer une attaque par déni de
service distribué (DDoS) sur un client DNS. La RRL empêche votre serveur DNS de
répondre à trop de requêtes en même temps, ce qui le protège lors des scénarios où un
botnet envoie plusieurs requêtes à la fois pour tenter d’interrompre les opérations du
serveur.

Prise en charge de DANE

Vous pouvez utiliser l’authentification d'entités nommées basée sur le DNS (DANE)
(RFC 6394 et RFC 6698 ) pour spécifier l’autorité de certification à partir de laquelle
vos clients DNS doivent attendre des certificats pour les noms de domaine hébergés sur
votre serveur DNS. Cela permet d’éviter les attaques de type attaque de l’intercepteur
où un acteur malveillant corrompt un cache DNS et pointe un nom DNS vers sa propre
adresse IP.

Prise en charge des enregistrements inconnus

Vous pouvez ajouter des enregistrements que le serveur DNS ne prend pas
explicitement en charge à l’aide de la fonctionnalité d’enregistrement inconnu. Un
enregistrement est inconnu lorsque le serveur DNS ne reconnaît pas son format RDATA.
Windows Server 2016 prend en charge les types d’enregistrements inconnus
(RFC 3597 ), ce qui vous permet d’ajouter des enregistrements inconnus aux zones de
serveur DNS Windows au format filaire binaire. Le programme de résolution de mise en
cache Windows peut déjà traiter des types d’enregistrements inconnus. Le serveur DNS
Windows n’effectue pas de traitement spécifique à l’enregistrement pour les
enregistrements inconnus, mais peut les envoyer en réponse aux requêtes qu’il reçoit.

Indicateurs racine IPv6

Le serveur DNS Windows inclut désormais des indications de racine IPv6 publiées par
l’IANA (Internet Assigned Numbers Authority). La prise en charge des indications de
racine IPv6 vous permet d’effectuer des requêtes Internet qui utilisent les serveurs racine
IPv6 pour effectuer des résolutions de noms.

Prise en charge de Windows PowerShell

Windows Server 2016 inclut de nouvelles commandes que vous pouvez utiliser pour
configurer DNS dans PowerShell. Pour plus d’informations, consultez le module
DnsServer de Windows Server 2016 et le module DnsClient de Windows Server 2016.

Support Nano Server pour le service DNS basé sur les

fichiers
Vous pouvez déployer des serveurs DNS dans Windows Server 2016 sur une image
Nano Server. Cette option de déploiement est disponible si vous utilisez un DNS basé
sur les fichiers. En exécutant un serveur DNS sur une image Nano Server, vous pouvez
exécuter vos serveurs DNS avec une réduction de l’encombrement, un démarrage rapide
et un minimum de correctifs.

７ Notes

Le service DNS intégré à Active Directory n’est pas pris en charge sur Nano Server.

Client DNS
Le service client DNS offre désormais une prise en charge améliorée des ordinateurs
dotés de plusieurs interfaces réseau.

Les ordinateurs multirésidents peuvent également utiliser la liaison du service client DNS
pour améliorer la résolution du serveur :

Lorsque vous utilisez un serveur DNS configuré sur une interface spécifique pour
résoudre une requête DNS, le client DNS se lie à l'interface avant d'envoyer la
requête. Cette liaison permet au client DNS de spécifier l'interface où la résolution
de nom doit avoir lieu, optimisant ainsi les communications entre les applications
et le client DNS sur l'interface réseau.

Si le serveur DNS que vous utilisez a été désigné par un paramètre de stratégie de
groupe de la table de stratégie de résolution de noms (NRPT), le service client DNS
 ne se lie pas à l'interface spécifiée.

７ Notes

Les modifications apportées au service client DNS dans Windows 10 sont

également présentes dans les ordinateurs exécutant Windows Server 2016 et les
versions ultérieures.

Services Bureau à distance

Services Bureau à distance (RDS) a apporté les modifications suivantes pour Windows
Server 2016.

Compatibilité des applications

RDS et Windows Server 2016 sont compatibles avec de nombreuses applications
Windows 10, créant une expérience utilisateur presque identique à celle d’un bureau
physique.

Azure SQL Database

Le service Broker pour les connexions Bureau à distance (RD) peut désormais stocker
toutes les informations de déploiement, telles que les états de connexion et les
associations utilisateur-hôte, dans une base de données SQL Azure structurée partagée.
Cette fonctionnalité vous permet d’utiliser un environnement à haute disponibilité sans
avoir à utiliser un groupe de disponibilité Always On de SQL Server. Pour plus
d’informations, veuillez consulter la rubrique Utilisation d’Azure SQL DB pour votre
environnement haute disponibilité du Service Broker pour les connexions Bureau à
distance .

Améliorations graphiques
L’affectation de périphériques discrets pour Hyper-V vous permet de mapper
directement les unités de traitement graphique (GPU) sur une machine hôte à une
machine virtuelle (VM). Toutes les applications sur la VM qui nécessitent plus de GPU
que ce que la VM peut fournir peuvent utiliser la GPU mappée à la place. Nous avons
également amélioré le vGPU RemoteFX, y compris la prise en charge d’OpenGL 4.4,
d’OpenCL 1.1, de la résolution 4K et des VM Windows Server. Pour plus d’informations,
veuillez consulter la rubrique Affectation de périphériques discrets .
Améliorations du Broker pour les connexions de Bureau à
Distance
Nous avons amélioré la façon dont le Broker pour les connexions RD gère les
connexions pendant les tempêtes de connexion, qui sont des périodes de demandes
d’inscription élevées des utilisateurs. Le Broker pour les connexions RD peut désormais
gérer plus de 10 000 demandes d’inscription simultanées ! Les améliorations de la
maintenance facilitent également la réalisation de la maintenance sur votre déploiement
en vous permettant de réintégrer rapidement les serveurs dans l’environnement une fois
qu’ils sont prêts à être remis en ligne. Pour plus d’informations, veuillez consulter la
section Amélioration des performances du Broker pour les connexions Bureau à
distance .

Modifications du protocole RDP 10

Le protocole Bureau à distance (RDP) 10 utilise désormais le codec H.264/AVC 444, ce
qui optimise à la fois la vidéo et le texte. Cette version inclut également la prise en
charge de la saisie au stylet. Ces nouvelles fonctionnalités permettent à votre session à
distance de se rapprocher davantage d’une session locale. Pour plus d’informations,
veuillez consulter la section Améliorations RDP 10 AVC/H.264 dans Windows 10 et
Windows Server 2016 .

Personal session desktops

Personal session desktops est une nouvelle fonctionnalité qui vous permet d’héberger
votre propre bureau personnel dans le cloud. Les privilèges administratifs et les hôtes de
session dédiés éliminent la complexité des environnements d’hébergement où les
utilisateurs souhaitent gérer un bureau à distance comme un bureau local. Pour plus
d’informations, veuillez consulter la rubrique Personal Session Desktops.

Authentification Kerberos
Windows Server 2016 inclut les mises à jour suivantes pour l’authentification Kerberos.

Prise en charge du centre de distribution de clés (KDC)

pour l’authentification cliente basée sur l’approbation de
clé publique
Les centres de distribution de clés (KDC) prennent désormais en charge le mappage des
clés publiques. Si vous provisionnez une clé publique pour un compte, le KDC prend en
charge Kerberos PKInit explicitement à l’aide de cette clé. Étant donné qu’il n’y a pas de
validation de certificat, Kerberos prend en charge les certificats auto-signés, mais pas la
garantie du mécanisme d’authentification.

Les comptes que vous avez configurés pour utiliser l’approbation de clé utilisent
uniquement l’approbation de clé, quelle que soit la façon dont vous avez configuré le
paramètre UseSubjectAltName.

Prise en charge du client Kerberos et du KDC pour

l’extension RFC 8070 PKInit Freshness
À partir de Windows 10, version 1607 et Windows Server 2016, les clients Kerberos
peuvent utiliser l’extension RFC 8070 PKInit Freshness pour les connexions basées sur
des clés publiques. Par défaut, l’extension PKInit Freshness est désactivée pour vous
permettre de configurer la prise en charge du KDC pour la stratégie des modèles
d’administration du KDC de l'extension PKInit Freshness sur tous les contrôleurs de
domaine de votre domaine.

La stratégie a les paramètres suivants disponibles lorsque votre domaine se trouve dans
le niveau fonctionnel du domaine (DFL) de Windows Server 2016 :

Désactivé : le KDC n’offre jamais l’extension PKInit Freshness et accepte les

demandes d’authentification valides sans vérifier l’actualisation. Les utilisateurs ne
reçoivent pas le SID d’identité de clé publique actualisé.
Prise en charge : Kerberos prend en charge l’extension PKInit Freshness sur
demande. Les clients Kerberos qui sont authentifiés avec l’extension PKInit
Freshness reçoivent le SID d’identité de clé publique actualisé.
Obligatoire : l’extension PKInit Freshness est requise pour une authentification
réussie. Les clients Kerberos qui ne prennent pas en charge l’extension PKInit
Freshness échoueront toujours lors de l’utilisation d’informations d’identification
de clé publique.

Prise en charge des appareils joints à un domaine pour

l’authentification à l’aide d’une clé publique
Si un appareil joint à un domaine peut enregistrer sa clé publique liée auprès d’un
contrôleur de domaine (DC) Windows Server 2016, il peut alors s’authentifier avec la clé
publique à l’aide de l’authentification Kerberos PKInit auprès d’un DC Windows Server
2016.
Les appareils joints à un domaine avec des clés publiques liées enregistrées auprès d’un
contrôleur de domaine Windows Server 2016 peuvent désormais s’authentifier auprès
d’un contrôleur de domaine Windows Server 2016 à l’aide des protocoles Kerberos de
chiffrement à clé publique pour l’authentification initiale (PKInit). Pour plus
d’informations, consultez Authentification par clé publique d’appareil joint au domaine.

Les centres de distribution de clés (KDC) prennent désormais en charge

l’authentification à l’aide de la confiance de clé Kerberos.

Pour plus d’informations, consultez Prise en charge du centre de distribution de clés

pour le mappage de comptes à approbation de clé.

Les clients Kerberos autorisent les noms d’hôte d’adresses

IPv4 et IPv6 dans les noms de principaux de service (SPN)
À partir de Windows 10 version 1507 et Windows Server 2016, vous pouvez configurer
les clients Kerberos pour qu'ils prennent en charge les noms d’hôte IPv4 et IPv6 dans les
SPN. Pour plus d’informations, consultez Configuration de Kerberos pour les adresses IP.

Pour configurer la prise en charge des noms d’hôte d’adresses IP dans les SPN, créez
une entrée TryIPSPN. Par défaut, cette entrée n’existe pas dans le Registre. Vous devez
placer cette entrée sur le chemin suivant :

text

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Para
meters

Après avoir créé l’entrée, remplacez sa valeur DWORD par 1. Si cette valeur n’est pas
configurée, Kerberos ne fait pas de tentative de noms d’hôte d’adresses IP.

L’authentification Kerberos ne réussit que si le SPN est inscrit dans Active Directory.

Prise en charge du KDC pour le mappage de compte

d’approbation de clé
Les contrôleurs de domaine prennent désormais en charge le mappage des comptes à
approbation de clés et le remplacement vers AltSecID et UPN (User Principal Name)
existants dans le comportement SAN. Vous pouvez configurer la variable
UseSubjectAltName sur les paramètres suivants :
 Paramétrer la variable sur 0 rend le mappage explicite obligatoire. Les utilisateurs
doivent utiliser une approbation de clé ou définir une variable ExplicitAltSecID.

Paramétrer la variable sur 1, qui est la valeur par défaut, autorise le mappage
implicite.

Si vous configurez une approbation de clé pour un compte dans Windows

Server 2016 ou version ultérieure, le KDC utilise KeyTrust pour le mappage.

S’il n’y a pas d’UPN dans le SAN, le KDC tente d’utiliser AltSecID pour le
mappage.

S’il y a un UPN dans le SAN, le KDC tente d’utiliser l’UPN pour le mappage.

Active Directory Federation Services (AD FS)

AD FS pour Windows Server 2016 contient les mises à jour suivantes.

Se connecter avec l’authentification multi-facteur

Microsoft Entra
AD FS 2016 s’appuie sur les fonctionnalités d’authentification multifacteur (MFA) d’AD
FS dans Windows Server 2012 R2. Vous pouvez désormais autoriser l’authentification qui
nécessite uniquement un code d’authentification multifacteur Microsoft Entra au lieu
d’un nom d’utilisateur ou d’un mot de passe.

Lorsque vous configurez l’authentification multifacteur Microsoft Entra en tant que

méthode d’authentification principale, AD FS invite l’utilisateur à saisir son nom
d’utilisateur et le code de mot de passe à usage unique (OTP) de l’application
Azure Authenticator.

Lorsque vous configurez l’authentification multifacteur Microsoft Entra en tant que

méthode d’authentification secondaire ou supplémentaire, l’utilisateur fournit des
informations d’identification d’authentification principales. Les utilisateurs peuvent
se connecter à l’aide de l’authentification intégrée Windows, qui peut leur
demander leur nom d’utilisateur et leur mot de passe, leur carte à puce ou un
certificat d’utilisateur ou d’appareil. Ensuite, les utilisateurs sont invités à fournir
leurs informations d’identification secondaires, telles que l’authentification
multifacteur Microsoft Entra basée sur le texte, la voix ou l’OTP.

La nouvelle carte d’authentification multifacteur Microsoft Entra intégrée offre un

paramétrage et une configuration plus simples pour l’authentification multifacteur
Microsoft Entra avec AD FS.
 Les organisations peuvent utiliser l’authentification multifacteur Microsoft Entra
sans disposer d’un serveur d’authentification multifacteur Microsoft Entra local.

Vous pouvez configurer l’authentification multifacteur Microsoft Entra pour un

intranet, un extranet ou dans le cadre d’une stratégie de contrôle d’accès.

Pour en savoir plus sur l’authentification multifacteur Microsoft Entra avec AD FS,
consultez Configurer AD FS 2016 et l’authentification multifacteur Microsoft Entra.

Accès sans mot de passe à partir des appareils conformes

AD FS 2016 s’appuie sur les fonctionnalités d’inscription d’appareils précédentes pour
activer l’authentification et le contrôle d’accès en fonction de l’état de conformité des
appareils. Les utilisateurs peuvent se connecter à l’aide des informations d’identification
de l’appareil, et AD FS réévalue la conformité quand les attributs de l’appareil changent
afin de garantir l’application des stratégies. Cette fonctionnalité active les stratégies
suivantes :

Activez l’accès uniquement à partir d’appareils managés et/ou conformes.

Activez l’accès extranet uniquement à partir d’appareils managés et/ou conformes.

Exiger l’authentification multifacteur pour les ordinateurs qui ne sont pas managés
ou sont non conformes.

AD FS fournit le composant local des stratégies d’accès conditionnel dans un scénario

hybride. Quand vous inscrivez des appareils auprès d’Azure AD pour l’accès conditionnel
aux ressources cloud, vous pouvez aussi utiliser l’identité de l’appareil pour les stratégies
AD FS.
Pour plus d’informations sur l’utilisation de l’accès conditionnel basé sur l’appareil dans
le cloud, consultez Accès conditionnel Azure Active Directory.

Pour en savoir plus sur l’utilisation de l’accès conditionnel basé sur les appareils avec AD
FS, consultez Planification de l’accès conditionnel basé sur l’appareil avec AD FS et
Stratégies de contrôle d’accès dans AD FS.

Se connecter avec Windows Hello Entreprise

Les appareils Windows 10 contiennent Windows Hello et Windows Hello Entreprise, qui
remplacent les mots de passe utilisateur par des informations d’identification de
l’utilisateur puissantes, protégées par un mouvement de l’utilisateur (un code
confidentiel, un mouvement biométrique comme une empreinte digitale ou une
reconnaissance faciale). Avec Windows Hello, les utilisateurs peuvent se connecter à des
applications AD FS à partir d’un intranet ou d’un extranet sans nécessiter de mot de
passe.

Pour plus d’informations sur l’utilisation de Windows Hello Entreprise dans votre
organisation, consultez Activer Windows Hello Entreprise dans votre organisation.

Authentification moderne
AD FS 2016 prend en charge les protocoles modernes les plus récents qui offrent une
meilleure expérience utilisateur pour Windows 10 et les appareils et applications iOS et
Android les plus récents.
Pour plus d’informations, consultez Scénarios AD FS pour les développeurs.

Configurer des stratégies de contrôle d’accès sans avoir à

connaître le langage de règles de revendication
Avant, les administrateurs AD FS devaient configurer des stratégies en utilisant le
langage de règles de revendication AD FS, ce qui compliquait la configuration et la
maintenance des stratégies. Avec les stratégies de contrôle d’accès, les administrateurs
peuvent utiliser des modèles intégrés pour appliquer des stratégies courantes. Par
exemple, vous pouvez utiliser des modèles pour appliquer les stratégies suivantes :

Autoriser l’accès intranet uniquement.

Autoriser tout le monde et exiger l’authentification MFA à partir de l’extranet.

Autoriser tout le monde et exiger l’authentification MFA pour un groupe

spécifique.

Les modèles sont faciles à personnaliser. Vous pouvez appliquer des exceptions ou des
règles de stratégie supplémentaires, et appliquer ces modifications à une ou plusieurs
applications pour une mise en œuvre cohérente de la stratégie.

Pour plus d’informations, consultez Stratégies de contrôle d’accès dans AD FS.

Activer l’authentification avec des annuaires LDAP non-

Active Directory
De nombreuses organisations combinent Active Directory et des annuaires tiers. Avec la
prise en charge dans AD FS de l’authentification des utilisateurs stockés dans des
annuaires compatibles Lightweight Directory Access Protocol (LDAP) v3, vous pouvez
désormais utilisé AD FS dans les scénarios suivants :

Les utilisateurs d’annuaires tiers compatibles LDAP v3.

Les utilisateurs des forêts Active Directory pour lesquelles aucune approbation
bidirectionnelle Active Directory n’est configurée.

Les utilisateurs des services AD LDS (Active Directory Lightweight Directory

Services).

Pour plus d'informations, voir Configure AD FS to authenticate users stored in LDAP

directories.
Personnaliser l’expérience de connexion pour les
applications AD FS
Avant, AD FS dans Windows Server 2012 R2 offrait une expérience d’authentification
commune pour toutes les applications par partie de confiance, avec la possibilité de
personnaliser un sous-ensemble de contenu textuel par application. Avec Windows
Server 2016, vous pouvez personnaliser non seulement les messages, mais aussi les
images, le logo et le thème web par application. Vous pouvez aussi créer des thèmes
web personnalisés et appliquer ces thèmes par partie de confiance.

Pour plus d’informations, consultez Personnalisation de la connexion utilisateur AD FS.

Audit rationalisé pour faciliter la gestion administrative

Dans les versions précédentes d’AD FS, une seule requête pouvait générer de nombreux
événements d’audit. Les informations pertinentes sur les activités de connexion ou
d’émission de jetons étaient souvent absentes ou réparties sur plusieurs événements
d’audit, ce qui compliquait le diagnostic des problèmes. Ainsi, les événements d’audit
étaient désactivés par défaut. Toutefois, dans AD FS 2016, le processus d’audit est plus
rationalisé et les informations pertinentes sont plus faciles à trouver. Pour plus
d’informations, consultez Améliorations de l’audit apportées à AD FS dans Windows
Server 2016.

Amélioration de l’interopérabilité avec SAML 2.0 pour la

participation aux confédérations
AD FS 2016 offre davantage de prise en charge du protocole SAML, notamment la prise
en charge de l’importation des approbations basées sur des métadonnées contenant
plusieurs entités. Ce changement vous permet de configurer AD FS pour participer à des
confédérations telles que la fédération InCommon et d’autres implémentations
conformes à la norme eGov 2.0.

Pour plus d’informations, consultez Interopérabilité améliorée avec SAML 2.0.

Gestion simplifiée des mots de passe pour les utilisateurs

Microsoft 365 fédérés
Vous pouvez configurer AD FS pour envoyer des revendications d’expiration de mot de
passe à toutes les approbations ou applications de partie de confiance qu’il protège. La
façon dont ces revendications apparaissent varie selon les applications. Par exemple,
avec Office 365 comme partie de confiance, des mises à jour ont été implémentées dans
Exchange et Outlook pour informer les utilisateurs fédérés de l’expiration prochaine de
leurs mots de passe.

Pour plus d’informations, consultez Configurer AD FS pour envoyer les revendications

d’expiration de mot de passe.

Simplification du passage d’AD FS dans Windows

Server 2012 R2 à AD FS dans Windows Server 2016
Auparavant, la migration vers une nouvelle version d’AD FS nécessitait l’exportation des
paramètres de configuration à partir de votre batterie Windows Server vers une nouvelle
batterie de serveurs parallèle. AD FS sur Windows Server 2016 facilite le processus en
supprimant l’obligation de disposer d’une batterie de serveurs parallèles. Lorsque vous
ajoutez un serveur Windows Server 2016 à une batterie de serveurs Windows
Server 2012 R2, le nouveau serveur se comporte comme un serveur Windows
Server 2012 R2. Lorsque vous êtes prêt à effectuer une mise à niveau et que vous avez
supprimé les serveurs plus anciens, vous pouvez passer au niveau opérationnel
Windows Server 2016. Pour plus d’informations, consultez Mise à niveau vers AD FS
dans Windows Server 2016.

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Vue d’ensemble de Credential Guard
Article • 21/06/2024 •
S’applique ✅ Windows 11, ✅ Windows 10, ✅ Windows Server 2022, ✅ Windows Server 2019,
à: ✅ Windows Server 2016

Credential Guard empêche les attaques de vol d’informations d’identification en

protégeant les hachages de mot de passe NTLM, les tickets d’octroi de tickets Kerberos
(TGT) et les informations d’identification stockées par les applications en tant
qu’informations d’identification de domaine.

Credential Guard utilise la sécurité basée sur la virtualisation (VBS) pour isoler les secrets
afin que seuls les logiciels système privilégiés puissent y accéder. L’accès non autorisé à
ces secrets peut entraîner des attaques de vol d’informations d’identification, comme
passer le hachage et transmettre le ticket.

Lorsqu’elle est activée, Credential Guard offre les avantages suivants :

Sécurité matérielle : NTLM, Kerberos et Credential Manager tirent parti des

fonctionnalités de sécurité de la plateforme, notamment le démarrage sécurisé et
la virtualisation, pour protéger les informations d’identification
Sécurité basée sur la virtualisation : NTLM, les informations d’identification
dérivées de Kerberos et d’autres secrets s’exécutent dans un environnement
protégé isolé du système d’exploitation en cours d’exécution
Protection contre les menaces persistantes avancées : lorsque les informations
d’identification sont protégées à l’aide de VBS, les techniques et outils d’attaque
de vol d’informations d’identification utilisés dans de nombreuses attaques ciblées
sont bloqués. Les programmes malveillants s’exécutant dans le système
d’exploitation avec des privilèges d’administration ne peuvent pas extraire les
secrets protégés par VBS

７ Notes

Bien que Credential Guard soit une solution d’atténuation puissante, les attaques
par menaces persistantes seront probablement déplacées vers de nouvelles
techniques d’attaque, et vous devez également incorporer d’autres stratégies et
architectures de sécurité.

Activation par défaut

 ） Important

Windows Server 2025 est en préversion. Ces informations concernent un produit de

préversion qui peut être considérablement modifié avant sa publication. Microsoft
n’offre aucune garantie, expresse ou implicite, concernant les informations fournies
ici.

À compter de Windows 11, 22H2 et Windows Server 2025 (préversion), VBS et

Credential Guard sont activés par défaut sur les appareils qui répondent aux exigences.

L’activation par défaut est sans verrouillage UEFI, ce qui permet aux administrateurs de
désactiver Credential Guard à distance si nécessaire.

Lorsque Credential Guard est activé, VBS l’est également automatiquement.

７ Notes

Si Credential Guard est explicitement désactivéavant la mise à jour d’un appareil

vers Windows 11, version 22H2/Windows Server 2025 (préversion) ou version
ultérieure, l’activation par défaut ne remplace pas les paramètres existants.
Credential Guard continuera à être désactivé sur cet appareil, même après la mise à
jour vers une version de Windows qui active Credential Guard par défaut.

Activation par défaut sur Windows

Les appareils exécutant Windows 11, 22H2 ou version ultérieure ont Credential Guard
activé par défaut s’ils :

Respecter les exigences de licence

Répondre à la configuration matérielle et logicielle requise
Ne sont pas explicitement configurés pour désactiver Credential Guard

７ Notes

Les appareils exécutant Windows 11 Professionnel/Professionnel Edu 22H2 ou

version ultérieure peuvent avoir la sécurité basée sur la virtualisation (VBS) et/ou
Credential Guard automatiquement activés s’ils répondent aux autres exigences
d’activation par défaut et qu’ils ont précédemment exécuté Credential Guard. Par
exemple, si Credential Guard a été activé sur un appareil d’entreprise qui a ensuite
été rétrogradé à Pro.
 Pour déterminer si l’appareil Pro est dans cet état, vérifiez si la clé de Registre
suivante existe :
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\Isolat
edCredentialsRootSecret . Dans ce scénario, si vous souhaitez désactiver VBS et

Credential Guard, suivez les instructions pour désactiver la sécurité basée sur la
virtualisation. Si vous souhaitez désactiver Credential Guard uniquement, sans
désactiver VBS, utilisez les procédures pour désactiver Credential Guard.

Activation par défaut sur Windows Server

Les appareils exécutant Windows Server 2025 (préversion) ou version ultérieure ont
Credential Guard activé par défaut s’ils :

Respecter les exigences de licence

Répondre à la configuration matérielle et logicielle requise
Ne sont pas explicitement configurés pour désactiver Credential Guard
Sont joints à un domaine
Ne sont pas un contrôleur de domaine

） Important

Pour plus d’informations sur les problèmes connus liés à l’activation par défaut,
consultez Credential Guard : problèmes connus.

Configuration requise
Pour que Credential Guard assure la protection, l’appareil doit répondre à certaines
exigences matérielles, microprogrammes et logicielles.

Les appareils qui dépassent les qualifications minimales du matériel et du

microprogramme reçoivent des protections supplémentaires et sont plus renforcés
contre certaines menaces.

Configuration matérielle et logicielle requise

Credential Guard nécessite les fonctionnalités suivantes :

Sécurité basée sur la virtualisation (VBS)

 ７ Notes

VBS a des exigences différentes pour l’activer sur différentes plateformes

matérielles. Pour plus d’informations, consultez Configuration requise pour la
sécurité basée sur la virtualisation.

Démarrage sécurisé

Bien qu’elles ne soient pas obligatoires, les fonctionnalités suivantes sont

recommandées pour fournir des protections supplémentaires :

Module de plateforme sécurisée (TPM), car il fournit une liaison au matériel. Les
versions de TPM 1.2 et 2.0 sont prises en charge, discrètes ou microprogrammes
Verrouillage UEFI, car il empêche les attaquants de désactiver Credential Guard
avec une modification de clé de Registre

Pour plus d’informations sur les protections pour une sécurité améliorée associées aux
options de matériel et de microprogramme, consultez Qualifications de sécurité
supplémentaires.

Credential Guard dans les machines virtuelles

Credential Guard peut protéger les secrets dans les machines virtuelles Hyper-V, comme
sur un ordinateur physique. Lorsque Credential Guard est activé sur une machine
virtuelle, les secrets sont protégés contre les attaques à l’intérieur de la machine
virtuelle. Credential Guard ne fournit pas de protection contre les attaques système
privilégiées provenant de l’hôte.

Les conditions requises pour exécuter Credential Guard sur les machines virtuelles
Hyper-V sont les suivantes :

L’hôte Hyper-V doit avoir un IOMMU

La machine virtuelle Hyper-V doit être de génération 2

７ Notes

Credential Guard n’est pas pris en charge sur les machines virtuelles Hyper-V ou
Azure de génération 1. Credential Guard est disponible uniquement sur les
machines virtuelles de génération 2.
Conditions d'octroi de licence d'édition
Windows
Le tableau suivant répertorie les éditions de Windows qui prennent en charge Credential
Guard :

ﾉ Agrandir le tableau

Windows Pro Windows Entreprise Windows Pro Education/SE Windows Éducation

Non Oui Non Oui

Les droits de licence Credential Guard sont accordés par les licences suivantes :

ﾉ Agrandir le tableau

Windows Windows Windows Windows Windows

Pro/Professionnel Entreprise E3 Entreprise E5 Éducation A3 Éducation A5
Éducation/SE

Non Oui Oui Oui Oui

Pour plus d’informations à propos des licences Windows, consultez Vue d’ensemble des
licences Windows.

Configuration requise pour les applications

Lorsque Credential Guard est activé, certaines fonctionnalités d’authentification sont
bloquées. Les applications qui nécessitent de telles fonctionnalités s’arrêtent. Nous
faisons référence à ces exigences en tant qu’exigences d’application.

Les applications doivent être testées avant le déploiement pour garantir la compatibilité
avec les fonctionnalités réduites.

２ Avertissement

L’activation de Credential Guard sur les contrôleurs de domaine n’est pas

recommandée. Credential Guard n’offre aucune sécurité supplémentaire aux
contrôleurs de domaine et peut entraîner des problèmes de compatibilité des
applications sur les contrôleurs de domaine.
 ７ Notes

Credential Guard ne fournit pas de protections pour la base de données Active

Directory ou le Gestionnaire des comptes de sécurité (SAM). Les informations
d’identification protégées par Kerberos et NTLM lorsque Credential Guard est
activé se trouvent également dans la base de données Active Directory (sur les
contrôleurs de domaine) et le SAM (pour les comptes locaux).

Les applications s’arrêtent si elles nécessitent :

La prise en charge du chiffrement DES via Kerberos

Délégation Kerberos sans contraintes
Extraction TGT Kerberos
NTLMv1

Les applications demandent et exposent des informations d’identification à des risques

si elles nécessitent :

Authentification Digest
Délégation des informations d’identification
MS-CHAPv2
CredSSP

Les applications peuvent entraîner des problèmes de performances lorsqu’elles tentent

de raccorder le processus [Link] isolé Credential Guard .

Les services ou protocoles qui s’appuient sur Kerberos, tels que les partages de fichiers
ou le Bureau à distance, continuent de fonctionner et ne sont pas affectés par Credential
Guard.

Étapes suivantes
Découvrez le fonctionnement de Credential Guard
Découvrez comment configurer Credential Guard
Passez en revue les conseils et les exemples de code pour rendre votre
environnement plus sécurisé et robuste avec Credential Guard dans l’article Autres
atténuations
Passer en revue les considérations et les problèmes connus liés à l’utilisation de
Credential Guard
Commentaires
Cette page a-t-elle été utile ?  Yes  No

Indiquer des commentaires sur le produit

Protection des informations d’identification à
distance
Article • 04/12/2023 •
S’applique ✅ Windows 11, ✅ Windows 10, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
à: Server 2016

Vue d'ensemble
Remote Credential Guard permet de protéger les informations d’identification via une connexion
Bureau à distance (RDP) en redirigeant les demandes Kerberos vers l’appareil qui demande la
connexion. Si l’appareil cible est compromis, les informations d’identification ne sont pas exposées,
car les informations d’identification et les dérivés d’informations d’identification ne sont jamais
passés sur le réseau à l’appareil cible. Remote Credential Guard fournit également des expériences
d’authentification unique pour les sessions Bureau à distance.

Cet article explique comment configurer et utiliser Remote Credential Guard.

） Important

Pour plus d’informations sur les scénarios de connexion Bureau à distance impliquant la prise
en charge du support technique, consultez Connexions Bureau à distance et scénarios de
support technique dans cet article.

Comparer Remote Credential Guard avec d’autres

options de connexion
L’utilisation d’une session Bureau à distance sans Remote Credential Guard a les implications de
sécurité suivantes :

Les informations d’identification sont envoyées à et stockées sur l’hôte distant

Les informations d’identification ne sont pas protégées contre les attaquants sur l’hôte distant
L’attaquant peut utiliser les informations d’identification après la déconnexion

Les avantages en matière de sécurité de Remote Credential Guard sont les suivants :

Les informations d’identification ne sont pas envoyées à l’hôte distant

Pendant la session à distance, vous pouvez vous connecter à d’autres systèmes à l’aide de
l’authentification unique
Un attaquant ne peut agir au nom de l’utilisateur que lorsque la session est en cours

Les avantages en matière de sécurité du mode Administration restreint sont les suivants :

Les informations d’identification ne sont pas envoyées à l’hôte distant

 La session Bureau à distance se connecte à d’autres ressources en tant qu’identité de l’hôte
distant
Un attaquant ne peut pas agir au nom de l’utilisateur et toute attaque est locale sur le serveur

Utilisez le tableau suivant pour comparer différentes options de sécurité de connexion Bureau à
distance :

ﾉ Expand table

Fonctionnalité Bureau à distance Protection des Mode Administration

informations restreint
d’identification à
distance

Authentification unique ✅ ✅ ❌
(SSO) sur d’autres systèmes
en tant qu’utilisateur
connecté

RDP multi-tronçon ✅ ✅ ❌

Empêcher l’utilisation de ❌ ❌ ✅
l’identité de l’utilisateur
pendant la connexion

Empêcher l’utilisation des ❌ ✅ ✅

informations d’identification
après la déconnexion

Empêcher pass-the-hash ❌ ✅ ✅
(PtH)

Authentification prise en Tout protocole Kerberos uniquement Tout protocole

charge négociable négociable

Informations d’identification - Informations - Informations - Informations

prises en charge à partir de d’identification de d’identification de d’identification de
l’appareil client Bureau à connexion connexion connexion
distance - Informations - Informations - Informations
d’identification fournies d’identification fournies d’identification fournies
- Informations - Informations
d’identification d’identification
enregistrées enregistrées

Accès RDP accordé avec Appartenance au groupe Appartenance au groupe Appartenance au

Utilisateurs Bureau à Utilisateurs Bureau à groupe
distance sur l’hôte distance sur l’hôte distant Administrateurs sur
distant l’hôte distant

Configuration requise de Remote Credential Guard

Pour utiliser Remote Credential Guard, l’hôte distant et le client doivent répondre aux exigences
suivantes.
L’hôte distant :

Doit autoriser l’utilisateur à accéder via des connexions Bureau à distance

Doit autoriser la délégation d’informations d’identification non exportables à l’appareil client

L’appareil client :

Doit exécuter l’application Windows Bureau à distance. L’application Bureau à distance

plateforme Windows universelle (UWP) ne prend pas en charge Remote Credential Guard
Doit utiliser l’authentification Kerberos pour se connecter à l’hôte distant. Si le client ne peut
pas se connecter à un contrôleur de domaine, RDP tente de revenir à NTLM. Remote
Credential Guard n’autorise pas le secours NTLM, car il expose les informations d’identification
à un risque

Conditions d'octroi de licence d'édition Windows

Le tableau suivant répertorie les éditions de Windows qui prennent en charge Remote Credential
Guard :

ﾉ Expand table

Windows Pro Windows Entreprise Windows Pro Education/SE Windows Éducation

Oui Oui Oui Oui

Les droits de licence Remote Credential Guard sont accordés par les licences suivantes :

ﾉ Expand table

Windows Pro/Professionnel Windows Windows Windows Windows

Éducation/SE Entreprise E3 Entreprise E5 Éducation A3 Éducation A5

Oui Oui Oui Oui Oui

Pour plus d’informations à propos des licences Windows, consultez Vue d’ensemble des licences
Windows.

Activer la délégation des informations d’identification

non exportables sur les hôtes distants
Cette stratégie est requise sur les hôtes distants pour prendre en charge le mode Remote Credential
Guard et Restricted Administration. Il permet à l’hôte distant de déléguer des informations
d’identification non exportables à l’appareil client.
Si vous désactivez ou ne configurez pas ce paramètre, les Administration restreints et le mode
Remote Credential Guard ne sont pas pris en charge. Les utilisateurs doivent transmettre leurs
informations d’identification à l’hôte, ce qui les expose au risque de vol d’informations
d’identification par des attaquants sur l’hôte distant.
Pour activer la délégation d’informations d’identification non exportables sur les hôtes distants, vous
pouvez utiliser :

Microsoft Intune/GPM
Stratégie de groupe
Registry

Les instructions suivantes fournissent des détails sur la configuration de vos appareils. Sélectionnez
l’option qui convient le mieux à vos besoins.

Intune/GPM

Pour configurer des appareils avec Microsoft Intune, créez une stratégie de catalogue
Paramètres et utilisez les paramètres suivants :

ﾉ Expand table

Catégorie Nom du paramètre Valeur

Délégation des informations d’identification L’hôte distant autorise la délégation Activé

système > des modèles > d’administration d’informations d’identification non
exportables

Affectez la stratégie à un groupe qui contient en tant que membres les appareils ou les
utilisateurs que vous souhaitez configurer.

Vous pouvez également configurer des appareils à l’aide d’une stratégie personnalisée avec le
csp Policy.

ﾉ Expand table

Paramètre

- OMA-URI
: ./Device/Vendor/MSFT/Policy/Config/CredentialsDelegation/RemoteHostAllowsDelegationOfNonExportableCredentials
- Type de données : chaîne
- Valeur: <enabled/>

Configurer la délégation des informations

d’identification sur les clients
Pour activer Remote Credential Guard sur les clients, vous pouvez configurer une stratégie qui
empêche la délégation des informations d’identification aux hôtes distants.

 Conseil
 Si vous ne souhaitez pas configurer vos clients pour appliquer Remote Credential Guard, vous
pouvez utiliser la commande suivante pour utiliser Remote Credential Guard pour une session
RDP spécifique :

Invite de commandes Windows

[Link] /remoteGuard

Si le serveur héberge le rôle Hôte RDS, la commande fonctionne uniquement si l’utilisateur est
administrateur de l’hôte distant.

La stratégie peut avoir des valeurs différentes, en fonction du niveau de sécurité que vous souhaitez
appliquer :

Désactivé : les Administration restreints et le mode Remote Credential Guard ne sont pas
appliqués et le client Bureau à distance peut déléguer des informations d’identification à des
appareils distants
Exiger des Administration restreints : le client Bureau à distance doit utiliser des
Administration restreints pour se connecter à des hôtes distants
Exiger remote Credential Guard : Le client Bureau à distance doit utiliser Remote Credential
Guard pour se connecter aux hôtes distants
Restreindre la délégation d’informations d’identification : le client Bureau à distance doit
utiliser Administration restreint ou Remote Credential Guard pour se connecter à des hôtes
distants. Dans cette configuration, Remote Credential Guard est préférable, mais il utilise le
mode Administration restreint (s’il est pris en charge) lorsque Remote Credential Guard ne
peut pas être utilisé

７ Notes

Lorsque restreindre la délégation d’informations d’identification est activé, le /restrictedAdmin

commutateur est ignoré. Windows applique la configuration de stratégie à la place et utilise
Remote Credential Guard.

Pour configurer vos clients, vous pouvez utiliser :

Microsoft Intune/GPM
Stratégie de groupe

Les instructions suivantes fournissent des détails sur la configuration de vos appareils. Sélectionnez
l’option qui convient le mieux à vos besoins.

Intune/GPM

Pour configurer des appareils avec Microsoft Intune, créez une stratégie de catalogue
Paramètres et utilisez les paramètres suivants :
 ﾉ Expand table

Catégorie Nom du paramètre Valeur

Délégation des informations Restreindre la délégation des Sélectionnez Activé et, dans la
d’identification système > des informations d’identification liste déroulante, sélectionnez
modèles > d’administration aux serveurs distants l’une des options suivantes :
- Restreindre la délégation
d’informations d’identification
- Exiger Remote Credential
Guard

Affectez la stratégie à un groupe qui contient en tant que membres les appareils ou les
utilisateurs que vous souhaitez configurer.

Vous pouvez également configurer des appareils à l’aide d’une stratégie personnalisée avec le
csp Policy.

ﾉ Expand table

Paramètre

- OMA-URI : ./Device/Vendor/MSFT/Policy/Config/ADMX_CredSsp/RestrictedRemoteAdministration
- Type de données : chaîne
- Valeur: <enabled/><data id=\"RestrictedRemoteAdministrationDrop\" value=\"2\"/>

Les valeurs possibles pour RestrictedRemoteAdministrationDrop sont les suivantes :

- 0 :Handicapés
- 1 : Exiger des Administration restreints
- 2 : Exiger Remote Credential Guard
- 3 : Restreindre la délégation d’informations d’identification

Utiliser Remote Credential Guard

Une fois qu’un client reçoit la stratégie, vous pouvez vous connecter à l’hôte distant à l’aide de
Remote Credential Guard en ouvrant le client Bureau à distance ( [Link] ). L’utilisateur est
automatiquement authentifié auprès de l’hôte distant :
 ７ Notes

L’utilisateur doit être autorisé à se connecter au serveur distant à l’aide du protocole Bureau à
distance, par exemple en étant membre du groupe local Utilisateurs bureau à distance sur
l’hôte distant.

Connexions Bureau à distance et scénarios de support

technique
Pour les scénarios de support technique dans lesquels le personnel a besoin d’un accès administratif
via des sessions Bureau à distance, il n’est pas recommandé d’utiliser Remote Credential Guard. Si
une session RDP est lancée sur un client déjà compromis, l’attaquant peut utiliser ce canal ouvert
pour créer des sessions au nom de l’utilisateur. L’attaquant peut accéder aux ressources de
l’utilisateur pendant une durée limitée après la déconnexion de la session.

Nous vous recommandons d’utiliser plutôt l’option Mode Administration restreint. Pour les
scénarios de support technique, les connexions RDP doivent uniquement être lancées à l’aide du
/RestrictedAdmin commutateur. Cela permet de garantir que les informations d’identification et les

autres ressources utilisateur ne sont pas exposées aux hôtes distants compromis. Pour plus
d’informations, consultez Atténuation du vol d’informations d’identification pass-the-hash et autres
vols d’informations d’identification v2 .

Pour renforcer la sécurité, nous vous recommandons également d’implémenter la solution de mot
de passe d’administrateur local Windows (LAPS), qui automatise la gestion des mots de passe de
l’administrateur local. LAPS atténue le risque d’escalade latérale et d’autres cyberattaques facilitées
lorsque les clients utilisent la même combinaison de compte local d’administration et de mot de
passe sur tous leurs ordinateurs.
Pour plus d’informations sur LAPS, consultez Qu’est-ce que Windows LAPS ?

Considérations
Voici quelques considérations relatives à Remote Credential Guard :

Remote Credential Guard ne prend pas en charge l’authentification composée. Par exemple, si
vous essayez d’accéder à un serveur de fichiers à partir d’un hôte distant qui nécessite une
revendication d’appareil, l’accès est refusé
Remote Credential Guard peut être utilisé uniquement lors de la connexion à un appareil joint
à un domaine Active Directory. Il ne peut pas être utilisé lors de la connexion à des appareils
distants joints à Microsoft Entra ID
Remote Credential Guard peut être utilisé à partir d’un client joint Microsoft Entra pour se
connecter à un hôte distant joint à Active Directory, à condition que le client puisse
s’authentifier à l’aide de Kerberos
Remote Credential Guard fonctionne uniquement avec le protocole RDP
Aucune information d’identification n’est envoyée à l’appareil cible, mais l’appareil cible
acquiert toujours des tickets de service Kerberos par lui-même
Le serveur et le client doivent s’authentifier à l’aide de Kerberos
Remote Credential Guard est pris en charge uniquement pour les connexions directes aux
machines cibles. Il n’est pas pris en charge pour les connexions via le service Broker pour les
connexions Bureau à distance et la passerelle Bureau à distance

Commentaires
Cette page a-t-elle été utile ?  Yes  No

Indiquer des commentaires sur le produit

Groupe de sécurité Utilisateurs protégés
Article • 15/02/2024

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Les Utilisateurs protégés sont un groupe de sécurité global pour Active Directory (AD)
conçu pour se protéger contre les attaques par vol d’informations d’identification. Le
groupe déclenche une protection non configurable sur les appareils et les ordinateurs
hôtes pour empêcher la mise en cache des informations d’identification lors de la
connexion de membres du groupe.

Prérequis
Avant de pouvoir déployer un groupe Utilisateurs protégés, votre système doit satisfaire
aux conditions préalables suivantes :

Les hôtes doivent exécuter l’un des systèmes d’exploitation suivants :

Windows 8.1 ou ultérieure
Windows Server 2012 R2 ou ultérieure avec les mises à jour de sécurité les plus
récentes installées

Le niveau fonctionnel du domaine doit correspondre à Windows Server 2012 R2 ou

ultérieure. Pour en savoir plus sur les niveaux fonctionnels, consultez Niveaux
fonctionnels de domaine et de forêt.

７ Notes

L’administrateur de domaine intégré, S-1-5-<domain>-500 , est toujours exempté

des stratégies d’authentification, même lorsqu’il est affecté à un silo de stratégies
d’authentification. Pour plus d'informations, voir Comment configurer des comptes
protégés.

Les appartenances aux groupes de sécurité globaux Utilisateurs protégés

autorisent les membres à utiliser uniquement le chiffrement Kerberos AES
(Advanced Encryption Standards). Les membres du groupe Utilisateurs protégés
doivent être en mesure de s’authentifier à l’aide d’AES.

Protections appliquées par Active Directory

Lorsque vous devenez membre du groupe Utilisateurs protégés, AD applique
automatiquement certains contrôles préconfigurés que vous ne pourrez pas modifier
tant que vous serez membre de ce groupe.

Protections d’appareil pour les membres du groupe

Utilisateurs protégés connectés
Lorsque l’utilisateur connecté est membre du groupe Utilisateurs protégés, celui-ci
fournit les protections suivantes :

La délégation des informations d’identification (CredSSP) ne met pas en cache les

informations d’identification en texte brut de l’utilisateur, même s’il active le
paramètre de stratégie de groupe Autoriser la délégation d’informations
d’identification par défaut.

Pour Windows 8.1 et ultérieures, et Windows Server 2012 R2 et ultérieures,

Windows Digest ne met pas en cache les informations d’identification en texte brut
de l’utilisateur, même lorsqu’il a activé Windows Digest.

NTLM arrête la mise en cache des informations d’identification en texte brut de

l’utilisateur ou de la fonction unidirectionnelle NT (NTOWF).

Kerberos cesse de créer des clés DES (Data Encryption Standard) ou RC4. Kerberos
ne met pas non plus en cache les informations d’identification en texte brut ou les
clés à long terme de l’utilisateur après l’acquisition du ticket initial TGT (Ticket
Granting Ticket).

Le système ne crée pas de vérificateur mis en cache lors de la connexion ou du

déverrouillage de l’utilisateur. Ainsi, les systèmes membres ne prennent plus en
charge la connexion hors connexion.

Une fois que vous avez ajouté un nouveau compte d’utilisateur au groupe Utilisateurs
protégés, ces protections s’activent lorsque le nouvel utilisateur protégé se connecte à
son appareil.

Protections de contrôleur de domaine pour le groupe

Utilisateurs protégés
Les comptes d’Utilisateurs protégés qui s’authentifient auprès d’un domaine exécutant
Windows Server 2012 R2 ou ultérieure ne peuvent pas effectuer les opérations
suivantes :

s'authentifier avec l'authentification NTLM ;

 utiliser les types de chiffrement DES ou RC4 dans la pré-authentification Kerberos ;

déléguer en utilisant la délégation non contrainte ou contrainte ;

renouveler des tickets TGT Kerberos au-delà de la durée de vie initiale de 4 heures ;

Des paramètres non configurables pour l’expiration des tickets TGT sont établis pour
chaque compte dans le groupe Utilisateurs protégés. En général, le contrôleur de
domaine définit la durée de vie et le renouvellement TGT en fonction des deux
stratégies de domaine suivantes :

Durée de vie maximale pour le ticket utilisateur

Durée de vie maximale pour le renouvellement du ticket utilisateur

Pour les membres du groupe Utilisateurs protégés, ce dernier définit automatiquement

ces limites de durée de vie à 600 minutes. L’utilisateur ne peut pas modifier cette limite,
sauf s’il quitte le groupe.

Fonctionnement du groupe Utilisateurs

protégés
Vous pouvez ajouter des utilisateurs au groupe Utilisateurs protégés à l’aide des
méthodes suivantes :

Outils d’interface utilisateur, comme Centre d’administration Active Directory

(ADAC) ou Utilisateurs et ordinateurs Active Directory.
Outil en ligne de commande, comme PowerShell.
Avec PowerShell, utilisez l’applet de commande Add-ADGroupMember.

） Important

N’ajoutez jamais de comptes de services et d’ordinateurs au groupe

Utilisateurs protégés. L’appartenance à ces comptes n’offre pas de protection
locale car le mot de passe ou le certificat est toujours disponible sur l’hôte.

N’ajoutez pas de comptes qui sont déjà membres de groupes dotés de

privilèges élevés, notamment les groupes Administrateurs d’entreprise ou
Admins du domaine, tant que vous ne pouvez pas garantir que l’ajout de ces
comptes n’aura pas de conséquences négatives. Les utilisateurs disposant de
privilèges élevés qui font partie des Utilisateurs protégés sont soumis aux
mêmes limitations et restrictions que les utilisateurs standard, et ces
 paramètres ne peuvent être ni contournés ni modifiés. Si vous ajoutez tous les
membres de ces groupes au groupe Utilisateurs protégés, leurs comptes
risquent d’être verrouillés accidentellement. Il est essentiel de tester votre
système pour vous assurer que les modifications apportées aux paramètres
obligatoires n’entraveront pas l’accès aux comptes de ces groupes
d’utilisateurs privilégiés.

Les membres du groupe Utilisateurs protégés peuvent uniquement s’authentifier à l’aide

du chiffrement Kerberos AES (Advanced Encryption Standards). Cette méthode nécessite
des clés AES pour le compte dans Active Directory. L’administrateur intégré ne dispose
pas d’une clé AES, sauf si le mot de passe du domaine exécutant Windows Server 2008
ou une version ultérieure change. Tout compte dont le mot de passe est modifié par un
contrôleur de domaine qui exécute une version antérieure de Windows Server est exclu
de l’authentification.

Pour éviter les verrouillages et les clés AES manquantes, nous vous recommandons de
suivre les instructions ci-dessous :

N’exécutez pas de tests dans les domaines, sauf si tous les contrôleurs de domaine
exécutent Windows Server 2008 ou une version ultérieure.

Si vous avez migré des comptes à partir d’autres domaines, vous devez réinitialiser
le mot de passe pour que les comptes possèdent des hachages AES. Dans le cas
contraire, ces comptes peuvent s’authentifier.

Les utilisateurs doivent modifier les mots de passe après le passage au niveau
fonctionnel de domaine de Windows Server 2008 ou ultérieure. Cela leur garantit
des hachages de mots de passe AES lorsqu’ils deviennent membres du groupe
Utilisateurs protégés.

Ajouter un groupe de sécurité global Utilisateurs

protégés à des domaines de niveau inférieur
Les contrôleurs de domaine qui exécutent un système d’exploitation antérieur à
Windows Server 2012 R2 peuvent prendre en charge l’ajout de membres au nouveau
groupe de sécurité Utilisateurs protégés. Ces membres peuvent ainsi bénéficier des
protections de l’appareil avant que vous ne mettiez le domaine à niveau.

７ Notes
 Les contrôleurs de domaine qui exécutent des versions antérieures de Windows
Server 2012 R2 ne prennent pas en charge les protections de domaine.

Pour créer un groupe Utilisateurs protégés sur un contrôleur de domaine qui exécute
une version antérieure de Windows Server :

1. Transférez le rôle d’émulateur de contrôleur de domaine principal vers un

contrôleur de domaine qui exécute Windows Server 2012 R2.

2. Répliquez l’objet de groupe vers les autres contrôleurs de domaine.

Ensuite, les utilisateurs peuvent bénéficier des protections des appareils avant que vous
ne mettiez le domaine à niveau.

Propriétés AD du groupe Utilisateurs protégés

Le tableau suivant spécifie les propriétés Active Directory du groupe Utilisateurs
protégés.

ﾉ Agrandir le tableau

Attribut Valeur

SID/RID connu S-1-5-21-<domaine>-525

Type Global du domaine

Conteneur par défaut CN=Users, DC=<domaine>,

DC=

Membres par défaut None

Membre par défaut de None

Protégé par ADMINSDHOLDER ? Non

Sortie du conteneur par défaut sécurisée ? Oui

Délégation de la gestion de ce groupe à des administrateurs Non

extérieurs au service sécurisée ?

Droits d’utilisateur par défaut Aucun droit d’utilisateur par

défaut

Journaux d’événements
Deux journaux d'administration opérationnels sont disponibles pour résoudre les
problèmes associés aux événements concernant les utilisateurs protégés. Ces nouveaux
journaux se trouvent dans l’observateur d’événements et sont désactivés par défaut. Ils
sont sous Journaux des applications et des
services\Microsoft\Windows\Authentification.

Pour activer la capture de ces journaux d’activité :

1. Cliquez avec le bouton droit de la souris sur Démarrer, puis sélectionnez

Observateur d’événements.

2. Ouvrez les Journaux des applications et des

services\Microsoft\Windows\Authentication.

3. Cliquez avec le bouton droit de la souris sur le nom de chaque journal que vous
souhaitez activer, puis sélectionnez Activer le journal.

ﾉ Agrandir le tableau

ID d'événement et Description
journal

104 Cause : Le package de sécurité sur le client ne contient pas les

ProtectedUser-Client informations d'identification.
L'erreur est consignée sur l'ordinateur client quand le compte est
membre du groupe de sécurité Utilisateurs protégés. Cet
événement indique que le package de sécurité ne met pas en cache
les informations d'identification nécessaires pour une
authentification auprès du serveur.

Affiche le nom du package, le nom d'utilisateur, le nom du domaine

et le nom du serveur.

304 Motif : le package de sécurité ne stocke pas les informations

ProtectedUser-Client d’identification des utilisateurs protégés.
Un événement d’information est journalisé dans le client pour
indiquer que le package de sécurité ne met pas en cache les
informations de connexion de l’utilisateur. Normalement, Digest
(WDigest), la délégation des informations d'identification (CredSSP)
et NTLM ne devraient pas pouvoir obtenir les informations
d'identification de connexion pour les utilisateurs protégés. Les
applications peuvent quand même réussir si elles demandent des
informations d'identification.

Affiche le nom du package, le nom d'utilisateur et le nom du

domaine.
ID d'événement et Description
journal

100 Cause : Un échec de connexion NTLM se produit pour un compte

ProtectedUserFailures- qui figure dans le groupe de sécurité Utilisateurs protégés.
DomainController Une erreur est consignée dans le contrôleur de domaine pour
indiquer l'échec de l'authentification NTLM en raison de
l'appartenance du compte au groupe de sécurité Utilisateurs
protégés.

Affiche le nom du compte et le nom de l'appareil.

104 Cause : Les types de chiffrement DES ou RC4 sont utilisés pour
ProtectedUserFailures- l'authentification Kerberos et un échec de connexion se produit
DomainController pour un utilisateur dans le groupe de sécurité Utilisateurs protégés.
La pré-authentification Kerberos a échoué, car les types de
chiffrement DES et RC4 ne peuvent pas être utilisés quand le
compte est membre du groupe de sécurité Utilisateurs protégés.

(AES est acceptable.)

303 Cause : Un ticket TGT Kerberos a été correctement émis pour un

ProtectedUserSuccesses- membre du groupe Utilisateurs protégés.
DomainController

Ressources supplémentaires
Gestion et protection des informations d’identification

Stratégies d’authentification et silos de stratégies d’authentification

Comment configurer des comptes protégés

Stratégies d'authentification et silos de
stratégies d'authentification
Article • 11/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cette rubrique destinée aux professionnels de l'informatique décrit les silos de stratégies
d'authentification et les stratégies qui peuvent limiter des comptes à ces silos. Elle
explique également comment utiliser des stratégies d'authentification pour restreindre
l'étendue d'utilisation de certains comptes.

Les silos de stratégies d'authentification et les stratégies qui les accompagnent

permettent de restreindre des informations d'identification dotées de privilèges élevés à
des systèmes pertinents uniquement pour certains utilisateurs, ordinateurs ou services
sélectionnés. Il est possible de définir et de gérer les silos dans les services de domaine
Active Directory (AD DS) en utilisant le Centre d'administration Active Directory et les
applets de commande Windows PowerShell relatifs à Active Directory.

Les silos de stratégies d'authentification sont des conteneurs dans lesquels les
administrateurs peuvent affecter des comptes d'utilisateur, d'ordinateur et de service. Il
est ensuite possible de gérer ces ensembles de comptes à l'aide des stratégies
d'authentification qui ont été appliquées à ces conteneurs. Cela évite à l'administrateur
d'avoir à effectuer le suivi de l'accès aux ressources pour les comptes individuels et
contribue également à empêcher les utilisateurs malveillants d'accéder à d'autres
ressources via le vol d'informations d'identification.

Les fonctionnalités introduites dans Windows Server 2012 R2 vous permettent de créer
des silos de stratégies d’authentification, hébergeant un ensemble d’utilisateurs à
privilèges élevés. Vous pouvez ensuite affecter des stratégies d'authentification pour ce
conteneur afin de limiter la zone du domaine où ces comptes privilégiés peuvent être
utilisés. Lorsque les comptes appartiennent au groupe de sécurité Utilisateurs protégés,
des contrôles supplémentaires sont appliqués, tels que l'utilisation exclusive du
protocole Kerberos.

Ces fonctions permettent de restreindre l'utilisation des comptes importants aux hôtes
importants. Par exemple, vous pouvez créer un nouveau silo Administrateurs de forêt
contenant les administrateurs d'entreprise, de schéma et de domaine. Ensuite, vous
pouvez configurer ce silo avec une stratégie d'authentification entraînant l'échec de
l'authentification par mot de passe ou carte à puce à partir de systèmes autres que les
contrôleurs de domaine et les consoles Administrateurs de domaine.
Pour plus d'informations sur la configuration de stratégies d'authentification et de silos
de stratégies d'authentification, voir Comment configurer des comptes protégés.

À propos des silos de stratégies d'authentification

Un silo de stratégies d'authentification détermine les comptes qui peuvent être
restreints par le silo et définit les stratégies d'authentification à appliquer aux membres.
Vous pouvez créer un silo en fonction des besoins de votre organisation. Les silos sont
des objets Active Directory destinés aux utilisateurs, ordinateurs et services, tels que
définis par le schéma exposé dans le tableau ci-dessous.

Schéma Active Directory pour les silos de stratégies d'authentification

Nom d’affichage Description

Silo de stratégies Une instance de cette classe définit des stratégies d'authentification et
d'authentification des comportements associés pour les utilisateurs, les ordinateurs et les
services affectés.

Silos de stratégies Un conteneur de cette classe peut obtenir des objets silos de
d'authentification stratégies d'authentification.

Silo de stratégies Spécifie si le silo de stratégies d'authentification est appliqué ou non.

d'authentification S'il n'est pas appliqué, la stratégie est par défaut en mode audit. Des
appliqué événements indiquant les succès ou échecs potentiels sont générés,
mais aucune protection n'est appliquée au système.

Lien secondaire du silo Cet attribut correspond au lien secondaire pour le silo msDS-
de stratégies AssignedAuthNPolicySilo.
d'authentification
affecté

Membres du silo de Spécifie quels principaux sont affectés au silo AuthNPolicySilo.

stratégies
d'authentification

Lien secondaire aux Cet attribut correspond au lien secondaire pour msDS-
membres du silo de AuthNPolicySiloMembers.
stratégies
d'authentification

Les silos de stratégies d'authentification peuvent être configurés à l'aide de la console

d'administration Active Directory ou de Windows PowerShell. Pour plus d'informations,
voir Comment configurer des comptes protégés.

À propos des stratégies d'authentification

Une stratégie d'authentification définit les propriétés de durée de vie des tickets TGT du
protocole Kerberos et les conditions de contrôle d'accès par authentification d'un type
de compte. La stratégie s'appuie sur le conteneur AD DS que constitue le silo de
stratégies d'authentification et contrôle ce dernier.

Les stratégies d'authentification contrôlent les éléments suivants :

La durée de vie du ticket TGT pour le compte, qui est définie comme non
renouvelable.

Les critères que doivent respecter les comptes de périphériques pour se connecter
avec un mot de passe ou un certificat.

Les critères que doivent respecter les utilisateurs et les périphériques pour
s'authentifier auprès des services s'exécutant sous ce compte.

Le type de compte Active Directory détermine le rôle de l’appelant parmi les rôles
suivants :

Utilisateur

Les utilisateurs doivent toujours être membres du groupe de sécurité Utilisateurs

protégés, lequel rejette par défaut les tentatives d'authentification utilisant NTLM.

Les stratégies peuvent être configurées de manière à réduire la durée de vie du

TGT d’un compte d’utilisateur ou à restreindre les appareils auxquels un compte
d’utilisateur peut se connecter. Des expressions riches peuvent être configurées
dans la stratégie d’authentification pour contrôler les critères que les utilisateurs et
leurs appareils doivent respecter pour s’authentifier auprès du service.

Pour plus d'informations, voir Groupe de sécurité Utilisateurs protégés.

Service

Des comptes de service administrés autonomes, des comptes de service

administrés de groupe ou un objet compte personnalisé dérivé de ces deux types
de comptes de service sont utilisés. Des stratégies peuvent définir les conditions
de contrôle d'accès d’un appareil, qui permettent de restreindre les informations
d’identification des comptes de service administrés à des appareils spécifiques
avec une identité Active Directory. Les services ne doivent jamais être membres du
groupe de sécurité Utilisateurs protégés car toute authentification entrante
échouera.

Ordinateur
 L'objet compte d'ordinateur ou l'objet compte personnalisé qui est dérivé de
l'objet compte d'ordinateur est utilisé. Des stratégies peuvent définir les conditions
de contrôle d'accès requises pour autoriser l'authentification auprès du compte en
fonction des propriétés propres à l'utilisateur et au périphérique. Les ordinateurs
ne doivent jamais être membres du groupe de sécurité Utilisateurs protégés car
toute authentification entrante échouera. Par défaut, les tentatives visant à utiliser
l'authentification NTLM sont rejetées. La durée de vie des tickets TGT ne doit pas
être configurée pour les comptes d'ordinateur.

７ Notes

Il est possible de définir une stratégie d'authentification sur un ensemble de

comptes sans associer la stratégie à un silo de stratégies d'authentification. Vous
pouvez utiliser cette stratégie quand vous n'avez qu'un seul compte à protéger.

Schéma Active Directory pour les stratégies d'authentification

Les stratégies prévues pour les objets Active Directory relatifs aux utilisateurs,
ordinateurs et services sont définies par le schéma présenté dans le tableau ci-dessous.

Type Nom d’affichage Description

Stratégie Stratégie Une instance de cette classe définit les comportements associés
d'authentification aux stratégies d'authentification pour les principaux affectés.

Stratégie Stratégies Un conteneur de cette classe peut obtenir des objets de

d'authentification stratégie d'authentification.

Stratégie Stratégie Spécifie si la stratégie d'authentification est appliquée ou non.

d'authentification Si elle n'est pas appliquée, la stratégie est par défaut en mode
appliquée audit et des événements indiquant les succès ou échecs
potentiels sont générés, mais aucune protection n'est appliquée
au système.

Stratégie Lien secondaire Cet attribut correspond au lien secondaire pour msDS-
de stratégie AssignedAuthNPolicy.
d'authentification
affecté

Stratégie Stratégie Spécifie la stratégie AuthNPolicy qui doit être appliquée à ce

d'authentification principal.
affectée

Utilisateur Stratégie Spécifie la stratégie AuthNPolicy qui doit être appliquée aux
d'authentification utilisateurs affectés à cet objet silo.
d'utilisateur
Type Nom d’affichage Description

Utilisateur Lien secondaire Cet attribut correspond au lien secondaire pour msDS-
de stratégie UserAuthNPolicy.
d'authentification
d'utilisateur

Utilisateur ms-DS-User- Cet attribut permet de déterminer l'ensemble des principaux

Allowed-To- autorisés à s'authentifier auprès d'un service s'exécutant sous le
Authenticate-To compte d'utilisateur.

Utilisateur ms-DS-User- Cet attribut permet de déterminer l'ensemble des périphériques

Allowed-To- auxquels un compte d'utilisateur est autorisé à se connecter.
Authenticate-
From

Utilisateur Durée de vie de Spécifie l'âge maximal d'un ticket TGT Kerberos émis pour un
ticket TGT utilisateur (exprimé en secondes). Les tickets TGT résultants sont
d'utilisateur non renouvelables.

Computer Stratégie Spécifie la stratégie AuthNPolicy qui doit être appliquée aux
d'authentification ordinateurs affectés à cet objet silo.
d'ordinateur

Computer Lien secondaire Cet attribut correspond au lien secondaire pour msDS-
de stratégie ComputerAuthNPolicy.
d'authentification
d'ordinateur

Computer ms-DS- Cet attribut permet de déterminer l'ensemble des principaux

Computer- autorisés à s'authentifier auprès d'un service s'exécutant sous le
Allowed-To- compte d'ordinateur.
Authenticate-To

Computer Durée de vie de Spécifie l'âge maximal d'un ticket TGT Kerberos émis pour un
ticket TGT ordinateur (exprimé en secondes). Il n'est pas conseillé de
d'ordinateur modifier ce paramètre.

Service Stratégie Spécifie la stratégie AuthNPolicy qui doit être appliquée aux
d'authentification services affectés à cet objet silo.
de service

Service Lien secondaire Cet attribut correspond au lien secondaire pour msDS-
de stratégie ServiceAuthNPolicy.
d'authentification
de service

Service ms-DS-Service- Cet attribut permet de déterminer l'ensemble des principaux

Allowed-To- autorisés à s'authentifier auprès d'un service s'exécutant sous le
Authenticate-To compte de service.
 Type Nom d’affichage Description

Service ms-DS-Service- Cet attribut permet de déterminer l'ensemble des périphériques

Allowed-To- auxquels un compte de service est autorisé à se connecter.
Authenticate-
From

Service Durée de vie de Spécifie l'âge maximal d'un ticket TGT Kerberos émis pour un
ticket TGT de service (exprimé en secondes).
service

Des stratégies d'authentification peuvent être configurées pour chaque silo à l'aide de la
console d'administration Active Directory ou de Windows PowerShell. Pour plus
d'informations, voir Comment configurer des comptes protégés.

Fonctionnement
Cette section décrit comment les stratégies d'authentification et les silos de stratégies
d'authentification fonctionnent en association avec le groupe de sécurité Utilisateurs
protégés et l'implémentation du protocole Kerberos dans Windows.

Comment utiliser le protocole Kerberos avec les stratégies et silos

d'authentification

Comment fonctionne la limitation d'une connexion d'utilisateur

Comment fonctionne la limitation de l'émission des tickets de service

Comptes protégés

Le groupe de sécurité Utilisateurs protégés déclenche une protection non configurable

sur les appareils et les ordinateurs hôtes exécutant Windows Server 2012 R2 et
Windows 8.1, ainsi que sur les contrôleurs de domaine dans les domaines avec un
contrôleur de domaine principal exécutant Windows Server 2012 R2 . En fonction du
niveau fonctionnel de domaine du compte, les membres du groupe de sécurité
Utilisateurs protégés sont également protégés en raison des modifications apportées
dans les méthodes d'authentification prises en charge dans Windows.

Le membre du groupe de sécurité Utilisateurs protégés ne peut pas s'authentifier

en utilisant NTLM, l'authentification Digest ni la délégation d'informations
d'identification par défaut CredSSP. Sur un appareil exécutant Windows 8.1 et
utilisant l’un de ces fournisseurs de support de sécurité (SSP), l’authentification à
un domaine échoue lorsque le compte est membre du groupe de sécurité
Utilisateurs protégés.
 Le protocole Kerberos n'utilise pas les types de chiffrement DES et RC4 plus faibles
dans le processus de pré-authentification. Cela signifie que le domaine doit être
configuré pour prendre en charge au moins le type de chiffrement AES.

Le compte de l’utilisateur ne peut pas être délégué via la délégation Kerberos

contrainte ou non contrainte. Cela signifie que les connexions antérieures à
d'autres systèmes peuvent échouer si l'utilisateur est membre du groupe de
sécurité Utilisateurs protégés.

Le paramètre de durée de vie des tickets TGT Kerberos par défaut de quatre heures
est configurable à l'aide des silos et stratégies d'authentification, auxquels il est
possible d'accéder via le Centre d'administration Active Directory. Cela signifie
qu'après quatre heures l'utilisateur doit s'authentifier de nouveau.

Pour plus d'informations sur ce groupe de sécurité, voir Comment fonctionne le groupe
Utilisateurs protégés.

Silos et stratégies d'authentification

Les stratégies d'authentification et les silos de stratégies d'authentification tirent parti de

l'infrastructure d'authentification Windows existante. L'utilisation du protocole NTLM est
rejetée et le protocole Kerberos doté de types de chiffrement plus récents est utilisé. Les
stratégies d'authentification offrent un complément au groupe de sécurité Utilisateurs
protégés en permettant d'appliquer des limitations configurables aux comptes, en plus
de limiter les comptes pour les services et les ordinateurs. Les stratégies
d'authentification sont appliquées pendant l'échange du service d'authentification (AS)
ou du service d'accord de tickets (TGS) du protocole Kerberos. Pour plus d'informations
sur la façon dont Windows utilise le protocole Kerberos et sur les changements qui ont
été effectués pour prendre en charge les stratégies d'authentification et les silos de
stratégies d'authentification, voir :

Fonctionnement du protocole d’authentification Kerberos version 5

Changements dans l’authentification Kerberos (Windows Server 2008 R2 et

Windows 7)

Comment utiliser le protocole Kerberos avec les

stratégies d'authentification et les silos de stratégies
d'authentification
Quand un compte de domaine est lié à un silo de stratégies d'authentification et que
l'utilisateur se connecte, le Gestionnaire des comptes de sécurité ajoute le type de
revendication Silo de stratégies d'authentification qui inclut le silo comme valeur. Cette
revendication sur le compte fournit l'accès au silo ciblé.

Quand une stratégie d'authentification est appliquée et que la demande du service

d'authentification pour un compte de domaine est reçue sur le contrôleur de domaine,
ce dernier retourne un ticket TGT non renouvelable, doté de la durée de vie configurée
(à moins que la durée de vie des tickets TGT du domaine soit plus courte).

７ Notes

Le compte de domaine doit avoir une durée de vie de ticket TGT configurée et doit
être directement lié à la stratégie ou indirectement lié via son appartenance au silo.

Quand une stratégie d'authentification est en mode audit et que la demande du service
d'authentification pour un compte de domaine est reçue sur le contrôleur de domaine,
ce dernier vérifie si l'authentification est autorisée pour le périphérique afin de pouvoir
consigner un avertissement en cas d'échec. Une stratégie d'authentification auditée
n'altère pas le processus, si bien que les demandes d'authentification n'échoueront pas
si elles ne satisfont pas aux conditions requises de la stratégie.

７ Notes

Le compte de domaine doit être directement lié à la stratégie ou indirectement lié

via son appartenance au silo.

Quand une stratégie d'authentification est appliquée et que le service d'authentification

est blindé, la demande du service d'authentification pour un compte de domaine est
reçue sur le contrôleur de domaine et ce dernier vérifie si l'authentification est autorisée
pour le périphérique. En cas d'échec, le contrôleur de domaine retourne un message
d'erreur et consigne un événement.

７ Notes

Le compte de domaine doit être directement lié à la stratégie ou indirectement lié

via son appartenance au silo.

Quand une stratégie d’authentification est en mode audit et qu’une requête de service
d’attribution de tickets est reçue par le contrôleur de domaine pour un compte de
domaine, le contrôleur de domaine vérifie si l’authentification est autorisée en fonction
des données du certificat d’attributs de privilèges (PAC) du ticket de la requête, et il
consigne un message d’avertissement en cas d’échec. Le certificat PAC contient divers
types de données d'autorisation, dont notamment les groupes dont l'utilisateur est
membre, les droits détenus par l'utilisateur et les stratégies qui s'appliquent à
l'utilisateur. Ces informations sont utilisées pour générer le jeton d’accès de l’utilisateur.
Si une stratégie d’authentification appliquée permet l’authentification auprès d’un
utilisateur, d’un appareil ou d’un service, le contrôleur de domaine vérifie si
l’authentification est autorisée en fonction des données de certificat PAC du ticket de la
requête. En cas d'échec, le contrôleur de domaine retourne un message d'erreur et
consigne un événement.

７ Notes

Le compte de domaine doit être lié directement ou via son appartenance à un silo
à une stratégie d'authentification auditée qui permet l'authentification auprès d'un
utilisateur, d'un périphérique ou d'un service,

Vous pouvez utiliser une stratégie d'authentification unique pour tous les membres d'un
silo ou des stratégies distinctes pour les utilisateurs, les ordinateurs et les comptes de
service administrés.

Des stratégies d'authentification peuvent être configurées pour chaque silo à l'aide de la
console d'administration Active Directory ou de Windows PowerShell. Pour plus
d'informations, voir Comment configurer des comptes protégés.

Comment fonctionne la limitation d'une connexion

d'utilisateur
Comme les stratégies d'authentification sont appliquées à un compte, la limitation
s'applique aux comptes utilisés par les services. Si vous souhaitez limiter l'utilisation d'un
mot de passe d'un service à des hôtes spécifiques, ce paramètre est utile. Par exemple,
les comptes de service administrés de groupe sont configurés si les hôtes sont autorisés
à récupérer le mot de passe à partir des services de domaine Active Directory. Toutefois,
ce mot de passe peut être utilisé à partir de n'importe quel hôte pour l'authentification
initiale. En appliquant une condition de contrôle d'accès, il est possible d'obtenir une
couche de protection supplémentaire en limitant le mot de passe aux seuls hôtes qui
peuvent le récupérer.

Quand des services exécutés en tant que système, service réseau ou autre identité de
service local se connectent à des services réseau, ils utilisent le compte de l’ordinateur
de l’hôte. Les comptes d'ordinateur ne peuvent pas faire l'objet d'une limitation. Ainsi,
même si le service utilise un compte d'ordinateur qui n'est pas destiné à un hôte
Windows, le compte ne peut pas faire l'objet d'une limitation.

La limitation de la connexion d’un utilisateur à des hôtes spécifiques exige que le

contrôleur de domaine valide l’identité de l’hôte. Quand l'authentification Kerberos est
utilisée avec le blindage Kerberos (qui fait partie du contrôle d'accès dynamique), le
centre de distribution de clés reçoit le ticket TGT de l'hôte à partir duquel l'utilisateur
s'authentifie. Le contenu de ce ticket TGT blindé sert à effectuer une vérification d'accès
pour déterminer si l'hôte est autorisé.

Quand un utilisateur se connecte à Windows ou entre ses informations d'identification

de domaine dans une invite de demande d'informations d'identification, par défaut,
Windows envoie une demande AS-REQ non blindée au contrôleur de domaine. Si
l'utilisateur envoie la demande à partir d'un ordinateur qui ne prend pas en charge le
blindage, tel qu'un ordinateur exécutant Windows 7 ou Windows Vista, la demande
échoue.

La liste suivante décrit le processus :

Le contrôleur de domaine présent dans un domaine exécutant Windows Server

2012 R2 exécute des requêtes relatives au compte d’utilisateur afin de déterminer
s’il est configuré avec une stratégie d’authentification limitant l’authentification
initiale qui exige des requêtes blindées.

Le contrôleur de domaine provoquera l'échec de la demande.

Comme un blindage est requis, l’utilisateur peut essayer de se connecter en

utilisant un ordinateur exécutant Windows 8.1 ou Windows 8, configuré pour
prendre en charge le blindage Kerberos afin de répéter le processus de connexion.

Windows détecte que le domaine prend en charge le blindage Kerberos et envoie

une demande AS-REQ blindée pour répéter la demande de connexion.

Le contrôleur de domaine effectue une vérification d’accès en utilisant les

conditions de contrôle d'accès configurées et les informations d’identité du
système d’exploitation client dans le ticket TGT qui a servi à blinder la requête.

En cas d'échec de la vérification d'accès, le contrôleur de domaine rejette la

demande.

Même quand les systèmes d'exploitation prennent en charge le blindage Kerberos, les
conditions requises de contrôle d'accès peuvent être appliquées et doivent être
satisfaites pour que l'accès soit accordé. Les utilisateurs se connectent à Windows ou
entrent leurs informations d'identification de domaine dans une invite de demande
d'informations d'identification pour une application. Par défaut, Windows envoie une
demande AS-REQ non blindée au contrôleur de domaine. Si l’utilisateur envoie la
requête à partir d'un ordinateur qui prend en charge le blindage, tel que Windows 8.1
ou Windows 8, les stratégies d'authentification sont évaluées comme suit :

1. Le contrôleur de domaine présent dans un domaine exécutant Windows Server

2012 R2 exécute des requêtes relatives au compte d’utilisateur afin de déterminer
s’il est configuré avec une stratégie d’authentification limitant l’authentification
initiale qui exige des requêtes blindées.

2. Le contrôleur de domaine effectue une vérification d’accès en utilisant les

conditions de contrôle d'accès configurées et les informations d’identité du
système dans le ticket TGT qui sert à blinder la requête. La vérification d'accès
réussit.

７ Notes

Si des limitations de groupe de travail héritées sont configurées, elles doivent

également être respectées.

3. Le contrôleur de domaine renvoie une réponse blindée (AS-REP) et

l'authentification continue.

Comment fonctionne la limitation de l'émission des

tickets de service
Quand un compte n’est pas autorisé et qu’un utilisateur disposant d’un ticket TGT essaie
de se connecter au service (par exemple, en ouvrant une application qui exige une
authentification auprès d’un service identifié par le nom de principal du service (SPN) de
ce service), la procédure suivante a lieu :

1. Dans sa tentative de connexion à SPN1 à partir de SPN, Windows envoie une

demande TGS-REQ au contrôleur de domaine qui demande un ticket de service à
SPN1.

2. Le contrôleur de domaine présent dans un domaine exécutant Windows Server

2012 R2 consulte SPN1 pour trouver le compte AD DS pour le service et détermine
que ce compte est configuré avec une stratégie d’authentification qui limite
l’émission de tickets de service.

3. Le contrôleur de domaine effectue une vérification d’accès en utilisant les

conditions de contrôle d’accès configurées et les informations d’identité de
 l’utilisateur dans le ticket TGT. La vérification d'accès échoue.

4. Le contrôleur de domaine rejette la demande.

Quand un compte est autorisé parce qu’il satisfait aux conditions de contrôle d’accès
définies par la stratégie d’authentification et qu’un utilisateur disposant d’un ticket TGT
essaie de se connecter au service (par exemple, en ouvrant une application qui exige
une authentification auprès d’un service identifié par le nom de principal du service
(SPN) de ce service), la procédure suivante a lieu :

1. Dans sa tentative de connexion à SPN1, Windows envoie une demande TGS-REQ

au contrôleur de domaine qui demande un ticket de service à SPN1.

2. Le contrôleur de domaine présent dans un domaine exécutant Windows Server

2012 R2 consulte SPN1 pour trouver le compte AD DS pour le service et détermine
que ce compte est configuré avec une stratégie d’authentification qui limite
l’émission de tickets de service.

3. Le contrôleur de domaine effectue une vérification d’accès en utilisant les

conditions de contrôle d’accès configurées et les informations d’identité de
l’utilisateur dans le ticket TGT. La vérification d'accès réussit.

4. Le contrôleur de domaine répond à la demande avec une réponse de service

d'accord de tickets (TGS-REP).

Messages d'erreur et d'événement

d'information associés
Le tableau ci-dessous décrit les événements associés au groupe de sécurité Utilisateurs
protégés et les stratégies d'authentification appliquées aux silos de stratégies
d'authentification.

Les événements sont enregistrés dans le journal Journaux des applications et des
services, dans Microsoft\Windows\Authentication.

Pour connaître les étapes de dépannage qui utilisent ces événements, voir Dépanner les
stratégies d'authentification et Dépanner les événements associés aux Utilisateurs
protégés.

ID d'événement et journal Description

ID d'événement et journal Description

101 Motif : Un échec de connexion NTLM se produit, car la stratégie

AuthenticationPolicyFailures- d'authentification est configurée.
DomainController Un événement est consigné dans le contrôleur de domaine pour
indiquer que l'authentification NTLM a échoué parce que des
limitations de contrôle d'accès sont requises et qu'elles ne
peuvent pas être appliquées à NTLM.

Affiche les noms du compte, du périphérique, de la stratégie et

du silo.

105 Motif : Un échec de limitation Kerberos se produit parce que

AuthenticationPolicyFailures- l'authentification à partir d'un appareil particulier n'était pas
DomainController autorisée.
Un événement est consigné dans le contrôleur de domaine pour
indiquer qu'un ticket TGT Kerberos a été refusé parce que le
périphérique ne satisfaisait pas aux limitations de contrôle
d'accès appliquées.

Affiche les noms du compte, du périphérique, de la stratégie et

du silo, ainsi que la durée de vie du ticket TGT.

305 Motif : Un éventuel échec de limitation Kerberos peut se produire

AuthenticationPolicyFailures- parce que l'authentification à partir d'un appareil particulier
DomainController n'était pas autorisée.
En mode audit, un événement d'information est consigné dans le
contrôleur de domaine pour déterminer si un ticket TGT Kerberos
sera refusé parce que le périphérique ne satisfaisait pas aux
limitations de contrôle d'accès appliquées.

Affiche les noms du compte, du périphérique, de la stratégie et

du silo, ainsi que la durée de vie du ticket TGT.

106 Motif : Un échec de limitation Kerberos se produit parce que

AuthenticationPolicyFailures- l'utilisateur ou l’appareil n'était pas autorisé à s'authentifier
DomainController auprès du serveur.
Un événement est consigné dans le contrôleur de domaine pour
indiquer qu'un ticket de service Kerberos a été refusé parce que
l'utilisateur, le périphérique ou les deux ne satisfont pas aux
limitations de contrôle d'accès appliquées.

Affiche les noms du périphérique, de la stratégie et du silo.

 ID d'événement et journal Description

306 Motif : Un échec de limitation Kerberos peut se produire parce

AuthenticationPolicyFailures- que l'utilisateur ou l’appareil n'était pas autorisé à s'authentifier
DomainController auprès du serveur.
En mode audit, un événement d'information est consigné sur le
contrôleur de domaine pour indiquer qu'un ticket de service
Kerberos sera refusé parce que l'utilisateur, le périphérique ou les
deux ne satisfont pas aux limitations de contrôle d'accès.

Affiche les noms du périphérique, de la stratégie et du silo.

Références supplémentaires
Comment configurer des comptes protégés

Gestion et protection des informations d’identification

Groupe de sécurité Utilisateurs protégés

Group Managed Service Accounts
Overview
Article • 01/08/2024

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cet article destiné aux informaticiens présente le compte de service administré de

groupe (« group Managed Service Account » – gMSA) en décrivant des applications
pratiques, les modifications apportées à l’implémentation Microsoft et les exigences
matérielles et logicielles.

Description de la fonctionnalité
Un compte de service administré autonome (sMSA) est un compte de domaine
administré qui fournit la gestion automatique des mots de passe, la gestion simplifiée
des noms principaux du service (SPN) et la possibilité de déléguer la gestion à d’autres
administrateurs. Ce type de compte de service managé (« Managed Service Account » –
MSA) a été introduit dans Windows Server 2008 R2 et Windows 7.

Le compte de service administré de groupe (gMSA) offre les mêmes fonctionnalités

dans un domaine que sur de nombreux serveurs. Lors de la connexion à un service
hébergé sur une batterie de serveurs, tel que la solution de charge réseau équilibrée, les
protocoles d’authentification prenant en charge l’authentification mutuelle exigent que
toutes les instances des services utilisent le même principal. Lorsque vous utilisez un
compte de service administré de groupe comme principal de service, le système
d’exploitation Windows gère le mot de passe du compte au lieu de laisser cette
responsabilité à l’administrateur.

Le service de distribution de clés Microsoft ( [Link] ) vous permet d’ obtenir en

toute sécurité la dernière clé ou une clé spécifique avec un identificateur de clé d’un
compte Active Directory. Le service de distribution de clés partage un secret qui sert à
créer des clés pour le compte. Ces clés changent régulièrement. Pour un compte de
service administré de groupe, le contrôleur de domaine calcule le mot de passe sur la
clé fournie par les Services de distribution de clés en plus d’autres attributs du compte
de service administré de groupe. Les hôtes membres peuvent obtenir les valeurs de mot
de passe actuelles et précédentes en contactant un contrôleur de domaine.

Cas pratiques
Les comptes de service administrés de groupe fournissent une solution d’identité
unique pour les services qui s’exécutent dans une batterie de serveurs ou sur des
systèmes reposant sur un équilibrage de la charge réseau. En fournissant une solution
gMSA, vous pouvez configurer des services pour le nouveau principal gMSA tandis que
Windows gère la gestion des mots de passe.

Avec un compte de service administré de groupe, ni les services, ni les administrateurs

de services n’ont besoin de gérer la synchronisation des mots de passe entre les
instances de services. Le compte de service administré de groupe prend en charge les
hôtes qui sont maintenus hors connexion pour une durée prolongée, ainsi que la
gestion des hôtes membres pour toutes les instances d’un service. Vous pouvez
déployer une batterie de serveurs prenant en charge une identité unique auprès de
laquelle les ordinateurs clients existants peuvent s’authentifier sans avoir à connaître
l’instance de service à laquelle ils se connectent.

Les clusters de basculement ne prennent pas en charge les comptes de service

administrés de groupe (gMSA, group Managed Service Account). Toutefois, les services
qui s'exécutent sur le service de cluster peuvent utiliser un compte gMSA ou un compte
de service administré autonome (sMSA, standalone Managed Service Account) s'il s'agit
d'un service Windows, d'un pool d'applications, d'une tâche planifiée ou s'ils prennent
nativement en charge les comptes gMSA ou sMSA.

Configuration logicielle requise

Pour exécuter les commandes Windows PowerShell dont vous avez besoin pour
administrer des gMSA, vous devez disposer d’une architecture 64 bits.

Un compte de service administré dépend des types de chiffrement pris en charge par
Kerberos. Lorsqu’un ordinateur client s’authentifie auprès d’un serveur à l’aide de
Kerberos, le contrôleur de domaine crée un ticket de service Kerberos protégé par le
chiffrement pris en charge par le contrôleur de domaine et le serveur. Le contrôleur de
domaine utilise l’attribut msDS-SupportedEncryptionTypes du compte pour déterminer le
chiffrement pris en charge par le serveur. S’il n’y a pas d’attribut, il suppose que
l’ordinateur client ne prend pas en charge les types de chiffrement plus forts. Si vous
avez configuré l’hôte pour ne pas prendre en charge RC4, l’authentification échoue
toujours. Pour cette raison, vous devez toujours configurer AES pour les MSA.

７ Notes

À compter de Windows Server 2008 R2, DES est désactivé par défaut. Pour plus
d’informations sur les types de chiffrement pris en charge, voir Modifications
 apportées à l’authentification Kerberos.

Les comptes de service administrés de groupe ne s’appliquent pas aux systèmes

d’exploitation Windows antérieurs à Windows Server 2012.

Informations sur le Gestionnaire de serveur

Vous n’avez pas besoin d’effectuer de configuration supplémentaire pour implémenter
MSA et gMSA à l’aide du Gestionnaire de serveur ou de l’applet de commande Install-
WindowsFeature .

Étapes suivantes
Voici quelques autres ressources que vous pouvez lire pour en savoir plus sur les
comptes de service administrés :

Nouveautés des comptes de service administrés

Documentation sur les comptes de service administrés pour Windows 7 et
Windows Server 2008 R2
Guide pas à pas des comptes de service
Comptes de service administrés dans Active Directory
Prise en main des comptes de service administrés de groupe
Comptes de service administrés dans les services de domaine Active Directory
Comptes de service administrés : présentation, implémentation, recommandations
et dépannage
Vue d’ensemble d’Active Directory Domain Services

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Prise en main des comptes de service
administrés de groupe
Article • 01/08/2024

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Dans cet article, découvrez comment activer et utiliser des comptes de service administré de
groupe dans Windows Server.

Les protocoles d'authentification prenant en charge l'authentification mutuelle, tels que

Kerberos, peuvent être utilisés uniquement si toutes les instances des services utilisent le
même principal. Par exemple, lorsqu'un ordinateur client se connecte à un service qui utilise
l'équilibrage de charge ou une autre méthode où tous les serveurs semblent être le même
service pour le client. Cela signifie que chaque service doit utiliser les mêmes mots de passe
ou clés pour prouver son identité. Les comptes de services gérés par groupe (gMSA) sont un
type de compte qui peut être utilisé avec plusieurs serveurs. Un gMSA est un compte de
domaine qui peut être utilisé pour exécuter des services sur plusieurs serveurs sans avoir à
gérer le mot de passe. Le gMSA permet une gestion automatique des mots de passe et une
gestion simplifiée des noms de principaux services (SPN), y compris la délégation de la
gestion à d'autres administrateurs.

７ Notes

Les clusters de basculement ne prennent pas en charge les comptes de service

administrés de groupe (gMSA, group Managed Service Account). Toutefois, les services
qui s'exécutent sur le service de cluster peuvent utiliser un compte gMSA ou un compte
de service administré autonome (sMSA, standalone Managed Service Account) s'il s'agit
d'un service Windows, d'un pool d'applications, d'une tâche planifiée ou s'ils prennent
nativement en charge les comptes gMSA ou sMSA.

Les services peuvent choisir le principal à utiliser. Chaque type de principal prend en charge
des services différents et présente des limitations différentes.

ﾉ Agrandir le tableau

Principaux Services pris en charge Gestion des mots de passe

Compte d'ordinateur du Limité à un serveur joint à un Géré par l'ordinateur

système Windows domaine

Compte d'ordinateur sans Tout serveur joint à un domaine None

système Windows
 Principaux Services pris en charge Gestion des mots de passe

Compte virtuel Limité à un serveur Géré par l'ordinateur

Compte de service géré Limité à un serveur joint à un Géré par l'ordinateur

autonome Windows domaine

Compte d’utilisateur Tout serveur joint à un domaine None

Compte de service administré Tout serveur Windows Server Le contrôleur de domaine gère et
de groupe relié à un domaine l'hôte récupère

Un compte d'ordinateur Windows, un compte de service géré autonome Windows (sMSA) ou

des comptes virtuels ne peuvent pas être partagés entre plusieurs systèmes. Lorsque vous
utilisez des comptes virtuels, l'identité est également locale à la machine et n'est pas reconnue
par le domaine. Si vous configurez un compte à partager par les services de la batterie de
serveurs, vous devrez choisir un compte d'utilisateur ou un compte d'ordinateur en dehors
d'un système Windows. D'une manière ou d'une autre, ces comptes n'ont pas la capacité de
gérer les mots de passe à partir d'un point de contrôle unique. Sans gestion des mots de
passe, chaque organisation doit mettre à jour les clés du service dans Active Directory et
distribuer ces clés à toutes les instances de ces services.

Avec Windows Server, les services et les administrateurs de services n'ont pas besoin de gérer
la synchronisation des mots de passe entre les instances de services lorsqu'ils utilisent des
comptes de services gérés par groupe (gMSA). Vous créez le gMSA dans AD, puis vous
configurez le service qui prend en charge les comptes de service gérés. L’utilisation de gMSA
est limitée à n’importe quel ordinateur capable d’utiliser LDAP pour récupérer les informations
d’identification de gMSA. Vous pouvez créer un gMSA à l'aide des cmdlets New-
ADServiceAccount qui font partie du module Active Directory. Les services suivants prennent

en charge la configuration de l'identité du service sur l'hôte.

Mêmes API que sMSA, donc les produits qui prennent en charge sMSA prennent en
charge gMSA.

Services qui utilisent Service Control Manager pour configurer l'identité de connexion

Services qui utilisent le gestionnaire IIS pour les pools d'applications afin de configurer
l'identité

Les tâches qui utilisent le Planificateur de tâches

Prérequis
Le tableau suivant répertorie la configuration requise du système d'exploitation pour que
l'authentification Kerberos puisse fonctionner avec les services utilisant des comptes gMSA.
Les conditions requises pour Active Directory sont répertoriées à la suite de ce tableau.
Une architecture 64 bits est requise pour exécuter les commandes Windows PowerShell
utilisées pour administrer les comptes de service administrés de groupe.

Système d’exploitation

ﾉ Agrandir le tableau

Élément Exigence

Hôte d'application cliente Client Kerberos conforme aux RFC

Contrôleurs de domaine du domaine du KDC conforme aux RFC

compte d'utilisateur

Hôtes membres du service partagé

Contrôleurs de domaine du domaine de KDC conforme aux RFC

l'hôte membre

Contrôleurs de domaine du domaine du Contrôleurs de domaine Windows Server 2012 disponibles

compte gMSA pour que l'hôte puisse récupérer le mot de passe

Hôte de service principal Serveur d'application Kerberos conforme aux RFC

Contrôleurs de domaine du domaine du KDC conforme aux RFC

compte de service principal

Windows PowerShell pour Active Les outils de l'administrateur du serveur distant des services
Directory de domaine Active Directory

Services de domaine Active Directory

Les comptes de service gérés par groupe doivent remplir les conditions suivantes dans les
services de domaine Active Directory (AD DS).

Le niveau fonctionnel du domaine et de la forêt Active Directory doit être Windows

Server 2012 ou une version ultérieure. Pour en savoir plus sur la mise à jour du schéma,
reportez-vous à la section Relèvement des niveaux fonctionnels du domaine et de la
forêt Active Directory.

Si vous gérez l'autorisation de l'hôte de service à utiliser gMSA par groupe, alors groupe
de sécurité nouveau ou existant.

Si vous gérez le contrôle d'accès au service par groupe, alors groupe de sécurité
nouveau ou existant.

La clé racine des services de distribution de clés (KDS) pour Active Directory doit être
créée dans le domaine. Le résultat de sa création peut être vérifié dans le journal des
opérations du service KDS, Event ID 4004 Pour en savoir plus sur la création de la clé
 racine KDS, reportez-vous à la section Créer la clé racine KDS des services de distribution
de clés.

Pour obtenir des instructions sur la création de la clé, consultez Créer la clé racine KDS des
services de clés Active Directory. Le service de distribution de clés Microsoft ([Link]) crée la
clé racine pour Active Directory.

Déploiement d'une nouvelle batterie de serveurs

Le processus de création et de gestion d'une batterie de serveurs à l'aide de la fonctionnalité
gMSA implique généralement les tâches suivantes.

Déploiement d'une nouvelle batterie de serveurs

Ajout d'hôtes membres à une batterie de serveurs existante

Désaffectation d'hôtes membres d'une batterie de serveurs existante

Désaffectation d'une batterie de serveurs existante

Suppression d'un hôte membre compromis d'une batterie de serveurs, le cas échéant.

Lorsque l'administrateur du service déploie une nouvelle batterie de serveurs, il doit

déterminer les informations suivantes.

Le service prend en charge l'utilisation des gMSA

Le service nécessite des connexions authentifiées entrantes ou sortantes.

Les noms de comptes d'ordinateur des hôtes membres du service utilisant la

fonctionnalité gMSA

Le nom NetBIOS du service

Le nom d'hôte DNS du service

Les noms de principal du service (SPN) pour le service

L'intervalle de changement de mot de passe (30 jours par défaut)

Créer des comptes de services gérés par groupe

Vous pouvez créer un gMSA uniquement si le schéma de la forêt est Windows Server 2012 ou
une version ultérieure. Vous devez également déployer la clé racine KDS pour Active Directory
et disposer d'au moins un contrôleur de domaine Windows Server 2012 ou version ultérieure
dans le domaine où vous souhaitez créer un gMSA.
 ） Important

Les noms des comptes gMSA doivent être uniques au sein d'une forêt et pas seulement
d'un domaine. Toute tentative de création d'un compte gMSA avec un nom dupliqué
échouera, même dans des domaines différents.

Vous devez au minimum appartenir au groupe Admins du domaine, ou avoir la capacité de

créer des objets msDS-GroupManagedServiceAccount pour réaliser les procédures suivantes.

Pour créer un gMSA à l'aide de PowerShell, procédez comme suit.

1. Dans le contrôleur de domaine Windows Server 2012, exécutez Windows PowerShell à

partir de la barre des tâches.

2. À l'invite de commandes de Windows PowerShell, tapez les commandes suivantes et

appuyez sur Entrée : (Le module Active Directory se charge automatiquement.)

New-ADServiceAccount [-Name] <string> -DNSHostName <string> [-

KerberosEncryptionType <ADKerberosEncryptionType>] [-ManagedPasswordIntervalInDays

<Nullable[Int32]>] [-PrincipalsAllowedToRetrieveManagedPassword <ADPrincipal[]>] [-

SamAccountName <string>] [-ServicePrincipalNames <string[]>]

７ Notes

Une valeur pour le paramètre -Name est toujours requise (que vous spécifiez -Name
ou non), les paramètres -DNSHostName , -RestrictToSingleComputer et -
RestrictToOutboundAuthentication étant des exigences secondaires pour les trois

scénarios de déploiement.

ﾉ Agrandir le tableau

Paramètre String Exemple

Nom Nom du BatterieIT1

compte

DNSHostName Nom d'hôte [Link]

DNS du
service

KerberosEncryptionType Tout type de None, RC4, AES128, AES256

chiffrement
pris en
charge par les
serveurs
hôtes
 Paramètre String Exemple

ManagedPasswordIntervalInDays Intervalle de 90
modification
de mot de
passe
exprimé en
jours (la
valeur par
défaut est 30
jours)

PrincipalsAllowedToRetrieveManagedPassword Comptes HôtesBatterieIT

d'ordinateur
des hôtes
membres ou
groupe de
sécurité
auquel
appartiennent
les hôtes
membres

SamAccountName Nom NetBIOS BatterieIT1

du service s'il
est différent
de Name

ServicePrincipalNames Noms de http/[Link]/[Link],

principal du http/[Link]/contoso,
service (SPN) http/ITFarm1/[Link],
pour le http/ITFarm1/contoso,
service MSSQLSvc/[Link],
MSSQLSvc/[Link]:INST01

） Important

L'intervalle de modification de mot de passe ne peut être défini qu'à la création. Si

vous avez besoin de modifier l'intervalle, vous devez créer un nouveau compte
gMSA et définir l'intervalle au moment de la création.

Par exemple, pour créer un nouveau gMSA appelé ITFarm1 pour le groupe, utilisez la
commande suivante. La gMSA permet au service d'utiliser les types de chiffrement
Kerberos RC4, AES128 et AES256. Le service est autorisé à utiliser les SPN
http/[Link]/[Link] , http/[Link]/contoso ,
http/ITFarm1/[Link] et http/ITFarm1/contoso .

Entrez la commande sur une seule ligne, même si elle tient ici sur plusieurs lignes du fait
de contraintes de mise en forme.
 Powershell

New-ADServiceAccount ITFarm1 -DNSHostName [Link] -

PrincipalsAllowedToRetrieveManagedPassword ITFarmHosts$ -
KerberosEncryptionType RC4, AES128, AES256 -ServicePrincipalNames
http/[Link]/[Link], http/[Link]/contoso,
http/ITFarm1/[Link], http/ITFarm1/contoso

Vous devez au minimum appartenir au groupe Admins du domaine ou Opérateurs de

compte, ou avoir la capacité de créer des objets msDS-GroupManagedServiceAccount pour
réaliser les procédures suivantes. Pour plus d’informations sur l’utilisation des comptes et
appartenances à des groupes appropriés, voir Groupes de sécurité Active Directory.

Pour créer un gMSA pour l'authentification sortante uniquement à l'aide de PowerShell,

procédez comme suit.

1. Dans le contrôleur de domaine Windows Server 2012, exécutez Windows PowerShell à

partir de la barre des tâches.

2. À l'invite de commande du module Windows PowerShell Active Directory, utilisez la

commande suivante.

New-ADServiceAccount [-Name] <string> -RestrictToOutboundAuthenticationOnly [-

ManagedPasswordIntervalInDays <Nullable[Int32]>] [-

PrincipalsAllowedToRetrieveManagedPassword <ADPrincipal[]>]

L'exemple suivant crée un gMSA à l'aide des paramètres du tableau.

ﾉ Agrandir le tableau

Paramètre String Exemple

Nom Nom du compte BatterieIT1

ManagedPasswordIntervalInDays Intervalle de modification de 75

mot de passe exprimé en jours
(la valeur par défaut est 30
jours)

PrincipalsAllowedToRetrieveManagedPassword Comptes d'ordinateur des HôtesBatterieIT

hôtes membres ou groupe de
sécurité auquel appartiennent
les hôtes membres

） Important

L'intervalle de modification de mot de passe ne peut être défini qu'à la création. Si

vous avez besoin de modifier l'intervalle, vous devez créer un nouveau compte
 gMSA et définir l'intervalle au moment de la création.

L'exemple de commande utilisant ces paramètres est le suivant.

PowerShell

New-ADServiceAccount ITFarm1 -RestrictToOutboundAuthenticationOnly -

PrincipalsAllowedToRetrieveManagedPassword ITFarmHosts$

Configurer le service d'application d'identité

Pour configurer les services dans Windows Server, consultez les articles suivants :

Pool d'applications IIS

Pour plus d’informations, voir Spécifier une identité pour un pool d’applications (IIS 7).

services Windows

Pour plus d’informations, voir Services.

Tâches

Pour plus d’informations, voir la Vue d’ensemble du planificateur de tâches.

D'autres services peuvent prendre en charge la fonctionnalité gMSA. Reportez-vous à la

documentation produit spécifique pour plus d'informations sur la configuration de ces
services.

Ajouter des hôtes membres à une batterie de

serveurs existante
Si vous utilisez des groupes de sécurité pour gérer les hôtes membres, ajoutez le compte
d'ordinateur du nouvel hôte membre au groupe de sécurité (auquel appartiennent les hôtes
membres du compte gMSA) en utilisant l'une des méthodes suivantes.

Vous devez au minimum appartenir au groupe Admins du domaine ou avoir la capacité

d'ajouter des membres à l'objet de groupe de sécurité pour réaliser ces procédures.

Méthode 1 : Utilisateurs et ordinateurs Active Directory

Pour connaître les procédures d’utilisation de cette méthode, voir Ajouter un compte
d’ordinateur à un groupe et Gérer des domaines différents dans le Centre
d’administration Active Directory.

Méthode 2 : dsmod
 Pour connaître les procédures d’utilisation de cette méthode, voir Ajouter un compte
d’ordinateur à un groupe à l’aide de la ligne de commande.

Méthode 3 : Applet de commande Windows PowerShell Active Directory Add-

ADPrincipalGroupMembership

Pour connaître les procédures d’utilisation de cette méthode, voir Add-

ADPrincipalGroupMembership.

Si vous utilisez des comptes d'ordinateur, recherchez les comptes existants et ajoutez le
nouveau compte d'ordinateur.

Vous devez au minimum appartenir au groupe Admins du domaine ou Opérateurs de

compte, ou avoir la capacité de gérer des objets msDS-GroupManagedServiceAccount pour
réaliser les procédures suivantes. Pour plus d'informations sur l'utilisation des comptes et
appartenances à des groupes appropriés, voir Groupes locaux et de domaine par défaut.

Ajouter des hôtes membres à l'aide de PowerShell

1. Dans le contrôleur de domaine Windows Server 2012, exécutez Windows PowerShell à
partir de la barre des tâches.

2. À l'invite de commandes du module Active Directory pour Windows PowerShell, tapez

les commandes suivantes et appuyez sur Entrée :

Get-ADServiceAccount [-Identity] <string> -Properties

PrincipalsAllowedToRetrieveManagedPassword

3. À l'invite de commandes du module Active Directory pour Windows PowerShell, tapez

les commandes suivantes et appuyez sur Entrée :

Set-ADServiceAccount [-Identity] <string> -

PrincipalsAllowedToRetrieveManagedPassword <ADPrincipal[]>

L'exemple suivant ajoute un membre à une batterie de serveurs en utilisant les paramètres du
tableau.

ﾉ Agrandir le tableau

Paramètre String Exemple

Nom Nom du compte BatterieIT1

PrincipalsAllowedToRetrieveManagedPassword Comptes d'ordinateur des hôtes Hôte1,

membres ou groupe de sécurité auquel Hôte2, Hôte3
appartiennent les hôtes membres

L'exemple suivant permet d'obtenir les membres actuels de la ferme ITFarm1 .

 PowerShell

Get-ADServiceAccount [-Identity] ITFarm1 -Properties

PrincipalsAllowedToRetrieveManagedPassword

L'exemple suivant ajoute des hôtes membres à une batterie de serveurs existante ITFarm1 .

PowerShell

Set-ADServiceAccount [-Identity] ITFarm1 -

PrincipalsAllowedToRetrieveManagedPassword Host1$,Host2$,Host3$

Mise à jour des propriétés du compte de service

administré de groupe
Vous devez au minimum appartenir au groupe Admins du domaine ou Opérateurs de
compte, ou avoir la capacité d'écrire dans des objets msDS-GroupManagedServiceAccount
pour réaliser ces procédures.

Ouvrez le module Active Directory pour Windows PowerShell et définissez n'importe quelle
propriété à l'aide de la cmdlet Set-ADServiceAccount

Pour plus d’informations sur la définition de ces propriétés, voir Set-ADServiceAccount dans la
Bibliothèque TechNet ou tapez Get-Help Set-ADServiceAccount à l’invite de commandes du
module Active Directory pour Windows PowerShell et appuyez sur ENTRÉE.

Supprimer un hôte membre d'une batterie de

serveurs existante
Vous devez au minimum appartenir au groupe Admins du domaine ou avoir la capacité de
supprimer des membres de l'objet de groupe de sécurité pour réaliser ces procédures.

Si vous utilisez des groupes de sécurité pour gérer les hôtes membres, supprimez le compte
d'ordinateur de l'hôte membre désaffecté du groupe de sécurité auquel les hôtes membres du
compte gMSA appartiennent en utilisant l'une des méthodes suivantes.

Méthode 1 : Utilisateurs et ordinateurs Active Directory

Pour connaître les procédures d’utilisation de cette méthode, voir Supprimer un compte
d’ordinateur à l’aide de l’interface Windows et Gérer des domaines différents dans le
Centre d’administration Active Directory.

Méthode 2 : drsm
 Pour connaître les procédures d’utilisation de cette méthode, voir Supprimer un compte
d’ordinateur à l’aide de la ligne de commande.

Méthode 3 : Applet de commande Active Directory pour Windows PowerShell Remove-

ADPrincipalGroupMembership

Pour obtenir des informations détaillées sur la manière de supprimer un membre du

compte de service géré par le groupe, consultez Remove-ADPrincipalGroupMembership
dans la Bibliothèque TechNet ou tapez Get-Help Remove-
ADPrincipalGroupMembership à l’invite de commandes du module Active Directory
pour Windows PowerShell et appuyez sur ENTRÉE.

Si la liste des comptes d'ordinateur est affichée, récupérez les comptes existants, puis ajoutez
tous les comptes sauf le compte d'ordinateur supprimé.

Vous devez au minimum appartenir au groupe Admins du domaine ou Opérateurs de

compte, ou avoir la capacité de gérer des objets msDS-GroupManagedServiceAccount pour
réaliser les procédures suivantes. Pour plus d'informations sur l'utilisation des comptes et
appartenances à des groupes appropriés, voir Groupes locaux et de domaine par défaut.

Supprimer des hôtes membres à l'aide de PowerShell

1. Dans le contrôleur de domaine Windows Server 2012, exécutez Windows PowerShell à
partir de la barre des tâches.

2. À l'invite de commandes du module Active Directory pour Windows PowerShell, tapez

les commandes suivantes et appuyez sur Entrée :

Get-ADServiceAccount [-Identity] <string> -Properties

PrincipalsAllowedToRetrieveManagedPassword

3. À l'invite de commandes du module Active Directory pour Windows PowerShell, tapez

les commandes suivantes et appuyez sur Entrée :

Set-ADServiceAccount [-Identity] <string> -

PrincipalsAllowedToRetrieveManagedPassword <ADPrincipal[]>

L'exemple suivant supprime un membre d'une batterie de serveurs en utilisant les paramètres
du tableau.

ﾉ Agrandir le tableau

Paramètre String Exemple

Nom Nom du compte BatterieIT1

 Paramètre String Exemple

PrincipalsAllowedToRetrieveManagedPassword Comptes d'ordinateur des hôtes Host1,

membres ou groupe de sécurité auquel Host3
appartiennent les hôtes membres

L'exemple suivant permet d'obtenir les membres actuels de la ferme ITFarm1 .

PowerShell

Get-ADServiceAccount [-Identity] ITFarm1 -Properties

PrincipalsAllowedToRetrieveManagedPassword

L'exemple suivant supprime les hôtes membres d'une batterie de serveurs existante ITFarm1 .

PowerShell

Set-ADServiceAccount [-Identity] ITFarm1 -

PrincipalsAllowedToRetrieveManagedPassword Host1$,Host3$

Supprimer un compte de service géré de groupe du système

Supprimez les informations d'identification de compte gMSA mises en cache de l'hôte
membre à l'aide de Uninstall-ADServiceAccount ou de l'API NetRemoveServiceAccount sur le
système hôte.

Vous devez au minimum appartenir au groupe Administrateurs ou à un groupe équivalent

pour réaliser ces procédures.

Supprimer un gMSA à l'aide de PowerShell

1. Dans le contrôleur de domaine Windows Server 2012, exécutez Windows PowerShell à
partir de la barre des tâches.

2. À l'invite de commandes du module Active Directory pour Windows PowerShell, tapez

les commandes suivantes et appuyez sur Entrée :

Uninstall-ADServiceAccount <ADServiceAccount>

L'exemple suivant désinstalle un compte de service géré Active Directory d'un

ordinateur.

PowerShell

Uninstall-ADServiceAccount ITFarm1
Pour plus d’informations sur l’applet de commande Uninstall-ADServiceAccount, à l’invite de
commandes du module Active Directory pour Windows PowerShell, tapez Get-Help Uninstall-
ADServiceAccountet appuyez sur ENTRÉE ou consultez Uninstall-ADServiceAccountdans la
Bibliothèque TechNet.

Contenu connexe
Vue d’ensemble des comptes de service administrés de groupe

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Créer la clé racine du service de
distribution de clés (KDS, Key
Distribution Service)
Article • 01/08/2024

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cet article destiné aux professionnels de l'informatique décrit comment créer une clé
racine du Service de distribution de clés Microsoft ([Link]) sur le contrôleur de
domaine en utilisant Windows PowerShell pour générer des mots de passe de compte
de service administré de groupe (gMSA, group Managed Service Account) dans
Windows Server 2012 ou ultérieur.

Les contrôleurs de domaine ont besoin d'une clé racine pour commencer à générer des
mots de passe de compte gMSA. Les contrôleurs de domaine n'autoriseront la création
d'un compte gMSA que 10 heures après la création d'une clé racine pour permettre à
tous les contrôleurs de domaine de converger leur réplication Active Directory. Attendre
jusqu’à 10 heures est une mesure de sécurité visant à empêcher la génération de mots
de passe avant que tous les contrôleurs de domaine de l’environnement ne soient en
mesure de répondre aux demandes de compte gMSA. Une tentative précoce
d’utilisation d’un compte gMSA peut échouer lorsque l’hôte gMSA tente de récupérer le
mot de passe, car la clé n’a peut-être pas été répliquée sur tous les contrôleurs de
domaine. Les échecs de récupération de mot de passe gMSA peuvent également se
produire lors de l’utilisation de contrôleurs de domaine avec des planifications de
réplication limitées ou en cas de problème de réplication.

７ Notes

La suppression et la recréation de la clé racine peuvent entraîner des problèmes où

l’ancienne clé continue d’être utilisée après la suppression en raison de la mise en
cache de la clé. Le service de distribution de clés (KDC) doit être redémarré sur tous
les contrôleurs de domaine si la clé racine est recréée.

Vous devez appartenir au groupe Admins du domaine ou Administrateurs de

l'entreprise, ou à un groupe équivalent, pour réaliser cette procédure. Pour plus
d’informations sur l’utilisation des comptes et appartenances à des groupes appropriés,
voir Groupes locaux et de domaine par défaut.
 ７ Notes

Une architecture 64 bits est requise pour exécuter les commandes Windows
PowerShell utilisées pour administrer les comptes de service administrés de groupe.

Créer la clé racine KDS à l'aide de l'applet de commande Add-

KdsRootKey

1. Sur le contrôleur de domaine Windows Server 2012 ou ultérieur, exécutez le

Windows PowerShell à partir de la barre des tâches.

2. À l'invite de commandes du module Active Directory pour Windows PowerShell,

tapez les commandes suivantes et appuyez sur Entrée :

Add-KdsRootKey -EffectiveImmediately

 Conseil

Le paramètre Heure d'effectivité peut être utilisé pour laisser le temps aux clés
d'être propagées sur tous les contrôleurs de domaine avant leur utilisation.
L’utilisation d’Add-KdsRootKey -EffectiveImmediately ajoutera une clé racine
au contrôleur de domaine cible qui sera immédiatement utilisée par le service
KDS. Toutefois, les autres contrôleurs de domaine ne pourront pas utiliser la
clé racine jusqu'à ce que la réplication ait réussi.

Les clés racines KDS sont stockées dans Active Directory dans le conteneur CN=Master
Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=<forest

name>; . Elles ont un msKds-DomainID d’attribut qui lie au compte d’ordinateur du

contrôleur de domaine qui a créé l’objet. Lorsque ce contrôleur de domaine est

rétrogradé et supprimé du domaine, la valeur fait référence à la désactivation du
compte d’ordinateur. Vous pouvez ignorer la valeur rompue, car elle est utilisée
uniquement pour aider l’administrateur à suivre l’objet lorsqu’il est fraîchement créé.
Vous pouvez également modifier la valeur d’attribut et le pointer vers l’objet ordinateur
d’un autre contrôleur de domaine dans votre forêt.

Dans les environnements de test à contrôleur de domaine unique, vous pouvez créer
une clé racine KDS et définir l'heure de début sur une heure passée afin d'éviter
l'intervalle d'attente avant la génération de clés. Utilisez pour cela procédure suivante.
Vérifiez qu'un événement 4004 a été consigné dans le journal des événements KDS.
Pour créer la clé racine KDS dans un environnement de test et faire
qu'elle soit immédiatement effective

1. Sur le contrôleur de domaine Windows Server 2012 ou ultérieur, exécutez le

Windows PowerShell à partir de la barre des tâches.

2. À l'invite de commandes du module Active Directory pour Windows PowerShell,

tapez les commandes suivantes et appuyez sur Entrée :

$a=Get-Date

$b=$[Link](-10)

Add-KdsRootKey -EffectiveTime $b

Ou utilisez une commande unique

Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))

Voir aussi
Prise en main des comptes de service administrés de groupe

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Configuration de la délégation Kerberos
pour les comptes de service administrés
de groupe
Article • 01/08/2024

Normalement, lorsque vous utilisez la délégation Kerberos, vous définissez simplement

le nom du principal de service (SPN) avec la commande [Link] ou manuellement
avec l’éditeur d’attribut dans Utilisateurs et ordinateurs Active Directory. En outre, le fait
d’activer Affichage>Fonctionnalités avancées dans Utilisateurs et ordinateurs Active
Directory permet d’ajouter une autre façon de configurer la délégation Kerberos à partir
de l’onglet Délégation d’un compte d’utilisateur ou d’ordinateur.

Mais, pour les comptes de service administrés autonomes et de groupe, l’onglet

Délégation n’apparaît pas, même après avoir ajouté des SPN à ces comptes ou avoir
activé Affichage>Fonctionnalités avancées.

Pour configurer une délégation pour ces comptes spéciaux, vous avez besoin de définir
manuellement les attributs appropriés. Vous devez modifier deux attributs pour ces
comptes :

userAccountControl définit le type de délégation.

msDS-AllowedToDelegateTo définit l’emplacement où les SPN sont ajoutés pour la
délégation.

Ces attributs peuvent être définis de différentes manières :

Utiliser PowerShell
Mise à jour manuelle de la valeur userAccountControl

Utilisation de commandes PowerShell

La méthode la plus sûre et la plus pratique consiste à utiliser des commandes
PowerShell pour mettre à jour ces attributs. Vous n’avez pas besoin de calculer les
valeurs userAccountControl finales quand vous utilisez PowerShell. Voici les commandes
permettant d’activer différents types de délégation :

Ne pas approuver cet ordinateur pour la délégation

PowerShell
 Set-ADAccountControl -Identity TestgMSA$ -TrustedForDelegation $false -
TrustedToAuthForDelegation $false
Set-ADServiceAccount -Identity TestgMSA$ -Clear 'msDS-
AllowedToDelegateTo'

Délégation non contrainte/Approuver cet ordinateur pour la délégation à tous

les services

PowerShell

Set-ADAccountControl -Identity TestgMSA$ -TrustedForDelegation $true -

TrustedToAuthForDelegation $false
Set-ADServiceAccount -Identity TestgMSA$ -Clear 'msDS-
AllowedToDelegateTo'

Délégation Kerberos contrainte/N’approuver cet ordinateur que pour la

délégation aux services spécifiés (Utiliser Kerberos uniquement)

PowerShell

Set-ADAccountControl -Identity TestgMSA$ -TrustedForDelegation $false -

TrustedToAuthForDelegation $false

Mettez à jour les SPN du service back-end dans l’attribut msDS-

AllowedToDelegateTo.

Délégation Kerberos contrainte avec transition de protocole/N’approuver cet

ordinateur que pour la délégation aux services spécifiés (Utiliser tout protocole
d’authentification)

PowerShell

Set-ADAccountControl -Identity TestgMSA$ -TrustedForDelegation $false -

TrustedToAuthForDelegation $true

Mettez à jour les SPN du service back-end dans l’attribut msDS-

AllowedToDelegateTo.

Mise à jour manuelle de la valeur

userAccountControl
Parmi les moyens les plus simples de modifier les attributs figure l’activation
d’Affichage>Fonctionnalités avancées dans Utilisateurs et ordinateurs Active Directory
ou à l’aide d’[Link].

Voici les valeurs userAccountControl pouvant être ajoutées pour différents types de
délégation. Faites preuve de prudence quand vous modifiez cette valeur d’attribut et
assurez-vous que seuls les indicateurs TRUSTED_FOR_DELEGATION ou
TRUSTED_TO_AUTH_FOR_DELEGATION sont ajoutés et que les autres propriétés ne sont
pas modifiées. De plus, vérifiez que les deux indicateurs ne sont pas ajoutés ensemble
dans la valeur userAccountControl sur un compte de service administré.

ﾉ Agrandir le tableau

Type de délégation Indicateur de propriété Valeur au Valeur au

format format
hexadécimal décimal

Délégation non TRUSTED_FOR_DELEGATION 0x80000 524 288

contrainte/Approuver cet
ordinateur pour la
délégation à tous les
services

Délégation Kerberos Aucune modification Aucune Aucune

contrainte/N’approuver modification modification
cet ordinateur que pour
la délégation aux
services spécifiés (Utiliser
Kerberos uniquement)

Délégation Kerberos TRUSTED_TO_AUTH_FOR_DELEGATION 0x1000000 16 777 216

contrainte avec transition
de
protocole/N’approuver
cet ordinateur que pour
la délégation aux
services spécifiés (Utiliser
tout protocole
d’authentification)

Lorsque vous mettez à jour manuellement la valeur userAccountControl, vérifiez que la

nouvelle valeur est ajoutée avec la valeur existante, qui n’est pas remplacée. Par
exemple, considérez que la valeur actuelle de UAC est 4096 (hex 0x1000), ce qui
correspond à WORKSTATION_TRUST_ACCOUNT.
Pour activer une délégation non contrainte (non sécurisée), vous devez ajouter la
valeur userAccountControl pour TRUSTED_FOR_DELEGATION plus la valeur existante. La
valeur UAC doit devenir 0x81000 (0x1000 + 0x80000), ce qui signifie
WORKSTATION_TRUST_ACCOUNT et TRUSTED_FOR_DELEGATION.

Si vous avez ajouté certains SPN par erreur ou si vous souhaitez supprimer certains SPN
de la liste de délégation du compte, vous pouvez modifier manuellement l’attribut
msDS-AllowedToDelegateTo du compte. Cette méthode s’applique à tout compte
d’utilisateur ou d’ordinateur.
Étape suivante
Vue d’ensemble des comptes de service administrés de groupe
Bien démarrer avec les comptes de service administrés de groupe

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Kerberos Authentication Overview
Article • 17/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Kerberos est un protocole d’authentification utilisé pour vérifier l’identité d’un utilisateur
ou d’un hôte. Cette rubrique contient des informations sur l’authentification Kerberos
dans Windows Server 2012 et Windows 8.

Description de la fonctionnalité
Les systèmes d’exploitation Windows Server implémentent le protocole
d’authentification Kerberos version 5 et des extensions pour l’authentification des clés
publiques, les données d’autorisation de transport et la délégation. Le client
d’authentification Kerberos est implémenté en tant que fournisseur SSP (Security
Support Provider) et est accessible par le biais de l’interface SSPI (Security Support
Provider Interface). L’authentification utilisateur initiale est intégrée à l’architecture à
authentification unique Winlogon.

Le centre de distribution de clés Kerberos est intégré à d’autres services de sécurité

Windows Server qui s’exécutent sur le contrôleur de domaine. Le contrôleur de domaine
Kerberos (KDC) utilise la base de données Active Directory Domain Services (AD DS)
comme base de données de son compte de sécurité. Les services de domaine Active
Directory (AD DS) sont requis pour les implémentations Kerberos par défaut au sein du
domaine ou de la forêt.

Cas pratiques
Les avantages offerts par l’authentification basée sur un domaine Kerberos sont les
suivants :

Authentification déléguée.

Les services qui s’exécutent sur des systèmes d’exploitation Windows peuvent
emprunter l’identité d’un ordinateur client lors de l’accès à des ressources au nom
du client. Dans de nombreux cas, un service peut effectuer son travail pour le client
en accédant aux ressources de l’ordinateur local. Lorsqu’un ordinateur client
s’authentifie auprès du service, les protocoles NTLM et Kerberos fournissent les
informations d’autorisation dont un service a besoin pour emprunter l’identité de
l’ordinateur client localement. Toutefois, certaines applications distribuées sont
conçues de telle sorte qu’un service frontal est obligé d’utiliser l’identité de
l’ordinateur client lorsqu’il se connecte à des services principaux sur d’autres
ordinateurs. L’authentification Kerberos prend en charge un mécanisme de
délégation qui permet à un service d’agir au nom de son client lors de la
connexion à d’autres services.

Authentification unique.

L’utilisation de l’authentification Kerberos dans un domaine ou dans une forêt

permet à l’utilisateur ou au service d’accéder aux ressources autorisées par les
administrateurs en évitant plusieurs demandes d’informations d’identification.
Après l’authentification initiale de domaine via Winlogon, Kerberos gère les
informations d’identification dans la forêt lors de chaque tentative d’accès aux
ressources.

Interopérabilité.

L’implémentation par Microsoft du protocole Kerberos V5 est basée sur des

spécifications normatives faisant l’objet de recommandations auprès du groupe de
travail IETF. Par conséquent, dans les systèmes d’exploitation Windows, le
protocole Kerberos pose les bases d’une interopérabilité avec les autres réseaux où
il est utilisé à des fins d’authentification. En outre, Microsoft publie la
documentation relative aux protocoles Windows pour l’implémentation du
protocole Kerberos. Cette documentation contient les spécifications techniques, les
limitations, les dépendances et le comportement du protocole spécifique de
Windows pour l’implémentation Microsoft du protocole Kerberos.

Authentification plus efficace auprès des serveurs.

Avant Kerberos, il était possible d’utiliser l’authentification NTLM, qui requiert un

serveur d’applications pour se connecter à un contrôleur de domaine afin
d’authentifier chaque ordinateur ou service client. Avec le protocole Kerberos, les
tickets de session renouvelables remplacent l’authentification directe. Le serveur
n’est pas requis pour accéder à un contrôleur de domaine (à moins qu’il doive
valider un certificat PAC (Privilege Attribute Certificate). Au lieu de cela, le serveur
peut authentifier l’ordinateur client en examinant les informations d’identification
présentées par le client. Les ordinateurs clients peuvent obtenir des informations
d’identification pour un serveur en particulier et les réutiliser au cours d’une
session de connexion réseau.

Authentification mutuelle.
 À l’aide du protocole Kerberos, chacune des parties situées à chaque extrémité
d’une connexion réseau peut vérifier que la partie distante est bien l’entité qu’elle
prétend être. NTLM ne permet pas aux clients de vérifier l’identité d’un serveur ou
à un serveur de vérifier l’identité d’un autre. L’authentification NTLM a été conçue
pour un environnement réseau dans lequel les serveurs sont considérés comme
authentiques. Le protocole Kerberos n’utilise pas ce genre d’hypothèse.

Voir aussi
Vue d’ensemble de l’authentification Windows
Nouveautés de Windows Server 2016
Article • 05/08/2024

Cet article décrit les nouvelles fonctionnalités de Windows Server 2016 qui sont
susceptibles d'avoir l'impact le plus important lorsque vous utilisez cette version.

Calcul
La zone Virtualisation contient des fonctionnalités et produits de virtualisation que les
professionnels de l’informatique peuvent utiliser pour la conception, le déploiement et
la maintenance de Windows Server.

Général
Les machines physiques et virtuelles bénéficient d’une plus grande précision du temps
en raison des améliorations apportées aux services Synchronisation date/heure de
Hyper-V et de Win32. Windows Server peut désormais héberger des services qui sont
conformes aux réglementations à venir qui exigent une précision égale à 1 ms en ce qui
concerne l’heure UTC.

Hyper-V
La virtualisation du réseau Hyper-V (HNV) est un élément fondamental de la nouvelle
solution SDN (Software Defined Networking) de Microsoft et est entièrement intégrée
dans la pile SDN. Windows Server 2016 inclut les changements suivants pour Hyper-V :

Windows Server 2016 inclut désormais un commutateur Hyper-V programmable.

Le contrôleur de réseau de Microsoft pousse les stratégies HNV vers le bas jusqu'à
un agent d'hôte qui s'exécute sur chaque hôte en utilisant le protocole de gestion
de base de données Open vSwitch (OVSDB) en tant qu'interface SouthBound
(SBI). L’agent hôte stocke cette stratégie à l’aide d’une personnalisation du schéma
VTEP et programme des règles de flux complexes dans un moteur de flux
performant dans le commutateur Hyper-V. Le moteur de flux du commutateur
Hyper-V est le même que celui utilisé par Azure. L'ensemble de la pile SDN
jusqu'au contrôleur de réseau et au fournisseur de ressources réseau est
également conforme à Azure, ce qui rend ses performances comparables à celles
du cloud public Azure. Dans le moteur de flux de Microsoft, le commutateur
Hyper-V est équipé pour gérer les règles de flux avec et sans état par le biais d'un
simple mécanisme de correspondance qui définit comment les paquets doivent
être traités dans le commutateur.

HNV prend désormais en charge l'encapsulation du protocole Virtual eXtensible

Local Area Network (VXLAN) . HNV utilise le protocole VXLAN en mode de
distribution MAC par l'intermédiaire du contrôleur de réseau Microsoft pour
mapper les adresses IP du réseau global du locataire aux adresses IP du réseau
physique sous-jacent. Les décharges de tâches NVGRE et VXLAN prennent en
charge des pilotes tiers pour améliorer les performances.

Windows Server 2016 inclut un équilibreur de charge logiciel (SLB) avec une prise
en charge complète du trafic de réseau virtuel et une interaction transparente avec
HNV. Le moteur de flux performant met en œuvre le SLB dans le v-Switch du plan
de données, puis le contrôleur de réseau le contrôle pour les mappages IP virtuels
(VIP) ou IP dynamiques (DIP).

HNV implémente des en-têtes Ethernet L2 corrects pour garantir l’interopérabilité

avec des appliances virtuelles et physiques tierces qui dépendent de protocoles
standard du secteur. Microsoft s'assure que tous les paquets transmis ont des
valeurs conformes dans tous les champs pour garantir l'interopérabilité. HNV
nécessite la prise en charge des trames Jumbo (MTU > 1780) dans le réseau
physique L2 pour tenir compte de la surcharge des paquets introduite par les
protocoles d'encapsulation tels que NVGRE et VXLAN. La prise en charge des
trames Jumbo garantit que les machines virtuelles invitées attachées à un réseau
virtuel HNV conservent une MTU de 1514.

La prise en charge des conteneurs Windows ajoute des améliorations de

performance, une gestion simplifiée du réseau et une prise en charge des
conteneurs Windows sur Windows 10. Pour plus d'informations, consultez notre
documentation sur les conteneurs Windows et les conteneurs : Docker, Windows
et les tendances .

Hyper-V est désormais compatible avec Connected Standby. Lorsque vous installez
le rôle Hyper-V sur un ordinateur qui utilise le modèle d'alimentation Always
On/Always Connected (AOAC), vous pouvez désormais le configurer pour qu'il
utilise l'état d'alimentation Connected Standby.

L'attribution de périphériques discrets vous permet de donner à une machine

virtuelle (VM) un accès direct et exclusif à certains périphériques matériels PCIe.
Cette fonctionnalité contourne la pile de virtualisation Hyper-V, ce qui permet un
accès plus rapide. Pour plus d'informations, voir Affectation de périphériques
discrets et Affectation de périphériques discrets - Description et contexte .
Hyper-V prend désormais en charge le chiffrement BitLocker des disques du
système d'exploitation dans les machines virtuelles de génération 1. Cette
méthode de protection remplace les modules TPM (Trusted Platform Modules)
virtuels, qui ne sont disponibles que dans les machines virtuelles de génération 2.
Pour décrypter le disque et démarrer la VM, l'hôte Hyper-V doit soit faire partie
d'une structure surveillée autorisée, soit disposer de la clé privée de l'un des
gardiens de la VM. Le stockage des clés nécessite une VM version 8. Pour plus
d'informations, reportez-vous à la section Mise à niveau de la version de la
machine virtuelle dans Hyper-V sur Windows ou Windows Server.

La protection des ressources de l'hôte empêche les machines virtuelles d'utiliser

trop de ressources système en surveillant les niveaux d'activité excessifs. Lorsque la
surveillance détecte un niveau d'activité anormalement élevé dans une VM, elle
limite la quantité de ressources consommées par la VM. Vous pouvez activer cette
fonctionnalité en exécutant la cmdlet Set-VMProcessor dans PowerShell.

Vous pouvez désormais utiliser l'ajout ou la suppression à chaud pour ajouter ou

supprimer des adaptateurs réseau pendant que la VM est en cours d'exécution,
sans temps d'arrêt, dans les VM de génération 2 exécutant les systèmes
d'exploitation Linux ou Windows. Vous pouvez également ajuster la quantité de
mémoire attribuée à une VM en cours d'exécution, même si vous n'avez pas activé
la mémoire dynamique sur les VM de génération 1 et 2 exécutant Windows Server
2016 et versions ultérieures ou Windows 10 et versions ultérieures.

Hyper-V Manager prend désormais en charge les fonctionnalités suivantes :

Les informations d'identification alternatives, qui vous permettent d'utiliser un

ensemble différent d'informations d'identification dans Hyper-V Manager lors
de la connexion à un autre hôte distant Windows Server 2016 ou Windows 10.
Vous pouvez également enregistrer ces informations d'identification pour
faciliter la connexion.

Vous pouvez désormais gérer Hyper-V sur des machines exécutant Windows
Server 2012 R2, Windows Server 2012, Windows 8.1 et Windows 8.

Hyper-V Manager communique désormais avec les hôtes Hyper-V distants à

l'aide du protocole WS-MAN, qui permet l'authentification CredSSP, Kerberos et
NTLM. Lorsque vous utilisez CredSSP pour vous connecter à un hôte Hyper-V
distant, vous pouvez effectuer une migration en direct sans activer la délégation
restreinte dans Active Directory. WS-MAN facilite également l'activation des
hôtes pour la gestion à distance. WS-MAN se connecte par le biais du port 80
qui est ouvert par défaut.
Les mises à jour des services d'intégration pour les invités Windows sont
désormais distribuées via Windows Update. Les fournisseurs de services et les
hôtes de nuages privés peuvent donner aux locataires qui possèdent les machines
virtuelles le contrôle de l'application des mises à jour. Les locataires Windows
peuvent désormais mettre à jour leurs machines virtuelles avec toutes les dernières
mises à jour par le biais d'une méthode unique. Pour plus d'informations sur la
façon dont les locataires Linux peuvent utiliser les services d'intégration, consultez
Machines virtuelles Linux et FreeBSD prises en charge pour Hyper-V sur Windows
Server et Windows.

） Important

Hyper-V pour Windows Server 2016 n'inclut plus le fichier image [Link]
car il n'est plus nécessaire.

Les systèmes d'exploitation Linux exécutés sur des VM de génération 2 peuvent

désormais démarrer avec l'option Secure Boot activée. Les systèmes d'exploitation
qui prennent en charge Secure Boot sur les hôtes Windows Server 2016
comprennent Ubuntu 14.04 et versions ultérieures, SUSE Linux Enterprise Server 12
et versions ultérieures, Red Hat Enterprise Linux 7.0 et versions ultérieures, et
CentOS 7.0 et versions ultérieures. Avant de démarrer la VM pour la première fois,
vous devez la configurer pour qu'elle utilise l'autorité de certification Microsoft
UEFI dans Hyper-V Manager, Virtual Machine Manager ou en exécutant la cmdlet
Set-VMFirmware dans PowerShell.

Les machines virtuelles et les hôtes Hyper-V de génération 2 peuvent désormais

utiliser beaucoup plus de mémoire et de processeurs virtuels. Vous pouvez
également configurer les hôtes avec plus de mémoire et de processeurs virtuels
que les versions précédentes. Ces modifications prennent en charge des scénarios
tels que l'exécution de grandes bases de données en mémoire pour le traitement
des transactions en ligne (OLTP) et l'entreposage de données (DW) pour le
commerce électronique. Pour plus d'informations, consultez les performances des
VM Windows Server 2016 Hyper-V à grande échelle pour le traitement des
transactions en mémoire . Pour en savoir plus sur la compatibilité des versions et
les configurations maximales prises en charge, consultez Mise à niveau de la
version de la machine virtuelle dans Hyper-V sur Windows ou Windows Server et
Planification de l'évolutivité d'Hyper-V dans Windows Server.

La fonction de virtualisation imbriquée vous permet d'utiliser une VM comme hôte

Hyper-V et de créer des VM au sein de l'hôte virtualisé. Vous pouvez utiliser cette
fonctionnalité pour créer des environnements de développement et de test
exécutant au moins Windows Server 2016 ou Windows 10 avec un processeur
compatible Intel VT-x. Pour plus d'informations, consultez la section Qu'est-ce que
la virtualisation imbriquée ?

Vous pouvez désormais configurer des points de contrôle de production pour vous
conformer aux politiques de support des VM exécutant des charges de travail de
production. Ces points de contrôle s'exécutent sur la technologie de sauvegarde à
l'intérieur du périphérique invité au lieu d'un état sauvegardé. Les machines
virtuelles Windows utilisent le service de cliché instantané de volume (VSS), tandis
que les machines virtuelles Linux rincent les tampons du système de fichiers pour
créer des points de contrôle cohérents avec le système de fichiers. Vous pouvez
toujours utiliser des points de contrôle basés sur des états sauvegardés en utilisant
des points de contrôle standard à la place. Pour plus d'informations, voir Choisir
entre les points de contrôle standard ou de production dans Hyper-V.

） Important

Les nouvelles machines virtuelles utilisent les points de contrôle de

production par défaut.

Vous pouvez désormais redimensionner les disques durs virtuels partagés (fichiers
.vhdx ) pour le clustering invité sans temps d'arrêt. Vous pouvez également utiliser

les clusters invités pour protéger les disques durs virtuels partagés en utilisant
Hyper-V Replica pour la reprise après sinistre. Vous ne pouvez utiliser cette
fonctionnalité que sur les collections d'un cluster invité pour lequel vous avez
activé la réplication via Windows Management Instrumentation (WMI). Pour plus
d'informations, voir la classe Msvm_CollectionReplicationService et la présentation
du partage des disques durs virtuels.

７ Notes

La gestion de la réplication d'une collection n'est pas possible via les cmdlets
PowerShell ou l'interface WMI.

Lors de la sauvegarde d'une seule machine virtuelle, nous ne recommandons pas

l'utilisation d'un groupe de VM ou d'une collection d'instantanés, que l'hôte soit en
cluster ou non. Ces options sont destinées à la sauvegarde de clusters d'invités qui
utilisent un vhdx partagé. Nous vous recommandons plutôt de prendre un
instantané à l'aide du fournisseur Hyper-V WMI (V2).
Vous pouvez désormais créer des VM Hyper-V protégées qui incluent des
fonctionnalités empêchant les administrateurs Hyper-V sur l'hôte ou les logiciels
malveillants d'inspecter, d'altérer ou de voler les données de l'état de la VM
protégée. Les données et l'état sont cryptés afin que les administrateurs Hyper-V
ne puissent pas voir la sortie vidéo et les disques disponibles. Vous pouvez
également limiter l'exécution des machines virtuelles aux hôtes dont un serveur
Host Guardian a déterminé qu'ils sont sains et dignes de confiance. Pour plus
d’informations, consultez Présentation de l’infrastructure protégée et des machines
virtuelles dotées d’une protection maximale.

７ Notes

Les machines virtuelles blindées sont compatibles avec Hyper-V Replica. Pour
répliquer une machine virtuelle blindée, vous devez autoriser l'hôte que vous
souhaitez répliquer à exécuter cette VM blindée.

La fonction de priorité de l'ordre de démarrage des machines virtuelles en grappe

vous permet de mieux contrôler les VM en grappe qui démarrent ou redémarrent
en premier. La priorité de l'ordre de démarrage vous permet de démarrer les
machines virtuelles qui fournissent des services avant les machines virtuelles qui
utilisent ces services. Vous pouvez définir des ensembles, ajouter des machines
virtuelles aux ensembles et spécifier des dépendances à l'aide de cmdlets
PowerShell telles que New-ClusterGroupSet, Get-ClusterGroupSet et Add-
ClusterGroupSetDependency.

Les fichiers de configuration de la machine virtuelle utilisent désormais le format

d'extension de fichier .vmcx tandis que les fichiers de données d'état d'exécution
utilisent le format d'extension de fichier .vmrs . Ces nouveaux formats de fichiers
sont conçus pour permettre une lecture et une écriture plus efficaces. Ils réduisent
également la probabilité de corruption des données en cas de défaillance du
stockage.

） Important

L'extension du nom de fichier .vmcx indique qu'il s'agit d'un fichier binaire.
Hyper-V pour Windows Server 2016 ne prend pas en charge la modification
des fichiers .vmcx ou .vmrs .

Nous avons mis à jour la compatibilité de la version avec les VM de la version 5.

Ces VM sont compatibles avec Windows Server 2012 R2 et Windows Server 2016.
 Cependant, les VM de la version 5 compatibles avec Windows Server 2019 ne
peuvent s'exécuter que sur Windows Server 2016, et non sur Windows Server 2012
R2. Si vous déplacez ou importez une VM Windows Server 2012 R2 vers un serveur
exécutant une version ultérieure de Windows Server, vous devez mettre à jour
manuellement la configuration de la VM pour utiliser les fonctionnalités des
versions ultérieures de Windows Server. Pour plus d'informations sur la
compatibilité des versions et les fonctionnalités mises à jour, voir Mise à niveau de
la version de la machine virtuelle dans Hyper-V sur Windows ou Windows Server.

Vous pouvez désormais utiliser les fonctions de sécurité basées sur la virtualisation
pour les machines virtuelles de génération 2, telles que Device Guard et Credential
Guard, afin de protéger votre système d'exploitation contre les exploits de logiciels
malveillants. Ces fonctionnalités sont disponibles dans les machines virtuelles
exécutant la version 8 ou une version ultérieure. Pour plus d'informations,
reportez-vous à la section Mise à niveau de la version de la machine virtuelle dans
Hyper-V sur Windows ou Windows Server.

Vous pouvez désormais exécuter des cmdlets à l'aide de Windows PowerShell

Direct pour configurer votre VM à partir de la machine hôte, ce qui constitue une
alternative à VMConnect ou Remote PowerShell. Vous n'avez pas besoin de
répondre à des exigences en matière de réseau ou de pare-feu, ni de disposer
d'une configuration spéciale de gestion à distance pour commencer à l'utiliser.
Pour plus d'informations, voir Gérer les machines virtuelles Windows avec
PowerShell Direct.

Nano Server
Nano Server possède maintenant un module mis à jour pour la création d’images Nano
Server, et propose notamment une plus grande séparation des fonctionnalités de l’hôte
physique et de la machine virtuelle invitée, ainsi que la prise en charge de différentes
éditions de Windows Server. Pour plus d'informations, voir Installer Nano Server.

Des améliorations ont également été apportées à la console de récupération,

notamment la séparation des règles de pare-feu entrantes et sortantes ainsi que la
possibilité de réparer la configuration de WinRM.

Machines virtuelles dotées d’une protection maximale

Windows Server 2016 fournit une nouvelle machine virtuelle Hyper-V dotée d’une
protection maximale, pour protéger une machine virtuelle de deuxième génération
contre une structure compromise. Les fonctionnalités introduites dans Windows
Server 2016 sont les suivantes :

Un nouveau mode Chiffrement pris en charge qui offre plus de protections que
pour une machine virtuelle ordinaire, mais moins que le mode Protection
maximale, tout en prenant toujours en charge le module de plateforme sécurisée
(TPM) virtuel, le chiffrement de disque, le chiffrement de trafic de migration
dynamique et d'autres fonctionnalités, notamment les avantages d'administration
de structure directe tels que les connexions de console de machine virtuelle et
PowerShell Direct.

Prise en charge complète de la conversion de machines virtuelles de génération 2

non protégées existantes en machines virtuelles dotées d’une protection maximale,
dont le chiffrement automatique du disque.

Hyper-V Virtual Machine Manager peut désormais afficher les structures sur
lesquelles une machine virtuelle dotée d’une protection maximale peut s’exécuter,
ce qui permet à l’administrateur de la structure d’ouvrir le protecteur de clé d’une
machine virtuelle dotée d’une protection maximale et d’afficher les structures sur
lesquelles l’exécution est autorisée.

Vous pouvez changer de mode d’attestation sur un service Guardian hôte en cours
d’exécution. Vous pouvez maintenant basculer sur-le-champ entre l’attestation
Active Directory moins sécurisée, mais plus simple, et l’attestation basée sur le
module de plateforme sécurisée.

Des outils de diagnostic de bout en bout basés sur Windows PowerShell qui sont
en mesure de détecter des problèmes de configuration ou des erreurs à la fois
dans les hôtes Hyper-V protégés et le service Guardian hôte.

Un environnement de récupération qui offre un moyen de résoudre les problèmes

des machines virtuelles dotées d’une protection maximale et de les réparer en
toute sécurité au sein de la structure dans laquelle elles s’exécutent normalement
tout en offrant le même niveau de protection que la machine virtuelle dotée d’une
protection maximale elle-même.

Le service Guardian hôte prend en charge une instance Active Directory sécurisée :
vous pouvez demander au service Guardian hôte d’utiliser une forêt Active
Directory comme la sienne au lieu de créer sa propre instance Active Directory.

Pour plus d’informations et d’instructions sur l’utilisation des machines virtuelles dotées
d’une protection maximale, consultez Structure protégée et machines virtuelles dotées
d’une protection maximale.
Identité et accès
De nouvelles fonctionnalités d'identité améliorent la capacité des organisations à
sécuriser les environnements Active Directory et leur permettent de migrer vers les
déploiements de cloud uniquement et les déploiements hybrides, où certains services et
applications sont hébergés dans le cloud et d'autres en local.

Services de certificats Active Directory

Les services de certificats Active Directory (AD CS) dans Windows Server 2016
améliorent la prise en charge de l’attestation de clé de module de plateforme sécurisée
(TPM) : vous pouvez maintenant utiliser le fournisseur de stockage de clés de carte à
puce pour l’attestation de clé, et les appareils qui ne sont pas joints au domaine peuvent
maintenant utiliser l’inscription NDES pour obtenir des certificats qui peuvent être
attestés pour des clés présentes dans un module de plateforme sécurisée (TPM).

Gestion des accès privilégiés

La gestion des accès privilégiés (PAM) permet d’atténuer les problèmes de sécurité dans
les environnements Active Directory qui sont causés par des techniques de vol
d’informations d’identification telles que le hachage, le hameçonnage de lance, etc. Vous
pouvez configurer cette nouvelle solution d’accès administratif à l’aide de Microsoft
Identity Manager (MIM). Elle présente les fonctionnalités suivantes :

La forêt bastion Active Directory, approvisionnée par MIM, a une relation

d’approbation spéciale PAM avec une forêt existante. Les forêts bastion constituent
un nouveau type d’environnement Active Directory, à l’abri de toute activité
malveillante, car elles sont isolées des forêts existantes et n’autorisent l’accès
qu’aux comptes privilégiés.

Nouveaux processus dans MIM pour demander des privilèges administratifs, y

compris de nouveaux flux de travail pour l’approbation des requêtes.

Nouveaux principaux de sécurité d’ombre (ou groupes) approvisionnés dans la

forêt bastion par MIM en réponse aux demandes de privilèges d’administration.
Les groupes de sécurité fantôme ont un attribut qui fait référence au SID d’un
groupe d’administration dans une forêt existante. Cela permet au groupe d’ombres
d’accéder aux ressources dans des forêts existantes sans modifier les listes de
contrôle d’accès.

Une fonctionnalité de liaisons arrivant à expiration, qui permet l’appartenance

limitée dans le temps dans un groupe d’ombres. Vous pouvez ajouter des
 utilisateurs au groupe pendant une durée définie pour leur permettre d’effectuer
des tâches administratives. L’appartenance limitée dans le temps est configurée
par une valeur de durée de vie propagée à une durée de vie de ticket Kerberos.

７ Notes

Les liens arrivant à expiration sont disponibles sur tous les attributs liés.
Toutefois, seule la relation d’attribut lié member/memberOF entre un groupe
et un utilisateur est préconfigurée avec PAM pour utiliser la fonctionnalité de
liens arrivant à expiration.

Les améliorations de contrôleur de domaine Kerberos (KDC) intégrées aux

contrôleurs de domaine Active Directory pour limiter la durée de vie des tickets
Kerberos à la valeur de durée de vie la plus faible possible lorsque les utilisateurs
ont plusieurs appartenances limitées dans le temps dans des groupes
d’administration. Par exemple, si vous appartenez à un groupe A limité dans le
temps, lorsque vous vous authentifiez, la durée de vie du ticket TGT (Ticket-
granting ticket) Kerberos est égale au temps qu’il vous reste dans le groupe A. Si
vous rejoignez également un autre groupe B limité dans le temps, dont la durée de
vie est inférieure à celle du groupe A, la durée de vie du TGT est égale au temps
qu’il vous reste dans le groupe B.

De nouvelles fonctionnalités de surveillance vous permettent d’identifier les

utilisateurs qui ont demandé un accès, les accès que les administrateurs leur ont
accordés et les activités qu’ils ont effectuées lorsqu’ils étaient connectés.

Pour en savoir plus sur les PAM, consultez Privileged Access Management for Active
Directory Domain Services.

Jonction Microsoft Entra

La jonction Microsoft Entra améliore les expériences d’identité pour les clients de
l’entreprise, du commerce et de l’éducation, et inclut des fonctionnalités améliorées
pour les appareils professionnels et personnels.

Les paramètres modernes sont désormais disponibles sur les appareils Windows
appartenant à l’entreprise. Les fonctionnalités de Core Windows ne nécessitent
plus de compte Microsoft personnel : elles s’exécutent désormais à partir des
comptes professionnels existants des utilisateurs pour garantir la conformité. Ces
services fonctionnent sur les PC qui sont joints à un domaine Windows local, ainsi
 que les appareils qui sont « joints » à Microsoft Entra. Il s’agit notamment des
paramètres suivants :

Itinérance ou personnalisation, paramètres d’accessibilité et informations

d’identification

Sauvegarde et restauration

Accès au Microsoft Store avec votre compte professionnel

Vignettes dynamiques et notifications

Accès aux ressources organisationnelles sur des appareils mobiles, notamment des
téléphones et des tablettes, qui ne peuvent pas être joints à un domaine Windows,
qu’ils appartiennent à une entreprise ou qu’ils soient BYOD.

Utilisez une authentification unique (SSO) pour Office 365 et d’autres applications,
sites web et ressources de l’organisation.

Sur les appareils BYOD, ajoutez un compte professionnel à partir d’un domaine
local ou d’Azure AD à un appareil appartenant à un utilisateur. Vous pouvez utiliser
le SSO pour accéder aux ressources professionnelles, via les applications et sur le
Web, de manière à garantir la conformité avec les nouvelles fonctionnalités telles
que le contrôle de compte conditionnel et l’attestation d’intégrité de l’appareil.

L’intégration de la gestion des appareils mobiles (MDM) vous permet d’inscrire

automatiquement des appareils à votre outil de gestion des appareils mobiles
(MDM) (Microsoft Intune ou tiers).

Configurer le mode « kiosque » et les appareils partagés pour plusieurs utilisateurs

de votre organisation.

L’expérience des développeurs vous permet de créer des applications qui

s’adressent aux contextes d’entreprise et personnels avec une pile de
programmation partagée.

L’option d’acquisition d’images vous permet de choisir entre la création d’images

et permettre à vos utilisateurs de configurer des appareils appartenant à
l’entreprise directement pendant l’expérience de première exécution.

Windows Hello Entreprise

Windows Hello Entreprise est une approche d’authentification basée sur la clé pour les
organisations et les consommateurs qui ne nécessite pas de passer par un mot de passe.
Cette forme d’authentification repose sur les informations d’identification contre les
violations, le vol et le hameçonnage.

L’utilisateur se connecte à l’appareil à l’aide d’un identifiant biométrique ou d’un code

PIN lié à un certificat ou à une paire de clés asymétriques. Les fournisseurs d’identité
valident l’utilisateur en mappant sa clé publique à IDlocker et fournissent des
informations de connexion via un mécanisme de notification tel que le mot de passe à
usage unique ou téléphone, entre autres.

Pour plus d'informations, voir Windows Hello for Business.

Dépréciation des niveaux fonctionnels du service de réplication de

fichiers (FRS) et de Windows Server 2003

Bien que le service de réplication de fichiers et les niveaux fonctionnels de Windows

Server 2003 soient déconseillés dans les versions précédentes de Windows Server, nous
souhaitons vous rappeler qu’AD DS ne prend plus en charge le système d’exploitation
Windows Server 2003. Vous devez donc supprimer du domaine tous les contrôleurs de
domaine qui exécutent Windows Server 2003. Vous devez également élever le niveau
fonctionnel du domaine et de la forêt au moins à Windows Server 2008.

Aux niveaux fonctionnels de domaine Windows Server 2008 et supérieurs, AD DS utilise

la réplication DFS (Distributed File Service) pour répliquer le contenu du dossier SYSVOL
entre les contrôleurs de domaine. Si vous créez un domaine au niveau fonctionnel de
domaine Windows Server 2008 ou supérieur, la réplication DFS réplique
automatiquement le dossier SYSVOL. Si vous avez créé le domaine à un niveau
fonctionnel inférieur, vous devez passer de l’utilisation de FRS à la réplication DFS pour
le fichier SYSVOL. Pour obtenir des étapes de migration plus détaillées, consultez
Installer, mettre à niveau ou migrer vers Windows Server.

Pour plus d’informations, consultez les ressources suivantes :

Présentation des niveaux fonctionnels des services de domaine Active Directory

(AD DS)
Comment élever les niveaux fonctionnels de domaine et de forêt Active Directory

Services de fédération Active Directory (AD FS)

Les services AD FS de Windows Server 2016 incluent de nouvelles fonctionnalités qui
vous permettent de configurer AD FS pour authentifier les utilisateurs stockés dans les
annuaires LDAP (Lightweight Directory Access Protocol).
Proxy d'application web
La dernière version du Proxy d'application Web se concentre sur les nouvelles
fonctionnalités qui permettent la publication et la préauthentification d'applications
supplémentaires et améliorent l'expérience utilisateur. Consultez la liste complète des
nouvelles fonctionnalités qui inclut la préauthentification des applications clientes riches
comme Exchange ActiveSync et les domaines avec caractères génériques pour une
publication plus facile des applications SharePoint. Pour plus d’informations, consultez
Proxy d’application web dans Windows Server 2016.

Administration
La section Gestion et automatisation fournit des informations sur les outils et références
pour les professionnels de l'informatique qui souhaitent exécuter et gérer Windows
Server 2016, dont Windows PowerShell.

Windows PowerShell 5.1 contient de nouvelles fonctionnalités importantes, notamment

la prise en charge du développement avec les classes, et de nouvelles fonctionnalités de
sécurité, qui étendent son utilisation, améliorent sa convivialité, et vous permettent de
contrôler et de gérer des environnements Windows de façon plus simple et plus
complète. Pour plus d’informations, consultez Nouveaux scénarios et nouvelles
fonctionnalités dans WMF 5.1.

Les nouveautés de Windows Server 2016 incluent la possibilité d’exécuter

[Link] localement sur Nano Server (et non plus seulement à distance), de
nouvelles applets de commande Utilisateurs et groupes locaux pour remplacer
l’interface utilisateur graphique, la prise en charge du débogage de PowerShell et la
prise en charge de Nano Server pour la transcription et la journalisation de la sécurité,
ainsi que JEA.&&

Voici d’autres nouvelles fonctionnalités d’administration :

Configuration d’état souhaité Windows PowerShell (DSC)

dans Windows Management Framework (WMF) 5
Windows Management Framework 5 inclut des mises à jour de configuration d’état
souhaité Windows PowerShell (DSC), Windows Remote Management (WinRM) et
Windows Management Instrumentation (WMI).

Pour plus d’informations sur le test des fonctionnalités DSC de Windows Management
Framework 5, consultez la série de billets de blog mentionnés dans Valider les
fonctionnalités de PowerShell DSC . Pour effectuer le téléchargement, consultez
Windows Management Framework 5.1.

Gestion unifiée des packages PackageManagement pour

la détection, l’installation et l’inventaire des logiciels
Windows Server 2016 et Windows 10 incluent une nouvelle fonctionnalité
PackageManagement (auparavant appelée OneGet) qui permet aux professionnels de
l’informatique ou développeurs d’automatiser la détection, l’installation et l’inventaire
des logiciels, localement ou à distance, quels que soient la technologie d’installation
utilisée et l’emplacement des logiciels.

Pour en savoir plus, voir [Link] .

Améliorations de PowerShell pour faciliter la forensique

numérique et aider à réduire les violations de sécurité
Pour aider l’équipe responsable de l’examen des systèmes compromis, parfois appelée
« l’équipe bleue », nous avons ajouté des fonctionnalités d’investigation numérique et
de journalisation PowerShell supplémentaires ainsi que des fonctionnalités destinées à
réduire les vulnérabilités dans les scripts, comme PowerShell limité et à sécuriser les API
CodeGeneration.

Pour plus d'informations, consultez le billet de blog PowerShell ♥ the Blue Team .

Réseau
La section Mise en réseau décrit les fonctionnalités et produits de mise en réseau que
les professionnels de l'informatique peuvent utiliser pour la conception, le déploiement
et la maintenance de Windows Server 2016.

Mise en réseau définie par logiciel

La mise en réseau définie par logiciel (SDN) est une nouvelle solution SDDC (Centre de
données définis par logiciel) qui inclut les fonctionnalités suivantes :

Contrôleur de réseau, qui vous permet d’automatiser la configuration de

l’infrastructure réseau au lieu d’effectuer une configuration manuelle des services
et appareils réseau. Le contrôleur de réseau utilise Representational State Transfer
(REST) sur son interface direction nord avec des charges utiles
JavaScript Object Notation (JSON). L’interface direction sud du contrôleur de
réseau utilise le protocole OVSDB (Open vSwitch Database Management).

Nouvelles fonctionnalités pour Hyper-V :

Commutateur virtuel Hyper-V, qui vous permet de créer une commutation et un

routage distribués, ainsi qu’une couche d’application de stratégie alignée et
compatible avec Microsoft Azure. Pour en savoir plus, consultez Commutateur
virtuel Hyper-V.

Accès direct à la mémoire à distance (RDMA) et switch-embedded teaming

(SET) lorsque vous créez des commutateurs virtuels. Vous pouvez configurer
RDMA sur les adaptateurs réseau liés à un commutateur virtuel Hyper-V, que
vous utilisiez ou non SET. SET peut donner à vos commutateurs virtuels des
capacités similaires à celles du teaming NIC. Pour plus de détails, voir
Configuration requise du réseau hôte pour Azure Stack HCI.

Les files d'attente multiples de machines virtuelles (VMMQ) améliorent le

rendement des VMQ en allouant plusieurs files d'attente matérielles par VM. La
file d'attente par défaut devient un ensemble de files d'attente pour une VM et
répartit le trafic entre les files d'attente.

La qualité de service (QoS) pour les réseaux définis par logiciel gère la classe de
trafic par défaut via le commutateur virtuel dans la bande passante de la classe
par défaut.

La virtualisation des fonctions réseau (NFV), qui vous permet de mettre en miroir
ou d’acheminer des fonctions réseau exécutées par des appareils matériels vers
des appareils virtuels, tels que des équilibreurs de charge, des pare-feu, des
routeurs, des commutateurs, etc. Vous pouvez également déployer et gérer toute
votre pile SDN à l’aide de System Center Virtual Machine Manager. Vous pouvez
utiliser Docker pour gérer la mise en réseau de conteneurs Windows Server et
associer des stratégies de mise en réseau SDN à des machines virtuelles et à des
conteneurs.

Un pare-feu de centre de données qui fournit des listes de contrôle d’accès (ACL)
granulaires, ce qui vous permet d’appliquer des stratégies de pare-feu au niveau
de l’interface de la machine virtuelle ou du sous-réseau. Pour en savoir plus,
consultez Qu’est-ce que le pare-feu de centre de données ?

Passerelle RAS, qui vous permet d’acheminer le trafic entre des réseaux virtuels et
des réseaux physiques, y compris les connexions VPN de site à site entre votre
centre de données dans le cloud et les sites distants de vos locataires. Le protocole
Border Gateway Protocol (BGP) vous permet de déployer et de fournir un routage
 dynamique entre les réseaux pour tous les scénarios de passerelles, y compris les
réseaux privés virtuels (VPN) de site à site IKEv2 (Internet Key Exchange version 2),
les VPN de couche 3 (L3) et les passerelles GRE (Generic Routing Encapsulation).
Les passerelles prennent désormais également en charge les pools de passerelles
et la redondance M+N. Pour en savoir plus, consultez Qu’est-ce qu’une passerelle
de service d’accès à distance (RAS) pour une mise en réseau définie par logiciel ?

L’équilibreur de charge logicielle (SLB) et la traduction d’adresses réseau (NAT)

améliorent le débit en prenant en charge le retour direct du serveur. Ainsi, le trafic
de retour du réseau peut contourner le multiplexeur d’équilibrage de charge et
peut être réalisé à l’aide d’un équilibreur de charge de couche 4 nord-sud et est-
ouest, et d’une NAT. Pour en savoir plus, consultez Qu’est-ce qu’un équilibreur de
charge logicielle (SLB) pour SDN ? et la virtualisation de fonction réseau.

Des technologies d’encapsulation flexibles qui fonctionnent au niveau du plan de

données et prennent en charge à la fois Virtual Extensible LAN (VxLAN) et Network
Virtualization Generic Routing Encapsulation (NVGRE).

Pour plus d’informations, consultez Planifier une mise en réseau SDN (Software Defined
Networking).

Principes de base de la mise à l’échelle cloud

Windows Server 2016 inclut les éléments fondamentaux suivants à l’échelle du cloud :

Carte d’interface réseau (NIC) convergée, qui vous permet d’utiliser une seule carte
réseau pour la gestion, le stockage compatible RDMA (Remote Direct Memory
Access) et le trafic de locataires. Une carte d’interface réseau convergée réduit le
coût de chaque serveur de votre centre de données, car elle nécessite moins de
cartes réseau pour gérer différents types de trafic par serveur.

Packet Direct fournit une infrastructure de traitement des paquets à faible latence
et à débit de trafic réseau élevé.

Switch Embedded Teaming (SET) est une solution d’association de cartes réseau
intégrée au commutateur virtuel Hyper-V. SET permet d’associer jusqu’à huit cartes
d’interface réseau physiques en une seule association SET, ce qui améliore la
disponibilité et assure le basculement. Dans Windows Server 2016, vous pouvez
créer des associations SET qui sont limitées à l’utilisation de Server Message Block
(SMB) et RDMA. Vous pouvez également utiliser des associations SET pour répartir
le trafic réseau pour la virtualisation de réseau Hyper-V. Pour en savoir plus,
consultez Exigences du réseau hôte pour Azure Stack HCI.
Améliorations des performances de TCP
La fenêtre de congestion initiale par défaut a été augmentée de 4 à 10 et TCP Fast Open
(TFO) a été implémenté. TFO réduit le temps nécessaire pour établir une connexion TCP
et la nouvelle fenêtre de congestion initiale permet de transférer des objets plus
volumineux dans la rafale initiale. Cette combinaison réduit considérablement le temps
nécessaire pour transférer un objet Internet entre le client et le cloud.

Pour améliorer le comportement de TCP en cas de récupération suite à une perte de

paquets, nous avons implémenté TCP TLP (Tail Loss Probe) et RACK (Recent
Acknowledgment). TLP permet de convertir des délais de retransmission en
récupérations rapides, et RACK réduit le temps nécessaire à une récupération rapide
pour retransmettre un paquet perdu.

Protocole DHCP (Dynamic Host Configuration Protocol)

Le protocole DHCP (Dynamic Host Configuration Protocol) présente les changements
suivants dans Windows Server 2016 :

À partir d Windows 10, version 2004, lorsque vous exécutez un client Windows et
que vous vous connectez à Internet à l’aide d’un appareil Android en partage de
connexion, les connexions sont désormais étiquetées comme mesurées. Le nom du
fournisseur client traditionnel qui s’affichait comme MSFT 5.0 sur certains appareils
Windows est maintenant MSFT 5.0 XBOX.

À compter de Windows 10, version 1803, le client DHCP peut désormais lire et
appliquer l’option 119, l’option de recherche de domaine, à partir du serveur DHCP
auquel votre système se connecte. L’option de recherche de domaine fournit
également des suffixes DNS (Domain Name Services) pour les recherches DNS de
noms courts. Pour plus d’informations, consultez RFC 3397 .

DHCP prend désormais en charge l’option 82 (sous-option 5). Vous pouvez utiliser
cette option pour autoriser les clients proxy DHCP et les agents de relais à
demander une adresse IP pour un sous-réseau spécifique. Si vous utilisez un agent
de relais DHCP configuré avec l’option DHCP 82 (sous-option 5), l’agent de relais
peut demander un bail d’adresse IP pour les clients DHCP à partir d’une plage
d’adresses IP spécifique. Pour plus d’informations, consultez Options de sélection
de sous-réseau DHCP.

Nouveaux événements de journalisation pour les cas où les inscriptions

d’enregistrements DNS échouent sur le serveur DNS. Pour en savoir plus, consultez
Événements de journalisation DHCP pour les inscriptions DNS.
 Le rôle de serveur DHCP ne prend plus en charge la protection d’accès réseau
(NAP). Les serveurs DHCP n’appliquent pas de stratégies NAP et les étendues
DHCP ne peuvent pas être activées pour NAP. Les ordinateurs clients DHCP qui
sont également des clients NAP envoient une instruction d’intégrité (SoH) avec la
requête DHCP. Si le serveur DHCP exécute Windows Server 2016, ces requêtes sont
traitées comme si aucun SoH n’était présent. Le serveur DHCP accorde un bail
DHCP normal au client. Si les serveurs qui exécutent Windows Server 2016 sont
des proxys RADIUS (Remote Authentication Dial-In User Service) qui transmettent
les demandes d’authentification à un serveur de stratégie réseau (NPS) qui prend
en charge NAP, le NPS évalue ces clients comme n’étant pas compatibles NAP, ce
qui entraîne l’échec du traitement NAP. Pour en savoir plus sur NAP et son
obsolescence, consultez Fonctionnalités supprimées ou obsolètes dans Windows
Server 2012 R2.

Tunneling GRE
La passerelle RAS prend désormais en charge les tunnels Generic Routing Encapsulation
(GRE) à haute disponibilité pour les connexions de site à site et la redondance M+N des
passerelles. GRE est un protocole de tunneling léger qui encapsule une grande variété
de protocoles de la couche réseau dans les liaisons point à point virtuelles sur un réseau
d’interconnexion IP. Pour plus d’informations, consultez Tunneling GRE dans
Windows Server 2016.

Gestion des adresses IP (IPAM)

L’IPAM présente les mises à jour suivantes :

Gestion des adresses IP améliorée L’IPAM a amélioré les capacités pour des
scénarios tels que la gestion des sous-réseaux IPv4 /32 et IPv6 /128 et la recherche
de sous-réseaux et de plages d’adresses IP libres dans un bloc d’adresses IP.

Vous pouvez maintenant exécuter l’applet de commande Find-IpamFreeSubnet

pour rechercher les sous-réseaux disponibles pour l’allocation. Cette fonction
n’alloue pas les sous-réseaux, mais signale uniquement leur disponibilité. Toutefois,
vous pouvez diriger la sortie de l’applet de commande vers l’applet de commande
Add-IpamSubnet pour créer un sous-réseau. Pour plus d'informations, consultez

Find-IpamFreeSubnet.

Vous pouvez maintenant exécuter l’applet de commande Find-IpamFreeRange pour

rechercher les plages d’adresses IP disponibles dans un bloc IP, une longueur de
préfixe et un nombre de sous-réseaux demandés. Cette applet de commande
n’alloue pas la plage d’adresses IP, signale uniquement leur disponibilité. Toutefois,
vous pouvez diriger la sortie vers l’applet de commande AddIpamRange pour créer
la plage. Pour plus d'informations, consultez Find-IpamFreeRange.

Gestion des services DNS améliorée :

Collection d’enregistrements de ressources DNS pour les serveurs DNS non

DNSSEC.

Configuration des propriétés et des opérations sur tous les types

d’enregistrements de ressources non DNSSEC.

Gestion des zones DNS pour les serveurs DNS intégrés dans Active Directory et
les serveurs DNS adossés à des fichiers. Vous pouvez gérer tous les types de
zones DNS, notamment les zones principales, secondaires et de stub.

Déclenchez des tâches sur les zones secondaires et Stub, qu'il s'agisse de zones
de recherche directe ou inversée.

Contrôle d’accès basé sur les rôles pour les configurations DNS prises en charge
pour les enregistrements et les zones.

Redirecteurs conditionnels

Gestion intégrée du service DNS, du protocole DHCP et des adresses IP (DDI). Vous
pouvez maintenant afficher tous les enregistrements de ressources DNS associés à
une adresse IP dans l’inventaire des adresses IP. Vous pouvez également conserver
automatiquement les enregistrements de pointeurs (PTR) des adresses IP et gérer
les cycles de vie des adresses IP pour les opérations DNS et DHCP.

Support pour plusieurs forêts Active Directory. Vous pouvez utiliser l’IPAM pour
gérer les serveurs DNS et DHCP de plusieurs forêts Active Directory lorsqu’il existe
une relation d’approbation bidirectionnelle entre la forêt dans laquelle vous avez
installé l’IPAM et chacune des forêts distantes. Pour en savoir plus, consultez Gérer
les ressources dans plusieurs forêts Active Directory.

La fonctionnalité « Supprimer définitivement les données d’utilisation » vous

permet de réduire la taille de la base de données IPAM en supprimant les
anciennes données d’utilisation IP. Spécifiez simplement une date et l’IPAM
supprime toutes les entrées de base de données antérieures ou égales à la date
que vous avez entrée. Pour plus d'informations, consultez Purger les données
d'utilisation.

Vous pouvez désormais utiliser le contrôle d’accès en fonction du rôle (RBAC) pour
définir des étendues d’accès pour les objets IPAM dans PowerShell. Pour plus
 d'informations, consultez Gérer le contrôle d'accès basé sur les rôles avec Windows
PowerShell et des applets de commande de serveur de gestion des adresses IP
(IPAM) dans Windows PowerShell.

Pour plus d’informations, consultez Gérer IPAM.

Sécurité et assurance
La section Sécurité et assurance contient des fonctionnalités et solutions de sécurité
pour professionnels de l'informatique à déployer dans votre environnement de centre
de données et cloud. Pour plus d’informations générales sur la sécurité dans Windows
Server 2016, consultez Sécurité et assurance.

Administration suffisante
Dans Windows Server 2016, Just Enough Administration est une technologie de sécurité
qui permet de déléguer l’administration de tout ce qui peut être géré avec Windows
PowerShell. Les fonctionnalités disponibles incluent la prise en charge de l’exécution
sous une identité réseau, la connexion par le biais PowerShell Direct, la copie de manière
sécurisée de fichiers vers/depuis des points de terminaison JEA (Just Enough
Administration) et la configuration de la console PowerShell pour un lancement dans un
contexte JEA par défaut. Pour en savoir plus, consultez JEA sur GitHub .

Protection des informations d’identification

La protection des informations d’identification utilise une sécurité basée sur la
virtualisation pour isoler les secrets, afin que seuls les logiciels système privilégiés
puissent y accéder. Pour plus d’informations, consultez la section Protéger les
informations d’identification de domaine dérivées avec Credential Guard.

Credential Guard pour Windows Server 2016 inclut les mises à jour suivantes pour les
sessions utilisateur connectées :

Kerberos et New Technology LAN Manager (NTLM) utilisent la sécurité basée sur la
virtualisation pour protéger les secrets Kerberos et NTLM pour les sessions
utilisateur connectées.

Credential Manager protège les identifiants de domaine enregistrés à l’aide d’une

sécurité basée sur la virtualisation. Les informations d’identification signées et les
informations d’identification de domaine enregistrées ne sont pas transmises aux
hôtes distants utilisant Remote Desktop.
 Vous pouvez activer Credential Guard sans verrou UEFI (Unified Extensible
Firmware Interface).

Credential Guard à distance

Protection des informations d’identification prend en charge les sessions RDP afin que
les informations d’identification de l’utilisateur restent côté client et ne soient pas
exposées côté serveur. Il fournit également l’authentification unique pour Bureau à
distance. Pour plus d’informations, consultez Protéger les informations d’identification
de domaine dérivées avec Windows Defender Credential Guard.

Remote Credential Guard pour Windows Server 2016 inclut les mises à jour suivantes
pour les utilisateurs connectés :

Remote Credential Guard conserve les secrets Kerberos et NTLM des informations
d’identification de l’utilisateur connecté sur l’appareil client. Toute requête
d’authentification de l’hôte distant pour évaluer les ressources du réseau en tant
qu’utilisateur nécessite que l’appareil client utilise les secrets.

Remote Credential Guard protège les informations d’identification fournies par

l’utilisateur lors de l’utilisation du bureau à distance.

Protections de domaine
Les protections de domaine nécessitent désormais un domaine Active Directory.

Prise en charge de l’extension PKInit Freshness

Les clients Kerberos tentent désormais d’utiliser l’extension de fraîcheur PKInit pour les
signatures basées sur les clés publiques.

Les KDC prennent désormais en charge l’extension de fraîcheur PKInit. Cependant, ils ne
proposent pas l’extension de fraîcheur PKInit par défaut.

Pour plus d’informations, consultez Prise en charge du client Kerberos et du centre de

distribution de clés pour l’extension RFC 8070 PKInit Freshness.

Clés publiques propagées uniquement les secrets NTLM

de l’utilisateur
À partir du niveau fonctionnel de domaine (DFL) de Windows Server 2016, les DC
prennent désormais en charge le roulement des secrets NTLM d’un utilisateur à clé
publique uniquement. Cette fonctionnalité n’est pas disponible dans les niveaux de
fonctionnement des domaines inférieurs (DFL).

２ Avertissement

L’ajout d’un DC activé avant la mise à jour du 8 novembre 2016 à un domaine qui
prend en charge les secrets NTLM roulants peut entraîner le plantage du DC.

Pour les nouveaux domaines, cette fonctionnalité est activée par défaut. Pour les
domaines existants, vous devez le configurer dans le Centre administratif Active
Directory.

Dans le Centre administratif Active Directory, cliquez avec le bouton droit de la souris
sur le domaine dans le volet gauche et sélectionnez Propriétés. Cochez la case Activer
le renouvellement des secrets NTLM expirés lors de l’ouverture de session pour les
utilisateurs qui doivent utiliser Windows Hello for Business ou une carte à puce pour
l’ouverture de session interactive. Ensuite, sélectionnez OK pour appliquer cette
modification.

L’autorisation de réseau NTLM lorsqu’un utilisateur est

limité à certains appareils associés à un domaine
Les DC peuvent désormais prendre en charge l’autorisation de NTLM réseau lorsqu’un
utilisateur est limité à des appareils spécifiques joints à un domaine dans la LDF
Windows Server 2016 et les versions ultérieures. Cette fonctionnalité n’est pas
disponible dans les LDF exécutant un système d’exploitation antérieur à Windows Server
2016.

Pour configurer ce paramètre, dans la stratégie d’authentification, sélectionnez

Autoriser l’authentification réseau NTLM lorsque l’utilisateur est limité aux appareils
sélectionnés.

Pour plus d’informations, voir Stratégies d’authentification et silos de stratégies

d’authentification.

Protection de périphérique (intégrité du code)

Protection de périphérique assure l’intégrité du code en mode noyau (KMCI) et en mode
utilisateur (UMCI), en créant des stratégies qui spécifient le code exécutable sur le
serveur. Consultez Introduction à Windows Defender Device Guard : Stratégies
d’intégrité du code et de sécurité basée sur la virtualisation.
Windows Defender
Windows Defender Overview for Windows Server 2016 (Présentation de Windows
Defender pour Windows Server 2016. Windows Server Antimalware est installé et activé
par défaut dans Windows Server 2016, mais pas son interface utilisateur. Toutefois,
Windows Server Antimalware va mettre à jour les définitions de logiciel anti-programme
malveillant et protéger l'ordinateur sans l'interface utilisateur. Si vous avez besoin de
l'interface utilisateur pour Windows Server Antimalware, vous pouvez l'installer après
l'installation du système d'exploitation à l'aide de l'Assistant Ajout de rôles et de
fonctionnalités.

Control Flow Guard

Protection de flux de contrôle est une fonctionnalité de sécurité de plateforme qui a été
créée pour lutter contre les risques de corruption de mémoire. Pour plus d’informations,
consultez Control Flow Guard (Protection du flux de contrôle).

Stockage
Le stockage dans Windows Server 2016 comprend de nouvelles fonctionnalités et
améliorations pour le stockage défini par logiciel et les serveurs de fichiers traditionnels.

Espaces de stockage directs

Les espaces de stockage direct permettent de créer un stockage à haute disponibilité et
scalable en utilisant des serveurs avec un stockage local. Il simplifie le déploiement et la
gestion des systèmes de stockage définis par logiciel et vous permet d'utiliser de
nouvelles classes de périphériques de disque, telles que les disques SSD SATA et les
périphériques de disque NVMe, qui n'étaient pas disponibles auparavant avec les
espaces de stockage en cluster avec des disques partagés.

Pour plus de détails, voir Storage Spaces Direct.

Réplica de stockage
Storage Replica permet une réplication synchrone au niveau des blocs, indépendante du
stockage, entre les serveurs ou les clusters pour la reprise après sinistre, et vous permet
d'étendre un cluster de basculement entre les sites. La réplication synchrone permet la
mise en miroir des données dans des sites physiques avec des volumes cohérents en cas
d’incident, ce qui garantit aucune perte de données au niveau du système de fichiers. La
réplication asynchrone permet l’extension de site au-delà de plages métropolitaines
avec la possibilité de perte de données.

Pour plus d’informations, consultez Storage Replica overview (Présentation du réplica de

stockage).

Qualité de service de stockage

Vous pouvez maintenant utiliser la qualité de service (QoS) de stockage pour analyser
de manière centralisée les performances de stockage de bout en bout et créer des
stratégies de gestion avec Hyper-V et des clusters CSV dans Windows Server 2016.

Pour plus d’informations, consultez Storage Quality of Service (Qualité de service de

stockage).

Déduplication des données

Windows Server 2016 inclut les nouvelles fonctionnalités suivantes pour la déduplication
des données.

Prise en charge de volumes importants

À compter de Windows Server 2016, le pipeline de la tâche de déduplication de

données peut exécuter plusieurs threads en parallèle en utilisant plusieurs files d’attente
d’E/S pour chaque volume. Cette modification permet d’atteindre des niveaux de
performance auparavant uniquement possibles en divisant les données en plusieurs
volumes de taille plus réduite. Ces optimisations s’appliquent à tous les travaux de
déduplication des données, et non uniquement au travail d’optimisation. Le schéma
suivant montre comment le pipeline a changé entre les versions de Windows Server.
Grâce à l’amélioration des performances, sur Windows Server 2016, la déduplication des
données offre des performances élevées sur les volumes jusqu’à 64 To.

Prise en charge des fichiers de grande taille

À compter de Windows Server 2016, la déduplication des données utilise des structures
de mappage de flux et d’autres améliorations pour augmenter les performances de
débit et d’accès de l’optimisation. Le pipeline de traitement de déduplication peut
également reprendre l’optimisation après Des scénarios de basculement au lieu de
recommencer à partir du début. Cette modification améliore les performances des
fichiers jusqu’à 1 To, ce qui permet aux administrateurs d’appliquer des économies de
déduplication à un plus grand nombre de charges de travail, notamment les fichiers
volumineux associés aux charges de travail de sauvegarde.

Prise en charge de Nano Server

Nano Server est une option de déploiement sans affichage dans Windows Server 2016,
qui présente un encombrement des ressources système très faible, démarre beaucoup
plus rapidement et nécessite moins de mises à jour et de redémarrages que l’option de
déploiement de Windows Server principal. De plus, Nano Server prend entièrement en
charge la déduplication des données. Pour en savoir plus sur Nano Server, consultez
Images de base de conteneur.

Configuration simplifiée pour les applications de sauvegarde

virtualisées
À compter de Windows Server 2016, les scénarios de déduplication des données pour
les applications de sauvegarde virtualisées sont considérablement simplifiés. Ce scénario
est désormais une option de type d’utilisation prédéfinie. Vous n’avez plus besoin de
paramétrer manuellement la déduplication, il vous suffit de l’activer pour un volume,
comme vous le feriez pour le serveur de fichiers à usage général et l’infrastructure VDI
(Virtual Desktop Infrastructure).

Prise en charge de la mise à niveau propagée du système

d’exploitation de cluster

Les clusters de basculement Windows Server exécutant la déduplication des données

peuvent comporter un mélange de nœuds qui exécutent des versions de Windows
Server 2012 R2 et de Windows Server 2016 de la déduplication des données. Cette
fonctionnalité de cluster en mode mixte offre un accès complet aux données de tous les
volumes dédupliqués pendant les mises à niveau propagées de cluster. Vous pouvez
désormais déployer progressivement des versions ultérieures des déduplications de
données sur des clusters exécutant des versions antérieures de Windows Server sans
temps d’arrêt.

Vous pouvez également utiliser les mises à jour en continu sur Hyper-V. Avec la mise à
niveau continue d'un cluster Hyper-V, vous pouvez désormais ajouter un nœud
exécutant Windows Server 2019 ou Windows Server 2016 à un cluster Hyper-V avec des
nœuds exécutant Windows Server 2012 R2. Après avoir ajouté le nœud exécutant la
version la plus récente de Windows Server, vous pouvez mettre à niveau le reste du
cluster sans interruption de service. Le cluster s'exécute à un niveau de fonctionnalité
Windows Server 2012 R2 jusqu'à ce que vous mettiez à niveau tous les nœuds du cluster
et que vous exécutiez Update-ClusterFunctionalLevel dans PowerShell pour mettre à
jour le niveau de fonctionnement du cluster. Pour des instructions plus détaillées sur le
fonctionnement du processus de mise à niveau continue, voir Mise à niveau continue du
système d'exploitation de cluster.

７ Notes

Hyper-V sur Windows 10 ne prend pas en charge le clustering de basculement.

Améliorations de la sécurisation renforcée SMB pour les

connexions SYSVOL et NETLOGON
Dans Windows 10 et Windows Server 2016, les connexions des clients aux services de
domaine Active Directory utilisaient par défaut les partages SYSVOL et NETLOGON sur
les contrôleurs de domaine. Désormais, ces connexions nécessitent une signature SMB
et une authentification mutuelle à l'aide de services tels que Kerberos. Si la signature
SMB et l’authentification mutuelle ne sont pas disponibles, un ordinateur Windows 10
ou Windows Server 2016 ne peut pas traiter les scripts ni la stratégie de groupe basés
sur un domaine. Cette modification protège les périphériques contre les attaques de
type "adversary-in-the-middle".

７ Notes

Les valeurs de registre pour ces paramètres ne sont pas présentes par défaut, mais
les règles de durcissement s'appliquent toujours jusqu'à ce que vous les remplaciez
en modifiant la stratégie de groupe ou d'autres valeurs de registre.

Pour plus d'informations sur ces améliorations de sécurité, voir MS15-011 : Vulnérabilité
dans la stratégie de groupe et MS15-011 & MS15-014 : Durcissement de la stratégie
de groupe .

Dossiers de travail
Windows Server 2016 propose une notification de changement améliorée lorsque le
serveur Work Folders exécute Windows Server 2016 et que le client Work Folders est
Windows 10. Lorsque des modifications de fichiers se synchronisent sur le serveur Work
Folders, le serveur en informe désormais immédiatement les clients Windows 10, puis
synchronise les modifications de fichiers.

ReFS
La nouvelle version de ReFS permet de réaliser des déploiements de stockage à grande
échelle avec diverses charges de travail, offrant ainsi plus de fiabilité, de résilience et
d'extensibilité pour vos données.

ReFS offre les améliorations suivantes :

Nouvelle fonctionnalité de niveau de stockage, offrant des performances plus

rapides et une capacité de stockage accrue, notamment les éléments suivants :

Plusieurs types de résilience sur le même disque virtuel en utilisant la mise en

miroir dans le niveau de performance et la parité dans le niveau de capacité.

Meilleure réactivité pour les dérives de plages de travail.

 Introduit le clonage de blocs pour améliorer les performances des opérations de
machines virtuelles, telles que les opérations de fusion de points de contrôle
.vhdx .

Un nouvel outil d'analyse ReFS qui peut vous aider à récupérer les espaces de
stockage perdus et à sauver les données des corruptions critiques.

Clustering de basculement
Windows Server 2016 inclut de nombreuses nouvelles fonctionnalités et améliorations
pour plusieurs serveurs regroupés dans un cluster à tolérance de panne, à l’aide de la
fonctionnalité Clustering avec basculement.

Mise à niveau propagée de système d’exploitation de

cluster
La mise à niveau propagée de système d’exploitation de cluster permet à un
administrateur de mettre à niveau le système d’exploitation des nœuds de cluster
Windows Server 2012 R2 vers Windows Server 2016, sans arrêter les charges de travail
du serveur de fichiers avec scale-out ni Hyper-V. Vous pouvez utiliser cette
fonctionnalité pour éviter les pénalités de temps d’arrêt sur les contrats de niveau de
service (SLA).

Pour plus d’informations, consultez Mise à niveau propagée du système d’exploitation

de cluster.

Témoin cloud
Dans Windows Server 2016, Témoin cloud est un nouveau type de témoin de quorum de
cluster avec basculement, qui utilise Microsoft Azure comme point d’arbitrage. Comme
n’importe quel autre témoin de quorum, le témoin cloud obtient un vote et peut être
utilisé dans les calculs de quorum. Vous pouvez le configurer comme témoin de quorum
à l’aide de l’Assistant Configuration de quorum du cluster.

Pour plus d’informations, consultez Déployer un témoin de cloud pour un cluster de

basculement.

Résilience des machines virtuelles

Windows Server 2016 inclut une résilience de calcul accrue des machines virtuelles (VM)
pour réduire les problèmes de communication intracluster dans votre cluster de calcul.
Cette résilience accrue comprend les mises à jour suivantes :

Vous pouvez désormais configurer les options suivantes pour définir la façon dont
les machines virtuelles doivent se comporter pendant les défaillances temporaires :

Le niveau de résilience définit la façon dont votre déploiement doit gérer les
défaillances temporaires.

La période de résilience définit la durée pendant laquelle toutes les machines

virtuelles sont autorisées à s’exécuter de manière isolée.

Les nœuds non sains sont mis en quarantaine et ne sont plus autorisés à rejoindre
le cluster. Cette fonctionnalité empêche les nœuds non sains d’affecter
négativement les autres nœuds et l’ensemble du cluster.

Pour en savoir plus sur les fonctionnalités de résilience de calcul, consultez Résilience de
calcul des machines virtuelles dans Windows Server 2016 .

Les machines virtuelles Windows Server 2016 incluent également de nouvelles

fonctionnalités de résilience de stockage pour gérer les défaillances de stockage
temporaires. L’amélioration de la résilience permet de préserver les états de session de
la machine virtuelle du locataire en cas d’interruption du stockage. Lorsqu’une machine
virtuelle se déconnecte de son stockage sous-jacent, elle se met en pause et attend le
rétablissement du stockage. Pendant qu’elle est en pause, la machine virtuelle conserve
le contexte des applications qui s’y exécutaient au moment de la défaillance du
stockage. Lorsque la connexion entre la machine virtuelle et le stockage est restaurée, la
machine virtuelle retourne à son état d’exécution. Par conséquent, l’état de session de la
machine du locataire est conservé pendant la récupération.

Les nouvelles fonctionnalités de résilience du stockage s’appliquent également aux

clusters invités.

Améliorations apportées au diagnostic

Pour vous aider à diagnostiquer les problèmes liés aux clusters de basculement,
Windows Server 2016 comprend les éléments suivants :

Plusieurs améliorations apportées aux fichiers journaux du cluster, comme les

informations sur le fuseau horaire et le journal DiagnosticVerbose, facilitent la
résolution des problèmes de clustering de basculement. Pour plus d’informations,
consultez Windows Server 2016 Failover Cluster Troubleshooting Enhancements -
Cluster Log .
 Un nouveau type de vidage de mémoire active filtre la plupart des pages de la
mémoire allouées aux machines virtuelles, ce qui réduit considérablement la taille
du fichier [Link] et facilite son enregistrement ou sa copie. Pour plus
d’informations, consultez Windows Server 2016 Failover Cluster Troubleshooting
Enhancements - Active Dump .

Clusters de basculement reconnaissant les sites

Windows Server 2016 inclut des clusters de basculement reconnaissant les sites qui
activent les nœuds de groupe dans les clusters étendus en fonction de leur
emplacement physique ou du site. La reconnaissance des sites par les clusters améliore
les opérations clés pendant le cycle de vie du cluster, comme le comportement de
basculement, les stratégies de placement, les pulsations entre les nœuds et le
comportement du quorum. Pour plus d’informations, consultez Site-aware Failover
Clusters in Windows Server 2016 .

Clusters de groupes de travail et à domaines multiples

Dans Windows Server 2012 R2 et les versions antérieures, un cluster peut uniquement
être créé entre des nœuds membres joints au même domaine. Windows Server 2016
déjoue cet obstacle en introduisant la possibilité de créer un cluster de basculement
sans dépendances Active Directory. Vous pouvez maintenant créer des clusters de
basculement dans les configurations suivantes :

Clusters à domaine unique, dont tous leurs nœuds sont rattachés au même
domaine.

Clusters à domaines multiples, dont les nœuds appartiennent à différents

domaines.

Clusters de groupe de travail, dont les nœuds sont des serveurs membres ou des
groupes de travail qui ne sont pas rattachés à un domaine.

Pour plus d’informations, consultez Workgroup and Multi-domain clusters in Windows

Server 2016

Équilibrage de charge des machines virtuelles

L’équilibrage de charge de machine virtuelle est une nouvelle fonctionnalité du
clustering de basculement qui équilibre de manière transparente la charge des machines
virtuelles sur les nœuds d’un cluster. La fonctionnalité identifie les nœuds trop sollicités
en fonction de la mémoire de la machine virtuelle et de l’utilisation du processeur sur le
nœud. Elle migre ensuite les machines virtuelles du nœud trop sollicité vers des nœuds
avec une bande passante disponible. Vous pouvez ajuster le degré auquel la
fonctionnalité équilibre les nœuds pour garantir des performances et une utilisation
optimales du cluster. L’équilibrage de charge est activé par défaut dans la préversion
technique de Windows Server 2016. Toutefois, l’équilibrage de charge est désactivé
quand l’optimisation dynamique SCVMM est activée.

Ordre de démarrage des machines virtuelles

L’ordre de démarrage de la machine virtuelle est une nouvelle fonctionnalité du
clustering de basculement qui introduit l’orchestration de l’ordre de démarrage pour les
machines virtuelles et les autres groupes d’un cluster. Vous pouvez désormais regrouper
des machines virtuelles en niveaux, puis créer des dépendances d’ordre de démarrage
entre différents niveaux. Ces dépendances garantissent que les machines virtuelles les
plus importantes, telles que les contrôleurs de domaine ou les machines virtuelles
d’utilitaire, démarrent en premier. Les machines virtuelles de niveau de priorité inférieur
ne démarrent qu’après le démarrage des machines virtuelles dont elles dépendent.

Réseaux de clusters à plusieurs cartes réseau et SMB

Multichannel simplifiés
Les réseaux de cluster de basculement ne sont plus limités à une seule carte d’interface
réseau (NIC) par sous-réseau ou réseau. Avec les réseaux de clusters simplifiés Server
Message Block (SMB) multicanaux et multi-NIC, la configuration du réseau est
automatique et chaque NIC du sous-réseau peut être utilisée pour le trafic des clusters
et des charges de travail. Cette amélioration permet aux clients d’optimiser le débit
réseau pour l’instance de cluster de basculement SQL Server, Hyper-V et d’autres
charges de travail SMB.

Pour plus d’informations, consultez Réseaux de cluster SMB Multichannel et multi-carte

réseau simplifiés.

Développement d’applications

Services IIS (Internet Information Services) 10.0

Les nouvelles fonctionnalités fournies par le serveur web IIS 10.0 dans Windows
Server 2016 sont notamment les suivantes :
 Prise en charge du protocole HTTP/2 dans la pile Gestion de réseau et intégration
à IIS 10.0, ce qui permet aux sites web IIS 10.0 de traiter automatiquement les
requêtes HTTP/2 pour les configurations prises en charge. Cette évolution apporte
de nombreuses améliorations comparé à HTTP/1.1, comme une réutilisation plus
efficace des connexions et une moindre latence, ce qui améliore les temps de
chargement des pages web.
Possibilité d’exécuter et de gérer IIS 10.0 dans Nano Server. Consultez IIS sur
Nano Server.
Prise en charge des en-têtes d’hôte génériques, permettant aux administrateurs de
configurer un serveur web pour un domaine de manière à ce qu’il traite les
requêtes de tout sous-domaine.
Un nouveau module PowerShell (IISAdministration) pour la gestion des services IIS.

Pour plus d'informations, consultez IIS .

Distributed Transaction Coordinator (MSDTC)

Trois nouvelles fonctionnalités ont été ajoutées dans Microsoft Windows 10 et Windows
Server 2016 :

Une nouvelle interface pour la méthode Rejoin de Resource Manager peut être
utilisée par un gestionnaire de ressources pour déterminer le résultat d’une
transaction incertaine après le redémarrage d’une base de données en raison
d’une erreur. Pour plus d’informations, consultez
IResourceManagerRejoinable::Rejoin.

La limite des noms de source de données (DSN) a été étendue de 256 octets à
3 072 octets. Pour plus d’informations, consultez IDtcToXaHelperFactory::Create,
IDtcToXaHelperSinglePipe::XARMCreate ou
IDtcToXaMapper::RequestNewResourceManager.

Suivi amélioré, qui vous permet de définir une clé de Registre de manière à inclure
un chemin de fichier image dans le nom de fichier Tracelog pour simplifier
l’identification du Tracelog à vérifier. Pour plus d’informations sur la configuration
du suivi pour MSDTC, consultez Guide pratique pour activer le suivi de diagnostic
pour MSDTC sur un ordinateur Windows .

Serveur DNS
Windows Server 2016 contient les mises à jour suivantes pour le serveur DNS (Domain
Name System).
Stratégies DNS
Vous pouvez configurer des stratégies DNS pour spécifier la façon dont un serveur DNS
répond aux requêtes DNS. Vous pouvez configurer les réponses DNS en fonction de
l’adresse IP du client, de l’heure de la journée et de plusieurs autres paramètres. Les
stratégies DNS peuvent activer le DNS qui prend en charge la géolocalisation, la gestion
du trafic, l’équilibrage de charge, le DNS split-brain et d’autres scénarios. Pour plus
d’informations, consultez le Guide de scénario de stratégie DNS.

RRL
Vous pouvez activer la limitation du taux de réponse (RRL) sur vos serveurs DNS pour
empêcher les systèmes malveillants de les utiliser pour lancer une attaque par déni de
service distribué (DDoS) sur un client DNS. La RRL empêche votre serveur DNS de
répondre à trop de requêtes en même temps, ce qui le protège lors des scénarios où un
botnet envoie plusieurs requêtes à la fois pour tenter d’interrompre les opérations du
serveur.

Prise en charge de DANE

Vous pouvez utiliser l’authentification d'entités nommées basée sur le DNS (DANE)
(RFC 6394 et RFC 6698 ) pour spécifier l’autorité de certification à partir de laquelle
vos clients DNS doivent attendre des certificats pour les noms de domaine hébergés sur
votre serveur DNS. Cela permet d’éviter les attaques de type attaque de l’intercepteur
où un acteur malveillant corrompt un cache DNS et pointe un nom DNS vers sa propre
adresse IP.

Prise en charge des enregistrements inconnus

Vous pouvez ajouter des enregistrements que le serveur DNS ne prend pas
explicitement en charge à l’aide de la fonctionnalité d’enregistrement inconnu. Un
enregistrement est inconnu lorsque le serveur DNS ne reconnaît pas son format RDATA.
Windows Server 2016 prend en charge les types d’enregistrements inconnus
(RFC 3597 ), ce qui vous permet d’ajouter des enregistrements inconnus aux zones de
serveur DNS Windows au format filaire binaire. Le programme de résolution de mise en
cache Windows peut déjà traiter des types d’enregistrements inconnus. Le serveur DNS
Windows n’effectue pas de traitement spécifique à l’enregistrement pour les
enregistrements inconnus, mais peut les envoyer en réponse aux requêtes qu’il reçoit.

Indicateurs racine IPv6

Le serveur DNS Windows inclut désormais des indications de racine IPv6 publiées par
l’IANA (Internet Assigned Numbers Authority). La prise en charge des indications de
racine IPv6 vous permet d’effectuer des requêtes Internet qui utilisent les serveurs racine
IPv6 pour effectuer des résolutions de noms.

Prise en charge de Windows PowerShell

Windows Server 2016 inclut de nouvelles commandes que vous pouvez utiliser pour
configurer DNS dans PowerShell. Pour plus d’informations, consultez le module
DnsServer de Windows Server 2016 et le module DnsClient de Windows Server 2016.

Support Nano Server pour le service DNS basé sur les

fichiers
Vous pouvez déployer des serveurs DNS dans Windows Server 2016 sur une image
Nano Server. Cette option de déploiement est disponible si vous utilisez un DNS basé
sur les fichiers. En exécutant un serveur DNS sur une image Nano Server, vous pouvez
exécuter vos serveurs DNS avec une réduction de l’encombrement, un démarrage rapide
et un minimum de correctifs.

７ Notes

Le service DNS intégré à Active Directory n’est pas pris en charge sur Nano Server.

Client DNS
Le service client DNS offre désormais une prise en charge améliorée des ordinateurs
dotés de plusieurs interfaces réseau.

Les ordinateurs multirésidents peuvent également utiliser la liaison du service client DNS
pour améliorer la résolution du serveur :

Lorsque vous utilisez un serveur DNS configuré sur une interface spécifique pour
résoudre une requête DNS, le client DNS se lie à l'interface avant d'envoyer la
requête. Cette liaison permet au client DNS de spécifier l'interface où la résolution
de nom doit avoir lieu, optimisant ainsi les communications entre les applications
et le client DNS sur l'interface réseau.

Si le serveur DNS que vous utilisez a été désigné par un paramètre de stratégie de
groupe de la table de stratégie de résolution de noms (NRPT), le service client DNS
 ne se lie pas à l'interface spécifiée.

７ Notes

Les modifications apportées au service client DNS dans Windows 10 sont

également présentes dans les ordinateurs exécutant Windows Server 2016 et les
versions ultérieures.

Services Bureau à distance

Services Bureau à distance (RDS) a apporté les modifications suivantes pour Windows
Server 2016.

Compatibilité des applications

RDS et Windows Server 2016 sont compatibles avec de nombreuses applications
Windows 10, créant une expérience utilisateur presque identique à celle d’un bureau
physique.

Azure SQL Database

Le service Broker pour les connexions Bureau à distance (RD) peut désormais stocker
toutes les informations de déploiement, telles que les états de connexion et les
associations utilisateur-hôte, dans une base de données SQL Azure structurée partagée.
Cette fonctionnalité vous permet d’utiliser un environnement à haute disponibilité sans
avoir à utiliser un groupe de disponibilité Always On de SQL Server. Pour plus
d’informations, veuillez consulter la rubrique Utilisation d’Azure SQL DB pour votre
environnement haute disponibilité du Service Broker pour les connexions Bureau à
distance .

Améliorations graphiques
L’affectation de périphériques discrets pour Hyper-V vous permet de mapper
directement les unités de traitement graphique (GPU) sur une machine hôte à une
machine virtuelle (VM). Toutes les applications sur la VM qui nécessitent plus de GPU
que ce que la VM peut fournir peuvent utiliser la GPU mappée à la place. Nous avons
également amélioré le vGPU RemoteFX, y compris la prise en charge d’OpenGL 4.4,
d’OpenCL 1.1, de la résolution 4K et des VM Windows Server. Pour plus d’informations,
veuillez consulter la rubrique Affectation de périphériques discrets .
Améliorations du Broker pour les connexions de Bureau à
Distance
Nous avons amélioré la façon dont le Broker pour les connexions RD gère les
connexions pendant les tempêtes de connexion, qui sont des périodes de demandes
d’inscription élevées des utilisateurs. Le Broker pour les connexions RD peut désormais
gérer plus de 10 000 demandes d’inscription simultanées ! Les améliorations de la
maintenance facilitent également la réalisation de la maintenance sur votre déploiement
en vous permettant de réintégrer rapidement les serveurs dans l’environnement une fois
qu’ils sont prêts à être remis en ligne. Pour plus d’informations, veuillez consulter la
section Amélioration des performances du Broker pour les connexions Bureau à
distance .

Modifications du protocole RDP 10

Le protocole Bureau à distance (RDP) 10 utilise désormais le codec H.264/AVC 444, ce
qui optimise à la fois la vidéo et le texte. Cette version inclut également la prise en
charge de la saisie au stylet. Ces nouvelles fonctionnalités permettent à votre session à
distance de se rapprocher davantage d’une session locale. Pour plus d’informations,
veuillez consulter la section Améliorations RDP 10 AVC/H.264 dans Windows 10 et
Windows Server 2016 .

Personal session desktops

Personal session desktops est une nouvelle fonctionnalité qui vous permet d’héberger
votre propre bureau personnel dans le cloud. Les privilèges administratifs et les hôtes de
session dédiés éliminent la complexité des environnements d’hébergement où les
utilisateurs souhaitent gérer un bureau à distance comme un bureau local. Pour plus
d’informations, veuillez consulter la rubrique Personal Session Desktops.

Authentification Kerberos
Windows Server 2016 inclut les mises à jour suivantes pour l’authentification Kerberos.

Prise en charge du centre de distribution de clés (KDC)

pour l’authentification cliente basée sur l’approbation de
clé publique
Les centres de distribution de clés (KDC) prennent désormais en charge le mappage des
clés publiques. Si vous provisionnez une clé publique pour un compte, le KDC prend en
charge Kerberos PKInit explicitement à l’aide de cette clé. Étant donné qu’il n’y a pas de
validation de certificat, Kerberos prend en charge les certificats auto-signés, mais pas la
garantie du mécanisme d’authentification.

Les comptes que vous avez configurés pour utiliser l’approbation de clé utilisent
uniquement l’approbation de clé, quelle que soit la façon dont vous avez configuré le
paramètre UseSubjectAltName.

Prise en charge du client Kerberos et du KDC pour

l’extension RFC 8070 PKInit Freshness
À partir de Windows 10, version 1607 et Windows Server 2016, les clients Kerberos
peuvent utiliser l’extension RFC 8070 PKInit Freshness pour les connexions basées sur
des clés publiques. Par défaut, l’extension PKInit Freshness est désactivée pour vous
permettre de configurer la prise en charge du KDC pour la stratégie des modèles
d’administration du KDC de l'extension PKInit Freshness sur tous les contrôleurs de
domaine de votre domaine.

La stratégie a les paramètres suivants disponibles lorsque votre domaine se trouve dans
le niveau fonctionnel du domaine (DFL) de Windows Server 2016 :

Désactivé : le KDC n’offre jamais l’extension PKInit Freshness et accepte les

demandes d’authentification valides sans vérifier l’actualisation. Les utilisateurs ne
reçoivent pas le SID d’identité de clé publique actualisé.
Prise en charge : Kerberos prend en charge l’extension PKInit Freshness sur
demande. Les clients Kerberos qui sont authentifiés avec l’extension PKInit
Freshness reçoivent le SID d’identité de clé publique actualisé.
Obligatoire : l’extension PKInit Freshness est requise pour une authentification
réussie. Les clients Kerberos qui ne prennent pas en charge l’extension PKInit
Freshness échoueront toujours lors de l’utilisation d’informations d’identification
de clé publique.

Prise en charge des appareils joints à un domaine pour

l’authentification à l’aide d’une clé publique
Si un appareil joint à un domaine peut enregistrer sa clé publique liée auprès d’un
contrôleur de domaine (DC) Windows Server 2016, il peut alors s’authentifier avec la clé
publique à l’aide de l’authentification Kerberos PKInit auprès d’un DC Windows Server
2016.
Les appareils joints à un domaine avec des clés publiques liées enregistrées auprès d’un
contrôleur de domaine Windows Server 2016 peuvent désormais s’authentifier auprès
d’un contrôleur de domaine Windows Server 2016 à l’aide des protocoles Kerberos de
chiffrement à clé publique pour l’authentification initiale (PKInit). Pour plus
d’informations, consultez Authentification par clé publique d’appareil joint au domaine.

Les centres de distribution de clés (KDC) prennent désormais en charge

l’authentification à l’aide de la confiance de clé Kerberos.

Pour plus d’informations, consultez Prise en charge du centre de distribution de clés

pour le mappage de comptes à approbation de clé.

Les clients Kerberos autorisent les noms d’hôte d’adresses

IPv4 et IPv6 dans les noms de principaux de service (SPN)
À partir de Windows 10 version 1507 et Windows Server 2016, vous pouvez configurer
les clients Kerberos pour qu'ils prennent en charge les noms d’hôte IPv4 et IPv6 dans les
SPN. Pour plus d’informations, consultez Configuration de Kerberos pour les adresses IP.

Pour configurer la prise en charge des noms d’hôte d’adresses IP dans les SPN, créez
une entrée TryIPSPN. Par défaut, cette entrée n’existe pas dans le Registre. Vous devez
placer cette entrée sur le chemin suivant :

text

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Para
meters

Après avoir créé l’entrée, remplacez sa valeur DWORD par 1. Si cette valeur n’est pas
configurée, Kerberos ne fait pas de tentative de noms d’hôte d’adresses IP.

L’authentification Kerberos ne réussit que si le SPN est inscrit dans Active Directory.

Prise en charge du KDC pour le mappage de compte

d’approbation de clé
Les contrôleurs de domaine prennent désormais en charge le mappage des comptes à
approbation de clés et le remplacement vers AltSecID et UPN (User Principal Name)
existants dans le comportement SAN. Vous pouvez configurer la variable
UseSubjectAltName sur les paramètres suivants :
 Paramétrer la variable sur 0 rend le mappage explicite obligatoire. Les utilisateurs
doivent utiliser une approbation de clé ou définir une variable ExplicitAltSecID.

Paramétrer la variable sur 1, qui est la valeur par défaut, autorise le mappage
implicite.

Si vous configurez une approbation de clé pour un compte dans Windows

Server 2016 ou version ultérieure, le KDC utilise KeyTrust pour le mappage.

S’il n’y a pas d’UPN dans le SAN, le KDC tente d’utiliser AltSecID pour le
mappage.

S’il y a un UPN dans le SAN, le KDC tente d’utiliser l’UPN pour le mappage.

Active Directory Federation Services (AD FS)

AD FS pour Windows Server 2016 contient les mises à jour suivantes.

Se connecter avec l’authentification multi-facteur

Microsoft Entra
AD FS 2016 s’appuie sur les fonctionnalités d’authentification multifacteur (MFA) d’AD
FS dans Windows Server 2012 R2. Vous pouvez désormais autoriser l’authentification qui
nécessite uniquement un code d’authentification multifacteur Microsoft Entra au lieu
d’un nom d’utilisateur ou d’un mot de passe.

Lorsque vous configurez l’authentification multifacteur Microsoft Entra en tant que

méthode d’authentification principale, AD FS invite l’utilisateur à saisir son nom
d’utilisateur et le code de mot de passe à usage unique (OTP) de l’application
Azure Authenticator.

Lorsque vous configurez l’authentification multifacteur Microsoft Entra en tant que

méthode d’authentification secondaire ou supplémentaire, l’utilisateur fournit des
informations d’identification d’authentification principales. Les utilisateurs peuvent
se connecter à l’aide de l’authentification intégrée Windows, qui peut leur
demander leur nom d’utilisateur et leur mot de passe, leur carte à puce ou un
certificat d’utilisateur ou d’appareil. Ensuite, les utilisateurs sont invités à fournir
leurs informations d’identification secondaires, telles que l’authentification
multifacteur Microsoft Entra basée sur le texte, la voix ou l’OTP.

La nouvelle carte d’authentification multifacteur Microsoft Entra intégrée offre un

paramétrage et une configuration plus simples pour l’authentification multifacteur
Microsoft Entra avec AD FS.
 Les organisations peuvent utiliser l’authentification multifacteur Microsoft Entra
sans disposer d’un serveur d’authentification multifacteur Microsoft Entra local.

Vous pouvez configurer l’authentification multifacteur Microsoft Entra pour un

intranet, un extranet ou dans le cadre d’une stratégie de contrôle d’accès.

Pour en savoir plus sur l’authentification multifacteur Microsoft Entra avec AD FS,
consultez Configurer AD FS 2016 et l’authentification multifacteur Microsoft Entra.

Accès sans mot de passe à partir des appareils conformes

AD FS 2016 s’appuie sur les fonctionnalités d’inscription d’appareils précédentes pour
activer l’authentification et le contrôle d’accès en fonction de l’état de conformité des
appareils. Les utilisateurs peuvent se connecter à l’aide des informations d’identification
de l’appareil, et AD FS réévalue la conformité quand les attributs de l’appareil changent
afin de garantir l’application des stratégies. Cette fonctionnalité active les stratégies
suivantes :

Activez l’accès uniquement à partir d’appareils managés et/ou conformes.

Activez l’accès extranet uniquement à partir d’appareils managés et/ou conformes.

Exiger l’authentification multifacteur pour les ordinateurs qui ne sont pas managés
ou sont non conformes.

AD FS fournit le composant local des stratégies d’accès conditionnel dans un scénario

hybride. Quand vous inscrivez des appareils auprès d’Azure AD pour l’accès conditionnel
aux ressources cloud, vous pouvez aussi utiliser l’identité de l’appareil pour les stratégies
AD FS.
Pour plus d’informations sur l’utilisation de l’accès conditionnel basé sur l’appareil dans
le cloud, consultez Accès conditionnel Azure Active Directory.

Pour en savoir plus sur l’utilisation de l’accès conditionnel basé sur les appareils avec AD
FS, consultez Planification de l’accès conditionnel basé sur l’appareil avec AD FS et
Stratégies de contrôle d’accès dans AD FS.

Se connecter avec Windows Hello Entreprise

Les appareils Windows 10 contiennent Windows Hello et Windows Hello Entreprise, qui
remplacent les mots de passe utilisateur par des informations d’identification de
l’utilisateur puissantes, protégées par un mouvement de l’utilisateur (un code
confidentiel, un mouvement biométrique comme une empreinte digitale ou une
reconnaissance faciale). Avec Windows Hello, les utilisateurs peuvent se connecter à des
applications AD FS à partir d’un intranet ou d’un extranet sans nécessiter de mot de
passe.

Pour plus d’informations sur l’utilisation de Windows Hello Entreprise dans votre
organisation, consultez Activer Windows Hello Entreprise dans votre organisation.

Authentification moderne
AD FS 2016 prend en charge les protocoles modernes les plus récents qui offrent une
meilleure expérience utilisateur pour Windows 10 et les appareils et applications iOS et
Android les plus récents.
Pour plus d’informations, consultez Scénarios AD FS pour les développeurs.

Configurer des stratégies de contrôle d’accès sans avoir à

connaître le langage de règles de revendication
Avant, les administrateurs AD FS devaient configurer des stratégies en utilisant le
langage de règles de revendication AD FS, ce qui compliquait la configuration et la
maintenance des stratégies. Avec les stratégies de contrôle d’accès, les administrateurs
peuvent utiliser des modèles intégrés pour appliquer des stratégies courantes. Par
exemple, vous pouvez utiliser des modèles pour appliquer les stratégies suivantes :

Autoriser l’accès intranet uniquement.

Autoriser tout le monde et exiger l’authentification MFA à partir de l’extranet.

Autoriser tout le monde et exiger l’authentification MFA pour un groupe

spécifique.

Les modèles sont faciles à personnaliser. Vous pouvez appliquer des exceptions ou des
règles de stratégie supplémentaires, et appliquer ces modifications à une ou plusieurs
applications pour une mise en œuvre cohérente de la stratégie.

Pour plus d’informations, consultez Stratégies de contrôle d’accès dans AD FS.

Activer l’authentification avec des annuaires LDAP non-

Active Directory
De nombreuses organisations combinent Active Directory et des annuaires tiers. Avec la
prise en charge dans AD FS de l’authentification des utilisateurs stockés dans des
annuaires compatibles Lightweight Directory Access Protocol (LDAP) v3, vous pouvez
désormais utilisé AD FS dans les scénarios suivants :

Les utilisateurs d’annuaires tiers compatibles LDAP v3.

Les utilisateurs des forêts Active Directory pour lesquelles aucune approbation
bidirectionnelle Active Directory n’est configurée.

Les utilisateurs des services AD LDS (Active Directory Lightweight Directory

Services).

Pour plus d'informations, voir Configure AD FS to authenticate users stored in LDAP

directories.
Personnaliser l’expérience de connexion pour les
applications AD FS
Avant, AD FS dans Windows Server 2012 R2 offrait une expérience d’authentification
commune pour toutes les applications par partie de confiance, avec la possibilité de
personnaliser un sous-ensemble de contenu textuel par application. Avec Windows
Server 2016, vous pouvez personnaliser non seulement les messages, mais aussi les
images, le logo et le thème web par application. Vous pouvez aussi créer des thèmes
web personnalisés et appliquer ces thèmes par partie de confiance.

Pour plus d’informations, consultez Personnalisation de la connexion utilisateur AD FS.

Audit rationalisé pour faciliter la gestion administrative

Dans les versions précédentes d’AD FS, une seule requête pouvait générer de nombreux
événements d’audit. Les informations pertinentes sur les activités de connexion ou
d’émission de jetons étaient souvent absentes ou réparties sur plusieurs événements
d’audit, ce qui compliquait le diagnostic des problèmes. Ainsi, les événements d’audit
étaient désactivés par défaut. Toutefois, dans AD FS 2016, le processus d’audit est plus
rationalisé et les informations pertinentes sont plus faciles à trouver. Pour plus
d’informations, consultez Améliorations de l’audit apportées à AD FS dans Windows
Server 2016.

Amélioration de l’interopérabilité avec SAML 2.0 pour la

participation aux confédérations
AD FS 2016 offre davantage de prise en charge du protocole SAML, notamment la prise
en charge de l’importation des approbations basées sur des métadonnées contenant
plusieurs entités. Ce changement vous permet de configurer AD FS pour participer à des
confédérations telles que la fédération InCommon et d’autres implémentations
conformes à la norme eGov 2.0.

Pour plus d’informations, consultez Interopérabilité améliorée avec SAML 2.0.

Gestion simplifiée des mots de passe pour les utilisateurs

Microsoft 365 fédérés
Vous pouvez configurer AD FS pour envoyer des revendications d’expiration de mot de
passe à toutes les approbations ou applications de partie de confiance qu’il protège. La
façon dont ces revendications apparaissent varie selon les applications. Par exemple,
avec Office 365 comme partie de confiance, des mises à jour ont été implémentées dans
Exchange et Outlook pour informer les utilisateurs fédérés de l’expiration prochaine de
leurs mots de passe.

Pour plus d’informations, consultez Configurer AD FS pour envoyer les revendications

d’expiration de mot de passe.

Simplification du passage d’AD FS dans Windows

Server 2012 R2 à AD FS dans Windows Server 2016
Auparavant, la migration vers une nouvelle version d’AD FS nécessitait l’exportation des
paramètres de configuration à partir de votre batterie Windows Server vers une nouvelle
batterie de serveurs parallèle. AD FS sur Windows Server 2016 facilite le processus en
supprimant l’obligation de disposer d’une batterie de serveurs parallèles. Lorsque vous
ajoutez un serveur Windows Server 2016 à une batterie de serveurs Windows
Server 2012 R2, le nouveau serveur se comporte comme un serveur Windows
Server 2012 R2. Lorsque vous êtes prêt à effectuer une mise à niveau et que vous avez
supprimé les serveurs plus anciens, vous pouvez passer au niveau opérationnel
Windows Server 2016. Pour plus d’informations, consultez Mise à niveau vers AD FS
dans Windows Server 2016.

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Authentification par clé publique
d’appareil joint au domaine
Article • 09/03/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows 10

Kerberos a ajouté la prise en charge des appareils joints à un domaine qui se connectent
avec un certificat, à compter de Windows Server 2012 et Windows 8. Ce changement
permet aux fournisseurs tiers de créer des solutions pour provisionner et initialiser des
certificats que les appareils joints à un domaine peuvent utiliser pour l’authentification
de domaine.

Provisionnement automatique de clé publique

À compter de Windows 10 version 1507 et de Windows Server 2016, les appareils joints
à un domaine provisionnent automatiquement une clé publique liée sur un contrôleur
de domaine Windows Server 2016. Dès qu’une clé est provisionnée, Windows peut
utiliser l’authentification par clé publique sur le domaine.

Génération de la clé
Si l’appareil exécute Credential Guard, une paire de clés publique/privée est créée,
protégée par Credential Guard.

Si Credential Guard n’est pas disponible, mais qu’il y a un TPM, la paire de clés
publique/privée créée est protégée par le TPM.

Si aucun des deux n’est disponible, aucune paire de clés n’est générée et l’appareil peut
s’authentifier uniquement avec un mot de passe.

Provisionnement d’une clé publique de compte

d’ordinateur
Quand Windows démarre, il vérifie si une clé publique est provisionnée pour son
compte d’ordinateur. Si ce n’est pas le cas, il génère une clé publique liée et la configure
pour son compte dans AD en utilisant un contrôleur de domaine Windows Server 2016
ou supérieur. Si tous les contrôleurs de domaine sont de niveau inférieur, aucune clé
n’est provisionnée.

Configuration de l’appareil pour utiliser uniquement une

clé publique
Si le paramètre de stratégie de groupe Prise en charge de l’authentification de
l’appareil avec un certificat est défini sur Forcer, l’appareil doit trouver un contrôleur de
domaine qui exécute Windows Server 2016 ou version ultérieure pour s’authentifier. Le
paramètre se trouve sous Modèles d’administration > Système > Kerberos.

Configuration de l’appareil pour utiliser uniquement un

mot de passe
Si le paramètre de stratégie de groupe Prise en charge de l’authentification de
l’appareil avec un certificat est désactivé, le mot de passe est toujours utilisé. Le
paramètre se trouve sous Modèles d’administration > Système > Kerberos.

Authentification des appareils joints à un

domaine avec une clé publique
Quand Windows a un certificat pour l’appareil joint au domaine, Kerberos authentifie
d’abord en utilisant le certificat et, en cas d’échec, effectue de nouvelles tentatives avec
le mot de passe. Cela permet à l’appareil de s’authentifier sur les contrôleurs de
domaine de niveau inférieur.

Comme les clés publiques provisionnées automatiquement ont un certificat auto-signé,

la validation du certificat échoue sur les contrôleurs de domaine qui ne prennent pas en
charge le mappage des comptes d’approbation de clé. Par défaut, Windows retente
l’authentification avec le mot de passe de domaine de l’appareil.
Kerberos Constrained Delegation
Overview
Article • 11/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cette rubrique de vue d’ensemble destinée aux professionnels de l’informatique décrit

les nouvelles fonctionnalités de la délégation Kerberos contrainte dans Windows
Server 2012 R2 et Windows Server 2012.

Description de la fonctionnalité

La délégation Kerberos contrainte a été introduite pour la première fois dans Windows
Server 2003 pour fournir une forme de délégation plus sûre utilisable par les services.
Lorsqu’elle est configurée, la délégation contrainte restreint les services sur lesquels le
serveur spécifié peut agir pour le compte d’un utilisateur. Des droits d’administrateur de
domaine sont requis pour configurer un compte de domaine pour un service et cela
restreint le compte à un domaine unique. De nos jours, les services frontaux ne sont pas
conçus pour être limités à une intégration aux seuls services dans leur domaine.

Dans les systèmes d’exploitation précédents sur lesquels l’administrateur de domaine a

configuré le service, l’administrateur de service ne possédait aucun moyen de connaître
les services frontaux qui déléguaient vers des services de ressources qu’ils détenaient. Et
tout service frontal qui pouvait déléguer à un service de ressources représentait un
point d’attaque potentiel. Si un serveur hébergeant un service frontal était compromis,
et qu’il était configuré pour déléguer aux services de ressources, les services de
ressources pouvaient également être compromis.

Dans Windows Server 2012 R2 et Windows Server 2012, la possibilité de configurer la

délégation contrainte pour le service a été transférée de l’administrateur de domaine à
l’administrateur de service. De cette façon, l’administrateur de service principal peut
autoriser ou refuser les services frontaux.

Pour obtenir des informations détaillées sur la délégation contrainte telle qu’elle a été
introduite dans Windows Server 2003, voir Transition du protocole Kerberos et
délégation contrainte.

L’implémentation Windows Server 2012 R2 et Windows Server 2012 du protocole

Kerberos inclut des extensions spécifiquement pour la délégation contrainte. Service for
User to Proxy (S4U2Proxy) permet à un service d’utiliser son ticket de service Kerberos
pour qu’un utilisateur obtienne un ticket de service à partir du centre de distribution de
clés (KDC) pour un service principal. Ces extensions permettent de configurer la
délégation contrainte sur le compte du service principal, lequel peut se trouver dans un
autre domaine. Pour plus d’informations sur ces extensions, voir [MS-SFU] : extensions
du protocole Kerberos : spécification du protocole de service pour l’utilisateur et de
délégation contrainte dans MSDN Library.

Cas pratiques

La délégation contrainte fournit aux administrateurs de service la capacité de spécifier et

d’appliquer des délimitations d’approbation d’application en limitant l’étendue dans
laquelle les services d’application peuvent agir pour le compte d’un utilisateur. Les
administrateurs de service peuvent spécifier les comptes de services frontaux qui
peuvent effectuer une délégation sur leurs services principaux.

La prise en charge de la délégation contrainte sur plusieurs domaines dans Windows

Server 2012 R2 et Windows Server 2012 permet aux services frontaux tels que Microsoft
Internet Security and Acceleration (ISA) Server, Microsoft Forefront Threat Management
Gateway, Microsoft Exchange Outlook Web Access (OWA) et Microsoft SharePoint
Server d’être configurés pour utiliser la délégation contrainte pour s’authentifier auprès
des serveurs dans d’autres domaines. Cela permet la prise en charge de solutions de
service sur plusieurs domaines via une infrastructure Kerberos existante. La délégation
Kerberos contrainte peut être gérée par les administrateurs de domaine ou les
administrateurs de service.

Délégation contrainte basée sur les ressources

sur plusieurs domaines
La délégation Kerberos contrainte peut être utilisée pour fournir une délégation
contrainte lorsque les services frontaux et les services de ressources ne sont pas dans le
même domaine. Les administrateurs de service sont en mesure de configurer la nouvelle
délégation en spécifiant les comptes de domaine des services frontaux qui peuvent
emprunter l’identité des utilisateurs sur les objets de compte des services de ressources.

Quels avantages cette modification procure-t-elle ?

En prenant en charge la délégation contrainte sur plusieurs domaines, les services

peuvent être configurés pour utiliser la délégation contrainte pour s’authentifier auprès
des serveurs dans d’autres domaines plutôt qu’utiliser une délégation non contrainte.
Cela permet la prise en charge de l’authentification pour des solutions de service sur
plusieurs domaines via une infrastructure Kerberos existante sans qu’il soit nécessaire
d’approuver les services frontaux pour effectuer une délégation à un service
quelconque.
Cela déplace également la décision de décider si un serveur doit approuver la source
d’une identité déléguée de l’administrateur de domaine délégué au propriétaire de la
ressource.

En quoi le fonctionnement est-il différent ?

Une modification dans le protocole sous-jacent permet la délégation contrainte sur

plusieurs domaines. L’implémentation du protocole Kerberos dans Windows Server 2012
R2 et Windows Server 2012 inclut des extensions du protocole S4U2Proxy (Service for
User to Proxy). Il s’agit d’un ensemble d’extensions au protocole Kerberos qui
permettent à un service d’utiliser son ticket de service Kerberos pour qu’un utilisateur
obtienne un ticket de service à partir du centre de distribution de clés (KDC) pour un
service principal.

Pour obtenir des informations d’implémentation concernant ces extensions, consultez

[MS-SFU] : extensions du protocole Kerberos : spécification du protocole de service pour
l’utilisateur et de délégation contrainte dans MSDN.

Pour plus d’informations sur la séquence de message de base pour la délégation

Kerberos avec un ticket TGT (Ticket-Granting Ticket) transmis par rapport aux extensions
S4U (Service for User), reportez-vous à la section 1.3.3 Vue d’ensemble du protocole
dans le document [MS-SFU] : extensions du protocole Kerberos : spécification du
protocole de service pour l’utilisateur et de délégation contrainte.

Implications de sécurité de la délégation contrainte basée sur les ressources

La délégation contrainte basée sur les ressources place le contrôle de la délégation

entre les mains de l’administrateur propriétaire de la ressource accessible. Elle dépend
des attributs du service de ressource plutôt que du service approuvé pour déléguer. Par
conséquent, la délégation contrainte basée sur les ressources ne peut pas utiliser le bit
Trusted-to-Authenticate-for-Delegation qui contrôlait précédemment la transition de
protocole. Le centre de distribution de clés (KDC) autorise toujours la transition de
protocole lors de l’exécution d’une délégation contrainte basée sur les ressources
comme si le bit était défini.

Étant donné que le KDC ne limite pas la transition de protocole, deux nouveaux ID de
sécurité (SID) connus ont été introduits pour donner ce contrôle à l’administrateur de la
ressource. Ces SID identifient si une transition de protocole a eu lieu, et peuvent être
utilisés avec des listes de contrôle d’accès standard pour accorder ou limiter l’accès en
fonction des besoins.

SID Description
 SID Description

AUTHENTICATION_AUTHORITY_ASSERTED_IDENTITY SID qui signifie que l’identité du client est

S-1-18-1 déclarée par une autorité
d’authentification à partir de la preuve de
possession des informations
d’identification du client.

SERVICE_ASSERTED_IDENTITY Un SID qui signifie que l’identité du client

S-1-18-2 est déclarée par un service.

Un service de back-end peut utiliser des expressions ACL standard pour déterminer la
façon dont l’utilisateur a été authentifié.

Comment configurer la délégation contrainte basée sur les ressources ?

Pour configurer un service de ressources pour autoriser l’accès à un service frontal pour
le compte d’utilisateurs, utilisez les applets de commande Windows PowerShell.

Pour récupérer une liste de principaux, utilisez les applets de commande Get-
ADComputer, Get-ADServiceAccountet Get-ADUser avec le paramètre Properties
PrincipalsAllowedToDelegateToAccount.

Pour configurer le service de ressources, utilisez les applets de commande New-

ADComputer, New-ADServiceAccount, New-ADUser, Set-ADComputer, Set-
ADServiceAccountet Set-ADUser avec le paramètre
PrincipalsAllowedToDelegateToAccount.

Configuration logicielle requise

La délégation contrainte basée sur les ressources peut uniquement être configurée sur
un contrôleur de domaine exécutant Windows Server 2012 R2 et Windows Server 2012,
mais elle peut être appliquée au sein d’une forêt mixte.

Vous devez appliquer le correctif logiciel suivant à tous les contrôleurs de domaine qui
exécutent Windows Server 2012 dans les domaines de compte d’utilisateur sur le
chemin d’accès de référencement entre les domaines frontaux et principaux qui
exécutent des systèmes d’exploitation antérieurs à Windows Server : échec
KDC_ERR_POLICY de délégation contrainte basée sur les ressources dans des
environnements dotés de contrôleurs de domaine basés sur Windows Server 2008 R2
([Link]
delegation-kdc-err-policy-failure-in-enviro ).
Empêcher Kerberos de modifier le mot
de passe utilisant des clés secrètes RC4
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows Server 2008 R2 et Windows Server 2008

Cette rubrique destinée aux professionnels de l’informatique explique certaines

limitations du protocole Kerberos qui peuvent conduire un utilisateur malveillant à
prendre le contrôle du compte d’un utilisateur. Il existe une limitation dans le service
d’authentification réseau Kerberos (V5) standard (RFC 4120), qui est bien connue dans le
secteur, selon laquelle un attaquant peut s’authentifier en tant qu’utilisateur ou modifier
le mot de passe de cet utilisateur si l’attaquant connaît la clé secrète de l’utilisateur.

La possession des clés secrètes Kerberos dérivées d’un mot de passe d’un utilisateur
(RC4 et Advanced Encryption Standard [AES] par défaut) est validée lors de l’échange de
modification de mot de passe Kerberos par RFC 4757. Le mot de passe en texte clair de
l’utilisateur n’est jamais fourni au Centre de distribution de clés (KDC) et, par défaut, les
contrôleurs de domaine Active Directory ne possèdent pas de copie de mots de passe
en texte clair pour les comptes. Si le contrôleur de domaine ne prend pas en charge un
type de chiffrement Kerberos, cette clé secrète ne peut pas être utilisée pour modifier le
mot de passe.

Dans les systèmes d’exploitation Windows désignés dans la liste S’applique à au début
de cette rubrique, il existe trois façons de bloquer la possibilité de modifier les mots de
passe à l’aide de Kerberos avec des clés secrètes RC4 :

Configurez le compte d’utilisateur pour inclure l’option compte La carte à puce est
requise pour l’ouverture de session interactive. Cela limite l’utilisateur à se
connecter uniquement avec une carte à puce valide afin que les demandes de
service d’authentification RC4 (AS-REQs) soient rejetées. Pour définir les options de
compte sur un compte, cliquez avec le bouton droit sur le compte, cliquez sur
Propriétés, puis cliquez sur l’onglet Compte.

Désactivez la prise en charge de RC4 pour Kerberos sur tous les contrôleurs de
domaine. Cela nécessite au minimum un niveau fonctionnel de domaine Windows
Server 2008 et un environnement dans lequel tous les clients Kerberos, serveurs
d’applications et relations d’approbation vers et depuis le domaine doivent
prendre en charge AES. La prise en charge d’AES a été introduite dans Windows
Server 2008 et Windows Vista.
 ７ Notes

Il existe un problème connu lors de la désactivation de RC4 qui peut entraîner

le redémarrage du système. Consultez les correctifs logiciels suivants :
Windows Server 2012 R2
Windows Server 2012
Aucun correctif logiciel n’est disponible pour les versions antérieures de
Windows Server

Déployez des domaines définis sur Windows Server 2012 niveau fonctionnel de
domaine R2 ou supérieur, et configurez les utilisateurs en tant que membres du
groupe de sécurité Utilisateurs protégés. Étant donné que cette fonctionnalité
perturbe plus que la simple utilisation de RC4 dans le protocole Kerberos,
consultez les ressources dans la section Voir aussi suivante.

Voir aussi
Pour plus d’informations sur la façon d’empêcher l’utilisation du type de
chiffrement RC4 dans Windows Server 2012 domaines R2, consultez Groupe de
sécurité utilisateurs protégés.

Pour obtenir des explications sur RFC 4120 et RFC 4757, consultez Documents
IETF .
Les clients Kerberos autorisent les noms
d’hôte d’adresses IPv4 et IPv6 dans les
noms de principal de service (SPN)
Article • 09/03/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

À compter de Windows 10 version 1507 et de Windows Server 2016, les clients Kerberos
peuvent être configurés pour prendre en charge les noms d’hôte IPv4 et IPv6 dans les
SPN.

Par défaut, Windows ne tente pas l’authentification Kerberos pour un hôte si le nom
d’hôte est une adresse IP. Il utilise les autres protocoles d’authentification activés
comme NTLM. Toutefois, les applications sont parfois codées en dur pour utiliser des
adresses IP, ce qui signifie que l’application utilise NTLM et non pas Kerberos. Cela peut
entraîner des problèmes de compatibilité quand les environnements désactivent NTLM.

Pour réduire l’impact de la désactivation de NTLM, une nouvelle fonctionnalité a été

introduite qui permet aux administrateurs d’utiliser des adresses IP comme noms d’hôte
dans les noms de principal de service. Cette fonctionnalité est activée sur le client avec
une valeur de clé de Registre.

Invite de commandes Windows

reg add
"HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Par
ameters" /v TryIPSPN /t REG_DWORD /d 1 /f

Pour configurer la prise en charge des noms d’hôte d’adresse IP dans les SPN, créez une
entrée TryIPSPN. Par défaut, cette entrée n’existe pas dans le Registre. Après avoir créé
l’entrée, remplacez la valeur DWORD par 1. Cette valeur de Registre doit être définie sur
chaque machine cliente qui doit accéder aux ressources protégées par Kerberos pour
chaque adresse IP.

Configuration d’un nom de principal de service

comme adresse IP
Un nom de principal de service est un identificateur unique utilisé pendant
l’authentification Kerberos pour identifier un service sur le réseau. Un SPN est composé
d’un service, d’un nom d’hôte et éventuellement d’un port au format
service/hostname[:port] , par exemple host/[Link] . Windows inscrit plusieurs
SPN sur un objet d’ordinateur quand une machine est jointe à Active Directory.

Les adresses IP ne sont normalement pas utilisées à la place des noms d’hôte, car elles
sont souvent temporaires. Cela peut entraîner des conflits et des échecs
d’authentification quand les baux des adresses expirent et se renouvellent. Par
conséquent, l’inscription d’un SPN basé sur une adresse IP est un processus manuel qui
doit être utilisé seulement quand il est impossible de basculer vers un nom d’hôte DNS.

L’approche recommandée est d’utiliser l’outil [Link]. Notez qu’un SPN peut être
inscrit seulement sur un compte à la fois dans Active Directory, les adresses IP doivent
donc avoir des baux statiques si DHCP est utilisé.

Setspn -s <service>/[Link]> <domain-user-account>

Exemple :

Setspn -s host/[Link] server01

NTLM Overview
Article • 07/10/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cette rubrique destinée aux professionnels de l’informatique décrit NTLM et les

modifications apportées à cette fonctionnalité, et fournit des liens vers des ressources
techniques relatives à l’authentification Windows et NTLM pour Windows Server.

Description de la fonctionnalité
L’authentification NTLM désigne un ensemble de protocoles d’authentification inclus
dans la bibliothèque Windows Msv1_0.dll. Les protocoles d’authentification NTLM
comprennent les versions 1 et 2 de LAN Manager et les versions 1 et 2 de NTLM . Ils ont
pour but d’authentifier des utilisateurs et des ordinateurs sur la base d’un mécanisme de
stimulation/réponse destiné à prouver à un serveur ou un contrôleur de domaine qu’un
utilisateur connaît le mot de passe associé à un compte. Lorsque vous faites appel au
protocole NTLM, un serveur de ressources doit entreprendre l’une des actions suivantes
afin de vérifier l’identité d’un ordinateur ou d’un utilisateur dès qu’un nouveau jeton
d’accès est nécessaire :

Contactez un service d’authentification de domaine sur le contrôleur de domaine

du compte de domaine de l’ordinateur ou de l’utilisateur si le compte en question
est un compte de domaine.

Si le compte est un compte local, recherchez le compte de l’ordinateur ou de

l’utilisateur dans la base de données du compte local.

Applications actuelles
L’authentification NTLM est toujours prise en charge et doit servir à des fins
d’authentification Windows avec des systèmes configurés en tant que membres d’un
groupe de travail. Elle est également employée pour l’authentification de connexion
locale sur des ordinateurs autres que des contrôleurs de domaine. L’authentification
Kerberos version 5 est la méthode d’authentification recommandée pour les
environnements Active Directory. Toutefois une application Microsoft ou non Microsoft
peut continuer d’utiliser NTLM.

Limiter l’utilisation du protocole NTLM dans un environnement informatique requiert de

connaître les exigences liées à l’application déployée sur NTLM et les stratégies et
étapes nécessaires à la configuration des environnements informatiques pour utiliser
d’autres protocoles. De nouveaux paramètres et outils ont été ajoutés pour vous
permettre de découvrir comment le protocole NTLM est utilisé pour limiter de manière
sélective le trafic NTLM. Pour plus d’informations sur la façon d’analyser et de limiter
l’utilisation de NTLM dans vos environnements, voir Présentation des limites de
l’authentification NTLM pour accéder au guide relatif à l’audit et à la limitation de
l’utilisation du protocole NTLM.

Fonctionnalités nouvelles et modifiées

Il n’y a aucune modification de fonctionnalité pour NTLM dans Windows Server.

Fonctionnalité supprimée ou déconseillée

Il n’y a aucune fonctionnalité supprimée ou déconseillée pour NTLM dans Windows
Server.

Informations sur le Gestionnaire de serveur

L’authentification NTLM ne peut être configurée à partir du Gestionnaire de serveur.
Vous pouvez faire appel aux paramètres de stratégie de sécurité ou aux stratégies de
groupe pour gérer le mode d’application de l’authentification NTLM entre un système
informatique et un autre. Dans un domaine, Kerberos constitue le protocole
d’authentification par défaut.

Voir aussi
Le tableau qui suit répertorie les ressources adaptées à l’authentification NTLM et à
d’autres technologies d’authentification Windows.

Type de contenu Références

Évaluation du Présentation des limites de l’authentification NTLM

produit
Modifications apportées à l’authentification NTLM

Planification Guide de modélisation des menaces pesant sur l’infrastructure informatique

Menaces et contre-mesures : Paramètres de sécurité dans Windows Server

2003 et Windows XP
Type de contenu Références

Guide des menaces et des contre-mesures : Paramètres de sécurité dans

Windows Server 2008 et Windows Vista

Guide des menaces et des contre-mesures : Paramètres de sécurité sous

Windows Server 2008 R2 et Windows 7

Déploiement Protection étendue pour l’authentification

Guide relatif à l’audit et à la restriction de l’utilisation du protocole NTLM

Demander à l’équipe des services d’annuaire : Blocage de NTLM et vous :

Méthodologies d’audit et d’analyse d’applications dans Windows 7

Blog sur l’authentification Windows

Configuration de MaxConcurrentAPI pour une authentification directe NTLM

Développement Microsoft NTLM (Windows)

[MS-NLMP] : Spécifications du protocole d’authentification NT LAN

Manager (NTLM)

[MS-NNTP] : Authentification NT LAN Manager (NTLM) : Extension NNTP

(Network News Transfer Protocol)

[MS-NTHT] : Spécifications du protocole NTLM sur HTTP

Mises à jour Nouvelles protections d’authentification directe NTLM pour CVE-2022-

21857
Vue d’ensemble sur les mots de passe
Article • 12/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Cette rubrique pour le professionnel de l’informatique décrit les mots de passe utilisés
dans les systèmes d’exploitation Windows, ainsi que des liens vers la documentation et
les discussions sur l’utilisation des mots de passe dans une stratégie de gestion des
informations d’identification.

Description de la fonctionnalité
Les systèmes d’exploitation et les applications sont aujourd’hui conçus autour des mots
de passe et même si vous utilisez des cartes à puce ou des systèmes biométriques, tous
les comptes ont toujours des mots de passe et ils peuvent toujours être utilisés dans
certaines circonstances. Certains comptes, notamment les comptes utilisés pour
exécuter des services, ne peuvent même pas utiliser de cartes à puce et de jetons
biométriques et doivent donc utiliser un mot de passe pour s’authentifier. Windows
protège les mots de passe à l’aide de hachages de chiffrement.

Pour plus d’informations sur les mots de passe Windows, consultez Vue d’ensemble
technique des mots de passe.

Cas pratiques
Dans Windows et de nombreux autres systèmes d’exploitation, la méthode la plus
courante pour l’authentification de l’identité d’un utilisateur consiste à utiliser une
phrase secrète ou un mot de passe. La sécurisation de votre environnement réseau
nécessite que les mots de passe forts soient utilisés par tous les utilisateurs. Cela permet
d’éviter la menace d’un utilisateur malveillant de deviner un mot de passe faible, qu’il
s’agisse de méthodes manuelles ou d’outils, pour acquérir les informations
d’identification d’un compte d’utilisateur compromis. Cela est particulièrement vrai pour
les comptes d’administrateur. Lorsque vous modifiez régulièrement un mot de passe
complexe, cela réduit la probabilité d’une attaque par mot de passe qui compromisse ce
compte.

Fonctionnalités nouvelles et modifiées

Dans Windows Server 2012 et Windows 8, les mots de passe d’image sont nouveaux.
Les mots de passe d’image sont une combinaison d’une image sélectionnée par
l’utilisateur couplée à une série de mouvements. La fonctionnalité de mot de passe
d’image est désactivée sur les ordinateurs joints au domaine. Des liens vers plus
d’informations sur les mots de passe image sont répertoriés dans Voir aussi ci-dessous.

Aucune modification n’a été apportée aux fonctionnalités de mot de passe dans
Windows Server 2012 et Windows 8. Aucun nouveau paramètre de stratégie de groupe
n’a été ajouté. Toutefois, des améliorations ont été apportées dans la gestion des
informations d’identification (et mot de passe), telles que les mots de passe d’image,
Credential Locker et la connexion à Windows 8 avec un compte Microsoft,
anciennement appelé ID Windows Live.

Fonctionnalités dépréciées
Aucune fonctionnalité de mot de passe n’a été déconseillée dans Windows Server 2012
et Windows 8.

Configuration logicielle requise

Dans les environnements d’entreprise, les mots de passe sont généralement gérés avec
les services de domaine Active Directory. Les mots de passe peuvent également être
gérés sur l’ordinateur local à l’aide des paramètres de sécurité locaux, des stratégies de
compte, de la stratégie de mot de passe.

Voir aussi
Ce tableau répertorie des ressources supplémentaires pour les fonctionnalités de mot
de passe, la technologie et la gestion des informations d’identification.

Type de Références
contenu

Documentation Protection de votre identité numérique

des scénarios

Opérations Utilisateurs et ordinateurs Active Directory

Dépannage Savoir quand votre mot de passe expire - Blog PowerShell Active Directory
Type de Références
contenu

Sécurité Guide des menaces et contre-mesures : stratégies de compte de Windows

Server 2008 R2 et Windows 7

Conseils pour modifier et créer des mots de passe forts

Outils et Référence des paramètres de stratégie de groupe pour Windows et Windows

paramètres Server à partir du Centre de téléchargement Microsoft

Ressources de la Protection de votre identité numérique

communauté
Connexion à Windows 8 avec un identifiant Windows Live

Connexion avec un mot de passe image

Optimisation de la sécurité des mots de passe d’image

Vue d’ensemble technique des mots de
passe
Article • 17/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows 10, Windows Server 2012 R2, Windows 8.1, Windows Server 2012,
Windows 8, Windows 7, Windows Server 2003, Windows Server 2008,
Windows Server 2008 R2 et Windows Vista

Cette rubrique destinée aux professionnels de l’informatique explique comment

Windows implémente les mots de passe dans les versions de Windows à partir de
Windows Server 2012 et Windows 8.1. Il aborde aussi les mots de passe forts, les
phrases secrètes et les stratégies de mot de passe.

Comment les mots de passe sont stockés dans

Windows
Cet article fournit des informations sur le stockage des mots de passe « au repos ».

Windows représente les mots de passe sous la forme de chaînes UNICODE de

256 caractères, mais la boîte de dialogue d’ouverture de session est limitée à
127 caractères. Par conséquent, le mot de passe le plus long possible comporte
127 caractères. Des programmes comme les services peuvent utiliser des mots de passe
plus longs, mais ils doivent être définis par programme.

Le système d’exploitation Windows stocke les mots de passe de différentes façons à des
fins différentes.

Mots de passe stockés en tant qu’OWF

Pour une utilisation en gestion de réseau Windows, y compris dans les domaines
Active Directory, le mot de passe est stocké de deux manières différentes par défaut : en
tant que fonction unidirectionnelle de LAN Manager (OWF LM) et en tant qu’OWF NT.
Le terme « Fonction unidirectionnelle » désigne une transformation mathématique
unidirectionnelle des données. Les données qui sont transformées peuvent être
converties par chiffrement de façon unidirectionnelle uniquement et cette
transformation ne peut pas être inversée. Le type le plus courant de fonction
unidirectionnelle est le hachage de chiffrement. Un hachage est un petit jeu de données
qui est mathématiquement lié à un jeu de données plus volumineux à partir duquel le
hachage est calculé. Si le plus grand jeu de données est modifié, le hachage change
également. Les hachages sont utiles, par exemple, en tant que somme de contrôle pour
vérifier que les données n’ont pas été modifiées lors de la transmission. Un hachage de
chiffrement est un hachage qui présente certaines propriétés. Un hachage de
chiffrement doit, par exemple, être créé de telle sorte qu’il soit mathématiquement
impossible de déduire le plus grand jeu de données à partir du hachage uniquement. De
même, il est mathématiquement impossible de trouver deux jeux de données
volumineux qui génèrent le même hachage.

Il existe de nombreux types de fonctions unidirectionnelles. Toutes les fonctions de

hachage sont, par définition, des fonctions unidirectionnelles. Toutefois, des fonctions
de chiffrement ordinaires qui sont généralement réversibles peuvent également être
utilisées pour créer une fonction unidirectionnelle. Pour ce faire, vous pouvez échanger
les données et la clé dans une fonction de chiffrement et chiffrer la valeur fixe (la clé) en
utilisant les données comme clé. C’est ainsi que le hachage LM est calculé. Le hachage
LM est calculé comme suit :

1. Le mot de passe est rempli d’octets NULL à exactement 14 caractères. Si le mot de

passe comporte plus de 14 caractères, il est remplacé par 14 octets NULL pour les
opérations restantes.
2. Le mot de passe est converti en majuscules.
3. Le mot de passe est divisé en deux clés de 7 octets (56 bits).
4. Chaque clé est utilisée pour chiffrer une chaîne fixe.
5. Les deux résultats de l’étape 4 sont concaténés et stockés en tant que hachage LM.

L’algorithme OWF LM est inclus dans Windows à des fins de compatibilité descendante
avec les logiciels et le matériel qui ne peuvent pas utiliser d’algorithmes plus récents.

Le hachage NT est simplement un hachage. Le mot de passe est haché à l’aide de

l’algorithme MD4, puis stocké. L’OWF NT est utilisé pour l’authentification par les
membres de domaine dans les domaines Windows NT 4.0 et versions antérieures et
dans les domaines Active Directory.

Ni le hachage NT ni le hachage LM ne sont salés. Le salage est un processus qui

combine le mot de passe à une valeur numérique aléatoire (le sel) avant de calculer la
fonction unidirectionnelle.

Mots de passe stockés dans Active Directory

Les mots de passe au repos sont stockés dans plusieurs attributs de la base de données
Active Directory (fichier [Link]). Ces attributs sont répertoriés dans le tableau
suivant :

Attribut Active Directory Contenu

unicodePwd Hachage NT chiffré

dbcsPwd Hachage LM chiffré

ntPwdHistory Hachages NT chiffrés : historique des mots de passe

lmPwdHistory Hachages LM chiffrés : historique des mots de passe

supplementalCredentials Clés Kerberos, WDigest, etc.

７ Notes

Le stockage des hachages LM est désactivé par défaut depuis Windows Vista et
Windows Server 2008.

Lorsqu’il est stocké dans le fichier DIT, le hachage NT est protégé par deux couches de
chiffrement. Sous Windows Server 2016/Windows 10 et versions ultérieures, il est
d’abord chiffré avec DES pour la compatibilité descendante, puis avec CNG BCrypt AES-
256 (voir CNGBCRYPT_AES_ALGORITHM). Les versions précédentes de Windows
chiffrent les hachages NT à l’aide de deux couches de chiffrement DES + RC4.

Pour plus d’informations sur les informations d’identification supplémentaires, consultez

MS-SAMR : supplementalCredentials et Structures d’informations d’identification
supplémentaires.

Mots de passe stockés dans la base de données SAM

locale
Sur les membres de domaine et les stations de travail, les hachages de mot de passe de
compte des utilisateurs locaux sont stockés dans une base de données SAM (Security
Account Manager) locale située dans le registre. Ils sont chiffrés à l’aide des mêmes
algorithmes de chiffrement et de hachage qu’Active Directory. Les mots de passe dans
l’attribut supplementalCredentials pour les comptes d’utilisateur locaux sont également
stockés dans la base de données SAM locale depuis Windows Server 2016.

Informations d’identification mises en cache

Windows stocke également un vérificateur de mot de passe sur les membres de
domaine lorsqu’un utilisateur de domaine se connecte à ce membre de domaine. Ce
vérificateur peut être utilisé pour authentifier un utilisateur de domaine si l’ordinateur
n’est pas en mesure d’accéder au contrôleur de domaine. Le vérificateur de mot de
passe est également communément appelé informations d’identification mises en
cache. Il est calculé en concaténant le hachage NT et le nom d’utilisateur, puis en
hachant le résultat à l’aide de la fonction de hachage MD4.

Fonctionnement des mots de passe sous

Windows
Sous Windows et de nombreux autres systèmes d’exploitation, une méthode
d’authentification de l’identité d’un utilisateur consiste à utiliser une phrase secrète ou
un mot de passe.

Nous vous recommandons d’utiliser l’authentification multifacteur sécurisée, telle

qu’une carte à puce, FIDO et Windows Hello Entreprise. Toutefois, l’authentification par
mot de passe est toujours requise dans certains scénarios.

La sécurisation de votre environnement réseau nécessite que des mots de passe forts
soient utilisés par tous les utilisateurs. Cela permet d’éviter qu’un utilisateur malveillant
devine un mot de passe faible, que ce soit de façon manuelle ou à l’aide d’outils, afin
d’acquérir les informations d’identification d’un compte d’utilisateur compromis. Cela
est particulièrement vrai pour les comptes d’administrateur. Lorsque vous modifiez
régulièrement un mot de passe complexe, cela réduit la probabilité de réussite d’une
attaque par mot de passe.

Les paramètres de stratégie de mot de passe contrôlent la complexité et la durée de vie

des mots de passe. Les stratégies de mot de passe affectent les mots de passe Windows,
mais pas nécessairement les mots de passe de fonctionnalités.

La capacité qu’ont les utilisateurs de modifier leurs mots de passe est régie par les
stratégies de mot de passe et les interfaces disponibles. Par exemple, via le bureau
sécurisé, les utilisateurs peuvent modifier leur mot de passe à tout moment en fonction
des stratégies de mot de passe gérées par l’administrateur système ou l’administrateur
de domaine. Les fonctionnalités telles que le coffre Windows, BitLocker et le système de
fichiers EFS permettent aux utilisateurs de modifier les mots de passe propres à ces
fonctionnalités.

Comment les mots de passe sont utilisés sous

Windows
Lorsqu’un utilisateur se connecte, le mot de passe qu’il tape est converti dans les
deux types de fonctions unidirectionnelles et conservé en mémoire par le processus
LSASS (Local Security Authority Subsystem Service). Si l’utilisateur s’authentifie au
moyen d’un compte local, l’OWF NT est comparé au hachage NT stocké localement, et si
les deux correspondent, l’utilisateur est connecté. Si l’utilisateur s’authentifie auprès d’un
domaine Active Directory à l’aide d’un nom d’hôte pour accéder à une ressource, le
hachage NT est utilisé dans une ouverture de session Kerberos auprès du centre de
distribution de clés (KDC), qui est généralement le contrôleur de domaine.

Kerberos ne peut pas être utilisé dans les situations suivantes :

Authentification auprès d’un domaine exécutant uniquement Windows NT 4.0 ou

version antérieure
Accès à une ressource sur un membre de domaine Active Directory à l’aide d’une
adresse IP au lieu d’un nom d’hôte
Accès à une ressource sur un ordinateur qui n’est pas membre d’un domaine
Active Directory
Accès à une ressource sur un ordinateur membre d’un domaine Active Directory,
mais non approuvé par votre domaine
Accès à une ressource sur un ordinateur en cours d’exécution et qui ne prend pas
en charge Kerberos

Dans ces situations, le processus d’authentification utilise deux protocoles différents,

appelés LAN Manager et NTLM. Le processus commence par le client qui demande une
vérification auprès du serveur d’authentification. Une fois la vérification reçue, le client
calcule une réponse à celle-ci. Pour ce faire, les deux hachages du mot de passe sont
remplis avec des valeurs Null à 168 bits. Les 168 bits de chaque hachage sont ensuite
divisés en trois clés DES 56 bits. Les six clés DES sont ensuite utilisées pour chiffrer la
vérification. Les trois textes de chiffrement générés à l’aide du hachage LM sont
concaténés et deviennent la réponse de LAN Manager. Les trois textes de chiffrement
générés à l’aide du hachage NT sont concaténés et deviennent la réponse de NTLM.

Les fonctions utilisées pour calculer la réponse peuvent être modifiées par le paramètre
Niveau de compatibilité LM dans le paramètre de stratégie de groupe Sécurité réseau :
niveau d’authentification LAN Manager . Si cette valeur est définie sur 1 ou moins, le
client envoie les réponses LAN Manager et NTLM d’origine. Si elle est définie sur 2, seule
la réponse NTLM est envoyée. Si elle est définie sur 3 ou plus, une nouvelle version des
deux protocoles est utilisée. La version de NTLM est appelée NTLMv2. La version de LAN
Manager est souvent appelée LMv2. Les deux protocoles utilisent le hachage NT pour
calculer la réponse, et tous deux utilisent une vérification côté client, au lieu ou en plus
de la vérification du serveur. Par ailleurs, si le paramètre Niveau de compatibilité LM est
défini sur 1 ou plus, la réponse NTLM est horodatée pour empêcher les attaques par
relecture. Pour plus d’informations sur le paramètre Niveau de compatibilité LM,
consultez Sécurité réseau : niveau d’authentification LAN Manager.

Mots de passe forts

Les mots de passe constituent la première ligne de défense contre les accès non
autorisés à votre organisation. À compter de Windows Server 2003, Windows vérifie la
complexité du mot de passe du compte Administrateur lors de l’installation du système
d’exploitation. Si le mot de passe est vide ou ne répond pas aux exigences de
complexité, la boîte de dialogue Installation de Windows vous invite à créer un mot de
passe fort pour le compte Administrateur. Si vous laissez ce mot de passe vide, vous ne
pourrez pas accéder à ce compte sur le réseau.

Les mots de passe faibles fournissent aux attaquants un accès facile à vos ordinateurs et
à votre réseau, tandis que les mots de passe forts sont beaucoup plus difficiles à
déchiffrer. Le tableau suivant compare les mots de passe faibles et forts.

Mot de passe faible Mot de passe fort

Vide Est composé d’au moins

sept caractères

Contient des informations facilement détectables ou connues, Contient des informations

telles que le nom d’utilisateur ou le nom de domaine « secrètes » ou aléatoires

Est similaire aux mots de passe précédents Est sensiblement différent des
mots de passe précédents

Contient un mot complet du dictionnaire Contient une combinaison des

caractères suivants :

- Lettres majuscules

- Lettres minuscules

- Chiffres

- Symboles, y compris des

espaces

J*p2leO4>F est un exemple de mot de passe fort.

Un mot de passe peut répondre à la plupart des critères d’un mot de passe fort, mais
rester quand même relativement faible. Par exemple, Hello2U! est un mot de passe
relativement faible même s’il répond à la plupart des critères d’un mot de passe fort et
répond également aux exigences de complexité de la stratégie de mot de passe.
H!elZl2o est un mot de passe fort, car le mot de dictionnaire est entrecoupé de
symboles, de chiffres et d’autres lettres. Il est important d’éduquer les utilisateurs au
sujet des avantages de l’utilisation de mots de passe forts et de leur apprendre à créer
des mots de passe qui sont réellement forts.

Vous pouvez créer des mots de passe qui contiennent des caractères du jeu de
caractères ANSI étendu. L’utilisation de caractères ANSI étendus augmente le nombre
de caractères que vous pouvez choisir lorsque vous créez un mot de passe. Par
conséquent, les logiciels de déchiffrage de mot de passe peuvent avoir besoin de plus
de temps pour déchiffrer les mots de passe qui contiennent ces caractères ANSI étendus
que pour déchiffrer d’autres mots de passe. Avant d’utiliser des caractères ANSI étendus
dans votre mot de passe, testez-les soigneusement pour vous assurer que les mots de
passe contenant des caractères ANSI étendus sont compatibles avec les applications
que votre organisation utilise. Soyez particulièrement prudent lors de l’utilisation de
caractères ANSI étendus dans les mots de passe si votre organisation utilise plusieurs
systèmes d’exploitation différents. Par exemple, ces systèmes peuvent être normalisés
selon la norme ISO-8859-15. L’implémentation réelle de protocoles sous Windows
utilise souvent l’encodage UNICODE ou UTF8 plutôt que l’encodage ANSI réel.

Exemples de mots de passe qui contiennent des caractères du jeu de caractères ANSI
étendu : kUμ!¶0o et Wf©$0k#»g≤5ªrd.

Phrases secrètes sous Windows

Une phrase secrète est une forme différente de mot de passe basé sur des jetons, dans
laquelle les jetons sont des mots plutôt que des symboles d’un jeu de caractères. Par
exemple, une phrase secrète peut contenir des caractères spéciaux, des chiffres, des
lettres majuscules et des lettres minuscules. Les principales différences entre les phrases
secrètes et les mots de passe sont les suivantes :

Une phrase secrète a généralement des espaces, contrairement aux mots de passe.
Une phrase secrète est beaucoup plus longue que la grande majorité des mots de
passe et, plus important, plus longue que n’importe quelle chaîne aléatoire de
lettres qu’une personne ordinaire pourrait mémoriser.

Les phrases secrètes qui respectent la limite de caractères définie dans la stratégie sont
généralement plus difficiles à déchiffrer que les mots de passe, car elles contiennent
plus de caractères. Les hachages LM et NT stockent le mot de passe ou la phrase
secrète, et le hachage LM est le plus faible des deux.

Il existe plusieurs façons de s’assurer que le hachage LM n’est pas stocké ; l’une d’elles
consiste à utiliser des mots de passe ou des phrases secrètes de plus de 14 caractères.
Vous pouvez également utiliser le paramètre de stratégie de groupe Sécurité réseau :
ne pas stocker de valeurs de hachage de niveau LAN Manager sur la prochaine
modification de mot de passe. L’utilisation de ce paramètre de stratégie désactive
globalement les hachages LM de stockage pour tous les comptes. La modification
prendra effet à la prochaine modification du mot de passe. Étant donné que l’effet de la
stratégie n’est pas immédiat, vous ne remarquerez pas immédiatement de problèmes
d’interopérabilité potentiels causés par le non-stockage des hachages LM.

Stratégies de mot de passe locales disponibles

sous Windows
Vous pouvez implémenter un paramètre de stratégie de mot de passe qui impose les
exigences de complexité des mots de passe. Pour plus d’informations sur ce paramètre
de stratégie, consultez Le mot de passe doit respecter des exigences de complexité.
Pour plus d’informations sur l’application d’une stratégie de mot de passe, consultez
Appliquer ou modifier une stratégie de mot de passe . Pour plus d’informations sur
tous les paramètres de stratégie de mot de passe disponibles, consultez Stratégie de
mot de passe.

Stratégie de mot de passe affinée disponible

via Active Directory Domain Services (AD DS)
À partir de Windows Server 2008, vous pouvez utiliser des stratégies de mot de passe
affinées pour spécifier plusieurs stratégies de mot de passe et pour appliquer des
stratégies différentes de restrictions de mot de passe et de verrouillage de compte à des
ensembles d’utilisateurs différents au sein d’un seul domaine. Par exemple, pour
renforcer la sécurité des comptes disposant de privilèges, vous pouvez appliquer des
paramètres plus stricts à ces comptes et des paramètres moins stricts aux comptes
d’autres utilisateurs. Ou, dans certains cas, vous pouvez appliquer une stratégie de mot
de passe spéciale pour les comptes dont les mots de passe sont synchronisés avec
d’autres sources de données.

Pour stocker des stratégies de mot de passe affinées, deux nouvelles classes d’objets
existent dans le schéma AD DS :

Conteneur de paramètres de mot de passe

Paramètres de mot de passe

Pour plus d’informations sur ces stratégies, consultez AD DS : Stratégies de mot de

passe affinées.
Vue d’ensemble technique des utilitaires
de clé système
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows 8.1, Windows
Server 2012, Windows Server 2012 R2

Cette rubrique destinée aux professionnels de l’informatique décrit l’utilitaire de clé

système (Syskey), qui protège la base de données du Gestionnaire des comptes de
sécurité (SAM) dans les systèmes d’exploitation Windows.

７ Notes

L’utilitaire Syskey n’est plus pris en charge dans Windows 10, version 1607, ni
Windows Server 2016 et les versions ultérieures.

Qu’est-ce que l’utilitaire de clé système ?

Les informations relatives aux mots de passe des comptes d’utilisateur sont stockées
dans la base de données SAM du Registre sur les stations de travail et les serveurs
membres. Sur les contrôleurs de domaine, les informations relatives aux mots de passe
sont stockées dans les services d’annuaire. Il n’est pas rare que les logiciels de craquage
de mot de passe ciblent la base de données SAM ou les services d’annuaire pour
accéder aux mots de passe des comptes d’utilisateur. L’utilitaire de clé système (Syskey)
fournit une ligne de défense supplémentaire contre les logiciels de craquage de mot de
passe. Il utilise des techniques de chiffrement renforcé pour sécuriser les informations
relatives aux mots de passe des comptes, stockées dans la base de données SAM ou
dans les services d’annuaire. Le craquage des mots de passe de compte chiffrés est plus
difficile et prend plus de temps que le craquage des mots de passe de compte non
chiffrés.

Il existe trois options de clé système dans la boîte de dialogue Clé de démarrage,
conçues pour répondre aux besoins de différents environnements, comme indiqué dans
le tableau suivant.
 Option de clé Niveau Description
système de
sécurité
relatif

Mot de passe + Utilise une clé aléatoire générée par l’ordinateur en tant que clé
généré par le système, et stocke une version chiffrée de la clé sur l’ordinateur
système, local. Cette option fournit un chiffrement renforcé des informations
stocker la clé de relatives aux mots de passe dans le Registre. Elle permet à
démarrage l’utilisateur de redémarrer l’ordinateur sans qu’un administrateur ait
localement besoin d’entrer un mot de passe ou d’insérer un disque

Mot de passe ++ Utilise une clé aléatoire générée par l’ordinateur en tant que clé
généré par système, et stocke une version chiffrée de la clé sur l’ordinateur
l’administrateur, local. La clé est également protégée par un mot de passe choisi par
démarrage par l’administrateur. Les utilisateurs sont invités à entrer le mot de passe
mot de passe de la clé système quand l’ordinateur se trouve dans la séquence de
démarrage initiale. Le mot de passe de la clé système n’est stocké
nulle part sur l’ordinateur.

Mot de passe +++ Utilise une clé aléatoire générée par l’ordinateur, et stocke la clé sur
généré par le une disquette. La disquette qui contient la clé système est
système, nécessaire au démarrage du système. Elle doit être insérée à une
stocker la clé de invite au cours de la séquence de démarrage. La clé système n’est
démarrage sur stockée nulle part sur l’ordinateur.
une disquette

L’utilisation de l’utilitaire de clé système est facultative. Si vous perdez le disque qui
contient la clé système, ou si vous oubliez le mot de passe, vous ne pouvez pas
démarrer l’ordinateur sans restaurer le Registre à l’état dans lequel il se trouvait avant
l’utilisation de la clé système.

Fonctionnement de l’utilitaire de clé système

Chaque fois qu’un nouvel utilisateur est ajouté à un ordinateur, l’API de protection des
données (DPAPI) Windows génère une clé principale qui sert à protéger toutes les autres
clés privées utilisées par les applications et services s’exécutant dans le contexte de cet
utilisateur, par exemple les clés EFS (système de fichiers EFS) et les clés S/MIME.
L’ordinateur dispose également de sa propre clé principale, qui protège les clés système
telles que les clés IPsec, les clés d’ordinateur et les clés SSL. Toutes ces clés principales
sont ensuite protégées par la clé de démarrage d’un ordinateur. Quand vous démarrez
un ordinateur, la clé de démarrage déchiffre les clés principales. La clé de démarrage
protège également la base de données SAM locale sur chaque ordinateur, les secrets
LSA (autorité de sécurité locale) de l’ordinateur, les informations de compte stockées
dans Active Directory Domain Services (AD DS) sur les contrôleurs de domaine ainsi que
le mot de passe du compte Administrateur utilisé pour la récupération du système en
mode sans échec.

L’utilitaire Syskey vous permet de choisir l’emplacement de stockage de la clé de

démarrage. Par défaut, l’ordinateur génère une clé aléatoire et la disperse dans le
Registre. Un algorithme d’obfuscation complexe vérifie que le modèle de dispersion est
différent sur chaque installation de Windows. Vous pouvez remplacer ce mode par l’un
des deux autres modes de Syskey : vous pouvez continuer à utiliser une clé générée par
l’ordinateur tout en la stockant sur une disquette, ou vous pouvez obliger le système à
demander au démarrage le mot de passe utilisé pour dériver la clé principale. Vous
pouvez toujours changer entre les trois options. Toutefois, si vous avez activé Mot de
passe généré par le système, stocker la clé de démarrage sur une disquette ou Mot de
passe généré par l’administrateur, démarrage par mot de passe, et si vous avez perdu
votre disquette ou oublié votre mot de passe, votre seule option de récupération
consiste à utiliser un disque de réparation pour restaurer le Registre à l’état dans lequel
il se trouvait avant l’activation du mode Syskey. Vous perdrez tous les autres
changements apportés entre-temps. Pour changer votre clé de démarrage, ouvrez une
invite de commandes, puis tapez syskey afin d’exécuter l’utilitaire Syskey.
Restriction de l’interface RPC
Article • 16/05/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows 11, Windows 10

Le service d’appel de procédure distante (RPC) sécurise les interfaces RPC par défaut
pour réduire les attaques. La clé de Registre RestrictRemoteClients vous permet de
modifier le comportement de toutes les interfaces RPC sur le système et peut être
utilisée pour éliminer l’accès anonyme à distance aux interfaces RPC sur le système, à
quelques exceptions près. Vous pouvez appliquer d’autres contrôles d’interface en
utilisant la clé de Registre EnableAuthEpResolution décrite dans cet article. Les
restrictions d’interface RPC peuvent être configurées à la fois par les développeurs
d’applications RPC et les administrateurs système.

Prérequis
Quand vous utilisez RestrictRemoteClients sur votre serveur :

Vos clients RPC doivent utiliser la sécurité RPC quand ils contactent vos
applications serveur. C’est la meilleure méthode pour atténuer les menaces de
sécurité.

Exemptez votre paramètre RPC d’exiger une authentification en définissant

l’indicateur RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH pendant l’inscription. Cela
configure RPC pour autoriser les connexions anonymes à vos applications.

Atténuation des menaces avec RestrictionRemoteClients

L’activation de RestrictRemoteClients est utile pour l’atténuation des menaces des vers
qui utilisent les dépassements de mémoire tampon exploitables pouvant être appelés à
distance sur des connexions anonymes. Les applications RPC qui attendent des appels
de clients RPC anonymes distants peuvent ne pas s’exécuter correctement quand vous
utilisez cette fonctionnalité. Par conséquent, les applications qui utilisent DCOM
(Distributed Component Object Model) peuvent ne pas fonctionner correctement si
cette valeur est définie.

Les appels RPC sur des protocoles non connectés échouent si cette clé est activée. Les
appels RPC sécurisés sur des protocoles non connectés comme UDP (User Datagram
Protocol) et IPX (Internetwork Packet Exchange), ncadq_ip_udp et ncadg_ipx
respectivement, utilisent un niveau de sécurité inférieur à celui des appels sur des
protocoles orientés connexion où ces appels sont toujours considérés comme non
sécurisés dans le but de cette stratégie.

Pour autoriser les appels de clients RPC qui utilisent des protocoles non connectés,
gardez la valeur RestrictRemoteClients définie sur désactivé.

Restrictions pour les clients RPC

Quand une interface est inscrite avec RpcServerRegisterIf , RPC permet à l’application
serveur de restreindre l’accès à l’interface en utilisant un rappel de sécurité. La clé de
Registre RestrictRemoteClients force RPC à effectuer des vérifications de sécurité
supplémentaires pour toutes les interfaces, même si l’interface n’a aucun rappel de
sécurité inscrit.

Les clients RPC qui utilisent la séquence de protocole de canal nommé ( ncacn_np ) sont
exemptés de toutes les restrictions décrites dans cette section. La séquence de
protocole de canal nommé ne peut pas être restreinte en raison de problèmes de
compatibilité descendante importants.

RestrictRemoteClients peut également être contrôlé programmatiquement dans l’en-

tête d’API (interface de programmation d’application) rpcdce.h.

Configuration de RestrictRemoteClients
Pour modifier ces stratégies dans l’éditeur GPO (objet stratégie de groupe) :

1. Cliquez sur Démarrer>, tapez [Link]> appuyez sur Entrée pour ouvrir
l’éditeur de stratégie de groupe local.

2. Pour activer l’équivalent des paramètres RestrictRemoteClients , accédez à

Configuration ordinateur\Modèles d’administration\Système\Appel de
procédure distante\Restrictions pour les clients à distance RPC non authentifiés,
puis sélectionnez l’une des options suivantes :

Désactivé : ce paramètre est la valeur par défaut pour les références SKU de
serveur. Il correspond à la valeur RPC_RESTRICT_REMOTE_CLIENT_NONE dans
rpcdce.h, et c’est à l’application serveur d’imposer les restrictions RPC
appropriées.
Authentifié : correspond à la valeur RPC_RESTRICT_REMOTE_CLIENT_DEFAULT
dans rpcdce.h. Autorise seulement les clients RPC authentifiés à se connecter
 aux serveurs RPC s’exécutant sur la machine où le paramètre de stratégie est
appliqué. Les appels anonymes sont rejetés par le runtime RPC. Si une
interface inscrit un rappel de sécurité et fournit l’indicateur
RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH, cette restriction ne s’applique
pas à cette interface.
Authentifié sans exception1 : correspond à la valeur
RPC_RESTRICT_REMOTE_CLIENT_HIGH dans rpcdce.h. Autorise seulement les
clients RPC authentifiés à se connecter aux serveurs RPC s’exécutant sur la
machine où le paramètre de stratégie est appliqué. Aucune exception n’est
autorisée quand cette valeur est définie, car le système ne peut pas recevoir
d’appels anonymes distants en utilisant RPC.

Tout changement de ces paramètres nécessite un redémarrage système pour prendre

effet.

Ｕ Attention

¹ N’utilisez pas cette valeur sans tests significatifs. Pour plus d’informations,
consultez Restrictions pour les clients à distance RPC non authentifiés .

EnableAuthEpResolution
La clé EnableAuthEpResolution permet au runtime du client RPC d’utiliser NTLM (NT LAN
Manager) pour s’authentifier sur le mappeur de point de terminaison s’il est activé. Cette
requête authentifiée a lieu seulement si l’appel du client RPC réel utilise
l’authentification RPC.

Les clients RPC effectuent des appels à un serveur RPC qui a un point de terminaison
dynamique inscrit avec l’authentification du client Mappeur de point de terminaison RPC
activée, appels qui sont interrogés pour le compte d’appels authentifiés avec
l’authentification NTLM.

Les clients RPC qui tentent d’effectuer un appel en utilisant un point de terminaison
dynamique interrogent d’abord le mappeur de point de terminaison RPC sur le serveur
pour déterminer le point de terminaison auquel ils doivent se connecter. Cette requête
est effectuée de manière anonyme, même si l’appel du client RPC lui-même est effectué
avec la sécurité RPC. L’interface du mappeur de point de terminaison RPC n’est pas
accessible de manière anonyme si le paramètre RestrictRemoteClients est activé.

Configuration d’EnableAuthEpResolution
Pour modifier ces stratégies dans l’éditeur GPO (objet stratégie de groupe) :

1. Cliquez sur Démarrer>, tapez [Link]> appuyez sur Entrée pour ouvrir
l’éditeur de stratégie de groupe local.

2. Pour activer l’équivalent des paramètres EnableAuthEpResolution , accédez à

Configuration ordinateur\Modèles d’administration\Système\Appel de
procédure distante\Activer l’authentification du client Mappeur de point de
terminaison RPC, puis sélectionnez l’un des deux paramètres disponibles :

Désactivé : c’est le paramètre par défaut. Les clients RPC ne s’authentifient

pas sur le service Mappeur de point de terminaison, mais peuvent
communiquer avec le service Mappeur de point de terminaison sur un
serveur Windows NT4.
Activé : les clients RPC s’authentifient via le service Mappeur de point de
terminaison pour les appels qui contiennent des informations
d’authentification. Les clients effectuant ces appels ne peuvent pas
communiquer avec le service Mappeur de point de terminaison du serveur
Windows NT4.

Tout changement de ces paramètres nécessite un redémarrage système pour prendre

effet.

） Important

Les paramètres de stratégie de groupe suivants trouvés dans Configuration

ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies
locales\Options de sécurité ne peuvent pas être utilisés avec
EnableAuthEpResolution :

Sécurité réseau : Restreindre NTLM : Trafic NTLM entrant, « Refuser tous les
comptes »
Sécurité réseau : Restreindre NTLM : Trafic NTLM sortant vers des serveurs
distants, « Tout refuser »

Nous vous recommandons de ne pas utiliser NTLM pour mieux sécuriser votre
environnement. Si vous devez choisir entre restreindre NTLM et utiliser
EnableAuthEpResolution , l’approche recommandée est de restreindre NTLM dans

votre environnement.

Autres indicateurs d’inscription d’interface RPC

Ces indicateurs d’inscription d’interface ont été créés pour permettre aux développeurs
d’applications de sécuriser plus facilement une interface RPC :

RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH
Quand cet indicateur est inscrit, le runtime RPC appelle le rappel de sécurité inscrit
pour tous les appels, quels que soient les paramètres de sécurité des appels. Sans
cet indicateur, RPC rejette tous les appels non authentifiés avant qu’ils n’atteignent
le rappel de sécurité. Cet indicateur fonctionne uniquement quand un rappel de
sécurité est inscrit.

RPC_IF_SEC_NO_CACHE
Un rappel de sécurité est inscrit pour une interface afin de restreindre l’accès à
cette interface. Le rappel de sécurité classique emprunte l’identité du client pour
déterminer s’il a des droits suffisants pour effectuer un appel à l’interface. Si une
identité de client particulière passe un rappel de sécurité une fois, elle passe
généralement le même rappel de sécurité chaque fois.
Le runtime RPC tire parti de ce modèle en mémorisant quand une identité de
client individuelle passe un rappel de sécurité et ignore le rappel de sécurité
pour les appels ultérieurs de ce client à la même interface. Cette fonctionnalité
est appelée mise en cache des rappels de sécurité et existe depuis la famille de
systèmes d’exploitation Microsoft Windows 2000. Vous pouvez utiliser
l’indicateur RPC_IF_SEC_NO_CACHE pour désactiver la mise en cache des
rappels de sécurité pour une interface donnée. Cela est utile si la vérification de
sécurité est susceptible de changer, rejetant éventuellement une identité de
client qui était précédemment autorisée.

RPC_IF_LOCAL_ONLY
Quand une interface est inscrite avec cet indicateur, RPC rejette les appels
effectués par les clients RPC distants. Par ailleurs, les appels locaux sur toutes les
séquences de protocole ncadg_ * et toutes les séquences de protocole ncacn_ * (à
l’exception des canaux nommés, avec ncacn_np ) sont également rejetés. Si un
appel est effectué sur ncacn_np , RPC l’autorise uniquement s’il ne provient pas de
SRV (Service Location Protocol), qui filtre tous les appels distants. Les appels
Ncalrpc sont toujours autorisés.

L’utilisation de ces indicateurs est à la discrétion du développeur d’applications. Les

développeurs d’applications RPC bénéficient d’outils de sécurité supplémentaires pour
sécuriser leur interface RPC, car ces indicateurs ne changent pas les applications
existantes ni ne perturbent leur exécution.

Références supplémentaires
Appel de procédure distante (RPC)
Résolution des erreurs RPC
Vue d’ensemble de TLS/SSL (SSP
Schannel)
Article • 23/01/2024

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows 11, Windows 10

Cet article a pour objet de présenter aux professionnels de l’informatique

l’implémentation de TLS et SSL dans Windows à l’aide du fournisseur de service de
sécurité (SSP) Schannel en décrivant des cas pratiques, des modifications dans
l’implémentation Microsoft et la configuration logicielle requise, ainsi que des
ressources supplémentaires pour Windows Server et les appareils clients.

Description
Schannel est un fournisseur de service de sécurité qui implémente les protocoles
d’authentification standard Internet SSL (Secure Sockets Layer) et TLS (Transport Layer
Security).

L’interface SSPI (Security Support Provider Interface) est une API utilisée par les
systèmes Windows pour exécuter des fonctions relatives à la sécurité, dont notamment
l’authentification. L’interface SSPI fonctionne comme une interface commune SSP, y
compris le fournisseur SSP Schannel.

La suite de protocoles d’authentification Schannel fournit plusieurs protocoles qui

utilisent tous un modèle client/serveur. Les protocoles suivants s’appuient sur la
cryptographie à clé publique :

Versions TLS 1.0, 1.1, 1.2 et 1.3

Versions SSL 2.0 et 3.0
Protocole DTLS (Datagram Transport Layer Security) versions 1.0 et 1.2
Protocole PCT (Private Communications Transport)

７ Notes

TLS 1.0 et TLS 1.1 sont dépréciés dans Windows à compter de la build Insider
Preview du 11 septembre de Windows et ses versions ultérieures. Pour plus
d’informations, consultez Dépréciation de TLS 1.0 et TLS 1.1 dans Windows.
Applications
Un problème lorsque vous administrez un réseau est la sécurisation des données
échangées entre les applications via un réseau non approuvé. Vous pouvez utiliser TLS
et SSL pour authentifier les serveurs et les ordinateurs clients, puis utiliser le protocole
pour crypter les messages entre les parties authentifiées.

Par exemple, vous pouvez utiliser TLS/SSL pour :

les transactions sécurisées par SSL avec un site Web de commerce électronique ;
l’accès des clients authentifiés à un site Web sécurisé par SSL ;
Accès à distance
l’accès SQL ;
Messagerie électronique

Configuration requise
Les protocoles TLS et SSL utilisent un modèle client/serveur et sont basés sur
l’authentification de certificat, laquelle requiert une infrastructure à clé publique.

Informations sur le Gestionnaire de serveur

Aucune procédure de configuration n’est requise pour implémenter TLS, SSL ou
Schannel.

Voir aussi
Le package de sécurité Schannel
Canal sécurisé
Protocole TLS

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Modifications du protocole TLS (SSP
Schannel) dans Windows 10 et Windows
Server 2016
Article • 09/03/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016 et
Windows 10

Modifications de la suite de chiffrement

Windows 10, version 1511 et Windows Server 2016 ajoutent la prise en charge de la
configuration de l’ordre de la suite de chiffrement à l’aide de la gestion des
périphériques mobiles (MDM).

Pour connaître les modifications de l’ordre de priorité de la suite de chiffrement,

consultez Suites de chiffrement dans Schannel.

Ajout de la prise en charge des suites de chiffrement suivantes :

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (RFC 5289) dans Windows 10,

version 1507 et Windows Server 2016
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (RFC 5289) dans Windows 10,
version 1507 et Windows Server 2016

Modification de DisabledByDefault pour les suites de chiffrement suivantes :

TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (RFC 5246) dans Windows 10,

version 1703
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (RFC 5246) dans Windows 10,
version 1703
TLS_DHE_DSS_WITH_AES_256_CBC_SHA (RFC 5246) dans Windows 10,
version 1703
TLS_DHE_DSS_WITH_AES_128_CBC_SHA (RFC 5246) dans Windows 10,
version 1703
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (RFC 5246) dans Windows 10,
version 1703
TLS_RSA_WITH_RC4_128_SHA dans Windows 10, version 1709
TLS_RSA_WITH_RC4_128_MD5 dans Windows 10, version 1709
À compter de Windows 10, version 1507 et Windows Server 2016, les certificats SHA 512
sont pris en charge par défaut.

Modifications de la clé RSA

Windows 10, version 1507 et Windows Server 2016 ajoutent des options de
configuration du Registre pour les tailles de clés RSA du client.

Pour plus d’informations, consultez Tailles de clé KeyExchangeAlgorithm.

Modifications des clés Diffie-Hellman

Windows 10, version 1507 et Windows Server 2016 ajoutent des options de
configuration du Registre pour les tailles de clés Diffie-Hellman.

Pour plus d’informations, consultez Tailles de clé KeyExchangeAlgorithm.

Modifications de l’option SCH_USE_STRONG_CRYPTO

Avec Windows 10, version 1507 et Windows Server 2016, l’option
SCH_USE_STRONG_CRYPTO désactive désormais NULL, MD5, DES et exporte les
chiffrements.

Changements liés aux courbes elliptiques

Windows 10, version 1507 et Windows Server 2016 ajoutent la configuration de
stratégie de groupe pour les courbes elliptiques dans les paramètres Configuration
ordinateur > Modèles d’administration > Réseau> Paramètres de configuration SSL. La
liste de l’ordre des courbes ECC spécifie l’ordre de préférence des courbes elliptiques et
active les courbes prises en charge qui ne sont pas activées.

Ajout de la prise en charge des courbes elliptiques suivantes :

BrainpoolP256r1 (RFC 7027) dans Windows 10, version 1507 et Windows

Server 2016
BrainpoolP384r1 (RFC 7027) dans Windows 10, version 1507 et Windows
Server 2016
BrainpoolP512r1 (RFC 7027) dans Windows 10, version 1507 et Windows
Server 2016
Curve25519 (RFC draft-ietf-tls-curve25519) dans Windows 10, version 1607 et
Windows Server 2016
Prise en charge au niveau de la distribution
pour SealMessage et UnsealMessage
Windows 10, version 1507 et Windows Server 2016 ajoutent la prise en charge de
SealMessage/UnsealMessage au niveau de la distribution.

DTLS 1.2
Windows 10, version 1607 et Windows Server 2016 ajoutent la prise en charge de
DTLS 1.2 (RFC 6347).

Pool de threads [Link]

Windows 10, version 1607 et Windows Server 2016 ajoutent une configuration du
Registre de la taille du pool de threads utilisé pour gérer les établissements de liaisons
TLS pour [Link].

Chemin d’accès au Registre :

HKLM\SYSTEM\CurrentControlSet\Control\LSA

Pour spécifier une taille maximale du pool de threads par cœur de processeur, créez une
entrée MaxAsyncWorkerThreadsPerCpu. Par défaut, cette entrée n’existe pas dans le
Registre. Une fois l’entrée créée, remplacez la valeur DWORD par la taille souhaitée. Si le
paramètre n’est pas configuré, la valeur maximum est 2 threads par cœur de processeur.

Prise en charge du protocole NPN (Next

Protocol Negotiation)
À compter de Windows 10 version 1703, le protocole NPN (Next Protocol Negotiation) a
été supprimé et n’est plus pris en charge.

Clé prépartagée (PSK)

Windows 10, version 1607 et Windows Server 2016 ajoutent la prise en charge de
l’algorithme d’échange de clés PSK (RFC 4279).

Ajout de la prise en charge des suites de chiffrement PSK suivantes :

 TLS_PSK_WITH_AES_128_CBC_SHA256 (RFC 5487) dans Windows 10, version 1607
et Windows Server 2016
TLS_PSK_WITH_AES_256_CBC_SHA384(RFC 5487) dans Windows 10, version 1607
et Windows Server 2016
TLS_PSK_WITH_NULL_SHA256 (RFC 5487) dans Windows 10, version 1607 et
Windows Server 2016
TLS_PSK_WITH_NULL_SHA384 (RFC 5487) dans Windows 10, version 1607 et
Windows Server 2016
TLS_PSK_WITH_AES_128_GCM_SHA256 (RFC 5487) dans Windows 10, version 1607
et Windows Server 2016
TLS_PSK_WITH_AES_256_GCM_SHA384 (RFC 5487) dans Windows 10, version 1607
et Windows Server 2016

Reprise de session sans amélioration des

performances côté serveur sans état côté
serveur
Windows 10, version 1507 et Windows Server 2016 fournissent 30 % de reprises de
session en plus par seconde avec des tickets de session par rapport à Windows
Server 2012.

Hachage de session et extension EMS

(Extended Master Secret)
Windows 10, version 1507 et Windows Server 2016 ajoutent la prise en charge de
RFC 7627 : hachage de session TLS (Transport Layer Security) et extension EMS
(Extended Master Secret)

En raison de cette modification, Windows 10 et Windows Server 2016 nécessitent des

mises à jour du fournisseur SSL CNG tiers pour prendre en charge
NCRYPT_SSL_INTERFACE_VERSION_3 et décrire cette nouvelle interface.

Prise en charge de SSL

À compter de Windows 10, version 1607 et Windows Server 2016, le protocole SSL 3.0
est désactivé par défaut pour le client TLS et le serveur. Cela signifie que, sauf si
l’application ou le service demande spécifiquement le protocole SSL 3.0 via
l’interface SSPI, le client ne propose jamais ni n’accepte le protocole SSL 3.0 et que le
serveur ne sélectionne jamais le protocole SSL 3.0.

À compter de Windows 10, version 1607 et Windows Server 2016, le protocole SSL 2.0 a
été supprimé et il n’est plus pris en charge.

Modifications apportées à la conformité de

Windows TLS concernant les exigences TLS 1.2
pour les connexions avec des clients TLS non
conformes
Avec le protocole TLS 1.2, le client utilise l’extension « signature_algorithms » pour
indiquer au serveur quelles paires d’algorithmes de signature/hachage peuvent être
utilisées dans les signatures numériques (c’est-à-dire les certificats de serveur et
d’échange de clés de serveur). Le document RFC TLS 1.2 exige également que le
message de certificat du serveur respecte l’extension « signature_algorithms » :

« Si le client a fourni une extension « signature_algorithms », tous les certificats fournis

par le serveur DOIVENT être signés par une paire d’algorithmes de hachage/signature
qui apparaît dans cette extension. »

Dans la pratique, certains clients TLS tiers ne sont pas conformes au document RFC
TLS 1.2. Ils ne parviennent pas à inclure toutes les paires d’algorithmes de
hachage/signature qu’ils sont prêts à accepter dans l’extension « signature_algorithms »
ou ils omettent complètement l’extension (dans ce cas, cela indique au serveur que le
client prend en charge uniquement SHA1 avec RSA, DSA ou ECDSA).

Souvent, un seul certificat est configuré par point de terminaison d’un serveur TLS, ce
qui signifie que le serveur ne peut pas toujours fournir un certificat conforme aux
exigences du client.

Avant Windows 10 et Windows Server 2016, la pile TLS Windows respectait strictement
les exigences du document RFC TLS 1.2, ce qui entraînait des échecs de connexion avec
les clients TLS non conformes au document RFC et des problèmes d’interopérabilité.
Dans Windows 10 et Windows Server 2016, les contraintes sont assouplies et le serveur
peut envoyer un certificat qui n’est pas conforme au document RFC TLS 1.2, s’il s’agit de
la seule option du serveur. Le client peut ensuite continuer ou mettre fin à
l’établissement d’une liaison.

Lors de la validation des certificats serveur et client, la pile TLS Windows est strictement
conforme au document RFC TLS 1.2 et autorise uniquement les algorithmes de signature
et de hachage négociés dans les certificats serveur et client.
Gérer TLS (Transport Layer Security)
Article • 15/06/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows 11, Windows 10

Configuration de l’ordre de la suite de

chiffrement du protocole TLS
Les suites de chiffrement TLS prises en charge et l’ordre de priorité varient selon les
versions de Windows. Consultez Suites de chiffrement dans TLS/SSL (SSP Schannel) pour
connaître l’ordre par défaut pris en charge par le fournisseur Microsoft Schannel dans
différentes versions de Windows.

７ Notes

Vous pouvez également modifier la liste des suites de chiffrement à l’aide de

fonctions CNG. Pour plus d’informations, consultez Priorisation des suites de
chiffrement Schannel.

Les modifications apportées à l’ordre de suite de chiffrement du protocole TLS prennent

effet au démarrage suivant. Jusqu’au redémarrage ou à l’arrêt, l’ordre existant sera en
vigueur.

２ Avertissement

La mise à jour des paramètres de Registre pour l’ordre de priorité par défaut n’est
pas prise en charge et peut être réinitialisée avec les mises à jour de maintenance.

Configuration de l’ordre des suites de chiffrement du

protocole TLS avec une stratégie de groupe
Vous pouvez utiliser les paramètres de la stratégie de groupe de l’ordre de suite de
chiffrement SSL pour configurer l’ordre de suite de chiffrement du protocole TLS par
défaut.

1. Dans la console de gestion de stratégie de groupe, accédez à Configuration de

l’ordinateur>Modèles d’administration>Réseau>Paramètres de la configuration
 SSL.

2. Double-cliquez sur Ordre de la suite de chiffrement SSL, puis cliquez sur l’option
Activé.

3. Cliquez avec le bouton droit sur la zone Suites de chiffrement SSL et sélectionnez
Sélectionner tout dans le menu contextuel.

4. Cliquez avec le bouton droit sur le texte sélectionné, puis sélectionnez Copier dans
le menu contextuel.

5. Collez le texte dans un éditeur de texte tel que [Link] et mettez à jour avec
la nouvelle liste de commandes de suite de chiffrement.

７ Notes

La liste de commandes de la suite de chiffrement TLS doit être au format strict

délimité par des virgules. Chaque chaîne de suite de chiffrement se termine
par une virgule (,) à droite de celle-ci.
 En outre, la liste des suites de chiffrement est limitée à 1 023 caractères.

6. Remplacez la liste dans les suites de chiffrement SSL par la liste ordonnée mise à
jour.

7. Cliquez sur OK ou Appliquer.

Configuration de l’ordre de suite de chiffrement du

protocole TLS à l’aide de MDM
Le fournisseur de solutions cloud de stratégie Windows 10 prend en charge la
configuration des suites de chiffrement TLS. Pour plus d’informations, consultez
Cryptography/TLSCipherSuites.

Configuration de l’ordre des suites de chiffrement TLS

avec les applets PowerShell TLS
Le module TLS PowerShell prend en charge l’obtention de la liste ordonnée des suites
de chiffrement TLS, la désactivation d’une suite de chiffrement et l’activation d’une suite
de chiffrement. Pour plus d’informations, consultez Module TLS.

Configuration de l’ordre des courbes TLS ECC

À compter de Windows 10 & Windows Server 2016, l’ordre de courbe ECC peut être
configuré indépendamment de l’ordre de la suite de chiffrement. Si la liste de
commandes de la suite de chiffrement TLS a des suffixes de courbe elliptique, elles
seront remplacées par le nouvel ordre de priorité de courbe elliptique, lorsque cette
option est activée. Cela permet aux organisations d’utiliser un objet de stratégie de
groupe pour configurer différentes versions de Windows avec le même ordre de suites
de chiffrement.

７ Notes

Avant Windows 10, les chaînes de suite de chiffrement ont été ajoutées avec la
courbe elliptique pour déterminer la priorité de la courbe.

Gestion des courbes Windows ECC à l’aide de CertUtil

À compter de Windows 10 et de Windows Server 2016, Windows fournit une gestion
des paramètres de courbe elliptique via l’utilitaire de ligne de commande [Link].
Les paramètres de courbe elliptique sont stockés dans le [Link]. À l’aide de
[Link], les administrateurs peuvent ajouter et supprimer des paramètres de courbe
à partir de Windows, respectivement. [Link] stocke les paramètres de courbe en
toute sécurité dans le Registre. Windows peut commencer à utiliser les paramètres de
courbe par le nom associé à la courbe.

Affichage des courbes inscrites

Utilisez la commande [Link] suivante pour afficher une liste de courbes inscrites
pour l’ordinateur actuel.

PowerShell

[Link] –displayEccCurve

Sortie Figure 1 [Link] pour afficher la liste des courbes inscrites.

Ajout d’une nouvelle courbe

Les organisations peuvent créer et utiliser des paramètres de courbe recherchés par
d’autres entités approuvées. Les administrateurs qui souhaitent utiliser ces nouvelles
courbes dans Windows doivent ajouter la courbe. Utilisez la commande [Link]
suivante pour ajouter une courbe à l’ordinateur actuel :

PowerShell
 Certutil —addEccCurue curveName curveParameters [curveOID] [curveType]

L’argument curveName représente le nom de la courbe sous laquelle les

paramètres de courbe ont été ajoutés.
L’argument curveParameters représente le nom de fichier d’un certificat qui
contient les paramètres des courbes à ajouter.
L’argument curveOid représente un nom de fichier d’un certificat qui contient
l’OID des paramètres de courbe que vous souhaitez ajouter (facultatif).
L’argument curveType représente une valeur décimale de la courbe nommée du
Registre de courbes nommées EC (facultatif).

Figure 2 Ajout d’une courbe à l’aide de [Link].

Suppression d’une courbe précédemment ajoutée

Les administrateurs peuvent supprimer une courbe précédemment ajoutée à l’aide de la

commande [Link] suivante :

PowerShell

[Link] –deleteEccCurve curveName

Windows ne peut pas utiliser une courbe nommée après qu’un administrateur supprime
la courbe de l’ordinateur.

Gestion des courbes Windows ECC à l’aide de la

stratégie de groupe
Les organisations peuvent distribuer des paramètres de courbe à l’entreprise, joint à un
domaine, à l’ordinateur à l’aide de la stratégie de groupe et de l’extension de Registre
des préférences de la stratégie de groupe. Le processus de distribution d’une courbe est
le suivant :

1. Sur Windows 10 et Windows Server 2016, utilisez [Link] pour ajouter une
nouvelle courbe nommée inscrite à Windows.
2. À partir de ce même ordinateur, ouvrez la console de gestion de la stratégie de
groupe, créez un objet de stratégie de groupe et modifiez-le.

3. Accédez à Configuration utilisateur|Préférences|Paramètres Windows|Registre.

Cliquez avec le bouton droit sur Registre. Pointez sur Nouveau, puis sélectionnez
Élément de collection. Renommez l’élément de collection pour correspondre au
nom de la courbe. Vous allez créer un élément de Collection de registre pour
chaque clé de registre sous
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Cryptography\ECCPara
meters.

4. Configurez la Collection de registre de préférences de stratégie de groupe

nouvellement créée en ajoutant un nouvel Élément de registre pour chaque valeur
de Registre répertoriée sous
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Cryptography\ECCPara
meters[curveName].

5. Déployez l’objet de la stratégie de groupe contenant la stratégie de groupe de

l’élément de la collection de Registre sur Windows 10 et les ordinateurs Windows
Server 2016 qui doivent recevoir les nouvelles courbes nommées.

Figure 3 Utilisation des préférences de la stratégie de groupe pour distribuer les

courbes
Gestion de l’ordre ECC TLS
À compter de Windows 10 et de Windows Server 2016, les paramètres de la stratégie de
groupe de commandes de courbe ECC peuvent être utilisés pour configurer l’ordre de
courbe TLS ECC par défaut. À l’aide d’ECC générique et de ce paramètre, les
organisations peuvent ajouter leurs propres courbes nommées approuvées (approuvées
pour une utilisation avec le protocole TLS) au système d’exploitation, puis ajouter ces
courbes nommées au paramètre de priorité de courbe de la stratégie de groupe pour
s’assurer qu’elles sont utilisées dans les futures liaisons du protocole TLS. Les nouvelles
listes de priorité de courbes deviennent actives lors du redémarrage suivant après avoir
reçu les paramètres de stratégie.

Figure 4 Gestion de la priorité de la courbe TLS à l’aide de la stratégie de groupe

Paramètres du Registre protocole TLS
Article • 16/07/2024

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows 11, Windows 10 et versions antérieures indiquées

Cet article décrit les informations de paramètre de Registre prises en charge pour
l’implémentation Windows des protocoles TLS (Transport Layer Security) et SSL (Secure
Sockets Layer) par le biais du fournisseur SSP (Security Support Provider) Schannel. Les
sous-clés et entrées de Registre couvertes dans cet article vous aident à administrer et à
dépanner le SSP Schannel, en particulier avec les protocoles TLS et SSL.

Ｕ Attention

Ces informations sont fournies à titre de référence et peuvent être utilisées dans le
cadre de la résolution de problèmes ou de la vérification de l’application des
paramètres requis. Nous vous recommandons de ne pas modifier directement le
Registre, sauf s’il n’y a pas d’autre solution. Les modifications apportées au Registre
ne sont pas validées par l’Éditeur du Registre ni par le système d’exploitation
Windows avant d’être appliquées. Par conséquent, des valeurs incorrectes peuvent
être stockées et cela peut générer des erreurs irrécupérables dans le système.
Plutôt que de modifier directement le Registre, utilisez si possible la stratégie de
groupe ou d’autres outils Windows tels que la console MMC (Microsoft
Management Console). Si vous devez modifier le Registre, soyez très vigilant.

Journalisation Schannel
Il existe huit niveaux de journalisation pour les événements Schannel enregistrés dans le
journal des événements système et visibles à l’aide de l’observateur d’événements. Ce
chemin de Registre est stocké dans
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL sous la clé
EventLogging avec une valeur DWORD définie sur 1.

ﾉ Agrandir le tableau

Décimal ou hexadécimal Événements de journalisation Schannel

0 Aucun événement
 Décimal ou hexadécimal Événements de journalisation Schannel

1 Événements d’erreur

2 Événements d’avertissement

3 Événements d’erreur et d’avertissement

4 Événements d’information et de réussite

5 Événements d’erreur, d’information et de réussite

6 Événements d’avertissement, d’information et de réussite

7 Événements d’erreur, d’avertissement, d’information et de réussite

７ Notes

Vous devez redémarrer votre appareil après avoir modifié le niveau de

journalisation Schannel.

CertificateMappingMethods
Quand une application serveur nécessite une authentification du client, SChannel tente
automatiquement de mapper le certificat fourni par l’ordinateur client à un compte
d’utilisateur. Vous pouvez authentifier les utilisateurs qui se connectent avec un certificat
client en créant des mappages qui lient les informations de certificat à un compte
d’utilisateur Windows.

Après avoir créé et activé un mappage de certificat, chaque fois qu’un client présente un
certificat client, votre application serveur associe automatiquement cet utilisateur au
compte d’utilisateur Windows approprié.

Dans la plupart des cas, un certificat est mappé avec un compte d’utilisateur de deux
manières :

Un seul certificat est mappé avec un compte d’utilisateur (mappage un-à-un).

Plusieurs certificats sont mappés avec un compte d’utilisateur (mappage plusieurs-
à-un).

Le fournisseur SChannel utilise quatre (4) méthodes de mappage de certificats :

1. Mappage S4U (service-for-user) Kerberos (activé par défaut)

2. Mappage du nom principal de l’utilisateur
3. Mappage un-à-un (également appelé mappage objet/émetteur)
 4. Mappage plusieurs-à-un

Chemin de Registre : HKLM

SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

ﾉ Agrandir le tableau

Nom de l’entrée DWORD Activée par défaut

Subject/Issuer 0x000000001 Non

Émetteur 0x000000002 Non

UPN 0x000000004 Non

S4U2Self 0x000000008 Oui

S4U2Self Explicit 0x000000010 Oui

Versions applicables : comme indiqué dans la liste S’applique à qui se trouve au début
de cet article.

Chiffrements
Les chiffrements TLS/SSL doivent être contrôlés en configurant l’ordre de la suite de
chiffrement. Pour plus d’informations, consultez Configuration de l’ordre de la suite de
chiffrement TLS.

Pour plus d’informations sur les ordres de la suite de chiffrement par défaut utilisés par
le fournisseur SSP SChannel, consultez Suites de chiffrement dans TLS/SSL (SSP
SChannel).

CipherSuites
La configuration des suites de chiffrement TLS/SSL doit être effectuée à l’aide d’une
stratégie de groupe, de la MDM ou de PowerShell. Pour plus d’informations, consultez
Configuration de l’ordre de la suite de chiffrement TLS.

Pour plus d’informations sur les ordres de la suite de chiffrement par défaut utilisés par
le fournisseur SSP SChannel, consultez Suites de chiffrement dans TLS/SSL (SSP
SChannel).

ClientCacheTime
Cette entrée spécifie la durée de vie de l’élément de cache de session TLS du client en
millisecondes. À compter de Windows Server 2008 et de Windows Vista, la valeur par
défaut est de 10 heures. La valeur 0 désactive la mise en cache de session TLS sur le
client.

La première fois qu’un client se connecte à un serveur via le fournisseur SSP SChannel,
une liaison TLS/SSL complète est établie. Ensuite, le secret principal, la suite de
chiffrement et les certificats sont stockés dans le cache de session sur le client et le
serveur correspondants.

Chemin de Registre : HKLM

SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

EnableOcspStaplingForSni
L’association OCSP (Online Certificate Status Protocol) permet à un serveur web, par
exemple IIS (Internet Information Services), de fournir l’état de révocation actuel d’un
certificat de serveur lorsqu’il envoie le certificat de serveur à un client pendant
l’établissement d’une liaison TLS. Cette fonctionnalité réduit la charge des serveurs
OCSP, car le serveur web peut mettre en cache l’état OCSP actuel du certificat de
serveur et l’envoyer à plusieurs clients web. Sans cette fonctionnalité, chaque client web
tenterait de récupérer l’état OCSP actuel du certificat de serveur auprès du serveur
OCSP, ce qui générerait une charge élevée sur ce serveur OCSP.

En dehors d’IIS, les services web sur [Link] peuvent également tirer parti de ce
paramètre, notamment les services de fédération Active Directory (AD FS) et le Proxy
d’application web (WAP).

Par défaut, la prise en charge d’OCSP est activée pour les sites web IIS comportant une
liaison sécurisée (SSL/TLS) simple. Cependant, cette prise en charge n’est pas activée par
défaut si le site web IIS utilise l’un des types de liaisons SSL/TLS suivants ou les deux :

Exiger l'indication de nom de serveur

Utiliser le magasin de certificats centralisés

Dans ce cas, la réponse hello du serveur pendant l’établissement d’une liaison TLS
n’inclut pas d’état associé OCSP par défaut. Ce comportement améliore les
performances : l’implémentation de l’association OCSP Windows s’adapte à des
centaines de certificats de serveur. Cependant, l’indication du nom du serveur (SNI) et le
magasin de certificats central (CCS) permettent à IIS de mettre à l’échelle des milliers de
sites web qui ont potentiellement des milliers de certificats de serveur. Par conséquent,
l’activation de l’agrafage OCSP pour les liaisons CCS peut entraîner des problèmes de
performances.

Versions applicables : toutes les versions à compter de Windows Server 2012 et

Windows 8.

Chemin de Registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHA
NNEL

Ajoutez la clé suivante :

"EnableOcspStaplingForSni"=dword:00000001

Pour désactiver l’option, définissez la valeur DWORD sur 0 :

"EnableOcspStaplingForSni"=dword:00000000

７ Notes

L’activation de cette clé de Registre peut avoir un impact sur les performances.

Codes de hachage
Les algorithmes de hachage TLS/SSL doivent être contrôlés en configurant l’ordre de la
suite de chiffrement. Pour plus d’informations, consultez Configuration de l’ordre de la
suite de chiffrement TLS.

IssuerCacheSize
Cette entrée contrôle la taille du cache de l’émetteur et est utilisée avec le mappage
d’émetteur. Le fournisseur SSP SChannel tente de mapper tous les émetteurs de la
chaîne de certificats du client, et pas seulement l’émetteur direct du certificat du client.
Lorsque les émetteurs ne correspondent pas à un compte (cas classique), le serveur peut
tenter de mapper le même nom d’émetteur à plusieurs reprises, des centaines de fois
par seconde.

Pour éviter ce problème, le serveur possède un cache négatif. Ainsi, tout nom
d’émetteur qui ne correspond pas à un compte est ajouté au cache. Le fournisseur SSP
SChannel ne tente pas de le mapper à nouveau tant que l’entrée de cache n’a pas
expiré. Cette entrée de Registre spécifie la taille du cache. Par défaut, cette entrée
n’existe pas dans le Registre. La valeur par défaut est 100.
Versions applicables : toutes les versions à compter de Windows Server 2008 et
Windows Vista.

Chemin de Registre : HKLM

SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

IssuerCacheTime
Cette entrée contrôle l’intervalle de temps d’expiration du cache en millisecondes. Le
fournisseur SSP SChannel tente de mapper tous les émetteurs de la chaîne de certificats
du client, et pas seulement l’émetteur direct du certificat du client. Lorsque les
émetteurs ne correspondent pas à un compte (cas classique), le serveur peut tenter de
mapper le même nom d’émetteur à plusieurs reprises, des centaines de fois par
seconde.

Pour éviter ce problème, le serveur possède un cache négatif. Ainsi, tout nom
d’émetteur qui ne correspond pas à un compte est ajouté au cache. Le fournisseur SSP
SChannel ne tente pas de le mapper à nouveau tant que l’entrée de cache n’a pas
expiré. Ce cache est conservé pour des raisons de performances, afin que le système ne
continue pas de tente de mapper les mêmes émetteurs. Par défaut, cette entrée n’existe
pas dans le Registre. La valeur par défaut est 10 minutes.

Versions applicables : toutes les versions à compter de Windows Server 2008 et

Windows Vista.

Chemin de Registre : HKLM

SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Tailles de clés KeyExchangeAlgorithm

Les entrées suivantes peuvent ne pas exister dans le registre par défaut et doivent être
créées manuellement. L’utilisation d’algorithmes d’échange de clés doit être contrôlée
en configurant l’ordre de la suite de chiffrement. Pour en savoir plus sur les algorithmes
cryptographiques de la suite de chiffrement TLS/SSL, voir Suites de chiffrement dans
TLS/SSL (SChannel SSP).

Diffie-Hellman

Ajoutée dans Windows 10 version 1507 et Windows Server 2016.

Chemin du Registre :
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExc
 hangeAlgorithms\Diffie-Hellman

Pour spécifier une plage minimale prise en charge de longueur de clé en bits Diffie-
Hellman pour le client TLS, créez une entrée ClientMinKeyBitLength. Remplacez
ensuite la valeur DWORD par la longueur souhaitée en bits. S’il n’est pas configuré,
1024 bits est la valeur minimale.

Pour spécifier une plage maximale prise en charge de longueur de clé en bits Diffie-
Hellman pour le client TLS, créez une entrée ClientMaxKeyBitLength. Remplacez
ensuite la valeur DWORD par la longueur souhaitée en bits.

Pour spécifier la longueur de clé en bits Diffie-Hellman par défaut du serveur TLS,
créez une entrée ServerMinKeyBitLength. Remplacez ensuite la valeur DWORD par
la longueur souhaitée en bits. S’il n’est pas configuré, 2048 bits est la valeur par
défaut.

７ Notes

Les courbes elliptiques configurées déterminent la force de chiffrement de

l’échange de clés ECDHE. Pour plus d’informations, consultez Gérer TLS (Transport
Layer Security).

MaximumCacheSize
Cette entrée contrôle le nombre maximal de sessions TLS à mettre en cache. En
définissant MaximumCacheSize sur 0, vous désactivez le cache de session côté serveur
et empêchez la reprise de session. Lorsque la valeur de cette entrée est supérieure aux
valeurs par défaut, [Link] consomme plus de mémoire. Chaque élément du cache de
session exige généralement 2 à 4 Ko de mémoire. Par défaut, cette entrée n’existe pas
dans le Registre. La valeur par défaut est 20 000 éléments.

Versions applicables : toutes les versions à compter de Windows Server 2008 et

Windows Vista.

Chemin de Registre : HKLM

SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Messagerie : analyse de fragments

Cette entrée contrôle la taille maximale autorisée d'un message de liaison TLS qui est
accepté. Les messages plus grands que la taille autorisée ne sont pas acceptés et la
liaison TLS échoue. Par défaut, ces entrées n’existent pas dans le Registre.

Lorsque vous définissez la valeur à 0x0, les messages fragmentés ne sont pas traités et
entraînent l'échec de la liaison TLS. Les clients ou serveurs TLS de la machine active se
retrouvent donc en non-conformité avec les RFC TLS.

La taille maximale autorisée peut être augmentée jusqu’à 2^16 octets. Permettre à un
client ou à un serveur de lire et de stocker de grandes quantités de données non
vérifiées sur le réseau n'est pas une bonne idée et consomme de la mémoire
supplémentaire pour chaque contexte de sécurité.

Ajout dans Windows 7 et Windows Server 2008 R2 : une mise à jour permettant à
Internet Explorer dans Windows XP, Windows Vista et Windows Server 2008 d’analyser
des messages fragmentés d’établissement d’une liaison TLS/SSL est disponible.

Chemin de Registre :
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Messaging

Pour spécifier la taille maximale autorisée des messages de liaison TLS fragmentés que
le client TLS accepte, créez une entrée MessageLimitClient. Remplacez ensuite la valeur
DWORD par la longueur souhaitée en bits. Si elle n’est pas configurée, la valeur par
défaut est de 0x8000 octets.

Pour spécifier la taille maximale autorisée des messages de liaison TLS fragmentés que
le serveur TLS accepte lorsqu'il n'y a pas d'authentification du client, créez une entrée
MessageLimitServer. Remplacez ensuite la valeur DWORD par la longueur souhaitée en
bits. Si elle n’est pas configurée, la valeur par défaut est de 0x4000 octets.

Pour spécifier la taille maximale autorisée des messages de liaison TLS fragmentés que
le serveur TLS accepte en cas d'authentification du client, créez une entrée
MessageLimitServerClientAuth. Remplacez ensuite la valeur DWORD par la longueur
souhaitée en bits. Si elle n’est pas configurée, la valeur par défaut est de 0x8000 octets.

SendTrustedIssuerList
Les serveurs TLS peuvent envoyer une liste des noms uniques d’autorités de certification
acceptables lors de la demande d’authentification du client. Cela peut aider les clients
TLS à sélectionner un certificat client TLS approprié. Les serveurs TLS basés sur SChannel
n’envoient pas cette liste d’émetteurs approuvés par défaut, car les autorités de
certification approuvées par le serveur se trouvent exposées à des observateurs passifs
et la quantité de données échangées au cours de l’établissement de la liaison TLS s’en
trouve également augmentée. Si vous définissez cette valeur sur 1, les serveurs basés sur
SChannel envoient leurs listes d’émetteurs approuvés.
Ne pas envoyer une liste d’émetteurs approuvés peut avoir un impact sur ce que le
client envoie lorsqu’il reçoit une demande de certificat client. Par exemple, lorsque
Microsoft Edge reçoit une requête d'authentification du client, il n'affiche que les
certificats du client qui s'enchaînent à l'une des autorités de certification envoyées par le
serveur. Si le serveur n'a pas envoyé de liste, Microsoft Edge affiche tous les certificats
clients installés sur le client.

Ce comportement peut être souhaitable. Par exemple, lorsque les infrastructures à clé
publique incluent des certificats croisés, les certificats du client et du serveur n'auront
pas la même autorité de certification racine. Par conséquent, Microsoft Edge ne peut pas
choisir un certificat qui s'enchaîne à l'une des autorités de certification du serveur. Les
clients TLS peuvent proposer n'importe quel certificat client disponible lorsqu'un serveur
n'envoie pas la liste des émetteurs de confiance. Par défaut, cette entrée n’existe pas
dans le Registre.

Comportement d’envoi de la liste par défaut des

émetteurs approuvés

ﾉ Agrandir le tableau

Version de Windows Comportement par défaut

Windows Server 2012, Windows 8 et versions ultérieures FALSE

Windows Server 2008 R2, Windows 7 et versions antérieures TRUE

Versions applicables : toutes les versions à compter de Windows Server 2008 et

Windows Vista.

Chemin de Registre : HKLM

SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

ServerCacheTime
Cette entrée spécifie la durée de vie de l’élément de cache de session TLS du serveur en
millisecondes. La valeur par défaut est 10 heures. La valeur 0 désactive la mise en cache
de session TLS sur le serveur et empêche la reprise de session. Lorsque la valeur de cette
entrée est supérieure aux valeurs par défaut, [Link] consomme plus de mémoire.
Chaque élément de cache de session nécessite en général entre 2 et 4 Ko de mémoire.
Par défaut, cette entrée n’existe pas dans le Registre.
Versions applicables : toutes les versions à compter de Windows Server 2008 et
Windows Vista.

Chemin de Registre : HKLM

SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Durée du cache du serveur par défaut : 10 heures

Paramètres de version des protocoles TLS, DTLS

et SSL
Le fournisseur SSP SChannel implémente différentes versions des protocoles TLS, DTLS
et SSL. Les versions des protocoles prises en charge varient selon les versions de
Windows. L’ensemble des versions des protocoles (D)TLS et SSL disponibles à l’échelle
du système peut être restreint (mais pas étendu) par les appelants SSPI qui spécifient la
structure SCH_CREDENTIALS dans l’appel AcquireCredentialsHandle. Il est recommandé
aux appelants SSPI d’utiliser les valeurs par défaut du système, plutôt que d’imposer des
restrictions sur la version des protocoles.

Une version prise en charge des protocoles (D)TLS et SSL peut se trouver dans les états
suivants :

Activé : À moins que l’appelant SSPI désactive explicitement cette version de

protocole à l’aide de la structure SCH_CREDENTIALS, le fournisseur SSP SChannel
peut négocier cette version de protocole avec un pair qui la prend en charge.
Désactivé : Le fournisseur SSP SChannel ne négocie pas cette version de protocole,
quels que soient les paramètres spécifiés par l’appelant SSPI.

Ces valeurs de Registre sont configurées séparément pour les rôles client et serveur de
protocole sous les sous-clés de Registre nommées au format suivant :

<SSL/TLS/DTLS><numéro de version majeure>.<numéro de version mineure>

<Client\Serveur>

Ces sous-clés propres à la version peuvent être créées sous le chemin de Registre
suivant :

HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

Par exemple, voici quelques chemins de Registre valides avec des sous-clés propres à la
version :
 HKLM
SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL
3.0\Client

HKLM
SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Server

HKLM
SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\DT
LS 1.2\Client

Pour remplacer une valeur système par défaut et définir une version prise en charge des
protocoles (D)TLS et SSL à l’état Activé, sous la sous-clé propre à la version
correspondante, créez une valeur de Registre DWORD nommée « Enabled » avec la
valeur « 1 ».

L’exemple suivant montre un client TLS 1.0 défini sur l’état Activé :

Pour remplacer une valeur système par défaut et définir une version prise en charge des
protocoles (D)TLS et SSL à l’état Désactivé, sous la sous-clé propre à la version
correspondante, remplacez la valeur de Registre DWORD « Enabled » par « 0 ».

L’exemple suivant montre le protocole DTLS 1.2 désactivé dans le Registre :

Le basculement d’une version des protocoles (D)TLS et SSL vers l’état Désactivé peut
entraîner l’échec des appels AcquireCredentialsHandle en raison de l’absence de
versions qui sont à la fois activées à l’échelle du système et autorisées par des appelants
SSPI particuliers. En outre, le fait de réduire l’ensemble des versions Activées des
protocoles (D)TLS et SSL risque de rompre l’interopérabilité avec les pairs distants.

Une fois que les paramètres de la version du protocole (D)TLS ou SSL sont modifiés, ils
prennent effet sur les connexions établies à l'aide de gestionnaires d'informations
d'identification ouverts par des appels AcquireCredentialsHandle ultérieurs. Les
applications et services client et serveur (D)TLS et SSL ont tendance, pour des raisons de
performances, à réutiliser les handles d’informations d’identification sur plusieurs
connexions. Un redémarrage de l'application ou du service peut s'avérer nécessaire pour
permettre à ces applications d'acquérir à nouveau leurs poignées d'identification.

Ces paramètres de Registre s’appliquent uniquement au fournisseur SSP SChannel. Ils

n’affectent pas les implémentations tierces des protocoles (D)TLS et SSL qui peuvent
être installées sur le système.

２ Avertissement

Il n'est pas recommandé d'essayer de créer ou d'ajuster des paramètres de registre

SChannel qui ne sont pas explicitement détaillés dans cet article, en raison des
 risques potentiels et des conséquences involontaires qui peuvent découler de
configurations non prises en charge.

Pour en savoir plus sur la gestion de la suite de chiffrement TLS à l'aide de PowerShell,
consultez la référence de la commande TLS. Si vous souhaitez gérer les paramètres TLS à
l'aide d'une stratégie de groupe, consultez Configuration de l'ordre de la suite de
chiffrement TLS à l'aide d'une stratégie de groupe.

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Informations techniques de référence
sur le fournisseur SSP (Security Support
Provider) Schannel
Article • 12/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows 10

Cette référence pour les professionnels de l’informatique contient des informations sur
le protocole TLS (Transport Layer Security), le protocole SSL (Secure Sockets Layer) et le
protocole DTLS (Datagram Transport Layer Security), tel qu’implémenté par le
fournisseur de support de sécurité (SSP) Schannel.

Ces protocoles fournissent un moyen de sécuriser les données envoyées entre les
applications sur un réseau non approuvé à l’aide de l’authentification basée sur les
certificats et de clés de chiffrement symétriques.

Protocole TLS (Transport Layer Security)

Protocole de la couche de transport de datagrammes

Liens connexes
Authentification WindowsAuthentification Kerberos
Protocole TLS (Transport Layer Security)
Article • 31/07/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016,
Windows 10

Cette rubrique destinée aux professionnels de l’informatique décrit le fonctionnement

du protocole TLS (Transport Layer Security) et fournit des liens vers les RFC (Request for
Comments) de l’IETF (Internet Engineering Task Force) pour TLS 1.0, TLS 1.1 et TLS 1.2.

７ Notes

Dans une version ultérieure de Windows Server, TLS 1.0 et 1.1 seront désactivés par
défaut. Pour plus d’informations, consultez les ressources de désactivation TLS
versions 1.0 et 1.1 .

Les protocoles TLS (et SSL) se trouvent entre la couche de protocole d’application et la
couche TCP/IP, où ils peuvent sécuriser et envoyer des données d’application à la
couche de transport. Étant donné que les protocoles fonctionnent entre la couche
d’application et la couche de transport, les protocoles TLS et SSL peuvent prendre en
charge plusieurs protocoles de couche d’application.

Les protocoles TLS et SSL supposent l’utilisation d’un transport orienté connexion,
généralement TCP. Le protocole permet aux applications clientes et serveur de détecter
les risques de sécurité suivants :

Falsification de messages

Interception de messages

Contrefaçon de messages

Les protocoles TLS et SSL peuvent être divisés en deux couches. La première couche se
compose du protocole d’application et des trois protocoles d’établissement de liaison :
le protocole d’établissement de liaison, le protocole de changement des spécifications
de chiffrement et le protocole d’alerte. La deuxième couche est le protocole
d’enregistrement.

Couches de protocole TLS et SSL

Le fournisseur SSP (Security Support Provider) Schannel implémente les protocoles TLS
et SSL sans modification. Le protocole SSL est propriétaire, mais l’Internet Engineering
Task Force produit les spécifications TLS publiques. Pour plus d’informations sur la
version des protocoles TLS ou SSL prise en charge dans les versions de Windows,
consultez Protocoles dans TLS/SSL (SSP Schannel). Chaque spécification contient des
informations concernant les éléments suivants :

Le protocole d’enregistrement TLS

Les protocoles de négociation TLS : - Protocole de changement des spécifications

de chiffrement - Protocole d’alerte

Les calculs de chiffrement

Les suites de chiffrement obligatoires

Le protocole de données d’application

RFC 5246 : Version 1.2 du protocole TLS (Transport Layer Security)

RFC 4346 : la version 1.1 du protocole TLS

RFC 2246 : la version 1.0 du protocole TLS

Reprise de session TLS

Introduit dans Windows Server 2012 R2, le SSP Schannel a implémenté la partie côté
serveur de la reprise de session TLS. L’implémentation côté client de RFC 5077 a été
ajoutée dans Windows 8.

Les périphériques qui connectent fréquemment TLS aux serveurs doivent se reconnecter.
La reprise de session TLS réduit le coût d’établissement des connexions TLS, car une
reprise implique l’établissement d’une liaison TLS abrégé. Cela facilite d’autres tentatives
de reprise en permettant à un groupe de serveurs TLS de reprendre les sessions TLS des
autres serveurs du groupe. Cette modification permet à tout client TLS prenant en
charge la norme RFC 5077, y compris les appareils Windows Phone et Windows RT, de
bénéficier des économies suivantes :

Utilisation des ressources sur le serveur réduite

Bande passante réduite, ce qui améliore l’efficacité des connexions client

Réduction du temps consacré aux établissements de liaison TLS grâce aux reprises
de connexion

Pour plus d’informations sur la reprise de session TLS sans état, consultez le document
IETF RFC 5077 .
Négociation de protocole d’application
Windows Server 2012 R2 et Windows 8.1 ont introduit la prise en charge de la
négociation du protocole d’application TLS côté client. Les applications peuvent donc
exploiter les protocoles dans le cadre du développement standard HTTP 2.0, et les
utilisateurs peuvent accéder à des services en ligne (comme Google et Twitter) à l’aide
d’applications exécutant le protocole SPDY.

Pour plus d’informations sur le fonctionnement de la négociation de protocole

d’application, consultez la rubrique Extension de la négociation de protocole à la couche
d’application Transport Layer Security (TLS) .

Prise en charge de TLS pour les extensions

d’indication du nom du serveur
La fonctionnalité d’indication du nom de serveur étend les protocoles SSL et TLS pour
permettre l’identification correcte du serveur lorsque de nombreuses images virtuelles
s’exécutent sur un serveur unique. Dans un scénario d’hébergement virtuel, plusieurs
domaines (chacun avec son propre certificat potentiellement distinct) sont hébergés sur
un seul serveur. Dans ce cas, le serveur n’a aucun moyen de savoir au préalable quel
certificat envoyer au client. La fonctionnalité SNI permet au client d’informer le domaine
cible plus tôt au cours du protocole et permet au serveur de sélectionner correctement
le certificat approprié.

Cela permet de bénéficier des fonctionnalités supplémentaires suivantes :

Héberger plusieurs sites web SSL sur une combinaison port/protocole Internet
unique

réduisent l’utilisation de la mémoire lorsque plusieurs sites Web SSL sont hébergés
sur un serveur Web unique ;

Permettre à plus d’utilisateurs de se connecter simultanément à des sites web SSL

Protocole de la couche de transport de
datagrammes
Article • 05/10/2023

Windows Server 2016, Windows 10

Cette rubrique de référence pour les professionnels de l’informatique décrit le protocole

DTLS (Datagram Transport Layer Security), qui fait partie du fournisseur de support de
sécurité (SSP) Schannel.

Introduit dans le SSP Schannel dans Windows Server 2012 et Windows 8, le protocole
DTLS fournit la confidentialité des communications pour les protocoles de datagramme.
Pour savoir quelle version de DTLS est prise en charge dans les versions de Windows,
voir Protocoles dans TLS/SSL (SSP Schannel). Le protocole permet aux applications client
et serveur de communiquer d’une manière conçue pour empêcher toute tentative
d’écoute clandestine, de falsification ou de contrefaçon de message. Le protocole DTLS
s’appuie sur le protocole TLS (Transport Layer Security) et fournit des garanties de
sécurité équivalentes, réduisant le besoin d’utiliser IPsec ou concevant un protocole
personnalisé de sécurité de la couche Application.

Les datagrammes sont communs dans la diffusion multimédia en continu, telle que les
jeux ou la vidéoconférence sécurisée. Les développeurs peuvent mettre au point des
applications qui utilisent le protocole DTLS dans le contexte du modèle SSPI (Security
Support Provider Interface) de l'authentification Windows pour sécuriser la
communication entre les clients et les serveurs. Le protocole DTLS repose sur le
protocole UDP (User Datagram Protocol). DTLS est conçu pour être aussi similaire que
possible à TLS afin de minimiser les nouvelles inventions en matière de sécurité et de
maximiser la réutilisation du code et de l'infrastructure.

Les suites de chiffrement disponibles pour la configuration sont basées sur celles que
vous pouvez configurer pour TLS. RC4 n’est pas autorisé. Schannel continue d'utiliser
Cryptography Next Generation (CNG). Cela permet de tirer parti de la certification FIPS
140, qui a été introduite dans Windows Vista.

Références supplémentaires
IETF RFC 4347 Datagram Transport Layer Security
Fonctionnement du contrôle de compte
d’utilisateur
Article • 11/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Le Contrôle de compte d’utilisateur (UAC) contribue à éviter que des programmes

malveillants n’endommagent un ordinateur tout en permettant aux organisations de
déployer un bureau mieux administré. Avec UAC, les applications et les tâches sont
toujours exécutées dans le contexte de sécurité d’un compte non administrateur, sauf si
un administrateur autorise spécifiquement l’accès administrateur au système. Le
contrôle de compte d’utilisateur peut bloquer l’installation automatique d’applications
non autorisées et empêcher les modifications accidentelles de paramètres système.

Processus et interactions UAC

Chaque application qui nécessite le jeton d’accès administrateur doit demander à
l’administrateur de donner son consentement. La seule exception à cette règle est la
relation qui existe entre les processus parent et enfant. Les processus enfants héritent
du jeton d’accès utilisateur du processus parent. Les deux processus parent et enfant
doivent cependant avoir le même niveau d’intégrité. Windows Server 2012 protège les
processus en marquant leurs niveaux d’intégrité. Les niveaux d’intégrité sont des
mesures de la confiance. Une application d’intégrité « élevée » est une application qui
effectue des tâches qui modifient les données système, comme une application de
partitionnement de disque, tandis qu’une application à « faible » intégrité est une
application qui effectue des tâches susceptibles de compromettre le système
d’exploitation, comme un navigateur web. Les applications avec des niveaux d’intégrité
inférieurs ne peuvent pas modifier les données dans les applications avec des niveaux
d’intégrité plus élevés. Lorsqu’un utilisateur standard tente d’exécuter une application
qui nécessite un jeton d’accès administrateur, UAC exige que l’utilisateur fournisse des
informations d’identification d’administrateur valides.

Pour mieux comprendre comment ce processus se produit, il est important de passer en

revue les détails du processus d’ouverture de session Windows Server 2012.

Processus d’ouverture de session Windows Server 2012

L’illustration suivante montre comment le processus d’ouverture de session d’un
administrateur diffère du processus d’ouverture de session d’un utilisateur standard.

Par défaut, les utilisateurs standard et les administrateurs accèdent aux ressources et
exécutent des applications dans le contexte de sécurité des utilisateurs standard.
Lorsqu’un utilisateur ouvre une session sur un ordinateur, le système crée un jeton
d’accès spécialement pour lui. Ce jeton d’accès contient des informations sur le niveau
d’accès accordé à l’utilisateur, notamment des identificateurs de sécurité et des
privilèges Windows spécifiques.

Lorsqu’un administrateur ouvre une session, deux jetons d’accès sont créés pour
l’utilisateur : un jeton d’accès utilisateur standard et un jeton d’accès administrateur. Le
jeton d’accès utilisateur standard contient les mêmes informations spécifiques à
l’utilisateur que le jeton d’accès administrateur, mais les privilèges et SID administratifs
Windows sont supprimés. Le jeton d’accès utilisateur standard est utilisé pour démarrer
des applications qui n’effectuent pas de tâches administratives (applications utilisateur
standard). Le jeton d’accès utilisateur standard est ensuite utilisé pour afficher le bureau
([Link]). [Link] est le processus parent duquel tous les autres processus
lancés par l’utilisateur héritent leur jeton d’accès. Par conséquent, toutes les applications
s’exécutent avec des privilèges d’utilisateur standard, sauf si un utilisateur fournit son
consentement ou des informations d’identification pour utiliser un jeton d’accès
administrateur total dans une application.

Un utilisateur membre du groupe Administrateurs peut ouvrir une session, naviguer sur
le Web et lire ses courriers électroniques avec un jeton d’accès utilisateur standard.
Lorsque l’administrateur doit effectuer une tâche qui requiert le jeton d’accès
administrateur, Windows Server 2012 demande automatiquement l’approbation de
l’utilisateur. Cette demande s’appelle une invite d’élévation. Vous pouvez configurer son
comportement à l’aide du composant logiciel enfichable Stratégie de sécurité locale
([Link]) ou de la stratégie de groupe.
 ７ Notes

Le terme "élévation" désigne le processus de Windows Server 2012 qui invite

l’utilisateur à fournir son consentement ou ses informations d’identification pour
utiliser un jeton d’accès administrateur total.

Expérience utilisateur du contrôle de compte d’utilisateur

Lorsque l’UAC est activé, l’expérience utilisateur des utilisateurs standard est différente
de celle des administrateurs en mode d’approbation Administration. La méthode
recommandée et la plus sécurisée d’exécution de Windows Server 2012 consiste à faire
de votre compte d’utilisateur principal un compte d’utilisateur standard. L’exécution en
tant qu’utilisateur standard contribue à optimiser la sécurité d’un environnement géré.
Avec le composant d’élévation UAC intégré, les utilisateurs standard peuvent facilement
effectuer une tâche d’administration en entrant des informations d’identification valides
pour un compte d’administrateur local. Le composant d’élévation UAC intégré par
défaut pour les utilisateurs standard est l’invite d’informations d’identification.

L’alternative à l’exécution en tant qu’utilisateur standard consiste à exécuter en tant

qu’administrateur en mode d’approbation administrateur. Grâce au composant
d’élévation du contrôle de compte d’utilisateur intégré, les membres du groupe
Administrateurs local peuvent facilement effectuer une tâche d’administration en
fournissant l’approbation. Le composant d’élévation UAC intégré par défaut pour un
compte d’administrateur en mode d’approbation administrateur est appelé invite de
consentement. Le comportement des invites d’élévation UAC peut être configuré à l’aide
du composant logiciel enfichable Stratégie de sécurité locale ([Link]) ou de la
stratégie de groupe.

Les invites de consentement et d’informations d’identification

Le contrôle de compte d’utilisateur étant activé, Windows Server 2012 demande le

consentement ou les informations d’identification d’un compte d’administrateur local
valide avant de démarrer un programme ou une tâche nécessitant un jeton d’accès
administrateur total. Cette invite garantit qu’aucun logiciel malveillant ne peut être
installé en mode silencieux.

Demande de consentement

La demande de consentement est présentée lorsqu’un utilisateur tente d’effectuer une

tâche qui nécessite un jeton d’accès administrateur. Voici une capture d’écran de l’invite
de consentement UAC.
Demande d’informations d’identification

La demande d’informations d’identification est présentée lorsqu’un utilisateur standard

tente d’effectuer une tâche nécessitant un jeton d’accès administrateur. Le
comportement des invites par défaut d’utilisateur standard peut être configuré à l’aide
du composant logiciel enfichable Stratégie de sécurité locale ([Link]) ou de la
stratégie de groupe. Les administrateurs peuvent également être amenés à présenter
leurs informations d’identification si le paramètre de stratégie Contrôle de compte
d’utilisateur : comportement de l’invite d’élévation pour les administrateurs en mode
d’approbation Administrateur est défini avec la valeur Demande d’informations
d’identification.

La capture d’écran suivante est un exemple d’invite d’informations d’identification UAC.

Invites d’élévation UAC

Les invites d’élévation du contrôle de compte d’utilisateur sont codées avec des
couleurs différentes selon l’application, ce qui permet d’identifier immédiatement le
risque de sécurité potentiel de l’application. Lorsqu’une application tente de s’exécuter
avec un jeton d’accès administrateur total, Windows Server 2012 commence par
analyser le fichier exécutable afin d’en déterminer l’éditeur. Les applications sont tout
d’abord classées en trois catégories, selon l’éditeur du fichier exécutable : Windows
Server 2012, vérifiées par l’éditeur (signées), et non vérifiées par l’éditeur (non signées).
Le diagramme suivant illustre la façon dont Windows Server 2012 détermine l’invite
d’élévation en couleur à présenter à l’utilisateur.

Le codage de couleur de l’invite d’élévation est le suivant :

Arrière-plan rouge avec une icône de bouclier rouge : l’application est bloquée par
la stratégie de groupe ou émane d’un éditeur bloqué.

Arrière-plan bleu avec une icône de bouclier bleue et dorée : l’application est une
application d’administration Windows Server 2012, telle qu’un élément du Panneau
de configuration.

Arrière-plan bleu avec une icône de bouclier bleue : l’application est signée à l’aide
de la technologie Authenticode et elle est approuvée par l’ordinateur local.

Arrière-plan jaune avec une icône de bouclier jaune : l’application est signée ou
non signée mais elle n’est pas encore approuvée par l’ordinateur local.

Icône de bouclier

Certains éléments du Panneau de configuration, tels que Propriétés de dates et

d’heures, contiennent une combinaison d’opérations d’utilisateur standard et
d’administrateur. Les utilisateurs standard peuvent afficher l’horloge et changer le
fuseau horaire, mais un jeton d’accès administrateur complet est requis pour modifier
l’heure système locale. L’image suivante est une capture d’écran de l’élément du
Panneau de configuration Propriétés de dates et d’heures.
L’icône de bouclier sur le bouton Changer la date et l’heure indique que le processus
requiert un jeton d’accès administrateur complet et qu’il va afficher une invite
d’élévation du contrôle de compte d’utilisateur.

Sécurisation de l’invite d’élévation

La sécurisation du processus d’élévation est renforcée car l’invite est envoyée sur le
bureau sécurisé. Les demandes de consentement et d’informations d’identification sont
affichées sur le bureau sécurisé par défaut de Windows Server 2012. Seuls les processus
Windows peuvent accéder au bureau sécurisé. Pour obtenir des niveaux de sécurité plus
élevés, il est recommandé de laisser le paramètre de stratégie Contrôle de compte
d’utilisateur : passer au Bureau sécurisé lors d’une demande d’élévation activé.

Lorsqu’un fichier exécutable demande l’élévation, le bureau interactif, également appelé

bureau de l’utilisateur, passe au bureau sécurisé. Le bureau sécurisé atténue le bureau
de l’utilisateur et affiche une invite d’élévation à laquelle vous devez répondre avant de
continuer. Lorsque l’utilisateur clique sur Oui ou sur Non, le bureau repasse au bureau
de l’utilisateur.

Les logiciels malveillants peuvent présenter une imitation du bureau sécurisé, mais
lorsque le paramètre de stratégie Contrôle de compte d’utilisateur : comportement de
l’invite d’élévation pour les administrateurs en mode d’approbation Administrateur est
défini sur Demande de consentement, ils n’obtiennent pas d’élévation si l’utilisateur
clique sur Oui sur l’imitation. En revanche, si le paramètre de stratégie est défini sur
Demande d’informations d’identification, il est possible que les logiciels malveillants
imitant la demande d’informations d’identification parviennent à réunir les informations
d’identification de l’utilisateur. Toutefois, le programme malveillant ne bénéficie pas de
privilèges élevés, et le système dispose d’autres protections qui empêchent les
programmes malveillants de prendre le contrôle de l’interface utilisateur, même avec un
mot de passe collecté.

Si les logiciels malveillants peuvent présenter une imitation du bureau sécurisé, ce

problème ne peut pas se produire sauf si un utilisateur a précédemment installé les
logiciels malveillants sur l’ordinateur. Comme les processus nécessitant un jeton d’accès
administrateur ne peuvent pas s’installer en mode silencieux lorsque le contrôle de
compte d’utilisateur est activé, l’utilisateur doit explicitement fournir un consentement
en cliquant sur Oui ou en fournissant des informations d’identification d’administrateur.
Le comportement spécifique de l’invite d’élévation UAC dépend de la stratégie de
groupe.

Architecture UAC
Le diagramme suivant montre l’architecture du contrôle de compte d’utilisateur en
détail.
Pour mieux comprendre chaque composant, consultez le tableau ci-dessous :

Composant Description

Utilisateur

L’utilisateur Si l’opération modifie le système de fichiers ou le Registre, la virtualisation est

effectue une appelée. Toutes les autres opérations appellent ShellExecute.
opération
nécessitant
des privilèges
Composant Description

ShellExecute ShellExecute appelle CreateProcess. ShellExecute recherche l’erreur

ERROR_ELEVATION_REQUIRED dans CreateProcess. S’il reçoit l’erreur,
ShellExecute appelle le service Informations sur l’application pour tenter
d’effectuer la tâche demandée à l’aide de l’invite avec élévation de privilèges.

CreateProcess Si l’application nécessite une élévation, CreateProcess rejette l’appel avec

ERROR_ELEVATION_REQUIRED.

Système

Service Service système qui démarre des applications nécessitant un ou plusieurs

Informations privilèges ou droits d’utilisateur élevés pour s’exécuter (des tâches
sur d’administration locales, par exemple), et des applications nécessitant des
l’application niveaux d’intégrité plus élevés. Le service Informations sur l’application aide à
démarrer ces applications en créant un nouveau processus pour l’application
avec le jeton d’accès complet d’un utilisateur administratif lorsque l’élévation est
requise et (en fonction de la stratégie de groupe) le consentement est donné par
l’utilisateur pour le faire.

Élévation Si ActiveX n’est pas installé, le système vérifie le niveau du curseur UAC.
d’une Si ActiveX est installé, le paramètre de stratégie de groupe Contrôle de compte
installation d’utilisateur : passer au Bureau sécurisé lors d’une demande d’élévation est
ActiveX activé.
Composant Description

Vérifier le UAC dispose désormais de quatre niveaux de notification et d’un curseur à

niveau du utiliser pour sélectionner le niveau de notification :
curseur du
contrôle de Élevé
compte Si le curseur est défini sur Toujours m’avertir, le système vérifie si le Bureau
d’utilisateur sécurisé est activé.
Moyenne
Si le curseur est défini sur Par défaut - M’avertir uniquement quand des
programmes tentent d’apporter des modifications à mon ordinateur, le
paramètre de stratégie Contrôle de compte d’utilisateur : élever
uniquement les exécutables signés et validés est activé :

Si le paramètre de stratégie n’est pas activé, la validation du chemin de

certification PKI n’est pas appliquée avant qu’un fichier exécutable
donné soit autorisé à s’exécuter.
Si le paramètre de stratégie n’est pas activé, la validation du chemin de
certification PKI n’est pas appliquée avant qu’un fichier exécutable
donné soit autorisé à s’exécuter. Le paramètre de stratégie de groupe
Contrôle de compte d’utilisateur : passer au Bureau sécurisé lors
d’une demande d’élévation est activé.
Faible
Si le curseur est défini sur M’avertir uniquement quand des programmes
tentent d’apporter des modifications à mon ordinateur (ne pas estomper
mon Bureau)., le processus CreateProcess est appelé.
Ne jamais avertir
Si le curseur est défini sur Ne jamais m’avertir quand, l’invite UAC ne vous
avertira jamais lorsqu’un programme tente de s’installer ou d’apporter des
modifications sur l’ordinateur. Important : Ce paramètre n’est pas
recommandé. Il est équivalent au paramètre de stratégie Contrôle de
compte d’utilisateur : comportement de l’invite d’élévation pour les
administrateurs en mode d’approbation Administrateur défini sur Élever
sans invite.

Bureau Le paramètre de stratégie Contrôle de compte d’utilisateur : passer au Bureau

sécurisé sécurisé lors d’une demande d’élévation est activé :
activé
- Si le bureau sécurisé est activé, toutes les demandes d’élévation passent au
bureau sécurisé quels que soient les paramètres de stratégie de comportement
d’invite pour les administrateurs et les utilisateurs standard.
- Si le Bureau sécurisé n’est pas activé, toutes les demandes d’élévation passent
au Bureau interactif de l’utilisateur et les paramètres par utilisateur sont employés
pour les administrateurs et les utilisateurs standard.
 Composant Description

CreateProcess CreateProcess appelle AppCompat, Fusion et Détection des programmes

d’installation pour déterminer si l’application nécessite une élévation. Le fichier
exécutable est alors examiné pour déterminer son niveau d’exécution demandé,
qui est stocké dans le manifeste d’application du fichier exécutable.
CreateProcess échoue si le niveau d’exécution demandé spécifié dans le
manifeste ne correspond pas au jeton d’accès et s’il renvoie une erreur
(ERROR_ELEVATION_REQUIRED) à ShellExecute.

AppCompat La base de données AppCompat stocke des informations dans les entrées de
correctif de compatibilité d’application pour une application.

Fusion La base de données Fusion stocke les informations des manifestes d’application
qui décrivent les applications. Le schéma de manifeste est mis à jour pour ajouter
un nouveau champ de niveau d’exécution demandé.

Détection des La détection du programme d’installation détecte les fichiers exécutables

programmes d’installation, ce qui empêche l’exécution des installations à l’insu et au
d’installation consentement de l’utilisateur.

Noyau

Virtualisation La technologie de virtualisation garantit que les applications non conformes

n’échouent pas en mode silencieux ou d’une manière dont la cause ne peut pas
être déterminée. UAC fournit également la virtualisation et la journalisation des
fichiers et du registre pour les applications qui écrivent dans des zones
protégées.

Système de La virtualisation de fichiers par utilisateur et du registre redirige les demandes

fichiers et d’écriture de fichiers et de registre par ordinateur vers des emplacements
Registre équivalents par utilisateur. Les demandes de lecture sont d’abord redirigées vers
l’emplacement par utilisateur virtualisé, puis vers l’emplacement par ordinateur.

UAC sur Windows Server 2012 présente des différences par rapport aux versions
précédentes de Windows. Le nouveau curseur ne désactivera jamais complètement UAC.
Le nouveau paramètre :

Maintient le service UAC en cours d’exécution.

Provoque l’approbation automatique de toutes les demandes d’élévation initiées

par les administrateurs sans afficher d’invite UAC.

Refuse automatiquement toutes les demandes d’élévation pour les utilisateurs

standard.

） Important
 Pour désactiver complètement UAC, vous devez désactiver la stratégie Contrôle de
compte d’utilisateur : exécuter les comptes d’administrateurs en mode
d’approbation d’administrateur.

２ Avertissement

Les applications personnalisées ne fonctionnent pas sur Windows Server 2012

lorsque l’UAC est désactivé.

Virtualisation
Étant donné que les administrateurs système dans les entreprises tentent de sécuriser
les systèmes, de nombreuses applications métier sont conçues pour n’utiliser qu’un
jeton d’accès utilisateur standard. Les administrateurs n’ont donc pas besoin de
remplacer la majorité des applications lorsqu’ils exécutent Windows Server 2012 avec le
contrôle de compte d’utilisateur activé.

Windows Server 2012 intègre la technologie de la virtualisation des fichiers et du

Registre pour les applications non compatibles avec le contrôle de compte d’utilisateur
qui requièrent un jeton d’accès administrateur pour s’exécuter correctement. Grâce à la
virtualisation, même les applications non compatibles avec le contrôle de compte
d’utilisateur sont compatibles avec Windows Server 2012. Lorsqu’une application
administrative non compatible UAC tente d’écrire dans un répertoire protégé, comme
Program Files, le contrôle de compte d’utilisateur donne à l’application sa propre vue
virtualisée de la ressource qu’il tente de modifier. La copie virtualisée est gérée dans le
profil utilisateur. Cette stratégie crée une copie distincte du fichier virtualisé pour
chaque utilisateur qui exécute l’application non conforme.

La plupart des tâches d’application fonctionnent correctement à l’aide des

fonctionnalités de virtualisation. Bien que la virtualisation autorise l’exécution d’une
majorité d’applications, il s’agit d’un correctif à court terme et non d’une solution à long
terme. Les développeurs d’applications doivent modifier leurs applications au plus vite
afin de les rendre compatibles avec le programme Logo Program Windows Server 2012,
plutôt que de s’appuyer sur la virtualisation des fichiers, des dossiers et du Registre.

La virtualisation n’est pas une possibilité dans les scénarios suivants :

1. La virtualisation ne s’applique pas aux applications qui sont élevées et s’exécutent

avec un jeton d’accès d’administration total.
 2. La virtualisation ne prend en charge que les applications 32 bits. Les applications
64 bits non élevées reçoivent simplement un message d’accès refusé lorsqu’elles
tentent d’acquérir un descripteur (identificateur unique) sur un objet Windows. Les
applications 64 bits Windows natives doivent être compatibles avec le contrôle de
compte d’utilisateur et pouvoir écrire des données dans les emplacements
corrects.

3. La virtualisation est désactivée pour une application si l’application inclut un

manifeste d’application avec un attribut de niveau d’exécution demandé.

Niveaux d’exécution des requêtes

Un manifeste d'application est un fichier XML qui décrit et identifie les assemblys côte à
côte partagés et privés auxquels une application doit se lier au moment de l'exécution.
Dans Windows Server 2012, le manifeste d’application contient des entrées pour assurer
la compatibilité des applications avec le contrôle de compte d’utilisateur. Les
applications administratives qui incluent une entrée dans le manifeste de l’application
demandent à l’utilisateur l’autorisation d’accéder au jeton d’accès de l’utilisateur. Même
s’il manque une entrée dans le manifeste d’application, la plupart des applications
d’administration peuvent s’exécuter sans modification grâce aux correctifs de
compatibilité des applications. Les correctifs de compatibilité des applications sont des
entrées de base de données qui permettent à des applications non compatibles avec le
contrôle de compte d’utilisateur de fonctionner correctement avec Windows
Server 2012.

Toutes les applications compatibles UAC doivent avoir un niveau d’exécution demandé
ajouté au manifeste de l’application. Si l’application nécessite un accès administratif au
système, le marquage de l’application avec un niveau d’exécution demandé
« Administrateur requis » garantit que le système identifie ce programme comme une
application administrative et effectue les étapes d’élévation nécessaires. Les niveaux
d’exécution demandés indiquent les privilèges requis pour une application.

Technologie de détection des programmes d’installation

Les programmes d’installation sont des applications conçues pour déployer des
logiciels. La plupart des programmes d’installation écrivent dans les répertoires système
et les clés du Registre. Ces emplacements système protégés sont généralement
accessibles en écriture uniquement par un administrateur dans la technologie de
détection du programme d’installation, ce qui signifie que les utilisateurs standard n’ont
pas suffisamment d’accès pour installer des programmes. Windows Server 2012 détecte
les programmes d’installation de manière heuristique et demande les informations
d’identification ou l’approbation de l’administrateur afin de les exécuter avec des
privilèges d’accès. Windows Server 2012 détecte également de manière heuristique les
mises à jour et programmes qui désinstallent les applications. L’un des objectifs
conceptuels du contrôle de compte d’utilisateur est d’empêcher l’exécution des
installations à l’insu ou sans le consentement de l’utilisateur, car les programmes
d’installation écrivent dans des zones protégées du système de fichiers et du Registre.

La détection du programme d’installation s’applique uniquement aux :

Fichiers exécutables 32 bits.

Applications sans attribut de niveau d’exécution demandé.

Processus interactifs s’exécutant en tant qu’utilisateur standard avec UAC activé.

Avant la création d’un processus 32 bits, les attributs suivants sont vérifiés pour
déterminer s’il s’agit d’un programme d’installation :

Le nom de fichier inclut des mots clés comme « install », « setup » ou « update ».

Les champs de gestion des versions des ressources contiennent les mots clés
suivants : Fournisseur, Nom de la société, Nom du produit, Description du fichier,
Nom de fichier initial, Nom interne et Nom d’exportation.

Les mots clés contenus dans le manifeste côte à côte sont incorporés dans le
fichier exécutable.

Les mots clés dans les entrées StringTable spécifiques sont liés dans le fichier
exécutable.

Les attributs clés dans les données de script de ressource sont liés dans le fichier
exécutable.

Il existe des séquences d’octets ciblées au sein du fichier exécutable.

７ Notes

Les mots clés et les séquences d’octets sont dérivés des caractéristiques communes
observées dans de nombreuses technologies de programmes d’installation.

７ Notes

Le paramètre de stratégie Contrôle de compte d’utilisateur : détecter les

installations d’applications et demander l’élévation doit être activé pour que la
technologie puisse détecter les programmes d’installation. Ce paramètre est activé
par défaut et peut être configuré localement à l’aide du composant logiciel
enfichable Stratégie de sécurité locale ([Link]), ou bien configuré pour le
domaine OU ou des groupes spécifiques à l’aide de la stratégie de groupe
([Link]).
Présentation de la liaison de jeton
Article • 11/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016 et
Windows 10

Le protocole de liaison de jeton permet aux applications et services de lier par

chiffrement leurs jetons de sécurité à la couche TLS afin d’atténuer le vol de jetons et les
attaques par relecture. Les liaisons TLS [RFC5246] à longue durée de vie peuvent
s’étendre sur plusieurs sessions et connexions TLS.

Versions prises en charge :

Windows 10, version 1507 : désactivé par défaut

Protocole de liaison de jeton ajouté [draft-ietf-tokbind-protocol-01]
WinInet & [Link] prise en charge de la liaison de jeton sur HTTP [draft-ietf-
tokbind-https-01]
Windows 10, versions 1511 et 1607, et Windows Server 2016 : activé par défaut
Protocole de liaison de jeton mis à jour [draft-ietf-tokbind-protocol-01]
Extension TLS pour la négociation de liaison de jeton ajoutée [draft-popov-
tokbind-negotiation-00]
WinInet & [Link] prise en charge de la liaison de jeton sur HTTP [draft-ietf-
tokbind-https-02]
Windows 10, version 1507 avec mise à jour de maintenance KB4034668 ,
Windows 10, version 1511 avec mise à jour de maintenance KB4034660 ,
Windows 10, version 1607 et Windows Server 2016 avec mise à jour de
maintenance KB4034658 prennent en charge le protocole de liaison de jeton
version 0.10 : activé par défaut
Protocole de liaison de jeton mis à jour [draft-ietf-tokbind-protocol-10]
Extension TLS pour la négociation de liaison de jeton ajoutée [draft-popov-
tokbind-negotiation-05]
WinInet & [Link] prise en charge de la liaison de jeton sur HTTP [draft-ietf-
tokbind-https-06]
Windows 10, version 1703 prend en charge le protocole de liaison de jeton version
0.10 : activé par défaut
Protocole de liaison de jeton mis à jour [draft-ietf-tokbind-protocol-10]
Extension TLS pour la négociation de liaison de jeton ajoutée [draft-popov-
tokbind-negotiation-05]
WinInet & [Link] prise en charge de la liaison de jeton sur HTTP [draft-ietf-
tokbind-https-06]
 Les appareils Windows avec la sécurité basée sur la virtualisation activée
conservent les clés de liaison de jeton dans un environnement protégé isolé du
système d’exploitation en cours d’exécution

Pour plus d’informations sur la prise en charge d’ASP .NET, consultez Source de
référence .NET Framework .

Pour obtenir des informations complémentaires sur .NET Framework, consultez les sujets
suivants :

Améliorations de la mise en réseau

Classe TokenBinding .NET

Antivirus Windows Defender pour
Windows Server
Article • 09/03/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Windows Server 2016 inclut désormais l’antivirus Windows Defender. L’antivirus

Windows Defender est une solution de protection contre les programmes malveillants
qui protège immédiatement et activement Windows Server 2016 contre les programmes
malveillants connus. Il peut régulièrement mettre à jour les définitions du logiciel anti-
programme malveillant par le biais de Windows Update.

Pour plus d’informations, consultez la bibliothèque de documentation Antivirus

Windows Defender dans Windows 10.

Les fonctionnalités, la configuration et la gestion de l’antivirus Windows Defender sont

globalement les mêmes dans Windows 10 ou Windows Server 2016 et versions
ultérieures. Il existe toutefois quelques différences.

７ Notes

Dans Windows Server 2016, l’antivirus Windows Defender ne se désactive pas

automatiquement quand vous exécutez un autre produit antivirus.

Pour en savoir plus, consultez les articles suivants :

Antivirus Microsoft Defender sur Windows Server

Activer l’antivirus Defender et le mettre à jour vers la dernière version sur Windows
Server
Configurer les fonctionnalités de l’antivirus Microsoft Defender
Configurer les exclusions de l’antivirus Microsoft Defender sur Windows Server
Examiner les journaux des événements et les codes d’erreur pour résoudre les
problèmes liés à l’antivirus Windows Defender