I have a pretty simple ASP.NET MVC Site Application. (MVC 1.0)
I have NO authorization sections in my web.config because I use the [Authoize] attribute on my controllers.
The default web.config for the server allows * for forms authentication, as expected.
I have 2 existing Windows 2008 dedicated (hosted) servers. The site works well.
I have a new dedicated server, seems identical except the site just won't work. Every resource, even images/javascript is redirecting to the login page.
I tried adding explicit authorization rules to allow * and location rules, same result. I checked the .NET Trust level, Internal/Full Trust. Everything runs perfectly on two servers, just this one is ignoring all rules for authorization.
Any ideas?
thanks
I found the issue :) Unless something has changed in Windows 2008 I would have expected this to show as an error but as stated above, it was being hidden by Forms Authentication.
The issue was the hosting company now adds data drives to all servers for your websites/storage. There were no permissions set to allow IIS to read the files. The reason I couldn't find it was I already added permission for the application pool user, in my case I just went ahead and added ASPNET, Network Service, IIS Anon User etc to have full permissions.
I needed to allow Everyone to have at least Read to the website folders and then IIS showed the non-secured content. I still think it is odd that forms auth. was kicking in and ignoring all web.config rules but anyway.
I found the error by turning off Forms Auth support in the IIS 7 manager. Then I got the process failure error because of file permissions.
Related
I am running an ASP.NET MVC 5 application on a Windows 2019 server with IIS 10. Now I want to set the IIS to pop up a window asking for a specific user with password before loading the web application in the browser. It is important that the prompt appears before the application accepts the client's requests. So actually before the application is started on the web server.
I can remember that something like this used to be possible with a .htaccess file. Is it possible to implement this in IIS 10 with the Web.config file somehow? In my Web.config I have already entered a http to https rule. So it would not be a security leak, because the connection is encrypted. Is it possible to configure IIS to ask for a specific password and username before starting the web application?
Thanks.
As can also be seen in the comments under the question, there is no IIS build-in solution for this requirement. The integration of third-party software for this requirement has not been considered.
I am in the process of building a Intranet MVC 4 application for our analysts. The goal is to allow internal users access to this application without having to sign on given they are part of our internal network. When they access the application I want to be able to capture their windows user name and check against the active directory using LDAP and retrieve the department they belong to and display the relevant details on the screen. Based on the advice from different fora, I have chosen Windows Authentication for this application and I was able to test the app successfully running from Visual Studio. The trouble I am having is when I deploy this to our UAT server running IIS 7.5.
<authentication mode="Windows">
</authentication>
<identity impersonate="false" />
This is the current state of my Web.config file. Irrespective of whether impersonate is true or false, the application seems to not capture the windows username of the browser from which the application is accessed. Is
impersonate = true
required for this at all? In the Welcome message on the homepage, I always see the windows user name of the computer where the application is hosted/IIS is running. I have tried a wide variety of ways to capture the Windows User name of the incoming user request.
string name = System.Web.HttpContext.Current.User.Identity.Name;
string name = System.Web.HttpContext.Current.Request.LogonUserIdentity.Name;
string name = System.Security.Principal.WindowsIdentity.GetCurrent().Name;
string name = System.Web.HttpContext.Current.Request.ServerVariables["LOGON_USER"].Name;
etc. I also looked into several other posts here like this. But I am unable to get it to work. I am afraid that I am trying to achieve this by accident rather than really understanding what is going on? Could someone please guide me in the right direction?
No, you misunderstand the purpose of impersonation.
First, Impersonation is no longer supported in IIS 7 or greater running in integrated mode.
Second, the purpose of impersonation is to change the "user" the worker process runs under at runtime, specifically to allow access to filesystem or database resources as that user. It has nothing to do with authentication in general, and is not particularly useful for most web applications.
You want to use Windows Authentication, however you should know that this will only work with Internet Explorer. It will also only work with servers that are joined to your domain, and do not have any intermediary Kerberos authentication issues. (these are often known as "double hop" problems). Other browsers do not, by default, provide Active Directory account information automatically, although some may be configured to allow it to do so, others do not.
If you are using a properly configured server with Windows Authentication, and you are using a browser that supports ActiveDirectory Kerberos ticket passthrough, and there are no network issues that would cause problems with this passthrough, then you can use HttpContext.Current.User.Identity.Name to get the users name.
Don't use LogonName or anything like that, as those will just give you the worker process, not the authenticated users name.
I was deploying my asp MVC 5 web site in Azure Web Site. Everything was fine until I tried to manage my account (changging the password), it gave an error like this:
The anti-forgery token could not be decrypted. If this application is hosted by a Web Farm or cluster, ensure that all machines are running the same version of ASP.NET Web Pages and that the configuration specifies explicit encryption and validation keys. AutoGenerate cannot be used in a cluster.
I was using Asp Identity, so all the code is built in. I have been searching the solution and found two possibilities:
1) It is because there are two #html.antiforgerytoken. One belongs to the MANAGE controller form, and the other belongs to the login partial view int he navigation bar. I tried to exclude the login partial view, but the error persisted, so I concluded that problem might not be it.
2) As the error says, maybe it is about MACHINE KEY. I tried to input setting to the web config. There are two popular ways to generate this machine key, fist is using ISS and the second is using third party. I wanted to use the ISS, but my ISS8 is not showing a modul to see the machine key which is weird that I could not find any solution for it. Then I tried the third party, and created something like this:
<machineKey validationKey="4359B782C08EF91E2AA6CA8AD46C0D63BF323E97ABAA06FBDA1535A1FA1CD2B7702B2BACDC937074ED65FC16D3ECA0F674BBAC8675910AF921D301CA22343AA1" decryptionKey="1A956B2A0405EC07AEBEFBA40DA7E61E2E17F001B868D7507EB3F3CD2AFF060E" validation="SHA1" decryption="AES" />
Then I redeployed my website but the error persisted. Can anyone please help me?
I have a few web applications running on production server.
Scenario:
Web App1(e.g. www.test.com): In this web application, User logs in and cookies are created in this application. User can do some other functionalities here, although on click of 1 button, it is required to redirect to another web application (WebApp2)
Web App2 (on different subdomain, e.g. abc.test.com): The session created earlier is to be passed here. Hence, I had used same machine key for Web.config in two webapps (Web App1 and Web App2) (As suggested on Link: Sharing sessions across applications using the ASP.NET Session State Service).
Issue:
Although, the session is getting shared fine and everything works great on staging.
But, on production, I am getting this error:
Unable to cast object of type 'System.Security.Principal.GenericIdentity' to type 'System.Web.Security.FormsIdentity'
It seems to me that the session sharing is not happening for some reason on production. Can you please guide me on the possible cause of this issue.
Either: Enable Forms authentication on production IIS
or: ensure your web.config on production (sessionState)
It looks like roots are configuration issues on production.
I have an odd situation occurring that I am trying to diagnose and would appreciate any advice on where to look.
I have an ASP.NET application using WIF that contains another ASP.NET application as a child in IIS 7.5. This child application contains a REST based web service. Accessing this service directly by pasting a URL into a browser will redirect to an ADFS sign in page. This is how I expect it to work. The odd part is that I have a second environment with the same applications and service deployed, and in this environment I am never redirected to the sign in page.
I have checked that all web.config files are identical, and also checked all IIS settings that I thought might be related. Browsing to web pages on the second environment requires a login, but not when browsing directly to the REST .svc file. I checked all HttpModules and Handler Mappings in IIS. I also enabled tracing of Microsoft.IdentityModel events and on the first environment can see a basic entries for a redirect to the STS. On the second environment I don't see any WIF events. The SessionAuthenticationModule appears to be called when I examine the data flow using IIS failed event tracing, but am not sure why it isn't requiring authentication.
I am familiar with cookie related issues with WIF and made sure that all cookieHandler settings were correct. I also closed browser windows and cleared all cookies to make sure the SessionAuthenticationModule wasn't seeing previous WIF cookies.
If you can think of anything else I should check please let me know.
If you have the same application in two separate environments bound to the same instance of ADFS, the URL's must be different so I am puzzled by the statement "all web.config files are identical"?
Have you tried re-running FedUtil on the application that doesn't work?
Also check AppPool settings.
After a lot of trial and error and carefully examining the applicationHost.config files between the two servers I found out this was caused by a difference in the ordering of HTTP handlers. The ExtensionlessUrl-Integrated-4.0 handler was picking up the request on one server and redirecting to ADFS. On the other server the svc-Integrated-4.0 handler was responding to the request first. You can read more about this behavior here: http://support.microsoft.com/kb/2520479