Learn LDAP - Distinguished Names & LDAP URLs

#Introduction

In episode 3 you met the schema that governs an entry's shape. Episode 4 covers that entry's address: the Distinguished Name (DN). The DN is how LDAP points to an entry uniquely — understanding DN means understanding how navigation, search, and references work across the entire LDAP ecosystem. You'll also learn to write LDAP URLs, the format every client tool uses to point at both a server and a search base at once.

#DN Structure

A DN is a sequence of Relative Distinguished Names (RDNs) ordered from most specific to most general, separated by commas. Each RDN takes the form attribute=value. For example:

A simple DN example

uid=budi,ou=users,dc=example,dc=com

Reading from left to right: the entry uid=budi sits inside ou=users, which sits inside dc=example, inside dc=com. The reading direction resembles tree navigation — from leaf to root. Because the DIT is hierarchical, a DN is effectively the complete path to an entry.

#DN vs RDN

The relationship between the two is simple but often confusing:

Aspect	RDN	DN
Definition	A single component	All components combined
Example	`uid=budi`	`uid=budi,ou=users,dc=example,dc=com`
Uniqueness	Unique within its parent	Unique across the whole directory
Change	Can be changed via ModRDN	Follows the RDN change

An RDN only needs to be unique among its siblings within one parent. It's the DN that guarantees global uniqueness because it includes the entire path.

#DN Component Types

Not every attribute may be a DN component. Attributes commonly used as RDNs include:

Component	Attribute	RDN example
dc	domainComponent	`dc=example`
ou	organizationalUnitName	`ou=users`
cn	commonName	`cn=admin`
uid	userID	`uid=budi`

The combination of these four forms almost every DN you'll encounter:

Full DN examples

uid=john,ou=users,dc=example,dc=com
cn=admin,dc=example,dc=com
ou=groups,dc=example,dc=com

Notice the hierarchical pattern: uid=john points to a single account, cn=admin points to an object named admin, ou=groups points to a single unit. The chosen RDN type must reflect the nature of the object it represents.

#DN Rules

Syntax — the general format is attribute=value,attribute=value, components separated by commas.
Case sensitivity — attribute names (dc, ou, cn) are case-insensitive; some values are also treated case-insensitively depending on the attribute's matching rule.
Escaping rules — if an RDN value contains special characters like a comma, plus, quotation mark, or backslash, those characters must be escaped with a backslash. For example cn=Kari, Mulya is written cn=Kari\, Mulya.
Separators — commas separate components; semicolons are also accepted for legacy X.500-style DNs.

#RDN in More Depth

Some important points about RDNs:

Uniqueness within a parent — two entries cannot have the same RDN within one parent. This is a basic rule enforced by the server.
Multi-valued RDN — an RDN can consist of more than one attribute=value pair joined with a plus sign. For example cn=Budiono+uid=budi,ou=users,dc=example,dc=com. This technique is rarely used, but it's valid and sometimes needed to reflect a dual identity.
RDN structure — the RDN determines which attribute becomes the entry's identity; choose a stable attribute so the DN doesn't change easily.

#LDAP URLs

All client tools can accept the server location as a URL. Its full structure:

LDAP URL structure

ldap://host:port/base_dn?attributes?scope?filter

The four components after host and port are optional:

host:port — server address and port (389 by default).
base_dn — the search starting point.
attributes — the comma-separated list of requested attributes.
scope — base, one, or sub.
filter — an LDAP search filter.

Two schemes are available:

Scheme	Function
`ldap://`	Plain LDAP connection (default port 389)
`ldaps://`	LDAP over SSL/TLS (default port 636)

#LDAP URL Examples

A few of the most commonly used examples:

LDAP URL examples

ldap://ldap.example.com/dc=example,dc=com
ldap://ldap.example.com/dc=example,dc=com?cn,mail?sub?(uid=john)
ldaps://ldap.example.com:636/

First URL: searches base dc=example,dc=com on server ldap.example.com.
Second URL: searches the same base, requesting attributes cn and mail, scope sub, and filter (uid=john).
Third URL: an LDAPS connection to port 636, no base — usually used to read the Root DSE.

URL encoding applies when the base DN or filter contains special characters: spaces, commas, and parentheses must be encoded per URL rules. When in doubt, almost every tool offers an option to separate the base and filter from the URL — an approach you'll practice in episode 6.

Note

The combination of -H for the URL and -b for the base DN in client tools actually points at the same thing: the search starting point. If both are given, the -b value wins. Understand this so you don't get confused when writing commands in episode 6.

#Closing

Episode 4 completes the entry identity material: DN as the hierarchical path of RDNs, the difference between DN and RDN, the four most common components dc, ou, cn, and uid, escaping and case sensitivity rules, and the LDAP URL format along with its encoding.

Key takeaways:

An RDN is unique within its parent, a DN is unique across the directory.
Commas in an RDN value must be escaped, e.g. cn=Kari\, Mulya.
ldap://ldap.example.com/dc=example,dc=com?cn,mail?sub?(uid=john) carries base, attributes, scope, and filter all at once.
ldaps:// indicates a TLS connection on port 636.

In the next episode, episode 5, the theory is over: you'll install a real OpenLDAP, configure your first database, and start the server for the first time.