Höchstwahrscheinlich müssen alle diese Assemblies auf UNSAFE
gesetzt werden , insbesondere die drei System.DirectoryServices* .NET Framework-Bibliotheken, die Sie importiert haben. Da Sie außerdem nicht unterstützte .NET Framework-Bibliotheken
importieren , müssen Sie die Datenbank auf TRUSTWORTHY ON
setzen um sie zum Arbeiten zu bringen. Einstellen einer Datenbank auf TRUSTWORTHY ON
ist normalerweise etwas, das Sie vermeiden möchten, da es ein Sicherheitsrisiko darstellt, aber in diesem Fall glaube ich nicht, dass es vermieden werden kann.
Allerdings bin ich mir nicht sicher, ob Sie diese Funktion überhaupt selbst in SQLCLR erstellen müssen. Wenn Sie nur wissen möchten, ob ein Login (natürlich nur Windows-Logins) zu einer bestimmten Active Directory-Gruppe gehört, gibt es eine eingebaute Funktion, die sollte mach das für dich. Das IS_MEMBER
Funktion zeigt an, ob die aktuelle Login ist Mitglied der angegebenen Windows-Gruppe (angegeben als Domain\Group
). Der Unterschied zwischen dieser Funktion und der von Ihnen erstellten Funktion besteht darin, dass sie nur für das aktuelle Login funktioniert; Sie können kein beliebiges Login hineingeben. ABER es erfordert auch keinen der zusätzlichen Anstrengungen und Sicherheitsrisiken, die damit einhergehen SQLCLR-Lösung. Also, etwas zu beachten :-).
Kommentar von O.P. zu dieser Antwort:
In diesem Fall machen Sie das dynamische SQL einfach zwei Schichten tief statt der üblichen einen Schicht. Etwas in der Art von:
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);
Bei diesem Ansatz führt die Abfrage OPENQUERY
aus ist dynamisches SQL, aber die an OPENQUERY
übergebene Abfrage auszuführen ist ein String-Literal.