I’m developing an MVC5 application that’s been configured to use ADFS as Identity Provider with the web app acting as a Relying Party. The app is behaving differently on IE9 and Chrome as far as authentication is concerned.
When I run the app on IE9 for the first time and go to a page that requires the user to be authenticated, IE asks me to authenticate as expected. But when I launch a new IE9 window and navigate to the same page, IE asks me to authenticate again which is not expected as it should know I am already logged in. However this does not happen on Chrome, i.e. the second instance of Chrome knows I am already logged in.
Similarly, on IE9 when I log out of the application on one instance the other instance thinks I am still logged in, whereas when I run two instances of Chrome and I log out on one, the other knows I’m logged out.
How can I get IE9 to behave the same as Chrome? Is this some configuration issue on ADFS or do I need more server side code in the application to ensure IE9 behaves properly?
Many thanks in advance
Its not AD FS. Its the IE browser config that needs investigating. I suggest taking fiddler traces when you repro this using two IE windows.
I assume you are referring to AD FS 2.x or on 2012 R2. When AD FS authenticates the user, it writes MSISAuth cookies if the credentials are valid. WIF apps consume tokens from AD FS and write FedAuth cookies.
When the 2nd browser window accesses the app, if it doesn't receive a FedAuth cookie, it will kick off the flow to request auth by redirecting to AD FS. If AD FS doesn't receive the MSISAuth cookies, it will cause the client to auth again.
Sounds like the 2nd browser window is not using the same cookie store and is thus unaware of the FedAuth and MSISAuth cookies.
I suspect this is whats happening here.
I assume you are testing from a PC running IE and Chrome. You don't mention much about browser OS/config so I don't know whether these are terminal server published apps from a farm (with multiple browser instances across terminal servers in farm) or simple browser installs on a PC.
There are other reasons why another prompt for creds happen. You can configure AD FS to force fresh auth again by disabling SSO or configuring the RP related auth policy to insist fresh auth. But given the chrome behaviour I don't think that's it.
We need to review fiddler traces and browser config to answer more specifically.
If you need to get to the bottom of this urgently and quicker than forum responses are received, please raise a case with Microsoft.
Related
There are lots of variations of this question/problem and it seems like this something that a lot struggle with. At a high level, I am trying to hit a site that uses IWA for auth. In more detail, we are trying to hit the site from a test VM. The test VM does not have a user logged in, so when the browser is opened by selenium or another driver, there is no IWA authenticated user. The session just times out each time.
I have tried for almost 2 weeks now and can't find a solution. Things that we have tried.
Opening the browser as a specific Chrome prolile (this doesn't seem even remotely possible, but I still tried it unsuccessuflly)
Enabling impersonation in IIS/Web.config and granting the permissions to this domain user (site still opens as no user using selenium, or opens as my account if I RDP to the box)
Disabling auth in the application, but that goes against what flows/features that we'd like to test
enabling and using proces.start in the selenium project but errors would arise about permissions creating folders on the VM
Auto login with AD account when VM boots up but domain GPO blocks that
From being very new to this and only troubleshooting for a couple weeks, that the approach should be somehow in the test project be able to login as that test user and open the browser/url. I just have not found out how to do that.
What is the best approach when in this situation? Is it possible to have a selenium/C# solution run on a windows machine and initiate a login? If that is even possible, could you pass that to the chrome driver and then the browser?
We have an MVC application that validates windows users by instantiating a principalcontext, locally and for domain users. However, this immediately fails when a connection to the domain cannot be made. Is there a way to leverage the capability of windows to still validate domain credentials when disconnected from the domain?
We see that in SSMS you can also use windows authentication after the server has lost access to the domain.
To be clear, the machine is joined to the domain but does not have access to the domain controller, i.e. a corporate laptop that is taken home.
Thanks for the help in advance.
The answer is in how Kerberos (and I believe NTLM is similar) works in that they use session tickets. So once authentication is successful against a domain controller, you have a "ticket" that proves you authenticated. When you authenticate to anything else that requires Windows authentication, the ticket is sent.
To take advantage of this, you must use the built-in Windows authentication. You cannot take a username and password and try to authenticate them that way.
If everyone who uses your website can use Windows authentication - then you can enable it for your whole site.
If you have a mixed audience - some who have a domain account and some that don't - it's a little trickier, but still doable. I've done it. You can look at the OWIN-MixedAuth project. I haven't used that specifically.
That project seems to use a separate button for the Windows authentication. When I did it, I made it seamless (it tries Windows auth and fails back to a login page). I did that by doing an AJAX request in the background to a page that requires Windows authentication, and if it succeeds, just forward on. If it fails, show the login fields.
All that said, I don't know it will work if the server cannot reach the domain. It will probably work for users who have already authenticated to the site before it lost connection to the domain, or if the site is hosted on the same computer that it is being accessed from. But it might not work if a user it has never seen before tries to login while there is no access to the domain. You will have to test.
But the benefit of using Windows authentication anyway is that you can make the login seamless. As long as the site is in your Trusted Sites (in the Windows Internet Options) then IE and Chrome will automatically send the user's credentials.
We are running ADFS 3 on Windows Server 2012 R2, and using the C# ADAL library v3 to retrieve an authentication token from ADFS for our custom .NET application. The idea is to use ADFS to provide AD authentication of our users to our .NET Core Web APIs using the same web-standard method whether the client application is a .NET app or a ReactJS app.
The applications are internal LOB applications, and all users are internal corporate users who are logged onto AD through Windows when using the application. The authentication appears to be working in that ADFS is called and provided a JWT token for the calling user, and that token is successfully checked by the web API.
What concerns me is that, when authentication is triggered for the Web API, a browser Window flashes up but never pauses to force the user to authenticate - ADFS just responds with a token for the user. I expected the users to have to authenticate with their username and password, at least the first time and immediately after a password change.
Is this expected behaviour, and why? This answer is to a different question, but implies that in this situation Integrated Windows Authentication (IWA) will be used unless ADFS is configured to force Forms Based Authentication (FBA).
Can anyone confirm that this is what is happening?
Thanks,
Peter
If you are running the ADFS Server in your Domain Environment (which I suppose you do, since ADFS is sort of Windows-only-ish). Then your users are experiencing SingleSignOn through Kerberos.
So what essentially happens is the following:
Users Browser (UA = user agent) opens
UA loads ADFS, providing it's user-agent-header
AD FS sniffs that header for configured values (PS> Get-ADFSProperties for more info)
AD FS sees IE or any other WIA-enabled browser (you can make Chrome and FF work, too)
AD FS starts Kerberos Negotiation with the UA
AD FS issues user ticket
You can enforce users to authenticate, by setting an appropriate policy or disabling WIA on AD FS (enable FBA, or you won't authenticate with any method).
You can also call AD FS via a WAP proxy - this will also force FBA (assuming you do not have device authentication)
Nevertheless - why would you reauthenticate the user in ADFS? He already provided his password to the windows machine he is sitting at - if you force reauth you loose a nice and smooth single-sign-on experience. You do not gain anything by asking the user again. If you want it "more secure" roll out two factor authentication. AD FS 2016 has modules for that.
Update - just to clearify for others:
AD FS should automatically fall-back to FBA (if not configured otherwise), if the browser does not support WIA!
I am using windows authentication for my intranet application which was developed in ASP.NET MVC 4.0.
In Web.config file, i set authentication mode="Windows" and in IIS Enabled Windows Authentication and disabled Ananymous and impersonation is disabled.
Everythng working fine in local, but when i deployed it to windows server 2012 using IIS 8.5 it was prompting credentials popup for first time page load. even if i enter correct credentials its not worked. then i clicked cancel for 3 to 4 times page loaded without issues. If i close the browser and reloads the same url its not asked for credentials. after sometime used the same url this time its asked for credentials.
This issue is happening randomly and am able to reproduce the issue when i refresh the page continuously for 10-15 times.am using IE 11 and google chrome browsers.in both browsers same issue.
As per my requirement it should not display the popup for credentials as it is a intranet application.
Please help me on this, i was trying to fix from last two weeks but no solution yet.
We were just working on this exact issue. It appears that a Windows update caused this issue. We were seeing problems in Exchange Web Services, Autodiscover, LDAPS, basically anything that touched IIS.
The KB is: KB3179575. We also removed KB3177723 just in case.
Hope this helps
In my experience, that generally happens when authorization fails. The user is authenticated, because they are logged into their machine, but they are not in a required role or are otherwise not authorized to view the resource. The popup is a chance to switch to an account that does have access.
Currently I am using windows authentication but several of the non technical users seem to have trouble entering their credentials when the browser requests them. The web app needs to be able to identify the users to keep track of their input throughout the site. I was initially thinking cookie but I would need to be able to tell which users entered what and the possibility of them clearing their cookies could cause issues. windows Authentication would be great if I could just get around requiring the users to enter their credentials.
On a properly configured network, internet explorer users should not have to enter their credintials. Furthermore, I think all the other browsers have settings to do automatic NTLM authentication (Chrome and Firefox definitely do).
What do you mean "have troup entering their credientials"? How do they log in to their computer?