Używanie ICACLS do ustawiania uprawnień do katalogów użytkowników


16

Próbuję zresetować uprawnienia do katalogów użytkowników i mam trochę problemów z ostatnim krokiem skryptu. Mój skrypt w zasadzie przejmuje własność całego katalogu użytkownika, resetuje uprawnienia do wszystkich plików i folderów dla katalogu, wyraźnie udziela potrzebnych uprawnień, zatrzymuje wszelkie dziedziczenie uprawnień z folderów nadrzędnych, ustawia prawowitego właściciela (określonego użytkownika) dla wszystkich plików i foldery, a następnie usuwa pozwolenie, które sam sobie dałem, aby móc operować na plikach. Potrzebuję tego ostatniego kroku, aby usunąć się ze WSZYSTKICH plików i podfolderów, ale w tej chwili po prostu usuwa mnie z% userDir% i pozostawia wszystkie odziedziczone uprawnienia poniżej. Jest to widoczna wada w ICACLS. Czy ktoś zna inny sposób na osiągnięcie tego?

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%"

Bawię się nieobsługiwanym skryptem XCACLS.vbs stworzonym przez Microsoft i miałem szczęście, wykorzystując go do ostatniego wiersza mojego skryptu. Zamiast tego ICACLS „E: \ Home Directories \% userDir%” / remove „MYDOMAIN \% username%” Zamieniłem go na cscript.exe xcacls.vbs „e: \ Test” / E / R „MYDOMAIN \% nazwa użytkownika% "To działa, ale naprawdę chciałbym uniknąć użycia XCACLS.vbs, ponieważ ma poważne problemy z wydajnością. Jakieś inne pomysły?
pk.

Odpowiedzi:


18

Najpierw spostrzeżenie: za każdym razem, gdy blokujesz dziedziczenie, odcinasz się od przyszłej elastyczności. Za wszelką cenę unikam blokowania dziedziczenia.

Jeśli chcesz, aby użytkownicy mogli wyświetlić zawartość folderu „E: \ Home Directories” najwyższego poziomu, rozważ na przykład następujące uprawnienie:

  • SYSTEM - Pełna kontrola - dotyczy tego folderu, podfolderów i plików
  • BUILTIN \ Administratorzy - Pełna kontrola - dotyczy tego folderu, podfolderów i plików
  • BUILTIN \ Uwierzytelnieni użytkownicy - odczyt i wykonanie - dotyczy tylko tego folderu

Ostatnie uprawnienie nie dziedziczy do podfolderów. W każdym podfolderze dziedziczenie pozostaje włączone i po prostu określasz użytkownika z uprawnieniami „Modyfikuj” lub „Pełna kontrola” (w zależności od tego, jak się czujesz, gdy użytkownicy mogą ustawiać uprawnienia w swoim katalogu domowym). (Zwykle ustawiam to ostatnie uprawnienie, dodając „Uwierzytelnionych użytkowników” w arkuszu właściwości zabezpieczeń innych niż „Zaawansowane”, odznaczając pola wyboru „Odczytaj” i „Odczytaj i wykonaj”. Następnie przechodzę do okna dialogowego „Zaawansowane” i zmieniam Ustawienie „Zastosuj do” dla tego wpisu ACE w „Tylko ten folder”. Jest to najłatwiejszy sposób, pod względem liczby kliknięć, aby go ustawić).

Następnie skrypt staje się:

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

Podejrzewam, że dodanie uprawnienia „Uwierzytelnieni użytkownicy”, które opisałem powyżej w / dziedziczenia ustawionego na „Tylko ten folder”, da ci to, czego szukasz pod względem funkcjonalności, i zapewni elastyczność w przyszłości, jeśli się dowiesz że musisz ustawić uprawnienie, które może wymagać dziedziczenia we wszystkich katalogach domowych użytkowników w przyszłości.

To jest moja SOP dla katalogów domowych użytkowników, przekierowanych folderów „Moje dokumenty”, „Pulpit” itp. Oraz dla katalogów profili użytkowników mobilnych. Działa świetnie.

Edytować

Odp: Twój komentarz na temat dostępu BUILTIN \ Administratorzy

Przez lata miałem różne spory z ludźmi na temat mojego podejścia do przyznawania dostępu BUILTIN \ Administratorzy, a moje zdanie jest następujące:

  • Łatwiej jest rozwiązać pewną klasę problemów użytkowników, jeśli możesz dostać się do ich plików. Przejęcie na własność jest uciążliwe i może być dość powolne, jeśli obecna jest także duża liczba plików.

  • Jak widzieliście w ICACLS, BUILTIN \ Administratorzy mogą „przypisać” własność (oprócz „przejęcia”), więc nie ma dodawanego „bezpieczeństwa”, ponieważ nie mają dostępu do plików dla BUILTIN \ Administratorów.

  • O ile nie używasz inspekcji (i przesiewania potencjalnie dużej liczby fałszywie pozytywnych wpisów), nie będzie ścieżki audytu, gdy użytkownik BUILTIN \ Administrators przejmie na własność pliki, do których nie powinien mieć dostępu, skopiuje je, a następnie zwraca pliki z powrotem do ich „właściwego” właściciela i pozwolenia.

  • W świecie Microsoft szyfrowanie systemu plików (EFS) ma na celu rozwiązanie problemu nieuprawnionego dostępu do BUILTIN \ Administrators. Listy ACL NTFS nie rozwiązują tego problemu. (Oczywiście EFS nie jest jedynym programem w mieście. Szyfrowanie jest prawdziwą odpowiedzią na rozwiązanie problemu „ogranicz dostęp administratora sieci” bez względu na to, jak go pokroisz).

