I have to access some customers databases being hosted in a shared environment. There are numerous databases being hosted on any given customers instance. So everytime I access a database I have to scroll and search.
I would like to be able to configure Management Studio to just go directly to the database I want to work with for a given connection and hide all others on that connection/instance. But i still want to be able to see databases on other instances i might be working with, i.e. local using the same Object Explorer.
If that not possible is there any reason why the web hosting provider would grant their customers the VIEW ANY DATABASE permission? Im assuming thats why I can see all the other dbs?
If i cant configure Management studio to do what i want as per (1) then I was going to email the provider and ask that they prevent me from seeing them from the "server" end. Would this be an easy thing for them to do? If they REVOKE the VIEW ANY DATABASE permission then that should solve my "problem" right? But would it create any others?
You will require access to the master db to effect the outcome you want. There are no options to configure Sql Server management Studio (SSMS) to do what you want.
So (1) is out.
(2) however is a go so long as your service provider play alongs. You are right they will have to
DENY VIEW ANY DATABASE TO youruseracount
which will require access to the master db. But before they do this they will have to set youruseraccount as the owner of your database.
sp_changedbowner 'youruseraccount'
The side affect of all of this is
a. You wont be able to see any other databases in the instance which is what you want.
b. Only one user will be able to use SSMS to admininster your database with the 'View Only My Db' list. This is because only one user can be the Database Owner.
..
Richard
2 articles describe it (no point if I copy/paste, really)
One and Two
Related
Before I ask my boss to enable Ad-Hoc queries, I want to know what I'm asking for.
Every once in a while (at least once a year, but not more than once a month), we get an excel sheet that has information that we need to put in the database. I'd like to write a stored procedure that takes the path to the spreadsheet as a parameter and does the necessary processing, but when I try to use OPENROWSET, I get this error:
Ad hoc access to OLE DB provider 'Microsoft.Jet.OLEDB.4.0' has been denied. You must access this provider through a linked server.
I've done some looking, and it seems that I have two choices:
Add a linked server, which is undesirable because it sounds like I would need to put the excel sheet directly on the machine that is running SQL Server. I would like anyone on the team to be able to run this process, but not everyone should necessarily have access to the server machine.
Allow Ad-hoc access to the database. This seems more desirable, but I want to know why Microsoft disables this functionality to begin with before I go asking permission to poke holes in our security.
So, does anyone know what the actual security risk is here, or is it just Microsoft being paranoid?
I have to execute some queries in Firebird, but I need to hide "query source" from viewing in mon$statements or any other log in database.
That's because the query has some business rules that I can't expose to other people.
Is there any way to do it? Or some "trick" that I can use?
There is no way to do this. However MON$STATEMENT only shows your own queries, unless you are SYSDBA, the owner of the database, or a user with the RDB$ADMIN role (then you can see all queries). Other then MON$STATEMENT, there is also the trace facility which allows people with sufficient access to see queries (either on the server or through the service api). People with insufficient access to the database can still see queries if they can see the network traffic between the application and the database server.
The only way is to not give any form of access to the database server to people who should not be able to see the queries. This can be done by hosting the application as a webapplication, or putting a webservice or other form of middleware between the database and the real application.
Problem
Is it somehow possible to create a Windows Authentication login for a SQL database without performing a check for the user at creation time?
Example
Consider ServerA that exists in our DomainA, and ServerB that exists in the customer's DomainB. Being separate companies, DomainA and DomainB never share resources. But, if we backup from ServerB and restore to ServerA, we are able to see the existing SQL logins for users from DomainB, and even modify and code against these logins. This is good, because we are able to develop the database schema on ServerA and then publish to ServerB.
But, if I want to add a new user for this database, and am working on ServerA in DomainA, the following command produces an error:
CREATE USER [DomainB\User];
Windows NT user or group 'DomainB\User' not found. Check the name again. (Microsoft SQL Server, Error: 15401)
This is bad, because we're no longer able to develop on ServerA using the same schema as ServerB.
Backstory
I'm attempting to bring our database-driven application's database schema into source control using a Visual Studio 2010 Database Project. It's important to me to make this work well enough to convince the boss not to continue using 60-GB database backups in a zip file as a means of 'Version Control' (especially since this is just for schema, and not a backup routine). VS2010 DB Projects use scripting to create/modify databases, and so they can't create WinNT users for an unknown domain. In order to get the boss's buy-off, we're going to have to be able to match the capabilities of restoring a backup, and that means being able to re-create users for domains that we don't have access to.
Using SQL Server 2008 in my case.
Note - DBProjects are best suited to managing and versioning your SCHEMA, not your data.
If you want to keep rolling backups of your SQL databases as a whole, then I'd recommend a decent backup strategy.
If you want to better manage your databases' evolving schemas, then using DBProjects may well be your best bet.
FWIW, if you reverse-engineer a DB into a DBProj, you could then run a script to replace DomainB\known-user with DomainA\known-user prior to deploying within DomainA, no?
No, because SQL needs to know the windows SID (ugly GUID) of the user at the time it's created.
Note that you can, however create a SQL or Windows User with the same name and password as your remote SQL, Machine, or Domain user, and it will be able to log in.
I want to install an application (ASP.Net + SQL server 2005 express) in local network of some small company for demoing it for a period of time, but I also want nobody even sysadmin have no permission on this database and any permission granting wants a secure pass that I have .
I just want my tables structure and relations and functions be hidden and encrypting the data have no advantage
I need to spend more time on this article Database Encryption in SQL Server 2008 Enterprise Edition that i found from this answer is-it-possible-to-password-protect-an-sql-server-database
but
1.I like to be sure and more clear on this because the other answer in this page says :
Yes. you can protect it from everyone
except the administrators of the
server.
2.if this is possible, the db have to be enterprise edition ?
3.is there any other possible solutions and workaround for this?
4.if I install a new instance with my own sa password , can i restrict other instances admins from attaching the mdf to their own ?
thanks in advance
These people can access your server or the SQL Server instance no matter what you do
anyone with physical access to the server
domain admins of the network
anyone with the sa password
a windows group with local admin and/or sa rights (which implies group policy etc)
You have to host your server offsite if you want no-one to get to log onto it.
It is that simple
In SQL Server, you cannot "password-protect" a database - what you can do is limit the permissions a given user or role has in your database.
You can DENY anyone access to your database - but that's a bit odd, since no one will be able to use it....
You can do all sorts of stuff to your database tables and logins - but a sysadmin will always be able to get around those things and get access to the database. As long as the sysadmin can get his hands physically on the server, I don't think there's any way to totally shut them out.
If you don't trust even your sysadmins, you have bigger problems.....
There's several different ways you could solve this problem.
Host it offsite - I think the easiest solution would just be to host it offsite. There's loads of cheap shared hosting out there which you could use.
Lock out the sysadmins from that server. Assuming you have root access and only you use/need that server you could change the root password and any other passwords on the server.
Do what you're currently doing and try to make something secure even when someone who shouldn't have access has root access to the server. This way sounds tricky and insecure even at best.
I have a contribution for (3):
I'm guessing (I might be wrong) you don't actually have sensitive information in your database, you just want to make it unfeasible for someone in the local network to use any of your stuff.
If that's the case, you could just make it harder for them to read your data by encrypting the data in the database and having your (compiled) code decrypt it before using it.
This way, any sysadmin who is just curious about the data or wants to change his hiscore to 13371337 will not want to go through the trouble of decompiling your code and/or cracking your encryption (for the duration of your demo) and your (assumed) problem will be solved.
I have no idea if this helps you at all, I guess I just want to say you might want to take a look at your problem again. Since you can't keep the sysadmins away from your stuff, you may want to take a different approach like making it less useful to them.
As discussed by the various other posters, you can't password protect a database - deny permissions - to the sysadmin. One alternative that hasn't been discussed is hosting it on a Laptop. Since this is a demo, you can host the Database and ASP.Net site on a laptop and hook that up to their Network - after Sysadmin permission of course - and have the clients test the application from your laptop.
This will allow you to protect the database from Sysadmins and provide the added benefit that if you want to allow them to see the database you can let them use your laptop and you will be there watching their actions on your database. This last benefit is something that you can't do easily with a hosted solution.
The above answers point 3. As for point 2, you will need the Enterprise Edition of SQL Server to take advantage of Transparent Data Encryption (TDE) as per the comparison link on MSDN. If you click on the Enterprise Security link at the top it will show a table explaining the different security capabilities of the different SQL Server versions and it shows that TDE is only for the Enterprise Edition.
I'm quite new to Microsoft SQL Server. I have some experience with MySQL, and there you have a user with privileges, if I understand things right; these privileges decide which databases you have access to on the MySQL server.
However now I am in the situation where I have to restore a database on my SQL Server 2005 Express, and this database has it's own users and user password. So if I want to make these users accessible from the outside (so that they can connect to my server), how would I go about that?
To illustrate clearer; say there are two login accounts on the database server "Mike" and "John", and on the database "Animals" there are two users; "Chris" and "Jeff".
I need Jeff to be able to sign in to get access to the database. Is there a good way to make this happen without creating new users/logins? And if not, what is the best/most common solution?
I would really appreciate any helpful input on this!
One server-level object (login) is mapped to multiple database-level objects (users).
A login cannot be mapped to more than one user within a database, but can be mapped to at most one user in each database.
Therefore, you need to create new logins for those users, but map them to existing users. This is done with ALTER USER command. Or, if you don't have any use for the Mike and John logins apart from mapping them to those existing users, you can do so, too.
Any user needing to access a database needs to either have their own login, or you can create a login for a Windows security group and grant access that way to a whole set of users. Then if you need to give access to more users in the future you can just add them to the windows security group.