LDAP, Kerberos, DNS, and Their Roles in Samba AD
Purpose of This Page
This page explains how identity functions in a Samba Active Directory Domain Controller environment by breaking the system into its core components: LDAP, Kerberos, and DNS. Rather than treating these as interchangeable or redundant services, this overview clarifies what each layer is responsible for, how they depend on one another, and how failures tend to manifest when one layer is misconfigured or unavailable.
The goal is not protocol-level exhaustiveness, but operational clarity: knowing where to look when something breaks, and why certain constraints exist.
The Identity Stack as a System
In a Samba AD environment, identity is not handled by a single service. It is an interdependent stack:
- Kerberos answers: Who are you, and can you prove it?
- LDAP answers: What are you, and what are you associated with?
- DNS answers: Where are the services that make identity work?
All three must function correctly for domain authentication and authorization to behave as expected. Problems are often misattributed to “LDAP issues” or “AD issues” when the root cause lies in DNS resolution or time synchronization.
LDAP: Directory and Metadata Layer
LDAP serves as the directory and query layer of Active Directory. In a Samba AD DC, LDAP stores structured information about:
- Users
- Groups
- Computers
- Domain configuration
- Trust and replication metadata
LDAP answers questions like:
- “Which groups does this user belong to?”
- “Is this computer a domain member?”
- “What attributes are associated with this account?”
Importantly, LDAP is not the primary authentication mechanism in Active Directory. While classic LDAP deployments often authenticate users by binding with a username and password, Active Directory shifts authentication responsibility to Kerberos. LDAP becomes a source of authoritative metadata, not proof of identity.
In Samba AD, LDAP schema and structure are tightly constrained by Active Directory expectations. Direct LDAP modification is possible but hazardous, as it bypasses domain-aware tools and may violate assumptions made by Windows clients and Kerberos.
Kerberos: Authentication and Trust
Kerberos is the authentication backbone of Active Directory. It is responsible for:
- Proving identity without transmitting passwords
- Issuing time-bound tickets for services
- Enforcing trust relationships between users, machines, and services
When a Windows client logs into the domain, it authenticates using Kerberos, not LDAP. Successful Kerberos authentication depends on:
- Accurate DNS resolution
- Correct system time (within tight tolerances)
- Properly registered service principals
Many issues that appear to be “login failures” or “domain trust problems” are in fact Kerberos failures caused by time drift, DNS misconfiguration, or missing service records.
From an operational perspective, Kerberos failures tend to be binary and unforgiving: when it breaks, authentication simply stops working.
DNS: Service Discovery and Naming Authority
DNS is not optional in Active Directory—it is foundational.
DNS is responsible for:
- Locating domain controllers
- Advertising Kerberos and LDAP services
- Resolving domain and host names consistently
Active Directory relies heavily on SRV records to allow clients to discover services automatically. If DNS is misconfigured, clients may be unable to find the domain controller even if LDAP and Kerberos are functioning correctly.
In a Samba AD DC deployment, the domain controller typically acts as the authoritative DNS server for the domain. Mixing external DNS resolvers or bypassing the AD-integrated DNS layer is a common source of subtle and persistent failures.
Operational rule of thumb:
If identity behavior is erratic or inconsistent across machines, check DNS first.
How These Layers Interact During a Domain Login
A simplified domain login flow looks like this:
- The client uses DNS to locate domain controllers and Kerberos services.
- The client authenticates using Kerberos, receiving a ticket.
- The system queries LDAP to retrieve user attributes, group memberships, and policy-related metadata.
- Access decisions and session setup proceed based on the combined results.
Failure at any stage can prevent successful login, but symptoms often surface later in the process, making root cause analysis non-obvious.
Operational Implications
Understanding the identity stack helps enforce good operational boundaries:
- Avoid direct LDAP edits unless absolutely necessary.
- Treat DNS configuration as identity infrastructure, not “network plumbing.”
- Ensure reliable time synchronization across all domain members.
- Use domain-aware tools for provisioning and modification whenever possible.
When troubleshooting, resist the urge to treat Active Directory as a monolith. Most failures can be isolated by asking which layer of the stack is failing to fulfill its role.
Summary
Samba AD does not provide identity through a single service, but through a coordinated system of protocols, each with a specific responsibility. LDAP provides structure, Kerberos provides trust, and DNS provides discoverability. Treating these layers distinctly—while understanding their interdependence—is essential for maintaining a stable, predictable domain environment.
This layered understanding is especially important in small but production-critical deployments, where simplicity and clarity matter more than theoretical flexibility.