Active Directory's directory tree is structured around the Windows domain, which changes how you find the right base DN compared to a generic LDAP directory.
Every label in a DNS domain name becomes a DC= component. A domain named corp.example.com has the base DN:
DC=corp,DC=example,DC=com
You'll do this conversion constantly when configuring clients.
Base DN Helper
Convert a domain name to a base DN instead of doing it by hand.
A fresh Active Directory domain ships with a few default containers under the root:
- dc=com
- dc=example
- dc=corp
- cn=Users
- cn=Computers
- ou=Domain Controllers
- dc=corp
- dc=example
Note that the built-in Users and Computers containers use cn=, not ou= — they're technically containers, not organizational units, which matters if you ever try to apply Group Policy to them (you can't; GPOs only link to OUs). Most real deployments create their own OU= structure underneath the root fairly quickly, mirroring the organization's teams or offices.
Active Directory listens for LDAP on the same standard ports as any other server:
| Port | Protocol |
|---|---|
| 389 | Plain LDAP |
| 636 | LDAPS |
| 3268 | Global Catalog (plain) |
| 3269 | Global Catalog (LDAPS) |
The Global Catalog ports (3268/3269) search across every domain in a multi-domain forest, but only return a partial, indexed set of attributes for each object. Regular ports (389/636) query a single domain but return full entries. Most single-domain deployments never need the Global Catalog.
Every domain controller (DC) in the domain can answer LDAP queries — they replicate the same directory data between themselves. Production code typically points at a DNS name that resolves to any healthy DC (dc=corp,dc=example,dc=com often has an SRV record for exactly this), rather than hardcoding one specific server, so a single DC being down doesn't take down the application.
Continue to Users to see how AD models a user account specifically.