Wygląda na to, że mam taką karmę: realizować standardowe zadania w różnorodny sposób. Jeśli ktoś ma inne widzenie problemu — zapraszam do dyskusji w celu omówienia kwestii.
P pewnego pięknego poranka pojawiło się interesujące zadanie, aby przyznać grupom użytkowników prawa do różnych folderów zawierających podfoldery projektów z dokumentami. Wszystko było w porządku i napisano skrypt przydzielający prawa do folderów. A potem okazało się, że grupy muszą zawierać użytkowników z różnych domen, z różnych lasów (). Załóżmy, że sam folder jest umieszczony na nośniku Synology, zarejestrowanym w domenie FB, w lesie PSI. Zadanie: umożliwić użytkownikom domenów innego lasu dostęp do zawartości tego folderu, w sposób bardzo selektywny.
Specyfikacja wymagań po pewnym czasie przybrała następującą formę:
- 2 lasy: Las PSI, las TG.
- W każdym lesie po 3 domeny: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Między lasami – zaufane relacje, Synology widzi wszystkie grupy Security we wszystkich lasach.
- Na folderach i podfolderach muszą być konta administratorów domeny FB z pełnymi prawami (FullControl)
- Nazwy folderów muszą być zsystematyzowane. Zarząd zajmował się uzgadnianiem ID projektów, ja podsunięcie pomysł, aby nazwy grup Security powiązać z ID projektów.
- Foldery projektów w systemowych folderach muszą zawierać wcześniej przygotowaną strukturę w pliku .xlsx, z odpowiednimi uprawnieniami dostępu (R/RW/NA, gdzie NA – brak dostępu)
- Musi istnieć możliwość ograniczenia praw użytkowników/członków grupy jednego projektu tylko do określonych katalogów danego projektu. Do innych katalogów/projektów użytkownik może nie mieć dostępu, zgodnie z członkostwem w grupach.
- Przy tworzeniu folderu projektu muszą być maksymalnie automatycznie tworzone grupy w odpowiednich domenach z nazwami odpowiadającymi ID projektów.
Uwagi do specyfikacji wymagań
- Konfiguracja zaufanych relacji nie wchodzi w zakres specyfikacji wymagań
- ID projektu zawiera cyfry i litery łacińskie
- Role użytkowników projektów dla wszystkich domen mają standardowe nazwy
- Plik .xlsx z folderami i prawami dostępu (macierz dostępu) jest przygotowywany przed rozpoczęciem realizacji całego projektu
- Podczas realizacji projektów możliwe jest tworzenie grup użytkowników w odpowiednich domenach
- Automatyzacja osiągana jest przy użyciu standardowych narzędzi administracyjnych MS Windows
Realizacja wymagań
Po sformalizowaniu wymagań, wzięto taktyczną pauzę na przetestowanie metod tworzenia katalogów i nadawania uprawnień do nich. Planowano używać tylko PowerShell, aby nie komplikować projektu. Jak już wcześniej pisałem, algorytm skryptu miał być dość prosty:
- rejestrujemy grupy z nazwą pochodzącą od ID projektu (np. KC40587) oraz odpowiednimi rolami wskazanymi w macierzy dostępu: KC40587-EN- dla inżyniera; KC40587-PM – dla menedżera produktu itd.
- uzyskujemy SID-y utworzonych grup
- rejestrujemy folder projektu oraz odpowiedni zestaw katalogów (lista podfolderów zależy od udostępniania, w którym zostanie utworzony i jest określona w macierzy dostępu)
- przyznajemy nowe prawa dostępu do podkatalogów projektu grupom według macierzy dostępu.
Trudności, z którymi trzeba było się zmierzyć na etapie 1:
- niezrozumienie sposobu definiowania macierzy dostępu w skrypcie (obecnie zrealizowano wielowymiarową tablicę, ale szuka się sposobu na jej uzupełnienie na podstawie zawartości pliku .xlsx/macierzy dostępu)
- niemożność nadawania praw dostępu w udostępnianiach SMB na nośnikach Synology przy użyciu 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 trzeba było dostosować wszystko pod skrypty z użyciem narzędzia do edytowania uprawnień icacls, co wymagało stworzenia pośredniego magazynu plików tekstowych i cmd.
W aktualnym trybie wykonanie plików cmd jest kontrolowane ręcznie, w zależności od potrzeby zarejestrowania folderu dla projektu.
Okazało się także, że skrypt musi być wykonywany również w celu rejestracji grup w innych lasach (używano terminu Cross-domains), przy czym relacja może być nie tylko 1 do 1, ale i 1 do wielu.
Oznacza to, że dostęp do zasobów jakiejkolwiek domeny mogą teraz ubiegać się grupy z innych cross-domen, w tym sąsiedniego lasu. W celu zapewnienia jednolitości, podjęto decyzję o stworzeniu symetrycznej struktury w OU wszystkich obsługiwanych domen wszystkich lasów (czarne pionowe owalne). Jak to mówią, w armii wszystko musi być chaotyczne, ale jednolite:
W ten sposób, podczas rejestracji projektu 80XXX w domenie TG, skrypt wykonuje:
1. utworzenie odpowiednich OU (czerwone poziome owalne kształty) w tej domenie i w cross-domenach, czyli tych domenach, których pracownicy powinni mieć dostęp do tego zasobu.
2. wypełnienie OU grupami o nazwach w formacie <SRC_domain><DST_domain><ID_project>-, gdzie:
- SRC_domain – cross-domena, której pracownicy będą mieli dostęp do zasobów domeny DST
- DST_domain – domena, do zasobów której, w rzeczywistości, ma być przyznany dostęp, czyli powód, dla którego to wszystko zostało zainicjowane
- <ID_project> — numer projektu
- ROLES – nazwy ról wymienionych w macierzy dostępu.
3. odczytanie tablicy SID wszystkich grup ze wszystkich zaangażowanych domen i zapisanie jej do późniejszego przesłania danych do pliku, określają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 w sobie wszystkie uruchamiane icacls dla wszystkich folderów projektu
Jak wspomniano wcześniej, uruchomienie pliku wykonywalnego odbywa się ręcznie, a ocena wyników wykonania – również jest przeprowadzana ręcznie.
Trudności, z którymi trzeba się było zmierzyć w końcu:
- jeśli folder projektu jest już wypełniony dużą ilością plików, to wykonanie polecenia icacls na istniejących danych może zająć znaczny czas, a w niektórych przypadkach prowadziło do błędów (na przykład w przypadku długich ścieżek plików);
- oprócz parametru /restore musiałem dodać linie z parametrem /reset na wypadek, gdyby foldery nie zostały utworzone, a przeniesione z już istniejących folderów, z wyłączonymi uprawnieniami dziedziczenia z korzenia;
- część skryptu dotycząca tworzenia grup musiała być wykonana na dowolnym DC każdego lasu, problem dotyczy kont administracyjnych dla każdego drzewa.
Ogólny wniosek: jest dziwne, że na rynku brakuje narzędzi o podobnej funkcjonalności. Możliwe jest wdrożenie podobnej funkcjonalności na podstawie portalu SharePoint.
Również niezrozumiałe jest, dlaczego nie ma możliwości wykorzystania narzędzi PoSH do nadawania praw na folder na urządzeniach Sinology.
Na życzenie chętnie podzielę się skryptem, tworząc jakiś projekt na GitHubie, jeśli to kogoś zainteresuje.
Źródło: habr.com
