Najprawdopodobniej wszystkie te zestawy będą musiały być ustawione na UNSAFE
, zwłaszcza trzy System.DirectoryServices* Zaimportowane biblioteki .NET Framework. Ponadto, ponieważ importujesz nieobsługiwane biblioteki .NET Framework
, musisz ustawić bazę danych na TRUSTWORTHY ON
aby zmusić ich do pracy. Ustawianie bazy danych na TRUSTWORTHY ON
jest to zazwyczaj coś, czego chcesz uniknąć, ponieważ jest to zagrożenie bezpieczeństwa, ale w tym przypadku nie wierzę, że można tego uniknąć.
To powiedziawszy, nie jestem pewien, czy musisz sam tworzyć tę funkcję w SQLCLR. Jeśli chcesz tylko wiedzieć, czy Login (oczywiście tylko Windows Login) należy do określonej grupy Active Directory, istnieje wbudowana funkcja, która powinna zrób to dla ciebie. IS_MEMBER
funkcja wskaże, czy bieżąca Login jest członkiem określonej grupy Windows (określonej jako Domain\Group
). Różnica w działaniu tej funkcji w przeciwieństwie do tej, którą tworzysz, polega na tym, że działa ona tylko dla bieżącego logowania; nie możesz przekazać do niego żadnego arbitralnego Loginu. ALE nie wymaga to również żadnego dodatkowego wysiłku i zagrożeń bezpieczeństwa, które są częścią tego Rozwiązanie SQLCLR. Więc coś do rozważenia :-).
Komentarz OP do tej odpowiedzi:
W takim przypadku po prostu utwórz dwie warstwy Dynamic SQL zamiast zwykłej jednej warstwy. Coś w stylu:
DECLARE @SQL NVARCHAR(MAX);
SET @SQL = N'
SELECT *
FROM OPENQUERY([LinkedServer], N''
SELECT *
FROM someResource
WHERE GroupName=N''''' + @Group + N'''''
AND ObjectName=N''''' + @Login + N''''';
'');
';
PRINT @SQL; -- DEBUG
EXEC (@SQL);
W tym podejściu zapytanie wykonujące OPENQUERY
to Dynamic SQL, ale zapytanie przekazane do OPENQUERY
do wykonania jest literałem ciągu.