AddEdit
L’opération ADD insère une nouvelle entrée dans la base de données du serveur de répertoires. Si le nom distinctif de la demande d’ajout existe déjà dans le répertoire, le serveur n’ajoutera pas d’entrée en double mais définira le code de résultat dans le résultat d’ajout sur decimal 68, « entryAlreadyExists ».
- les serveurs conformes LDAP ne déréférenceront jamais le nom distinctif transmis dans la demande add lors de la tentative de localisation de l’entrée, c’est-à-dire que les noms distinctifs ne sont jamais dénaturés.,
- les serveurs conformes LDAP veilleront à ce que le nom distinctif et tous les attributs soient conformes aux normes de nommage.
- L’entrée à ajouter ne doit pas exister, et le supérieur immédiat doit exister.
Dans l’exemple ci-dessus, uid=user,ou=people,dc=example,dc=com ne doit pas exister, et ou=people,dc=example,dc=com doit exister.
Bind (authenticate)Edit
Lorsqu’une session LDAP est créée, c’est-à-dire lorsqu’un client LDAP se connecte au serveur, l’état d’authentification de la session est défini sur anonymous. L’opération BIND établit l’état d’authentification pour une session.,
simple BIND et SASL PLAIN peuvent envoyer le DN et le mot de passe de l’utilisateur en texte brut, de sorte que les connexions utilisant Simple ou SASL PLAINshould soient cryptées en utilisant Transport Layer Security (TLS). Le serveur vérifie généralement le mot de passe par rapport à l’attribut userPassworddans l’entrée nommée. Anonymous BIND (avec dn et mot de passe vides) réinitialise la connexion à l’état anonyme.
la liaison SASL (simple Authentication and Security Layer) fournit des services d’authentification par le biais d’une large gamme de mécanismes, par exemple Kerberos ou le certificat client envoyé avec les fichiers de connexion.,
BIND définit également la version du protocole LDAP en envoyant un numéro de version sous la forme d’un entier. Si le client demande une version que le serveur ne prend pas en charge, le serveur doit définir le code de résultat dans la réponse de liaison au code pour une erreur de protocole. Normalement, les clients doivent utiliser LDAPv3, qui est la valeur par défaut dans le protocole, mais pas toujours dans les bibliothèques LDAP.
BIND devait être la première opération d’une session dans LDAPv2, mais n’est pas obligatoire à partir de LDAPv3., Dans LDAPv3, chaque demande de liaison réussie modifie l’état d’authentification de la session et chaque demande de liaison infructueuse réinitialise l’état d’authentification de la session.
DeleteEdit
Pour supprimer une entrée, un client LDAP transmet une requête de suppression correctement formée au serveur.,
- Une demande de suppression doit contenir le nom distinctif de l’entrée à supprimer
- Les contrôles de demande peuvent également être attachés à la demande de suppression
- Les serveurs ne déréférencent pas les alias lors du traitement d’une demande de suppression
- seules les entrées feuilles (entrées sans subordonnés) peuvent être supprimées par, Certains serveurs prennent en charge un attribut opérationnel
hasSubordinatesdont la valeur indique si une entrée a des entrées subordonnées, et certains serveurs prennent en charge un attribut opérationnelnumSubordinatesindiquant le nombre d’entrées subordonnées à l’entrée contenant l’attributnumSubordinates. - certains serveurs prennent en charge le contrôle de requête de suppression de sous-arbre permettant la suppression du DN et de tous les objets subordonnés au DN, soumis à des contrôles d’accès., Les demandes de suppression sont soumises à des contrôles d’accès, c’est-à-dire si une connexion avec un État d’authentification donné sera autorisée à supprimer une entrée donnée est régie par des mécanismes de contrôle d’accès spécifiques au serveur.
Recherche et CompareEdit
L’opération de Recherche est utilisé à la fois pour rechercher et lire les entrées. Ses paramètres sont:
baseObject le nom de l’entrée de l’objet de base (ou éventuellement de la racine) par rapport à laquelle la recherche doit être effectuée. portée quels éléments sous le baseObject à rechercher., Cela peut êtreBaseObject(recherchez uniquement l’entrée nommée, généralement utilisée pour lire une entrée),singleLevel(entrées immédiatement en dessous du DN de base), ouwholeSubtree(tout le sous-arbre commençant par le DN de base). filtrer les critères à utiliser pour sélectionner les éléments dans la portée., Par exemple, le filtre(&(objectClass=person)(|(givenName=John)(mail=john*)))vous sélectionnez « personnes » (éléments de objectClassperson) où les règles de correspondance pour legivenNameetmaildéterminer si les valeurs de ces attributs correspondent au filtre de l’assertion. Notez qu’une idée fausse commune est que les données LDAP sont sensibles à la casse, alors qu’en fait les règles de correspondance et les règles de classement déterminent la correspondance, les comparaisons et les relations de valeur relative., Si les filtres d’exemple devaient correspondre à la casse de la valeur d’attribut, un filtre de correspondance extensible doit être utilisé, par exemple,
(&(objectClass=person)(|(givenName:caseExactMatch:=John)(mail:caseExactSubstringsMatch:=john*)))déréfalifie si et comment suivre les entrées d’alias (entrées qui se réfèrent à d’autres entrées), les attributs qui attributs à renvoyer dans les entrées de résultat. sizeLimit, timeLimit nombre Maximum d’entrées à renvoyer et durée maximale pour permettre l’exécution de la recherche. Ces valeurs, cependant, ne peuvent pas remplacer les restrictions que le serveur place sur la limite de taille et la limite de temps. typesOnly renvoie uniquement les types d’attributs, pas les valeurs d’attributs.,
le serveur renvoie les entrées correspondantes et potentiellement les références de continuation. Ceux-ci peuvent être retournés dans n’importe quelle commande. Le résultat final inclura le code de résultat.
L’opération de comparaison prend un DN, un nom d’attribut et une valeur d’attribut, et vérifie si l’entrée nommée contient cet attribut avec cette valeur.
ModifyEdit
L’opération MODIFY est utilisée par les clients LDAP pour demander au serveur LDAP d’apporter des modifications aux entrées existantes. Les tentatives de modification d’entrées qui n’existent pas échoueront. Les demandes de modification sont soumises aux contrôles d’accès mis en œuvre par le serveur.,
L’opération de modification nécessite que le nom distinctif (DN) de l’entrée soit spécifié, ainsi qu’une séquence de modifications. Chaque changement dans la séquence doit être:
- add (ajouter une nouvelle valeur, qui ne doit pas déjà exister dans l’attribut)
- delete (supprimer une valeur)
- replace (remplacer une valeur par une nouvelle valeur)
LDIF exemple d’ajout d’une valeur à un attribut:
dn: dc=example,dc=comchangetype: modifyadd: cncn: the-new-cn-value-to-be-added-
Pour remplacer la valeur d’un attribut existant, Utilisez la remplacer par mot clé., Si l’attribut est à valeurs multiples, le client doit spécifier la valeur de l’attribut à mettre à jour.
pour supprimer un attribut d’une entrée, utilisez le mot clé delete et l’indicatif changetype modify. Si l’attribut multi-valué, le client doit spécifier la valeur de l’attribut à supprimer.
Il existe également une extension Modify-Increment qui permet d’incrémenter une valeur d’attribut incrémentable d’un montant spécifié., L’exemple suivant utilisant LDIF incrémente employeeNumber de 5:
dn: uid=user.0,ou=people,dc=example,dc=comchangetype: modifyincrement: employeeNumberemployeeNumber: 5-
lorsque les serveurs LDAP sont dans une topologie répliquée, les clients LDAP doivent envisager d’utiliser le contrôle post-lecture pour vérifier les mises à jour au lieu d’une recherche après une mise à jour. Le contrôle post-Lecture est conçu de sorte que les applications n’aient pas besoin d’émettre une demande de recherche après une mise à jour – il est mauvais de récupérer une entrée dans le seul but de vérifier qu’une mise à jour a fonctionné en raison du modèle de cohérence éventuel de réplication., Un client LDAP ne doit pas supposer qu’il se connecte au même serveur d’annuaire pour chaque requête, car les architectes peuvent avoir placé des équilibreurs de charge ou des proxys LDAP ou les deux entre les clients LDAP et les serveurs.
Modify DNEdit
Modify DN (move / rename entry) prend le nouveau RDN (nom distinctif relatif), éventuellement le DN du nouveau parent, et un indicateur qui indique s’il faut supprimer la ou les valeurs de l’entrée qui correspondent à l’ancien RDN. Le serveur peut prendre en charge le renommage de sous-arbres de répertoire entiers.,
Une opération de mise à jour est atomique: les autres opérations verront soit la nouvelle entrée, soit l’ancienne. D’autre part, LDAP ne définit pas les transactions de plusieurs opérations: si vous lisez une entrée puis la modifiez, un autre client peut avoir mis à jour l’entrée entre-temps. Les serveurs peuvent implémenter des extensions qui prennent en charge cela, cependant.
Extended operationsEdit
L’opération Extended est une opération LDAP générique qui peut définir de nouvelles opérations qui ne faisaient pas partie de la spécification de protocole d’origine. StartTLS est l’une des extensions les plus importantes., D’autres exemples incluent Annuler et modifier le mot de passe.
StartTLSEdit
L’opération StartTLS établit la sécurité de la couche de Transport (le descendant de SSL) sur la connexion. Il peut assurer la confidentialité des données (pour protéger les données contre l’observation par des tiers) et/ou la protection de l’intégrité des données (qui protège les données contre la falsification). Pendant la négociation TLS, le serveur envoie son certificat X. 509 pour prouver son identité. Le client peut également envoyer un certificat pour prouver son identité. Après cela, le client peut alors utiliser SASL / EXTERNAL., En utilisant le SASL / EXTERNAL, le client demande au serveur de dériver son identité à partir des informations d’identification fournies à un niveau inférieur (telles que TLS). Bien que techniquement le serveur puisse utiliser toutes les informations d’identité établies à n’importe quel niveau inférieur, généralement le serveur utilisera les informations d’identité établies par TLS.
les serveurs prennent également souvent en charge le protocole non standard « LDAPS » (« SECURE LDAP », communément appelé « LDAP over SSL ») sur un port séparé, par défaut 636., LDAPS diffère de LDAP de deux manières: 1) lors de la connexion, le client et le serveur établissent TLS avant que tous les messages LDAP ne soient transférés (sans opération StartTLS) ET2) la connexion LDAPS doit être fermée lors de la fermeture de TLS.
certaines bibliothèques clientes « LDAPS » chiffrent uniquement les communications; elles ne vérifient pas le nom d’hôte par rapport au nom du certificat fourni.
AbandonEdit
L’opération Abandon demande au serveur d’abandonner une opération nommée par un ID de message. Le serveur n’a pas besoin d’honorer la demande. Ni abandonner ni une opération abandonnée avec succès n’envoie de réponse., Une opération étendue Cancel similaire envoie des réponses, mais toutes les implémentations ne le supportent pas.
UnbindEdit
l’opération Unbind abandonne toutes les opérations en suspens et ferme la connexion. Il n’a pas de réponse. Le nom est d’origine historique, et n’est pas le contraire de l’opération de liaison.
Les Clients peuvent interrompre une session en fermant simplement la connexion, mais ils doivent utiliser Unbind. Unbind permet au serveur de fermer gracieusement la connexion et de libérer des ressources qu’il conserverait autrement pendant un certain temps jusqu’à ce que le client découvre qu’il a abandonné la connexion., Il demande également au serveur d’annuler les opérations qui peuvent être annulées et de ne pas envoyer de réponses pour les opérations qui ne peuvent pas être annulées.