Tag Archive: LDAP

Reference Article: https://technet.microsoft.com/en-us/library/cc978012.aspx

Port 3268. This port is used for queries specifically targeted for the global catalog. LDAP requests sent to port 3268 can be used to search for objects in the entire forest. However, only the attributes marked for replication to the global catalog can be returned. For example, a user’s department could not be returned using port 3268 since this attribute is not replicated to the global catalog.

Port 389. This port is used for requesting information from the local domain controller. LDAP requests sent to port 389 can be used to search for objects only within the global catalog’s home domain. However, the requesting application can obtain all of the attributes for those objects. For example, a request to port 389 could be used to obtain a user’s department.

The Schema Manager is used to specify additional attributes (i.e ThumbnailPhoto, Department…) that should be replicated to each global catalog server. The attributes included in the global catalog are consistent across all domains in the forest.

Effect of Global Catalog When Searching Back Links and Forward Links

Some Active Directory attributes cannot be located specifically by finding a row in the directory database. A back link is an attribute that can be computed only by referencing another attribute, called a forward link. An example of a back-link attribute is the memberOf attribute on a user object, which relies on the group attribute members to derive its values. For example, if you request the groups of which a specific user is a member, the forward link members , an attribute of the group object, is searched to find values that match the user name that you specified.

Because of the way that groups are enumerated by the Global Catalog, the results of a back-link search can vary, depending on whether you search the Global Catalog (port 3268) or the domain (port 389), the kind of groups the user belongs to (global groups vs. domain local groups), and whether the user belongs to groups outside the local domain. Connecting to the local domain does not locate the user’s group membership in groups outside the domain. Connecting to the Global Catalog locates the user’s membership in global groups but not in domain local groups because local groups are not replicated to the Global Catalog


reference: http://msdn.microsoft.com/en-us/library/cc223241.aspx

ldap filters: http://msdn.microsoft.com/en-us/library/aa746475%28v=vs.85%29.aspx



Hi, here is a new article to explain how to limit ldap queries (in order to minimize attacks or to minimize impact on the performance of ldap/AD server):

Technet article: https://social.technet.microsoft.com/wiki/contents/articles/14559.active-directory-ldap-policy.aspx

AD does not allow anonymous connection: http://support.microsoft.com/kb/326690/en-us

By default, anonymous Lightweight Directory Access Protocol (LDAP) operations to Active Directory, other than rootDSE searches and binds, are not permitted in Microsoft Windows Server 2003 or greater.

Using ntdsutil to limit AD queries: https://support.microsoft.com/kb/315071/en-us

These limits prevent specific operations from adversely affecting the performance of the server, and also make the server more resilient to some types of attacks.

Windows Server 2008 and newer domain controller returns only 5000 values in a LDAP response: http://support.microsoft.com/kb/2009267

Override the hardcoded LDAP Query limits introduced in Windows Server 2008 and Windows Server 2008 R2: http://blogs.technet.com/b/qzaidi/archive/2010/09/02/override-the-hardcoded-ldap-query-limits-introduced-in-windows-server-2008-and-windows-server-2008-r2.aspx

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 (http://www.iso.ch/) and ITU (http://www.itu.ch/). 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 http://pen.iana.org/pen/PenApplication.page. There is no fee and turnaround appears relatively quick.

b. To get one from ANSI, go to http://web.ansi.org/public/services/reg_org.html . 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