Práce s právy nad SharePoint objekty není vůbec snadná a přitom Vás pořád dokola nutíme držet v nich pořádek. Proč je to tak důležité? Ti co byli na SharePoint konferenci už ví (a berte to jako malé opakování), pro všechny ostatní to bude krátké shrnutí.

Tak za prvé: Pokud udržíte pořádek v právech, portálové stránky budou rychlejší, bez debat. Zní to trošku jako levný marketingový slogan, ale máme to prokazatelně naměřeno na projektech, kde už jsme oprávnění čistili – občas je redukce času potřebného k načtení čištěných objektů i 50% a jde to logicky vysvětlit. Každá kolekce, web, list nebo knihovna dokumentů s individuálně nastavenými oprávněními představují tzv. security scope objekt, každý tento security scope objekt má svůj unikátní seznam oprávnění, kterému se říká ACL („Access Control List“) a v něm může být jen omezený počet tzv. „security principal“ objektů, členů. Ke knihovně souborů celkem bez problémů přidáte 100, 200 i 300 různých uživatelů, můžete je přidat přímo, můžete rušit dědění nad jednotlivými soubory a přidat lidí ještě víc, ale vše má své limity.

Nejprve si trochu ujasněme ony pojmy. Kamil k tomu říká:

Security Scope je jakýkoliv SharePoint objekt s individuálně nastavenými oprávněními. Nastavíte dokumentové knihovně individuální oprávnění? Vytvořili jste security scope. Nastavíte dokumentu v knihovně individuální oprávnění? Vytvořili jste security scope. A obecně platí – čím méně security scope objektů v rámci webu / kolekce webů máme, tím lépe.

Security scope objekty si na úrovni obsahové databáze můžete vypsat např. takto:

SELECT [SiteId], [ScopeId], [RoleDefWebId], [WebId], [ScopeUrl], [Acl] FROM [your Content DB].[dbo].[Perms] order by scopeurl

Klíčové je přitom vědět, že počet security scope objektů v rámci jednoho seznamu / knihovny by neměl překročit číslo 50 000. Toto číslo je ale spíše teoretický, než praktický limit. Jen samotný fakt, že takovýto počet security scope objektů na úrovni jednoho seznamu či knihovny lze vytvořit neznamená, že to máte v praxi dělat. Překročíte-li hodnotu 5000 (výchozí hodnota omezující počet položek pro zobrazení v rámci seznamu), pak sami uvidíte, co bude následovat. Zpomalení vykreslování obsahu daného seznamu / knihovny může být citelné.

Každý security scope obsahuje svůj Access Control List, v němž jsou tzv. Security Principal Objects. Mezi ně, v rámci SharePoint prostředí, počítáme skupiny či uživatelské účty z libovolného adresáře či služby, kterou SharePoint využívá (Active Directory, LDAP, SQL…), plus navíc i SharePoint skupiny.

Ostatně zkuste u vybrané obsahové databáze následující SQL dotaz, možná budete překvapeni:

select COUNT(ra.PrincipalId) as [Count],p.ScopeUrl
from RoleAssignment ra with(nolock)
join Perms p with(nolock) on p.SiteId = ra.SiteId and p.ScopeId = ra.ScopeId
group by p.ScopeUrl
order by [Count] desc

U ACL je důležité si pamatovat, že celková velikost ACL na jednom security scope je max. 64kb a protože jeden security principal má průměrně 32bytů, tak jeden security scope může mít cca 2000 security principals. Překročíte-li tuto hodnotu, začnou se dít divné věci. Nejen že objekt se Vám už nemusí podařit nikdy nikam přesunout, ale nám v tomhle bodě jde hlavně o to, že každý pokus o otevření složky nebo souboru uvnitř takového objektu stojí portál hromadu výpočtů proti ACL listům pro získání výsledných (efektivních) práv, která má uživatel mít. To mohou být za určitých podmínek až celé vteřiny. Vyhledávací služba může rovněž kompletně odmítnout vložit daný objekt do indexu. V crawl logu v tomto případě uvidíte chybové zprávy „Parameter is incorrect.The filter daemon did not respond within the timeout limit.“.

