The Identity Stack, Episode 9
EP08: FreeIPA → EP09 → EP10: SAML/OIDC → …
Focus Keyphrase: Active Directory LDAP
Search Intent: Informational
Meta Description: Active Directory is LDAP + Kerberos + DNS + Group Policy — all tightly integrated. Here’s how AD replication, Sites, GPO, and Linux domain join actually work. (160 chars)
TL;DR
- Active Directory is not a product that happens to use LDAP — it is an LDAP directory with a Microsoft-extended schema, a built-in Kerberos KDC, and DNS tightly integrated
- Replication uses USNs (Update Sequence Numbers) and GUIDs — the Knowledge Consistency Checker (KCC) automatically builds the replication topology
- Sites and site links tell AD which DCs are physically close — AD prefers to authenticate users against a DC in the same site to minimize WAN latency
- Group Policy Objects (GPOs) are stored as LDAP entries (in the
CN=Policiescontainer) and Sysvol files — LDAP tells clients which GPOs apply; Sysvol delivers the policy files - Linux joins AD via
realm join(uses adcli + SSSD) ornet ads join(Samba + winbind) — both register a machine account in AD and get a Kerberos keytab - The difference between Linux in AD and Linux in FreeIPA: AD is optimized for Windows; FreeIPA is optimized for Linux — both interoperate
The Big Picture: What AD Actually Is
Active Directory Domain: corp.com
┌────────────────────────────────────────────────────────────┐
│ │
│ LDAP directory Kerberos KDC │
│ ───────────── ────────── │
│ Schema: 1000+ classes Realm: CORP.COM │
│ Objects: users, groups, Issues TGTs + service tickets │
│ computers, GPOs, OUs Uses LDAP as the account DB │
│ │
│ DNS Sysvol (DFS share) │
│ ──── ──────────────── │
│ SRV records for KDC GPO templates │
│ and LDAP discovery Login scripts │
│ Replicated via DFSR │
│ │
│ Replication engine: USN + GUID + KCC │
└────────────────────────────────────────────────────────────┘
│ replicates to │ replicates to
▼ ▼
DC: dc02.corp.com DC: dc03.corp.com
EP08 showed FreeIPA as the Linux-native answer to enterprise identity. AD is the Microsoft answer — and because most enterprises run Windows clients, understanding AD is unavoidable for Linux infrastructure engineers. This episode goes behind the LDAP and Kerberos protocols to explain what makes AD specifically work.
The AD Schema: LDAP With 1000+ Object Classes
AD’s schema extends the base LDAP schema with Microsoft-specific classes and attributes. Every user object is a user class (which extends organizationalPerson which extends person which extends top) with additional attributes like:
sAMAccountName ← the pre-Windows 2000 login name (vamshi)
userPrincipalName ← the modern UPN ([email protected])
objectGUID ← a globally unique 128-bit identifier (never changes, even if DN changes)
objectSid ← Windows Security Identifier (used for ACL enforcement on Windows)
whenCreated ← creation timestamp
pwdLastSet ← password change timestamp
userAccountControl ← bitmask: disabled, locked, password never expires, etc.
memberOf ← back-link: groups this user belongs to
objectGUID is the authoritative identifier in AD — not the DN. When a user is renamed or moved to a different OU, the GUID stays the same. Applications that store a user’s DN will break on rename; applications that store the GUID won’t.
userAccountControl is the bitmask that controls account state:
Flag Value Meaning
ACCOUNTDISABLE 2 Account disabled
LOCKOUT 16 Account locked out
PASSWD_NOTREQD 32 Password not required
NORMAL_ACCOUNT 512 Normal user account (set on almost all accounts)
DONT_EXPIRE_PASSWD 65536 Password never expires
# Query AD from a Linux machine
ldapsearch -x -H ldap://dc.corp.com \
-D "[email protected]" -w password \
-b "dc=corp,dc=com" \
"(sAMAccountName=vamshi)" \
sAMAccountName userPrincipalName objectGUID memberOf userAccountControl
Replication: USN + GUID + KCC
AD replication is multi-master — every DC accepts writes. The replication engine uses:
USN (Update Sequence Number) — a per-DC counter that increments on every local write. Each attribute in the directory stores the USN at which it was last modified (uSNChanged, uSNCreated). When DC-A replicates to DC-B, DC-B asks: “give me everything you’ve changed since the last USN I saw from you.”
GUID — each object has a globally unique identifier. If the same attribute is modified on two DCs before replication (a conflict), the conflict is resolved: last-writer-wins at the attribute level, based on the modification timestamp. If timestamps are equal, the attribute value from the DC with the lexicographically higher GUID wins.
KCC (Knowledge Consistency Checker) — a component that runs on every DC and automatically constructs the replication topology. You don’t configure which DCs replicate to which — the KCC builds a minimum spanning tree that ensures every DC is connected to every other within a set number of hops. You configure Sites and site links; the KCC does the rest.
# Check replication status from a Linux machine (requires rpcclient or adcli)
# Or on the DC: repadmin /showrepl (Windows tool)
# Simulate: query the highestCommittedUSN from a DC
ldapsearch -x -H ldap://dc.corp.com \
-D "[email protected]" -w password \
-b "" -s base highestCommittedUSN
Sites and Site Links
Sites are AD’s concept of physical network topology. A site is a set of IP subnets with high-bandwidth connectivity between them. Site links represent the WAN connections between sites.
Site: Mumbai Site: Hyderabad
┌────────────────┐ ┌────────────────┐
│ DC: dc-mum-01 │ │ DC: dc-hyd-01 │
│ DC: dc-mum-02 │ │ DC: dc-hyd-02 │
│ subnet: 10.1/16│ │ subnet: 10.2/16│
└───────┬────────┘ └────────┬───────┘
│ │
└──── Site Link ───────────┘
Cost: 100
Replication interval: 15 min
When a user in Mumbai authenticates, AD’s KDC locates a DC in the same site using DNS SRV records. The SRV records include the site name in the service name: _ldap._tcp.Mumbai._sites.dc._msdcs.corp.com. SSSD and Windows clients query site-local SRV records first.
If no DC is available in the local site, authentication falls back to a DC in another site across the WAN link. Configuring sites correctly prevents remote authentication failures from killing local operations.
Group Policy: LDAP + Sysvol
GPOs are stored in two places:
LDAP — the CN=Policies,CN=System,DC=corp,DC=com container holds GPO metadata objects. Each GPO has a GUID, a display name, and version numbers. The gPLink attribute on OUs and the domain root links GPOs to where they apply.
Sysvol — the actual policy templates and scripts live in \\corp.com\SYSVOL\corp.com\Policies\{GPO-GUID}\. Sysvol is a DFS-R (Distributed File System Replication) share replicated to every DC.
When a Windows client applies Group Policy:
1. LDAP query: what GPOs are linked to my OU chain?
2. Sysvol fetch: download the policy templates from the GPO’s Sysvol path
3. Apply: process Registry settings, Security settings, Scripts
Linux clients don’t process GPOs natively. The adcli and sssd tools interpret a small subset of AD policy (password policy, account lockout) via LDAP. Full GPO processing on Linux requires Samba’s samba-gpupdate or third-party tools.
Joining Linux to AD
realm join (recommended)
# Install required packages
dnf install -y realmd sssd adcli samba-common
# Discover the domain
realm discover corp.com
# corp.com
# type: kerberos
# realm-name: CORP.COM
# domain-name: corp.com
# configured: no
# server-software: active-directory
# client-software: sssd
# Join
realm join corp.com -U Administrator
# Prompts for Administrator password
# Creates machine account in AD
# Configures sssd.conf, krb5.conf, nsswitch.conf, pam.d automatically
# Verify
realm list
id [email protected]
What the join does:
- Creates a machine account
HOSTNAME$inCN=Computers,DC=corp,DC=com - Sets a machine password (rotated automatically by SSSD)
- Retrieves a Kerberos keytab to
/etc/krb5.keytab - Configures SSSD with
id_provider = ad,auth_provider = ad - Updates
/etc/nsswitch.confto includesss - Updates
/etc/pam.d/to includepam_sss
After joining, SSSD uses the machine’s Kerberos keytab to authenticate to the DC and query LDAP — no hardcoded service account credentials required.
LDAP Queries Against AD from Linux
# Find a user (after kinit or with -w password)
ldapsearch -Y GSSAPI -H ldap://dc.corp.com \
-b "dc=corp,dc=com" \
"(sAMAccountName=vamshi)" \
sAMAccountName mail memberOf
# Find all members of a group
ldapsearch -Y GSSAPI -H ldap://dc.corp.com \
-b "dc=corp,dc=com" \
"(cn=engineers)" \
member
# Find all AD-joined Linux machines
ldapsearch -Y GSSAPI -H ldap://dc.corp.com \
-b "dc=corp,dc=com" \
"(&(objectClass=computer)(operatingSystem=*Linux*))" \
cn operatingSystem lastLogonTimestamp
# Find disabled accounts
ldapsearch -Y GSSAPI -H ldap://dc.corp.com \
-b "dc=corp,dc=com" \
"(userAccountControl:1.2.840.113556.1.4.803:=2)" \
sAMAccountName
The last filter uses an LDAP extensible match (1.2.840.113556.1.4.803 is the OID for bitwise AND). userAccountControl:1.2.840.113556.1.4.803:=2 means “entries where userAccountControl AND 2 equals 2” — i.e., the ACCOUNTDISABLE bit is set. This is a Microsoft AD extension not in standard LDAP.
⚠ Common Misconceptions
“AD is just Microsoft’s LDAP.” AD is LDAP + Kerberos + DNS + DFS-R + GPO, all tightly integrated and with a schema that the Microsoft ecosystem depends on. You can query AD with standard ldapsearch. You cannot replace it with OpenLDAP without breaking every Windows client.
“Linux machines in AD get GPO.” Linux machines appear in AD and can be organized into OUs. Standard GPOs don’t apply to them. Samba’s samba-gpupdate can process a subset of AD policy for Linux — mostly Registry and Security settings mapped to Linux equivalents.
“realm leave removes the machine cleanly.” realm leave removes local configuration but does not delete the machine account from AD. The stale computer object stays in CN=Computers until an AD admin deletes it. Always run realm leave && adcli delete-computer -U Administrator for a clean removal.
Framework Alignment
| Domain | Relevance |
|---|---|
| CISSP Domain 5: Identity and Access Management | AD is the dominant enterprise identity store — understanding its LDAP structure, Kerberos realm, and GPO model is essential for IAM in mixed environments |
| CISSP Domain 4: Communications and Network Security | AD replication traffic (RPC, LDAP, Kerberos) is a significant portion of enterprise WAN traffic — Sites and site links are a network security and performance design decision |
| CISSP Domain 3: Security Architecture and Engineering | AD forest/domain/OU hierarchy is an architectural decision with long-term security consequences — getting OU structure wrong constrains GPO delegation for years |
Key Takeaways
- AD is LDAP + Kerberos + DNS + GPO + DFS-R — not a product that “uses” these; they’re the implementation
- Replication is multi-master via USN + GUID; the KCC builds the topology automatically from Sites configuration
objectGUIDis the stable identifier — not the DN, which changes on rename/moverealm joinis the correct way to join Linux to AD — it configures SSSD, Kerberos, PAM, and NSS correctly in one commanduserAccountControlis the bitmask that controls account state —(userAccountControl:1.2.840.113556.1.4.803:=2)finds disabled accounts
What’s Next
EP09 covered AD — LDAP and Kerberos inside the corporate network. EP10 covers what happens when identity needs to work across the internet, where Kerberos doesn’t reach: SAML, OAuth2, and OIDC — the protocols that let identity leave the building.
Next: SAML vs OIDC vs OAuth2: Which Protocol Handles Which Identity Problem
Get EP10 in your inbox when it publishes → linuxcent.com/subscribe
