LDAP Structure for an Organizational Hierarchy Standard

version: 0.0.2

Introduction

The purpose of this document is to present and suggest a method for storing company organizational structure data in LDAP databases (examples of implementation: Active Directory, OpenLDAP, Oracle Directory, etc.).

The methodology was developed and implemented in one of the leading companies on the Polish internet market and has proven to be an oITDmal solution for many years.

Principles

The principles on which data storage will be based are presented below.

Data Storage

Organizational units will be represented as group class objects (objectClass=group).

A company's organizational structure is a tree of organizational units in a specific hierarchy. LDAP is a database that stores data hierarchically, and it would seem natural to store organizational information hierarchically as well.

Unfortunately, this method of data storage has a very serious drawback: it drastically complicates operations related to modifying the tree. It also complicates the creation of filters used to search for appropriate relationships between organizational units and employees. Therefore, we propose a solution based on a flat model, and the hierarchy itself will be implemented based on the values of the following attributes:

• member – an attribute whose value points to the DN (a unique object identifier indicating its location in the tree, also known as Distinguished Name) of the member object of the group representing a given organizational unit.
• memberOf – an attribute whose value points to the DN of the object that the given organizational unit is a member of.

---

Group Naming

Additionally, an important element related to storage is the use of appropriate group naming, specifically the use of properly constructed acronyms. The following rules are recommended:

• The group name (CN attribute, or Common Name) should be its acronym, a shortcut containing the acronym of the parent group as a prefix. An example of three organizational units in the following hierarchy will best illustrate this:
  • Information Technology Division: CN=ITD
    • Infrastructure Support Department: CN=ITDISD
    • Software Development Department: CN=ITDSDD

The purpose of this is to simplify the creation of a dependency tree by sorting the groups (in ascending order) by the CN attribute.

