Category: Openldap

How to create and deploy a client certificate for MAC:

Transforming .cer to .pem or vice-versa:

using openssl to convert a certificate format to another format:

Exporting a private key:



LDAP resources


LDAP (Lightweight Directory Access Protocol) est un protocole d’accès à un annuaire,  dérivé d’ X500, au dessus de TCP/IP. C’est une implémentation allégée du protocole ISO DAP. Il est devenu le standard des annuaires électroniques qui prennent de plus en plus d’importance dans les systèmes d’information des entreprises…

Pointeurs pour démarrer

Les RFCs

Le coeur de LDAP :

  • RFC 4511 : Lightweight Directory Access Protocol (v3)
  • RFC 4517 : Lightweight Directory Access Protocol (v3): Syntaxes and Matching Rules
  • RFC 4514 : Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names
  • RFC 4515 : The String Representation of LDAP Search Filters
  • RFC 4516 : The LDAP URL Format
  • RFC 2256 : A Summary of the X.500(96) User Schema for use with LDAPv3
  • RFC 2829 : Authentication Methods for LDAP
  • RFC 2830 : Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security
  • RFC 3377 : Lightweight Directory Access Protocol (v3): Technical Specification
  • RFC 4518 : Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation

Autour de LDAP :

  • RFC 2247 : Using Domains in LDAP/X.500 Distinguished Names
  • RFC 2307 : An Approach for Using LDAP as a Network Information Service
  • RFC 2377 : Naming Plan for Internet Directory-Enabled Applications
  • RFC 2589 : Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services
  • RFC 2596 : Use of Language Codes in LDAP
  • RFC 2891 : LDAP Control Extension for Server Side Sorting of Search Results
  • RFC 3062 : LDAP Password Modify Extended Operation
  • RFC 3112 : LDAP Authentication Password Schema
  • RFC 2044 : UTF-8, a transformation format of Unicode and ISO 10646
  • RFC 2849 : The LDAP Data Interchange Format (LDIF) – Technical Specification
  • RFC 3384 : LDAPv3 Replication Requirements

Les serveurs

*Implémentations commerciales :

Des clients et des passerelles

  • LDAP Browser/Editor est un butineur graphique LDAP en Java
  • JXplorer est un autre butineur graphique LDAP en Java
  • GQ est un butineur graphique s’appuyant sur GTK
  • Luma est un gestionnaire graphique, basé sur python-ldap, extensible via des plugins
  • Frood est un butineur Gtk-Perl/PerLDAP
  • phpLDAPadmin est un client web d’administration/exploration  LDAP
  • KLDAP est un client ldap pour KDE
  • ldapvi ou comment modifier des entrées LDAP avec un éditeur de texte
  • web500gw est une passerelle HTTP/LDAP autonome
  • web2ldap est une passerelle HTTP/LDAP en Python multi-plateformes (Unix/Windows)
  • LAST est un outil d’administration d’annuaire en http à base de scripts Perl et de CGI
  • auth_ldap est un module d’authentification LDAP pour Apache
  • WXD est une autre passerelle HTTP/LDAP autonome (commerciale)
  • Calendra Directory Manager® est un gestionnaire de contenu d’annuaires orienté métiers
  • Meibo est un gestionnaire de contenu dédié de Ilex
  • Apache Directory Studio est un plugin/application RCP Eclipse (multi plate-formes donc) permettant la navigation dans un DIT et l’édition de données ainsi que de schémas. Il permet également d’éditer les ACIs du serveur Apache Directory Server

Connecteurs et meta-annuaires


  • mod_auth_ldap : un module d’authentification pour Apache utilisant les mécanismes standard d’authentification HTTP
  • mod_authz_ldap : un module d’authentification/autorisation pour Apache exploitant les certificats X509
  • lemonLDAP : un reverse-proxy d’authenfication d’accès à des applications web

Tout sur les schémas standardisés


À propos du nommage

L’intégration de LDAP dans Linux (en standard dans la plupart des distributions)

Plus loin


  • Une librairie PHP pour faciliter le développement d’applications d’interrogation et de mise à jour d’annuaires : CruLDAP

An OID (object identifier) is a numeric string that is used to uniquely identify an object. It is created by self-extending a private enterprise number that an institution has acquired. Typical objects that can be identified using OIDs include attributes in X.500/LDAP-based directories, certificate policies and practice statements, MIBS for network management and encryption algorithms.

In particular, as a university defines attributes for local use within directories, it will need OID’s to identify these attributes. More generally, OIDs are a managed hierarchy starting with ISO ( and ITU ( ISO and ITU delegate OID management to organizations by assigning them OID numbers; these organizations can then assign OIDs to objects or further delegate to other organizations.

OIDs are associated with objects in protocols and data structures defined using ASN.1. OIDs that define data structures and protocol elements are generated and processed by client and server software. OIDs are intended to be globally unique. They are formed by taking a unique numeric string (e.g. and adding additional digits in a unique fashion (e.g.,,, etc.) An institution will acquire an arc (eg and then extend the arc (called subarcs) as indicated above to create additional OID’s and arcs.

There is no limit to the length of an OID, and virtually no computational burden to having a long OID. OID’s are only using for “equality-matching”. That is, two objects (e.g. directory attributes or certificate policies) are considered to be the same if they have exactly the same OID. There are no implied navigational or hierarchical capabilities with OID’s (unlike IP addresses, for example); given an OID one can not readily find out who owns the OID, related OID’s, etc. OIDs exist to provide a unique identifier, recognizing that in a decentralized world, organizations may pick the same identical names for objects that they manage.

How Do we Get an OID and How do we use it?

OID’s can be obtained from a number of sources. Two formal mechanisms include IANA and ANSI.

a. To get one from IANA, fill out a form at There is no fee and turnaround appears relatively quick.

b. To get one from ANSI, go to . There is a one-time fee and turnaround can take several weeks.

In addition one can get a subarc designated from someone who already has an arc. In such instances it is important to insure that the assigning entity has legitimate claim to their own arc and that they are appropriately diligent in assigning subarcs to insure no duplication.

Once a campus has an OID arc, it will likely create subarcs to be used for particular purposes. Given arc x, a campus may use x.1 for local directory attributes (e.g. x.1.1 for parking location, x.1.2 for residence hall, etc.) and x.2 for certificate policies (e.g. x.2.1 for a low-grade policy, x.2.2 for a high-grade policy, etc.)

The importance of an OID is its uniqueness, not who owns the OID arc to which the specific OID belongs. As long as the holder of an arc is diligent about not re-issuing an OID for a different purpose, an OID should be politically neutral. There should be no political implications about using an OID in a different organization for the same purpose.

For example if SUN were to create an OID for purpose “Z” there should be no technical or valid political reasons for Example.EDU to create a different OID for the exact same purpose. However, many organizations do not publish or promote the assignment of local OIDs.

The practical result is that many sites create different OIDs for the same purpose. In the long run advertising assigned OIDs with details about the intended semantics tends to foster common solutions and reusable code.

Other references