Przypisywanie praw na dużą skalę użytkownikom domeny z różnych lasów

Najwyraźniej moja karma jest taka: realizować standardowe zadania na różne, nietrywialne sposoby. Jeśli ktoś ma inną wizję problemu, proszę omówić to, aby można było rozwiązać problem.

Pewnego pięknego poranka pojawiło się ciekawe zadanie polegające na dystrybucji praw pomiędzy grupy użytkowników do różnych udziałów zawierających podfoldery projektów z folderami dokumentów. Wszystko było w porządku i napisano skrypt przydzielający prawa do folderów. A potem okazało się, że w grupach powinni znajdować się użytkownicy z różnych domen, z różnych lasów (dla tych, którzy zapomnieli, co to jest). Załóżmy, że sam udział znajduje się na nośniku Synology, zarejestrowanym w domenie FB lasu PSI. Zadanie: aby umożliwić użytkownikom domen w innym lesie dostęp do zawartości tego udziału i to bardzo selektywnie.

Po pewnym czasie specyfikacja techniczna przybrała następującą postać:

• 2 lasy: las PSI, las TG.

  

• Każdy las ma 3 domeny: PSI (ZG, PSI, FB); TG (TG, HU, KC).
• Pomiędzy lasami istnieje relacja zaufania; firma Synology widzi wszystkie grupy zabezpieczeń we wszystkich lasach.
• Udziały i foldery/podfoldery muszą mieć konta administratora domeny FB z uprawnieniami FullControl
• Nazwy folderów należy usystematyzować. Kierownictwo koordynowało identyfikatory projektów; zdecydowałem się powiązać nazwy grup zabezpieczeń z identyfikatorami projektów.
• Foldery projektów w udziałach systemowych muszą zawierać przygotowaną wcześniej strukturę w pliku .xlsx, z odpowiednimi uprawnieniami dostępu (R/RW/NA, gdzie NA – brak dostępu)

  

• Powinna istnieć możliwość ograniczenia praw użytkowników/członków grup jednego projektu tylko do niektórych katalogów tego projektu. Użytkownik może nie mieć dostępu do innych katalogów/projektów, w zależności od członkostwa w grupie.
• Tworząc folder projektu, należy w miarę możliwości automatycznie tworzyć w odpowiednich domenach grupy o nazwach odpowiadających identyfikatorom projektu.

Uwagi do specyfikacji technicznych

• Ustanawianie relacji zaufania nie jest objęte zakresem specyfikacji technicznych
• Identyfikator projektu zawiera cyfry i znaki łacińskie
• Role użytkowników projektu dla wszystkich domen mają standardowe nazwy
• Przed rozpoczęciem całego projektu przygotowywany jest plik .xlsx z folderami i prawami dostępu (macierz dostępu).
• Podczas realizacji projektów istnieje możliwość tworzenia grup użytkowników w odpowiednich domenach
• Automatyzację osiąga się poprzez wykorzystanie standardowych narzędzi administracyjnych MS Windows

Wdrażanie specyfikacji technicznych

Po sformalizowaniu tych wymagań nastąpiła taktyczna przerwa w celu przetestowania metod tworzenia katalogów i nadawania do nich uprawnień. W zamierzeniu miało to służyć wyłącznie PowerShellowi, aby nie komplikować projektu. Jak pisałem wcześniej, algorytm skryptu wydawał się dość prosty:

• rejestrujemy grupy o nazwie pochodzącej z identyfikatora projektu (np. KC40587) i odpowiadających im rolach określonych w matrycy dostępu: KC40587-EN- dla inżyniera; KC40587-PM – dla menadżera produktu itp.
• otrzymujemy identyfikatory SID utworzonych grup
• zarejestruj folder projektu i odpowiedni zestaw katalogów (lista podfolderów zależy od udziału, w którym jest utworzona i zdefiniowana w macierzy dostępu)
• przydzielaj uprawnienia grupom dla nowych podkatalogów projektu zgodnie z matrycą dostępu.

Trudności napotkane na etapie 1:

