SQL Server: проверка принадлежности роли

Question

В SQL Server у меня есть много разных отношений между элементами и активными группами каталогов. Я хочу создать запрос, который на основе пользователя активного каталога, который будет использоваться, я бы мог запросить все элементы, связанные с активной группой каталогов, если пользователь является членом группы.

Я пошел по дороге с использованием IS_Member, но это работает только для текущего пользователя. Хранимую процедуру вызывается веб-приложением asp.net, которое в настоящее время подключается к определенной учетной записи пользователя SQL. Я не думаю, что я могу подключиться с помощью интегрированной аутентификации и олицетворения в веб-приложении, потому что я не верю, что наша инфраструктурная конфигурация позволит делегировать с пользовательского компьютера через веб-сервер, а затем на сервер db (проблема с 3-мя переменами) ,

Что я могу сделать здесь?

Answer 1

Напишите C# или VB.NET .exe, который запрашивает AD и заполняет таблицу в базе данных всеми пользователями/группами и вызывает ее из заданий SQL, которые вы выполняете ежедневно. Затем просто используйте синхронизированные данные таблицы, чтобы выполнить сравнения. Таким образом, вы можете избежать любой другой сложности, пытаясь сделать это на лету. Членство в группе часто не меняется. Даже если что-то изменилось в AD, вы можете просто запустить «синхронизацию» вручную, и все будет в порядке. Вы можете использовать Windows.Identity() или что-то еще из ASP.NET, чтобы проверить имя пользователя.

Answer 2

Проблема, которую вы описываете, представляет собой классический сценарий с двумя прыжками, который может быть (в конечном итоге) разрешен посредством кропотливого процесса, известного как конфигурация Kerberos. Ложное обходное решение предполагает передачу учетных данных из приложения asp.net в виде переменной в SQL-запрос в вашей базе данных.

Если SQL Server имеет сервер LDAP, настроенный как связанный сервер, вы можете переписать свои хранимые процедуры, чтобы принять пользователя в качестве входной переменной, и проверить, должен ли пользователь являться членом группы AD, прежде чем продолжить. Рассмотрим включение OPENQUERY в хранимых процедурах, как показано ниже:

CREATE PROCEDURE CheckAccess 
@CurrentUser varchar(max) 
AS 
IF @CurrentUser IN 
(
SELECT CN 
FROM OPENQUERY(ADSI,'<LDAP://DC=Your,DC=DomainComponent,DC=com>;(&(CN=*) 
(memberOf=CN=YourADGroupName,OU=Your,OU=OrganizationalUnit,OU=Name,DC=Your,DC=DomainComponent,DC=com));CN') 
) 
THEN 
SELECT 'Authorized User' 
ELSE 
SELECT 'Unauthorized User' 
END 

Если вы можете проконсультироваться с админами LDAP, чтобы убедиться, что вы получите правильные domainComponents и organizationalUnits группы на подправить OPENQUERY. Один из недостатков этого заключается в том, что может потребоваться некоторое время для запроса вашей группы AD, очевидно, в зависимости от размера членства. Это может быть боль, но пока ваше приложение может передавать пользователя как переменную, вы можете использовать OPENQUERY или даже запросить sys.database_principals, чтобы проверить их доступ.