14.7 Authentification et sécurité

Cette section contient des informations sur les éléments suivants :

14.7.1 Utilisation de TLS en cas de liaison simple avec mot de passe

Le protocole SSL (Secure Socket Layer) 3.1 était à l'origine diffusé via Netscape. Le groupe de travail IETF prend possession de cette norme en mettant en oeuvre TLS (Transport Layer Security) 1.0. TLS 1.0 assure une compatibilité avec les versions précédentes de SSLv2 et v3.

TLS permet de coder les connexions dans la couche Session. Il n'est pas nécessaire d'utiliser un port codé pour obtenir une connexion TLS. Il existe une autre manière : le port 636 est le port TLS implicite et le serveur LDAP lance automatiquement une session TLS lorsqu'un client se connecte au port sécurisé.

Un client peut également se connecter au port en texte clair et utiliser ultérieurement TLS pour passer d'une connexion en clair à une connexion codée.

Pour exiger TLS en cas de liaison simple avec mot de passe :

Dans NetIQ iManager, cliquez sur le bouton Rôles et tâches .
Cliquez sur LDAP > Options LDAP > Afficher les groupes LDAP.
Cliquez sur l'objet Groupe LDAP, puis sur Informations sous l'onglet Général.
Cochez la case Exiger TLS en cas de liaison simple avec mot de passe.
Cliquez sur Appliquer, puis sur OK.

14.7.2 Démarrage et arrêt de TLS

La fonction LDAP étendue STARTTLS permet de passer d'une connexion en clair à une connexion codée. Cette mise à niveau constituait une nouveauté dans eDirectory 8.7.

Lorsque vous employez une connexion codée, c'est la totalité du paquet qui est codée. De ce fait, les analyseurs réseau (ou sniffers) sont dans l'impossibilité de diagnostiquer les données envoyées sur le réseau.

Scénario : à l'aide de STARTTLS— Vous créez une connexion en clair (sur le port 389) et effectuez quelques recherches anonymes. Toutefois, lorsque vous accédez à des données sécurisées, vous préférez lancer une session TLS. Vous exécutez donc une opération étendue STATTLS pour passer d'une connexion en clair à une connexion codée. Vos données sont alors sécurisées.

Vous arrêtez TLS pour passer d'une session codée à une session en clair. Avec les connexions en clair, la surcharge est moindre du fait qu'il n'est pas nécessaire de coder et décoder les données destinées au client et provenant de celui-ci. Les données sont donc acheminées plus rapidement. À ce stade, la connexion est rétrogradée au statut Anonymous (anonyme).

Pour vous authentifier, vous utilisez l'opération de liaison LDAP. La liaison établit votre ID en fonction des références que vous avez fournies. Lorsque vous arrêtez TLS, le service LDAP supprime les authentifications préalablement établies. Votre état d'authentification devient alors Anonyme. Par conséquent, pour passer à un autre état qu'Anonyme, vous devez de nouveau vous authentifier.

Scénario : réauthentification— Henri lance STOPTLS. Son état devient Anonyme. Pour accéder à ses fichiers sur Internet et les utiliser, Henri exécute la commande Bind, fournit ses références de connexion et, après avoir été authentifié, se remet à travailler sur ses données non codées sur Internet.

14.7.3 Configuration du serveur pour TLS

Lorsqu'une instance de session TLS est créée, un processus de reconnaissance mutuelle intervient. Le serveur et le client échangent des données. Le serveur détermine la façon dont cette reconnaissance se produit. Pour prouver qu'il est le serveur légitime, le serveur envoie toujours son certificat au client. Cette reconnaissance garantit au client que le serveur est bien celui prévu.

Pour exiger que le client établisse également sa légitimité, vous définissez une valeur sur le serveur. Il s'agit de l'attribut ldapTLSVerifyClientCertificate.

Valeur	Description
0	Inactif. Pendant un processus de reconnaissance mutuelle, le serveur fournit un certificat au client. Il n'impose jamais au client d'envoyer un certificat. Ce dernier peut utiliser le certificat ou l'ignorer. Une session sécurisée est établie.
1	Pendant le processus de reconnaissance mutuelle, le serveur fournit au client un certificat et demande à ce dernier de lui en faire parvenir un. Le client peut choisir de retourner son certificat. Le certificat du client est validé. Si le serveur ne peut pas le valider, il met fin à la connexion. Si le client n'envoie pas de certificat, le serveur maintient la connexion.
2	Pendant le processus de reconnaissance mutuelle, le serveur impose au client de lui faire parvenir un certificat. Si le client ne fournit pas de certificat ou que le certificat ne peut pas être validé, le serveur met fin à la connexion.

