How do I assign an entire Active Directory group security access in SQL Server 2008?

• Set the AD group as a login. And "login" means server level login not the AD concept of user/login. In SQL Server speak, this is a server level principal
• Create a mapped user in. You shouldn't really permission a user directly on tables. And "user" means database user not the AD concept of user: in SQL Server speak, this is a "database level principal"
• Add user to role (also a "database level principal")
• GRANT permissions to the roles on the tables (a table or proc etc is a "securable")

Sample script

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 is deprecated starting with SQL Server 2012, where ALTER ROLE should be used instead.

From marc_s answering "How to add Active Directory user group as login in SQL Server":

In SQL Server Management Studio, go to Object Explorer > (your server) > Security > Logins and right-click New Login:

Then in the dialog box that pops up, pick the types of objects you want to see (Groups is disabled by default - check it!) and pick the location where you want to look for your objects (e.g. use Entire Directory) and then find your AD group.

You now have a regular SQL Server Login - just like when you create one for a single AD user. Give that new login the permissions on the databases it needs, and off you go!

Any member of that AD group can now login to SQL Server and use your database.

Granting the permissions within SQL Server to an AD Group is relatively straightforward. It can be done either through T-SQL or Management Studio.

For instance, if you have an AD group called MYDOMAIN\APPLICATION SUPPORT, you would create the login at the server level,and then use mappings to individual databases to give slightly more granular permissions such as data reader.

Ideally, all application access should be through stored procedures*, so only execute permissions on those stored procedures in that database is required.

* From a security point of view, to allow a particular user to see some specific data, you could create a procedure and grant the user execute permission on that procedure, and nothing else. Allowing the user to query directly would mean giving select permission on all the tables involved. It's also easier to work with procedures, and easier to debug.

Stored procedures abstract table access away and limit access. To DBA types, it's like "let me see all your instance variables: I don't want to use methods, getters or setters".