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.
Related
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 recently Registered a Keycloak Application on my Azure AD B2C tenant, one of my colleagues accidentally deleted the registration, so i have restored the application on the Azure portal, Later i tried changing the Redirection URI, but the Azure portal doesn't allow me to do so and shows the below error
"Failed to update KeyCloak application. Error detail: Encountered an internal server error."
I have tried to change the same in the Manifest and tried to upload file, even it shows the same error.
Did my application restore made any difference here, if it was so please suggest me some check points to solve this.
Note : The other applications in this tenant allow me to do same changes, I have issue only with this application registration.
A bug has been filed and the product team is working on it. In the mean time for the work around Please re-create another app if possible.
You could also try to change "SignInAudience" to "AzureADMultipleOrgs" (if it works) - than you'll be able to modify reply urls and switch "SignInAudience" back.
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.
I installed a Kentico 9.0 website and everything worked fine. Then I tried to configure Windows Active Directory authentication using this documentation: https://docs.kentico.com/display/K8/Configuring+Windows+AD+authentication. However, when I open the URL, the login popped up, I used my working login credentials and the login pops up back constantly.
I changed back the web.config and saw the event log, and there was nothing logged about my numourous login attemps.
The documentation was straight forward, so I am guessing there is a permission issue in my environment. There is one little warning in the documentation but it doesn't say how to do it:
Prerequisite
For Windows authentication to work, the application must be able to access the following attributes of user objects in Active Directory (i.e. the attributes cannot be protected or confidential):
memberof
userAccountControl
My application is in a virtual server in a domain. And the Active Directory service is in different server in the domain. Does it mean I need to do something for my application's permission to AD? I am using NetworkServices application pool identity.
Thanks.
You (your laptop) have to be in company intranet and logged in to your laptop with your AD credentials. If you meet those conditions IE or Chrome should not even prompt you for credentials as they are already known, so browser just passes your AD account information to Kentico.
Once you see the prompt continuously there is something wrong with your setup. Make sure
you configured everything according to documentation (Kentico + IIS)
server/host is in domain
you're in intranet and logged in with AD creds
Usually how Active Directory authentication works is you need to pass it a AD Username and password that has access to read the users. I would check that user's permissions.
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.)