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.)
Related
The problem: I'm getting errors from Google while attempting SSO through Azure AD and can't even begin to guess why or how to go about debugging the issue.
The story:
My org is looking at leveraging Microsoft's nonprofit benefits by setting up Azure for web hosting and Sharepoint to start with, which also entails using Active Directory. As it stands right now, we've successfully gotten our website running and accessible to the world on our custom domain, and our AD is populated with a copy of what's in our Google Workspace directory so we can use Active Directory as our authoritative directory.
We've been trying to implement SSO with the Azure/Gsuite connector, to have them auth with their Azure credentials to get into GMail, Docs, Drive, etc, but Google Workspace seems to choke. I have gone over the setup instructions repeatedly, ensured we're using all of the proper URLs in the Connector's SAML settings and in Workspace's "SSO with third party IDPs" settings, the proper certificate is in place... Provisioning is set up but not active, and I have successfully provision-on-demanded my account and an unprivileged test account.
Here are my settings in Azure:
Here are my settings in Google:
And to test this here's what I've done:
I open up a fresh InPrivate/Incognito window.
I go to https://myapplications.microsoft.com/ and am prompted to login. I use my unprivileged test account credentials.
Upon auth I click on the Connector app to attempt to go to my Gmail inbox.
After a wait on a white screen, I get a Google error screen with "Invalid Email - We are unable to process your request at this time, please try again later."
If I disable the SSO settings for my org in Google Admin, I'm able to log into the account just fine with Google, get to the gmail inbox, etc.
Conversely, if I attempt the same steps with my admin account, I get a similar page with a slightly different message, "Server Error - We are unable to process your request at this time, please try again later."
I have been bashing my head against this for two whole nights and can't make any headway. What gives? I can't even figure out how to debug these errors.
Somebody (me) failed their perception check repeatedly because the problem was that the Unique User Identifier SAML claim in Azure was set to user.mail instead of user.userprincipalname as it should have been as per the tutorial.
I'll see myself out now.
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
I am developing an ASP.NET MVC website. It is hosted in Azure and users are authenticated with AAD for our single tenant. I intend to make the website available in a Teams app, so that my coworkers can navigate to my website via the Teams Windows app and the mobile app.
I follow these steps to integrate security in a web browser: https://learn.microsoft.com/en-us/learn/modules/msgraph-build-aspnetmvc-apps/5-exercise-add-auth
I followed these directions to integrate security with Teams: https://learn.microsoft.com/en-us/microsoftteams/platform/tabs/how-to/authentication/auth-aad-sso. I'm not sure that I did this correctly.
At this point, I can:
Login with a web browser
Login via Teams mobile app
Load Teams in a web browser then load my app (not a use case that I need to support, but this worked and I was not prompted to login. I assume that I wasn't prompted to login because I was already logged in directly in another browser tab).
I cannot:
Login via Teams Windows app -- This is my primary use case unfortunately.
When I try to login with the Teams application on Windows (using the same pages and forms as on mobile), the page just disappears. I'm not prompted with the usual Microsoft login page.
How can I diagnose the cause of the problem? I don't see any obvious errors reported in Teams. Is there any way to get access to the root error?
EDIT:
login.microsoftonline.com is reporting "Your browser is currently set to block cookies. You need to allow cookies to use this service." I'm now aware of the SameSite changes (https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-handle-samesite-cookie-changes-chrome-browser?tabs=dotnet) and I've implemented the recommended SameSiteCookieManager code to address the SameSite issue.
I'm still running into the same issue. No exceptions or errors reported except that Teams does not accept cookies.
May have to break this down further, here's how I would decipher it.
First of all, you will have to figure out if the issue is with Teams or on the Auth side.
Figure out which line of code is executing last? You can debug or write to terminal/logs.
Do you see any exceptions? Ideally debuggers can help or you can add some code to catch any exception.
If it's failing before executing any code, do you see any http requests going out, you can use fiddler for this. See if you are seeing any error codes.
If you are using Windows then check Event Logs for any errors or exceptions for Teams App. Look at the Application logs.
Look out for Audit logs and sign in logs and check if you see any activity in your tenant when you run this app.
https://learn.microsoft.com/en-us/azure/active-directory/reports-monitoring/concept-activity-logs-azure-monitor
Some other points would be to check if you can repro this with a sample app or a different user(elevated user). If there is any additional info do share.
I have an intranet Blazor Server application created using the Visual Studio template with the Work or School Accounts authentication option. Everything was working beautifully when running on my local machine and when the app was published to our development environment. However, once I moved the app to our staging environment, the application would sometimes crash after authenticating the user in Azure.
After troubleshooting the issue, I believe the problem to be that our on-premises staging environment is load balanced (mimicking production). Our dev environment is not load balanced. I think what was occurring was that once authenticated in Azure and redirected back to the application, the user doesn't always land on the same server due to the load balancer. This breaks the Signal-R circuit and caused the application to crash. This also explains why the error was random; happening maybe 2 out of every 10 logon attempts. To test this, I removed Azure AD authentication from the application and allowed anonymous access to every page. The crashes stopped.
My question is if anyone knows of any workaround to get Blazor Server with Azure AD authentication working with an on-premises load balancer. I searched all over the web and the only workaround I found was to use sticky sessions with Azure Signal R service. We are not hosting apps on the cloud yet. Is switching to Blazor Webassembly the only option if I want to use Blazor with authentication in my environment? Someone at work suggested switching the application to use our on premises ADFS server. However, wouldn't that encounter the same issue?
For reference, here is the code in startup.cs ConfigureServices method that sets up the Azure authentication in the application:
services.AddAuthentication(AzureADDefaults.AuthenticationScheme)
.AddAzureAD(options => Configuration.Bind("AzureAd", options));
services.AddControllersWithViews(options =>
{
var policy = new AuthorizationPolicyBuilder().RequireAuthenticatedUser().Build();
options.Filters.Add(new AuthorizeFilter(policy));
});
I found the solution to this and am posting it here in case anyone else is facing a similar issue.
It turns out the problem wasn't SignalR or anything specific to Blazor Server. After enabling the developer exception page on the load balanced environment, I saw that the error was "Unable to unprotect the message.State". The application state is encrypted by middleware before the user is authenticated by Azure AD. When Azure AD posts back, it includes that encrypted state which is then in turn decrypted on the client side by the middleware.
The key needed to decrypt is by stored on the web server. When in a load balanced environment, if you land on a different server than where you started, the middleware will then be attempting to decrypt state with the wrong key. This of course results in an error.
To fix this you have to store the keys on a central location like a file share instead of on the server itself. Implementing the fix is actually simple. Include the following line in ConfigureServices in startup.cs:
services.AddDataProtection()
.PersistKeysToFileSystem(new DirectoryInfo(#"\\server\share\directory\"));
There are also options to store keys on Azure if that is preferred.
This post by Kevin Dockx is what finally gave me the answer:
Solving Correlation Failed: State Property Not Found Errors (OpenID Connect Middleware / ASP.NET Core)
I have been updating a system that has been in place for sometime and finding some clients have issues with login on mobile devices.
I have a test system in place and setup Application in Azure AD and noticed during testing if I login with incorrect credentials, login.microsoftonline.com will show:
Sorry, but we’re having trouble signing you in.
AADSTS50020: User account...
When login to the clients live systems I don't see this error and just get returned to the home page of the application.
The only difference is the client apps are configured with credentials for there Azure AD instance and I cannot access them. These where also built on the legacy App Registrations but that shouldn't be issue (ha). The server side is the same implementation.
Why am I not seeing the AADSTS errors in productions sites?
If you are not seeing any error and are just getting returned to the homepage it seems more likely to be an issue with the Redirect URI or the app registration configuration.
Please confirm that the redirect URIs in your application and in your registration are what they are intended be.
Also, ask them to check the developer tool logs when signing in to see if anything shows up. It might be failing but not triggering the error message.