In LDAP directory services, we encounter two primary structural approaches for organizing entries:
// Domain Component (dc) style dn: dc=example,dc=com objectClass: domain dc: example // Organization (o) style dn: o=Example objectClass: organization o: Example
The dc=example,dc=com structure follows Internet DNS conventions and works particularly well with:
- Modern directory services like OpenLDAP 2.4+
- DNS-based service discovery
- Multi-domain environments
The o=Example structure originates from X.500 directory standards and offers:
- Simpler hierarchy for small deployments
- Better compatibility with legacy systems
- More straightforward naming for internal applications
Here's how user entries would differ between the two approaches:
// dc style user entry dn: uid=jdoe,ou=People,dc=example,dc=com objectClass: inetOrgPerson uid: jdoe cn: John Doe sn: Doe // o style user entry dn: cn=John Doe,o=Example objectClass: inetOrgPerson cn: John Doe sn: Doe
For new deployments in 2023+, I recommend the dc=example,dc=com approach because:
- Better alignment with Internet standards
- Easier integration with DNS and TLS certificates
- More flexible for organizational restructuring
- Wider support in modern LDAP clients and tools
However, the o=Example style might be preferable when:
- Migrating legacy X.500 systems
- Working with specialized enterprise software requiring this format
- Implementing simple test environments
For those needing to transition between structures, here's a basic migration strategy:
# Export existing o=Example data ldapsearch -x -D "cn=admin,o=Example" -w password -b "o=Example" -LLL > export.ldif # Convert DNs in the export file sed -i 's/o=Example/dc=example,dc=com/g' export.ldif sed -i 's/^dn: cn=$.*$,o=Example/dn: cn=\1,ou=People,dc=example,dc=com/' export.ldif # Import into new structure ldapadd -x -D "cn=admin,dc=example,dc=com" -w newpassword -f export.ldif
In LDAP directory services, we encounter two fundamental approaches to structuring the directory tree:
// Domain Component (dc) style: dn: dc=example,dc=com objectClass: top objectClass: domain // Organization (o) style: dn: o=Example objectClass: organization
The o=Example structure originated in early X.500 directories, while the dc=example,dc=com approach gained prominence with DNS integration in LDAP v3. Modern implementations typically favor the domain component style as it:
- Aligns with Internet domain naming conventions
- Facilitates integration with DNS-based services
- Supports hierarchical structures more naturally
Let's examine both approaches with concrete examples:
// DC-style group definition dn: cn=developers,ou=Groups,dc=example,dc=com objectClass: groupOfNames member: cn=john,ou=Users,dc=example,dc=com member: cn=mary,ou=Users,dc=example,dc=com // O-style group definition dn: cn=developers,o=Example objectClass: groupOfNames member: cn=john,o=Example member: cn=mary,o=Example
When choosing between these structures, consider:
For dc=example,dc=com:
- Better compatibility with modern directory servers (OpenLDAP, Active Directory)
- Easier integration with DNS and SSL certificates
- More intuitive for web-based applications
For o=Example:
- Simpler structure for small-scale deployments
- Historical compatibility with legacy systems
- May require less configuration for basic setups
Modern directory servers typically support both schemas. Here's how you might implement both in OpenLDAP's slapd.conf:
# Schema definitions for both approaches include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema
For new deployments, I strongly recommend the dc=example,dc=com approach:
- Future-proofs your directory structure
- Maintains consistency with Internet standards
- Simplifies integration with cloud services
- Works better with modern authentication protocols
Example of a complete DC-style LDIF file:
dn: dc=example,dc=com objectClass: top objectClass: domain dc: example dn: ou=People,dc=example,dc=com objectClass: organizationalUnit ou: People dn: uid=jsmith,ou=People,dc=example,dc=com objectClass: inetOrgPerson uid: jsmith cn: John Smith sn: Smith mail: jsmith@example.com