Como atribuir um acesso de segurança completo ao grupo do Active Directory no SQL Server 2008?

Eu gostaria de usar a segurança integrada com meu aplicativo interno, que está todo em um domínio. Infelizmente, nunca consegui fazer isso funcionar bem. Gostaria de atribuir a um grupo inteiro do Exchange (Active Directory) uma função no SQL Server para acesso de leitura / gravação a determinadas tabelas. Dessa forma, eu não precisaria criar um operador sempre que alguém for contratado ou excluir um operador sempre que alguém for demitido. Isso é possível? Que medidas eu daria para fazer isso?

• Defina o grupo do AD como um logon. E "logon" significa logon no nível do servidor, não o conceito de usuário / logon no AD. No SQL Server speak, esse é um princípio no nível do servidor
• Crie um usuário mapeado. Você realmente não deve permitir um usuário diretamente nas tabelas. E "usuário" significa usuário do banco de dados, não o conceito de usuário do AD: no SQL Server, este é um "principal no nível do banco de dados"
• Adicionar usuário à função (também um "principal no nível do banco de dados")
• Permissões de GRANT para as funções nas tabelas (uma tabela ou proc etc é um "protegível")

Script de amostra

USE master;
GO
CREATE LOGIN [MYDOMAIN\APPLICATION SUPPORT] FROM WINDOWS;
GO
USE mydb;
GO
CREATE USER [MYDOMAIN\APPLICATION SUPPORT] FROM LOGIN [MYDOMAIN\APPLICATION SUPPORT];
GO
CREATE ROLE rSupport;
GO
EXEC sp_addrolemember 'rSupport', 'MYDOMAIN\APPLICATION SUPPORT';
GO
GRANT SELECT, INSERT,UPDATE, etc ON Mytable TO rSupport;
GO

sp_addrolememberfoi descontinuado a partir do SQL Server 2012, onde ALTER ROLEdeve ser usado.

A concessão das permissões no SQL Server a um grupo do AD é relativamente simples. Isso pode ser feito através do T-SQL ou do Management Studio.

Por exemplo, se você tiver um grupo do AD chamado MYDOMAIN\APPLICATION SUPPORT, criaria o logon no nível do servidor e usaria mapeamentos para bancos de dados individuais para fornecer permissões um pouco mais granulares, como o leitor de dados.

Idealmente, todo acesso ao aplicativo deve ser realizado por meio de procedimentos armazenados *, portanto, apenas é necessário executar permissões nos procedimentos armazenados nesse banco de dados.

* Do ponto de vista da segurança, para permitir que um usuário em particular veja alguns dados específicos, você pode criar um procedimento e conceder ao usuário permissão de execução nesse procedimento, e nada mais. Permitir que o usuário consulte diretamente significaria dar permissão de seleção em todas as tabelas envolvidas. Também é mais fácil trabalhar com procedimentos e mais fácil de depurar.

Os procedimentos armazenados abstraem o acesso à tabela e limitam o acesso. Para tipos de DBA, é como "deixe-me ver todas as suas variáveis ​​de instância: não quero usar métodos, getters ou setters".

De marc_s, respondendo "Como adicionar o grupo de usuários do Active Directory como logon no SQL Server" :

No SQL Server Management Studio, vá para Object Explorer > (your server) > Security > Loginse clique com o botão direito do mouse em New Login:

Em seguida, na caixa de diálogo exibida, escolha os tipos de objetos que você deseja ver ( Groupsestá desativado por padrão - marque!) E escolha o local onde deseja procurar seus objetos (por exemplo, use Entire Directory) e encontre o seu grupo de anúncios .

Agora você tem um logon regular do SQL Server - exatamente como quando você cria um para um único usuário do AD. Dê a esse novo login as permissões nos bancos de dados de que ele precisa e pronto!

Qualquer membro desse grupo do AD agora pode fazer login no SQL Server e usar seu banco de dados.

Se o usuário for membro de um DOMAIN \ SecurityGroup que possui autoridade Sysadmin no SQL, isso será usado ao acessar bancos de dados. Caso contrário, você precisará verificar quais DOMAIN \ SecurityGroup (s) receberam autoridade em cada banco de dados. Se o usuário for membro de 2 SecurityGroups, com SecGroupA com autoridade de seleção e SecGroupB com autoridade de inserção, o usuário poderá selecionar e inserir.