Active Directory a protokol LDAP

Tento článek pouze stručně popisuje adresářové služby, hlavně se zaměřením na Active Directory, a dále protokol pro komunikaci s adresářovými službami LDAP. V praxi se často zaměňují termíny adresář, adresářová služba a LDAP a článek vysvětluje vzájemné vazby mezi nimi. Jedná se o teoretický úvod k praktickému použití LDAPu v PHP.

Tento článek navazuje na předchozí díl, který se věnoval Adresářovým službám a LDAPu. Zde se stručně pojednává o bezpečnostním modelu LDAPu a autentizačních možnostech adresářových služeb a zaměřuje se na speciality Active Directory. Jinak řečeno, jsou zde popsány způsoby, jakými se ověřuje uživatel vůči doméně.

Tento článek slouží jako upozornění na možnosti, které nám dává PHP. V PHP můžeme přistupovat do adresářových služeb, například Active Directory, což se hodí pro řadu aplikací (třeba na intranetu). Také uvádí postup, jak rozchodit využití LDAPS pod Windows.

Tento článek navazuje na minulé ukázky použití LDAPu v PHP. Jednou užitečnou vlastností, kterou nám přináší přístup přes LDAP k adresářovým službám, je možnost provedení autentizace uživatele. V praxi tak můžeme, třeba na intranetu, autentizovat uživatele jeho doménovým účtem proti Active Directory. Článek ukazuje jednoduchý příklad, jak to provést. Samozřejmě lepší by ještě bylo využití Single Sign On, ale to již není tak jednoduché.

Tento článek se věnuje relativně jednoduchému postupu, jak rozšířit možnosti administračního nástroje Active Directory Users And Computers o editaci dalšího atributu. Jedná se o atribut, který je součástí schématu AD, ale nemá podporu v ADUC. V příkladu je uveden atribut employeeID (číslo zaměstnance), ale je možno obdobně aplikovat na libovolný jiný. V prvním kroku se vytváří VB skript, který přistupuje k hodnotě. V druhém kroku se rozšiřuje kontextové menu ADUC.

Mým původním plánem bylo napsat článek, který by byl určen začátečníkům v oblasti správy Microsoftího firemního prostředí a jednoduchou formou popsal základní struktury Active Directory (les, strom, doména a site), jejich vzájemné vztahy a použití. Ale když jsem článek psal, tak jsem doplňoval více a více informací, takže ač myslím, že je stále vhodný pro začátečníky, tak i zkušenější admin může nalézt vhodné informace. Stále je však velké množství podrobností, kterým se v článku nevěnuji, jako replikace či vztahy důvěry. Doplnil jsem ale popis globálního katalogu, operations masters rolí a něco o nasazení.

Tento článek obsahuje stručný popis kroků pro převod MS domény na nový funkční level. Nejedná se o žádný podrobný ani úplný návod, ale pouze o orientační informace, které jsem si sepsal, když jsem převod prováděl. Vycházíme z toho, že máme doménu Windows Server 2003 a pro zjednodušení popisu jeden řadič.

Podíváme se na standardní protokol Kerberos, který je již dlouho používaný ve Windows a v posledních verzích se jedná o primární protokol pro autentizaci. Tento protokol je velmi bezpečný a ze svého principu podporuje Single sign-on. A právě SSO je to, co nás zajímá. Kerberos je obecně využívaný (nejen na Windows), ale v popisu budeme vycházet z MS implementace v doménovém prostředí.

V článku se řeší nastavení klienta, aby bylo možno používat Single sign-on vůči aplikaci na serveru. Jako klienty bereme Microsoft Windows, které jsou zařazeny do domény, celá SSO autentizace probíhá vůči Active Directory a uvažujeme pouze protokol Kerberos. Samozřejmě naše serverová aplikace musí SSO podporovat. Hlavně se budeme věnovat webovým aplikacím a tedy konfiguraci webových prohlížečů a hromadné konfiguraci pomocí Group Policy.

