Como atribuo um acesso de segurança de grupo inteiro do Active Directory no SQL Server 2008?

• Defina o grupo AD como um logon. E "login" significa login no nível do servidor e não o conceito AD de usuário/login. No SQL Server, esta é uma entidade de nível de servidor
• Crie um usuário mapeado. Você não deveria realmente permitir um usuário diretamente nas tabelas. E "usuário" significa usuário de banco de dados e não o conceito de usuário do AD: no SQL Server, este é um "principal de nível de banco de dados"
• Adicionar usuário à função (também um "principal de nível de banco de dados")
• GRANT permissões 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_addrolememberé preterido a partir do SQL Server 2012, onde ALTER ROLEdeve ser usado.

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

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

Em seguida, na caixa de diálogo que aparece, escolha os tipos de objetos que deseja ver ( Groupsdesativado por padrão - verifique!) e escolha o local onde deseja procurar seus objetos (por exemplo, use Entire Directory) e encontre seu grupo AD .

Agora você tem um login regular do SQL Server - assim 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.

Conceder as permissões no SQL Server para um grupo do AD é relativamente simples. Isso pode ser feito por meio do T-SQL ou do Management Studio.

Por exemplo, se você tiver um grupo AD chamado MYDOMAIN\APPLICATION SUPPORT, você 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 leitor de dados.

Idealmente, todo o acesso ao aplicativo deve ser por meio de procedimentos armazenados*, portanto, apenas as permissões de execução nesses procedimentos armazenados nesse banco de dados são necessárias.

* Do ponto de vista da segurança, para permitir que um determinado usuário 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 os tipos de DBA, é como "deixe-me ver todas as suas variáveis ​​de instância: não quero usar métodos, getters ou setters".

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