This is my first post on this forum. I have a question in regards to securing connection strings in web.config and app.config for a solution I am working on. I have a web farm with a central node that's used to push out the solution to all the servers in the web farm, this is done using a batch script.
I would like to secure the connection strings in the web and app configs on all the solutions. I know that aspnet_regiis can only be used with web.configs so it's not an option and I built a small app that secures connection strings for web and app configs but it only runs on one machine, how can I programmatically secure web and app configs in a web farm scenario? I haven't tested it yet, because I imagine it will fail, but can I just copy the programmatically secured web.config and app.config to all the servers and it will...just...work?
It will work, provided you do have the same machineKey value set for each machine.
You can set it in machine.config file in framework home directory.
Related
I am new to web development. We are having a legacy intranet web application using ASP.NET web forms.
We have encrypted web.config using ASPNET_REGIIS tool for the connection strings, based on security feedback. I am able to test it locally using IISExpress.
What are the steps to follow to update the old web.config with new web.config, in an environment.
We need to update web.config in multiple environments(DEV,TEST, UAT) before refreshing in production.
We will be announcing downtime for the same. Please list down the steps like resetting IIS etc.
Since the key used for encrypt/decrypt is different on different server. You can decrypt the connection string section before publishing. Then just override the web.config on your target server, then encrypt the connection string with asp_regiis tool again. You can find aspnet_regiis under the root folder of .NET framework.
Of course, there is a way to sync up RSA container for mutiple servers.
https://learn.microsoft.com/en-us/previous-versions/aspnet/yxw286t2(v=vs.100)
After that, please don't forget to grant permission for machinekey file in \Microsoft\Crypto\RSA\MachineKeys.
Finally you just have to recyle the application pool.
I had to do below steps:
First and Foremost: Took a backup of existing web.config, so that, if something goes wrong, I can fallback to original web.config
As web.config encryption is machine specific, I encrypted the web.config using ASPNET_REGIIS tool, as mentioned in the codeproject Link
Web.config changes are automatically picked by IIS. I did not have to restart IIS or recycle APPPool. The site was working fine with the new web.config changes, I made.
Is it possible to have a Data Source configured on IIS and get access to it from an Asp.Net application (Entity Framework), instead of configuring the connection in "Web.config" file of the web application?
I mean, I don't want to make database connection dependent of the application, but leave its configuration to the server. So the application can access it.
I know this kind of architecture is wildly used on Java EE applications, where datasource configuration resides on server and is accessed by its JNDI name.
How can we do that in IIS and Asp.NET with Entity Framework?
A simple approach to share connectionstrings among different websites is placing it on machine.config.
All web configs inherits from this file so any setting there is available on your application (unless you explicitly say not to do it).
I have an MVC2 .NET 4.0 app, hosted on TFS 2008 (soon to be TFS 2010) that uses connection strings in web.config to connect to a database on another server. I need to encrypt these connection strings.
As I understand it, I can use aspnet_regiis.exe to encrypt the connectionstring portion of the web.config file, but I have to do it on the deployment machine because the encryption uses the machine name to generate the encryption key.
Now, it seems to me that this represents a problem - every time I deploy my code to the dev server won't it overwrite the web.config file, and need to be re-encrypted? This sort of manual process seems kludgy.
Is my understanding about needing to re-encrypt after deployment correct?
If so, is there some way to automate this process? I don't want to forget this or get a new team member who doesn't know the process and have the connectionstring exposed to the world.
web.config files aren't typically part of a deployment (though Visual Studio 2010 supports configuration file transforms in web application deployment projects). I wouldn't expect that you should be overwriting the web.config when you deploy (because the web.config is where you would place those things that are specific to that machine/environment.
So, encrypt it once, and then don't overwrite it, would be my advice.
Since that isn't available in your situation, it is possible to specify a key when encrypting, so that you can share the encrypted file between machines. By default, the command to encrypt uses the DPAPI to encrypt the section (which is tied to the machine) but you can also use RSA for encryption. More info is available on MSDN in Specifying a Protected Configuration Provider.
What changes are required in web.config file to configure Web Farm ?
Normally, when asked this in an interview, you will be expected to know that all machines in a web farm should have the same <machineKey>.
Read more details here (Generate Machine Key Elements for Web Farm).
Anybody can provide me the best practices to be followed in deployment of asp.net web application & WCF service in IIS 7 regarding the IIS 7 configuration settings , Security setting, application access level settings..
Does this help? IIS Security. Where possible you should only install / enable the IIS features that you intend to use.
It depends on your situation.
I always publish my solution to a folder, zip it, ftp it to my server.
On the server (using RemoteDesktop) i backup the running version (makes me feel safe & secure) and delete all the files, except web.config. I unzip the file i sent and copy all the files, except web.config. If i made changes to web.config i adjust it manually.
This works for me because i have a shitty internet connection. If it were faster i'd do it differently.