V minulých článcích jsme se věnovali popisu protokolu Kerberos a jeho použití při Single sign-on. Dále používání SSO z pohledu Windows klienta, primárně při ověřování k webové aplikaci. Dnes se podíváme na druhou stranu a to na webový server a využití SSO v naší webové aplikaci. Základní popis je obecný, ale v detailech musíme vycházet z přesně daných podmínek. Opět budeme využívat to, že máme správu uživatelů v doméně Active Directory, a tedy autentizace vůči AD pomocí protokolu Kerberos. Klienti budou na Windows, tak jak jsme je popsali v minulém článku. Na serveru budeme využívat aplikační server Apache a malá zmínka kódu se bude týkat jazyka PHP.

Již od Windows Server 2000 jsou součástí MS Active Directory (AD) atributy pro uložení obrázku (fotografie) k uživatelskému účtu. Tyto údaje můžeme využít v některých aplikacích (třeba Instant Messaging), které načítají údaje o uživatelích z AD. A hodí se, pokud používáme adresář pro personální data. Nově jsou fotografie z AD podporovány v MS Outlook 2010. Vkládání obrázků do AD není složité, ale existují různé možnosti, které si zde popíšeme.

Active Directory asi všichni používáme (pokud jsme na MS platformě) pro centrální identity management (zjednodušeně správu uživatelů a autentizaci). Ale otázka je, kolik firem využívá množství atributů, které můžeme u uživatele nastavovat. Přitom různé personální či organizační údaje většinou evidujeme v personálních systémech. Tomu se sice nevyhneme, ale můžeme zadat (či exportovat nebo synchronizovat) tyto údaje do AD. A k čemu je to dobré? Například poštovní klient Outlook může tyto údaje zobrazovat a zjednodušit nám komunikaci.

Tak už i na mne dolehl PowerShell, ne že bych se mu bránil, ale hodně věcí udělám radši v GUI. Pro různé hromadné úpravy či výpisy určitých hodnot, se jedná o velice užitečného pomocníka. Myslím ale, že PowerShell není vytvořen zrovna User Friendly, takže pokud něco nepoužíváme pravidelně, není možné si to zapamatovat (neobsahuje takovou jednoduchou a chytrou nápovědu jako Cisco IOS). Proto jsem začal vytvářen tento seznam užitečných příkazů (a jejich variací), abych měl v případě potřeby, kam nahlédnout.

Pokud chceme logovat operace (zaznamenávat události do logu) nad Active Directory Domain Services (AD DS) - prakticky jde o vytváření, měnění či mazání uživatelských a počítačových účtů a skupin, tak využijeme funkci auditování AD DS. Tento audit byl možný již dříve a to obdobným způsobem, ale Windows Server 2008 přináší rozšíření a zpřesnění. Nově můžeme auditovat pouze určitou podkategorii (vylepšené nastavení nabízí Windows Server 2008 R2), u změn se loguje i původní a nová hodnota (ne jen kdo a jaký atribut změnil) a také se změnily ID událostí.

Novinkou na doméně (lese) ve funkčním stupni Windows Server 2008 R2 je koš (Recycle Bin). Myslím, že je to užitečná vlastnost, i když jsem ji za rok, co je zapnutá, použil pouze jednou. Rozhodně ničemu neškodí. Dělá to, co každý tuší. Smazaný objekt v Active Directory Domain Services (AD DS) se přesune do koše a jej možné je obnovit do původního stavu.

Článek se věnuje ukládání šifrovacích certifikátů do Active Directory. Jak k nim potom přistupují klienti jako je Outlook nebo OWA. Jaké mohou nastat problémy, když přejdeme na novou certifikační autoritu, a klientům se z AD nabízí stále staré certifikáty. A také různým PowerShell příkazům, pomocí kterých můžeme s certifikáty v AD pracovat.

