Processus des informations d’identification dans l’authentification Windows

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

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 SSPIInitializeSecurityContext (General).

• L’application côté serveur de la connexion répond avec la fonction SSPIAcceptSecurityContext (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 Secur32.dll, 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.

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 Ksecdd.sys 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 lsass.exe. 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.

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