Pokud jste to nepochopili nevadí, zajděte si ke Kamilovi na školení a on Vám všechno vysvětlí :o)
Za druhé: Proces indexace bude rychlejší a výsledky přesnější. Jak víme, každý uživatel v SharePointu vidí jen to, na co má přiřazena práva. A práva jsou při speciálním druhu indexace zvané „Security-only crawl“ porovnávána opět s těmi už známými ACL listy, plus navíc s listy uloženými v administrativní databázi hledání pro posouzení změn. Pokud tedy bude uživatel přidaný přímo k dokumentu uvnitř knihovny, která bude vložená do stránek s dalšími, unikátními právy, a ta stránka bude náhodou vstupní (takže společná všem dalším 4000 zaměstnancům firmy přiřazených pro jistotu přímo) „Crawler“ se hodně zapotí, protože 64 kb limit byl překročený už na úrovni kolekce. Porovnávat pak každou další změnu s tak obludně obrovským ACL listem je časově velmi náročné.
Dalším zdržovadlem, i když máte v právech relativně pořádek, jsou klasické „SharePoint Groups“. Zařazení člověka do takové skupiny automaticky znamená, že daší naplánovaná úloha bude kromě klasických přírustků zároveň typu „security-only“, protože je potřeba přepočítat výsledná práva uživatelů. Změna ACL vždy vynutí security crawl. Opakovaným testováním je dokázáno, že manipulace s AD skupinami, tedy změna členů AD skupiny, do EventCache (tedy do tabulky uvnitř Content DB, kam se zapisují všecky změny co musí být (mimo jiné) hledáním zpracovány) nic nepíše. Změna členů AD skupiny totiž nezpůsobí změnu ACL. A že „security-only“ úlohy jsou ty dlouhé, dost těžko předvídatelné úlohy, které mohou běžet několik hodin… Záleží na počtu (unikátních) objektů, kterým pozměněná skupina patří. Opět malý příklad naměřený z praxe, nepořádek v právech dokáže zpomalit proces indexace 10 až 12x.

Bod třetí: Správa práv bude jednodušší. Pokud Váš portál není jen sada pěti stránek s kalendářem, je často těžké plnit úkoly typu „přidej mi stejná práva jako má Petr Novák“  nebo „vypiš mi všechny objekty všech kolekcí, kam vidí Tonda Dvořák“, a to nemluvíme o situaci, kdy na Vás přijde audit… Kromě toho delegace práce s právy na správce stránek (obsahu) bez systému a pravidel je za takových podmínek naprosto nemožná. Všechna ta unikátnost, dědění a různé úrovně oprávnění dokáží zamotat hlavu i zkušeným AD adminům, natož dobrovolníkům, kteří jen chtějí přidat nováčka svého týmu k jedné malé knihovně dokumentů.

Jak vypadá takový nepořádek, o kterém tu celou dobu mluvím? Pozorně se zadívejte na obrázek níže, který představuje jednu celou site bez jakýchkoliv dalších unikátností a rušeného dědění. Co je špatně?

… asi tak úplně všechno. Jaký smysl mají uživatelé přidaní přímo s úrovní „Limited“? Pravděpodobně prodědení, ale tady jsou nám opravdu k ničemu. Co pak celé doménové „domain users“ skupiny s „Limited“ ? Pro jistotu přidané znovu ve skupině „Portal members“…  Například uživatel označný jako Filip má tedy „Limited“ přímo, „Read“ skrz „domain users“ skupinu, „Contribute“ díky „Portal Members“ skupině a protože je rovnou správce (což z obrázku nevyčtete, ale věřte mi), tak dostane k tomu všemu ještě „Full Control“ přes skupinu „Portal Owners“. A to nemluvím o tom, že všechny „built-in“ skupiny (Viewers, Approvers apod.) jsou přiřazené, ale nepoužívané a prázdné.

Vyčištěné to samé místo může vypadat nějak takto:

Všichni přečtou, správci upraví, členi týmu zapíšou.

Chcete v portále také takový pořádek? Naše rada zní: Používejte AD skupiny a přiřazujte jim napřímo SharePoint úrovně oprávnění. Vyhněte se SharePoint skupinám!

… tak, pokud teď otevřete Google a začnete pátrat po tom jestli máme pravdu, můžete se začíst na dobré dva nebo i tři dny a stejně budou odpovědi nejednoznačné, protože názory na strategii se hodně liší. Jsou lepší SharePoint skupiny nebo ty ADčkové? Co nějaký mix? Od jaké úrovně je vhodné použít tu a od které zas tamtu? Mno, přidávám sem srovnávací tabulku „Pro“ a „Proti“ výroků a rozhodněte se sami, nicméně ať už si vyberete jakoukoliv strategii, držte se jí za každou cenu a udržujte v právech pořádek. A pokud to nezvládáte, čemuž bychom se nedivili, pořiďte si na to vhodný nástroj nějaké třetí strany.

Poznámka první: AD skupina musí být vždy typu „security“, jinak s ní nejde pracovat a v prostředí s více doménamy také „Domain Global“, což nemusí chtít každý. Přiřazené „Domain Local“ skupiny jsou vidět jen u účtů vždy stejné domény (cz\sp-cesta-role bude u účtu cz\tomas.novak), což neznamená, že v nich nemohou být zařazení ostatní (nl\nicky.jackson), jen to ve vlastnostech nebude vidět. To může být pro správce matoucí.
Toto nicméně platí jen pro multidoménové prostředí. Jsme si dobře vědomi toho, že dle Best-Practices zásad (ADLP strategii) jsou to právě Domain Local skupiny, kterým mají být přiřazena oprávnění.
Poznámka druhá: Nepoužívejte „built-in účty“ a už vůbec ne „Guest“ účet, „Everyone“ účet a „Authenticated users“.
Poznámka třetí: Existuje limit 1024 security skupin na jeden účet, nicméně to doufám nikdy nikde neuvidím. On existuje limit i na počet položek jednoho ACL listu a dá se poměrně jednoduše navyšovat, ale tím ničemu nepomůžete.

