Chaque organisation poss\u00e8de une structure bien d\u00e9finie qui d\u00e9finit les r\u00f4les et les responsabilit\u00e9s des employ\u00e9s dans les diff\u00e9rents d\u00e9partements tels que les ventes, le marketing et l’informatique. Afin d\u2019utiliser efficacement les ressources de l’entreprise et rester productives, les organisations doivent \u00e9laborer des mesures de contr\u00f4le d’acc\u00e8s.<\/p>\n\n\n\n
L’authentification AD est un syst\u00e8me fonctionnant sur Windows qui authentifie et autorise les utilisateurs, les terminaux et les services \u00e0 Active Directory. Les \u00e9quipes informatiques peuvent utiliser l’authentification AD pour rationaliser la gestion des utilisateurs et des droits tout en b\u00e9n\u00e9ficiant d\u2019un contr\u00f4le centralis\u00e9 des p\u00e9riph\u00e9riques et des configurations des utilisateurs gr\u00e2ce \u00e0 la fonction \u00ab Politique de groupe \u00bb d\u2019AD. <\/p>\n\n\n\n
Elle offre \u00e9galement une fonctionnalit\u00e9 d’authentification unique (SSO)<\/a>, permettant aux utilisateurs de s’authentifier une seule fois et d’acc\u00e9der ensuite de mani\u00e8re transparente \u00e0 toutes les ressources de l’entreprise dans le domaine pour lequel ils sont autoris\u00e9s. L’authentification AD succ\u00e8de \u00e0 LAN Manager (LM) et NT LAN Manager (NTLM), des protocoles qui \u00e9taient facilement exploitables.<\/p>\n\n\n\n
Active Directory est un processus qui prend en charge deux normes : Kerberos et Lightweight Directory Access Protocol (LDAP)<\/a>. <\/p>\n\n\n\n
Dans une authentification AD bas\u00e9e sur Kerberos, les utilisateurs ne se connectent qu’une seule fois pour avoir acc\u00e8s aux ressources de l’entreprise. Plut\u00f4t que de transmettre les informations de connexion sur le r\u00e9seau, comme c’est le cas avec les protocoles LM et NTLM, le syst\u00e8me Kerberos g\u00e9n\u00e8re une cl\u00e9 de session pour l’utilisateur. La cl\u00e9 de session g\u00e9n\u00e9r\u00e9e est valable pour une p\u00e9riode d\u00e9termin\u00e9e, ce qui offre une certaine souplesse aux utilisateurs en mati\u00e8re d’authentification. <\/p>\n\n\n\n
Outre la cl\u00e9 de session, le syst\u00e8me Kerberos g\u00e9n\u00e8re \u00e9galement un jeton contenant toutes les politiques et tous les droits d’acc\u00e8s associ\u00e9s \u00e0 l’utilisateur. Cela garantit que les utilisateurs n’acc\u00e8dent qu’aux ressources auxquelles ils sont autoris\u00e9s.<\/p>\n\n\n\n
Si un client veut se connecter au serveur AD ou au contr\u00f4leur de domaine (DC) dans ce cas, il doit s’authentifier aupr\u00e8s d’un centre de distribution de cl\u00e9s (KDC), qui est un tiers de confiance. Le KDC se compose de deux serveurs : le serveur d’authentification (AS) et le serveur d’octroi de tickets (TGS). Le serveur d’authentification chiffre les informations de connexion des clients en utilisant la cl\u00e9 secr\u00e8te de leur mot de passe. C’est ainsi que l’AS authentifie les clients sur le r\u00e9seau.<\/p>\n\n\n\n
Apr\u00e8s avoir authentifi\u00e9 l’utilisateur, l’AS lui envoie un ticket d’acc\u00e8s (TGT), qui est crypt\u00e9 avec une autre cl\u00e9 secr\u00e8te. Lorsque le client re\u00e7oit le TGT, il le transmet au TGS avec une demande d’autorisation pour acc\u00e9der \u00e0 la ressource cible sur le serveur. Le TGS d\u00e9chiffre alors le TGT avec sa cl\u00e9 secr\u00e8te qu’il partage avec l’AS. <\/p>\n\n\n\n
Ensuite, le TGS \u00e9met un jeton au client qu’il chiffre avec une autre cl\u00e9. La troisi\u00e8me cl\u00e9 secr\u00e8te est partag\u00e9e entre le serveur cible et le TGS. Enfin, le client transmet le jeton re\u00e7u au serveur cible. Lorsque le serveur cible re\u00e7oit le jeton, il le d\u00e9chiffre avec la cl\u00e9 partag\u00e9e par le TGS pour permettre au client d’acc\u00e9der aux ressources pendant une dur\u00e9e limit\u00e9e (session).<\/p>\n\n\n\n
LDAP est un protocole open source et multiplateforme qui fournit des services d’authentification AD. Il existe deux options associ\u00e9es \u00e0 l’authentification bas\u00e9e sur LDAP dans AD :<\/p>\n\n\n\n
AD fonctionne de mani\u00e8re transparente avec les syst\u00e8mes et services bas\u00e9s sur Windows. Celui-ci dominait peut-\u00eatre le march\u00e9 des syst\u00e8mes d’exploitation dans les ann\u00e9es 1990, mais il nous est forc\u00e9 d’admettre qu’aujourd’hui les choses ont chang\u00e9. Linux et macOS font d\u00e9sormais partie int\u00e9grante de toute infrastructure informatique. Comme les entreprises continuent \u00e0 exploiter diff\u00e9rents syst\u00e8mes d’exploitation, la pression pour fournir une gestion centralis\u00e9e des acc\u00e8s devient r\u00e9elle. <\/p>\n\n\n\n
Il existe deux m\u00e9thodes principales pouvant \u00eatre utilis\u00e9es pour connecter les appareils bas\u00e9s sur Linux \u00e0 AD.<\/p>\n\n\n\n
Cette approche exige que les \u00e9quipes informatiques reconfigurent les appareils bas\u00e9s sur Linux pour exploiter le module d’authentification enfichable (PAM) de LDAP. L’authentification AD \u00e9tant largement ax\u00e9e sur le protocole Kerberos, les \u00e9quipes informatiques doivent g\u00e9rer manuellement l’ensemble du processus d’authentification.<\/p>\n\n\n\n
Il s’agit d’un outil d’interop\u00e9rabilit\u00e9 standard de Windows pour les syst\u00e8mes Linux. Les \u00e9quipes informatiques peuvent utiliser Samba comme interm\u00e9diaire pour prendre en charge l’authentification AD dans les machines Linux. Par exemple, les \u00e9quipes informatiques peuvent utiliser le service pour cr\u00e9er des domaines, configurer un serveur d’impression partag\u00e9 et configurer PAM pour permettre aux utilisateurs de s’authentifier aupr\u00e8s des services install\u00e9s localement.<\/p>\n\n\n\n
Les \u00e9quipes informatiques peuvent utiliser un connecteur LDAP et AD<\/a> pour configurer les Macs leur permettant d’acc\u00e9der aux d\u00e9tails des comptes de base dans les infrastructures AD DS (Active Directory Domain Services). Ces outils permettent aux \u00e9quipes informatiques d’exploiter l’authentification AD pour permettre aux utilisateurs d’acc\u00e9der aux ressources de l’entreprise \u00e0 partir de leurs Macs lors du d\u00e9ploiement. Le connecteur AD peut \u00e9galement fournir un SSO f\u00e9d\u00e9r\u00e9 en mettant en correspondance les identit\u00e9s AD avec les r\u00f4les de gestion des identit\u00e9s et des acc\u00e8s (IAM) de macOS. <\/p>\n\n\n\n
Par exemple, le connecteur AD peut g\u00e9n\u00e9rer tous les attributs n\u00e9cessaires pour authentifier les appareils macOS aupr\u00e8s de l’infrastructure AD. Toutefois, les machines \u00e9quip\u00e9es de macOS 10.12 ou d’une version ult\u00e9rieure ne peuvent rejoindre un domaine AD sans services de domaine Windows Server 2008 ou plus r\u00e9cents. Pour utiliser AD sur de tels appareils, les \u00e9quipes informatiques doivent activer une cryptographie faible, ce qui met en p\u00e9ril la s\u00e9curit\u00e9 de l’organisation.<\/p>\n\n\n\n
Dans les ann\u00e9es 1990 et au d\u00e9but des ann\u00e9es 2000, la plupart des outils et des syst\u00e8mes de gestion des p\u00e9riph\u00e9riques \u00e9taient essentiellement bas\u00e9s sur des syst\u00e8mes d’exploitation Windows sur site, et l’authentification AD fonctionnait bien dans ces environnements informatiques. Cependant, le paysage actuel des syst\u00e8mes d’exploitation est de plus en plus h\u00e9t\u00e9rog\u00e8ne, avec l’apparition de plateformes Linux et macOS ainsi que d’infrastructures cloud. <\/p>\n\n\n\n
Par cons\u00e9quent, fournir des contr\u00f4les et une gestion des acc\u00e8s dans un environnement informatique h\u00e9t\u00e9rog\u00e8ne est devenu un v\u00e9ritable casse-t\u00eate pour les \u00e9quipes informatiques des entreprises. Si l’authentification AD traditionnelle permet de g\u00e9rer l’IAM, elle est loin d’\u00eatre efficace. Dans la plupart des cas, les \u00e9quipes informatiques sont contraintes d’utiliser LDAP pour authentifier les p\u00e9riph\u00e9riques Linux et macOS aupr\u00e8s d’AD, for\u00e7ant ainsi l’int\u00e9gration et la gestion d’une couche de s\u00e9curit\u00e9 suppl\u00e9mentaire.<\/p>\n\n\n\n
Essentiellement, les organisations se retrouvent avec de multiples \u00ab mini-annuaires \u00bb offrant des services d’authentification et d’autorisation plut\u00f4t qu’avec une seule plateforme d’annuaire centralis\u00e9e. Outre les syst\u00e8mes d’exploitation h\u00e9t\u00e9rog\u00e8nes, le taux d’adoption des applications SaaS (Software-as-a-Service) et d’autres services clouds est mont\u00e9 en fl\u00e8che ces derni\u00e8res ann\u00e9es.<\/p>\n\n\n\n
Cette adoption s’accompagne de son propre lot de d\u00e9fis dans le paysage IAM. Par exemple, la plupart des applications SaaS ont tendance \u00e0 \u00eatre cloisonn\u00e9es, ce qui complique leur gestion du point de vue des autorisations. De plus, l’int\u00e9gration des utilisateurs dans un environnement SaaS est longue et fastidieuse car elle implique des utilisateurs provenant de plusieurs d\u00e9partements diff\u00e9rents. <\/p>\n\n\n\n
JumpCloud est une plateforme d’annuaire cloud compl\u00e8te<\/a> que les entreprises peuvent exploiter pour pallier les insuffisances de l’authentification AD dans les environnements informatiques h\u00e9t\u00e9rog\u00e8nes. Vous pouvez utiliser la plateforme d’annuaire JumpCloud pour \u00e9tendre l’authentification AD \u00e0 pratiquement toutes les ressources informatiques de l’entreprise. Vous pouvez \u00e9galement utiliser JumpCloud pour \u00e9tendre AD au cloud ou \u00e9liminer compl\u00e8tement les DC sur site.<\/p>\n","protected":false},"excerpt":{"rendered":"