• Each organizational unit should be divided into two abstract units – the first group will be the unit whose member is the leader of the organizational unit, and the second group will be the unit with rank-and-file employees. This division should always exist, regardless of whether the organizational unit has a leader or not (in an extreme case, the leader's group will be empty). The name (CN) of the abstract unit is created by adding an appropriate suffix separated by a special character.

NOTE

User objects (employees) are assigned exclusively to abstract groups. Using the previous example, we get the following hierarchy:

• Information Technology Division: CN=ITD
  • Information Technology Division – leader: CN=ITD-Manager
  • Information Technology Division – employees: CN=ITD-Team
  • Infrastructure Support Department: CN=ITDISD
    • Infrastructure Support Department – leader: CN=ITDISD-Manager
    • Infrastructure Support Department – employees: CN=ITDISD-Team
  • Software Development Department: CN=ITDSDD
    • Software Development Department – leader: CN=ITDSDD-Manager
    • Software Development Department – employees: CN=ITDSDD-Team

Tree Example

Let's use the example presented earlier, supplementing it with the appropriate data:

1. The groups representing the structure will be stored in the ou=Structure,dc=example,dc=com branch.
2. Users (data representing employees) will be stored in the ou=Users,dc=example,dc=com branch.
3. Jan Kowalski (jkowalski) is the head of the Information Technology Division.
4. Anna Asystentka (aasystentka) is Jan Kowalski's assistant in the Information Technology Division.
5. Witek Szarak (wszarak), Mirek Dzielny (mdzielny) are employees of the Infrastructure Support Department. The department does not have a direct leader; this role is performed by the head of the Information Technology Division.
6. Zdzisława Wielka (zwielka) is the leader of the Software Development Department. The employees of the Software Development Department are: Michał Mały (mmaly) and Michał Duży (mduzy).

Here are the entries (objects with attributes) stored in LDAP:

• Information Technology Division (CN=ITD)

dn: cn=ITD,ou=Structure,dc=example,dc=com
description: Information Technology Division
cn: ITD
member: cn=ITD-Manager,ou=Structure,dc=example,dc=com
member: cn=ITD-Team,ou=Structure,dc=example,dc=com
member: cn=ITDISD,ou=Structure,dc=example,dc=com
member: cn=ITDSDD,ou=Structure,dc=example,dc=com

• Information Technology Division – leader (CN=ITD-Manager)

dn: cn=ITD-Manager,ou=Structure,dc=example,dc=com
description: Information Technology Division - leader
cn: ITD-Manager
memberOf: cn=ITD,ou=Structure,dc=example,dc=com
member: cn=jkowalski,ou=Users,dc=example,dc=com

• Information Technology Division – employees (CN=ITD-Team)

dn: cn=ITD-Team,ou=Structure,dc=example,dc=com
description: Information Technology Division - employees
cn: ITD-Team
memberOf: cn=ITD,ou=Structure,dc=example,dc=com
member: cn=aasystentka,ou=Users,dc=example,dc=com

• Infrastructure Support Department (CN=ITDISD)

dn: cn=ITDISD,ou=Structure,dc=example,dc=com
description: Infrastructure Support Department
cn: ITDISD
memberOf: cn=ITD,ou=Structure,dc=example,dc=com
member: cn=ITDISD-Manager,ou=Structure,dc=example,dc=com
member: cn=ITDISD-Team,ou=Structure,dc=example,dc=com

• Infrastructure Support Department – leader (CN=ITDISD-Manager)

dn: cn=ITDISD-Manager,ou=Structure,dc=example,dc=com
description: Infrastructure Support Department - leader
cn: ITDISD-Manager
memberOf: cn=ITDISD,ou=Structure,dc=example,dc=com

• Infrastructure Support Department – employees (CN=ITDISD-Team)

dn: cn=ITDISD-Team,ou=Structure,dc=example,dc=com
description: Infrastructure Support Department - employees
cn: ITDISD-Team
memberOf: cn=ITDISD,ou=Structure,dc=example,dc=com
member: cn=wszarak,ou=Users,dc=example,dc=com
member: cn=mdzielny,ou=Users,dc=example,dc=com

• Software Development Department (CN=ITDSDD)

dn: cn=ITDSDD,ou=Structure,dc=example,dc=com
description: Software Development Department
cn: ITDSDD
memberOf: cn=ITD,ou=Structure,dc=example,dc=com
member: cn=ITDSDD-Manager,ou=Structure,dc=example,dc=com
member: cn=ITDSDD-Team,ou=Structure,dc=example,dc=com

• Software Development Department (CN=ITDSDD-Manager)

dn: cn=ITDSDD-Manager,ou=Structure,dc=example,dc=com
description: Software Development Department - leader
cn: ITDSDD-Manager
memberOf: cn=ITDSDD,ou=Structure,dc=example,dc=com
member: cn=zwielka,ou=Users,dc=example,dc=com

• Software Development Department (CN=ITDSDD-Team)

dn: cn=ITDSDD-Team,ou=Structure,dc=example,dc=com
description: Software Development Department - employees
cn: ITDSDD-Team
memberOf: cn=ITDSDD,ou=Structure,dc=example,dc=com
member: cn=mmaly,ou=Users,dc=example,dc=com
member: cn=mduzy,ou=Users,dc=example,dc=com

Benefits

The benefits of using the proposed data organization for describing the organizational structure are described below.

---

Simple Data Transformation

• With simple mechanisms, you can transfer a given structure to, for example, relational databases. Create a dependency tree by sorting the groups (in ascending order) by the CN attribute.

• It is very simple to extract information about employees or leaders by attaching appropriate suffixes to the basic names.

• It is very easy to extract information about an employee's superior by performing simple operations on the name of the abstract group they belong to (removing the -Team suffix from the name and appending the -Manager suffix, and then searching for members of the group with the resulting name).

• We can create a problem escalation method from one superior to another without much effort.

---

Improved Permission Granting

• The given structure can be very easily used to manage permissions. We become independent of permissions assigned to specific employees in favor of permissions related to performing a given role in the company's organizational structure.

---

Group Correspondence

• The implementation of simple mechanisms for inheriting users between parent and child groups makes sending correspondence to specific organizational units relatively easy to implement.

---

Simplified Modification Operations

• You do not need to modify the user's DN attribute to move them from one group to another.

---

Summary by Google Gemini

Your standard for storing an organizational structure in LDAP is very interesting and has several significant advantages, especially in the context of scalability and the simplicity of operations. Here are my thoughts on the matter:

Pros and Strengths

1. Simplified Hierarchy

The flat model, with the hierarchy implemented at the attribute level (memberOf), is a clever solution. It eliminates the complexity associated with modification operations in a traditional, hierarchical LDAP tree, where moving objects would require changing their Distinguished Name (DN). In this model, moving an employee or a department is simply a matter of changing an attribute value, which is much faster and less invasive.

2. Logical Group Naming

The use of acronyms with prefixes that reflect the hierarchy (ITD > ITDISD) is very effective. It allows for easy sorting and searching of groups, as well as an intuitive understanding of dependencies. This makes it possible to build simple and efficient filters for queries.

3. Division into Roles (Manager/Team)

Dividing each organizational unit into two abstract groups (-Manager and -Team) is an excellent idea. It simplifies the management of permissions and correspondence. Instead of assigning permissions individually, you can assign them to a role. This increases security and facilitates access management, especially with high employee turnover.

4. Data Transformation and Integration

As you noted, this model is very flexible. It's easy to transform into relational databases and to reconstruct the hierarchy by sorting groups by the CN attribute. This makes it very universal and easy to integrate with other systems.

Potential Challenges and Remarks

1. Maintaining Consistency

It is crucial that the system managing such a structure ensures data consistency. For example, changing the name of a parent group would require updating the prefixes in all subordinate groups, which must be automated. Similarly, the member and memberOf attributes must always be synchronized.

2. Standards and Tools

Although the concept is solid, its implementation in various LDAP systems may require custom scripts or tools that adhere to the naming conventions and manage the member/memberOf relationships. Not all administrative tools may intuitively support this "flat" hierarchy by default.

3. Understanding for New Administrators

New administrators may initially be confused, as they expect a traditional tree hierarchy. Good documentation and training are necessary to ensure everyone understands the logic of this model.

Summary

In summary, your standard is a very well-thought-out and practical approach to managing organizational structure in LDAP. Instead of relying on a built-in but rigid tree hierarchy, it uses attributes in an intelligent way, which leads to greater flexibility, simplicity, and ease of automation. I particularly like the separation of roles using suffixes, which is key for efficient permission and correspondence management. This solution is certainly more effective in large and dynamic organizations.