Ondrej Sevecek's Blog

Aktualizace 27.9.2012

Nejprve několik poznámek po delší době ladění u různých zákazníků. Článek popisuje zprovoznění delegace pro služby Excel Services a PerformancePoint Services. Obě jsou téměř stejné, mají dohromady jen jediný rozdíl. Týká se to pouze SharePoint 2010 a SQL Server 2008 R2. Novinky v SharePoint 2013 a SQL Server 2012 zmíním v jiném článku.

Pro informaci, je úplně jedno, jestli se uživatel do web-frontend webové aplikace ověřuje pomocí Classic Mode Authentication, nebo Claims Based Authentication. V obou případech to Security Token Service (STS), který běží na tom konkrétním front-endu, přeloží správně na vnitřní claims XML.

Také bych poznamenal, že jiné služby, jako je Business Data Connectivity Services (BDC), nebo SQL Reporting Services (SQL RS), tuto technologii nepoužívají. Tedy přesně řečeno, nepoužívají Claims to Windows Token Service (C2WTS) a tím pádem se jich článek vůbec netýká. Tyto dvě služby pracují s normální Kerberos delegací (Kerberos constrained delegation) bez technologie protocol transition.

V případě Business Data Connectivity Services (BDC) i Reporting Services (RS) na SharePoint 2010 a SQL Server 2008 R2 nelze použít webovou aplikaci, která by měla zapnuto Claims Based Authentication. Oba potřebují Classic Mode Authentication - jinak nebudou schopni klasicky delegovat. Tyto dva kámoši začínají být na větší samostatný článeček, který snad v brzku vyplodím :-)

A už hurá na původní článek

Zrovna minulý týden jsem strávil čtyři hodiny rozcházením Performance Point Services (PPS) tak, aby se do zadního datového zdroje přistupovalo přímo pod identitou uživatele (As user), který do SharePointové webové aplikace sám přichází. A to není žádná sranda :-) Vyžaduje to znalosti Kerberos delegation, o které si samozřejmě můžete přečíst v mém starším článečku. Nebo dojděte rovnou na školení do GOPASu. Máme k tomu například kurz GOC16 Kerberos Troubleshooting, případně GOC176 SharePoint Advanced Architecture and Troubleshooting.

Jen ještě pro info - dělal jsem to zadarmo pro kamaráda, pana Kamila Juříka z WBI, takže až vám to budou někde nasazovat, tak tohle peklo jsem je naučil já :-)

Proč to tu píšu je, protože to zaprvé chci vysvětlit a za druhé tady budou správné informace, na rozdíl od oficiálních článků přímo z dílny Microsoftu, které vřele nedoporučuju - psal to nějaký chaotik, který absolutně netušil, vo co go.

Samochvála smrdí. Takže raději už jdem na to :-)

Autentizační vnitřnosti SharePoint

Podívejte se nejpreve na obrázek, musíme si ujasnit jaké uživatelské účty se používají pro kterou službu. Mám to namalované pro případ právě Performance Point Services (PPS), ale platí to obecně pro celou SharePoint architekturu. Dokonce bez ohledu na to, jestli to máte celé na jednom serveru, nebo to máte rozložené na více operačních systémů.

V obrázku vidíte dva modré IIS web servery (SRVWFE01 a SRVWS01) a nějaké databázové servery. Web Front-End (WFE) je ten počítač, na němž běží v IIS nějaká webová aplikace, v mém případě asi nazvaná intranet s public URL třeba http://intranet. Na ni přistupuje doménový uživatel Honzík. Při přístupu se ověří pomocí svého doménového loginu a hesla, nebo možná čipovou kartou a certifikátem. V případě Performance Point Services (PPS) je úplně jedno, jestli se ověří pomocí NTLM, nebo Kerberos. To by nebylo jedno v případě Business Connectivity Services (BCS), ale pro PPSko nás to překvapivě vůbec nezajímá.

Tedy samozřejmě raději uděláme Kerberos, protože je výkonově úspornější, nevyskakují chaoticky přihlašovací okna a je bezpečnější. Dále je úplně jedno, jestli máte zapnutu claims-based authentication, nebo používáte starší classic mode authentication. Stejně se v obou případech okamžitě po přístupu přemění AD identita Honzíka na XMLkový claims token, kterému SharePoint vnitřně rozumí a používá ho jako uživatelovu identitu.

Tím Honzík vstoupí do farmy. Uvnitř se děje něco, co vysvětlíme detailněji za chviličku. Pro samotného uživatele je podstatné, že do zadního datového zdroje - v našem případě nějaká SQL Server Analysis Services OLAP služba a její OLAP Discovery služba - se leze pod jeho účtem. To je logické ne? Mám SQL BI udělané pro doménové uživatele, proč bych tam složitě definoval jinou bezpečnost.

Uvnitř farmy je to ale něco jiného. WFE běží pod dvěma účty, tedy sp-farm a sp-intranet. Pod sp-farm účtem běží front-endové služby serveru a pod účtem sp-intranet běží samotná webové aplikace (sharepoint web application), na kterou Honza přistupuje. Pod těmito dvěma účty si to čte data ze svých konfiguračních databází (ConfigDB, AdminContent) i z obsahových databází (ContentDB).

Takže Honzíka v těchto databázích vůbec SQL server neuvidí. Jediné dva účty, které do něho lezou jsou sp-farm a sp-intranet. Přístup si kontroluje samo .ASPX uvnitř front-endových aplikací.

