V jednom ze svých předchozích příspěvků jsem se dotkl autentizačního protokolu Kerberos. Dnes se mu budu věnovat podrobněji. Podíváme se především na to, jak nakonfigurovat počítač s SharePointem 2010 tak, aby pro autentizaci uživatelů využíval právě protokol Kerberos. Na úvod musím říct, že na webu je mnoho článků, které se tomu věnují, ale mnohé si protiřečí, obsahují jen část toho, co je potřeba udělat nebo obsahují chyby. Proto jsem se rozhodl to vyzkoušet a rozchodit. A řeknu vám: byl to boj.

Co to je Kerberos?

Kerberos je standardizovaný autentizační protokol vyvinutý na MIT, který Microsoft implementoval do svých operačních systémů. Podporuje ho od verze Windows 2000. Na rozdíl od protokolu NTLMv2 (nejčastěji používaný autentizační protokol ve Windows sítích) má následující výhody:

1. Je otevřený - jeho bezpečnost není založena na tom, že útočník neví, jak to funguje, ale na tom, že všichni ví jak to funguje a mohou bezpečnost zkoumat a chyby zveřejnit.
2. Je standard - jeho změna je sice možná, ale procesně dlouhá, takže se o ní pravděpodobně dozvíte dříve, než ji Microsoft implementuje. U proprietárních řešení si nemůžete být jisti, od které aktualizace jejich chování změní.
3. Je bezpečnější - nejenže využívá propracovanějšího schématu, ale je založen i na bezpečnějších kryptografických konstruktech.
4. Umožňuje delegaci - tzn. umožňuje, aby služba (v našem případě SharePoint) použila identitu uživatele a s jejím pověřením přistupovala k dalším službám. Díky tomu může zprostředkovat uživateli data (nebo funkcionalitu) ke kterým by SharePoint (resp. účet pod kterým běží) neměl přístup.

Kerberos využívá tzv. ticketů. To jsou v podstatě časově omezená potvrzení vydaná autentizačním serverem. Ty používá klient k prokazování své identity.

Blízký pojem k delegaci je pojem impersonace, který se používá častěji, hlavně ve světe ASP.NET. Někdy dochází k záměně resp. zmatení těchto pojmů, proto uvedu základní vlastnosti:

Impersonace

• Služba přijme identitu volajícího (nebo taky nějakého konkrétně zadaného) uživatele.
• Služba, která využila impersonaci, se tváří (předstírá), že běží v kontextu jiného uživatele.
  
• Platnost impersonace je omezena na počítač, na kterém proces běží.
• Lze ji použít jak s NTLM tak s Kerberem
  

Delegace

• Služba běží v kontextu účtu, který ji byl přidělen.
  
• Služba, která využívá delegace, komunikuje s ostatními službami s tím, že komunikaci provádí na základě pověření (delegace) dotyčného uživatele. To služba dokládá použitím ticketu uživatele.
  
• Platnost delegace je omezena na služby, které mají možnost ověřit si platnost ticketu (mají kontakt s autentizačním serverem, typicky počítače v doméně) a tím, jak je možnost delegace uživatelova účtu nastavena (zda je možné jej delegovat a zda to může provést příslušná služba, viz. dále).
• Tohle NTLM neumí
  

 Rozdíl v tom, co umožňuje delegace Kerbera, ukazují následující obrázky:

Obrázky ukazují komunikaci mezi servery a účty pod nimiž komunikace/přístup může probíhat.

Nevýhody použití Kerbera vůči NTLM:

1. Díky propracovanosti je to složitější.
2. Je potřeba další konfigurace na úrovni domény i konkrétních služeb, aby to běželo.
3. Potřebuje ještě propustný port 88 pro vyřízení komunikace s autentizačním serverem.
   

Zprovoznění Kerbera

Rozchození Kerbera pro účely SharePointu se skládá z konfigurace na úrovni domény a konfigurace na služby. Konfigurace služby se v případě SharePointu skládá s konfigurace IIS serveru a SharePointu samotného.

Vytvoření SPN

Klíčovým pojmem ve světě kolem protokolu Kerberos je tzv. SPN (service principal name) do češtiny Microsoftem překládaný jako hlavní jméno služby. Kerberos ho používá jako identifikátor služeb. Službou je v tomto případě myšlen nějaký software, se kterým můžete komunikovat a který vás chce identifikovat. Proces autentizace obecně sebou nese 2 problémy:

