OMO: MS SQL Server

[timwilky]

I cannot be bothered trying to find an join a sqlserver forum to ask one question. So hope the mighty org may know.

My background is Oracle so I may not use quite the correct terminology, so be understanding/gentle.

Our outsourced datacentres provider, is refusing to grant elevated rights to users saying the instance is shared to multiple databases and would comprimise the security of other databases.

In the Oracle world I am familiar with. The users within an instance only have rights to that instance. Granting them DBA rights etc would not impact upon any other instances hosted on that server. (unless they tried to do something stupid that impacted upon server resources, such as extending tablespaces/ rollback segments etc.)

Is the outsource DBA just being pig headed and protective of his sqlserver environment. The only way out I see is to pull our databases from his servers and host elsewhere.

[Teejayexc]

What ?

[Haircut]

If you are a "SQL Server Admin" on your instance rather then a "Local Admin" on the server then you will only be able to see the databases on your instance.

It is possible that he is thinking in terms of a "Local Admin" on the server which would give you inherited SQL server rights to all instances on the server.

If you were gransted "SQL Server Admin" rights to your instance it is possible that you could make changes that could impact the performance of the server, it could potentially also impact the security of other files on the server dependent on how the SQL services have been set up.

It is also possible that there are databases on your instance that they do not want you to see.

Could your issues not be solved by "elevated" user rights?

[shiftin_gear98]

What kind of world do you guys live in. One I'm glad I don't.


As Teejayexc said, What?

[phi-dan]

Sounds to me like they have taken some shortcuts when setting the db permissions and are granting rights at the instance level.
It should be possible for them to apply the appropriate rights to each db, but at the cost of having to redo ALL of the rights/roles.
Having done it the "wrong" way for years it was only when we migrated to a new domain (and started from scratch with our permissions) that we were able to remove all the bodges.

Sent from my XT1068 using Tapatalk

You have 3 levels of admin rights here.
Physical Server.
Server instance.
Database.

The server admin, can do pretty much as he pleases.
The Server instance Admin (SA account would be an example) can do whatever he wants to the database, but is limited by the rights the server admin grants him to file access etc.

the DB admin only has "owner" rights on that database, and may not have rights to do things like backup and restore, these can only be set at server, or instance level.

I'd ask for "DB Owner" rights on your database, and do the rest yourself personally.
C.

[timwilky]

Thanks guys.

I am glad I have little to do with MS stuff, it sounds easy to poorly design for the enterprise for the convenience of operation.

Enough of the techy stuff. Back to two wheels

[Haircut]

Originally Posted by timwilky

Thanks guys.

I am glad I have little to do with MS stuff, it sounds easy to poorly design for the enterprise for the convenience of operation.

Enough of the techy stuff. Back to two wheels

Yes often configured wide open or nailed down shut by 'DBA''s without the knowledge or time to configure correctly.

I should not moan, I always get admin access . . .

[russell664]

With webservers for example (One.com etc...) they use a single server, split into multiple webservers - but they all seem to share the same SQL database internally.

I dound this out as I wanted to change some PHP caches, and enable some stuff for Drupal. I contacted One, and they basically said exactly the same as what you posted above mate.

We run a lot of MS SQL databases at work. Normal practise seems to be to setup multiple instances, and then run one or two databases per instance.

It wouldn't surprise me if there were some pretty subtle ways that you could subvert another database if you tried hard enough.

For example, (in Oracle) utl_file can open any files that the database process has access to. So unless you've gone to the trouble of running each instance as a different service account, not making any of them local admins, and setting file ACLs correctly, you can open any file (in a directory that the DBA has permitted). That includes files that control the behaviour of other instances.