it-swarm.dev

Come scopri quali autorizzazioni ha un gruppo AD se non disponi di documentazione?

Sei appena stato assunto dalla compagnia A e il vecchio amministratore non è più lì. Le richieste iniziano ad arrivare per l'aggiunta di utenti al gruppo di restrizioni Internet. Quando guardi i gruppi nessuno dei nomi ha senso e non c'è documentazione là fuori per spiegare a cosa ciascun gruppo ha diritti e cosa fa. Ciò desterebbe preoccupazione per me. Per sicurezza come fai a sapere se tutti hanno i diritti corretti.

Come scopriresti a cosa hanno diritto i gruppi? Esiste uno strumento là fuori che troverà queste informazioni per te?

20
Ambar Batista

Vorrei prefigurare quella che probabilmente sarà una risposta a lungo termine con "Non esiste una soluzione semplice".
Per risolverlo ci vorrà un po 'di lavoro strategico (motivo per cui ho raccomandato no di spostarlo su SF).

Ora spiegherò perché.

Windows, al suo interno, si basa principalmente sul modello DAC del controllo di accesso.
Everything nel sistema operativo è protetto con un ACL: file, cartelle, registro, named pipe, socket, condivisioni, ecc. Ecc.

L'uso di gruppi AD consente di astrarre ciò in un modello di tipo RBAC, ma internamente è ancora un modello DAC. (Ciò che intendo è che è possibile creare un ACE (voce controllo accessi) per un gruppo (ovvero ruolo), ma si sta ancora creando un ACE - e questo è ciò che verrà verificato all'accesso).

Enfasi su "principalmente".
Vi sono alcune distinte eccezioni a questo:

  1. Esiste una certa implementazione del MAC, ovvero Livelli di integrità (in Vista/7/2008).
    Tuttavia, si tratta in genere di un meccanismo di protezione del sistema operativo interno e di solito non sfruttato per un controllo reale degli accessi (diverso dall'UAC incorporato). Di solito .
  2. Privilegi a livello di sistema operativo. (Sebbene sia possibile specificare un utente specifico a cui concedere questi privilegi, è inteso - e funziona come - un modello RBAC).

Ma aspetta, è solo nel sistema operativo stesso ...
Windows, come piattaforma, consente e incoraggia le applicazioni (terze parti, prodotti MS e componenti aggiuntivi del sistema operativo) a utilizzare l'appartenenza al gruppo AD come meccanismo RBAC:

  1. Le applicazioni di terze parti possono verificare l'appartenenza al gruppo tramite una semplice ricerca AD/LDAP: queste app potrebbero archiviare il nome del gruppo e risolverlo o salvare il SID del gruppo e interrogarlo direttamente.
  2. Non dimenticare SQL Server: si basa principalmente su (diversi tipi di) ruoli, tuttavia in genere si consiglia di aggiungere AD gruppi a questi ruoli e non gli utenti direttamente.
  3. Finché ci siamo, COM + gestisce anche l'accesso tramite RBAC, ma di nuovo la migliore pratica è quella di aggiungere gruppi, non utenti, ai ruoli COM +.
  4. Sharepoint gestisce anche l'accesso ai siti in base a ruoli/gruppi/e mailing list ...

Cominciando a vedere il mio punto?
Non voglio dire che è senza speranza, MA ...

Per ricapitolare:
Per trovare l'elenco definitivo delle autorizzazioni di un gruppo specifico, tu (o uno strumento) dovresti controllare ricorsivamente TUTTO quanto segue (e, non dimenticare di ricorrere anche all'appartenenza al gruppo):

  • Per ciascun server nell'organizzazione:
    • controllare ricorsivamente ACL su tutte le cartelle e tutti i file
    • controllare ricorsivamente SACL su tutte le cartelle e tutti i file (elenchi di controllo di accesso al sistema - questi controlli di controllo)
    • controlla ricorsivamente il proprietario su tutte le cartelle e tutti i file
    • controllare ricorsivamente ACL, SACL e proprietario su tutte le chiavi di registro
    • controllare ricorsivamente ACL, SACL e proprietario su tutte le pipe, i processi e i thread, i servizi, i lavori, ecc.
    • Controlla tutti i privilegi a livello di sistema operativo (anche se è possibile ciò può essere semplificato utilizzando gli oggetti Criteri di gruppo ...)
    • Controlla tutti i ruoli COM +, i ruoli MSMQ, ecc.
  • Per ogni dominio nel tuo annuncio:
    • Controlla tutti i privilegi a livello di dominio
    • controlla tutti gli oggetti Criteri di gruppo (oggetti criteri di gruppo)
  • Per ciascun server di database:
    • Controlla tutti i ruoli del server
    • controlla tutti i ruoli del database
    • controlla tutti i ruoli dell'applicazione (in MSSQL)
  • Per ciascun portale Sharepoint:
    • controlla tutti i ruoli e i privilegi a livello di server
    • controlla tutti i ruoli e i privilegi a livello di sito e di elenco
  • Per ogni applicazione di terzi:
    • Controlla qualsiasi utilizzo di gruppi AD
    • verifica how l'app utilizza questi ruoli:
      -> Nome gruppo vs. DN vs. gruppo SID vs. ... ad es. GUID di gruppo
      -> l'app verifica esplicitamente l'appartenenza diretta al ruolo o utilizza i metodi ricorsivi "più intelligenti"?
    • Si noti che ciò vale sia per prodotti e piattaforme impacchettati di terze parti (ad es. Oracle, SAP, MQSeries, WebSphere ...) sia per app aziendali sviluppate personalizzate.

