Comment fonctionne le proxy LDAP ?

de passerelle, le
proxy peut gérer les transactions (par exemple traduire des données, consolider,
multiplexer des transactions, définir les niveaux de sécurité des extraits et
contrôler le mode de transaction).

Dans un scénario d’intranet, la gestion de
l’accès aux ressources LDAP peut se faire à  la fois à  l’intérieur et à  l’extérieur
de l’entreprise. Sur la figure 1, le serveur proxy LDAP gère l’accès aux annuaires
LDAP à  l’intérieur d’un firewall. Un Internet ou un extranet permet de cacher
les ressources d’annuaires internes tout en permettant malgré tout l’accès géré
aux requêtes LDAP. Sur la figure 2, le serveur proxy LDAP gère l’accès aux annuaires
LDAP de l’extérieur d’un firewall pour les solutions Internet et extranet. Voyons
rapidement les capacités d’un serveur proxy LDAP à  la fois à  l’intérieur et à 
l’extérieur du firewall. Lorsqu’il gère une transaction, le proxy
accepte une connexion LDAP avec un port TCP donné pour le compte d’un client,
puis transmet la requête LDAP au serveur selon des règles définies.
Cette requête peut être dite « pass through » car basée sur une adresse IP distincte
ou bien peut nécessiter une traduction d’adresse. Une requête pass through n’exige
ni traduction ni manipulation ; le proxy lui sert simplement de relais.

En revanche lorsqu’une requête exige une traduction d’adresse, il faudra que le
client interroge le proxy sur le port TCP 389, port TCP standard des connexions
LDAP. Il peut également être nécessaire d’interroger un autre serveur sur le port
636, le port TCP standard pour les connexions LDAP par la LDAPS (Secure Sockets
Layer). Ce sera le cas s’il s’agit de clients d’intranet devant accéder à  l’annuaire
d’un partenaire de l’entreprise et si la connexion à  cet annuaire ne peut se faire
qu’au moyen de SSL.
Les grandes entreprises sont souvent dotées d’un firewall bien verrouillé mis
en oeuvre par le service responsable de la sécurité.
Dans ce type de situations, le firewall interdit tout trafic, ne permettant aux
requêtes que de traverser les ports et les protocoles.
La plupart des solutions de firewall n’autorisent pas les ports LDAP standards
ou le protocole LDAP ; les clients ne peuvent donc pas interroger les adresses
utilisant ce protocole. Le cas échéant, il faudra par conséquent peut-être interroger
plusieurs hôtes pour consolider une requête LDAP ou bien interroger plusieurs
serveurs LDAP simultanément (pour renvoyer le résultat comme s’il provenait d’un
seul serveur) pour multiplexer une transaction. Le proxy LDAP permet également
de mettre en oeuvre plusieurs zones de sécurité. Bien que n’étant pas spécifique
à  la sécurité, les fonctions du proxy LDAP permet de contrôler la portée d’une
requête.

Un proxy LDAP a la capacité de manipuler les informations transmises par la requête,
ainsi que ses résultats

Manipulation des requêtes. Un proxy LDAP a la capacité
de manipuler les informations transmises par la requête, ainsi que ses résultats.
Les solutions actuellement disponibles supportent certaines fonctions rudimentaires,
mais le potentiel d’évolution reste grand. Le proxy LDAP peut empêcher telle ou
telle requête d’utiliser certains attributs ou bien de renvoyer tel ou tel attribut
(par exemple une zone d’annuaire) dans le résultat d’une requête.
Par exemple, pour empêcher des requêtes externes de déterminer le numéro de téléphone
personnel d’un objet représentant une personne de l’entreprise. Il est possible
dans ce cas d’exclure toutes les requêtes pour l’attribut Téléphone personnel
et d’empêcher le proxy de renvoyer l’attribut Numéro personnel dans le résultat
d’une requête. L’écran 1 montre une requête LDAP de l’annuaire natif par le biais
de Microsoft Outlook. L’écran 2 montre les résultats d’une consultation du même
annuaire par un proxy LDAP. Dans l’écran 2, certains attributs disponibles auparavant,
comme le Numéro personnel, ne sont plus là  et sont désignés comme N/A.
Ce changement tient à  ce que la seconde connexion est faite à  partir d’une adresse
IP externe.Supposons
que vous vouliez permettre à  une requête interne de renvoyer davantage d’informations
sur un objet et que les informations sur cet objet proviennent de l’attribut Distinguished
Name (DN) de l’objet de l’utilisateur.
Pour ce faire vous avez la possibilité d’appliquer une transformation pour traduire
les informations au moment de leur transfert du serveur LDAP au client. (J’utilise
transformation pour décrire l’utilisation
des données de transaction par le proxy LDAP en vue de modifier la requête ou
le result set d’une requête). Pour un objet Personne d’une entreprise, supposons
que DN définisse l’attribut directeur dans l’objet.
Pour renvoyer des informations sur le directeur incluant son nom complet et son
numéro de téléphone, il faudrait deux requêtes de la part du client. Un proxy
permet, quant à  lui, d’obtenir les mêmes résultats avec une seule requête sans
surcharger le client. Il renvoie les requêtes sous forme de valeurs séparées et
exige que l’application cliente soit prête à  les recevoir.

