I'm new to IIS/ASP .Net development, my application is using connection string which are declared to my web.config.
Now I read/heard that I can use IIS App Pool Identities to use instead of web.config.
Here's what I did:
I've deleted my connection string from my web.config
setup my app pool Identity property -> (Identity = ApplicationPoolIdentity)
Added my connection string declared/within the App Site Connection Strings under "Custom" like "Data Source=sql...blah;Initial Catalog=dbname;Integrated Security=False;Persist Security Info=False;User ID=MyDBUserName;Password=MyPassword;Connect Timeout=60;Encrypt=False;Current Language=English;"
It works as far as I know, but my question is, is this really how you configure it?
I was under the impression that you could use some variable (username, pass, dbname..etc), declared it on your web.config and binds it thru your app pool identities but I cannot find any article regarding that.
Thank You
You can set the user that the app-pool runs under. All that does is make the app-pool think that the user is some particular user who is logged on to the server.
This tends to NOT effect your database code, since you STILL need to tell your code what database to use. Even if your host computer and network is say using a domain controller, and you using windows logons to consume sql server. Your .net code behind will WILL need some connection string to specify the database and server anyway. And you having added that user under app-pool identify (I assume this one):
Well, now that "user" is for your file and network rights. So, that user can say be restricted to some set of folders - maybe a another server with large number of documents.
Added my connection string declared/within the App Site Connection Strings under "Custom"
Yes, and that puts the connection string in web.config - if you check the web config after doing above, you should see that string in web.config.
So, in theory, in your code, you can connect to the database server - and your app-pool user will be used, but you STILL have a connection string - what database, what server, etc. still needs to be defined (and used in your code). I mean, say desktop with windows authentication to SQL server does not get you off the hook as having a defined connection string some place to use. While the user might be running in the context of the "defined" app-pool user, you still need some place to store and eventually use some connection string. So, the fact of defining what user in app pool the code behind will run as? You still need a connection string and the connection string you use to the database would not be stored, nor come from app-pool settings anyway.
Related
I am building a website using asp.net MVC. I have two connection strings in the web.config, one for local db and one for the server db. I am testing my work on local and then put it on the server. the server connection string (user name and password) is also in the web.config. Tomorrow when I sell the product, I want to make sure I don't give this web.config to the clients. but It can happen by mistake. How can I prevent this?
My suggestion would be to use one of two methods:
A ConnectionStrings.config or a Web.Config transform. As usual there are pros and cons for both.
Using a separate config file for connection strings
Each developer can have a local copy of their connection strings
ConnectionStrings can be marked to ignore and never committed to source control
However
- Requires each client/developer to be individually managed
Web.config transforms
Each connection string/build configuration can be source controlled
Requires publish of application rather than just a build
However
Can become difficult to maintain with large numbers of transforms.
Personally I prefer having a ConnectionStrings.config - I don't like having production credentials in source control. It also has the nice side effect of giving a build error if you've forgotten it so you can't leave them out by mistake.
Don't use user name and password in the connection string, but use integrated security.
Instead of this.
User ID=****; Password=****;
Use this.
Integrated Security=true;
And make sure your logon user has access to the local database. And the IIS server has access to the server database.
See here for configuring IIS to be able to access SQL Server.
I follow the direction in here How to configure SQL Server to manage ASP.NET sessions to create ASPState db.
I have 2 web application in IIS 7. In IIS web application setting, i go to "Session State" and set session state as "SQL Server" and provide connection string.
In each web application web.config, i add
<sessionState
mode="SQLServer"
allowCustomSqlDatabase="false"
sqlConnectionString="data source=server;user id=user;password=password"
cookieless="false"
timeout="7200"
/>
I create a session ,
Session["Data"] = "test"
in Web App A and go to Web App B in the same browser to print it
Response.Write(Session["Data"]);
It shows NOTHING. I can see there are data in table : ASPStateTempApplications and ASPStateTempSessions under ASPState Database. Also, i dont see any error in event log. Can anyone think anything i may do wrong?
Thanks!!
You can not get session that belongs to App-A from App-B and vice versa.
The sessions are connected with the cookies, and the cookies are different between app-a and app-b, are random made. Even if set some how the same cookies then next the database connects session with the Application ID, that are also different for each applications.
So even if you have the same database, the application id is different, and the cookies are different, and you can not get session from a to b.
The only possible way to archive that is to make your custom session code, and some how knows that you have the same use on app-A and app-B, so to connected them together.
I have a SQL Server instance that is throwing the "Named Pipes Provider" error, code 40. I know that this is a relatively common error on new installs and there's a convoluted process to fix it. However, the odd part of this error for me is that (1) it only happens intermittently and (2) it only happens with my ASP.NET application. I have other apps that are accessing this server just fine without any errors.
I came across a vague reference to this error happening when your connection string is part of the ASPX code (as opposed to the web.config) and that doesn't make sense but it's the only option I could come up with. Anyone else seen this?
Sounds like a security context issue? How is the asp.net application accessing the sql server? Integrated windows security or sql security? If the earlier check that the identity of the application (asp.net process) which is defined by the Application Pool identity has login rights on the DB.
From http://blogs.msdn.com/b/sql_protocols/archive/2007/03/31/named-pipes-provider-error-40-could-not-open-a-connection-to-sql-server.aspx :
Summary, give checklist:
Is your target server started?
Is your target server listening on NP? Which Pipe?
Has your client enabled NP? Use the same pipe to connect as Server?
Are you making local connection? If so, what is the instance, default or remote?
Did you put correct instance name in the connection string? Remember, Sqlexpress is a named instance.
Did you enable remote connection? Firewall? IPSec? "File and Printer Sharing" opened? Can access server?
Can you make basic connection by using or \? Use sqlcmd or osql.
I am responsible for several ASP.NET web apps running on a local Intranet server. Users outside the company aren't supposed to have access to the server, but I don't like leaving anything to chance if it's not necessary. And only admins should have access to the file system.
Should I encrypt the app settings and connection string sections of web.config? I haven't see this mentioned very often, and I was wondering if it's overkill or not a best-practice. I've got passwords in my connection strings and account info for a service account I use to query AD in the app settings.
BTW: I would encrypt using
Configuration webConfig = WebConfigurationManager.OpenWebConfiguration(System.Web.HttpContext.Current.Request.ApplicationPath);
ConfigurationSection section = webConfig.Sections["connectionStrings"];
if (section != null && !section.SectionInformation.IsProtected)
{
section.SectionInformation.ProtectSection("DataProtectionConfigurationProvider");
webConfig.Save();
}
Should I encrypt the app settings and connection string sections of web.config?
If the connection strings include passwords: then yes, there is no other reasonable option.
If using integrated security to connect to the database, then the information exposure would be database and server names, which is less of an issue. But might be easier to have a deployment rule of always encrypting, because the simpler rule is easier to follow and audit.
You can also use aspnet_regiis.exe to encrypt sections, rather than writing your own code. Enter aspnet_regiis.exe -? into a PowerShell (or cmd) prompt to see options.
I did something similar for encrypting my web.config file, and I don't regret it. Maintaining it isn't complicated, and it adds yet another layer of defense. Since security is built in layer, there's nothing wrong in doing that.
I usually store my connectionstring in web.config or in the application settings of my Visual Studio project. The application I'm currently working on makes a lot of trips to the database which means it will look up the connectionstring every time. Should I be putting the connectionstring in the cache or should I be looking at storing the whole SqlConnection object in the cache to eliminate the need to open and close them all the time?
Update: Seems like the consensus is to store the connection string in a configuration file and leave the caching in the trusting hand of ADO.NET
I wouldn't cache the connection object, that will defeat the built-in connection pooling -- ADO.NET will handle connections (assuming you instantiate and close them) efficiently by itself.
As far as the connection string itself, you shouldn't need to cache it if you load it from connection -- the connection manager object in the .NET 2.0 framework loads the config into memory when you first access it, so there are no repeat trips to the file system.
The web.config is cached. But even if it wasn't, don't forget that ado.net maintains a connection pool - its not opening a new connection every time you make a call to the db.
I usually cache the connection string in a global configuration object in my application. This value is loaded up at the beginning of program execution from where ever it is stored -- file, encrypted file, config file, etc. ADO.NET is very good at caching connection objects to the database so I would not cache the SqlConnection object.
Keep it in a configuration file. Use a robust data access strategy provided by tools like NHibernate or Linq to Sql.
From what I can recall the contents of the .config file are held in memory anyway... I'll get back to you.
Edit: What HE said
A possible solution:
Store the initial encrypted connection string ( in Web.Config or App.Config) for a login allowed to run only one stored procedure for authentication. Than switch the login dynamically from encrypted values stored in a config table in the db.