Co ještě dodat? Pokud to jde, nepoužívejte práva přidaná přímo uživatelům. Už tři lidé jednoho místa mohou být skupina. Tam kde to opravdu nejde (a že takové případy mohou být naprosto oprávněné) si jen znamenejte seznam vyjímek. Pokud to jde, zrušte zbytečně porušené dědení. Pokud to jde, spolupracujte při čištění s vlastníky dat, možná Vám ulehčí práci a nebudete muset nahrazovat všechno.

Já osobně nepoužívám na čištění žádný specielní nástroj, občas ani žádný k dispozici nemáte. Dříve než se pustím do samotného nahrazování, prozkoumám portálové místo od spoda, od nejmenších unikátností směrem k rootu webu a připravím si několik odpovídajících prázných AD skupin (resources) dopředu. Pokud to jde, rovnou je naplním existujícími hromadnými distribučními skupinami, protože než je budu potřebovat, musí se uživatelé minimálně jednou znovuověřit vůči kontroleru (přehlásit/přihlásit).

Skupiny vytvářím vždy po třech podle rolí (i když vím, že je nezaplním, jsou připravené). Pokud pro jejich pojmenování použijeme strukturu firmy (hierarchii stránek, projekty, cokoliv logicky členěného uvnitř Vaší firmy), mohou vypadat například takto:
Res-SP-Oddeleni-Tym-Objekt-Admins  (správci webu nebo podle struktury manažeři) Res-SP-Oddeleni-Tym-Objekt-Members  (členi týmu nebo oddělení) Res-SP-Oddeleni-Tym-Objekt-Visitors  (uživatelé jiných oddělení s právy pro něco uvnitř, hosté)

… s malými písmenky, s podtržítky místo pomlček, česky (bez háčků) nebo anglicky, to je na Vás. Během práce samozřejmě narazíte i na skupiny, které pravidlem tří být vyráběné nemohou a nemusí:
Res-SP-Technology-Content-Admins  (správci obsahu daného oddělení) Res-SP-All  (všichni uživatelé portálu, všechny XX\domain users skupiny)

Název by měl být co nejkratší, zkratky jsou OK, ale musí dávat nějaký smysl tomu, kdo bude se skupinami pracovat. Do „description“ skupin vždy vkládám adresu objektu, pro který je vytvořena a do poznámky viditelné jen pro správce nechávám vzkazy ostatním kolegům. Skupiny jsou pro čtení všem, ale tam kde mám šikovné správce obsahu, deleguji správu do specielních OU.

Poté co máte založené odpovídající AD skupiny, upozorněte uživatele na probíhající změny mailem nebo informačním pruhem v záhlaví stránky a pusťte se do čištění od spoda (od jednotlivých souborů v knihovnách s unikátními právy) směrem nahoru k rootu webu. Pozor, tohle je nesmírně důležité! Nikdy nezačínejte rootem webu, po odstranění zdánlivě nepotřebných skupin Vám může zůstat hromada sirotků bez práv a těžko dohledáte kdo kde byl. Práva nemají historii. Odstraňte duplicity, triplicity a zbytečnosti a nahraďte stávající SharePoint skupiny za nové ADčkové. Na druhou stranu, jak jednou přiřadíte práva složce v knihovně, záznam o nové skupině se dostane automaticky nahoru ke knihovně samonté s příznakem „Limited access“ (pokud je knihovna s nepřerušeným děděním, klidně až k rootu stránky) a pak je jednoduché měnit oprávnění tak jak potřebujete a nemusíte ji znovu hledat.

Hned jak skončíte, napište uživatelům, že potřebujete nově nastavená práva otestovat. Nechte si tak týden na testování a pokud se během té doby nic neobjeví, pokračujte přípravami na další čištění někde jinde. Postup toho, co už máte hotové, si někam značte. K tomuto účelu dobře slouží Visio mapa stránek, kde si můžete v atributech sbírat seznam správců a vlastníků dat, stejně jako čištěných míst. Hlídejte nejbližší další hledací úlohu a pokud jsou změny rozsáhlé, klidně znovu sestavte nové indexy.

Poznámka nakonec: Nesnažte se nahradit úplně všechno a všude. Buď si přizvěte na pomoc správce jednotlivých stránek nebo si dohodněte úroveň, po kterou chcete jít, například čtvrtý level a konec. Např. web oddělení – podweb týmu – důležitý objekt s unikátními právy – složka. Čas a počet skupin potřebných pro čištění se hodně špatně odhaduje, za sebe mohu říci, že poměrně malý portál o 1 milionu položek s hodně složitými právy čistím už 20 víkendů a jsem na 900 skupinách.

Diskuze na toto téma je možná uvnitř naší VIP sekce.