January 28, 2014 at 7:09 am
I'm looking for an efficient way to grant/block database permissions based on which server a user connects to.
I have a development server that has a copy of a database which grants development users fairly open permissions (execute/create/drop/alter/read).
When I copy this database to the production server I want the development users to only have read access. I want this to happen for no more reason that I copied the database between the two servers.
What is a way to get this done with very low administrative overhead?
January 28, 2014 at 7:13 am
script up the database copy\restore and include the permission change in the script.
---------------------------------------------------------------------
January 28, 2014 at 7:32 am
George. Thanks for the reply but it doesn't really give me much to go on. What I'm seeking would be some difference at the SERVER level.
What would be different with the servers' configurations that would accomplish this?
Do you have such a script as you suggest OR can you point me to SERVER level screens which I can utilize as the bases of my continued research?
January 28, 2014 at 7:36 am
database permissions are held within the database, so when you copy a database across its permissions come across with it, so there are no server level configurations that can be used. You will need to make the permissions changes each time in the database, hence why I say script it. Do it through the GUI first time and use the script function to produce the SQL for you
---------------------------------------------------------------------
January 28, 2014 at 8:21 am
That it is only possible at the db level is exactly not what I wanted to hear - but expected as the answer.
January 28, 2014 at 8:47 am
sslyle-1091060 (1/28/2014)
I'm looking for an efficient way to grant/block database permissions based on which server a user connects to.I have a development server that has a copy of a database which grants development users fairly open permissions (execute/create/drop/alter/read).
When I copy this database to the production server I want the development users to only have read access. I want this to happen for no more reason that I copied the database between the two servers.
What is a way to get this done with very low administrative overhead?
The easiest way is to list out the database users and then drop them, then add them back with read permission only. Otherwise your script will have to list out current permissions too and then revoke them, messy!
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 28, 2014 at 9:40 am
a scheduled job could check each database, and if it finds the right role or user, perform the same script we are recommending above.
Lowell
January 28, 2014 at 9:57 am
Thanks guys.
All good remarks.
Just getting to the fact that you cannot do this from the simpler server level is what I was thinking as far as I need to carry the conversation.
I appreciate your remarks. And the idea of an Agent Task will certainly pickup changes without my having to do it in the day-to-day routine.
January 28, 2014 at 1:02 pm
First of all, don't grant access the individual developers. Grant access to roles or Windows groups. If you grant the exec etc access to a role, all you need to do in the restored database is to drop that role. Poof, permissions gone. There could still be a role that gives the developers membership in db_datareader.
You should spend to much on effort on this part, because you will only copy from test to production once. You may copy in the other direction more often, though.
I'm assuming here that you are using Windows logins. If you use SQL Server logins, it is all a lot simpler - don't add the logins for the developers on the production server, but give them other logins.
[font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply