Jak zjistíte, jaká oprávnění má skupina AD, pokud nemáte dokumentaci?

Dovolte mi předmluvu, jaká bude pravděpodobně dlouhotrvající odpověď s „Neexistuje jednoduché řešení“.
Řešení tohoto problému bude vyžadovat nějakou strategickou práci (proto jsem doporučil ne přesunout to do SF).

Teď vysvětlím proč.

Windows, ve svém jádru, je většinou založena na DAC model řízení přístupu.
Vše v OS je zabezpečitelné pomocí ACL - soubory, složky, registr, pojmenované kanály, zásuvky, sdílené položky atd. Atd.

Používání AD skupin vám umožňuje abstraktní to na model typu RBAC, ale interně je to stále model DAC. (Mám na mysli to, že pro skupinu (tj. Roli) můžete vytvořit ACE (položka řízení přístupu), ale stále vytváříte ACE - a to je to, co bude při přístupu ověřeno).

Důraz na "většinou".
Existuje několik zřetelných výjimek:

1. Existuje určitá implementace MAC - tj. Úrovně integrity (ve Vista/7/2008).
   Nicméně, toto je obvykle a interní mechanismus ochrany OS a obvykle se ne využívá pro skutečné řízení přístupu (jiné než vestavěný UAC). Obvykle .
2. Oprávnění na úrovni OS. (Ačkoli je možné určit konkrétního uživatele, kterému tato oprávnění udělit, je určen - a funguje jako - model RBAC).

Ale počkejte, to je jen v samotném OS ...
Windows jako platforma umožňuje a povzbuzuje aplikace (produkty třetích stran, produkty MS a doplňky OS) k použití členství ve skupině AD jako mechanismu RBAC:

1. Aplikace třetích stran mohou ověřit členství ve skupině pomocí jednoduchého vyhledávání AD/LDAP - tyto aplikace mohou ukládat název skupiny a řešit na něm, nebo ukládat SID skupiny a přímo na to zadávat dotazy.
2. Nezapomeňte na SQL Server - to je hlavně založeno na (několika různých typech) rolí, ale doporučeným postupem je obvykle do těchto rolí přidat AD skupiny, nikoli přímo uživatelé.
3. Dokud jsme u toho, COM + také řídí přístup pomocí RBAC, ale opět nejlepší praxí je přidávat skupiny, ne uživatele, do rolí COM +.
4. Sharepoint také řídí přístup k webům podle rolí/skupin/a seznamů adresátů ...

Začínáte vidět můj názor?
Nechci říkat, že je to beznadějné, ale ...

Shrnout:
Chcete-li najít konečný seznam oprávnění, která má určitá skupina, musíte (nebo nástroj) rekurzivně zkontrolovat VŠECHNY z následujících (a nezapomeňte také opakovat členství ve skupině):

• Pro každý server ve vašem orgu:
  • rekurzivně zkontrolujte ACL ve všech složkách a souborech
  • rekurzivně zkontrolujte SACL ve všech složkách a souborech (seznamy řízení přístupu k systému - tyto kontrolní audity)
  • rekurzivně zkontrolujte vlastníka ve všech složkách a souborech
  • rekurzivně zkontrolujte ACL, SACL a vlastníka na všech klíčích registru
  • rekurzivně kontrolujte ACL, SACL a vlastníka na všech pojmenovaných potrubích, procesech a vláknech, službách, úlohách atd.
  • Zkontrolujte všechna oprávnění na úrovni operačního systému (i když je to možné pomocí GPO ...)
  • Zkontrolujte všechny role COM +, MSMQ atd.
• Pro každou doménu vaší reklamy:
  • Zkontrolujte všechna oprávnění na úrovni domény
  • zkontrolovat všechny objekty zásad skupiny (objekty zásad skupiny)
• Pro každý databázový server:
  • Zkontrolujte všechny role serveru
  • zkontrolujte všechny role databáze
  • zkontrolovat všechny aplikační role (v MSSQL)
• Pro každý portál Sharepoint:
  • zkontrolujte všechny role a oprávnění na úrovni serveru
  • zkontrolujte všechny role a oprávnění na úrovni webu a na úrovni seznamu
• Pro každou aplikaci třetí strany:
  • Zkontrolujte použití skupin AD
  • ověřit jak aplikace používá tyto role:
    -> Název skupiny vs. DN vs. skupina SID vs. ... např. GUID skupiny
    -> kontroluje aplikace výslovně kontrolu přímého členství v roli nebo používá „chytřejší“ rekurzivní metody?
  • Toto platí jak pro produkty a platformy zabalené třetími stranami (např. Oracle, SAP, MQSeries, WebSphere ...), tak pro obchodní aplikace vyvinuté na míru.

Je to kompletní?
Bohužel ne. Například jsem nezahrnul přezkoumání všech stolních počítačů v org, protože u těch shouldnt ​​jsou na nich nastavena specifická oprávnění na úrovni AD skupiny (kromě např. Administrátorů a HelpDesk) - ale poznámka které často dělají.
Ale toto není úplný seznam ...

