Utilizzo di ICACLS per impostare le autorizzazioni per le directory degli utenti


16

Sto cercando di ripristinare le autorizzazioni per le directory degli utenti e ho un po 'di problemi con l'ultimo passaggio del mio script. Il mio script fondamentalmente prende la proprietà dell'intera directory dell'utente, reimposta le autorizzazioni su tutti i file e le cartelle per la directory, concede esplicitamente le autorizzazioni di cui ho bisogno, interrompe tutta l'eredità delle autorizzazioni dalle cartelle principali, imposta il legittimo proprietario (utente specificato) per tutti i file e cartelle, quindi rimuove l'autorizzazione concessa a me stesso in modo da poter operare sui file. Ho bisogno di questo ultimo passaggio per rimuovere me stesso da TUTTI i file e le sottocartelle, ma al momento mi rimuove da% userDir% e lascia tutte le autorizzazioni ereditate di seguito. Questo è un difetto apparente in ICACLS. Qualcuno conosce un altro modo per ottenere questo risultato?

set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "E:\Home Directories\%userDir%" /r /d y
ICACLS "E:\Home Directories\%userDir%" /reset /T
ICACLS "E:\Home Directories\%userDir%" /grant:r "MYDOMAIN\%userDir%":(OI)(CI)F /grant:r "SYSTEM":(OI)(CI)F /grant:r "MYDOMAIN\%username%":(OI)(CI)F
ICACLS "E:\Home Directories\%userDir%" /inheritance:r
ICACLS "E:\Home Directories\%userDir%" /setowner "MYDOMAIN\%userDir%" /T
ICACLS "E:\Home Directories\%userDir%" /remove "MYDOMAIN\%username%"

Sto giocando con lo script XCACLS.vbs non supportato creato da Microsoft e ho avuto la fortuna di impiegarlo per l'ultima riga del mio script. Invece di questo ICACLS "E: \ Home Directory \% userDir%" / rimuovi "MYDOMAIN \% nome utente%" L'ho sostituito con cscript.exe xcacls.vbs "e: \ Test" / E / R "MYDOMAIN \% username% "Funziona, ma mi piacerebbe davvero evitare l'uso di XCACLS.vbs poiché ha gravi problemi di prestazioni. Altre idee?
pk.

Risposte:


18

Un'osservazione prima di tutto: ogni volta che blocchi l'eredità, ti tagli fuori dalla flessibilità futura. Evito di bloccare l'eredità a tutti i costi.

Se hai bisogno che gli utenti siano in grado di elencare i contenuti della cartella "E: \ Home Directories" di primo livello, ad esempio, considera le seguenti autorizzazioni:

  • SISTEMA - Controllo completo - Applicato a questa cartella, sottocartelle e file
  • BUILTIN \ Administrators - Controllo completo - Applicato a questa cartella, sottocartelle e file
  • BUILTIN \ Utenti autenticati - Leggi ed esegui - Applicato solo a questa cartella

L'ultima autorizzazione non eredita nelle sottocartelle. In ogni sottocartella, l'ereditarietà rimane abilitata e si specifica semplicemente l'utente con i diritti "Modifica" o "Controllo completo" (a seconda di come si ritiene che gli utenti siano in grado di impostare le autorizzazioni all'interno della propria directory home). (In genere ho impostato quest'ultima autorizzazione aggiungendo "Utenti autenticati" nella finestra delle proprietà di sicurezza non "Avanzate", deselezionando le caselle di controllo "Leggi" ed "Leggi ed Esegui". Procedere quindi nella finestra di dialogo "Avanzate" e modificare il Impostazione "Applica a" per quell'ACE su "Solo questa cartella". È il modo più semplice, in termini di numero di clic, di impostarlo.)

Quindi, il tuo script diventa:

set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "E:\Home Directories\%userDir%" /r /d y
ICACLS "E:\Home Directories\%userDir%" /reset /T
ICACLS "E:\Home Directories\%userDir%" /grant:r "MYDOMAIN\%userDir%":(OI)(CI)F
ICACLS "E:\Home Directories\%userDir%" /setowner "MYDOMAIN\%userDir%" /T

Sospetto fortemente che l'aggiunta dell'autorizzazione "Utenti autenticati" che ho descritto sopra con l'eredità impostata su "Solo questa cartella" ti darà ciò che stai cercando in funzionalità e ti darà flessibilità futura se lo scopri che è necessario impostare un'autorizzazione che potrebbe essere necessario ereditare in tutte le home directory degli utenti in futuro.

Questo è il mio SOP per le directory home degli utenti, le cartelle "Documenti", "Desktop", ecc. Reindirizzate e per le directory dei profili utente in roaming. Funziona benissimo.

modificare

ri: il tuo commento sull'accesso BUILTIN \ Administrators

Ho avuto vari argomenti con le persone sulla mia opinione sulla concessione dell'accesso BUILTIN \ Administrators nel corso degli anni e la mia opinione è questa:

  • È più facile risolvere una determinata classe di problemi dell'utente se riesci ad accedere ai loro file. "Prendere possesso" è una seccatura e può essere piuttosto lento se ci sono anche molti file presenti.

  • Come hai visto con ICACLS, BUILTIN \ Administrators può "assegnare" la proprietà (oltre a "prenderlo"), quindi non c'è "sicurezza" aggiunta non avendo i file accessibili a BUILTIN \ Administrators in primo luogo.

  • A meno che tu non stia usando il controllo (e setacciando un numero potenzialmente enorme di voci false positive) non ci sarà una pista di controllo quando un utente BUILTIN \ Administrators diventa proprietario dei file a cui non dovrebbe accedere, li copia e quindi restituisce i file al proprietario e all'autorizzazione "propri".

  • Nel mondo Microsoft, Encrypting filesystem (EFS) ha lo scopo di risolvere il problema di impedire l'accesso BUILTIN \ Administrators non autorizzato. Gli ACL NTFS non risolvono questo problema. (Ovviamente, EFS non è l'unico spettacolo in città. La crittografia è la vera risposta alla soluzione del problema "Limita l'accesso dell'amministratore di rete", non importa come lo tagli.)

