Sécurité multiplateforme

Prise en charge complète : Windows, UNIX, et Active Directory

Cet article est adapté du Guide de solutions Microsoft pour les services de sécurité et d'annuaire Windows pour UNIX , disponible sur le site Web TechNet.

Savez-vous que grâce à Active Directory, vous disposez d'une sécurité centralisée et d'une fonctionnalité d'annuaire pour les environnements mixtes, y compris ceux comprenant des postes UNIX ? Découvrez ce dont vous avez besoin pour bénéficier de la fonctionnalité d'authentification unique que vous attendiez pour votre environnement hétérogène.

Sur cette page

Services d'annuaire et gestion d'identité
Présentation de Kerberos 4
Passage de X.500 à LDAP
Présentation du service d'annuaire LDAP
Modèle d'information
Modèle de nommage
Modèle fonctionnel
Modèle de sécurité
Format d'échange LDAP
Utilisation du protocole LDAP pour l'authentification réseau
Microsoft Active Directory
Vintela Authentication Services
Résumé
Peter Larsen
Jason Zions

L'émergence des systèmes connectés dans le monde a fait naître un nouveau problème. Comment les organisations et les partenaires stockent-ils les données sensibles en environnements hétérogènes, et comment vérifient-ils l'identité des utilisateurs sollicitant des informations sur les différentes plateformes ?

Les utilisateurs finaux, tout comme les organisations, souhaitent que leurs solutions de sécurité intègrent trois aspects : confidentialité, intégrité et disponibilité. Lors de l'authentification d'un utilisateur, le processus peut utiliser des méthodes diverses, telles que des mots de passe (informations), des cartes à puce (objets) ou encore un procédé biométrique, une combinaison de ces techniques étant la solution idéale. Lorsque vous êtes responsable d'un site utilisant différents serveurs Windows®, UNIX et Linux, vous pouvez bénéficier de tous ces aspects et méthodes en optant pour les protocoles Kerberos et LDAP.

Services d'annuaire et gestion d'identité

Active Directory®, disponible avec Windows Server™ 2003, offre les bases de la gestion d'identité, couvrant les informations liées aux individus. La gestion d'identité comprend la gestion des comptes d'utilisateurs des ordinateurs, les informations de contact correspondantes, les comptes d'utilisateurs du système d'ouverture de porte, les comptes d'utilisateurs des applications, les adresses et comptes d'utilisateurs du système de messagerie électronique, etc.

La gestion d'identité résout les problèmes de gestion de ces informations. Les informations sur les individus sont stockées à un emplacement spécifique et administrées de façon cohérente. La norme LDAP évoquée plus bas définit un service d'annuaire pouvant être utilisé comme base des solutions de gestion d'identité.

Présentation de Kerberos 4

Le protocole Kerberos est une norme conçue pour fournir une authentification forte au sein d'un environnement de réseau client/serveur. Les messages réseau Kerberos sont cryptés et décryptés à l'aide d'algorithmes qui convertissent les données Kerberos dans une forme très complexe à décoder dans sa forme d'origine. Une clé de cryptage secrète est utilisée pour crypter et décrypter les données. Kerberos utilise également des techniques mathématiques appelées hachages, garantissant l'intégrité de toutes les données non cryptées.

Il est primordial de connaître certains termes et concepts de Kerberos 4.

Entités Les entités de Kerberos comprennent notamment les utilisateurs, les ordinateurs et les services. Les noms des entités sont uniques. Cet aspect est garanti par une structure de noms hiérarchique.

Domaines L'entité est membre d'un domaine. Par convention, le nom de domaine est le nom DNS converti en majuscules. Par exemple, le domaine exemple.com devient EXEMPLE.COM. Les domaines ne doivent pas nécessairement être convertis en majuscules. Ceci permet cependant de les différencier des domaines classiques.

Ticket Un ticket constitue l'unité de base de l'authentification Kerberos. Il s'agit d'un message minutieusement structuré contenant les informations d'authentification, que les ordinateurs s'échangent.

Centre de distribution de clés Le centre de distribution de clés (KDC, Key Distribution Center) se compose de trois éléments : une base de données d'entités contenant des utilisateurs, des ordinateurs et des services ; un serveur d'authentification qui émet des tickets d'accord de ticket (TGT, Ticket Granting Tickets) ; et un service d'accord de ticket (TGS, Ticket Granting Service) qui émet des tickets de service accordant aux clients l'accès à des services spécifiques.

