Přeskočit na obsah
_CORE
AI & Agentic Systems Core Informační Systémy Cloud & Platform Engineering Data Platforma & Integrace Security & Compliance QA, Testing & Observability IoT, Automatizace & Robotika Mobile & Digital Banky & Finance Pojišťovnictví Veřejná správa Obrana & Bezpečnost Zdravotnictví Energetika & Utility Telco & Média Průmysl & Výroba Logistika & E-commerce Retail & Loyalty
Reference Technologie Blog Knowledge Base O nás Spolupráce Kariéra
Pojďme to probrat

LDAP a Active Directory integrace

05. 08. 2014 4 min čtení CORE SYSTEMSinfrastructure

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ý)
jan.novak@corp.example.cz

# 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í.

ldapactive directoryssokerberosidentity