I have a MCV3 application in godaddy serves and the session is quite unstable.
When I login it works fine but while navigating in the application it logs me out, and hitting refresh or navigating a little more inside the application in logs me in just like that (without asking credentials or anything). On my remote test servers and local in works fine.
This is probably not a session issue but rather an authentication cookie/ticket issue. GoDaddy (most likely) has their servers load balanced. Meaning that your application actually exists on more than one server at a time.
In your web.config, if you are not properly defining the <machineKey> attribute, then IIS makes up a machine key for you. Each server running the application will make their own machine key if it is not defined by you. As a result, one server is able to decrypt and read your authentication ticket, while the next request goes to another server which cannot decrypt the authentication ticket because it was encrypted with a different key and this server thinks that you are not logged in.
To address this issue, open your web.config file and define your <machineKey> attribute and redeploy. Once you login with the newly deployed application, you should see this issue disappear.
Forms authentication and Machine Key information on MSDN
Machine Key Generator (Most likely, everyone going here should use the .NET 2.0 version that is generated)
Related
When I'm deploying an ASP.NET Core web application to Azure, I have an issue with the session : they are shared across browsers.
Explanation : I'm going to my deployed site, I log in with my email/password then I'm logged in. If I open the website in an other browser on the same machine or on an other machine, I'm now connected with the credentials I used in the first browser.
I deployed the default template from Visual Studio without any changes.
Is there something to do to resolve this issue or am I missing something ?
Pretty sure this functionality is by design... and it makes a lot of sense - you wouldn't want to have to re-authenticate if you opened another tab to view a document in your on-line banking would you?
If you need to logon without sharing the cookies with existing browser (it will be the cookies that are holding the reference to the session that ensures the server knows who you are) you need to start a new session. For Internet Explorer this is simply File >> New Session.
For Chrome it is a little more complicated but explained here... Separate session for each window
I've been beating my head for hours on this request.
I have an on-premise installation of an Azure MultiFactor Authentication Server. I'm building a new ASP.Net MVC 5 application that will do an LDAP lookup for users in Active Directory (also on-premise) with no ADFS configured.
I've gone through the sdk for MFA Server and can easily enable SMS requests to be sent. I get the otp code from calling pf_auth.pf_authenticate(authParams, out otp, out callStatus, out errorId);
This works for test. But I need to direct this request to my on-site MFA Server. I can't find anything that tells me where I can set this value.
I know that if I login to a machine on that domain it automatically sends the SMS text to my phone and I can enter it into the next screen to complete a login (the default user portals set up with MFA). I would assume that this would possibly work when I call ValidateCredentials on my application's newly created PrincipalContext. But how do I submit the sms code without some sort of RequestId to synch up the communication.
I'm sorry if this doesn't make much sense. It's just all the examples I can find are for using MFA with a local ADFS. I only have Active Directory which is causing me to do the custom LDAP lookup.
Any help or direction is greatly appreciated.
OK, sorry for the delay in responding to this post. After getting no responses I moved on but have recently noticed that there have been 45+ views since my post and thought I should update for others who might be experiencing a similar issue.
Turns out that when using MFA on premise you can point multiple applications to a single MFA server, like Remote Access, VPN, etc.
However if you are attempting to setup a Web Application hosted on IIS you need to install a copy of the MFA server on the IIS server hosting the application.
When installing you can point to the existing MFA setup so that both machines are in the same configuration. This local install also adds a custom IIS Plugin that does the request interception and directs it through the MFA pipeline. If everything looks good the request is then forwarded to your web application like normal.
This is really pretty straight forward but the documentation for MFA setup was sorely lacking. Hopefully in the future there will be a decent sample app provided by Microsoft that demos this process using local MFA and not just the Azure hosted solution.
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've been busy with this for months now.
I currently have 2 servers for 1 website. Using round robin dns I find that in the beginning everything works (checking the ip of the website it changed but I can go on with my session), but after a while I lose my session, seems like the formsauthentication cookie cannot be read and is being discarded. (assumption) But this does not happen all the time. Only sometimes.
I'm using iis7 shared configuration, I set the machine key and I'm using stateserver pointing to one of the servers and I verified that on both servers the stateserver works.
I read something about the IIS application path, but I don't really know what is meant by that, is it the path of the webapp, or the path where IIS is installed? In both cases they are the same.
Anyone have some ideas?
I'll answer this one myself, for anyone facing the same problem. Everything was set up correct but the machine key should be located in the web.config under system.web. Generating the key via iis 7 didn't work for some reason, I generated it with an online tool: http://aspnetresources.com/tools/machineKey
So, to do load balancing and set up multiple servers on iis7 you should:
Use a stateserver out-proc (stateserver or sql server) and have all
servers point to that stateserver (example: stateConnectionString="tcpip=server1:42424")
Use iis shared configuration so all your servers point to a share where the applicationhost.config resides.
Generate a machine key (not via iis, just use an online tool!)
Set up NLB (or round robin DNS) and test it by flushing your dns on
your client when you're logged in and see if your session doesn't get lost.
Hope this helps someone.
And the machine keys are specific to the .NET version. To check your current version: In the IIS console, at the server level, click "Change .NET Framework Version" in the Actions pane.
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