Access Denied Assistance
Do tej pory, w systemach Windows bylo prosto: albo ktos ma prawa do plików i udzialów albo ich nie ma. Jak ma – moze zrobic to, na co prawa pozwalaja. Mozna miec nadzieje, ze oznacza to to samo, co mial na mysli administrator i ze ten ustawil wszystko tak, jak potrzebowal wlasciciel danych. To nietrywialne wymaganie, ale dzisiaj nie bede sie nim zajmowal. Jezeli uzytkownik systemu w jakims miejscu praw nie ma – przy pomocy brutalnego komunikatu dowie sie, ze nie moze zrobic tego, co zamierzal. Komunikat ten (i jego "przyjaznosc") nie zmienil sie specjalnie od czasów DOSa, gdzie uzywany byl do wskazania, ze plik juz jest otwarty w sposób uniemozliwiajacy uzyskanie zadanego dostepu. Nie mialo to wiele wspólnego z obecnie rozumianym bezpieczenstwem i ACLami, ale warto wiedziec, ze obsluga zabraniania dostepu wywodzi sie z naprawde dawnych czasów i jezeli chodzi o wspólprace z uzytkownikiem, to az do Windows Server 2008 R2 mocno te czasy przypominala.
Jak latwo sie domyslec, w Windows Server 2012 pojawilo sie cos nowego i jest to wlasnie tytulowa funkcjonalnosc Access Denied Assistance. Zalozenie jest bardzo proste. Skoro uzytkownik siega po dane i okazuje sie, ze nie ma do nich uprawnien, to skoro:
- Serwer i system kliencki wiedza, ze gdzies uprawnien zabraklo (a wiedza, skoro zabronily dostepu)
- Administrator wie, kto jest wlascicielem potrzebnych uzytkownikowi danych (a wie, albo powinien wiedziec)
To moze zmienic dotychczas stosowane podejscie? Zamiast metody "zadzwonic do admina, skontaktowac sie z wlascicielem, poprosic admina o nadanie uprawnien, poinformowac uzytkownika", w której rola administratora sprowadza sie do bialkowego interfejsu pomiedzy wlascicielem danych a ich niedoszlym uzytkownikiem, zastosowac podejscie, w którym rola administratora jest poprawne skonfigurowanie serwera a kwestie proszenia o dostep i nadawania go wyjasniaja sobie zainteresowane tym strony.
Konfigurujac taka funkcjonalnosc, musimy odpowiedziec sobie na kilka pytan:
- Czy na pewno wiemy, kto jest wlascicielem danych dla poszczególnych udzialów?
- Czy poslugujemy sie prostym rozwiazaniem opartym o email (gdzie na koncu pewnie i tak sprawa trafi do admina) czy siegamy bo bardziej zaawansowane systemy (chocby Forefront Identity Manager), gdzie wlasciciel danych sam moze panowac nad tym kto i jak do jego danych moze siegac.
- Czy rozwiazanie Access Denied Assistance chcemy wyklikac, skonfigurowac przez GPO czy oskryptowac przy pomocy PowerShella.
A pózniej juz jest bardzo prosto.
- Na poziomie udzialów konfigurujemy adres mailowy wlasciciela danych.
- W konsoli File Server Resoruce Manager konfigurujemy i sprawdzamy parametry serwera SMTP.
- W tej samej konsoli FSRM wlaczamy funkcjonalnosc Access Denied Assistance.
- Na poziomie calego serwera konfigurujemy komunikat dla uzytkowników i dodatkowe (inne niz wlasciciela) adresy, pod które wyslane zostanie powiadomienie o potrzebie dostepu do plików.
- Opcjonalnie, na poziomie poszczególnych udzialów konfigurujemy indywidualne komunikaty.
Gotowe. Od tej pory, uzytkownik zamiast komunikatu w stylu "nie wolno, bo zostalo zabronione", dostanie czytelna, przewidziana przez wlasciciela danych informacje.
Domyslny komunikat wyglada wprawdzie malo zachecajaco, ale wczesniejszych obrazkach widac, ze mozna go dosc dowolnie zmieniac, wlacznie z uzyciem specjalnych pól takich jak chocby [Data Owner Email].
Po kliknieciu "Request Assistance" pojawia sie okienko edycyjne, w którym uzytkownik moze wpisac dlaczego potrzebuje dostepu do danych. "Send" i gotowe.
Calosc jest tak prosta do skonfigurowania, ze kazdy administrator powinien we wlasnym interesie Acces Denied Assistance uruchomic. Fakt, ze to nie jemu uzytkownicy beda zawracac glowe powinien byc wystarczajaca motywacja.
Autor: Grzegorz Tworek [MVP]