LDAP a Active Directory integrace

Každá enterprise aplikace dříve nebo později narazí na stejný požadavek: „Napojte to na Active Directory.” Zní to jednoduše. Ve skutečnosti je LDAP integrace plná úskalí, která vás mohou stát týdny ladění. Tady je náš battle-tested průvodce.

Active Directory — víc než adresářová služba¶

Active Directory (AD) je páteř identity managementu ve většině českých korporací. Windows Server 2012 R2, aktuální verze, kombinuje LDAP adresář, Kerberos autentizaci, DNS služby a Group Policy do jednoho celku. Pro vývojáře webových aplikací je LDAP rozhraní primární vstupní bod.

Ale pozor — AD není čistý LDAP server. Microsoft přidal vlastní rozšíření, nestandardní atributy a chování, které se liší od OpenLDAP nebo 389 Directory Server. Kdo to neví, ten debuguje.

Autentizace — bind správně¶

LDAP autentizace funguje přes operaci „bind” — klient pošle DN (Distinguished Name) a heslo, server ověří. V AD máte tři způsoby, jak specifikovat identitu:

# 1. DN bind (standardní LDAP)
CN=Jan Novák,OU=Users,DC=corp,DC=example,DC=cz

# 2. UPN bind (Active Directory specifický)
[email protected]

# 3. Down-level logon (NTLM styl)
CORP\jan.novak

Doporučujeme UPN bind — je nejčistší, nevyžaduje znalost přesného DN (který se mění při přesunu uživatele mezi OU) a funguje konzistentně napříč doménami v lese.

Vyhledávání uživatelů — LDAP filtry¶

Po úspěšném bindu potřebujete vyhledat uživatele a jeho atributy. LDAP filtry mají specifickou syntaxi, kterou je nutné znát:

# Najdi uživatele podle sAMAccountName
(&(objectClass=user)(objectCategory=person)(sAMAccountName=jnovak))

# Najdi všechny aktivní uživatele v OU
(&(objectClass=user)(objectCategory=person)
  (!(userAccountControl:1.2.840.113556.1.4.803:=2)))

# Najdi členy skupiny
(&(objectClass=user)(memberOf=CN=Admins,OU=Groups,DC=corp,DC=example,DC=cz))

Klíčový detail: userAccountControl je bitové pole. Filtr s OID 1.2.840.113556.1.4.803 je bitwise AND — testuje, zda je bit 2 (ACCOUNTDISABLE) nastaven. Bez tohoto filtru vrátíte i zablokované účty. Častá chyba.

Skupiny a autorizace¶

AD skupiny jsou základ autorizace, ale mají svá specifika:

• Nested groups — skupina může být členem jiné skupiny. Atribut memberOf ukazuje jen přímé členství, ne tranzitivní.
• LDAP_MATCHING_RULE_IN_CHAIN (OID 1.2.840.113556.1.4.1941) — AD rozšíření pro rekurzivní vyhledávání členství
• Primary group — typicky Domain Users, není v memberOf! Musíte kontrolovat primaryGroupID zvlášť.
• Token bloat — uživatel v příliš mnoha skupinách může mít problémy s Kerberos tokenem (max 65535 bajtů)

# Rekurzivní členství — najdi všechny (i nepřímé) členy skupiny
(&(objectClass=user)(memberOf:1.2.840.113556.1.4.1941:=CN=App-Admins,OU=Groups,DC=corp,DC=example,DC=cz))

LDAPS — šifrování je nutnost¶

LDAP bez šifrování posílá hesla v plaintextu. To je nepřijatelné. Máte dvě možnosti:

• LDAPS (port 636) — SSL/TLS wrapper, vyžaduje certifikát na domain controlleru
• StartTLS (port 389) — upgrade existujícího spojení na TLS

V praxi doporučujeme LDAPS. StartTLS má známé implementační problémy v některých Java LDAP knihovnách a starších AD verzích. Certifikát na DC by měl být podepsaný interní CA — pokud nemáte PKI infrastrukturu, je čas ji vybudovat.

Connection pooling a performance¶

LDAP bind je relativně drahá operace. Pro webovou aplikaci s desítkami requestů za sekundu nechcete dělat bind na každý request. Řešení:

• Service account bind — aplikace se přihlásí servisním účtem a pak vyhledává uživatele
• Connection pool — udržujte pool otevřených LDAP spojení (Spring LDAP, Apache Directory API)
• Cache — výsledky LDAP dotazů cachujte s rozumným TTL (5–15 minut)
• Paging — pro velké výsledky používejte Simple Paged Results Control (1000 záznamů na stránku)

Nejčastější chyby¶

Za roky integrace s AD jsme viděli tyto chyby opakovaně:

• Referral chasing — AD vrací referrals na jiné domain controllery. Pokud je nesledujete, chybí vám uživatelé z child domén.
• Escapování speciálních znaků — DN obsahující čárky, uvozovky nebo zpětná lomítka musí být správně escapovaný. Jinak LDAP injection.
• Anonymous bind — moderní AD ho defaultně zakazuje. Vždy používejte servisní účet.
• Hardcoded Base DN — místo toho použijte RootDSE pro automatické zjištění defaultNamingContext
• Ignorování hesla s prázdným stringem — některé LDAP knihovny provedou anonymous bind místo chyby. Vždy validujte vstup.

Směr k SSO — SAML a Kerberos¶

Čisté LDAP autentizace vyžaduje, aby uživatel zadal heslo do vaší aplikace. To není ideální — heslo prochází aplikací, která ho nemusí potřebovat. Lepší přístupy pro rok 2014:

• Kerberos/SPNEGO — transparentní SSO pro uživatele přihlášené do domény. Prohlížeč pošle Kerberos ticket, aplikace ho ověří.
• ADFS + SAML 2.0 — federované SSO přes Active Directory Federation Services. Vhodné pro webové aplikace a cloud služby.
• Hybrid — LDAP pro autorizaci (skupiny, atributy), Kerberos/SAML pro autentizaci

AD integrace — investice do základů¶

Správná integrace s Active Directory není sexy projekt. Neukážete ji na boardu a nevyhraje žádnou cenu za inovaci. Ale je to fundament, na kterém stojí identity management celé organizace. Udělejte to jednou a pořádně — servisní účet, LDAPS, connection pool, správné filtry a cesta k SSO. Vaši uživatelé (a váš ops tým) vám poděkují.