Vous aurez peut-être intérêt à  protéger les adresses e-mail de l’entreprise
contre les messages commerciaux indésirables

Si vous autorisez les requêtes sur un extranet, vous aurez peut-être
intérêt à  protéger les adresses e-mail de l’entreprise contre les messages commerciaux
indésirables. Pour empêcher les utilisateurs extérieurs d’obtenir des adresses
de l’annuaire, il suffit d’utiliser une adresse de département générique.
Avec une solution sécurisée installée, pour obtenir des données sur un sujet,
comme, par exemple, sa clé publique, la requête par extranet ne fonctionnera que
si l’utilisateur effectuant la requête donne l’adresse électronique complète du
sujet. MaXware Benelux propose le seul serveur proxy LDAP permettant
des transformations programmables. MLPS permet d’utiliser VBScript pour définir
les transformations des données.
Certes VBScript limite la définition à  une seule entrée et un seul résultat, mais
le potentiel de définitions détaillées reste grand. Une transformation de données
permet d’obtenir des données sur un attribut baptisé mail,
où l’annuaire LDAP source stocke les informations dans un attribut baptisé rfc822mailbox.

Dans cet exemple, il est possible de décider que la requête ne doit renvoyer la
valeur que lorsque le département de la personne est Ventes. L’écran 3 montre la boîte de dialogue Groupe d’utilisateurs
qui permet de configurer de quelle manière le proxy effectue la requête et transmet
la transformation au serveur, et de quelle manière il applique la transformation
aux données renvoyées par le proxy au client.
La boîte de dialogue Groupe d’utilisateurs permet également de convertir les données
au fur et à  mesure que le proxy transmet la requête. L’écran 4 montre le code
transformer les données de l’attribut Téléphone personnel des Propriétés de l’utilisateur
Archie Reed de l’écran 1. Le serveur proxy LDAP peut également jouer un rôle de
médiateur d’annuaires pour permettre aux clients internes d’interroger plusieurs
annuaires LDAP sur l’Internet.
Dans ce cas, il est possible de paramétrer le proxy pour qu’il consulte plusieurs
serveurs LDAP au nom d’une seule requête et renvoie des informations très spécifiques,
comme l’adresse d’e-mail. L’écran 5 montre les résultats, au format du client
Outlook, que ce scénario peut renvoyer. Pour pouvoir interroger tous
les serveurs d’annuaires, il faut configurer le client pour qu’il s’adresse à 
tous les serveurs. Chaque requête du client étant une action séparée, il risque
d’y avoir trop de charge sur l’utilisateur du client. Il est possible de mettre
en oeuvre une solution dans laquelle le client s’adresse à  tous les serveurs pour
augmenter l’exploitabilité des clients compatibles LDAP, surtout ceux de messagerie
électronique.

