I have following connection string in my web application.
<add name="ApplicationDs" connectionString="Data Source=(localhost);Initial Catalog=DBName;User ID=XXX;Password=xxxxxxx;" providerName="System.Data.SqlClient"/>
For some security purpose , unable to put sql username and password directly in web.config file. If anything build in security option is available in asp .net to handle this.
Advice me
Use integrated security and run your web application with a user account you gave permissions to within your database.
Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;
for more connection string examples, find them here
http://www.connectionstrings.com/sql-server-2012
You might consider encrypting your connection string section. If the security issue is that the username and password cannot be exposed in clear text, then encryption might help/solve the issue.
For more information on web.config encryption, see this link.
Related
I have inherited an asp.net 2.0 application that uses a SQL Server 2005 Express database and I am grappling with the authentication mode.
I have read that windows authentication is more secure and locally that works just fine. I use the default machine account and a trusted connection in the connection string similar to :
value="trusted_connection=True;server=MYMachineName\SQLExpress;Database=DatabaseName;Pooling=false"
On the server though, I find myself having to grant more privileges to the aspnet user (execute, update) in the database and am wondering if this makes sense after all. The login verification is actually handled by the application.
Does it make more sense to set up a database user and use those credentials in the connection string? Would this be an acceptable connection string?
value="Server=myServerName\SQLExpress; Database=myDataBase; User Id=myUsername; Password=myPassword;"
If you’re not in a need for a very high security you’ll be doing just fine with sql authentication.
Try this connection string instead
<add name="connstring" connectionString="Data
Source=myServerName\SQLExpress; Initial Catalog=myDataBase;
Persist SecurityInfo=True;User ID=myUsername; Password=myPassword"
providerName="System.Data.SqlClient"/>
Previously for all our asp.net applications we have been using a sysadmin user within SQL Server to connect and add/update/delete/get data. Our SQL Admin wants to delete that account and create a Domain Account so we can use that account within our .net applications.
My current connection string is:
name="name" connectionString="Data Source=server;Initial Catalog=database;Persist Security Info=True;User ID=user;Password=password" providerName="System.Data.SqlClient"
What would the connection string be for using a domain account?
I tried:
name="name" connectionString="Data Source=server;Initial Catalog=database;Persist Security Info=True;User ID=domain\user;Password=password" providerName="System.Data.SqlClient"
and it does not work.
Is there a different way to connect to SQL Server using a domain account?
Have a look at connectionstrings.com for every possible variation - a very handy resource I use all the time
Specifically, you want this format:
Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;
This, of course, only works if the domain account in question is the one opening the connection.
There's no easy way to connect with arbitrary credentials - but you can impersonate the user in question and then connect.
This can be a bit of a pain. An alternative if the users are on the local network (or you control their browser config) is to use Kerberos authentication on your site. The pages will be served with the relevant user's permissions - then you can use the connection string above and IIS will connect to the Db with the appropriate credentials for each user. This is particularly useful from a security perspective as the Db is able to audit on a per-user basis, and permissions can be per-user/row/column instead of only per-app.
If you want to use different user account then the logged in user you have two options.
Option 1
You can add the user to Application pool Identity.
For this go to advance setting of application pool and edit the identity to use the user you want.
Option 2
Add this in Web config:
<identity impersonate="true" userName="Domain\User" password="Password" />
And use this connection stirng:
<add name="Name" connectionString="Data source=SqlServer;Initial Catalog=DbName;Integrated security=True" providerName="System.Data.SqlClient"/>
For More Details See:
https://msdn.microsoft.com/en-us/library/134ec8tc.aspx
Also found another good article here
https://www.codeproject.com/tips/520341/implement-impersonation-in-asp-net
Use integrated security:
Integrated Security=SSPI
Which has a variant:
Trusted_Connection=True
The different connection strings (for a variety of databases) can be found on connectionstrings.com.
With both of these you need to ensure that the application is running under the account you need to login with.
Yes, try this:
Data Source=server;Initial Catalog=database;Integrated Security=SSPI;
This specifies that you wish to use integrated Windows authentication where you were still trying to use SQL Server authentication (even though the username you entered looked like a Windows domain / user account SQL server still treats it as standard SQL Server authentication)
Also take a look at connectionstrings.com
Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;
The above is a connection string for Windows Authentication against your SQL Server instance.
I have been building my web application with visual studio and sql server express and now I'm in the process of deploying it on a server. I need to change the connection string
This is what I have:
<add name="MySiteDBConnectionString"
connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\MySiteDB.mdf;Integrated Security=True;User Instance=True"
providerName="System.Data.SqlClient" />
This is what I need to replace it with:
<add name="LocalSqlServer"
connectionString="Data Source=DBServerName;Integrated Security=false;Initial Catalog=DBName;User ID=DBLogin;Password=DBPassword"
providerName="System.Data.SqlClient" />
The problem is that I don't know where or even if I set up a password for the database. What is integrated security?
I'm using linq-to-sql, do I also need to make some changes in the dbml file?
Thanks for some suggestions.
If you are not using Intergrated Security you will need to set up a user and password on the database server itself. If you are using shared hosting it is possible this will be provided for you. You can then replace DBLogin and DBPassword with your credentials.
Intergrated security uses your windows login/password details to authenticate against the database.
With your linq to sql if you are not passing in a connection string yourself you will need to use the designer to change the connection to the new database (or just overwrite the one in your config file).
Integrated security means that it will use credentials that the web site (app pool) is running under to access the database. You'd need to have SQL server set up to allow this account access to read/write your tables in order for this to work. If your web site is set up to run under the anonymous network account, then it's unlikely that this would be the case. If your web site runs under a domain account, then it's possible that you would need to use integrated security.
If you're not using integrated security, then your DB admin will have set up a SQL login for your application. This is the id/password that you need to use in your connection string. It's possible that multiple accounts have been set up, an admin account, a read/write account, a read-only account, execute SP account (these describe the permissions assigned to the account, not necessarily their names). In that case choose the appropriate one -- it's almost certainly not the admin account unless your DBAs know nothing about security.
FYI, if you use the User ID=...;Password=... format, you can omit the Integrated Security=false as it will assume a SQL login account and password.
'Integrated Security' mode is what was formerly called 'Use Trusted Connection': it uses the credentials of the currently logged on Windows user (in this case, most likely the IUSR_xxx account the web application is running as, or sometimes the computer account) as its login credentials.
We have a windows account in the SQL Server 2008 called drwho for example
and a password. In the connection string we disabled integrated security and added User Id and password values.
User Id=THEDOMAIN\drwho;Password=......
However ASP.NET keeps thinking we are using SQL server authentication.
Any suggestions?
You cannot connect to SQL server using a domain user/pass. If you wish to connect as a domain user, you need to specify integrated security and run your ASP.NET process as that user.
See this page at Microsoft for more information.
You will have to use impersonate to do this. As far as I'm aware you can't pass domain usernames/passwords in connection strings only a trusted connection, .e.g.
<identity impersonate="true"
userName="domain\user"
password="password" />
the best place to check the validity of your connections strings is here
I suspect that you have not quite got the format correct.
Have you had a look at http://www.connectionstrings.com/? Always a good resource if you're having connection problems.
I'm trying to use Impersonation and Delegation in an intranet ASP.Net web-app in order to pass authenticated users' credentials onto a SQL Server.
The web server and SQL server are two separate machines, but in the same domain, so Delegation is required.
I've done the following:
set <authentication mode="Windows"/> and <identity impersonate="true"/> in my web-app's web.config.
enabled Constrained Delegation from the web server to the MSSQLSvc service on the SQL Server, in Active Directory.
enabled only Windows Authentication in the website, through IIS.
Apparently this should all work, but it doesn't (the SQL Server is denying access to the anonymous user - "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'").
In IIS7, the Application Pool is set to use Integrated Pipleline Mode and is running with the NetworkService Identity. The website only has Windows Authentication enabled, Extended Protection is Off, Kernel-mode authentication is enabled, and NTLM is the provider.
All the web pages I've read seem to indicate that my setup should work. What am I missing?
I've discovered the answer:
The Windows Authentication provider in IIS7 must be set to Negotiate:Kerberos, not NTLM. This means that the Kernel-mode authentication setting must be disabled. This seems to be fine. I think I'm right in saying that Kernel-mode authentication is required when using a custom identity, i.e. one specific identity. Delegation can use an arbitrary number of identities. So all is well.
I've written a blog post about this too, which goes into a bit more detail.
No - it is not accurate to say you need Kerberos, an SPN, to trust the server for delegation, and that this is the ONLY way to do it. Yes, this is one way to do it (and you do need all of it to make it happen via Kerberos), but it is not the ONLY way, or even technically the most secure way or easiest way. Do you really want to have to do extra configurations and create a login for every web user to your DB in SQL? What if any one of those accounts is compromised? More accounts, more vulnerabilities.
No, create a Domain service account, instead, and let that access SQL. If your security guys lock down things, give that user these rights: Logon as a service, Logon as a batch job, and Allow logon locally. Or, if this is just to develop and test the theory or you don't care or can't find the settings or are still getting errors later on, and this might not get a large following, but give it local Admin (sometimes you gotta do what you gotta do - some security pros lock down things tighter than I would care to write about - can always troubleshoot security later to lock it back down). Then set that account as the custom account on the app pool and give that account a login in SQL. Give it dbo on just THAT ONE database.
On the website in IIS, set the authentication type as Windows. I've seen them say "Basic" in other blogs so Kerberos will work, but NTLM uses Windows authentication. In IIS 7, you may also want to enable ASP .NET impersonation. Personally, I've only tried this on IIS 6, but the principal is the same.
In the web.config, add this under <configuration>, which is a "peer" to <system.web>:
<connectionStrings>
<add
name="NorthwindConnectionString"
connectionString="Data Source=serverName;Initial
Catalog=Northwind;Integrated Security=SSPI;User
ID=userName;Password=password"
providerName="System.Data.SqlClient"
/>
</connectionStrings>
And in <system.web>:
<authentication mode="Windows"/>
<identity impersonate="true"
userName="domain\user"
password="password" />
Then read the string into your app like this:
using System.Configuration;
string connString = String.Empty;
if (ConfigurationManager.ConnectionStrings.ConnectionStrings.Count > 0)
{
connString = ConfigurationManager.ConnectionStrings["NorthwindConnectionString"].ConnectionString;
if (connString != null) // do DB connection stuff here
Console.WriteLine("Northwind connection string = \"{0}\"",
connString.ConnectionString);
else
Console.WriteLine("No Northwind connection string");
}
See http://msdn.microsoft.com/en-us/library/ms178411.aspx.
If it will not connect with the service account after filling in that account in the web.config for the impersonate tag and the SQL connection, you can then use impersonation methods using WindowsImpersonationContext (http://msdn.microsoft.com/en-us/library/system.security.principal.windowsimpersonationcontext.aspx). Specifically, you want wic.Impersonate() and wic.Undo() after getting their token. You can read in the service account domain, name, and password from the web.config, in the form of AppKeys.
In short, there are ways around the issues. You can even encrypt the password in the web.config - both in the ConnectionString, and if you want to store it in an AppKey instead of directly in the "impersonate" tag, if you don't want plain text passwords in there (which I'd recommend against), and so you can have it for the creation of a Logon token, if you need to use the Impersonation methods (as I did).