È completo?
Purtroppo no. Ad esempio, non ho incluso la revisione di tutti i desktop nell'organizzazione, poiché quelli non dovrebbero hanno autorizzazioni specifiche a livello di gruppo AD impostate su di essi (ad eccezione di amministratori e helpdesk ) - ma nota che spesso lo fanno.
Ma questo non è un elenco completo ...

Questo è il grande svantaggio dell'uso di un modello DAC: il "D" avrebbe potuto essere lo stesso per "Distributed", poiché non esiste un posto centrale per cercare tutti questi ACL.
Come ho notato in Qual è la differenza tra RBAC e DAC/ACL? :

  • Le definizioni DAC sono in genere associate ai dati/alla risorsa, mentre RBAC è generalmente definito in due posizioni: in codice/configurazione/metadati (accesso ai ruoli) e sull'oggetto utente (o tabella - i ruoli che ciascun utente ha).

Ora, un po 'di soluzioni:

  • Esistono diversi strumenti per raccogliere diverse parti degli elenchi di cui sopra, ad es. @ La risposta di Ian usando gli script PowerShell per raccogliere gli ACL delle cartelle. Ci sono molti altri strumenti per questo (sono stato conosciuto per usare CACLS in passato), alcuni sono noti qui .
    Per richiedere uno strumento/script per una parte specifica dell'elenco, potresti ottenere idee migliori su ServerFault. Tuttavia, tenere presente che è solo una parte dell'elenco.
  • Esistono prodotti di "gestione dei ruoli" e di "individuazione dei ruoli", di alcuni dei grandi distributori, di solito nello spazio Identity Management - non posso specificatamente consigliarne uno, ma vale la pena esaminarlo: CA (precedentemente Eurekify che era uno strumento decente (anche se non completo)), IBM , Oracle .
    Naturalmente ce ne sono altri, e mi spingerei pesantemente verso la ricerca di venditori più piccoli e migliori, anche da una startup (okay, forse sono di parte;)). Voglio dire, da quelli che non sono stati acquistati dai più grandi venditori.
  • Potresti (e probabilmente dovresti, anche se questo è tutt'altro che banale) iniziare il processo di mappatura dell'organizzazione, requisiti aziendali e simili - mirando a quali privilegi dovrebbero get, e non solo qual è lo status quo in questo momento =. Alcuni degli strumenti menzionati nel punto precedente potrebbero aiutare qui.
  • Se l'analisi dei ruoli precedenti e la modellazione vanno bene, prendi in considerazione l'idea di una soluzione IdM/IAM/EAM completa. Ancora una volta, i miei commenti sui venditori sono ancora validi.
  • In ogni caso, mira a ridurre al minimo la distribuzione di ACL in tutto il luogo e Push per un minimo RBAC, centralizzato il più possibile.

E, un'ultima parola di avvertimento per coloro che sono abbastanza fortunati da essere prima la spiacevole situazione in cui ti trovi attualmente:
Sicuramente esamina una piattaforma di autorizzazione centralizzata, come i prodotti IdM/IAM/EAM. (Nota che alcuni sono molto migliori di altri, e alcuni non risolverebbero nemmeno questa situazione.)


tl; dr: Sei giustamente e veramente fregato . Vedi sopra. ;)
(Ma non tutta la speranza è persa...)

23
AviD

La risposta a questo dipende esattamente da come vorresti vedere/gestire questi dati. La mia raccomandazione sarebbe PowerShell per ottenere tutto questo.

Se si sceglie l'utente PowerShell, è possibile utilizzare i cmdlet AD nativi o i cmdlet gratuiti di Quest (http://www.quest.com/powershell/activeroles-server.aspx). Per utilizzare i cmdlet nativi, è necessario disporre di almeno un controller di dominio Windows Server 2008 R2 nel dominio o almeno un'istanza in un set di configurazione AD LDS in esecuzione su un server Windows Server 2008 R2 - vedere http: //technet.Microsoft.com/en-us/library/ee617195.aspx per i dettagli.

In effetti, tutto ciò che devi fare è controllare ricorsivamente gli ACL delle cartelle per il livello di accesso di un determinato Gruppo. Ci sono alcuni posti ( qui e qui ) in cui le persone fanno tentativi, ma dato che questa è probabilmente una quantità incredibilmente grande di struttura di file che lo script deve navigare, esso potrebbe sicuramente richiedere del tempo. Diventa ancora più complicato per i gruppi nidificati.

EDIT: @AviD è perfetto sulla sintassi del comando originale e stava facendo completamente la cosa sbagliata! Modificato per essere più in tema.

4
Ian Pugsley

Questo può essere fatto tramite il comando Prompt di Windows come segue:

  • Vai alla directory in cui vuoi salvare il tuo rapporto, se nessuno lo seleziona dovrebbe essere predefinito nella directory dell'utente che ha effettuato l'accesso. Un esempio potrebbe essere cd C:\Users\Administrator\Desktop

  • Genera un rapporto usando il seguente comando:

    gpresult /s servername /user INTERNAL\user1 /h gpreport.html
    
  • Il comando sopra genererà un rapporto basato sul GPOS e sulle regole applicate all'utente per cui è selezionato il rapporto. Questo utente dovrebbe essere qualcuno che è membro di un determinato gruppo o potresti creare un utente di prova per testare le impostazioni di un determinato gruppo.

  • Un altro modo per trovare queste informazioni è modificando il GPO e su Windows 2008 dovresti avere un'opzione per vedere tutte le impostazioni e ordinarle per stato, puoi quindi registrare tutte le impostazioni abilitate del GPO.

1