i am preparing for Microsoft exam 70-432 SQL Server 2008 . In the book i read, its highly recommended that you use separate log-in for each SQL Service. But i am unable to understand what is a benefit in using separate USER?
Please let me know if anyone has an idea about this.
Regards,
fayalif
The benefit is that if somehow someone manages to take control of one of the services he will not have access to the other ones.
What Giorgi said and that the different services require different rights.
By using different accounts these individual accounts have as little rights as possible. Combining these accounts by using one account a malicious user could obtain enough rights to do damage.
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.
MS Access causes many performance problems when it is used to connect to SQL Server. How can I prevent MS Access from connecting to my MS SQL Server database?
Take away the rights to the user it connects as.
You have users with Access who also have rights to SQL Server? But you'd prefer they didn't use that tool?
You could look in dm_exec_sessions in a logon trigger and stop users whose program name is whatever Access sends: Is it possible to deny access to SQL Server from specific programs?
This can work, but isn't proof against a savvy or malicious user, since the Program Name is just provided when a connection is made.
Ideally, you'd want to restrict their rights so that whatever objects they do have access to, there isn't very much possibility for them to misuse them. i.e. no direct table access, any views don't select over a "for all time" set of data etc.
Agreed with Cade Roux. If you take away the possibility to use Access, they might use the MS query tool or Excel...
It's better to restrict their rights to data or otherwise tackle the root cause of your problems (user education? lack of better tools?) than just restricting use of Access...
You could use SQL Server tracing to track down users running e.g. long running queries and suggest alternatives. Or educate them. Gently ;)
I'm working on a website (asp.net c# with SQL Server) and the client is asking for SSO solution. I'm looking to use one shortest implementation where we can create sub-domains for different modules and install/deploy on same or different servers but all of these module/application uses same SQL Server and session is also maintained and shared by SQL Server. However the client is concerned about the performance/scalability and security therefore I would like your advise if you have already worked on such projects and if you would recommend me this solution or anything else.
thank you in advance for your help !
Keep your single sign on information in LDAP. It's definitely the most standardized way to store user information and access. It's really just a database but if scalability and performance are concerns this is your best bet.
I need a software that let me compare and synchronize two database on two different server.
I found this, and was great until i deploy the site and put the database online.
Now I can't connect to remote server.
The standard port of SQL server is opened to my IP.
Anyone use it?
Do I miss something?
Does anyone know a better software?
I've tried to get support but after 5 days still no answer on the forum.
Please, any help appreciated.
Red Gate offer some very good tools for this.
There's:
Red Gate SQL Compare
Red Gate Data Compare
For schema management (versioning, continuous integration & automated migrations) you can try Wizardby.
It allows you to apply migrations to multiple database instances in a controlled and consistent manner.
It's a guess, but the most likely cause of your problem seems to me to be that the synchronisation process has amended either the password or the permissions of the login you are using to connect to your remote site. It's impossible to know without more details of exactly what you did with sqldelta.
Try using a username/password combination which works on your local machine. If this doesn't work, you will probably need to request some help from the DBA of the remote machine, either to recreate your original login or restore the database to a pre-synchronisation state.
I'm not sure that this is down to the tool - it would be possible to do this with any of the database comparison tools for SQL server which include permission/login synchronisation.
What is the best option for a windows application that uses SQL server authentication? Should I create a single SQL account and manage the users inside the application (using a users table). Or should I create a SQL server account for each user. What is your experience? Thank you!
Depends on whether the username/password for the SQL server would be exposed to the user, and whether that would be a problem. Generally for internal apps (in smaller organisations), one would trust the users not too log in directly to the sql server. If you have a middleware layer (ie webservices) the password can be hidden from user.
I prefer to use a general login for the DB and manage users in the application. Even if you do create a login to sql for each application user, they could still connect directly, so why not just use a generic sql login that is easier to manage. This is of course assuming all users have the same accesses.
One good practice, if the users potentially can get direct access to the db, would be to grant access only through Stored Procedures and not directly to tables, so that only certain actions can be performed. Steer away from writing business logic or security checks (except basic ones) within the stored procs.
One way I would solve your problem is to write some webservices that check security and does your CRUD (via datasets, etc), but again it depends on the app and environment.
In summary if you have a middle layer or all users have the same access manage the user within the application and use a single user login. Otherwise use a login per user or role.
One option that I have used in the past is to use the ASP.NET Membership Provider. It makes authentication a breeze to use. The only drawback that I saw was that it added a bunch of tables to your database.
The code for using it is very straight-forward.
Here's a blog post about using this in a Windows app. http://msmvps.com/blogs/theproblemsolver/archive/2006/01/12/80905.aspx Here's another article with more details. http://www.c-sharpcorner.com/UploadFile/jmcfet/Provider-basedASP.NET10162006104542AM/Provider-basedASP.NET.aspx
Here's another article that talks about using it with Windows applications: http://www.theproblemsolver.nl/usingthemembershipproviderinwinforms.htm
Google for "ASP.NET 2.0 Membership Provider", and you will get plenty of hits.
What about having SQL accounts based on the level of permissions needed for the task. For example you could have a read only account just used for reporting if your system has a lot of reporting. You would also need an account what has write access for people to change their passwords and other user admin tasks.
If you have situations where certain users are only going to have access to certain data I would have separate accounts for that data. The problem with using 1 account is you are saying that there is no SQL injection anywhere in your application. That is something everyone would strive for but sometimes perfect security is not possible, hence the multi-pronged approach.