A Crash Course in X.500 Naming

You probably already are familiar with the concept of hierarchical naming conventions, thanks to the Internet's Domain Name Service (DNS). Each organization on the Internet belongs to some root domain such as .org, .com, .info and so on, but with its own unique domain name, such as example.com, and perhaps with subdomains, such as marketing.example.com and support.example.com. This scheme is extended to people through e-mail addresses, each consists of a user name unique within the organization, concatenated to the organization's domain name, such as weasel@marketing.example.com.

Conceptually, entity names in LDAP and X.500 are built the same way. An LDAP/X.500 entity's full name, called its distinguished name (more formally, its distinguishedName or dn), is similarly constructed from a unique combination of a unique entity name and shared organization name elements. For example, my own distinguished name in an LDAP database might be expressed as cn=Mick Bauer,dc=linuxjournal,dc=com. cn is short for common name, which is the name by which my entry is indexed, and dc is short for domain component.

X.500/LDAP has two common methods for organizing names (and thus of representing organizational structures), one of which is simply a fancy way of notating DNS names. The other, the traditional X.500 convention, is based on geographical locations. The traditional X.500 equivalent of the distinguished name in the previous paragraph might be cn=Mick Bauer, o=Linux Journal, l=Seattle, st=WA, c=US.

In this article, I'm sticking to DNS-style names due to this newer convention's popularity and its similarity (conceptually if not cosmetically) to the more-familiar Internet DNS. But you should keep in mind two things. First, unless you intend to use LDAP for DNS, which is way beyond the scope of this article, there technically isn't any relationship between the naming convention you choose to use in your organization's LDAP database and your local DNS. Though I recommend that you make them consistent for sanity's sake, LDAP and DNS technically are two separate things. So if, for example, your organization's Internet domain name is sklablozzleflik.info, but you've got some reason to make your LDAP suffix sklablozzleflik.com instead (or more precisely dc=sklablozzleflik,dc=com), you're free to do so.

Second, regardless of which naming convention you choose, even if you make up your own, which is possible with customized LDAP schema, remember to use naming tags and commas rather than simple dots to delineate your name. For example, if my Internet domain name is wiremonkeys.org, my equivalent LDAP domain name will be dc=wiremonkeys,dc=org.