Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

different user database permissions across servers Expand / Collapse
Author
Message
Posted Tuesday, January 28, 2014 7:09 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, July 29, 2014 12:33 PM
Points: 8, Visits: 28
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?


Post #1535426
Posted Tuesday, January 28, 2014 7:13 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 7:18 AM
Points: 5,871, Visits: 12,972
script up the database copy\restore and include the permission change in the script.

---------------------------------------------------------------------

Post #1535429
Posted Tuesday, January 28, 2014 7:32 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, July 29, 2014 12:33 PM
Points: 8, Visits: 28
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?
Post #1535445
Posted Tuesday, January 28, 2014 7:36 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 7:18 AM
Points: 5,871, Visits: 12,972
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

---------------------------------------------------------------------

Post #1535450
Posted Tuesday, January 28, 2014 8:21 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, July 29, 2014 12:33 PM
Points: 8, Visits: 28
That it is only possible at the db level is exactly not what I wanted to hear - but expected as the answer.
Post #1535481
Posted Tuesday, January 28, 2014 8:47 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 2:54 AM
Points: 6,414, Visits: 13,796
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"
Post #1535505
Posted Tuesday, January 28, 2014 9:40 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 6:44 AM
Points: 12,901, Visits: 32,135
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

--There is no spoon, and there's no default ORDER BY in sql server either.
Actually, Common Sense is so rare, it should be considered a Superpower. --my son
Post #1535542
Posted Tuesday, January 28, 2014 9:57 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, July 29, 2014 12:33 PM
Points: 8, Visits: 28
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.

Post #1535549
Posted Tuesday, January 28, 2014 1:02 PM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Wednesday, September 24, 2014 1:24 PM
Points: 805, Visits: 722
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.


Erland Sommarskog, SQL Server MVP, www.sommarskog.se
Post #1535596
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse