I am newbie in asp.net. and I need to store some string (aka connection string) permanently. It is looks well if I store it to in web.config.
I need that user can modify it string via web ui. Than is why I must do it programmatically. But ApplicationPoolIdentity doesn't have writing rights to web.config. And I don't want to bother admins so that they grant rights.
I thought I can store data in some file in {user}\AppData but by default App Pool doesn't load user profile. UPDATE It's not quite right. I don't know exactly what default settings is. But I still can not get access to folder. See my paired question UPDATE2 I have access to LocalAppData now and can store my connection string. I had to write an installer who enable loading user profile. But I think this is too complex solution.
So where I can store on string and modify it programmatically without any administration of IIS?
Storing connection strings in database seems illogical to me, as you have to connect to database to read the connection string.
Better place is web.config. There are chances that if you change connection string, then IIS will restart your application but it will be good because you will change connection string when you have change your database server's location or password. IIS restart will ensure that new connection string is used in every where.
Related
I've been trying for just over a month to connect an ASP script here to a SQL Server database
but each time I use this connection string:
Data Source=dbServer01;Initial Catalog=POS123;Integrated Security=SSPI;User ID=domain\usr;Password=pwd;
It ignores the user I specify and takes the machine name to authenticate the connection, which obviously fails.
so I change the Integrated Security value to False, like this:
Data Source=dbServer01;Initial Catalog=POS123;Integrated Security=False;User ID=domain\usr;Password=pwd;
I then get an error: Login Failed for user "domain\usr" which is impossible because it works when we test the connection with it in the odbc admin app.
I asked the help of a senior and he said it's taking the user name as a database user name, but we need to make it use windows authentication, and specify which user to use.
I remember reading about this a month ago and finding that there was no way to specify a user and password when connecting using windows authentication with this version of ASP.NET.
I'm going to kill myself soon If I can't get this script to connect, someone save me please!
You've got at least 2 3 options here:
Create an App Pool on your web server which runs as domain/usr and then assign your app to this app pool, and use integrated security. Your connection string will be Data Source=dbServer01;Initial Catalog=POS123;Integrated Security=SSPI; - i.e. drop the username and password - these are inherent in the AppPool's identity.
or (assuming Mixed Mode security is enabled) ask your DBA's to create a new SQL User (just called usr) with the same permissions as domain/usr and then change your connection string to standard security, with User Id=usr
If you enable impersonation (here and here), you can use the domain credential without changing the app pool identity. Note the point about securing cleartext passwords, and IME this typically also requires additional configuration to avoid the double-hop issue.
ASP.NET websites should store connection string in web.config file for various reasons and best practice. Today I was asked by my manager that "Can we store DB username and password in another location on top of web.config file? It will be easier to change SQL id/password without having developer change it every time on Production if that is done".
I wanted to ask experts the same question - is it possible to retrieve SQL connection string id/password from another place instead of web.config? I know the best practice is to store it into web.config but I am just curious is it even possible at all?
Of course, you can read the username/password from virtually anything that is accessible through code (if I understand your question correctly).
Have you looked at Web Config Transformations?
I cannot connect to my SQL Server database when running app on server.
Everything runs fine when debugging but when I run on the server as ASPNET the user is unable to login.
I created the dataabse in a test project then simply connected to this db. My connection string is
Data Source=.\SQLEXPRESS;AttachDbFilename=C:\Temp\Barry\fsr\FSR.mdf;
Integrated Security=True;Connect Timeout=30;User Instance=True
So this asp app runs on IIS 5 and when deployed the initial select works fine as my gridview that I have a binding to shows data but when I run the program (update the db) I hit the following:
[SqlException (0x80131904): Cannot open user default database.
Login failed.
Login failed for user 'hostxxxxx\ASPNET'.]
I am not creating this database programmatically as mentioned previously, simply connecting to an existing database.
The database is located on my c: - but I have added user ASPNET. How can I add this db to the program as a resource rather than reference a copy on c:?
My first question is this: If you have control of the server, why are you using an attached database. From:
AttachDbFilename=C:\Temp\Barry\fsr\FSR.mdf
There is no reason to attach if you can control the server. Attach the database to the actual instance in SQL Server, not with the bastardized version you have above. The bastardized version is useful on an ISP that does not give you access to SQL tools. Beyond that, it is more work than it is worth.
The second problem you have is authentication. There are a couple of ways to handle this. The easiest is set up a SQL user to access the database. If every user will have login credentials, you can keep the Windows Authentication method, but you have to turn off anonymous access, so every user GETS authenticated. As long as anon is a choice in IIS, it will default to anon and you will have issues. The third way is to impersonate a user for database access. I guess the fourth is open your database wide open, but I don't suggest destruction of security to make something "work".
If you have your database on a server, you need to use a server-based connection string - something like:
Data Source=servername\SQLEXPRESS;database=FSR;
Integrated Security=True;Connect Timeout=30;
Your user needs to have a login on the server, and a user in the appropriate database, in order to connect successfully.
See the ConnectionStrings.com web site for a huge list of possible connection strings - and what their settings mean and how you can change those.
You need to get into your database and assign the proper privileges to the account that is trying to access the database, which in this case looks like the built-in ASPNET account. Instead of the ASPNET account, you should use the NETWORK SERVICE account. You can change this through IIS.
Our ASP.Net application uses SQL Server 2008. Most of the time the application connects to SQL Server using a SQL account with very limited access rights.
However once in a while we need to be able to create a new database on the fly. As such we need elevated permissions and I am a little nervous about storing this connection string in Web.config, which may be in a DMZ.
We are considering writing a Windows service to run on the SQL Server machine (i.e. not in the DMZ) which will monitor a table for requests to create a new database, but it seems like overkill.
Any suggestions for alternatives or recommended practices?
You can store the connection string in the registry and protect that by limiting access to the specified registry keys. That's one of the ideasI ran across back in .Net 1.1 as a reccomendation from Microsoft. The concept is still the same in 2.0 and up. Here's a link to the documentation.
http://msdn.microsoft.com/en-us/library/aa302406.aspx
It sounds like you're already concerned about security, so I'm guessing you've read through or at least run across the "Building Secure ASP.Net applications" section of the MSDN library. The link above is in the how-To section of that guide. Hopefully this is helpful.
Also, if you DO store your connection info in the web.config, at a minimum, encrypt those portions.
And I just ran across this. Probably more like what you were looking for.
http://msdn.microsoft.com/en-us/library/aa302388.aspx#secnetch08_storingsecrets
If you are using mixed mode authentication in your database connection strings (I.E., username and password) then you should encrypt the web.config connectionStrings element.
What about using a stored procedure to create the database? I haven't tried it; the one part I'm worried about is specifying the database name through a variable. By using the stored proc, you only need to grant your web id execute access on the stored proc.
Another option would be to create a console app (instead of a service). Then use a job scheduler to run the job every 15 or 30 minutes or upon request if you have a capable scheduler. That will be much simpler than writing a service; it just isn't an "instant" process. I do this for some Active Directory work that triggers off of web site updates (I didn't want to give my web id Domain Admin priveleges).
I’m using .Net 3.5 and SQL Server 2008 Express.
Should I use the administrator user for the connection string,
Or should I create a new user with limited permissions?
If I need to create a new user for the connection string:
What security permissions should I grant him?
How do I set those permissions?
Thanks.
You must definitely create a specific SQL login, which you will use for database hits in your application.
Access only to the database it uses.
Assign specific write/read permissions according to the logic you have.
Never use Admin users account. Decide what all permission is required by your application then create the user based on that. I dont work mostly with SQl servers but I don't think there is a definite rule for this. It depends on application and the situation.
if the application is used to display only records then grand only read access.
Please check this post too
Enterprise Connection String Management in ASP.NET - Best Practice?
never use the sysadmin (sa) account - EVER!! create a new account, probably start with a member of the Public group, which is the default and then work from there.
Also, do not embed the pwd in the connection string - rather make it part of a config file; not only is it more secure, it's easier to manage.
In fact, you should really store the entire connection string in a config file.