Comment fonctionne le LSA ?

LSA AD sécurité

Sommaire

1 Cinématique d'authentification

2 Composants du système

3 Mémoire d'authentification

4 Schéma du processus d'authentification

(en domaine Active Directory avec client/serveurs/cache/LSA  et autres mécanisme)

 

 


1 Cinématique d’authentification


 

 

Démarrage du KDC

  1. LSA (LSASS) démarre les services AS et TGS qui constitu le KDC
  2. KDC génère une clé
  3. Tout est stocké dans la base de donnée géré par le DSA sous process LSA
  1. TGT donne le droit au client de demander au KDC un ST pour une ressource
  1. Donne la clé au user/ computer avec durée de vie 10h par défaut

 

Jonction du poste dans le domaine (System Key)

  • Le poste recoit une clé système lors de la jonction au domaine

 

Logon utilisateur (TGT)

  1. Logon de l’utilisateur : demande TGT au près de l’AS (user+pwd = pre-authenticator
  2. AS décrypte timestamp+pwd
  3. Si ok AS envoi TGT au client/utlisateur
  4. Obtient un TGT par l’AS du KDC
  5. Le client utilise le TGT pour demander un ST au près du TGS

Kerberos active directory AD authentification

Demande d’accès à un serveur de ressource (ST)

Demande d’accès ressource sur serveur à travers le réseau

  1. Envoi requête utilisateur pour accès à une ressource
    1. Nécessite un SPN pour localiser le service sur un serveur du réseau
  2. Le serveur de la ressource demande un « Service Ticket » ST
  3. Le client regarde son « credential cache »
  4. S’il n’y en a pas il regarde le cache LSA s’il y a un TGT et une clé afin de demander au KDC
  5. Cherche en cache les information de localisationd KDC

 

Echange avec le DNS pour localiser le KDC

  1. Si rien en cache envoi d’une requète au DNS
  2. Le DNS renvoi un enregistrement de service (SRV) pour localiser un KDC
  3. Le client regarde le cache DNS s’il a l’enregistrement hote(A) qui correspond au SRV
  4. Sinon envoi d’une requète au DNS
  5. Le DNS renvoi l’enregistre hote (A)

 

Contact du KDC pour demande de ST

  1. Le client envoi une requète au KDC pour un Service ou Session Ticket (ST)
    1. En envoyant son TGT et sa clé (consituant l' »Authenticator ») ainsi que le SPN cible
  2. Le KDC décrypte le TGT du client et le vérifie ainsi que la clé
    1. Par le biais de sa clé généré par « krbtgt » (SPN du KDC)
    2. LSA donne la main à DSA
    3. DSA gère les comptes dans la base de donnée
    4. Le TGS crée le ST (service ticket)
  3. Le KDC envoi un SK crypté avec un « TimeStamp »
    1. Temps actuel par défaut sauf si temps précisé dans la requète cliente
  4. Le client reçoit et décrypte avec sa clé le ST (SK + ticket +authenticator)
  5. Le client met en cache LSA le « Service Ticket » (RAM uniquement, pas de swap) jusqu’au logoff ou shudown

 

Envoi ST à la cible

  1. Le client envoi le ST et un nouveau authenticator à la ressource réseau cible
  2. La cible décrypte le ticket
  3. La cible valide l’authenticator
  4. Pour les services Windows, la cible cré un « Access Token » basé sur les SID du ticket
  5. Pour l’authentification mutuelle le client peut vérifier l’identité du serveur cible
    1. La cible crypte le timestamp du ticket du client avec la SK et le renvoi au client
  6. La LSA du serveur cible crée un « Access token » à partir des tickets contenu dasn le ST
  7. Si besoin la cible peut renvoyer le ST pour délégation (exemple serveur web envoi à la base de donnée
  8. La cible ouvre une session
  9. LSA réutilise le hash en cache pour renouveller le TGT avant expiration et pour ne pas redemdander le mot de passe à chaque utilisation d’une ressource
  10. Les ST et TGT sont supprimé au logoff, shutdow des clients et à un temps défini par clé de registre sur les ressources (à la déconnection depuis WS 2012 ou avec le KB 2919355)

 

SPN

      • Services tournant sous le compte ordinateurActive Directory logo
      • Retrouve dans le CG
      • Syntaxe:
        • <type of service>/<hostname>[:<port>][/servicename]

 

Les applications et le mode utilisateur

Démarrer un service

      • Le contrôleur de service se connecte en utilisant le compte qui est désigné pour le service et présente ensuite les informations d’identification du service pour l’authentification par l’autorité LSA.
      • Le service Windows implémente une interface de programmation qui permet de contrôler le service par le Gestionnaire de contrôle de service.
      • Pour obtenir une connexion authentifiée :

le service doit disposer d’informations d’identification qui approuve la LSA de l’ordinateur distant.

Lors de la communication avec d’autres ordinateurs du réseau, LSA utilise les informations d’identification de compte de domaine de l’ordinateur local, que tous les autres services s’exécutant dans le contexte de sécurité du système Local et Service réseau.

Services sur l’ordinateur local s’exécutent en tant que système, informations d’identification n’est pas nécessaire à présenter à l’autorité LSA.

Le fichier Ksecdd.sys gère et chiffre les informations d’identification et utilise un appel de procédure locale dans l’autorité LSA. Le type de fichier est LECT (pilote) et est connu en tant que fournisseur de prise en charge de sécurité en mode noyau (SSP).

En mode noyau a un accès complet aux ressources système et du matériel de l’ordinateur. Le mode noyau arrête les services en mode utilisateur et les applications d’accéder aux zones critiques du système d’exploitation qu’ils ne doivent pas avoir accès à.

 

Stockage d’informations d’identification et validation

Processus d’informations d’identification d’ouverture de session à distance

Le protocole RDP (Remote Desktop) gère les informations d’identification de l’utilisateur qui se connecte à un ordinateur distant à l’aide du Client Bureau à distance, qui a été introduite 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, l’utilisateur connecte aux ressources autorisées. RDP ne stocke pas les informations d’identification sur le client, mais les informations d’identification du domaine de l’utilisateur sont stockées dans le processus LSASS.

identifaction

Processus d’authentification d’informations d’identification de redémarrage automatique

Lorsqu’un utilisateur se connecte sur un périphérique Windows, LSA enregistre les informations d’identification en mémoire chiffrée qui sont accessibles uniquement par LSASS.exe. Lorsque Windows Update initie un redémarrage automatique sans la présence d’un utilisateur, ces informations d’identification sont utilisées pour configurer l’ouverture de session automatique pour l’utilisateur.

https://msdn.microsoft.com/fr-fr/library/dn751047(v=ws.11).aspx>

 

Component Description
Credssp.dll The default dynamic-link library (DLL) module that operates in the security context of Winlogon.
Netlogon.dll Les services qui exécute le service Net Logon sont comme suit :

  • Gère le canal l’ordinateur sécurisé (afin de ne pas confondre avec Schannel) à 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é (SID) du domaine et les droits de l’utilisateur.
  • Publie des enregistrements de ressource de service dans le système DNS (Domain Name) et utilise le système DNS pour résoudre des noms pour les adresses IP (Internet Protocol) des contrôleurs de domaine.
  • Implémente le protocole de réplication basée sur l’appel de procédure distante (RPC) pour la synchronisation des contrôleurs de domaine principal (PDC) et contrôleurs de domaine de sauvegarde (BDC).
  • Le service Net Logon publie des enregistrements de ressources de service dans le Système de noms de domaine (DNS) et utilise DNS pour résoudre les noms des adresses IP (Internet Protocol) des contrôleurs de domaine.
Schannel.dll The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) authentication protocol. This protocol provides authentication over an encrypted channel instead of a less-secure clear channel.
Kerberos.dll The Kerberos V5 authentication protocol. This protocol provides authentication using Kerberos protocol instead of plaintext, NTLM, or digest method.

Extended Protection for Authentication is enabled using the channel binding token.

Negoexts.dll An authentication package that negotiates the use of SSPs for applications and scenarios implemented by Microsoft and other software companies.
Lsasrv.dll Le service serveur LSA, qui joue le rôle du Gestionnaire de package de sécurité pour l’autorité LSA et applique les stratégies de sécurité. L’autorité LSA contient la fonction Negotiate, qui sélectionne le protocole Kerberos ou NTLM après avoir déterminé quel protocole est aboutisse.

The LSA Server service, which both enforces security policies and acts as the security package manager for the LSA.

Secur32.dll Plusieurs fournisseurs d’authentification qui forment la base du processus d’authentification.

The authentication provider that exposes the SSP interfaces to applications.

 

LSA components unique to domain controllers

 Component Description
Kdcsvc.dll The Kerberos Key Distribution Center (KDC) service, which is responsible for the Kerberos authentication service and the ticket granting service.
Ntdsa.dll The directory service module, which supports the Windows replication protocol and LDAP, and manages partitions of data
Ntdsapi.dll A directory service module which can communicate over RPC through a set of COM interfaces used for accessing directory services to manage network resources.

 

 


2 Composants du système


 

 

LSASS (Local Security Authority Subsystem Service)

Autre grande figure de la protection logicielle dans Microsoft Windows, le sous-système d’autorité de sécurité locale (LSASS, Local Security Authority Subsystem Service) est un dispositif de sécurité dont les ramifications se répartissent entre tous les services d’authentification et d’autorisation interactives de l’ordinateur. Il est chargé de la stratégie de sécurité du système local, de l’authentification des utilisateurs et de l’envoi des messages d’audit au service de journalisation des événements.

La liste suivante énumère quels sont, dans les grandes lignes, les rôles du composant LSA. Sur le plan technique, c’est le service d’autorité de sécurité locale (Lsasrv, \Windows\System32\Lsasrv.dll), bibliothèque chargée par LSASS, qui implémente la plupart de ces fonctionnalités.

      • Gestion des stratégies de sécurité locales Il gère et applique les stratégies de sécurité définies pour permettre aux utilisateurs locaux de s’authentifier, et met en œuvre les mécanismes nécessaires, par exemple, l’identification des entités ayant la permission d’accéder au système et de leurs modalités d’accès, et les paramètres de l’audit de la sécurité du système.
      • Authentification des utilisateurs Il offre un ensemble de services chargés d’authentifier les comptes accédant à l’ordinateur, incluant les stratégies de mot de passe et les privilèges accordés aux utilisateurs et aux groupes. Il est également utilisé pour traiter les demandes d’authentification via le protocole Kerberos ou le protocole NTLM dans Active Directory.
      • Création des jetons d’accès Une fois le contrôle d’ouverture de session validé, il est alimenté en informations détaillant l’identité de l’utilisateur, données à partir desquelles il génère un jeton d’accès.
      • Contrôle des stratégies d’audit Il gère et applique la stratégie d’audit du système local et met à jour le journal d’audit en fonction de cette stratégie lorsqu’il y a lieu de le faire.

L’autorité de sécurité locale se présente sous la forme d’un processus mode utilisateur, exécutant l’image \Windows\System32\Lsass.exe, qui héberge un certain nombre d’autres composants en lien avec l’architecture de sécurité de Windows, tous implémentés en tant que DLL : service d’autorité de sécurité locale (Lsasrv.dll), service SAM (Samsrv.dll), serveur Active Directory (Ntdsa.dll), service d’ouverture de session réseau (Netlogon.dll), service de distribution de tickets Kerberos (Kdcsvc.dll), ainsi qu’un ensemble de packages d’authentification (msv1_0.dll et Kerberos.dll).

LSASS, lors de l’ouverture de session, a pour mission de gérer une authentification sécurisée. Ainsi, lorsqu’une entité souhaite se connecter à un système, la demande est relayée à LSASS qui va devoir valider l’authentification demandée. (En interne, cette validation est réalisée, non par LSASS lui-même, mais par l’intermédiaire de composants spécialisés. Voir sur le sujet la section Packages d’authentification). Si la demande est acceptée, autrement dit si le contrôle d’accès a débouché sur une issue favorable, LSASS demande au SRM de procéder à la création d’un jeton d’accès.

En plus de l’authentification des comptes accédant à un ordinateur, LSASS est également chargé de valider les connexions des utilisateurs distants. Ainsi, lorsqu’un utilisateur tente de s’authentifier auprès d’un domaine, un contrôleur de domaine est contacté pendant la phase d’authentification. Celui-ci contrôle le nom et le mot de passe d’ouverture de session et, si le contrôle est positif, renvoie alors, entre autres, la liste des groupes auquel l’utilisateur appartient. Le sous-système local LSASS du poste où l’utilisateur s’est connecté crée à ce moment à ce moment un jeton d’accès qui contient les données d’identification de sécurité de cet utilisateur. Ce jeton contient l’identifiant de sécurité unique (SID) du compte utilisateur ainsi que les SIDs de tous les groupes dont il est membre dans le domaine dans lequel il s’authentifie.

La liste suivante énumère les composants fondamentaux de Windows en matière de sécurité. Notez que le catalogue ainsi constitué ne présente que les entités les plus directement impliquées dans ce domaine, à l’exclusion, donc, des dispositifs périphériques, par exemple la séquence SAS, et des mécanismes internes entrant en jeu dans l’implémentation.

      • SRM (Security Reference Monitor), Moniteur de référence de la sécurité. Composant de l’exécutif Windows responsable de la mise en œuvre et de la stricte application des stratégies de contrôle d’accès. Il procède a ce titre aux vérifications requises pour statuer si une entité (un utilisateur ou un processus agissant pour son compte) demandant d’accéder à une ressource a les droits nécessaires pour le faire, valide ou non les tentatives d’accès aux objets, et par cela génère les messages d’audit utilisés par le sous-système de sécurité.
      • Logon Process, Processus d’ouverture de Session. Processus mode utilisateur (Winlogon.exe) chargé de gérer les sessions interactives.
      • LSASS (Local Security Authority Subsystem), Sous-système d’autorité de la sécurité locale. Processus mode utilisateur, exécutant l’image Lsass.exe, responsable de la stratégie de sécurité du système local, incluant l’identification et l’authentification des utilisateurs ainsi que la gestion de leurs privilèges, les politiques de mot de passe et les paramètres d’audit de la sécurité du système.
      • LSA database, Base de données des stratégies LSA. Base de données hébergeant un contenu en rapport avec les aspects rationnels de la stratégie de sécurité du système local. Elle est stockée dans le registre sous HKEY_LOCAL_MACHINE\Security, dont l’accès est protégé au niveau système afin d’interdire sa manipulation par des utilisateurs standards.
      • Network Logon Service, Service d’ouverture de session réseau. Service Windows (\Windows\System32\Netlogon.dll) prenant en charge les événements d’ouverture de session pour les ordinateurs d’un domaine. L’ouverture de session en réseau est traitée comme une ouverture de session interactive, avec au préalable l’ouverture d’un canal sécurisé vers un contrôleur de domaine.
      • SAM database, Base de données SAM. Base de données qui, sur les systèmes ne faisant pas office de contrôleurs de domaine, contient les noms des utilisateurs et des groupes locaux, avec leurs mots de passe, leurs identifiants de sécurité et leurs attributs. Elle est située dans le registre, sous HKEY_LOCAL_MACHINE\SAM, dont l’accès est protégé.
      • Security Accounts Manager, Service SAM. Ensemble de contrôles et de routines chargés de gérer la base de données des comptes locaux. La base de données SAM (pour Security Account Manager) est l’un des composants du Registre. Le service SAM (pour Security Accounts Manager, avec un s à Account)(Samsrv.dll) est exécuté dans le processus LSASS.EXE.
      • Authentication Package, (msv1_0.dll et Kerberos.dll) exécutée dans le contexte du processus LSASS, qui implémente la stratégie d’authentification de Windows. Cette DLL est chargée de vérifier les informations d’identification fournies pour l’ouverture de session et de retourner le résultat à l’autorité concernée, en l’occurrence le processus Winlogon.

 

source : <http://ntoskrnl.org/>

 

 


3 Mémoire d’authentification


Mémoire du processus LSASS

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, 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 :cerveau cpu electronic

  • Tickets Kerberos (tickets TGT, tickets de service), Texte en clair chiffré réversible, Hachage NT et Hachage LM, relation d’approbation

 

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é

 

Secrets d’autorité de sécurité locale (LSA) sur le lecteur de disque dur

Un secret LSA est une donnée secrète qui est accessible uniquement aux processus du compte SYSTÈME. disque dur ouvert

 

Certaines 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 de compte utilisé pour le compte 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

 

Base de données AD DS (NTDS.DIT)

Accessible en écriture : Chaque contrôleur de domaine accessible en écriture dans le domaine contient une copie complète de la base de données AD DS du domaine, qui comprend les informations d’identification de tous les comptes inclus dans le domaine.base de donnée

 

En lecture seule  : Les contrôleurs de domaine en lecture seule (RODC) hébergent un réplica local partiel avec les informations d’identification pour un sous-ensemble sélectionné des comptes dans le domaine.

 

La base de données stocke plusieurs attributs pour chaque compte, y compris les types des noms d’utilisateur et les informations suivantes :

  • Hachage NT du mot de passe actuel
  • Hachages NT pour l’historique des mots de passe (configuré à 11 mots de passe à la DMF soit 11 hachages NT )

 

Magasin du Gestionnaire d’informations d’identification

Les utilisateurs peuvent choisir d’enregistrer les mots de passe dans Windows en utilisant une application ou via l’applet Gestionnaire d’informations d’identification du Panneau de configuration.

Ces informations d’identification sont stockées sur le lecteur de disque dur et protégées par l’interface DPAPI (Data Protection Application Programming Interface).

Tout programme s’exécutant sous l’identité de cet utilisateur est en mesure d’accéder aux informations d’identification incluses dans ce magasin.

Le Gestionnaire d’informations d’identification peut obtenir ses informations de deux manières :

Création explicite   Quand les utilisateurs entrent un nom d’utilisateur et un mot de passe pour un domaine ou un ordinateur cible, ces informations sont stockées et utilisées quand les utilisateurs tentent d’ouvrir une session sur un ordinateur approprié.

Si aucune information stockée n’est disponible et que les utilisateurs fournissent un nom d’utilisateur et un mot de passe, ils peuvent enregistrer ces informations. Si l’utilisateur décide d’enregistrer ces informations, le Gestionnaire d’informations d’identification les reçoit et les stocke.

Remplissage par le système   Quand le système d’exploitation tente de se connecter à un nouvel ordinateur dans le réseau, il fournit le nom d’utilisateur et le mot de passe actuels à cet ordinateur. Si cela ne suffit pas à permettre l’accès, le Gestionnaire d’informations d’identification tente de fournir le nom d’utilisateur et le mot de passe nécessaires. Tous les noms d’utilisateur et mots de passe stockés sont examinés, du plus spécifique au moins spécifique en fonction de la ressource, et le système tente d’établir la connexion dans l’ordre de ces noms d’utilisateur et mots de passe. Comme les noms d’utilisateur et les mots de passe sont lus et appliqués dans l’ordre, du plus spécifique au moins spécifique, pas plus d’un nom d’utilisateur et d’un mot de passe ne peuvent être stockés pour chaque domaine ou cible.

Le Gestionnaire d’informations d’identification utilise le stockage sécurisé des informations d’identification, auparavant appelé Coffre Windows, pour le stockage sécurisé des noms d’utilisateur et des mots de passe.

Sources : https://technet.microsoft.com/fr-fr/library/hh994565(v=ws.11).aspx

 

 


4 Schéma du processus d’authentification


 

 

 

Cinématique d’authentification Kerberos simplifié entre domaine

logo2 itconsult

Laisser un commentaire