L’authentification dans Active Directory : comment ça marche ?

Chaque entreprise possède sa structure propre, qui se décline généralement en services (ventes, marketing, IT, par exemple). Dans l’optique de préserver la productivité des utilisateurs sans manquer aux obligations réglementaires et de confidentialité, il est essentiel de contrôler l’accès aux ressources de l’entreprise. L’authentification Active Directory est couramment utilisée pour gérer l’accès des utilisateurs aux applications et autres ressources.

Cette approche simplifie l’administration et améliore la sécurité. Cependant, gérer le cycle de vie des identités manuellement au sein Active Directory peut poser des difficultés aux entreprises modernes ayant recours au télétravail, qui augmente potentiellement la surface d’attaque.

Ce guide explique les mécanismes sous-jacents à l’authentification Active Directory (AD) sur site et montre comment UserLock se superpose aux processus d’authentification existants d’AD en vue d’améliorer l’efficacité, l’interopérabilité et la sécurité de la solution.

En termes d’infrastructure, le système fait appel à différents protocoles d’authentification pour vérifier l’identité des utilisateurs et leur accorder l’accès à un domaine. Par exemple : LM, NTML, NTMLv2, Kerberos ou LDAP.

L’authentification Active Directory sur site est un système Windows qui authentifie et autorise l’accès des utilisateurs, terminaux et services à la solution Active Directory sur site. Les équipes informatiques s’appuient sur l’authentification AD pour rationaliser la gestion des utilisateurs et des droits et centraliser le contrôle des machines et des utilisateurs à l’aide de politiques de groupe AD.

Remarque : on confond souvent l’authentification Active Directory sur site, dont il est question ici, avec l’authentification Microsoft Entra ID. Entra ID utilise le système d’authentification OpenID Connect, qui n’est pas concerné par cet article.

L’authentification Active Directory sur site prouve que les personnes qui se connectent à Active Directory sont bien qui elles prétendent être. La première étape de ce processus consiste à vérifier une combinaison nom d’utilisateur/mot de passe (via les identifiants Windows).

À l’inverse, l’autorisation Active Directory consiste à octroyer un droit d’accès à une personne déjà authentifiée. Parfois abrégée en « AuthZ », elle précise les données et les actions accessibles à cette personne. Microsoft utilise OAuth 2.0 à des fins d’autorisation, c’est-à-dire pour attribuer le bon niveau d’accès aux personnes une fois leur identité validée.

Alors que l’authentification confirme l’identité d’un utilisateur, l’autorisation détermine ce qu’il a le droit de faire. L’authentification précède l’autorisation pour éviter tout accès non autorisé. La procédure est similaire lorsque vous présentez votre pièce d’identité à l’aéroport : on commence par contrôler votre identité (en confirmant que les informations sont correctes), avant de vous autoriser à passer.

Windows NT LAN Manager (NTLM) est un protocole d’authentification challenge-response utilisé pour authentifier un client auprès du système Active Directory sur site. Le protocole NTLM transmet des valeurs hachées et des réponses chiffrées à Active Directory, mais le mot de passe lui-même n’est jamais directement transmis sur le réseau. Grâce au hachage et au chiffrement des données, un éventuel assaillant aura beaucoup plus de mal à intercepter et à récupérer le mot de passe d’origine. Toutefois, il convient de remarquer que l’on considère NTLM comme moins sûr que certains protocoles modernes comme Kerberos, principalement du fait de vulnérabilités dans les mécanismes de hachage et de la possibilité de mener des attaques par force brute ou de type « pass-the-hash ».

Le Centre Kerberos de distribution des clés (KDC), qui fait partie des services de domaine Active Directory (AD DS) au niveau du contrôleur de domaine, génère des tickets. Lorsqu’un utilisateur se connecte, le client émet une demande de ticket auprès du KDC en chiffrant la requête à l’aide du mot de passe de l’utilisateur.