Valeur

Description

Inactif. Pendant un processus de reconnaissance mutuelle, le serveur fournit un certificat au client. Il n'impose jamais au client d'envoyer un certificat. Ce dernier peut utiliser le certificat ou l'ignorer. Une session sécurisée est établie.

Pendant le processus de reconnaissance mutuelle, le serveur fournit au client un certificat et demande à ce dernier de lui en faire parvenir un. Le client peut choisir de retourner son certificat. Le certificat du client est validé. Si le serveur ne peut pas le valider, il met fin à la connexion.

Si le client n'envoie pas de certificat, le serveur maintient la connexion.

Pendant le processus de reconnaissance mutuelle, le serveur impose au client de lui faire parvenir un certificat. Si le client ne fournit pas de certificat ou que le certificat ne peut pas être validé, le serveur met fin à la connexion.

Pour que le serveur puisse prendre en charge TLS, vous devez lui fournir un certificat X.509 qu'il utilisera pour établir sa légitimité.

Ce certificat est fourni automatiquement pendant l'installation d'eDirectory. C'est au cours de cette installation que des objets matériels clés sont créés dans le cadre de l'infrastructure de clés publiques (PKI) et des services NMAS (NetIQ Modular Authentication Services). La figure suivante présente ces objets dans iManager :

L'installation associe automatiquement l'un de ces certificats au serveur LDAP. Dans NetIQ iManager, l'onglet Connexions de l'objet Serveur LDAP affiche un DN. Il représente le certificat X.509. Le champ Certificat du serveur de la figure suivante illustre ce DN.

Dans NetIQ iManager, vous pouvez parcourir le système jusqu'aux certificats d'objet Matériel clé (KMO). La liste déroulante vous permet de changer de certificat. Le certificat DNS ou IP fonctionne.

Dans le cadre de la validation, le serveur doit contrôler le nom (adresse IP matérielle ou DN) qui figure dans le certificat.

Pour établir une connexion TLS, vérifiez ce qui suit :

Le serveur LDAP doit connaître l'objet Matériel clé du serveur
Vous devez vous connecter au port sécurisé ou lancer TLS après vous être connecté au port en clair.

Une fois le serveur LDAP reconfiguré, rafraîchissez-le. Reportez-vous à la Section 14.6, Rafraîchissement du serveur LDAP. iManager rafraîchit automatiquement le serveur.

14.7.4 Configuration du client pour TLS

Un client LDAP est une application (par exemple, Internet Explorer ou ICE). Il doit être en mesure de comprendre l'autorité de certification qu'emploie le serveur LDAP.

Lorsqu'un serveur est ajouté dans une arborescence eDirectory, l'installation crée par défaut :

une autorité de certification pour l'arborescence (la CA de l'arborescence) ;
un KMO à partir de la CA de l'arborescence.

Le serveur LDAP emploie ce fournisseur de certificat.

Le client doit importer un certificat dans lequel il a confiance, afin de valider la CA de l'arborescence que le serveur LDAP affirme utiliser. Cette importation est impérative pour que, lorsque le serveur envoie son certificat, le client puisse le valider et vérifier l'authenticité du serveur.

Pour pouvoir établir une connexion sécurisée, le client doit être configuré avant la connexion.

La méthode d'importation du certificat par le client diffère en fonction du type d'application utilisée. Chaque application doit avoir une méthode pour importer un certificat. Internet Explorer en a une et ICE, une autre. Ce sont des clients LDAP différents. Chaque client possède sa méthode pour localiser les certificats dans lesquels il a confiance.

14.7.5 Exportation de la racine approuvée

Vous pouvez exporter automatiquement la racine approuvée tout en acceptant le serveur de certificats.

Pour exporter manuellement la racine approuvée, reportez-vous à la section Exportation d'un certificat de racine approuvée ou d'un certificat de clé publique.

La fonctionnalité d'exportation crée le fichier indiqué. Bien qu'il soit possible de modifier le nom du fichier, il peut s'avérer utile de laisser « DNS » ou « IP » dans le nom, de manière à pouvoir reconnaître le type d'objet Matériel. Laissez également le nom du serveur.