To je velká nevýhoda použití modelu DAC - „D“ by mohl být stejně dobře použit pro „Distribuovaný“, protože neexistuje centrální místo pro vyhledávání všech těchto ACL.
Jak jsem poznamenal v Jaký je rozdíl mezi RBAC a DAC/ACL? :

• Definice DAC jsou obvykle připojeny k datům/zdrojům, zatímco RBAC je obvykle definována na dvou místech: v kódu/konfiguraci/metadatech (přístup k rolím) a na uživatelském objektu (nebo tabulce - role, které má každý uživatel).

Teď něco o řešeních:

• Existuje několik nástrojů pro shromažďování různých částí výše uvedených seznamů, např. @ Ianova odpověď pomocí skriptů powershell ke shromažďování ACL složek. Existuje mnoho dalších nástrojů k tomu (bylo mi známo, že používám CACLS v minulosti), některé jsou známé zde .
  Pro vyžádání nástroje/skriptu pro konkrétní část seznamu byste mohli získat lepší nápady na ServerFault. Vezměte však v úvahu, že je to pouze jedna část seznamu.
• Existují produkty „správy rolí“ a „objevování rolí“ od některých velkých dodavatelů, obvykle v prostoru správy identit - nemůžu jeden konkrétně doporučit, ale stojí za to prozkoumat: CA (dříve Eurekify, což byl slušný (i když ne úplný) nástroj), IBM , Oracle .
  Samozřejmě existují i ​​další a já bych se naklonil těžce k nalezení nejlepších prodejců menších prodejců, a to i od spuštění (v pořádku, možná jsem zkreslený;)). Myslím tím, od těch, které nebyly odkoupeny většími prodejci.
• Mohli byste (a pravděpodobně byste měli, i když to zdaleka není triviální) zahájit proces mapování organizace, obchodních požadavků a podobně - zaměřit se na jaká privilegia by měla get, a nejen co je současný stav právě teď . Některé z nástrojů uvedených v předchozím bodě by zde mohly pomoci.
• Pokud předchozí analýza rolí a modelování proběhnou dobře, zvažte řešení plně rozvinutého řešení IdM/IAM/EAM. Opět platí, že moje komentáře wrt prodejci stále stojí.
• V každém případě usilujte o minimalizaci distribuce ACL na celém místě a prosadte minimální RBAC, co nejvíce centralizované.

A poslední varovné slovo pro ty, kteří mají to štěstí, že jsou před nepříjemnou situací, ve které se momentálně ocitnete:
Rozhodně podívejte se na centralizovanou autorizační platformu, jako jsou produkty IdM/IAM/EAM. (Všimněte si, že některé jsou mnohem lepší než jiné, a některé by ani tuto situaci nevyřešily.)

tl; dr: Jste správně a skutečně zašroubovaní . Viz výše. ;)
(ale veškerá naděje není ztracena ...)

Odpověď na to závisí přesně na tom, jak chcete tato data zobrazit/spravovat. Mým doporučením by bylo PowerShell, abychom to všechno získali.

Pokud se rozhodnete používat PowerShell, můžete použít nativní AD Cmdlets nebo Quest Cmdlets zdarma (http://www.quest.com/powershell/activeroles-server.aspx). Chcete-li používat nativní Cmdlets, musíte mít ve své doméně alespoň jeden řadič domény Windows Server 2008 R2 nebo alespoň jednu instanci v sadě konfigurace AD ​​LDS, která je spuštěna na serveru Windows Server 2008 R2 - viz http: //technet.Microsoft.com/en-us/library/ee617195.aspx pro podrobnosti.

Ve skutečnosti stačí jen rekurzivně zkontrolovat ACL složky pro přístupovou úroveň určité skupiny. Existuje několik míst ( zde a zde ), kde se lidé pokoušejí, ale vzhledem k tomu, že se jedná o neuvěřitelně velké množství struktur souborů, které skript musí procházet, by určitě mohl nějakou dobu trvat. Pro vnořené skupiny je to ještě složitější.

ÚPRAVA: @AviD je na místě o původní syntaxi příkazu a dělala úplně špatnou věc! Upraveno tak, aby bylo více na téma.

To lze provést příkazem Windows Prompt takto:

• Přejděte do adresáře, do kterého chcete sestavu uložit, pokud ji nikdo nevybral, měla by být výchozí adresář přihlášeného uživatele. Příkladem by bylo cd C:\Users\Administrator\Desktop

• Vytvořte sestavu pomocí následujícího příkazu:

  gpresult /s servername /user INTERNAL\user1 /h gpreport.html
  

• Výše uvedený příkaz vygeneruje sestavu založenou na GPOS a pravidlech použitých pro uživatele, pro kterého je sestava vybrána. Tento uživatel by měl být někdo, kdo je členem určité skupiny, nebo byste mohli vytvořit zkušebního uživatele, který otestuje nastavení určité skupiny.

• Dalším způsobem, jak tyto informace najít, je editace GPO) a ve Windows 2008 byste měli mít možnost vidět všechna nastavení a setřídit je podle stavu, pak byste mohli zaznamenat všechna povolená nastavení GPO.