Si le KDC est en mesure de la déchiffrer à l’aide du mot de passe utilisateur connu, il crée un ticket d’octroi de tickets (TGT) chiffré à l’aide du même mot de passe et le renvoie au client.

Le client présente le ticket de service au serveur applicatif, en le déchiffrant à l’aide de son propre hachage de mot de passe. Si l’opération réussit, le serveur accorde l’accès.

Toutefois, Kerberos fait lui aussi l’objet de quelques réserves en matière de sécurité. Il dépend d’une synchronisation dans le temps entre le client et le serveur. Ainsi, il est vulnérable aux attaques par rejeu si les horloges viennent à se désynchroniser. Dans ce cas, si un attaquant parvient à compromettre le KDC, il peut générer de faux tickets et obtenir un accès non autorisé.

Active Directory prend également en charge le protocole LDAP (Lightweight Directory Access Protocol) pour les recherches d’annuaire, qu’on utilise souvent en complément de Kerberos. Active Directory utilise le protocole LDAP pour échanger des informations avec les services d’annuaire et se connecter à des applications extérieures au réseau.

L’authentification par le protocole LDAP s’effectue selon deux grands mécanismes d’authentification : l’authentification simple et la couche d’authentification et de sécurité simple (SASL) L’authentification simple requiert une approche anonyme sans authentification ou par combinaison nom/mot de passe. Généralement, elle envoie une requête BIND nom/mot de passe au serveur.

La structure SASL ajoute une couche de sécurité supplémentaire en exploitant un autre service, tel que Kerberos, à des fins d’authentification. LDAP transmet une requête BIND au serveur d’annuaire, qui vérifie alors les identifiants du client et octroie l’accès si ces derniers sont valides.

Néanmoins, le protocole LDAP présente certaines limites et faiblesses dans le contexte d’Active Directory : le trafic LDAP est bien souvent non chiffré, ce qui l’expose aux techniques d’espionnage et au attaques par phishing. Par ailleurs, il ne prend pas en charge l’authentification multifacteur (MFA) de manière native, ce qui peut poser un risque de sécurité.

Dans le cadre des scénarios de connexion ou d’authentification système, les fournisseurs d’identifiants ont eux aussi un rôle à jouer dans l’authentification Active Directory. Depuis Windows 10 et Microsoft Passport, le rôle des fournisseurs d’identifiants est devenu prépondérant pour authentifier les utilisateurs auprès des applications, des sites web et bien plus encore.

Le fournisseur d’identifiants installé sur les serveurs d’applications propose des outils de CLI ou d’API natifs permettant de récupérer les mots de passe sur diverses plateformes, comme Java, C/C++ ou NET. Il évite de devoir coder les identifiants en dur dans les applications et les scripts.

Pour empêcher les vols d’identifiants, le fournisseur d’identifiants intègre des mécanismes anti-falsification qui authentifient les applications au moment de l’exécution. Cette fonction, qui s’installe sur chaque serveur, met en cache local les identifiants afin d’en optimiser les performances et la disponibilité.

Avec l’authentification Active Directory, les administrateurs contrôlent de manière centralisée l’accès, les machines et les ressources liées au compte utilisateur Active Directory. Ils peuvent également créer/modifier/désactiver les comptes utilisateurs, déployer des logiciels, configurer plusieurs ordinateurs simultanément et réaliser des opérations de dépannage à distance.

Les administrateurs Active Directory gèrent facilement les ressources telles que les fichiers, les applications et le matériel par l’intermédiaire des services de domaine AD. AD permet de gérer les utilisateurs, les ordinateurs et d’autres ressources à partir d’une interface unique, ce qui simplifie le suivi et la maintenance réseau tout en réalisant des économies de temps et de ressources.

L’authentification Active Directory fournit un point unique pour la gestion des ressources réseau. Elle utilise l’authentification unique (SSO), qui octroie l’accès à toutes les ressources du serveur du domaine après authentification.

Une fois qu’Active Directory a identifié et authentifié un utilisateur, la procédure est terminée. Par la suite, l’utilisateur n’a plus qu’à s’identifier une fois pour accéder aux ressources réseau autorisées en fonction de son rôle AD et de ses privilèges.

