An object identifier (OID) is a numeric string used to uniquely identify an object in a directory. OIDs are used in directory schema, controls, and extended operations that require unique identification of elements.
LDAP object classes and attributes require a base object identifier (OID) that must be unique within your organization to avoid naming conflicts in the directory. If you plan to use your directory internally within your organization, use the OIDs provided in the directory server. If you plan to export your schema or publicly expose your schema in any way, you should consider entering a request for a unique OID for your organization. For more information, see Obtaining a Base OID.
After you have obtained a base OID, you can add branches to it for your organization's object classes and attributes. For example, the directory server uses an assigned base OID of 188.8.131.52.4.1.26027. For each component type, the directory server provides unique branch numbers to the base OID for each schema component.
Note - The directory server provides a comprehensive set of OIDs that should be sufficient for most applications. You can also request OIDs for addition to the directory server repository.
The following table shows the base OIDs used for each schema component:
For each schema type, a unique branch number is added to the base OID. For example, attribute types use a branch number of 1 to form the OID of 184.108.40.206.4.1.26027.1.*1*. For each specific attribute type, the directory server assigns another set of branch numbers, one for each attribute type.
The following table displays a (partial) list of assigned OID values for attribute types.
Note - The directory server allows the use of non-numeric OIDs as long as a corresponding numeric OID is defined within the schema. For example, you can use a non-numeric OID, mytestattribute-oid for the named attribute, myTestAttribute. The non-numeric OID must be all lowercase with the -oid appended to the named attribute. The use of non-numeric OIDs is an LDAP-specification violation but is permissible for ease of use.
If you plan to make your directory server publicly available, or if you plan to redistribute your schema definitions for custom applications, you can obtain a base OID for your organization. You can use your own OIDs in a custom schema file if you plan to create custom extensions to the directory server. Alternatively, you can modify the schema configuration files by adding your base OID with its respective branch number.
Note - Do not modify the default OIDs unless you are sure of what you are doing. Modifying the OIDs can potentially damage your directory server.
To obtain and create base OIDs for your organization, perform the following steps:
Point your browser to the Internet Assigned Numbers Authority (IANA) web site at or a national organization in your country that handles such tasks. In some countries, corporations already have OIDs assigned to them. If your organization does not already have an OID, you can fill out a request at the IANA web site.
Determine the unique object classes, attributes, names, and other schema elements. Ensure that the names are descriptive to make it easier to manage the schema. One trick is to add a custom prefix to your custom object classes and attributes. For example, if your organization is Example.com, you can add the prefix Example before each custom schema element, such as adding Example to a Person object class as in ExamplePerson.
Create an OID registry to keep track of OID assignments. The registry is nothing more than a list that you maintain to ensure that OIDs and their descriptions are unique within your directory. The registry should be sufficiently protected so that only a privileged administrator can modify the registry.
Create branches in the OID tree to accommodate the schema elements.
Shut down the directory servers in your topology.
Manually edit the schema configuration files on each directory server in your topology. Replace each OID with your company's OID. This avoids problems with schema replication seeing differences in the schema and attempting to synchronize the information.
Manually edit any custom schema extensions. Ideally, you should define any custom extensions in a separate file.