Chaque domaine nécessite au moins un KDC pour être opérationnel. L'authentification Kerberos repose sur l'utilisation de tickets échangés entre le client, le KDC et le serveur requis pour confirmer l'authentification et l'autorisation.

La figure 1 illustre les échanges ayant lieu lors de l'authentification avec le protocole Kerberos.

Initialement, un client contacte le composant du serveur d'authentification du KDC, en envoyant une demande contenant le nom de l'entité, un cachet de date, la durée de vie du ticket demandé par le client et le nom du TGS.

En retour, le serveur d'authentification génère une clé de session et en fait deux copies : une pour le client, l'autre pour le TGS. Le serveur d'authentification renvoie un TGT au client. Ce TGT contient une copie de la clé de session, l'identité du client, un cachet de date, les détails de l'adresse IP du client, ainsi que la durée de vie du ticket.

Lorsque le serveur d'authentification retourne le TGT au client, il retourne également une copie de la clé de session, le nom de l'entité du TGS, ainsi que la durée de vie du ticket. L'ensemble de la réponse adressée au client est cryptée à l'aide de la clé du client.

Le client reçoit les informations dans la réponse cryptée. Il est alors en mesure de les décrypter puisque la réponse a été cryptée avec sa clé. Le client obtient ainsi sa clé de session, ainsi qu'un TGT toujours crypté par la clé du TGS.

Le client transfère alors le TGT au serveur d'accord de ticket, avec une demande concernant le service auquel il souhaite accéder et un cachet de date crypté avec la clé de session obtenue du serveur d'authentification. Le cachet de date permet de prévenir les attaques répétées se produisant lorsqu'une demande de service émanant du client est interceptée par un pirate, puis à nouveau envoyée ultérieurement. Le TGS traite cette demande et répond avec un nouveau jeu de clés de session, le nom de l'entité du service demandé, la durée de vie du ticket et un ticket de service crypté avec la clé de service.

Le ticket de service est similaire au TGT. Il contient une nouvelle clé de session, le nom d'entité du client, la durée de vie du ticket, un cachet de date et l'adresse IP du client. Toutes ces informations sont ensuite cryptées avec la clé du client, puis elles sont envoyées.

La dernière étape de la procédure d'authentification diffère selon le service et le serveur demandés. En effet, chaque application définit ses propres méthodes d'échange du ticket de service.

Le système de fichiers NFS (Network File System) est un exemple de service. Il permet à un hôte d'accéder (« monter ») à des annuaires sur un serveur distant. Cet accès peut être contrôlé par Kerberos.

Kerberos 5 est une extension de Kerberos 4. Il contient toutes les fonctionnalités de la version précédente, ainsi que de nombreuses améliorations, notamment la prise en charge du transfert d'informations d'identification, de plusieurs types de cryptage, des tickets renouvelables et de la pré-authentification. Kerberos 5 est la méthode d'authentification réseau utilisée par défaut pour les services et applications Windows Server 2003.

Le protocole Kerberos est distribué sous une multitude de formes, notamment dans une version commerciale et sous forme de logiciel ouvert. La plupart des versions principales d'UNIX incluent l'implémentation de Kerberos au sein de l'installation standard. Deux versions de Kerberos 5 sous forme de logiciel ouvert sont distribuées : MIT et Heimdal. Pour plus d'informations sur la version Heimdal, consultez le site Internet Heimdal (en anglais).

La version MIT de Kerberos peut être compilée très simplement sur toutes les plateformes et fonctionne avec toutes les autres implémentations. Vous pouvez télécharger des versions précompilées auprès d'autres sources. Dans ce cas, il est cependant recommandé de vérifier l'intégrité de la source afin de garantir une sécurité optimale. La version MIT de Kerberos peut être téléchargée via le site Internet Kerberos: The Network Authentication Protocol (en anglais).

Certains pays imposent des restrictions concernant l'utilisation de la cryptographie. Assurez-vous que Kerberos est conforme aux réglementations de votre pays avant d'implémenter une solution Kerberos.

Passage de X.500 à LDAP

La norme LDAP est utilisée pour les services d'authentification et d'annuaire, et a évolué vers une méthode d'accès simple à X.500. La norme X.500 a été conçue pour permettre la mise en place d'un annuaire distribué mondial avec une interface d'accès standard. Elle est extrêmement complexe, à l'instar des protocoles réseau OSI (Open System Interconnection) auxquels elle est destinée. En fait, les protocoles réseau OSI sont beaucoup plus complexes que les protocoles les plus répandus de la suite TCP/IP.

