Learn LDAP - Active Directory & LDAP

#Introduction

So far in this series you've worked with OpenLDAP. Episode 22 introduces the other giant in the directory world: Microsoft Active Directory. You'll see that AD speaks the same LDAP language you already know — but with its own ecosystem, schema, and tooling. Then you'll learn how Linux systems join an AD domain, because in a mixed environment this is a daily reality.

#Active Directory's LDAP Interface

Active Directory is a directory service, but not built on OpenLDAP — it's built on its own database (Jet/ESE) with its own schema and security model. What's important here: AD exposes a full LDAP interface. Any LDAP client can search, bind, and query AD as if it were any other LDAP server.

• Bind — AD authenticates with simple bind against userPrincipalName or sAMAccountName, and supports SASL NTLM and Kerberos.
• Base DN — the directory root is derived from the domain name, e.g. dc=corp,dc=example,dc=com for corp.example.com.
• Users — live under CN=Users,DC=corp,DC=example,DC=com or an OU you create.
• Schema — AD's own schema; the classic uid is replaced by sAMAccountName and userPrincipalName.
• The password — stored as NT hash and hashes, not {SSHA}.

ldapsearch -x -H ldap://dc01.corp.example.com \
  -D "CN=Administrator,CN=Users,DC=corp,DC=example,DC=com" -W \
  -b "DC=corp,DC=example,DC=com" \
  "(sAMAccountName=budi)" sAMAccountName mail

#Domain Controllers and the Global Catalog

• Domain controller (DC) — the AD server holding a replica of the directory and the domain's security services.
• Global Catalog (GC) — a special server holding a partial copy of every domain in the forest, used for searching across domains.

The Global Catalog listens on ports 3268/3269. Applications that must search across the whole forest use the GC, not the regular LDAP port.

#The Active Directory Schema

• Distinguished names — built around CN= for containers and objects (CN=Budi,CN=Users,DC=corp,DC=example,DC=com).
• Key user attributes — sAMAccountName (the short login), userPrincipalName (login@domain), mail, telephoneNumber, memberOf.
• The schema is extensible — with ldapmodify or the AD Schema console, custom attributes can be added to user objects.

The most practical difference from OpenLDAP: the attribute that applications and admins use for the username is sAMAccountName, not uid.

#Linux Joining AD: realmd + SSSD

The modern way for Linux to join an AD domain uses realmd and sssd. The packages on Debian and Ubuntu:

sudo apt install realmd sssd sssd-tools libnss-sss libpam-sss adcli krb5-user

Discover and join:

sudo realm discover CORP.EXAMPLE.COM
sudo realm join --user=Administrator CORP.EXAMPLE.COM

The join writes an sssd.conf and a computer account in AD. Then test:

sudo realm list
getent passwd budi@corp.example.com
id budi@corp.example.com

Configuration lives in /etc/sssd/sssd.conf:

[sssd]
domains = corp.example.com
services = nss, pam
 
[domain/corp.example.com]
ad_domain = corp.example.com
krb5_realm = CORP.EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
auth_provider = ad
access_provider = ad

The ad provider tells SSSD to use AD directly; cache_credentials = True keeps logins working when a DC is unreachable.

#Linux Joining AD: Winbind

The older (still widely used) path is Samba Winbind. Install winbind and set the Kerberos realm in /etc/krb5.conf:

[libdefaults]
    default_realm = CORP.EXAMPLE.COM
 
[realms]
    CORP.EXAMPLE.COM = {
        kdc = dc01.corp.example.com
        admin_server = dc01.corp.example.com
    }

Join with Samba:

sudo smbpasswd -r CORP.EXAMPLE.COM -U Administrator
sudo net ads join -U Administrator -D CORP

Then configure NSS and PAM with wbinfo for lookups and pam_winbind for authentication. The difference: Winbind is older and less integrated, SSSD is the recommended modern choice, but both are production-viable.

#Application Integration

AD as an LDAP server integrates with applications exactly as OpenLDAP did in episode 21:

• LDAP bind from applications — bind with userPrincipalName or sAMAccountName@corp.example.com.
• Postfix — the same map pattern, but the query filter uses AD attributes: (&(objectClass=user)(mail=%s)).
• Dovecot — pass_filter: (&(objectClass=user)(userPrincipalName=%u)), with auth_bind = yes.
• Kerberos SSO — Linux clients and AD share the realm; GSSAPI binds work across the whole domain.
• Keycloak — the ldap user federation connects to AD with the base DN and the sAMAccountName login attribute.

The migration path from OpenLDAP to AD (or back) is a real project — attribute mapping, ACL translation, and application rewrites — covered more deeply in episode 28.

#Closing

In this episode 22 you understood Active Directory as an LDAP ecosystem: its LDAP interface with sAMAccountName and userPrincipalName, domain controllers and the Global Catalog with ports 3268/3269, the AD schema, joining Linux with realmd/SSSD, the Winbind alternative, and application integration through the same LDAP patterns.

Key takeaways:

• AD speaks LDAP — but its schema uses sAMAccountName, not uid.
• Know the ports — 389/636 for LDAP, 3268/3269 for the Global Catalog, 88 for Kerberos.
• SSSD is the modern Linux join — realmd + sssd beats Winbind for new deployments.
• Applications don't care — the LDAP pattern from episode 21 works against AD with different attributes.

In the next episode, episode 23, we connect the directory to other data sources: LDAP proxy & gateway patterns — back-ldap, the meta backend, and back-sql, for federating and bridging.