prosta idea [nie zawsze wykonalna] – wedle podręcznikowego przydzielania uprawnień i zarządzania grupami polega na tym, że dla każdego udziału na FS tworzona jest grupa security-domain local – np. Share_FS01_RW_public. tej grupie nadawane są uprawnienia [w tym przypadq RW] a całe zarządzanie przydzielaniem uprawnień polega na dodaniu grupy funkcyjnej do grupy dostępowej. przykład w praktyce:

  1. zakładam w AD jednostkę organizacyjną OU=AccessGroups
  2. zakładam w AD jednostkę organizacyjną OU=Accounting
  3. zakładam grupę funkcyjną security-global ‘Accounting’ i dodaję odpowiednich userów). te 3 kroki oczywiście definiują miniaturkę podstawowego środowiska lab
  4. księgowość musi mieć swój prywatny katalog na FS więc:
  1. zakładam grupę Security-Domain Local o nazwie “AG_FS01_RW_Accounting” w OU-AccessGroups – to przykładowa notacja która pozwala w łatwy sposób odróżnić grupy dostępowe od innych, zawiera nazwę serwera, którego dotyczy, uprawnienia [dzięki temu można łatwo odróżniać grupy RW od R] oraz jakiego udziału dotyczą.
  2. zakładam katalog ‘Accounting’ na FS01 i publiqję go jako ‘\FS01Accouting’
  3. jedyne uprawnienia jakie zakładam na katalogu to “authenticated users:M” na poziomie udziału oraz “AG_FS01_RW_Accounting:RW” na poziomie NTFS
  4. teraz aby nadać uprawnienia do katalogu wystarczy, że dodam grupę ‘Accounting’ do ‘AG_FS01_RW_Accounting’

wadą takiego rozwiązania jest niezliczona ilość grup w złożonym środowisq – a więc czasem podręcznikowe rozwiązanie nie może być zastosowane. zalet jednak jest bardzo dużo:

  • wszystko zarządzane z jednego miejsca za pomocą ADUaC bez potrzeby logowania/sprawdzania na serwerach plików
  • ..czyli centralizacja zarządzania uprawnieniami
  • łatwość delegacji zarządzania uprawnieniami
  • utrzymywanie spójnej, prostej struktury: przejrzystość
  • prostota automatyzacji mapowania: ujednolicone/uniwersalne skrypty mapowania
  • automatyczne mapowanie dysków dla użytkowników zaraz po dodaniu do grupy funkcyjnej

poniżej zamieszczam przykładowy skrypt logowania mapujący dyski, który ma możliwość mapowania na podstawie przynależności do grupy. ponieważ użytkownicy nie należą bezpośrednio do grupy dostępowej, sprawdzany jest drugi poziom zagnieżdżenia – atrybut memberof. jest możliwość włączenia rekursywnego sprawdzania zagnieżdżenia ale ma to kilka mankamentów:

  • jest dość powolne w realnym środowisq, gdzie grup jest sporo
  • istnieje niebezpieczeństwo przypadkowego zmapowania katalogu z powodu powiązań pomiędzy grupami

jak się okazuje, czasem teoria przekłada się na praktykę – mówię tu o podręcznikowym projektowaniu grup (global/domain local i standardowe AGDLP).

eN.