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

Question

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

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

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

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

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

Answer 1

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

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

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

Лучший вариант - создать процедуру, которая выбирает из надлежащих представлений каталога метаданных, и подписать эту процедуру учетными данными, добавляемыми в роль db_securityadmin. См. Подписание активированной процедуры для примера того, как подписать процедуру. Грант EXECUTE на эту процедуру для тех, кто должен был просматривать эти принципы и роли.

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

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