1. Jak volající/uživatel prokáže, že je tím, za koho se vydává?
2. Jak volaný/služba prokáže, že je tím, koho chce uživatel volat a tedy ten, komu je ochoten prozradit svou identitu?

A právě druhý problém řeší SPN. V doméně existuje registr důvěryhodných služeb. Pokud se nějaká služba pokusí o autentizaci volajícího pomocí protokolu Kerberos a není v tomto registru, pokus bude automaticky neúspěšný. Pokud tedy chcete, aby vaše aplikace mohla autentizovat uživatele pomocí Kerbera, musíte mít v doméně registrované SPN. A jak takové SPN vypadá? Je to vlastně skupina následujících údajů:

1. protokol - HTTP, MSSQLSvc, ...
   
2. jméno počítače
3. číslo port - nepovinný údaj, standardní protokoly mají svá standardní čísla protokolů a proto je v SPN není potřeba uvádět
   
4. název doménového účtu, pod kterým služba běží - v našem případě se jedná o doménový účet, pod kterým běží aplikační pool webové aplikace SharePointu.

v následujícím formátu: protokol/plné jméno počítače:port doménový účet službu. Příklad http/pocitac.domena.cz:2145 domena\login

Práce se SPN se provádí pomocí příkazu SETSPN. Ten podporuje přidávání, změnu, mazání a zobrazení existujících SPN. Na manipulaci s registrovanými SPN musíte mít pochopitelně odpovídající doménová práva.

Pro potřeby SharePointu potřebujeme, aby v doméně bylo zaregistrováno SPN pro HTTP protokol, FQDN(úplné doménové jméno) počítače na němž SharePoint běží a doménový účet, pod kterým běží IIS aplikační pool SharePointu. Pokud SharePoint běží na jiném portu než 80, je potřeba do SPN přidat i číslo portu. Příklad:

SetSPN -S HTTP/Portal.vmlab.local  vmlab\svcportal10App.

Pokud provozujete více SharePoint aplikací, které se liší portem, nebo doménovým jménem IIS aplikačního poolu, pod kterým běží, budete potřebovat i více SPN.

Nastavení delegace

I když je delegace úžasná věc, je potřeba být opatrný, protože to je dvousečná zbraň. Dvousečnost spočívá v tom, že uživatel si nemůže být jistý (nemá nad tím kontrolu) k čemu server jeho identitu použije. Může tedy jen doufat, že server s ní dělá to, co slibuje a nerozesílá místo toho např. spam. S tímhle rizikem naštěstí ale autoři protokolu počítali a dali správcům možnost omezit, k čemu (jakým dalším severům) může server uživatelskou identitu delegovat. Stejně tak se dá nastavit, že daný uživatelský účet nelze delegovat.

Nastavení delegace se provádí v Active Directory ve vlastnostech účtu.

Z obrázku je vidět, že delegaci lze docela pestře konfigurovat. Lze ji:

• zakázat (výchozí stav)
• povolit ji a omezit tak, že dotyčný účet (resp. služba běžící pod tímto účtem) ji může použít pouze ve vztahu k dalším službám používajícím Kerberos autentizaci
• povolit ji a omezit tak, že dotyčný účet (resp. služba běžící pod tímto účtem) ji může použít pouze ve vztahu k službám s vyjmenovanými SPN

U uživatelských účtů se silnými právy se doporučuje zakázat možnost jejich delegace:

 

Konfigurace IIS

Podporu Kerbera je potřeba zapnout i zde. Ve správci IIS si vyberte webovou aplikaci SharePointu a v poté v hlavní části správce otevřete zabezpečení.

Zde můžete konfigurovat nejrůznější formy autentizace uživatelů. Nás bude zajímat windows autentizace, takže ji vyberte ze seznamu nabízených způsobů autentizace.

Poté je potřeba pomocí akce "Providers..." vybrat toho správného providera.

V nabídce je jich několik:

1. Negotiate
2. NTLM
3. Negotiate:LiveSSP
4. Negotiate:Kerberos