Moim zdaniem, nieokreślanie BUILTIN \ Administratorów z dostępem do domowych katalogów użytkowników (a właściwie dowolnego folderu) oznacza, że ​​zwiększasz złożoność i czas potrzebny do rozwiązania problemów, zapewniając jednocześnie mniej niż brak rzeczywistych zabezpieczeń („mniej niż żaden” „ponieważ daje fałszywe poczucie bezpieczeństwa tam, gdzie go nie ma).

Zrezygnowałem z próby wygrania sporu z ludźmi za pomocą logiki. Wydaje się, że jest to problem emocjonalny u niektórych osób. To jak głupie ACE „Odmów / Odbierz jako”, które umieszcza się w katalogu głównym organizacji Exchange, aby uniemożliwić niektórym uprzywilejowanym grupom otwieranie skrzynek pocztowych użytkowników. Nie zapewnia prawdziwego bezpieczeństwa (ponieważ bez kontroli można usunąć / ponownie zastosować ACE, jeśli to konieczne), fałszywe poczucie bezpieczeństwa i przeszkadza w rozwiązywaniu prawdziwych problemów.

Nawet jeśli nie podoba ci się mój argument o dostępie BUILTIN \ Administratorzy, chcesz zachować nienaruszoną hierarchię dziedziczenia, używając w razie potrzeby dziedziczenia „Tylko ten folder”. Blokowanie dziedziczenia w hierarchiach uprawnień jest pewnym znakiem, że coś w projekcie jest „zepsute” (odwrócone itp.).


1
Czy zalecamy udzielenie BUILTIN \ Administratorom pełnego dostępu do całej struktury katalogów? Uważam, że my (administratorzy) naprawdę nie powinniśmy mieć pełnego dostępu do katalogów / profili użytkowników bez przejęcia własności.
pk.

+1, uwielbiam punkty o fałszywym poczuciu bezpieczeństwa ...
DCookie

1

Po pierwsze, dziękuję za fragment skryptu. Pracowałem nad tym samym, ale utknąłem w innym miejscu. W moim pudełku SBS 2008 poniższy kod działa dla mnie (oczywiście przy założeniu, że jest podwyższony). Zrobiłem icacls% userdir% / t zupełnie nowego (domyślnego) folderu użytkownika utworzonego przez system operacyjny i porównałem go z icacls% userdir% / t folderu po uruchomieniu tego skryptu i wygląda na to, że wszystkie „O” i Ja mam rację. Mam nadzieję, że zadziała również dla ciebie.

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

Z poważaniem,

 -d

Upewnij się, że zweryfikowałeś ostatni wiersz skryptu. Z mojego doświadczenia wynika, że ​​ICACLS nie usunie odziedziczonych uprawnień. Usuwa pozycję w folderze „MYDOMAIN \% username%”, ale uprawnienia podfolderów pozostają nietknięte. Dlatego „MYDOMAIN \% nazwa użytkownika%” nadal będzie mieć dostęp do podfolderów, jeśli będzie dostępny bezpośrednio, po prostu nie będzie można ich przeglądać. XCACLS.vbs rozwiązało to dla mnie. cscript.exe xcacls.vbs "e: \ Test" / E / R "MYDOMAIN \% nazwa użytkownika%"
pk.

Tam właśnie . część przyszła do mojej edycji. robi / dziedziczenie: r na folderze nadrzędnym, miałem ten sam problem. ale robi to dalej . w folderze nadrzędnym wydawało się załatwić sprawę. Po uruchomieniu powyższego% userdir% ma% nazwa_użytkownika%, system i administratorów, ale wszystko pod tym jest tylko% nazwa_użytkownika% i system, tak jak serwer początkowo je skonfigurował - dokładnie to, czego chciałem.

-1

Potrzebuję twojej pomocy w modyfikacji tego polecenia zgodnie z moimi wymaganiami, jeśli jest to technicznie możliwe.

Oto struktura

\ Server \ Parent \ UserA \ unix

\ Server \ Parent \ UserB \ unix

\ Server \ Parent \ UserC \ unix .... i tak dalej ..

Pod każdym folderem User $ znajduje się folder o nazwie „unix”.

Chcę dodać użytkownika lub grupę z pełnymi uprawnieniami do wszystkich folderów User $ wymienionych w folderze „Parent” (nazwy wzięte z powyższej struktury), ale chcę wykluczyć uprawnienia tylko do folderu „unix”.

Mam to polecenie, które działa dobrze w perspektywie zastosowania wymaganych uprawnień, ale nie mogę w tym dodać funkcji wykluczania.

icacls "\\ Serwer \ Nadrzędny \ UżytkownikA" / grant Domain \ Group: (OI) (CI) F / T

Czy będziesz w stanie prowadzić w tym scenariuszu?


1
Witaj w Server Fault! Proszę nie zadawać pytań poprzez odpowiedź. Użyj przycisku Zadaj pytanie , aby opublikować zapytanie.
Shunz
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.