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.

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.