Installez l'autorité de certification auto-assignée dans tous les navigateurs établissant des connexions LDAP sécurisées avec eDirectory.

Si vous utilisez le certificat avec des produits Microsoft (par exemple, Internet Explorer), conservez l'extension .der.

Si des applications ou des SDK requièrent le certificat, importez-le dans une base de données de certificats.

Internet Explorer 5 exporte automatiquement les certificats de racine lors d'une mise à jour de la base de registres. L'extension classique .X509 utilisée par Microsoft est indispensable.

14.7.6 Authentification auprès d'un certificat client

L'authentification mutuelle exige une session TLS et un certificat client. Le serveur et le client doivent l'un et l'autre vérifier que leur correspondant est bien l'objet qu'il prétend être. Le certificat client a été validé au niveau de la couche Transport. Toutefois, au niveau de la couche du protocole LDAP, le client est anonyme jusqu'à ce qu'il effectue une requête de liaison LDAP.

À ce stade, le client a établi son authenticité vis-à-vis du serveur, mais pas de LDAP. Si un client souhaite s'authentifier à l'aide de l'identité mentionnée dans le certificat client, il exécute une opération de liaison en utilisant le mécanisme SASL EXTERNAL.

Dans NetIQ iManager, cliquez sur le bouton Rôles et tâches .
Cliquez sur LDAP > Options LDAP.
Cliquez sur Afficher les serveurs LDAP, puis cliquez sur le nom d'un objet Serveur LDAP.
Cliquez sur Connexions.
Dans la section TLS (Transport Layer Security), sélectionnez le menu déroulant Certificat client, puis Requis.

L'authentification mutuelle est alors activée.
Cliquez sur Appliquer, puis sur OK.

14.7.7 Utilisation d'autorités de certification de fournisseurs tiers

Pendant l'installation d'eDirectory, le serveur LDAP reçoit une autorité de certification (CA) de l'arborescence. L'objet Matériel clé LDAP repose sur cette CA. Tout certificat qu'un client envoie au serveur LDAP doit pouvoir être validé via cette CA de l'arborescence.

Les services LDAP pour eDirectory prennent en charge plusieurs autorités de certification. La CA de l'arborescence de NetIQ n'est qu'une autorité de certification parmi d'autres. Le serveur LDAP peut en avoir d'autres (par exemple VeriSign*, une société externe). Ce type d'autorité de certification supplémentaire est également une racine approuvée.

Pour configurer le serveur LDAP afin qu'il utilise plusieurs autorités de certification, définissez l'attribut ldapTLSTrustedRootContainer sur l'objet Serveur LDAP. En faisant référence à plusieurs autorités de certification, le serveur LDAP permet à un client d'employer un certificat d'une autorité externe.

14.7.8 Création et emploi d'utilisateurs proxy LDAP

NetIQ eDirectory affecte l'identité [Public] aux utilisateurs qui ne sont pas authentifiés. Dans le protocole LDAP, un utilisateur non authentifié est un utilisateur anonyme. Par défaut, le serveur LDAP accorde aux utilisateurs anonymes les droits d'une identité [Public]. Grâce à ces droits, les utilisateurs eDirectory non authentifiés et les utilisateurs anonymes de LDAP peuvent parcourir eDirectory en utilisant les droits [Public].

Le serveur LDAP permet également aux utilisateurs anonymes de se servir des droits d'un autre utilisateur proxy. La valeur correspondante est située dans l'objet Groupe LDAP. Dans NetIQ iManager, cette valeur est le champ Utilisateur proxy. La figure suivante illustre ce champ dans NetIQ iManager.

L'utilisateur proxy est un nom distinctif. Vous pouvez lui accorder d'autres droits que ceux dont bénéficie l'utilisateur Public. Avec l'utilisateur proxy, vous pouvez contrôler l'accès d'un client LDAP anonyme à des conteneurs spécifiques de l'arborescence eDirectory.

REMARQUE :n'imposez pas de restrictions de connexion à l'utilisateur proxy, sauf si vous souhaitez qu'elles soient appliquées à l'ensemble des utilisateurs LDAP anonymes.

