Authentification et sécurité

Cette section fournit les informations suivantes :


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. 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 :

  1. Dans Novell iManager, cliquez sur le bouton Rôles et tâches Bouton R?les et t?ches.

  2. Cliquez sur LDAP > Présentation LDAP > Afficher les groupes LDAP.

  3. Cliquez sur l'objet Groupe LDAP, puis sur Informations dans l'onglet Général.

  4. Cochez la case Exiger TLS en cas de liaison simple avec mot de passe.


    Case à cocher Exiger TLS en cas de liaison simple avec mot de passe.

  5. Cliquez sur Appliquer, puis sur OK.


Démarrage et arrêt de TLS

L'opération étendue LDAP 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 analyseurs réseau (ou sniffers) sont dans l'impossibilité de diagnostiquer les données envoyées sur le réseau.

Scénario : avec 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 à l'état 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 : nouvelle 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 login et, après avoir été authentifié, se remet à travailler en texte clair sur Internet.


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, ce dernier 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 aucun certificat, le serveur maintient la connexion.

2

Pendant le processus de reconnaissance mutuelle, le serveur impose au client de lui faire parvenir un certificat. S'il ne le fournit pas ou si 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 de eDirectory. C'est au cours de cette procédure que des objets Matériel clé 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 :


Objets SSL

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 du serveur de la figure suivante illustre ce DN.


Champ Certificat du serveur

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 à la section Rafraîchissement du serveur LDAP. ConsoleOne et Novell iManager rafraîchissent automatiquement le serveur.


Configuration du client pour TLS

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.

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. Le navigateur Netscape possède la sienne, Internet Explorer également 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.


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, consultez le site Web 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 de modifier son nom, il peut s'avérer utile de garder DNS ou IP dans celui-ci, 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.


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.

  1. Dans Novell iManager, cliquez sur le bouton Rôles et tâches Bouton R?les et t?ches.

  2. Cliquez sur LDAP > Présentation LDAP.

  3. Cliquez sur Afficher les serveurs LDAP, puis cliquez sur le nom d'un objet Serveur LDAP.

  4. Cliquez sur Connexions.

  5. Dans la section TLS (Transport Layer Security), sélectionnez le menu déroulant Certificat client, puis cliquez sur Requis.

    L'authentification mutuelle est alors activée.

  6. Cliquez sur Appliquer, puis sur OK.


Utilisation d'autorités de certification de fournisseurs tiers

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.8 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 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.


Création et emploi d'utilisateurs proxy LDAP

Novell eDirectory assigne 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 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.


Champ Utilisateur Proxy

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.

NOTE:  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 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.

  1. Dans Novell iManager, cliquez sur le bouton Rôles et tâches Bouton R?les et t?ches.

  2. Cliquez sur Administration eDirectory > Créer un objet et créez un utilisateur proxy (par exemple, LDAPProxy).

  3. Affectez un mot de passe nul à cet utilisateur.

  4. (Facultatif) Assignez à l'utilisateur proxy des droits sur les répertoires spécifiés.

  5. Cliquez sur LDAP > Présentation LDAP > Afficher les groupes LDAP > objet Groupe LDAP.

  6. Dans le champ Utilisateur Proxy, cliquez sur le bouton Parcourir, sélectionnez l'utilisateur LDAPProxy, puis cliquez sur OK.


Utilisation de SASL

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. Toutefois, sous Linux et 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.


DIGEST-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.

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 requête renvoie 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 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 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 les opérations suivantes :

  • demander les références à la couche EXTERNAL ;
  • authentifier l'utilisateur comme correspondant à ces références et à l'utilisateur concerné.

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 plus d'informations sur la configuration 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 :

  • 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.
  • Le client n'a pas vérifié rootDSE avant d'envoyer la requête.


NMAS_LOGIN

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.


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 saisir de 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 à la section Configuration de GSSAPI avec eDirectory.