I'd have to implement my own security for the application (windows form).
The application is for internal use (10 users) but security is very important due to sensitive data. (SQL Server 2008 is in the back end, .NET 4.0)
I don't have a login form but I have a connection string in app.config. So I guess that maybe app.config is a good place to implement AD groups? Or borrow asp.net membership provider?
Thanks for advice.
If you're trying to maintain database permissions, set them on the database and have your application use Integrated Security=True in the connection string. The user will connect as themselves to the database and have whatever permissions the database specifies.
Why not just use active directory group membership to control security? Your connection string to the SQL Server database can go in the config file, but you should probably 'encrypt' that before releasing it to clients.
If you're determined to check the user's AD groups and prevent the application from continuing to run on startup, take a look here.
Related
I have an application that accesses a database directly. This application controls what user can do according to the context.
At the moment, I am using Windows authentication, but all the users has permissions to select, insert, update and delete, because it is the application which controls the action.
For example, one user can modify a document, but only if the document is created by this user. So in the database the user has to have permissions to create a update, but only if it is the owner of the document. I am not sure if I can handle this case with SQL Server user roles.
But the problem is that all users have all the permissions to the database, so they could use another application, like SQL Server Management Studio, to access the database and do what they want.
So I was thinking in the option to use SQL Server authentication, with full access to the database. This user is not known by users, so they can't use another applications to modify the database.
The problem that I see with this solution is that I have to store the credentials in the client application, and I don't know if it is really a secure way to do it.
If using SQL Server authentication is an good option, how could I store the credentials of the user in a safe way?
I have read about application roles too, but it is needed to store the password in the client application, so I think I would have the same problem. And also I don't see the difference between application role and to use SQL Server authentication.
In summary, is it a good solution to use SQL Server authentication in the way I explained above? And if it is a good option, how could I store credentials in a safe way?
Thanks.
The difference between an application role and using SQL Auth is that the application role password is not enough, by itself, to access the database. The user must be individually authorized first and can be individually monitored and audited.
how could I store the credentials of the user in a safe way?
The application role (or SQL Auth) password is never truly secure when used from a client application running on a machine where the user is an administrator. So you could run the app in desktop virtualization, or a kiosk-mode PC.
But for many scenarios involving mostly-trusted users application role security is good enough, especially when combined with Windows Integrated auth so the users access to the database can be audited.
I have a website that is used for uploading data to a restricted database. Usually when I built out connection strings for SQL Server inserts, it was from an in house user so I could use windows authentication, what's the best practice for when the user does not have access to the database?
The best practice is to authorize your IIS APPpool where your website is running on... You can simply do this by creating a user in sqlserver.... FOr example IISApppool\Yourapppoolname. You can find the name of the pool where your site is running in the IIS manager.
Yes exactly, read this article msdn it's very interessant
Link : http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring(v=vs.71).aspx
Link : http://www.connectionstrings.com/
You have to use a SQL user specific to the website.
I have a small web application in asp.net and I'm using SQL Server. How do I authenticate my web application to block some people from changing the database?
This statement has to change from this:
Data Source=AYKUT-PC;Initial Catalog=BUS;Integrated Security=True
To something like this:
Data Source=AYKUT-PC;Initial Catalog=BUS;Integrated Security=False
Integrated Security is a feature that allows SQL Server to authenticate a user based on their Windows login.
You could also use SQL Server authentication, which would require a specific user name / password to login.
Finally - you could use Mixed mode that would allow both SQL Server and Windows authentication.
Here's an article about it: http://technet.microsoft.com/en-us/library/ms144284.aspx
If you would like a more detailed answer about how to implement it - you should probably give more information about your situation, and what your requirements are.
EDIT:
SQL Server can restrict permissions to users (or SQL Logins). So you could restrict acccess to certain tables through a combination of authentication methods and security permissions.
I have written some C# which connects to a live production database. I want to give my application read only access to the DB but am unsure how to achieve this.
Is there any trivial way to get this done by amending the connection string?
My understanding is that the application will logon with the credentials of the person running the application and hence may or may not have write access to the db based on that fact. Can I statically limit the permissions of the application so that if someone changes the program to do something devastating at a later date any manipulation will fail?
Apologies for how trivial the question may be but it's my first venture into the world of MS programming.
Thanks,
Gav
You can't change the permissions for the account by changing the connection string. There is a user account in the database that determines the permissions.
Unless you want different people to have different permissions, you should set up an account for the application and use in the connection string.
For any account in the database you can specify which databases it can access, and what it can do with the databases. The permissions can be specified down to the level of objects and operations, so you can for example specify that it can only do selects on certain tables.
Have it login to the database server as a user that only has read-only permissions. That and just don't try to write anything to the database.
You can always grant the user connection to your database just the "db_datareader" role on that database.
db_datareader gives your user SELECT permission on all tables - but nothing more.
There are basically two main types of SQL Server authentication:
Integrated Windows authentication and
Mixed authentication mode (SQL Server authentication)
It sounds like you are using the former. If you use the latter you can create a specific user account within SQL Server, give it a username and password, and then grant access to the tables you wish it to be able to read. You can control at the account level what access it has to any object in the database.
See http://msdn.microsoft.com/en-us/library/ms144284.aspx for more details.
Just a thought; usually not every logged in user gets to access the database, let alone a read-right. Therefore you in your case you can create a database user for your application with read rights; and use that in your connection string.
I am connecting to a SQL Server database via LINQ in my ASP.NET application (returning results to a web service). The problem is that it only returns results when I'm running it in debug/test mode - When I publish the service I get an error telling me
"Login failed for user 'NT AUTHORITY\NETWORK SERVICE' "
So how do I set / provide the credentials I want the site to use to log into SQL Server?
Thanks in advance for any help
You have to set the credentials in the connection string.
It's possible that the connection string to use on the server will be different than the credentials to use during Development. Ask your DBA which credentials you should use.
You are likely not passing a connection string into your DataContext constructor, causing your program to use the connection string in the constructor, which you have been using for development.
So instead of using something like this:
using (var dc = new MyDataContext()) {
...
}
use
using (var dc = new MyDataContext(MyConnectionString)){
...
}
... and take MyConnectionString from your config file...
A few questions first
Is the SQL server on the same machine?
If it's on a different machine is it in a domain?
Are you using a full SQL installation, or SQL Express?
I'm going to assume you're using a full version of SQL, because if you're using SQL Express user instances will not give you this problem.
If it's on the same machine then you need to add Network Service to the list of allowed users in SQL. To do this start SQL Management studio, expand the security folder, then right click on Logins and choose New Login. Click search on the "Login - New" dialog, making sure Windows Authentication is selected then enter Network Service in the object name box and click Ok. Choose the database you want it to access from the drop down list in the Login - new page and click ok. Finally expand out the databases folder and for each database you wish to grant access to expand out security, right click on users, then select the network service login name, give it a name in the dialog of Network Service and grant it the right access by checking the role in the Database role membership list. If you're messing around db_owner will be fine, you will want to lock this down later.
If the SQL server is on a different box and you are in a domain you can run the application pool as a domain user and grant that access on the SQL box. How to do this varies on the version of IIS.
Finally you can use SQL logins and passwords if the SQL server is configured to do this. Create a SQL user and then add them to the connection string like so
Data Source=myServerAddress;Initial Catalog=myDataBase;User Id=myUsername;Password=myPassword;
In your question, it is unclear if you are using a different database between development and production. Typically, you would have (at least) two copies of the database and would set the connection string to point to the correct environment when you deploy typically by changing the value in the web config. Alternatively, you could set the connection string at runtime using the technique Dave mentions.
In your case, I suspect that you are using integrated authentication and getting cought off-guard by SQL security permissions. When you are testing this in your local environment by debugging it in Visual Studio, it runs under your security credential. Most likely, your user account is an administrator (db owner) in the database and thus you have full permission against the database.
When you deploy this, IIS is running under the NetworkService credential. When you try to access the database, the request fails because NetworkService has not been given rights in the database on each of the tables/views/sprocs/etc.
If you have mixed mode set on your server, you can set the permissions on each database object to a SQL user and set the SQL user and password in your web.config. Alternatively, you can change the user account that the IIS process works under and configure the database to work with that user.