different user database permissions across servers

  • 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?

  • script up the database copy\restore and include the permission change in the script.

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

  • 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?

  • 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

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

  • That it is only possible at the db level is exactly not what I wanted to hear - but expected as the answer.

  • 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" 😉

  • 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


    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

  • 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.

  • 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