Роли базы данных SQL 2005 и безопасность

Question

Я перешел к созданию/использованию схем в Sql Server 2005, где я также создал роли базы данных и назначил схемы для ролей.

Проблема у меня есть одна из ролей db у меня должен быть полный доступ - скажем SuperSysRole.
Однако, когда я назначаю логин для этой роли, он не может выполнять определенные команды. В частности, я хочу, чтобы пользователь в этой роли управлял сбрасыванием пароля. Однако при выполнении хранимой процедуры он не возвращает всех пользователей в базе данных.

Запущена хранимая процедура, которая возвращает данные назад и вызывает представление, которое объединяет таблицы sysusers и sysmembers.

Пользователь, скажем, myAdmin, был назначен роли SuperSysRole. Роль SuperSysRole была предоставлена ​​выполнение хранимой процедуры selectRoles.

Это, наверное, простая вещь, но кто-то может рассказать мне, что мне не хватает?
Мое приложение аутентифицируется с использованием имени пользователя и пароля myAdmin. Он отлично работает при входе в аккаунт sa.

Answer 1

Членство в роли роли данных запрашивается через sys.database_principals и sys.database_role_members виды каталога, которые представляют собой правильные представления каталогов вместо устаревших пользователей и sysmembers. Оба имеют те же ограничения безопасности:

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

Необходимые разрешения указаны в GRANT Database Principal Permissions: VIEW DEFINITION. Нет разрешения, которое может быть предоставлено для просмотра любого принципала и определения роли.

Ваш лучший вариант - создать процедуру, которая выбирает из соответствующих представлений каталога метаданных и подписывает эту процедуру с учетными данными, которые добавляются в роль db_securityadmin. См. Signing an Activated Procedure для примера, как подписать процедуру. Грант ИСПОЛНИТЕ в этой процедуре тем, кто должен был рассмотреть эти принципы и роли.

Однако все это не даст вам нигде в отношении заявленного намерения: управление сбрасыванием пароля. Только серверные принципы (например, логины) имеют пароли, и любая схема, разработанная на уровне основных принципов базы данных, не может влиять на принципы сервера, поскольку они являются неправильной абстракцией. И так как нет ролей сервера для определения (у вас могут быть только группы Windows в качестве ролей, но вы хотите использовать SQL Auth), вы не можете сделать это по членству в ролях.

Моя рекомендация, опять же, использовать подписание кода. Создайте процедуры, которые выполняют нужные действия (запрос sys.server_principals и sys.sql_logins для проверки истечения срока действия пароля, выпуск инструкций ALTER LOGIN для сброса паролей и т. Д.), Затем используйте подписание кода для подписи этих процедур и предоставления необходимых прав для подписи. Я снова ссылаюсь на Signing an activated procedure для примера, как это сделать. Затем дайте EXECUTE по этим процедурам «специальным» пользователям, которым необходимо управлять ими.