LDAPv3 est implémenté dans de nombreux systèmes d'exploitation, systèmes d'exploitation réseau, services d'annuaire, applications telles que les serveurs de messagerie, et applications clientes. LDAPv3 est un composant central de Windows Server 2003 Active Directory. L'implémentation de LDAPv3, disponible avec Active Directory, est entièrement intégrée avec un système de sécurité conforme aux normes, basé sur Kerberos et Microsoft? Windows.

Présentation du service d'annuaire LDAP

Protocole standard d'accès aux annuaires, LDAP définit les opérations permettant de communiquer avec un service d'annuaire, la façon de faire référence à une entité de l'annuaire, la façon de décrire les attributs d'une entité, ainsi que les fonctionnalités de sécurité utilisées pour l'authentification auprès de l'annuaire et pour contrôler l'accès aux entités de l'annuaire. LDAP se caractérise par les aspects suivants : Le protocole est directement transféré par TCP pour un transport orienté connexion (accusé de réception des données) et par le protocole UDP (User Datagram Protocol) pour le transport sans connexion (pas d'accusé de réception à l'envoi ou à la réception des données).La plupart des éléments de données de protocole, tels que les noms uniques, peuvent être codés sous forme de chaînes classiques.Les références à d'autres serveurs peuvent être retournées au client.Les mécanismes SASL (Simple Authentication and Security Layer) peuvent être utilisés avec LDAP de façon à fournir les services de sécurité associés.Les valeurs des attributs et les noms uniques peuvent être internationalisés via l'utilisation du jeu de caractères ISO 10646.Le protocole peut être étendu pour prendre en charge de nouvelles opérations, et des contrôles peuvent être utilisés pour développer les opérations existantes.Le schéma est alors publié via un attribut sur l'objet racine, pour permettre une utilisation par les clients.

Les modèles de composants définis dans le protocole LDAP sont les mêmes que ceux définis dans X.500. Ils sont expliqués dans les sections suivantes.

Modèle d'information

Les attributs et caractéristiques associés à une entrée sont définis dans les classes d'objets de l'entrée. La définition des attributs et classes d'objets est, quant à elle, conservée dans le schéma. Les trois types de classes d'objets utilisées dans les serveurs d'annuaire LDAP sont définis ci-dessous :

Classe d'objet structurelle Une classe d'objet structurelle représente un objet du monde réel, par exemple, un individu. Une entité doit appartenir à une seule et unique classe d'objet structurelle.

Classe d'objet auxiliaire Une classe d'objet auxiliaire est utilisée pour étendre une classe d'objet structurelle. Elle ne présente pas d'intérêt spécifique en elle-même.

Classe d'objet résumée La classe d'objet résumée est utilisée uniquement lorsqu'il s'agit de l'ancêtre d'une classe dérivée.

Modèle de nommage

Le modèle de nommage définit le mode de référencement de chaque entrée. Dans un annuaire LDAP, les entrées sont organisées dans une arborescence hiérarchique appelée arborescence d'information d'annuaire (DIT, Directory Information Tree). Chaque nœud de l'arborescence constitue une entrée pouvant stocker des informations et sert également de conteneur pour d'autres entrées. Une entrée de l'arborescence peut être référencée par l'utilisation de son nom unique relatif (RDN) ou de son nom unique (DN). Un nom unique relatif est unique au sein d'un annuaire spécifique seulement ; un nom unique est unique de façon globale.

Le nom unique relatif d'un attribut peut être le nom commun (cn) d'un objet, comme dans cet attribut : cn="Michael Allen"

Un nom unique relatif peut également être constitué de plusieurs valeurs d'attribut lorsque l'utilisation d'un seul attribut ne suffit pas pour assurer son caractère unique. Par exemple : cn="Michael Allen"+ou="Engineering"

Dans cet exemple, le symbole plus (+) indique clairement que le nom unique relatif possède plusieurs valeurs. Les noms uniques relatifs possédant plusieurs valeurs s'avèrent très pratiques, notamment lorsque deux employés nommés Michael Allen font partie de votre organisation. S'ils travaillent dans des services distincts, ils peuvent posséder des noms uniques relatifs qui sont uniques au sein d'un service, comme défini dans l'exemple par l'attribut d'unité d'organisation (ou). Le nom unique de l'entrée Michael Allen peut être le suivant : cn="Michael Allen",dc="example",dc="com"

Dans ce cas, l'objet est défini de façon unique dans l'annuaire local et de façon globale. Les valeurs de l'attribut de composant de domaine (dc) sont utilisées pour définir de façon unique le nom de domaine DNS du serveur d'annuaire.

