Včera jsem dostal podnět k napsání tohoto článečku na základě tohoto, kde někdo píše, že distribution group se dá v SharePoint údajně použít pro přidělení přístupu. Je to tam tak jednoduše mimochodem zmíněno, takže se stalo, že autorské emvípí (MVP) zmátlo jiné emvípí a tak to třetí emvípí musí napravit.
Nedá. Oficiální článek o verzi SharePoint 2013 je zde. Ano, Microsoft poskytuje návod, jak údajně "expand a distribution group and add the individual members to a SharePoint group" - například tady.
Když si ten support přečtete, tak pochopíte, že se jedná o ruční vybrání seznamu emailových adres z té skupiny a natvrdo naplnění do SharePointu. Já se nehádám, to samozřejmě jde udělat pomocí PowerShell skriptíku na 2 řádky.
Ale fakt je, že distribution group se pro zabezpečení použít nedá. Podívejme se proč.
A současně zničme populární fámu, že distribuční skupina nemá SID.
Distribution group má SID
Ano. Distribuční skupina je v podstatě úplně stejná skupina v Active Directory LDAP databázi, jako jakákoliv jiná bezpečnostní skupina. Je to typ objektu (class) group. Má objectSID atribut a ten se taky naplní unikátním SIDem hned při vytváření. SID se generuje běžným unikátním způsobem za použití RID FSMO master role.
Poznámka - o RID managerovi si můžete přečíst v několika mých starších poustech jako je tady, zde, tuten, tenhleten nebo tudlenc.
Jeden rozdíl mezi security group a distribution group je hodnota atributu groupType. V případě distribution group ne-obsahuje zapnutý bit 0x80000000, který tam je jen pro security group (viz. ADS_GROUP_TYPE_ENUM). Druhý rozdíl je v atributu sAMAccountType, kde je pro distribution group hodnota 268435457 (NON_SECURITY_GROUP_OBJECT), zatímco security group tam má hodnotu 268435456 (GROUP_OBJECT).
Jinak je to z pohledu LDAP úplně stejné.
Distribution group se nevyhodnocuje při ověřování a nepřidává se do access token
Proč by se tedy distribution group nedala použít k zabezpečení? No ona by se i dala. SID má, takže použít se v podstatě dá. Jenom je vám to na nic. Protože v této skupině v podstatě "nejste".
Při příhlašování si DC vytváří seznam vašich skupin. Tento seznam potom putuje přes NTLM, nebo Kerberos tiket do uživatelova access token. O téhle skupině jsem tu psal už ohledně omezení na počty položek, nebo když jde o aktualizaci členství ve skupinách.
V každém případě se do něho nedostane nic jiného, než bezpečnostní skupiny. Domain controller při ověřování uživatele členství v distribučních skupinách vůbec nevyhodnocuje. Prostě je v databázi nehledá a ignoruje.
SID distribuční skupiny se tedy může objevit na NTFS, nebo v SharePointu. Nebude mít ale efekt, protože stejný SID se v access tokenu uživatele nikdy neobjeví.
Zřetězené členství
Jen pro úplnost dodejme, že byste mohli mít v ADčku dokonce skupiny zřetězené do mixu. Jakože distribuční skupina by byla členem bezpečnostní a to by zase mohlo být členem jiné distribuční apod. Asi to nenaklikáte, ale principiálně by to šlo.
V každém případě to ale poruší řetěz skupin, takže členství při ověřování se vyhodnocuje pouze v souvislé security group oblasti.