We're using SQL 2005 and want to identify individual users so we can trace their SQL for performance purposes, but we're finding it hard to unique identify who is who.
We're using SQL 2005 with connection pooling so every user has the same user in the Activity Monitor. Their NT user name doesn't appear to be set - maybe because we're using SQL Server users not domain users, we're also using Citrix so there is no individual IP address set. In this (very common) environement how do you identify an individual user?
If everyone is using the same username and coming from the same IP you won't be able to tell them apart. Unless you're using windows authentication MSSQL won't even be told what username on windows the user connecting has.
Have you considered changing your setup so that it uses Windows Authentication? It seems like the logical solution to the problem. Either that or setting up separate logins for everyone on SQL but that'd be duplicating your Active Directory user list...
In order to identify users in SQL Profiler, you need to provide that information to SQL Server in some way with each request or as part of the connection context. One way is to connect as different users, but if you have thousands of users, you would need thousands of accounts (SQL Auth or Windows Auth), and it becomes unmanageable quickly.
A much better way is to set the Application Name parameter in the connection string to be the name of the user. Once set, you can filter on that field in SQL Profiler: Data Source=.;Initial Catalog=Northwind;Integrated Security=SSPI;Application Name=RickNZ
The disadvantage with this approach is that connection pooling (which is enabled by default) only shares connections when the connection strings are byte-for-byte identical. So if you make them different per user, then you will have many more connections, with a resulting impact on performance. In a heavily multi-threaded environment, there's also a possibility that you could run out of available pooled connections. Even so, it might be useful for short-term debugging.
Solved the problem by tracking the Client Process Id in Sql Profiler. We can identify a particular user and their PID from within Citrix, or Task Manager in a normal setup. Then filter the output in Sql Profile by that PID.
This is brilliant when you're working on a DB but don't have access to the source of the application. Often standard reports need to be changed, SP's fixed etc, but if you don't know what's being run it's a needle in a haystack - use Sql Profile to track a user, capture the Sql, analyse/debug - fix move on.
Related
I have inherited a SQL Server box with a series of databases and it has Windows Auth for creation/maintaining the well-baked and established databases. The box itself has many other services which require a user to login as admin to maintain.
I now have to create a new database on the server that only a select few in the company, including IT, will have access to. So I'm kind of chasing my tail on the best place to start.
I want to continue to give the guys the admin level access they require to all the other stuff on this box but limit them on SQL Server options so I can better manage the databases and secure them. What might be the best way to unwind the Windows Authentication method and dole out databases / create opportunities for those users while securing new databases they should not access? Am I even going in the right direction by deviating from the Windows Auth method?
One of the primary reasons for creating a second instance on a server is security. By creating a second instance you basically re-start security over again. So this is an option you might consider for your new database. IE Creating a second instance and putting the "secure" database on it.
A few things you should also consider.
First, yes you should unwind your security as possible and give out the minimum security required for any given user/group. This is a best practices thing. Never give out dbo or sysadmin permissions without an explicit reason to do so, and even then question it thoroughly to make sure that there isn't some other way around the problem. Never give out more permissions than are absolutely required.
Second, It is almost impossible to keep the administrator of the server the instance is on out of the instance if they really really want to get in. And I only say "almost" impossible because there may be a way that I don't know about. At the level of administrator for the server, or domain administrator for that matter you have to assume they can be trusted not to try to break in. You probably won't be able to keep them out anyway.
Last but not least if you can move your instance off of a server that has many other services which require a user to login as admin to maintain. This is a security nightmare first of all (as I said above) and second your SQL server will work better on it's own server. I've even heard advice from experts that say you should never remote into the server a SQL Server instance is on. And if you have to remote in definitely don't copy files around while remoted. Generally said the less going on on the server the happier SQL is.
You can remove the domain administrators ability to access the SQL Server by removing the BUILTIN\Administrators group from the SQL Server logins.
I wouldn't recommend moving away from Windows Authentication, as you would create a whole new set of security concerns you then would have to deal with.
Domain admins can
add themselves to any group (local or domain) that has has access to SQL Server
change the service account policies and log in with that
change SQL server to use a service account in case it uses a built in account
use any user account that has SQL Server access
change password to allow this
Do anything in the domain. At. All.
SQL Server always has Window Auth switched on so it is always available to Domain Admins
If it's that sensitive then it needs to be in separate domain or standalone or something.
Good day all,
I am studing the following case:
Scenario: An application connects to the production database(SQL server 2008) using a generic "SA" user instead of the domain user. This is making traces\logs\organization harder, because everything is flagged as done by SA user!
NOTE: In the application the domain user/password is used, the generic account is only regarding to the database.
Questions: What would be the best pratice in this case? every user should have an account to log in the database? (sql using windows authentication) there are +- 500 users is that an issue regarding to database performance? or a generic account is indicated?
Many thanks!
As others have mentioned, Active Directory and Windows Authentication might be more appropriate if that's an option. But if not...
If the application has a central place that creates the connection & transaction prior to update, you may be able to use SET CONTEXT_INFO to pass along the "real" application user while still using a shared SQL account for the login.
Then in your auditing triggers you can pull the information back out again using the CONTEXT_INFO() function
This is the approach used by at least one commercial auditing tool
See also similar SO questions here and here which reference context_info and a blog post Exploiting Context_Info for Fun and Audit which gives an NHibernate example.
Nitpick on something else in your question: you said it's using sa user. Maybe that was just an example, but probably the application should not have so many rights on the server. Create a user with only the rights needed for the particular database(s) that application uses. This limits the impact of any future security vulnerability (e.g. SQL Injection) in your application. And to take it one step further, you might have one connection string with a read-only user account, and then at the point where you create a transaction to update data, switch to a connection string with the read/write user account. You still get most of the benefits of connection pooling, but you limit even further the impact of any application-tier bugs.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is it possible to password protect an SQL server database even from administrators of the server?
I am hosting my database on SQL Server 2008 on a windows 7 machine. The Windows 7 machine and the SQL Server 2008 are controlled and administered by third party admins.
I have sensitive information in my database.
How do I secure my database, so that the third party admins do not look at the sensitive data?
Is there any way to restrict the third party admins from copying the stored procedures, table designs etc.
Only to a limited degree.
If they are administering the actual SQL Server Instance as well they have the "keys to the kingdom". They can view the definitions of every object, make changes to the definitions or the data, and do virtually anything else. Even if they merely have admin rights on the machine but not the server, they can get admin on the server through certain techniques which are generally considered valid rather than bugs or exploits. It is after all their server and the server will obey them.
In a situation like this, you need to be able to trust those admins at least to a degree. If you cannot trust them, you should ideally not be hosting with them at all, and if you can't trust them and must host with them, try to get your own VM where you can at least apply some additional security and auditing.
There are a few things you can do though, but none are completely effective.
The first is encryption. If you meet all the requirements and set it up properly, SQL's transparant data encryption can prevent an admin without the keys from reading the data (but they can still see the structure!) in the database. This is quit effective at protecting the actual data (but not the structure) but is difficult to set up properly.
You can use the "with encryption" option to protect your stored procedures. This is very weak protection and its very easy to get around this. But it at least sends a strong message to the curious that you don't want them looking and makes them jump through some hoops.
Traces and auditing will also help you determine what happened and see if they did anything, but those come at a performance price.
Hi there is no perfect defense for this issue you have to follow some steps to protect up to some extent like
If you don't want any people in the admin group on the server to be able to access the database, then remove the "BUILTIN\Administrators" user on the server.
Enable auditing
Enable Encryption
Use third party tools at io level that block crud to the database unless a password is provided
Apologies in advance for the long post, I am trying to be as clear as possible. Is there a way to disable a user / Windows AD group accessing a database via SQL Server Management Studio (SSMS)?
I have an desktop application that uses a SQL Server 2005 database. The application runs as the user logged onto the machine (unfortunately we can't change that otherwise this would be simple). The database is permissioned with groups (but it would apply to users as well) to give access to the appropriate schemas and objects that the user requires. The users have (and need) the ability to select, insert, update and delete data to complete their process.
The application carries out a series of validation and auditing steps on the user input to ensure they are entering decent data (and for some additional business processing). A user could open SSMS and make these changes through the query editor avoiding the application completely which is what we are trying to avoid. What I am looking for is a way to stop the users updating the database through any tool other than the application provided.
I have found a couple of similar posts (including How to disable SQL Server Management Studio for a user) but these don't quite cover this issue as they work on restricting user access or using different logins.
The only solution I can think of at the moment is to have a set of tables where the user data goes initially and then another process picks this up, runs the application processes on and then puts the data into the master / source tables. Then I could restrict user access to the master tables.
This appears to be a good scenario for an application role.
I have a rich client program installed on users PCs where I want to start storing some user created data on SQL Azure/SQL Server. The potential anonymous-to-me users would key in their name, email account and a password which would get stored on SQL Azure/SQL Server. Then they would start generating their own data. I'm anticipating volumes of maybe 1000 users.
There are times when those users would like to run their own queries against their own data but, obviously, I must ensure that they can never view other users data.
I'm thinking the best way to ensure security of data is for each user to be issued their own SQL Azure account and password. I will setup a SQL Azure user and long password, known only to me, which only has permissions to execute several stored procedures with appropriate parameters being passed to those SPs which will create the SQL Server accounts, logins and add the users to a role which I have created.
Obviously someone running debugging tools could figure out the user name and password but I'm thinking this isn't a big deal. If all that particular SQL Azure account can do is execute a few SPs so what if a malicious individual starts doing that. I will only allow a very limited amount of data to be uploaded before I require payment.
The users can only insert records using stored procedures which use the following:
SELECT #uName=SYSTEM_USER
and only select appropriate parent records. All stored procedures which users can execute would have the above as required to ensure they can only work with their own records.
All views will have embedded with them WHERE clauses such as
WHERE tbLoginName = SYSTEM_USER.
I'm new to SQL Server so I may be missing some fundamental concepts so I'd appreciate any and all comments.
The issue is, as pointed out on http://msdn.microsoft.com/en-us/library/ms189751.aspx:
In SQL Azure, only the server-level principal login (created by the provisioning process) or members of the loginmanager database role in the master database can create new logins.
Those accounts are also capable of alter and drop logins. So if you embed those accounts in the client application, you’re essentially granting every user permission to alter/drop other users accounts. While an average user won’t do that, a hacker will. So you cannot let a client application manage SQL Azure logins, unless only trusted users (such as your IT administrator) are permitted to use the app.
Best Regards,
Ming Xu.
I would like to point out a potential issue in the approach you mentioned: Your master SQL Azure account need to have privilege to create new accounts and grant them access to particular tables. This means your master account itself need to also have access to all those tables. If you store the master account on the client side, a clever user will get access to all users data.
From my experience, connecting to a database directly from a client side application will almost always make your solution less secure. You can do that for testing purposes, but in a real world solution, I would like to suggest you to use a service. You can host the service in Windows Azure. Then the service will access the database, and client application can only access the service. In this way, you can authenticate clients using any mechanisms you like, such as ASP.NET membership.
Best Regards,
Ming Xu.
You are essentially creating a physical two-tier database connection, allowing a client application to connect directly to the database. This is a problem in many ways, including security and performance. From a security standpoint, not controlling from where your customers will connect, you will need to keep your firewall rule wide open for anyone in the world to try to hack every customer uid/pwd. And instead of having only 1 user id to play with, hackers will have up to 1,000...
The second issue is performance. You applications will be unable to leverage connection pooling, creating undue stress on your database server and possibly hitting throttling issues at some point. Using a web service, with ASP.NET membership to manage logins, and using a service account (i.e. the same uid/pwd) to get data will ensure you will leverage connection pooling correctly if you keep the connection string the same for all your requests.
With a web service layer you also have a whole slew of new options at your fingertips that a two-tier architecture can't offer. This includes centralizing your business and data access logic, adding caching for improved performance, adding auditing in a centralized location, allowing to make updates to parts of your applications without redeploying anything at your customer locations and so much more...
In the cloud, you are much better off leveraging web services.
My 2 cents.