SQL 2008 R2 создает пользователя / схему, когда пользователь Windows создает таблицы

9

Мы добавили имя пользователя сервера и базы данных, которые сопоставляют группу Windows с экземпляром SQL 2008 R2 с помощью следующего сценария, имена которого изменены для анонимности:

USE master
go
CREATE LOGIN [DOMAIN\AppUsers] FROM WINDOWS
WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english]
go
USE AppDb
go
CREATE USER [DOMAIN\AppUsers] FOR LOGIN 
[DOMAIN\AppUsers]
go
EXEC sp_addrolemember N'db_owner', N'DOMAIN\AppUsers'
go

Когда учетная запись DOMAIN \ User1 входит в приложение, User1 отлично выполняет запросы к таблицам в схеме dbo, поскольку User1 является членом DOMAIN \ AppUsers, но это приложение также позволяет пользователю создавать таблицы. При создании этих таблиц без указания схемы SQL Server выполняет следующие действия:

  1. Создает пользователя «DOMAIN \ User1» в AppDb, который использует имя входа «DOMAIN \ User1», не указанное в SSMS \ Security \ Logins для экземпляра.
  2. Создает схему 'DOMAIN \ User1' в AppDb.
  3. Создает эти таблицы, используя новую схему DOMAIN \ User1.

Я полностью сбит с толку этими результатами. Вот мои вопросы:

  1. Я ожидаю, что создание таблицы не удастся, а создаст дополнительные объекты. Может кто-нибудь указать мне на ту часть Books Online, которая объясняет это?
  2. Почему сервер не создает схему 'DOMAIN \ AppUsers' и не добавляет новые таблицы в эту схему, если собирается добавить схемы?
  3. Кроме того, как база данных использует имя входа, не показанное в SSMS \ Security \ Logins?
  4. Если посмотреть на пользователя 'DOMAIN \ User1' в SSMS \ Databases \ AppDb \ Security \ Users, значок пользователя имеет небольшую красную стрелку, указывающую вниз. Что это обозначает?

Мы только начинаем использовать проверку подлинности Windows в организации, которая для простоты предпочла проверку подлинности SQL, поэтому я уверен, что мой вопрос заключается в том, что я не знаю о различиях. Этот код был написан задолго до того, как мы рассмотрели вопрос об использовании проверки подлинности Windows, поэтому я уверен, что нам нужно улучшить понимание создания новых схем при входе в систему с использованием проверки подлинности Windows от имени любого другого лица, кроме владельца базы данных.

В случае, если вы не можете сказать, я настаиваю на использовании проверки подлинности Windows поверх проверки подлинности SQL. Если мы не получим четкого понимания этого, мы вернемся к SQL-аутентификации.

flipdoubt
источник
Вы можете определить схему по умолчанию {dbo, например} для пользователей домена, но не для групп домена.

Ответы:

9

Это всегда происходило, начиная с SQL Server 2000.
Как SQL Server узнает, что без схемы вы хотите поместить ее в dboсхему?

Единственный способ указать схему по умолчанию:

  • использовать логины SQL (не Windows)
  • запустить как "сисадмин"

Ни один из них не является приемлемым

Рекомендуется всегда квалифицировать схему для каждой ссылки на объект для DDL и DML. Существуют явные преимущества в производительности благодаря повторному использованию плана.

Кроме того, преднамеренное использование схемы лучше для SQL Server 2005:

  • таблицы в Data
  • другие таблицы в Archiveи Stagingт. д.
  • код в схемах для клиентских разрешений: Desktopи WebGUIт. д.

Использование схемы dbo - это последнее тысячелетие :-) Ссылки:

ГБН
источник
Таким образом, мой вывод заключается в том, что мы должны обновить код, чтобы добавить новые таблицы к схеме, верно? Означает ли это, что появление нового пользователя в узле безопасности является обычным явлением?
flipdoubt
@flipdoubt: да, обоим. Как только вы входите в него и используете схемы в качестве пространств имен или контейнеров, это становится второй натурой
gbn
Последний вопрос. Если обычной практикой является автоматическое добавление пользователей и рекомендуется указывать схемы во время создания объекта, как вы можете предоставить права на новую схему до того, как автоматически созданный пользователь создаст ошибку при запросе объекта в новой схеме? Используя приведенный мной пример, касающийся «DOMAIN \ User1», я могу назначить доступ к учетной записи «DOMAIN \ AppUsers», но будут ли запросы использовать права доступа для «DOMAIN \ User1» или «DOMAIN \ AppUsers»? Это настолько подлый, что сервер создает пользователя, как только объект создан.
flipdoubt
Разрешения будут по умолчанию для владельца схемы, который является user1. Это похоже на DB_OWNER для схемы
gbn
2

Ну, @gbn печатает быстрее, чем я ...

Мое единственное предложение ... Вы ссылаетесь на то, что пользователь входит в приложение, и это позволяет ему создавать таблицы и тому подобное. Если приложение разрешает это, а пользователь не делает этого через сам SQL Server (вход в базу данных напрямую с помощью SSMS), вам нужно будет узнать у поставщика этого приложения.

Сообщество
источник
Мы написали приложение.
flipdoubt
2

Хотя вопрос очень старый и на него уже есть принятый ответ, я постараюсь ответить на ваши вопросы более конкретно (вместо того, чтобы давать общие советы).

  1. Поведение описано в https://docs.microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql , в разделе «Неявная схема и создание пользователя».

  2. Если вы хотите, чтобы объекты создавались в конкретной схеме (когда схема не указана явно в операторе), вы должны указать DEFAULT_SCHEMA для пользователя. В SQL Server 2008 R2 (и более ранних версиях) вы получите сообщение об ошибке, если попытаетесь назначить DEFAULT_SCHEMA пользователю на основе группы Windows, но в SQL Server 2012 (и более поздних версиях) это теперь возможно.

  3. Он не отображается просто потому, что для этого пользователя нет логина. Как указано в https://docs.microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql , пользователь может быть создан для того, кто входит в систему с использованием другой группы или даже без любой логин.

  4. Маленькая красная стрелка (или маленькая красная буква X в более новых версиях SSMS) представляет пользователя, у которого нет разрешения CONNECT в базе данных (однако это разрешение может быть получено через другую группу).

Разван Соколь
источник
0

Хотя это старый вопрос, я наблюдал это поведение (в SQL Server 2014) и обнаружил следующее:

Учитывая сценарий

USE [master]
CREATE DATABASE [Test]

USE [Test]

-- Note that we create the users without specifying the default schema
CREATE USER [MyDomain\MyADGroup] FOR LOGIN [MyDomain\MyADGroup] -- ad group
CREATE USER [MyDomain\MyDomainUser] FOR LOGIN [MyDomain\MyDomainUser] -- ad user (not in said AD group)

ALTER ROLE db_ddladmin ADD MEMBER [MyDomain\MyADGroup]
ALTER ROLE db_ddladmin ADD MEMBER [MyDomain\MyDomainUser]

EXECUTE AS LOGIN = 'MyDomain\MyAdGroupUser' -- a windows account which is a member of [MyDomain\MyADGroup]

CREATE TABLE Test
(
    a INT
)

REVERT 

EXECUTE AS USER = 'MyDomain\MyDomainUser'

CREATE TABLE Test
(
    a INT
)

Этот скрипт создаст две таблицы с именем Test.

Первый CREATE TABLEсоздает таблицу с именем, [MyDomain\MyAdGroupUser].[Test]а также создает MyDomain\MyAdGroupUserсхему (а также MyDomain\MyAdGroupUserпользователя базы данных, который отключен)

вторая CREATE TABLEсоздает таблицу с именем[dbo].[Test]

Причина этого заключается в том, что, поскольку CREATE TABLEкоманды не раскрывают схему подробно, они будут использовать схему по умолчанию.

Поскольку мы не указали схему по умолчанию при создании пользователей, SQL Server устанавливает схему по умолчанию для пользователя Windows как dbo, но НЕ устанавливает ЛЮБУЮ схему по умолчанию для пользователя группы Windows, и поэтому это вызывает создание схемы / пользователя.

SEarle1986
источник