Avec UserLock, la fonctionnalité d’authentification unique (SSO) est intégrée à l’authentification AD. Avec un seul jeu d’identifiants, les utilisateurs accèdent à de multiples ressources. Cette approche permet de gagner du temps, d’améliorer la productivité et de limiter le risque que les utilisateurs oublient leur mot de passe ou utilisent des mots de passe faibles.

L’authentification Active Directory permet de publier des fichiers et des ressources d’impression sur le réseau, simplifiant l’allocation des ressources. Pour y accéder en toute sécurité, il suffit aux utilisateurs de rechercher l’objet souhaité dans la base de données Active Directory.

Hautement évolutif, Active Directory prend en charge des milliers d’utilisateurs et de machines. À mesure que votre entreprise grandit, Active Directory évolue pour s’adapter aux besoins de l’organisation. Le système prend également en charge plusieurs domaines et forêts, ce qui permet de gérer efficacement les ressources sur l’ensemble des sites et des unités opérationnelles.

Grâce à l’authentification Active Directory sur site, l’authentification multifacteur de UserLock reste aussi sur site. On désigne par cette expression l’hébergement des systèmes et processus d’authentification au sein de l’infrastructure de l’entreprise, que complètent le déploiement et la gestion des serveurs d’authentification sur site. Les entreprises gardent ainsi le contrôle de leurs données d’authentification, pour une sécurité sur-mesure et une conformité réglementaire à toute épreuve.

L’authentification sur site permet de contrôler et de superviser directement les systèmes d’authentification. Il est ainsi possible de réagir aux incidents, de déployer des mises à jour et d’appliquer les politiques particulièrement rapidement. Toutefois, cette approche requiert d’investir dans l’infrastructure nécessaire : serveurs, matériel et ressources IT, etc. Ce qui représente un coût initial supérieur à l’authentification cloud.

L’authentification Active Directory excelle dans le rôle de service d’annuaire dans les environnements Windows. Son intégration est en revanche bien moins performante avec les plateformes non-Windows telles que MacOS, Linux ou Unix. La gestion des environnements IT hétérogènes peut donc s’avérer plus difficile.

Les administrateurs ont la possibilité d’avoir recours aux politiques de groupe pour contrôler plusieurs ordinateurs et appliquer des instructions au groupe. Cependant, ils ne peuvent déployer ni appliquer de politiques AD sur les machines Mac et Linux sans faire appel à des outils tiers ou à des scripts personnalisés, qui introduisent souvent des incohérences et des lacunes de sécurité.

Active Directory est particulièrement adapté aux architectures sur site traditionnelles et aux applications métier Microsoft. C’est moins le cas pour les entreprises qui utilisent des solutions cloud non-Microsoft et doivent prendre en charge des utilisateurs distants.

À l’heure où les entreprises adoptent de plus en plus les services cloud et les environnements hybrides, l’authentification Active Directory peut se retrouver confronté à de nouvelles difficultés lorsqu’il s’agira d’étendre ses fonctionnalités à ces nouveaux environnements. Les services cloud disposent généralement de leurs propres services de gestion des identités et des accès. Les entreprises doivent s’assurer que l’intégration des différents systèmes et mécanismes d’authentification aux différents environnements se fait de façon sûre et rigoureuse afin d’éviter les attaques sur les identités.

L’authentification Active Directory impose souvent le recours à diverses solutions de contournement, qui s’accompagnent du déploiement de multiples outils informatiques. L’annuaire finit par s’étendre à l’excès, ce qui entraîne une augmentation des coûts, de la complexité réseau et des problèmes de gestion. Des problèmes de compatibilité peuvent se manifester au moment d’intégrer des outils tiers à AD ou entre eux. Conséquence de cette expansion de l’annuaire, les administrateurs doivent se former à chaque outil, ce qui rallonge la courbe d’apprentissage et augmente les coûts globaux.