We setup multiple Websites based on single Assembley. All sites use Forms authentication mode, set on single Web.config file. Now we need to setup an Intranet site based on the same assembley (as well as same Web.config file) but this time it should authenticate users with Windows authentication mode.
Can anyone be able to give some guidelines about this?
It would be ideal if we can do it with IIS7 module without tweaking the Web.config file.
Sounds impossible. You need to put the "Windows Authentication" site in it's own directory. The Web.config (and linked configs) and License.config needs to be unique for that site. But the rest of the application files can be an exact copy of the other dir.
Related
We are using ASP.NET for our web application which is hosted in IIS 8.5. ASP.NET uses a web.config file to store all application and IIS related configurations. Whenever we deploy a new version of code for the web application, we also deploy the web.config file.
Recently the operation team has raised a concern to this deployment process. They say, if someone change some settings in IIS and for that web.config has been updated for that, there is no way for the developers to know that change so that they can update the web.config in codebase (version control system). So eventually at the time of next deployment the web.config changes will be overridden by the old web.config.
There are two possible solutions can be taken:
Merge the web.config with server and codebase before deploy the code everytime.
Decouple the application configuration and IIS configuration in different configuration files.
My question is, what is the best practice to solve these kinds of problems in ASP.NET?
IIS 7+ introduced its distributed configuration which allowed for IIS as well as .NET configuration to live inside of Site/App/Directory web.config files. One of the primary reasons for this is as follows: In IIS 6, whenever an application team needed to deploy their application and make changes to settings like Default Document, they needed the IIS team involved because "Default Document" was an IIS configuration setting. You could argue that Default Document settings for a particular application is not IIS configuration, but instead is Application configuration. As result, the Application Team should own that configuration setting and deploy it as part of the application.
A bit more about IIS7+ configuration system: Administrators are able to configure what settings are allowed to be set inside Web.config files. For example, by default, "Default Document" is able to be set inside Web.config files, and Authentication settings like Windows Authentication are not. The implementation can actually get complex, but if you'd like to read about it, you can see it here: https://learn.microsoft.com/en-us/iis/get-started/planning-for-security/how-to-use-locking-in-iis-configuration.
Ultimately the best practice is for IIS Administrators to configuration the settings they want Application teams to manage (by delegating those settings to Web.config) and then not touch them. In other words, if Default Document needs to be updated, then it is the Application Team's responsibility and they publish a new web.config file. If the IIS team decides they want to manage Default Document, then they need to lock down the IIS configuration system to prohibit Default Document from being managed in the web.config files.
I'm working with an ASP.NET application that is currently used only from intranet. The authentication mode for it is integrated Windows security. I now have a requirement that a part of the system should be visible externally with Forms based authentication.
Is it possible to set up authentication in web.config in a way that access to one of the pages goes through Forms while the other pages use integrated auth? Can it be done using a single web.config or do I need a subfolder with its own web.config file?
I know I could create a separate application for the external part but that would mean moving common parts around which ideally I'd like to avoid.
authentification-tag can be located only in Machine.config, Root-level Web.config, Application-level Web.config (source).
I suppose you should create new website in IIS for each authorization mode and add virtual directory that point to source code location. Every website should have custom web.config with authorization-settings.
You can set two MembershipProvider to authenticate users using FormsAuthentication.
For instance, if you want your application to authenticate intranet users with ActiveDirectory, you will select your first MembersipProvider and for the others the second one (you can manage it simply in your login page).
http://msdn.microsoft.com/en-us/library/system.web.security.activedirectorymembershipprovider.aspx
Or you can implement your own MembershipProvider:
http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx
I'm looking for a guide on how to set file permissions for hosting an ASP.NET project in IIS 7.
Full access rights for all files in the project directory to everyone works, but I guess this is not a good idea?
Thanks for your help in advance!
Take a look at the "In Practice" part of my answer to this question:
What are all the user accounts for IIS/ASP.NET and how do they differ?
You should prefer to use "Application Pool Identity" on with IIS7:
Application Pool Identities
IIS 7 has some pretty good security around the \inetpub directory already. When adding a site the default id that the worker processes execute under already have all of the permissions necessary.
The only real reason to change these is if you are allowing file uploads to be saved to disk. At which point you are better off creating a directory outside of your site structure and using a virtual directory to point to it.
However, some applications like DotNetNuke, require the worker process to have read/write permissions on the site files themselves, including the web.config. This is generally a very bad idea.
I am using a 3rd party component which creates settings files based on hard-coded file paths i.e. they are compiled into the DLL e.g.
%APPDATA%\Vendor\Settings.ini
I have created a few console/service applications that use this and work very well. However, I am now trying to use a similar approach via my ASP.NET MVC web application and the settings file never seems to write out!
Usually if the application is running under my acconut for example the file would be written to somewhere like:
C:\Documents and Settings\James\Application Data\Vendor\Settings.ini
So I thought if the website AppPool was running under the same account the file would be saved to the same place....However, it never appears. The account is an admin account running under Windows server 2003.
Any ideas?
Thanks.
Have you checked to see if the settings file is created in the App_Data folder in the web application? If not, could you put an existing settings file there and see if it uses it?
It's not about the webpool account, it's about guest user's account.
Go to the properties of your site in IIS, Directory Security and in the anonymous access click on the Edit button, there you'll see wich account is been used when someone access your site.
Couldn't find a solution to this, so I decided to develop a local WCF service (which would create the settings file in the correct directory path) and just accessed it via my web application.
Environment: IIS 6.0, ASP.NET 3.5
I have the need to secure just one file with windows authentication and just want to ensure that I understand my options correctly.
Through IIS turn off anonymous
access for the file I want to
secure, and make sure Integrated
Windows Security is checked
Put the file in its own directory and drop a web.config file in there that has the authorization configuration setup for that directory to require windows authentication
Is there a way to setup the web config to control access to a single file? Will any of the security attributes help me here to lock down the single file?
Thanks in advance
Kevin
Put the file in its own directory and drop a web.config file in there that has the authorization configuration setup for that directory to require windows authentication
You can't mix authentication providers for a single app. So, eg., you can't have Forms Authentication for ~/ and Windows Authentication for ~/Secure. You may be able to get around it by making ~/Secure another app in IIS - but that greatly complicates deployment and testing IMO.
I've run into this problem while trying to secure ASMX services with basic authentication from a domain, but being in the same app as Forms Authenticated pages. I ended up hacking in a basic auth challenge in the ASMX service itself to prompt for credentials.
This should be possible using the <location> tag.
http://support.microsoft.com/kb/316871
I know in the past I have done the opposite and used it to enable access to a single resource and denied all others to unauthenticated users. Should work the same in reverse.
If you want the web.config to apply then you need to ensure that the directory in which it is placed is an IIS virtual directory. That ought to do the trick as the web.config's security restrictions will govern all files in that directory.