SQL Server выполняется как требует отдельного входа
Вечер,
Я хотел бы получить некоторое практическое подтверждение в отношении проблемы, с которой мы сталкиваемся.
У нас есть решение K2/SourceCode, которое включает успешное использование EXECUTE AS с Sql Server 2008 R2.
Мы не имеем прямого контроля над тем, как реализовано это решение, т.е. мы не можем изменять запросы, которые отправляются в ядро Sql Server. Мы можем, конечно, захватить их, используя Profiler, и они имеют тенденцию следовать этой схеме:
DECLARE @cookie VARBINARY(100);
EXECUTE AS LOGIN = 'DOMAIN\username' WITH COOKIE INTO @cookie;
SELECT @cookie;
exec [dbo].[SomeStoredProcedure] /* ... various params ...*/
exec sp_executesql N'REVERT WITH COOKIE = @cookie;',N'@cookie varbinary(100)',@cookie=/* some cookie value */
Таким образом, происходит то, что [SomeStoredProcedure] выполняется в контексте безопасности пользователя [Домен \ имя пользователя], а учетная запись службы (приложения) выдает себя за этого пользователя. Я еще раз подчеркиваю, что у нас нет контроля над этой моделью. Это то, что делает приложение.
Внешне такое поведение совершенно желательно, потому что мы хотим, чтобы все было организовано таким образом, чтобы хранимая процедура эффективно выполнялась любым пользователем, который в данный момент находится на переднем крае приложения.
Однако эти запросы постоянно терпели неудачу, и наше исследование в конечном итоге привело нас к этому из документации по Sql Server (мой акцент):
Указание имени пользователя или имени для входа Имя пользователя или имя для входа, указанное в EXECUTE AS, должно существовать как принципал в sys.database_principals или sys.server_principals, соответственно, иначе оператор EXECUTE AS завершится неудачно. Кроме того, IMPERSONATE разрешения должны быть предоставлены на принципале. Если вызывающая сторона не является владельцем базы данных или членом фиксированной серверной роли sysadmin, принципал должен существовать, даже когда пользователь обращается к базе данных или экземпляру SQL Server через членство в группе Windows. Например, предположим, что выполнены следующие условия: Группа CompanyDomain\SQLUsers имеет доступ к базе данных Sales. CompanyDomain\SqlUser1 является членом SQLUsers и, следовательно, имеет неявный доступ к базе данных Sales. Хотя CompanyDomain \ SqlUser1 имеет доступ к базе данных через членство в группе SQLUsers, оператор EXECUTE AS USER = 'CompanyDomain\SqlUser1' завершается ошибкой, поскольку CompanyDomain \ SqlUser1 не существует в качестве участника в базе данных. Если пользователь осиротел (связанный логин больше не существует), и пользователь не был создан без БЕЗ ВХОДА, EXECUTE AS завершится с ошибкой для пользователя.
У нас есть группа из примерно 30 конечных пользователей, которым необходимо иметь возможность использовать это приложение, и требование состоит в том, чтобы учетная запись безопасности приложения могла выдавать себя за любого из этих пользователей для выполнения этих хранимых процедур. Это требование является фиксированным и не подлежит обсуждению.
Представленная выше документация, по-видимому, исключает возможность выполнения этого требования, добавляя всех 30 пользователей в группу AD, добавляя эту группу в качестве имени входа SQL Server и предоставляя группе соответствующие разрешения. И наши практические результаты тестирования подтверждают это - EXECUTE AS не помогает.
Возьмите одного из этих пользователей и дайте им свой индивидуальный логин AD на сервере Sql, и решение будет успешно работать для этого пользователя. EXECUTE AS выполняется успешно, и необходимые разрешения не нужно назначать отдельной учетной записи, поскольку они уже были назначены с помощью группы AD.
Итак, на данный момент, я достаточно уверен, что знаю, что мне придется делать. Требуется, чтобы каждому пользователю была добавлена учетная запись AD в качестве индивидуальной учетной записи Sql Server для Windows.
Однако, прежде чем приступить к реализации этого, я хотел бы задать вопрос публично: есть ли что-то, чего я здесь не хватает?
Поучительно представить подобный сценарий в приложении масштаба предприятия - эта модель несколько развалится из-за необходимости добавления сотен отдельных учетных записей Sql Server, прошедших проверку подлинности Windows. Оставляя в стороне возможность автоматизации этого процесса и административную нагрузку, которая в конечном итоге приведет к этому, я просто немного напрягаюсь, чтобы представить, что это единственный путь.
Буду благодарен за подтверждение и / или комментарии.
Спасибо
Роберт
1 ответ
Поскольку никто не ответил на обратное (или даже вообще), мы предположили, что BOL является точным и что нет альтернативного разрешения.