We have moved from NAM Identity Provider to AzureAD. The MS Edge_C uses Enterprise Mode Site List to force IE mode for the application.
On a new session, the user is redirected (GET) from our application to login.microsoftonline.com via SAML. After selecting the account, another redirect is sent to the company authentication service, which successfully authenticates the user. The SAML response is sent to the application via POST.
That's how it should be, and that's how it was with NAM (which authenticated the user directly). But since the switch to AzureAD, the final POST back to the application is broken. Our application receives a GET request without SAML related parameters and therefore the SSO fails.
Without IE mode it works, but since it is a legacy application we have to use IE mode.
The same process directly in IE11 works as expected.
Does anyone know what could be wrong with AzureAD's response? It seems like something is irritating the Edge_C about the response, which is why the change "Non IE Mode" (login.mso.com) to "IE Mode" (application) discards the POST and a GET is made.
I would appreciate any ideas to help us with this problem.
After a long debugging session, the solution turned out to be really simple:
The SSO related URLs must be added to the Enterprise Mode Site List as Neutral
see https://learn.microsoft.com/en-US/deployedge/edge-ie-mode-sitelist#configure-neutral-sites
This ensures, that the SSO service is used in the same browser instance as the application that triggered the SSO. No switch between Edge and IE happens.
App uses IE Mode -> SSO service uses the IE Mode
App uses Edge Mode -> SSO service uses the Edge Mode
Related
I have a Blazor WASM app with Azure AD Authentication. I use Visual Studio as IDE and use Browserlink to test before deploying to Azure App Service.
This morning (was fine yesterday) when I try to use the Browserlink "View in Browser", the website comes up properly in localhost, but when I click the Login button, the microsoft authentication window (pop up) flashes up and then disappears and I can't see it or get to it in any way.
I deployed the exact same current application to Azure App Service and the authentication window comes up as expected with no issues. I do have the localhost address in the Azure portal under the App registrations authentication section and am using https for all calls.
Not sure what else to check. Appreciate any help, thank you.
Please check if it was the issue with Internet explorer as there are known issues with pop-up windows on Internet Explorer.
During sign in, to acquire tokens using MSAL.js, the library first attempt a silent token request using the acquireTokenSilent method and checks the cache in browser storage to see if a valid token exists and returns it.See if it is not clearing the cache and has azure AD Session is found already which may not redirect or pop up for login.
If no valid token is in the cache, it sends a silent token request to Azure Active Directory (Azure AD) from a hidden iframe . However, if no valid Azure AD Session exists, silent token request fails and user can be either provided with a login popup or redirect.
In your case, at the first launch of the application, when no valid token in the cache or valid Azure AD Session is found, silent token request fails and you are presented with the login popup but subsequent logins work without login popup.
Pop up and redirect
I still have no idea what was going on. I had tried the hard refresh and empty cache option as well as a reboot.
It seems to have fixed itself as today was fine. Thank you for your responses.
We are having problem with ADAL redirect authentication in MS Team Desktop client recently.
We have a custom Teams app package (Team Tab) to display a page on our application server. The page uses ADAL JS library to get Graph token to access One Drive. Since the page is displayed in iframe and will be used in Teams desktop client, we use page redirect authentication in ADAL. From debug console, we can see the issue happened when ADAL sent request to “login.microsoftonline.com”(login_hint parameter is used to specify current user account). The flow stopped with error saying the “login.microsoftonline.com” can’t be displayed in iframe. In the past, “login.microsoftonline.com” simply redirected the browser to the specified redirect URL and auth flow completed without any problem.
Our application server has implemented SSO with Azure. Implicit auth flow is used to get the token. The issue only happens in Teams desktop client, we use ADAL popup (not supported in desktop client) to get token in browser. The flow was working before April. Seems to me that something has changed recently at the Microsoft login page.
Just wondering if anybody has the same issue. Any suggestions will be appreciated.
Have you looked at using Teams SSO, which uses MSAL, instead of ADAL? See here for a sample: https://github.com/pnp/teams-dev-samples/tree/master/samples/tab-sso
I am adding OIDC login to a WinForms application. I set up the application using the IdentityModel.OidcClient library and pulled the boilerplace code from their WinForm Sample. The OIDC successfully shows the login form, does MFA, and I get back the tokens.
However, if I close the application and open it again, I have to authenticate again. Usually, the SSO session in the browser allows me to bypass this step. It seems the OidcClient is using a browser session that gets destroyed when the application closes and is not shared between applications.
How can I configure my application to use the SystemBrowser or another browser that will maintain those SSO cookies between executions and/or for different applications that use this component.
Thanks in advance.
First thing to check is that the session cookie that you set have an expire date in the future, otherwise it will just be a cookie that will last this browser session.
In your browser you can see that in the developer tools section, like in this example:
Alternatively, you can use a tool like Fiddler to check the response that sets the session cookie and make sure it contains a future expire date.
You can configure that in your ASP.NET application.
I'm currently try to develop an Office web addin, integrated in the Outlook (Read and Compose).
Everything works fine, except the authentication process.
Indeed, We have to authenticate the user from within Azure AD to access another application (our own application using the Azure AD Architecture where we need to call some web apis)
The solution I used is issued from this great article from Richard diZerega :
Connecting to SharePoint from Azure web app
This solution (we opt for the last scenario) works fine in our Desktop and Web based solution.
But it clearely doesn't work in phone web app , IOS app.
The problem comes from the popup Windows allowing the user to log in.
Actually, window.open, window.location.replace etc ... don't work "as expected" in our Outlook frame.
Everytime it open a popup window. (This is a good solution when the user use the desktop or web Outlook application)
I remember read somewhere that the Office Window where the plugin is loaded, is a secured Window where we can't do any sort of redirection.
I tried to work with ADAL.js, enabling the implicit flow of course, but the problem is the same. We need to redirect the frame to the Azure AD login page.
Finally, the question is : How to deal with an OAuth2/OpenID authentication in an Outlook web addin, and when we want it to work with all kind of devices ?
Login in Adal.Js is a page redirect by default. You don't have pop up issue. Adal.Js gets idtoken initially to be used for your own back end. It also does iframe requests to get access tokens for API endpoints. Office365 APIs support CORS api requests and you can use adal.js to send requests. Tokens will be attached to the requests if you define the endpoints in the config.
You can read about examples here: https://blogs.office.com/2015/03/06/increasing-opportunities-javascript-developers-office-365-platform/
or here : http://www.andrewconnell.com/blog/adal-js-cors-with-o365-apis-files-sharepoint
I setup a test Server 2008 box with Active Directory and ADFS 2.0. I have an ASP.NET app which uses WIF to federate identity. ADFS is configured to use Active Directory for identity info. I used WIF to configure the client app to use the ADFS endpoint.
When I attempt to load the ASP.NET app as a user from the browser I am redirected to the ADFS endpoint and am prompted for credentials. I have attempted to login with several users accounts, even resetting passwords but the credentials never seem to be correct and a 401 Unauthorized is returned. I can login to other systems successfully with the same credentials.
I have enabled debug trace in verbose mode and enabled auditing in verbose mode but I can't find any errors or info to help me figure out the issue.
How can I get more info to narrow down the problem?
UPDATE:
I found that this issue is caused by my testing environment. My dev machine is on our corporate domain (acme.com). I created two 2008R2 VMs for a test Domain Controller (notacme.com) and Web Server.
If I attempt to access the website from a computer on the acme.com domain the error described above occurs. If I attempt to access the website from a computer on the notacme.com domain it works.
What can I do to access the website from a computer on the acme.com domain?
Apparently this was caused by the Extended Protection feature built into ADFS. In trying to troubleshoot this issue I had Fiddler running to track the requests/responses but at one point I swear I turned it off to test as well but it still didn't work. Apparently I didn't fully remove the Fiddler proxy because after a IE reboot and with Fiddler not running it worked in IE but found it still didn't work in Firefox or Chrome. This led me to a TechNet article which described the behavior I've been seeing in conjuction with using Fiddler.
http://social.technet.microsoft.com/wiki/contents/articles/ad-fs-2-0-continuously-prompted-for-credentials-while-using-fiddler-web-debugger.aspx
In my experience, every sign-in failure in IIS (including AD FS) is logged in the 'Security' event log as an 'Audit Failure' event, which contains more details. So I would search in the event viewer on the AD FS system, and see what those events have to say. Also in the event viewer, check the 'Applications and Services Logs' -> 'AD FS 2.0' -> Admin event log.
It looks like you did try to look at the HTTP traffic, e.g., using Fiddler. That's good. I presume the problem also occurs when Fiddler is not used?
(Do you perhaps have the problem of a repeated sign-in form, after you entered correct user name and password? Then look at the following answer: ADFS authentication - IE8 works, Chrome fails.)
(I have also seen a case where the initial authentication was successful, resulting in 'Audit Success' events, and then a 401 resulted from a later redirect. Also in this case the event logs on the AD FS system helped.)