A tady už to začne jet z kopce. Volba NTLM je jasná. Negotiate:LiveSSP už možné méně (jedná se o autentizaci pomocí LiveID), ale tou se také nebudeme zabývat. Zbývá nám tedy Negotiate a Negotiate:kerberos. Obě varianty představují Kerberos. To označení Negotiate souvisí s autentizační metodou v rámci protokolu Kerberos. Ten totiž v rámci své definice podporuje několik metod autentizace a jednou z nich je právě metoda Negotiate. A aby to nebylo tak jednoduché, tak varianta Negotiate:Kerberos reprezentuje metodu Negotiate2, která je novější variantou Negotiate. Bohužel v IE 8 obsahuje chybu v implementaci této metody, takže ani tato varianta nepřipadá v úvahu, protože při jejím využití se uživatelé s IE 8 nepřihlásí, což ho jistě nepotěší.

Ve výsledku je vlastně pro Kerberos jedinou použitelnou variantou volba Negotiate.

V pokročilých nastaveních ještě zkontrolujeme, že je vypnutá Kernel-Mode autentizace a Extended Protection.

Konfigurace SharePointu

Na webu centrální administrace v sekci Security -> General Security -> Specify Authentication provider klikněte na jméno zóny, pro kterou chcete Kerberos nastavit. Tím se dostanete na stránku nastavení:

Poznámky a nástroje, které by se mohly hodit

Poznámky:

• Jako první bych chtěl zdůraznit následující fakt. V případě lokálního přístupu ke službě se VŽDY použije NTLM autentizace. Pokud tedy chcete něco okolo Kerbera ladit, musíte přistupovat k službám po síti, nejlépe z jiného počítače.
• NTLM autentizace se použije i v případě, že v URL použijete IP adresu a ne doménové jméno serveru. V takovém případě totiž není možné určit, které registrované SPN by se mělo použít. S danou IP adresou může existovat několik doménových jmen a tudíž i několik SPN.
• Pro MS SQL existuje příkaz, kterým si ověříte, pomocí jakého protokolu jste aktuálně autentizováni: select auth_scheme from sys.dm_exec_connections where session_id=@@spid .Výsledek pak může vypadat nějak takto:

Nástroje:

• setspn - pro manipulaci se SPN. Pomocí příkazu SETSPN -l domena\loginname můžete vypsat všechna SPN týkající se zadaného doménového účtu. Stejně to funguje i se jménem počítače:
• Kerbtray.exe - je součástí Windows 2000 Resource Kitu a Windows 2003 resource kitu. Program běží v tray. Zobrazí vám Kerberos tickety, které aktuálně vlastníte.
• KList - je součástí Windows 2000 Resource kitu (dá se stáhnout samostatně), nebo součástí Windows 2003 Resource kitu. Pomocí tohoto příkazu (je to program příkazové řádky) si můžete nechat vypsat aktuálně vydané tickety.
• Fiddler - dokáže zachytit a zobrazit komunikaci prohlížeče s okolím. Tedy i tu která souvisí s Kerberem.
• Network Monitor - zachytává data na úrovni TCP. Nízkoúrovňové ladění.
• Dalším užitečným zdrojem informací o tom, co se ohledně Kerbera děje, je Event log. Je potřeba ale zapnout podrobnější logování Kerberos událostí. To uděláte pomocí úpravy registrů. Popis najdete zde.
  

Další zdroje:

• Configuring Kerberos Authentication for Microsoft SharePoint 2010 Products - dokument ve wordu
• Configure Kerberos authentication (SharePoint 2010) - článek na TechNetu
• Troubleshoot Kerberos Errors - dokument ve Wordu. Vysvětluje chybové kódy Kerbera, které najdete v Prohlížeči událostí, a popisuje v čem může být problém.

Závěr

Autentizace uživatelů pomocí protokolu Kerberos má smysl pouze v případě, že chcete využít některou z jeho vlastností, kterou má navíc oproti NTLM. V ostatních případech nevidím, vzhledem k nutnému úsilí na rozchození, jeho použití jako účelné.

Nejčastěji využívanou je schopnost delegace, tzn. že SharePoint je schopen použít identitu uživatele k tomu, aby přistoupil k dalšímu systému (službě).

Druhým scénářem, který využívá výhody delegace, je situace, kdy nějaká stránka v SharePointu zobrazuje údaje z dalšího systému podle toho, který uživatel se na stránku dívá (a podle toho jaká má v daném systému práva).

Oba scénáře se potkávají při integraci SharePointu s Reporting Services MS SQL serveru, kdy SharePoint zobrazuje report umístěný na ReportServeru a ten report zobrazuje data, na která má uživatel práva, získaná z dalšího serveru.