Cette section contient des informations sur les éléments suivants :
Le protocole SSL (Secure Socket Layer) 3.1 était à l'origine diffusé via Netscape. L'IETF s'est approprié cette norme en mettant en oeuvre TLS (Transport Layer Security) 1,0.
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 façon de procéder : 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 Novell iManager, cliquez sur le bouton Rôles et tâches 
.
Cliquez sur LDAP > Présentation LDAP > Afficher les groupes LDAP.
Cliquez sur Objet Groupe LDAP, puis sur Informations dans 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.
La fonction LDAP étendue STARTTLS permet de passer d'une connexion en clair à une connexion codée. Cette fonction constituait une nouveauté de eDirectory 8.7.
Lorsque vous employez une connexion codée, c'est la totalité du paquet qui est codée. De ce fait, les détecteurs de paquet sont dans l'impossibilité de diagnostiquer les données envoyées via le réseau.
Scénario : utilisation 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 transitent donc plus rapidement. À ce stade, la connexion est rétrogradée à l'état Anonyme.
Pour vous authentifier, vous devez utiliser 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 Anonymous. Par conséquent, si vous souhaitez accéder à un état différent d'Anonyme, vous devez vous authentifier à nouveau.
Scénario : nouvelle authentification---Henri lance STOPTLS. Son état devient " Anonymous ". Pour accéder à ses fichiers sur Internet et les utiliser, Henri exécute la commande Bind, fournit ses références de login et, après avoir été authentifié, se remet à travailler en texte clair sur Internet.
Lorsqu'une instance de session TLS est créée, un processus de reconnaissance mutuelle intervient. Le serveur et le client échangent des données. C'est le serveur qui détermine la façon dont ce processus de reconnaissance se produit. Pour prouver qu'il est le serveur légitime, le serveur envoie toujours son certificat au client. Grâce à ce processus de reconnaissance, le client est certain 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.
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 de eDirectory. C'est au cours de cette procédure que des objets matériels clés sont créés, dans le cadre de l'infrastructure PKI (Public Key Infrastructure) et des services NMASTM ( Novell 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 Novell iManager, l'onglet Connexions de l'objet Serveur LDAP affiche un DN. Il représente le certificat X.509. Le champ Certificat de serveur de la figure suivante présente ce DN :
Dans Novell 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 :
Une fois le serveur LDAP reconfiguré, rafraîchissez-le. Pour plus de détails, reportez-vous à Rafraîchissement du serveur LDAP. ConsoleOne et Novell iManager rafraîchissent automatiquement le serveur.
Un client LDAP est une application (par exemple Netscape Communicator, 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
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.
Selon le type d'application utilisée, la méthode d'importation du certificat par le client diffère. Chaque application doit avoir une méthode pour importer un certificat. Le navigateur Netscape possède sa propre méthode, Internet Explorer la sienne et ICE en utilise une troisième. Tous trois sont des clients LDAP différents. Chaque client possède sa méthode pour localiser les certificats dans lesquels il a confiance.
Vous pouvez exporter automatiquement la racine approuvée tout en acceptant le serveur de certificats.
Pour exporter manuellement la racine approuvée, reportez-vous à Exporting a Trusted Root or Public Key Certificate (Exportation d'un certificat de racine approuvée ou de clé publique).
La fonctionnalité d'exportation crée le fichier indiqué. Bien qu'il soit possible d'en modifier le nom, il peut s'avérer utile de laisser DNS ou IP dans le nom de fichier, 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 racine lors de chaque mise à jour du registre. L'extension classique .X509 utilisée par Microsoft est indispensable.
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 Novell iManager, cliquez sur le bouton Rôles et tâches .
Cliquez sur LDAP > Présentation 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.
Pendant l'installation de 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 8.7.3 prennent en charge plusieurs autorités de certification. L'autorité de certification d'arborescence Novell n'est que l'une d'entre elles. Le serveur LDAP peut avoir d'autres CA (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.
Novell 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 (Anonymous). 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 Novell iManager, cette valeur est le champ Utilisateur proxy. Dans ConsoleOne, elle correspond au champ Nom d'utilisateur proxy. La figure suivante illustre ce champ dans Novell iManager :
L'utilisateur proxy est un nom distinctif. Vous pouvez accorder à cet utilisateur proxy des droits différents de 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 login à l'utilisateur proxy, sauf si vous souhaitez les voir 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 des enquêtes et les stocker sur DigitalAir43, serveur sous NetWare 6 de Digital Airlines. Vous ne souhaitez pas que DataSure dispose des droits Public sur les répertoires de DigitalAir43.
Vous pouvez donc créer un utilisateur proxy LDAP et lui assigner des droits spécifiques sur le répertoire DataSure. Vous renseignez 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 Novell iManager, cliquez sur le bouton Rôles et tâches .
Cliquez sur Administration eDirectory > Créer un objet et créez un utilisateur proxy (par exemple, LDAPProxy).
Affectez un mot de passe nul à cet utilisateur.
(Facultatif) Affectez à l'utilisateur proxy des droits sur les répertoires spécifiés.
Cliquez sur LDAP > Présentation LDAP > Afficher les groupes LDAP > objet Groupe LDAP.
Dans le champ Utilisateur proxy, cliquez sur le bouton Parcourir, affichez et sélectionnez l'utilisateur LDAPProxy, puis cliquez sur OK.
SASL (Simple Authentication and Security Layer) définit divers mécanismes d'authentification qui doivent être enregistrés auprès de IANA (Internet Assigned Numbers Authority). 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 de eDirectory. Cependant, sous UNIX, vous devez exécuter l'utilitaire nmasinst pour installer les méthodes NMAS.
Le serveur LDAP interroge SASL pour connaître les mécanismes installés lors de 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.
Comme ces mécanismes sont enregistrés, vous devez les saisir entièrement en majuscules. Dans le cas contraire, le serveur LDAP ne les reconnaîtra pas.
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 la liaison simple et fournir un DN et un mot de passe ou opter pour la liaison SASL et indiquer le nom du mécanisme SASL en majuscules, ainsi que toute référence SASL associée requise par le mécanisme.
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.
LDAP prend en charge les mécanismes SASL dans le cadre de la demande de liaison. Au lieu de demander une liaison LDAP simple (DN et mot de passe en texte clair), vous demandez une liaison LDAP SASL. Cette demande fournit un DN et des références MD5.
MD5 fournit un hachage 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 quelqu'un analyse 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 LDAP SASL (et non une liaison simple). Par conséquent, le serveur LDAP accepte ces demandes, même si vous avez coché la case Exiger TLS en cas de liaison simple avec mot de passe pendant l'installation.
Le mécanisme EXTERNAL informe le serveur LDAP qu'un DN utilisateur et des références ont déjà été fournis au serveur. De ce fait, il n'est pas nécessaire que le DN et les références soient soumis à la demande de liaison.
La demande de liaison LDAP à l'aide du mécanisme SASL EXTERNAL demande au serveur d'effectuer ce qui suit :
Une reconnaissance mutuelle sécurisée a eu lieu. Le serveur a demandé des références au client et ce dernier les lui a transmises. Le serveur LDAP a reçu le certificat envoyé par le client, l'a transmis au module NMAS et a authentifié l'utilisateur en fonction du DN transmis dans le certificat.
Pour disposer d'un certificat avec un DN utilisable, quelques opérations de configuration sont nécessaires sur le client. Pour toute information sur la définition du certificat, consultez la documentation en ligne NMAS.
Même si le client envoie un mécanisme EXTERNAL, la requête peut ne pas être satisfaite par le serveur LDAP. Novell iMonitor peut fournir les raisons de cet échec :
Le mécanisme NMAS_LOGIN permet au serveur LDAP d'accéder aux capacités biométriques de NMAS. Pour plus d'informations, consultez le Novell Developer Kit (NDK).
Lorsque le serveur est activé, le serveur LDAP s'initialise avec le module SASL et demande à ce dernier quels mécanismes sont à sa disposition.
Le client peut interroger rootDSE pour connaître l'attribut pris en charge par le mécanisme. Le serveur LDAP affiche ensuite les mécanismes pris en charge.