Contrôles d’accès. Toutes les solutions de serveur proxy
permettent de contrôler d’une manière ou d’une autre le type d’opérations à  exécuter
vis-à -vis de l’annuaire. Dans certains cas, il s’agit de s’assurer que les clients
ne peuvent effectuer aucun type d’opérations d’écriture. Dans d’autres, certains
clients ne doivent pas pouvoir lire tel ou tel annuaire sécurisé. Selon le produit
choisi, les permissions peuvent être contrôlées par adresse IP ou par logon authentifié.
le Directory Boundary Agent gère les connexions en fonction de l’adresse IP et
du numéro de port et ne permet pas le contrôle de la sécurité sur la base de requêtes
authentifiées.

Chiffrement de protocole. ILPS supporte TLS (Transport
Layer Security), c’est-à -dire le standard Internet SSL 3.0. SSL est la pierre
angulaire de la sécurité avec le protocole HTTP utilisé par les transactions basées
sur le Web. TLS et SSL sont incompatibles, mais TLS fournit un mécanisme pour
supporter les solutions SSL courantes. SSL et TLS sont indépendants des protocoles
et peuvent donc être utilisés pour la plupart des protocoles Internet, y compris
LDAP. SSL est plus commun, mais TLS se répand de plus en plus.Pour permette à 
un client de se connecter à  un serveur compatible SSL, celui-ci envoie un certificat
signé par une autorité de certification (CA) au client LDAP pour l’informer de
son identité. Le client doit ensuite décider s’il y a lieu d’approuver le certificat
(par exemple vérifier la relation d’approbation avec l’autorité ayant signé le
certificat du serveur).
ILPS comporte un mécanisme de signature automatique de certificat pour supporter
LDAPS, qui équivaut, pour l’utilisateur, à  générer et signer son propre certificat
afin de sécuriser la conversation par le protocole LDAP. Cette fonction n’est
disponible que dans la version US. Au moment de la mise sous presse, MLPS ne supportait
pas SSL, mais MaXware Benelux prévoit d’y remédier prochainement.
Pour ce qui est de SASL (Simple Authentification and Security Layer, décrit dans
la RFC 2.222), qui permet d’ajouter d’autres méthodes d’authentification que la
simple authentification et SSL, il est supporté par ILPS, mais pas par MLPS. En
effet, SASL exige LDAPv3 et, si MLPS supporte les requêtes LDAPV3 des serveurs,
il ne supporte en revanche que les requêtes LDAPv2 des clients.

Un proxy LDAP permet également de créer un point central d’administration pour
l’équilibrage des charges et le failover

Failover. Un proxy LDAP permet également de créer un point
central d’administration pour l’équilibrage des charges et le failover.
Par exemple, ILPS permet de spécifier une propriété d’équilibrage des charges
pour équilibrer les requêtes entre plusieurs serveurs et, qui plus est, identifier
et gérer un scénario prévoyant l’indisponibilité d’un ou plusieurs serveurs. En
cas d’indisponibilité d’un serveur, le proxy dirigera les requêtes vers les serveurs
disponibles jusqu’à  ce que ce serveur soit à  nouveau disponible. Malheureusement,
ILPS n’assure pas, pour le moment, la notification d’incident dynamique (comme
SNMP), mais ce sera peut-être le cas dans des releases futures.

Consignation consolidée. Il n’existe guère de méthode
assurant une consignation consolidée entre serveurs d’annuaires, c’est pourquoi
le proxy LDAP permet une vue consolidée des annuaires. Les serveurs proxy LDAP
offrent des niveaux divers de consignation, mais conservent les journaux au même
endroit. Si vous accédez à  plusieurs annuaires utilisant le proxy, vous pouvez
obtenir une vue consolidée de leur utilisation. Cette vue consolidée peut aider
à  résoudre des problèmes de sécurité.
Pour cela, il convient de rediriger toutes les requêtes LDAP à  travers le proxy
pour une durée spécifiée et de diriger la requête vers l’hôte approprié en se
servant du type de requête. On obtient ainsi une vue générale de la constitution
des requêtes.
à€ l’exception des notes d’applications dans les journaux systèmes, des notes dans
les journaux des applications, et des journaux de base en format texte, il n’existe
qu’une utilisation limitée des outils de surveillance de Windows NT. ILPS stocke
les journaux en format syslog. Il existe des outils, comme UNIX Swatch, pour surveiller
les fichiers syslog, mais ils ne s’entendent pas bien avec NT.