Dans le protocole LDAP, le contexte d'appellation d'un annuaire peut être défini selon un format géographique ou relatif au nom de domaine. Le format géographique était à l'origine la principale méthode de localisation d'un annuaire dans X.500, et est toujours utilisé avec les serveurs LDAP. Cependant, le nom de domaine d'un serveur LDAP est fréquemment utilisé comme contexte d'appellation, car les noms de domaine sont globalement uniques sur Internet.

Dans la figure 2, le contexte d'appellation du serveur d'annuaire est le nom de domaine exemple.com ou le DN dc=exemple, dc=com. Le nom unique utilise ou="Utilisateurs" et non cn="Utilisateurs". Dans ce cas, cn et ou sont interchangeables car le nom et le nom commun de l'unité d'organisation sont identiques.

Modèle fonctionnel

Le modèle fonctionnel est la méthode de communication d'un client avec l'annuaire. Ce rôle est assuré par le protocole LDAP lui-même. LDAP assure les opérations suivantes : Interrogation : recherche dans l'annuaireModification : mise à jour, ajout ou suppression d'entrées de l'annuaireAuthentification et contrôle : authentification auprès de l'annuaire (ou opération de liaison)

Modèle de sécurité

Le modèle de sécurité fournit des méthodes d'authentification auprès de l'annuaire et d'autorisation du contrôle d'accès client à l'annuaire. Le modèle de sécurité comprend deux éléments : l'authentification à l'aide des liaisons LDAP et le contrôle de tout accès aux objets de l'annuaire.

Les détails de l'authentification via LDAP seront expliqués plus loin dans cet article. Cependant, une fois authentifié, le client peut utiliser l'annuaire LDAP uniquement tel que défini par les listes de contrôle d'accès (ACL, Access Control List) de l'annuaire. L'utilisation des listes de contrôle d'accès dans un annuaire LDAP dépend de l'implémentation.

Format d'échange LDAP

Les annuaires LDAP peuvent échanger des définitions de données et de schémas à l'aide d'une notation standard nommée LDIF (LDAP Interchange Format). Le format LDIF se présente sous la forme d'un fichier texte comprenant les éléments suivants : Entrées séparées par des lignes vides, représentant une entité uniqueCommentaires commençant par le caractère dièse (#)Affectation de valeurs aux attributsDirectives informant l'analyseur LDIF du mode d'interprétation des entrées

L'exemple suivant illustre un fichier LDIF indiquant la définition d'une entité représentant un individu. Ce fichier LDIF peut être utilisé pour créer l'entité dans un annuaire LDAP : # This is a comment dn: cn=Michael Allen,cn=Users,dc=example,dc=com objectClass: person cn: Michael Allen sn: Reid telephoneNumber: 555-0100 La dernière ligne est vide. Ce fichier définit une entité avec le nom unique : cn=Michael Allen,cn=Users,dc=example,dc=com L'entrée est membre de la classe d'objet « person » (individu), qui contient des attributs tels que le nom commun (cn) d'un individu, son nom (sn) et son numéro de téléphone (telephoneNumber).

Utilisation du protocole LDAP pour l'authentification réseau

L'authentification LDAP implique la liaison d'une entité à un serveur LDAP. Le succès de l'opération de liaison dépend de l'acceptation ou du refus des informations d'identification de l'entité. L'entité est authentifiée uniquement si la liaison réussit.

Pour que le protocole LDAP puisse être utilisé pour une connexion UNIX et Linux ou l'authentification du service, il doit être combiné au module PAM (Pluggable Authentication Module) LDAP.

Contrairement à Kerberos, conçu comme un mécanisme d'authentification, l'authentification LDAP est conçue spécifiquement pour sécuriser les transactions d'annuaire. L'utilisation de l'authentification LDAP à des fins autres que l'accès à des annuaires LDAP peut engendrer des problèmes de performances. En effet, les services d'annuaire LDAP ne sont pas conçus pour gérer un grand nombre de demandes d'authentification, mais plutôt pour gérer correctement les transactions d'annuaire.

Microsoft Active Directory

Active Directory est un composant essentiel et indissociable de l'architecture réseau, qui améliore l'architecture de domaine du système d'exploitation Windows NT? 4.0 dans le but de fournir un service d'annuaire conçu pour les environnements réseau distribués. Lancé avec Windows 2000, Active Directory fait partie intégrante de Windows Server 2003.

Active Directory s'articule autour des protocoles Kerberos 5 et LDAPv3 et est donc compatible avec les clients Kerberos 5 et LDAPv3 sur toutes les plateformes. Les serveurs Windows Active Directory peuvent ainsi fournir des services d'annuaire et de sécurité dans un réseau hétérogène.

