@wloochacz: Pracownik podaje login i hasło do swojego konta,
Po co?
Przecież jak user zalogował się do domeny zanim uruchomi aplikację, to jest już zalogowany na własne konto.
a ja następnie przy pomocy PrincipalContext sprawdzam, czy dane się zgadzają.
Ale tu nie logujesz się de-facto do bazy danych, a do domeny i z domeny sprawdzasz te dane, tak?
Ty po prostu ponownie sprawdzasz, czy ten zalogowany ma odpowiednie poświadczanie w AD.
Hmm... Dziwne i niepotrzebne moim zdaniem.
Następnie taki użytkownik ma dostęp do zasobów bazy. Ze względu na to, że wszyscy muszą mieć dostęp i operować na konkretnych danych w bazie postawiłem na jedno konto użytkownika DB (oprócz admina oczywiście).
Ale wiesz, że ten user w bazie na poziomie bazy danych (chodzi mi o login w MS SQL, nie w domenie) nie jest do niczego potrzebny?
Poczytaj o o Windows Authentication w kontekście MSSQL, ponieważ IMHO poplątałeś tu co nieco.
A sprowadza się to jednej (JEDNEJ!) zmiany w ConnectionString
i wszystko działa - w aplikacji nie prosisz o usera i haslo, bo user jest już zalogowany do domeny i to wystarcza.
Oczywiście możesz sobie dodatkowo sprawdzać usera i hasło na poziomie aplikacji, ale to będą tylko uprawnienia do Twojej aplikacji.
Znając takie dane nie da się zalogować nigdzie (na pewno nie do bazy danych np. z poziomu Management Studio), ale da się zalogować do Twojej aplikacji pod warunkiem, że najpierw ktoś się poprawnie zalogował do domeny. To uprawnienia domeny uprawniają danego usera do zalogowania do bazy danych i działa to transparentnie.
Uprawniania do bazy danych (tabel, widoków, itd.) musisz oczywiście dodać na poziome użytkowników/grup domenowych.
Ale tu (czyli w uprawnieniach AD, bazy danych, itd.) już w szczegółach nie pomogę, nie zajmowałem się już tym bardzo dawno.