Well, permissions and SQL are a little more complicated than normal folder/file NTFS security ACLs.
First, will SQL be running on a machine that users who need access to SQL be logging on locally? Will the users actually walk up to your SQL box and physically log into it? Since SQL is normally installed and running on a server, I am gonna assume NO. The users will not be logging onto the server itself to run their queries on SQL server.
('cause we all know when users touch a server, let along log into one -- when given the rights to log into a server -- that the users normally manage to DESTROY the server!)
Ok. So the users are going to log into their normal workstations in your office and connect to SQL server using an application, web site, direct ODBC connection or whatever. There are a lot of ways to connect to SQL server.
Now, the acutal NTFS permissions on the SQL server really aren't any different from normal permissions. This is because you can build logins ON the SQL server, then ASSIGN the users domain logins TO the SQL server logins.
You see, it is a 3 step process, technically.
1) you build a login on SQL Server's Enterprise Manager for the user(s) to use. Off the top of my head, I believe the path is open your server, open Management, then Logins. This is where you make them.
2) During the login creation process, you can assign a Windows user or group to a login. This works if the SQL server is in Native mode (where only NT/2000 user accounts can connect) or Mixed mode (where you can build SQL accounts or connect with Windows accounts)
3) You can then assign the logins rights by adding them to Roles (syadmin role for full server control, DATABASEREADER to do Select statements only, DB_OWNER to doEverything to a database but not do anything to a server, etc).