A mio avviso, non specificare BUILTIN \ Administrators con accesso alle home directory degli utenti (e, di fatto, a qualsiasi cartella) significa che stai aumentando la complessità e il tempo necessari per risolvere i problemi fornendo meno della reale sicurezza ("minore di nessuno "perché impartisce un falso senso di sicurezza dove non ce n'è nessuno).

Ho smesso di provare a vincere l'argomento con le persone per logica. Sembra essere un problema emotivo con alcune persone. È come il ridicolo ACE "Nega / Ricevi come" che viene inserito nella radice di un'organizzazione di Exchange per impedire ad alcuni gruppi privilegiati di aprire le cassette postali degli utenti. Non offre alcuna sicurezza reale (poiché senza l'audit si potrebbe rimuovere / riapplicare l'ACE secondo necessità), un falso senso di sicurezza e si mette in mezzo quando si risolvono problemi reali.

Anche se non vi piace la mia tesi su BUILTIN \ Administrators avere accesso che si desidera mantenere la gerarchia di ereditarietà intatta utilizzando "Solo la cartella" eredità, se del caso. Il blocco dell'ereditarietà nelle gerarchie di autorizzazioni è un segno sicuro che qualcosa nel progetto è "rotto" (invertito, ecc.).


1
Consiglieresti di dare a BUILTIN \ Administrators pieno accesso all'intera struttura di directory? Sono dell'opinione che noi (amministratori) non dovremmo davvero avere pieno accesso alle directory / ai profili utente di tutti senza assumerne la proprietà.
pk.

+1, adoro i punti sul falso senso di sicurezza ...
DCookie

1

Innanzitutto, grazie per il tuo estratto dalla sceneggiatura. Ho lavorato sulla stessa cosa ma ero bloccato in un posto diverso. Sulla mia casella SBS 2008, il codice seguente funziona per me (supponendo che sia eseguito in modo elevato, ovviamente). Ho creato una icacls% userdir% / t di una nuova cartella utente (predefinita) creata dal sistema operativo e l'ho confrontata con la icacls% userdir% / t di una cartella dopo aver eseguito questo script e sembra che tutte le "O e "Ho ragione. Spero che funzioni anche per te.

set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "E:\Home Directories\%userDir%" /r /d y
ICACLS "E:\Home Directories\%userDir%" /reset /T
ICACLS "E:\Home Directories\%userDir%" /grant:r "MYDOMAIN\%userDir%":(oi)(ci)f
ICACLS "E:\Home Directories\%userDir%\*.*" /grant:r "SYSTEM":(OI)(CI)F /grant:r "MYDOMAIN\%userDir%":(OI)(CI)F /grant:r "MYDOMAIN\%username%":(OI)(CI)F
ICACLS "E:\Home Directories\%userDir%\*.*" /inheritance:r
ICACLS "E:\Home Directories\%userDir%\*.*" /setowner "MYDOMAIN\%userDir%" /T
ICACLS "E:\Home Directories\%userDir%" /remove "MYDOMAIN\%username%" /t

I migliori saluti,

 -d

Assicurati di verificare la riga finale del tuo script. È stata la mia esperienza che ICACLS non rimuoverà correttamente le autorizzazioni ereditate. Rimuove la voce nella cartella "MYDOMAIN \% username%", ma le autorizzazioni delle sottocartelle non vengono toccate. Pertanto, "MYDOMAIN \% username%" avrà comunque accesso alle sottocartelle se si accede direttamente, semplicemente non sarà possibile cercarle. XCACLS.vbs ha risolto questo per me. cscript.exe xcacls.vbs "e: \ Test" / E / R "MYDOMAIN \% nome utente%"
pk.

Ecco dove il .parte è arrivata sulla mia modifica. fare / ereditarietà: r nella cartella padre, ho avuto lo stesso problema. ma farlo . nella cartella principale sembrava fare il trucco. Dopo aver eseguito quanto sopra,% userdir% ha% username%, sistema e amministratori, ma tutto ciò che è solo% username% e sistema, che è come il server li ha impostati inizialmente - proprio quello che volevo.

-1

Ho bisogno del tuo aiuto per modificare questo comando in base alle mie esigenze se ciò è tecnicamente possibile.

Ecco la struttura

\ Server \ Parent \ UserA \ unix

\ Server \ Parent \ UtenteB \ unix

\ Server \ Parent \ UserC \ unix .... e così via ..

Sotto ciascuna cartella User $ è presente una cartella denominata "unix".

Voglio aggiungere un utente o un gruppo con autorizzazioni complete su tutte le cartelle User $ elencate nella cartella "Parent" (nomi presi come sopra della struttura) ma voglio escludere le autorizzazioni solo sulla cartella "unix".

Ho questo comando che funziona bene per me in prospettiva dell'applicabilità delle autorizzazioni richieste ma non posso aggiungere la funzione di esclusione in questo.

icacls "\\ Server \ Parent \ UserA" / grant Dominio \ Gruppo: (OI) (CI) F / T

Sarai in grado di guidare in questo scenario?


1
Ciao e benvenuto in Server Fault! Si prega di non porre domande tramite la risposta. Utilizzare il pulsante Poni domanda per pubblicare la richiesta.
Shunz,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.