Grâce à la combinaison de ces technologies, les organisations peuvent appliquer des règles métier normalisées aux applications et ressources réseau distribuées sans intervention de la part des administrateurs pour gérer différents annuaires spécialisés. Active Directory est présenté dans la figure 3.

Vintela Authentication Services

Tout comme Active Directory, les systèmes UNIX et Linux incluent généralement leurs propres implémentations de Kerberos et LDAP. Même si ces implémentations peuvent interagir avec Active Directory, elles sont généralement réalisées indépendamment de la façon dont Microsoft a intégré ces deux normes dans Active Directory.

Vintela Authentication Services (VAS) implémente les fonctionnalités Kerberos et LDAP sur les systèmes UNIX et Linux, et s'intègre parfaitement à Active Directory. L'utilisation de VAS offre les avantages suivants : Vous pouvez gérer UNIX, et les utilisateurs et ordinateurs Linux sont gérés via le composant logiciel enfichable Microsoft Management Console (MMC) Utilisateurs et ordinateurs Active Directory.Kerberos est le protocole utilisé pour sécuriser le trafic LDAP.Les performances sont définies pour un fonctionnement efficace avec Active Directory.

Le produit VAS permet aux clients UNIX et Linux de fonctionner au sein d'un domaine Active Directory d'une façon similaire aux clients Windows.

Références

Le guide détaillé complet « Guide de solutions Microsoft pour les services de sécurité et d'annuaire Windows pour Unix » est disponible sur le site Web TechNet.

Pour plus d'informations sur les arborescences des identificateurs d'objets (OID, Object ID), consultez le site Web Internet Assigned Numbers Authority (en anglais).

Recherchez l'entrée « Enterprise Numbers » sous la lettre « E ».

Les documents RFC (Requests for Comments) suivants décrivent le protocole LDAP (Lightweight Directory Access Protocol), la représentation des attributs standard au sein de LDAP et les relations entre LDAP et X.500, norme internationale de fourniture de services d'annuaire en ligne :

• RFC 1777 , « Lightweight Directory Access Protocol »

• RFC 1778 , « The String Representation of Standard Attribute Syntaxes »

• RFC 1779 , « A String Representation of Distinguished Names »

• RFC 2247 , « Using Domains in LDAP/X.500 Distinguished Names »

• RFC 2251 , « Lightweight Directory Access Protocol (v3) »

• RFC 2252 , « Attribute Syntax Definitions »

• RFC 2253 , « UTF-8 String Representation of Distinguished Names »

• RFC 2254 , « A String Representation of LDAP Search Filters »

• RFC 2255 , « The LDAP URL Format »

• RFC 2256 , « A Summary of the X.500(96) User Schema for use with LDAPv3 »

Les documents RFC suivants décrivent le protocole Kerberos et les méthodes d'utilisation de Kerberos avec GSSAPI (Generic Security Service Application Programming Interface) :

• RFC 1510 , « The Kerberos Network Authentication Service (Version 5) »

• RFC 1964 , « The Kerberos Version 5 GSS-API Mechanism »

Tous ces documents RFC sont disponibles sur Internet (en anglais), à l'adresse www.ietf.org/rfc.html .

Résumé

Dans cet article, nous avons décrit les technologies de base nécessaires à l'obtention d'une authentification unique entre des ordinateurs en réseau exécutant différents systèmes d'exploitation. Le guide en ligne indiqué dans les références fournit des instructions détaillées sur la configuration de l'authentification unique entre des systèmes d'exploitation tels que Linux et Windows. Ce guide décrit deux méthodes d'authentification unique : l'une à l'aide du code source ouvert et l'autre à l'aide de la version du produit Vintela disponible dans le commerce. Grâce à ces nouvelles technologies, vous pourrez assurer un accès aux informations à tout moment, à partir de n'importe quel périphérique, et sur n'importe quelle plateforme.

Peter Larsen

est développeur logiciel chez Microsoft. Avant de rejoindre Microsoft, Peter était impliqué dans l'architecture et le développement de systèmes logiciels opérationnels de télécommunication et dans la normalisation et le développement de services sans fil.

Jason Zions

est architecte chez Microsoft. C'est lorsqu'il était responsable scientifique chez Softway Systems qu'il a chapeauté le développement d'Interix, qui fut ensuite intégré à Microsoft Services For UNIX. Jason s'est également beaucoup impliqué dans la normalisation de POSIX.

Article issu de l'édition d'hiver 2005 du magazine TechNet .