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.
Related
We have a Teams App which is created using Teams Toolkit - SSO Enabled Tab option.
This App is single tenant by default and we want to convert it to Multi Tenant.
We are following the steps mentioned in "https://github.com/OfficeDev/TeamsFx/wiki/Multi-tenancy-Support-for-Azure-AD-app" to do the same.
Here when I update the aad.template.json file and change the value of signInAudience to AzureADMultipleOrgs, and then run provisioning using teams toolkit. I get an error - "Failed to update application in Azure Active Directory. Please make sure 'templates/appPackage/aad.template.json' is valid: Request failed with status code 400 Detailed error: Request failed with status code 400. Reason: Values of identifierUris property must use a verified domain of the organization "
On changing the value back to AzureADMyOrg, provisioning is successful.
Anyone faced similar issue
It sounds like it's failing because you don't have a verified domain registered with Azure. It's only required for multi-tenant apps, but that's exactly what you're building. Essentially, you need to have a regular external domain registered with Azure, something like a .com, .io, .net, .whatever public domain.
On the page you linked, it actually says as much:
Since Azure AD app requires an "tenant verified domain" for Application ID URI, you can use your own Custom Domain or Create a new Custom Domain on Azure.
But this looks useful too: https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-modify-supported-accounts#why-changing-to-multi-tenant-can-fail
This error is because you are not using a verified domain in Application Id Uri of your multi-tenant Azure AD app. Teams Toolkit will by default use Storage to host your Tab app, however Storage endpoint is not a tenant verified domain, and thus you will fail with this error if only update your AAD manifest.
You can follow step 2-4 in Update your Tab applications to create your CDN or use your own tenant verified domain and setup the endpoint in your project.
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.
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 code working in development that authorizes against Azure AD in a multi-tenant setup using the MSAL library (with the Microsoft Angular wrapper for MSAL).
This code all works as expected when I am running it against localhost:5001.
My configuration contains a redirectUri for https://localhost:5001 and my application in Azure AD has its "Redirect URI" value set to the same.
However, when I move this to production, it is continuing to try to redirect me to localhost:5001 on a successful AD authentication, even though I have changed my redirectUri in my configuration, as well as the Azure B2C application "Redirect URI", to now be the production site at:
https://[mysite].azurewebsites.net
Where is it still getting localhost:5001 from? I searched my code/configuration and this value does not exist. It is not currently in Azure AD for the Application. I have stopped and restarted my App Service to no avail.
The redirection it is trying to make is to:
https://localhost:5001/#id_token=eyJ0eXAiOiJKV1Qi ...
I was able to work around this issue by deleting the Azure AD App Registration and creating a new one from scratch with the proper endpoints.
For some reason, it was not "holding" the change when the endpoint URLs were edited and saved. It showed the correct endpoints in the Azure AD control panel for the App Registration, but it was still redirecting to localhost.
When I deleted and re-created, it properly forwarded the replies to the production site.
I am unsure at this time if this is an issue on Microsoft's side or not, but this conclusively resolved the issue.
Registering a new application solved this issue.
No need to delete and register a new application. Simply update the replyUrlsWithType attribute on the Azure Active Directory app manifest file to point to the new domain, url or location:
"replyUrlsWithType": [
{
"url": "https://localhost:4400/services/office365/redirectTarget.html",
"type": "InstalledClient"
}
],
See this link for more information: https://learn.microsoft.com/en-gb/azure/active-directory/develop/reference-app-manifest?WT.mc_id=Portal-Microsoft_AAD_RegisteredApps
Using adal.js v1.0.17 and Web API via JavaScript.
Running a custom tab within Microsoft Teams and getting this error when trying to authenticate.
Looked at the app registration within Azure portal and not seen anything there that could help. Tried to edit the manifest file and change the value of oauth2AllowImplicitFlow to true but still getting error.
Found the solution.
Need to access the Azure portal using Chrome.
Go to Azure Active Directory and choose App Registrations (Preview).
Open up the app registration and choose Authentication on the left.
Under Advanced Settings, Implicit grant check the box "ID tokens".
That will add the property oauth2AllowIdTokenImplicitFlow to the manifest file with the value set to "true".
you can try by enabling the 'ID Token'