How to Create a Custom CA Directory LDAP Schema for a New CA Directory Implementation?
Article ID: 395239
Updated On: 04-23-2025
Products
Issue/Introduction
For a new CA Directory implementation, the first thing is to confirm or create a data model to hold the data for the LDAP service it is providing. This data model is then implemente through a set of LDAP schemas.
This process is somewhat similar to offering a relational database service to an application. The main difference is that LDAP data exist in a Directory Information Tree (DIT) that can actually integrate with other third-party LDAP services in a distributed manner. The distributed manner of a DIT creates the need for co-existence of LDAP schemas that are owned by different authorities. This is very different from a relational database schema that tends to be standalone.
Environment
Release: 14.1
Component: CA Directory
Resolution
To implementing a new CA Directory LDAP service is to provide a network-based data service using the LDAP technology.
For LDAP technology, data are organized in a Directory Infromation Tree (DIT) where they are arranged in a hierarchical tree structure. In addition to the tree structure, the entries (or nodes) exist in the tree consist of a set of attributes. Similar to the Relational Data Base schema, LDAP schemas are the rules that govern the different set of attributes for each type of the nodes. In additon, the tree structure of a DIT actually allows an LDAP service to integrate with other third-party LDAP services in a distributed manner. The distributed manner of a DIT further creates the need for co-existence of LDAP schemas that are owned by different authorities.
Unlike a Relational Data Base schema where RDB Data Architect tend to use available attribute types offered by the data base engine to create highly custom schemas, an LDAP Data Architect is, however, encouraged to reuse and/or extend a rich set of the industrial standard LDAP schemas. Please see the following link:
Supported Schemas and Syntaxes
for a list of out-of-the-box CA Directory supported schemas.
How to Define a Custom Schema
Please see the following product documentation for more information:
This article is meant to provide a brief overview and snippets about what a custom LDAP schema is like.
Custom Schema Starts with a Single Unique OID
A Relation Data Base is an independent datastore that provides the data services the applications rely on. It is up to the applications to integrate multiple databases as needed. Under this design, a Relation Data Base architect has the freedom to define a set of self-contained database schema.
An LDAP service by design uses a tree structure and allows a distributed data service to be constructed. The distributed data services naturally create the need to allow data schema under different authorities to coexist. As a result, when a custom LDAP schema is required, the LDAP Architect is advised to register an Object Identifier (OID) from a proper authority by reaching out to the organization's internal authority first if one exists. Otherwise, the Architect can reach out to a few international organizations such as IANA at https://iana.org, ANSI (for US organizations), or BSI (for UK organizations). Please note that IANA uses enterprise numbers to refer to OIDs and they are used primarily for Simple Network Management Protocol (SNMP).
An OID is arranged in a tree-like manner. As a result, a single OID is sufficient for an enterprise to own that space and uses the same distributed nature to allow its own subsidiaries to manage their own subspaces.
Basic Components of an LDAP Schema
There are a few basic components when constructing a custom LDAP Schema:
- attribute: that describes the syntax/data type of an attribute
- attribute set: that combines a set of attributes to describe a complex attribute
- object class: that describes the kind of the entry (object) and the attributes it has and whether any of them are mandatory
- name binding: that describes where an entry can exist in the Directory Information Tree and its naming attribute.
Examples Included in the Product Installation
The schema files included under the config/schema out of a standard Directory server installation can always serves as examples to help you create your own custom LDAP schema.
For example, the following snippet is taken from the config/schema/scim.dxc that contains basic components described above:
schema set oid-prefix scimAttributeType = (1.3.6.1.4.1.3327.200);
...
schema set oid-prefix scimObjectClass = (1.3.6.1.4.1.3327.201);
schema set oid-prefix scimNameBinding = (1.3.6.1.4.1.3327.202)
...
schema set attribute scimAttributeType:1 = {
name = id
syntax = caseIgnoreString
single-valued
};
...
schema set attribute scimAttributeType:117 = {
name = addresses
syntax = caseIgnoreString
};
...
schema set object-class scimObjectClass:3 = {
name = scimGroup
subclass-of scimCommon
kind = structural
must-contain
id,
displayName
may-contain
members
};
...
schema set name-binding scimNameBinding:3 = {
name = scimGroup-o
ScimGroup allowable-parent organization
named-by id
};
An attribute set example can be found in the x500.dxc:
set attr-set (2.5.7.7.2) = {
name = postalAttributeSet
physicalDeliveryOfficeName,
postalAddress,
postalCode,
postOfficeBox,
streetAddress
};
Note that the 3327 seen in the scim.dxc is assigned to Computer Associates under the 1.3.6.1.4.1 of {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1)}.
With these, you now should be able to plan on creating your own custom CA Directory LDAP schema if necessary. Following the convention, your schema dxc file should be stored under the config/schema subdirectory.
Feedback