Přístup do zadní web service application

Co se dějě, když Honzík chce vidět nějaká data ze zadní PPS? Služba PPS běží možná na jiném web serveru. Určitě ale běží ve vlastní web service application (WSA) pod svým vlastním účtem sp-pps (jsem samozřejmě masochista, všechno vždycky běží pod svým vlastním účtem :-)). Pod tímto účtem také přistupuje do své vlastní databáze PPSDB, ve které má konfigurace a vůbec svoje data.

I služba PPS ale musí být schopna vidět Honzíkovu identitu. Musí vědět kdo k ní ve skutečnosti přistupuje. K tomuhle byste pro čistě Windows ověřování mohli použít Kerberos delegation, ale v tomhle případě se to nepoužije. SharePoint prostě jen dozadu pošle ten XML claims token, který si vygeneroval při přihlášení Honzíka na WFE.

To musí takhle fungovat. Do SharePointu nechodí jen Windows uživatelé. Když máte forms-based authentication, nebo Active Directory Federation Services (ADFS), potřebná Kerberos delegation by nefungovala. Takže SharePoint ta přihlášení prostě nějak vnitřně standardizuje do formy toho claims tokenu.

Claims token je digitálně podepsaný. Generuje ho služba Security Token Service, kterou máte na každém SharePoint web serveru ve farmě. V tomto případě ho tedy vygeneroval STS běžící přímo na WFE.

Malá odbočka - SharePoint vnitřní certifikační autorita

Digitální podpis je pomocí RSA certifikátu, který si při připojení do farmy každý web server vygeneruje. Jestli jste si toho nevšimli, SharePoint farma má svoji vlastní certifikační autoritu - tedy privátní a veřejný RSA klíč a certifikát. To je všechno uloženo v konfigurační databázi (a zašifrováno pomocí passphrase). Takže SharePoint si sám generuje vlastní certifikáty a sám si své autoritě věří. Váš počítač jí pro zajímavost nevěří, jen SharePoint sám vnitřně.

Na obrázku můžete vidět ty podepisovací certifikáty a také SSL certifikát, který je automaticky nastaven pro SSL na portu 32844 pro Web Service Applications web site.

Certifikát oné vnitřní SharePoint certifikační autority si můžete prohlédnout a klidně i vyexportovat pomocí PowerShellu:

Get-SPCertificationAuthority
(Get-SPCertificationAuthority).RootCertificate.Export('cert')

Zpátky k ověřování

Takže do PPS přijde už jenom XML balíček (claims token), ve kterém je napsána identifikace uživatele Honzík. A tady to začíná být zajímavé.

PPS potřebuje znát členství doménového uživatele Honzík ve skupinách a vůbec mít k dispozici jeho access token. Jiné služby by to třeba ani nepotřebovaly, ale PPS to chce. K tomu ovšem potřebuje metodu, jak ten claims token překonvertovat zpět na windows access token. Tohle dělá Claims to Windows Token Service (C2WTS) - v mém obrázku běží pod účtem sp-c2wts.

A ten už k tomu bude potřebovat Kerberos constrained delegation s protocol transition (to je taková ta volba Trust this account for delegation to specified services only - Any authentication protocol). Proč?

No nepřišlo nic. Služba by buď musela dostat rovnou nějaký Kerberos TGS, nebo by musela mít k dispozici přímo login a heslo uživatele. Ani jedno ale v ruce nemá. Takže až zde začíná nastavení delegací podle následující tabulky:

Poznámky k tabulce - delegace je jasná včetně všech jejích podmínek - to je podle mého dřívějšího článku. Jen je možná divné, že účet sp-c2wts musí delegovat sám na sebe. On prostě sám potřebuje Kerberos tiket, aby si z něho mohl udělat access token. Tak proto.

Jakmile má služba C2WTS Honzikův access token, může jeho obsah (token sám předat nejde) předat zpět službě PPS. Služba PPS dále potřebuje přístup do zadního OLAPu a případně dalších služeb, na které přistupuje. K tomu potřebuje opět Kerberos delegation with protocol transition, protože ani ona nic lepšího o Honzikovi nedostala.

Poznámky - služba PPS nepotřebuje SeTcbPrivilege, protože nepotřebuje lokální (impersonation) access token - potřebuje jen síťový, takže SeTcbPrivilege není potřeba. SPN hodnoty pro SQL Analysis Services si musíte už udělat sami, na to tu nemáme místo :-)

Přístup služby zpět do content database

A jen pro pořádek, ještě jedna informace. Každá back-endová služba jako je Excel Services, PerformancePoint Services i Reporting Services musí být schopna chodit zpět do content databáze. Tedy do té, ve které je příslušná site collection (kolekce webů), pro kterou ta služba zrovna pracuje.

Přistupuje tam ale pod svým servisním účtem (v našem případě sp-pps). Tady se tedy už nejedná o delegaci, ale o normální přístup služby do databáze.

Musíte pro ni tedy v SQL serveru vytvořit login a přidělit jí db_owner přístup do všech content database (databáze obsahu), do kterých se má dostat.

Ale jak říkám, zde se nejedná o delegaci, takže tabulku Delegation v Active Directory měnit nemusíte, a SPN pro SQL server tam dávat tedy nemusíte.