У меня есть база данных, к которой я хочу ограничить доступ к 3 названным лицам. Я думал, что смогу сделать следующее:
Когда я пытаюсь выполнить шаг 3, я получаю следующую ошибку:
Msg 15353, Level 16, State 1, Line 1
An entity of type database cannot be owned by a role, a group, an approle, or by principals mapped to certificates or asymmetric keys.
Я пытался сделать это через IDE, sp_changedbowner sproc, и ALTER AUTHORIZATION команда, и каждый раз я получаю одну и ту же ошибку.
После поиска в MSDN и Google я обнаружил, что это ограничение является намеренным. Отлично, это полезно. Кто-нибудь может мне сказать:
Другая информация, которая может быть уместна:
Почему это запрещено, читайте дальше SQL Server: группы Windows, схемы по умолчанию и другие свойства. Подводя итоги статьи, если можно разрешить DEFAULT_SCHEMA группе, какой должна быть схема по умолчанию для входа в систему, которая принадлежит двум отдельным группам, каждая со своим собственным значением по умолчанию? Это разница между первичными идентичностями и вторичными, и на то есть веские причины.
Если вы хотите управлять разрешениями в схеме 'dbo', просто создайте логин для локальной группы, затем пользователя в базе данных для этой группы и, наконец, предоставьте этому пользователю КОНТРОЛЬ на schema :: dbo. Это позволит трем лицам (и любому другому пользователю в локальной группе) полностью контролировать все, что есть в схеме dbo. Они смогут изменять, выбирать и обновлять любой объект в dbo.schema, но они не смогут создавать новый объект (если это явно не разрешено). Если вы хотите, чтобы у них был полный контроль над чем-либо в базе данных, а не только над существующими объектами в схеме dbo, просто добавьте пользователя локальной группы к роли db_owner.
Если вы хотите использовать схемы в качестве пространства имен и избавить своих разработчиков от явного использования двухчастного имени, то ... просто не делайте этого. Использование квалификатора имени из двух частей не причинит вреда и только добавляет преимущества.
Что касается №2, мы решаем эту проблему, создавая пользовательские роли базы данных для конкретной базы данных.
Например, у меня есть 3 пользователя домена, которые являются разработчиками. Я хочу, чтобы у них был специальный доступ к базе данных. Создаем доменную группу и помещаем их в нее. Затем создайте связанную учетную запись в SQL. Для этой базы данных (Безопасность> Роли> Роли базы данных) мы создаем новый список и добавляем этот логин в список.
Ролл может давать привилегии для определенных элементов в базе данных, может добавлять разрешения от других ролей (например, db_owner) и многое другое. Это довольно гибко.
Я часто слышал, как люди жалуются на это. В основном потому, что если у них есть «сотни» объектов базы данных, это занимает слишком много времени, но довольно гибко можно быстро добавить все или отдельные объекты. Кроме того, плохое администрирование - не уделять внимания предоставляемому вами доступу.
Ограничение связано с невозможностью определить схему по умолчанию для конкретного имени входа, если оно является частью нескольких групп.
Предположим, они разрешили это.
Если domaingroup DOMAIN \ xx был добавлен как в локальную группу SERVER \ xx1 -> в sqlsecurity, сопоставленную с serverlogin 'xx1', в свою очередь, сопоставленной с db-login 'xx1' со схемой по умолчанию 'xx1' и локальной группой SERVER \ xx2 -> ... со схемой по умолчанию 'xx2'
Предположим, пользователь DOMAIN \ xx входит в систему и выдает инструкцию
CREATE table yy
Будет ли таблица создаваться в схеме xx1 или в схеме xx2? Ответ = НЕ ОПРЕДЕЛЕН
поэтому нет схемы по умолчанию для групп. однако пользователь все еще может выдать
CREATE table xx1.yy
и
CREATE table xx2.yy