Como posso mapear um login de grupo do Windows para o esquema dbo em um banco de dados?

Question

Eu tenho um banco de dados para o qual eu quero restringir o acesso a três pessoas nomeadas. Eu pensei que poderia fazer o seguinte:

1. Crie um grupo local do Windows no servidor de banco de dados e adicione os indivíduos nomeados a ele.
2. Crie um login do Windows no SQL Server mapeado para o grupo local do Windows.
3. Mapeie o login para o esquema "dbo" no banco de dados, para que os usuários possam acessar todos os objetos sem precisar qualificá-los com o nome do esquema.

Quando tento fazer o passo 3, recebo o seguinte erro:

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.

Eu tentei fazer isso através do IDE, o comando sp_changedbowner sproc e ALTER AUTHORIZATION , e recebo o mesmo erro a cada vez.

Depois de pesquisar no MSDN e no Google, acho que essa restrição é por design. Ótimo, isso é útil. Alguém pode me dizer:

1. Por que esta restrição existe? Parece muito arbitrário.
2. Mais importante, posso realizar minha exigência de outra maneira?

Outras informações que podem ser pertinentes:

• O servidor está totalmente atualizado com service packs e hotfixes.
• Todos os objetos no banco de dados são de propriedade do esquema "dbo" e não é possível alterá-lo.
• O banco de dados está sendo executado no nível de compatibilidade 80, e não é possível alterar isso para 90 ainda.
• Tenho liberdade para fazer outras alterações (dentro do razoável, dependendo do que elas são).

Answer 1

Por que isso não é permitido, leia em SQL Server: Grupos do Windows, esquemas padrão e outras propriedades . Para resumir o artigo, se alguém permitir um DEFAULT_SCHEMA para um grupo, qual deve ser o esquema padrão de um login que pertence a dois grupos separados, cada um com seu próprio padrão? Essa é uma diferença entre as identidades primárias e secundárias e por um bom motivo.

Se você quiser controlar as permissões no esquema 'dbo', basta criar um login para o grupo local, depois um usuário no banco de dados para este grupo e, finalmente, conceder CONTROL no schema :: dbo a este usuário. Isso permitirá que os 3 indivíduos (e qualquer outro usuário no grupo local) tenham controle total sobre qualquer coisa no esquema dbo. Eles poderão alterar, selecionar e atualizar qualquer objeto no dbo.schema, mas não poderão criar novos objetos (a menos que sejam explicitamente concedidos). Se você quiser que eles tenham controle total sobre qualquer coisa no banco de dados, não apenas os objetos existentes no esquema dbo, basta adicionar o usuário do grupo local à função 'db_owner'.

Se você quiser usar esquemas como um namespace e salvar seus desenvolvedores explicitamente usando um nome de duas partes, então ... simplesmente não use. Usar um qualificador de nome de duas partes não pode causar danos e apenas agrega benefícios.

    

Answer 2

1. Nenhum indício porque existe. Interessante.

Quanto ao nº 2, resolvemos isso criando funções de banco de dados personalizadas para um banco de dados específico.

Por exemplo, eu tenho 3 usuários de domínio que são desenvolvedores. Eu quero que eles tenham acesso especial ao banco de dados. Criamos um grupo de domínio e os colocamos nele. Em seguida, crie a conta associada no SQL. Para esse banco de dados (Security > Roles > Database Roles), criamos um novo rolo e adicionamos esse login ao rolo.

O rolo pode fornecer privilégios para itens específicos no banco de dados, adicionar permissões de outras funções (como db_owner) e muito mais. É bastante flexível.

Eu sempre ouvi pessoas reclamando sobre como fazer isso dessa maneira. Principalmente porque se eles têm "centenas" de objetos de banco de dados, isso leva muito tempo, mas é bastante flexível adicionar rapidamente tudo ou objetos individuais. Além disso, a má administração não é específica no acesso que você está concedendo.

    

Answer 3

A restrição tem a ver com a incapacidade de definir um esquema padrão para um login específico, se ele fizer parte de vários grupos.

Suponha que eles permitiram isso.

Se domaingroup DOMAIN \ xx tiver sido adicionado a ambos um grupo local SERVIDOR \ xx1 - > no sqlsecurity mapeado para serverlogin 'xx1' por sua vez mapeado para db-login 'xx1' com o esquema padrão 'xx1' e grupo local SERVIDOR \ xx2 - > ... com o esquema padrão 'xx2'

Suponha que um usuário de DOMAIN \ xx efetue login e emita uma declaração

CREATE table yy

A tabela seria criada no esquema xx1 ou no esquema xx2? Resposta = INDEFINIDO

portanto, nenhum esquema padrão para grupos. no entanto, o usuário ainda pode emitir

CREATE table xx1.yy

e

CREATE table xx2.yy