Scénario : configuration d'un utilisateur proxy NLDAP— Digital Airlines a passé un contrat avec DataSure, un groupe de recherche. DataSure utilisera LDAP pour accéder aux résultats de recherche et les stocker sur DigitalAir43, un serveur Linux de Digital Airlines. Vous ne souhaitez pas que DataSure dispose de droits Public sur les répertoires de DigitalAir43.

Vous pouvez donc créer un utilisateur proxy LDAP et lui affecter des droits spécifiques sur le répertoire DataSure. Vous indiquez le Nom distinctif du proxy dans l'objet Groupe LDAP, et rafraîchissez le serveur. Le serveur emploie alors automatiquement les droits de l'utilisateur proxy pour tout utilisateur anonyme nouveau ou existant.

Dans NetIQ iManager, cliquez sur le bouton Rôles et tâches .
Cliquez sur Administration de l'annuaire > Créer un objet, puis créez un utilisateur proxy (par exemple, LDAPProxy).
Affectez un mot de passe nul à cet utilisateur.
(Facultatif) Assignez à l'utilisateur proxy des droits sur les répertoires spécifiés.
Cliquez sur LDAP > Options LDAP > Afficher les groupes LDAP > objet Groupe LDAP.
Dans le champ Utilisateur Proxy, cliquez sur le bouton Parcourir, accédez et sélectionnez l'utilisateur LDAPProxy, puis cliquez sur OK.

14.7.9 Utilisation de SASL

SASL (Simple Authentication and Security Layer) est un mécanisme permettant d'ajouter des services de sécurité des données et de prise en charge de l'authentification aux protocoles basés sur les connexions via différents mécanismes. Il présente une interface bien formée entre les protocoles et les mécanismes. En outre, il fournit un protocole pour la sécurisation des échanges de protocole suivants au sein d'une couche de sécurité des données, et garantit l'intégrité et la confidentialité des données ainsi que d'autres services.

SASL est conçu pour permettre à de nouveaux protocoles de réutiliser les mécanismes existants sans modifier ces derniers et aussi pour permettre aux protocoles existants, sans les modifier, d'utiliser de nouveaux mécanismes. Pour utiliser SASL, chaque protocole propose une méthode pour identifier quel mécanisme utiliser, une méthode pour échanger des défis serveur et des réponses client spécifiques du mécanisme et une méthode pour communiquer le résultat de l'échange d'authentification.

Les mécanismes SASL sont nommés par des chaînes, composées de lettres majuscules, de chiffres, de traits d'union et de traits de soulignement. Les noms des mécanismes SASL doivent être enregistrés auprès de l'IANA (Internet Assigned Numbers Authority).

Si un serveur prend en charge le mécanisme demandé, il lance un échange de protocole d'authentification. Il s'agit d'une série de défis serveur et de réponses client qui sont propres au mécanisme demandé. Au cours de l'échange de protocole d'authentification, le mécanisme effectue une authentification, transmet une identité d'autorisation du client au serveur et négocie l'utilisation d'une couche de sécurité propre au mécanisme. Si l'utilisation d'une couche de sécurité est acceptée, le mécanisme doit également définir ou négocier la taille maximale du tampon de texte chiffré que chaque côté est capable de recevoir.

Le serveur LDAP gère les mécanismes suivants :

Ces mécanismes sont déployés sur le serveur pendant une installation ou une mise à niveau d'eDirectory. Cependant, sous Linux, l'utilitaire nmasinst doit être utilisé pour installer les méthodes NMAS.

Comme indiqué ci-dessus, le serveur LDAP interroge SASL pour connaître les mécanismes installés lorsqu'il reçoit sa configuration, et prend automatiquement en charge les éléments installés. Le serveur LDAP signale également les mécanismes SASL pris en charge dans son entrée rootDSE à l'aide de l'attribut supportedSASLMechanisms. Étant donné que ce sont les mécanismes enregistrés, les conventions de dénomination correctes doivent être utilisées pour les utiliser.

Le protocole de liaison LDAP autorise le client à utiliser différents mécanismes SASL pour l'authentification. Lorsque l'application utilise l'API de liaison LDAP, elle doit choisir soit la liaison simple et fournir un DN et un mot de passe, soit la liaison SASL et indiquer le nom du mécanisme SASL ainsi que les références SASL associées exigées par le mécanisme.

DIGEST-MD5

