Miałem ostatnio zadanie w postaci połączenia Reporting Services działających na jednym serwerze, z bazą danych MS SQL Server działającą na drugim serwerze. Okazuje się, że problemy pojawiają się, gdy przenosimy wszystko z konfiguracji testowej do produkcyjnej. Zwykle w konfiguracji testowej Reporting Services i SQL Server działają na jednym komputerze, zatem mają do siebie “pełne prawa”, ze względu na działanie z uprawnieniami użytkownika Network Service. Na oddzielnych serwerach już nie jesteśmy w tak komfortowej sytuacji. Postanowiłem stworzyć tego posta “dla potomności” 
żeby ktoś w podobnej sytuacji mógł to sobie wygoolować 
Kilka informacji podstawowych -> Raporty na serwerze raportów zwykle mają zdefiniowany plik Data source zawierający informacje o połączeniu do bazy danych. Tak dla ułatwienia, żeby nie trzeba było dla każdego raportu wpisywać tych informacji. W Data Source definiuje się także sposób połączenia do bazy. Najprościej jest wykorzystać autentykację windows, czyli na podstawie uprawnień użytkownika domenowego. Niestety to nie jest takie proste. O tym dalej.
Załóżmy, że użytkownik domenowy, który wyświetla raport (*może to być użytkownik na prawach którego działa aplikacja ASP, która korzysta z kontrolki do wyświetlania raportu) ma prawa do tego raportu jak i do bazy danych, z której ten raport bierze dane. Skoro raport działa z uprawnieniami użytkownika (autentykacja Windows, czyli domenowa) no to wszystko gra. Ma prawa do tego, co trzeba. No nie do końca. Pojawia się błąd:
“An error has occurred during report processing. (rsProcessingAborted)
Cannot impersonate user for data source ‘DS1′. (rsErrorImpersonatingUser)
Logon failed. (rsLogonFailed)
For more information about this error navigate to the report server on the local server machine, or enable remote errors ”
Można sobie włączyć Remote errors (http://technet.microsoft.com/en-us/library/aa337165.aspx) ale niewiele to daje. Dodatkowa informacja to:
“Logon failure: the user has not been granted the requested logon type at this computer. (Exception from HRESULT: 0×80070569)”
Pierwsza przeszkoda
Aby możliwe było użycie Data Source na prawach użytkownika domenowego, ten użytkownik musi mieć prawo “Allow log on locally” (Zezwalaj na logowanie lokalne) na komputerze na którym działa Reporting Services. To prawo musi mieć użytkownik, który “wyzwala” Data source. Można także w konfiguracji Reporting Services (Start -> programy -> Microsoft SQL Server 2005 -> configuration tools -> Reporting Services Configuration) ustawić “Execution account” i tam wpisać użytkownika, który takie prawo będzie posiadał . W ten sposób Reporting Services będzie mogło wywoływać wszystkie data source. Jest do dokładniej opisane tutaj: http://msdn2.microsoft.com/en-us/library/bb326317.aspx
Druga przeszkoda
Chcieliśmy ustawić aby Reporting Services działały na zasadzie autentykacji windows. Daje to tyle ze aplikacja webowa IIS (w tym przypadku Reporting Services) może działać z uprawnieniami użytkownika domenowego, który z niej korzysta. Wszystko jest w porządku dopóki serwer IIS na podstawie tych danych uwierzytelniania spróbuje się dobrać do innych zasobów sieci (np. serwera MS SQL). Nie jest dopuszczalne takie zachowanie. Aplikacja nie możę korzystać z uprawnień tego użytkownika w innych usługach. Uznano, że to zbyt duże uprawnienie nadane aplikacji. Użytkownik musi wiedzieć do czego będą użyte jego uprawnienia. Ten problem nazwano “double hop”. Pierwszy hop to połączenie między użytkownikiem a IIS, a drugi hop to połączenie pomiędzy IIS a SQL serverem. Tego nie można zrobić. Jest to opisane tutaj: http://blogs.msdn.com/nunos/archive/2004/03/12/88468.aspx Tak naprawdę użytkownik daje prawo aplikacji do działania z jego uprawnieniami tylko na poziomie serwera IIS.
* Kilka użytecznych definicji i wyjaśnień można znaleźć tutaj: http://msdn2.microsoft.com/en-us/library/aa480547.aspx
Można to obejść w różny sposób.
1. W data source w Reporting Services wpisać nazwę użytkownika i hasło do połączenia z bazą danych (Stored Credentials). Hasło będzie zaszyfrowane w bazie danych Reporting Services (dla jasności: Reporting Services ma własną bazę danych do przechowywania raportów i innych rzeczy) .
Raczej nie ma możliwości zapisania nazwy użytkownika i hasła Data Source w rejestrze tak jak to można zrobić z aplikacją ASP. Jedynie można impersonifikować całą usługę Reporting Services, tak jak zostało to opisane tutaj: http://msdn2.microsoft.com/en-us/library/bb326419.aspx
2. Można zezwolić serwerowi IIS na “drugi hop” zgodnie z :
http://support.microsoft.com/default.aspx?scid=kb;en-us;810572
Czyli trzeba by było zmienić ustawienia active directory, aby ufać serwerowi IIS jeśli chodzi o delegowanie uprawnień (drugi hop):
http://msdn2.microsoft.com/en-us/library/ms916706.aspx
Minus jest taki, że trzeba by było zmienić ustawienia komputerów klienckich zgodnie z pierwszym podanym przeze mnie linkiem. Poza tym może to w jakimś stopniu obniżyć bezpieczeństwo, bo skoro serwer IIS będzie miał pozwolenie na delegowanie uprawnień, no to wszystkie aplikacje (nie tylko Reporting Services) będą mogły z tej opcji korzystać. Niby klient (Internet Explorer) musi pozwolić na delegowanie jego uprawnień, ale i tak może to być problem.
Mam nadzieję, że ten post zaoszczędzi komuś czas Dzięki temu problemowi zdecydowanie poprawiłem sobie znajomość zagadnień związanych z ASP i uprawnieniami domenowymi, choć nie ukrywam, że wolałbym spędzić nad tym mniej czasu
Znalezienie bezpłatnych narzędzi dla firmy świadczącej usługi informatyczne nie jest prostą sprawą. Mało kogo stać na zaawansowane systemy zgodne z 
W tym wypadku chyba jedynym słusznym rozwiązaniem jest 
Ostatnie komentarze