SYSVOL je důležitý sdílený adresář, který se nachází na všech doménových kontrolerech (DC). A právě proto, aby se nacházel stejný na všech DC, tak se využívají replikace. Od Windows 2000 Server jsou replikace řešeny pomocí File Replication Service (FRS). Při přechodu na doménu Windows Server 2008 se standardně stále používá FRS, ale je možno celkem jednoduše přejít na novější a lepší Distributed File System Replication (DFSR). Jak na to si stručně popíšeme zde.

Nový Windows Server 2012 přináší i novou verzi Active Directory Domain Services. Jednou z novinek je i způsob instalace, kdy se již nepoužívá dcpromo, ale PowerShell nebo Server Manager.

Když provozujeme certifikační autoritu od MS, což se hodí skoro pro každou firmu, tak je dobré nastavit určité logování operací. Do té doby můžeme sledovat informace, třeba o selhání vystavení certifikátu, pouze v konzoli certifikační autority. Článek je pouze pro přehled, stejné informace nalezneme přímo u MS.

Článek popisuje problém, na který jsem nedávno narazil. Jde o situaci, kdy máme uživatele, který je členem velkého množství skupin. Nejprve jsem narazil na problém u webové aplikace, která využívá SSO a to přestalo fungovat. Řešení je úprava konfigurace Apache nebo Tomcatu. Pak jsem narazil na problém ve Windows 7, kdy se uživatel přestal korektně autentizovat (přitom některé funkce stále fungovaly).

Dosud jsme se věnovali průběhu Kerberos autentizace (SSO) v rámci jedné domény (Realmu). Výhoda protokolu Kerberos je, že umí navazovat vztahy mezi Realmy a provádět autentizaci Cross-Realm. V případě Microsoft domén to znamená, že když máme navázaný vztah důvěry mezi nějakými doménami, tak nám automaticky funguje autentizace. Uživatelský účet se může nacházet v jedné doméně a server (služba) v jiné, uživatel se přesto přihlásí pomocí SSO.

V článku se podíváme na nějaké možnosti hledání problémů, když nastavíme Single Sign-On (SSO) autentizaci pomocí protokolu Kerberos a automatické přihlášení přesto nefunguje. Jako autentizační server uvažujeme AD doménový řadič. Většina možností je obecná, ale v praktických příkladech budeme uvažovat situaci, kdy jde o autentizaci k webové aplikaci z prohlížeče.

Vítejte u prvního dílu seriálu, který se věnuje protokolu Kerberos se zaměřením na Single Sign-On (SSO) v prostředí Microsoft Active Directory. Dnešní díl se přímo Kerberos protokolu nevěnuje, ale popíšeme si základní termíny Active Directory, které potřebujeme znát, a s kterými Kerberos autentizace souvisí (když ji používáme v doménovém prostředí). Stručně zmíníme AD komponenty, protože struktura souvisí s Kerberos Realm. Dále si popíšeme, jak klient hledá doménový řadič (což je zároveň Kerberos autentizační server).

Druhá část seriálu o protokolu Kerberos, se zaměřením na Single Sign-On (SSO) v prostředí Microsoft Active Directory, naváže na první díl a nebude se věnovat Kerberosu, ale věcem okolo Active Directory Domain Services. Docela podrobně se podíváme na přihlašovací jména uživatelských účtů, tedy User Principal Name (UPN) a sAMAccountName. V závěru ještě popíšeme jména instancí služeb (Service Principal Name).

Starší článek, popisující přechod z verze 2003 na 2008 R2 je docela populární. Takže nyní přináším popis přechodu Active Directory Domain Services (AD DS) na aktuální verzi Windows Server 2012 R2. Jde o přidání nových doménových řadičů (Domain Controller) Windows Server 2012 R2, přesun rolí a funkcí, odstranění původních serverů a na závěr povýšení funkčního stupně domény. Mělo by jít o docela jednoduchý proces, ale v praxi se samozřejmě objeví řada problémů.