LDAP prend en charge le mécanisme DIGEST-MD5 via la requête de liaison. Au lieu de demander une liaison simple LDAP (DN et mot de passe en texte clair), vous demandez une liaison SASL LDAP et fournissez le DN et les références MD5. Le mécanisme DIGEST-MD5 n'a pas besoin de TLS. Le serveur LDAP prend en charge DIGEST-MD5 sur les connexions en clair et sécurisées.

MD5 fournit un hashage codé des mots de passe. Ces derniers sont codés même sur les connexions en clair. C'est la raison pour laquelle le serveur LDAP accepte les mots de passe utilisant MD5 sur le port en texte clair ou le port codé. Si un utilisateur tente de « renifler » cette connexion, le mot de passe ne peut pas être détecté. Toutefois, la connexion peut être simulée ou piratée.

Ce mécanisme est une liaison SASL LDAP (et non une liaison simple). Par conséquent, le serveur LDAP accepte ces requêtes, même si vous avez coché la case Exiger TLS en cas de liaison simple avec mot de passe pendant l'installation.

EXTERNAL

Le mécanisme EXTERNAL informe le serveur LDAP que le DN utilisateur et les références ont déjà été fournis au serveur. Par conséquent, il n'est pas nécessaire que le DN et les références soient communiqués dans la requête de liaison.

La requête de liaison LDAP utilise le mécanisme SASL EXTERNAL pour commander au server d'effectuer les opérations suivantes :

demander les références à la couche EXTERNAL ;
authentifier l'utilisateur avec ces références et cet utilisateur.

Une fois cette opération effectuée, elle est suivie d'une reconnaissance mutuelle sécurisée. Le serveur LDAP demande des références au client qui les lui communique, le serveur reçoit ensuite le certificat qui a été envoyé par le client et le transmet au module NMAS, puis il authentifie l'utilisateur comme le DN fourni dans le certificat

Pour disposer d'un certificat avec un DN utilisable, quelques opérations de configuration sont nécessaires sur le client. Pour plus d'informations sur la configuration du certificat, consultez la documentation en ligne NMAS.

Même si le client envoie un mécanisme EXTERNAL, le serveur LDAP peut faire échouer la requête, pour les éventuelles raisons suivantes :

La connexion n'est pas sécurisée.
Bien que la connexion soit sécurisée, le client n'a pas fourni le certificat requis pendant la procédure de reconnaissance mutuelle.
Le module SASL est indisponible.

NMAS_LOGIN

NMAS (NetIQ Modular Authentication Service) est une structure de développement qui permet d'écrire des applications qui s'authentifient auprès du réseau en utilisant différentes méthodes de connexion et d'authentification. La structure NMAS permet de concevoir un système de connexion et d'authentification flexible et évolutif utilisant des méthodes de plug-in modulaires qui tirent parti de l'infrastructure NICI (Novell International Cryptographic Infrastructure) et des services NetIQ Directory Services (eDirectory).

Le mécanisme NMAS_LOGIN permet au serveur LDAP d'accéder aux capacités biométriques de NMAS. Pour plus d'informations, reportez-vous à la documentation NetIQ Modular Authentication Services NDK.

GSSAPI

Le mécanisme GSSAPI permet à un utilisateur Kerberos de s'authentifier auprès d'un serveur eDirectory à l'aide d'un ticket, sans devoir entrer un mot de passe utilisateur LDAP distinct. Cette fonctionnalité est destinée aux utilisateurs d'applications LDAP dans des environnements disposant d'une infrastructure Kerberos existante. Ces utilisateurs doivent pouvoir utiliser des tickets délivrés par le serveur Kerberos afin de s'authentifier auprès du serveur LDAP sans devoir fournir de mot de passe utilisateur LDAP distinct.

Pour plus d'informations sur la configuration de GSSAPI, reportez-vous à l'Section E.0, Configuration de GSSAPI avec eDirectory.

14.7.10 Utilisation de connexions NMAS pour l'authentification LDAP

La connexion NMAS est activée par défaut dans eDirectory. Pour désactiver la connexion NMAS, définissez NDSD_TRY_NMASLOGIN_FIRST sur false.

REMARQUE :vous devez ajouter toutes les variables d'environnement requises pour l'exécution du service eDirectory dans le script pre_ndsd_start_custom sur les plates-formes RHEL 7.x et SLES 12.x.