• niezrozumienie sposobu podawania macierzy dostępu w skrypcie (obecnie zaimplementowana jest tablica wielowymiarowa, ale ścieżki do jej wypełnienia szuka się na podstawie zawartości pliku .xlsx/macierzy dostępu)

  

• brak możliwości ustawienia praw dostępu w udziałach SMB na dyskach Synology za pomocą PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), przez co stracono mnóstwo czasu i wszystko trzeba było dostosować do skryptów za pomocą narzędzia do edycji praw dostępu icacls, co wymagało stworzenia pośredniego repozytorium plików tekstowych i cmd.

W bieżącym trybie wykonywanie plików cmd kontrolowane jest ręcznie, w zależności od konieczności zarejestrowania folderu dla projektu.

Okazało się też, że skrypt powinien zostać wykonany także w celu rejestracji grup w innych lasach (użyto określenia Cross-domains), a stosunek może wynosić nie tylko 1 do jednego, ale także 1 do wielu.

Oznacza to, że grupy z innych domen, w tym z sąsiedniego lasu, mogą teraz ubiegać się o dostęp do zasobów dowolnej domeny. Aby osiągnąć jednolitość zdecydowano się stworzyć w jednostce organizacyjnej symetryczną strukturę wszystkich obsługiwanych domen wszystkich lasów (czarne pionowe owale). Jak to mówią, w wojsku wszystko powinno być brzydkie, ale jednolite:

Tym samym podczas rejestracji projektu 80XXX w domenie TG skrypt wykonuje:

1. utworzenie odpowiedniej jednostki organizacyjnej (czerwone poziome owale) w tej domenie i międzydomenach, czyli tych domenach, których pracownicy muszą mieć dostęp do tego zasobu.

2. wypełnienie jednostki organizacyjnej grupami o nazwach typu -, Gdzie:

• Domena SRC_ – międzydomenowa, której pracownicy będą mieli dostęp do zasobów domeny DST
• DST_domain – domena, do której zasobów tak naprawdę należy zapewnić dostęp, czyli od której wszystko się zaczęło
• - numer projektu
• ROLE – nazwy ról wymienione w matrycy dostępu.

3. odczytanie tablicy SID wszystkich grup wszystkich zaangażowanych domen i zapisanie jej w celu późniejszego przeniesienia danych do pliku definiującego uprawnienia do konkretnego podfolderu projektu

4. generowanie plików źródłowych (parametr /restore) z zestawem uprawnień do wykorzystania przez narzędzie icacKC w trybie pliku wykonywalnego „icacKC „as-nasNNKCProjects” /restore C:TempKCKC40XXKC40XX.txt”

5. utworzenie pliku CMD, który łączy wszystkie uruchomione pliki icacl dla wszystkich folderów projektu

Jak napisano wcześniej, uruchomienie pliku wykonywalnego odbywa się ręcznie i ocena wyników wykonania również odbywa się ręcznie.

Trudności, z którymi musieliśmy się na koniec zmierzyć:

• jeśli folder projektu jest już wypełniony dużą liczbą plików, uruchomienie polecenia icacls na istniejących woluminach może zająć dużo czasu, a w niektórych przypadkach może zakończyć się niepowodzeniem (na przykład, gdy ścieżki plików są długie);
• oprócz parametru /restore musieliśmy dodać linie z parametrem /reset na wypadek, gdyby foldery nie zostały utworzone, ale zostały przeniesione z wcześniej istniejących folderów, z wyłączonymi prawami dziedziczenia z roota;
• Część skryptu tworzenia grup musiała zostać wykonana na dowolnym DC każdego lasu, problem dotyczy kont administracyjnych dla każdego drzewa.

Wniosek ogólny: to bardzo dziwne, że na rynku nie ma jeszcze narzędzi o podobnej funkcjonalności. Wydaje się, że możliwa jest implementacja podobnej funkcjonalności w oparciu o portal Sharepoint.
Niezrozumiałe jest również to, że nie można używać narzędzi PoSH do ustawiania praw do folderów na urządzeniach sinology.

W razie potrzeby jestem gotowy udostępnić skrypt, tworząc projekt na githubie, jeśli ktoś jest zainteresowany.

Źródło: www.habr.com