Již je tu rok, kdy (řekněme) oficiálně končí podpora hashovacího algoritmu SHA-1 v certifikátech. Doporučení je, co nejdříve přejít na SHA-2. Pokud interně využíváme Microsoft Certification Authority, tak je také dobré provést tuto změnu. Naštěstí to (ve většině případů) není nic složitého a jde pouze o pár změn na stávající certifikační infrastruktuře. O této oblasti se na internetu hodně píše, ale nenalezl jsem nějaký souhrnný článek, takže jej přináším zde.

Na počítačích, serverech a obzvláště doménových řadičích může nastávat řada bezpečnostních událostí, které bychom měli hlídat a kontrolovat. Ve Windows využíváme logy událostí (Event Log) kam se zaznamenává mnoho situací. Pro různé události si můžeme nastavit, zda a kdy je chceme do logu ukládat. To řešíme nastavením auditování (Security Auditing). To ale samo nestačí. Dále je potřeba auditní log událostí nějak automatizovaně zpracovávat a vybírat informace, které jsou pro nás důležité, a ty si někde zobrazovat či zasílat.

Článek uvádí obecnější informace, jak ve firemním prostředí s Microsoft doménou změnit heslo doménového uživatele (který je aktivní s platným heslem). Detailně možnosti záleží na prostředí, a využívaných službách, dané společnosti. Neřešíme zde situace s exspirací hesla, kdy může vyskakovat dialog na změnu. Zato se podíváme na situace, kdy uživatel pracuje vzdáleně. Když změníme heslo doménového účtu, tak často musíme udělat několik dalších kroků, protože se různě používá staré heslo. Trochu podobná je situace, když se změní uživatelské jméno (například při změně příjmení).

Stručně se podíváme na možnosti konfigurace Microsoft Network Policy Server (NPS), který využijeme jako RADIUS server pro bezdrátové sítě (WLAN). Popíšeme možnost vytvořit více profilů pro různé WLAN (SSID). Zmíníme běžné ověřovací metody, které využijeme pro ověření Active Directory uživatelů nebo počítačů při přihlášení do WiFi. Včetně situace s autentizací ve Windows 11 od verze 22H2 (Credential Guard).

Podíváme se na autentizační protokol Kerberos. Hlavní zaměření je zablokování slabé a nebezpečné šifry RC4 a kompletní přechod na AES šifrování. Tomu se budeme věnovat v druhé části. V tomto článku projdeme fungování Kerberos protokolu, které je docela důležité znát pro provádění změn. Zaměříme se na šifrovací algoritmy a klíče, obecněji typy šifrování. Hlavní je, jak se volí použitý typ šifrování, tedy jestli se využije RC4 nebo AES. Mimo teoretických informací si ukážeme nějaké příkazy pro zjišťování údajů a nastavování parametrů pro šifrování. Na konci trochu rozebereme Microsoft aktualizaci 11/2022, která částečně mění chování a přináší nové možnosti. Při zveřejnění patrně obsahovala chybu, na kterou snad již nenarazíme.

V první části jsme se věnovali teorii fungování Kerberos protokolu a volbě typu šifrování. Dnes navážeme praktickými příklady. Jak detekovat tickety s RC4. Jak hledat účty, které nemají povolen AES nebo nemají vystaveny AES klíče. Jaké informace a chyby můžeme nalézt mezi událostmi v logu na doménovém řadiči. Kde mohou být problémy, pokud používáme Keytab soubory. Pro většinu věcí budeme využívat PowerShell. Na závěr si uvedeme jak vynutit použití AES a zablokovat RC4.

Jak lépe a bezpečněji řešit servisní účty pro běh služeb nebo naplánovaných úloh v prostředí Microsoft Active Directory domény. Již dlouho máme k dispozici spravované servisní účty. Managed Service Accounts byly přidány s Windows Server 2008 R2. Pomáhají řešit identity služeb s vyšším zabezpečením a snižují režii na správu. Administrátor se nemusí starat o hesla, protože bezpečnou správu hesel k účtům zajišťuje operační systém Windows. Slouží k neinteraktivnímu běhu aplikací, služeb, procesů či úloh, které potřebují bezpečnou identitu (credential).