Azure AD enterprise applications save issue

Question

Azure AD enterprise applications save issue

This is an obvious bug. I will try to explain.

I work for 2 companies that have each a set of Enterprise applications we created. A live environment, 2 test environments and a staging environment .

All 4 environments now have around 74 subdomains that we have configured for SSO using basic SAML configuration. All domains use https://<customer>.<domain>.<ext> as identifier and https://<customer>.<domain>.<ext>/saml-login/ as return URL.

When saving a new URL it is always a gamble if they are saved. The Save button goes grey but there will not be a confirmation the URLs have been saved, trying anything on the page will result in a message that there are unsaved items but the Save button is greyed and cannot be used anymore. It has been times it took me 5-10 retries before a save would really save the URLs. As this needs to be done for 2x 4 environments this is a PITA.

But that is not all, on a regular basis (and I expect this to happen when saving a new URL) other URLs (especially return URLs) are dropped. So I have to add them again but this triggers the dropping of URLs again once in a while.

Anybody else seen this behaviour? All help is appreciated

Answer 1

Alfredo Revilla (MSFT) 17,016 Microsoft Employee

This could be some temporary issue with the portal. In the meantime please try using AzureAD powershell:

   Connect-AzureAD -TenantId <tenant id>  
   $app=Get-AzureADApplication -ObjectId <saml application object id>  
   $app.IdentifierUris.Add(<new uri>)  
   $app.ReplyUrls.Add(<new reply url>)  
   $app|Set-AzureADApplication -ReplyUrls $app.ReplyUrls -IdentifierUris $app.IdentifierUris

If the first issue persist or powershell result is the same please Create a support request or let us know if you need assistance for the later.

Frank Verheggen - SyncForce 21 Reputation points

2020-12-17T18:29:49.427+00:00

Thank you,

I will try this tomorrow.

This issue is in the portal since the beginning of June, al least that is the first time we experienced this.

Also nice to know there is a powershell script. We looked for that before and we found nothing.

If I understand your answer correctly. The issue of vanishing URLs is not fixed with this?
Frank Verheggen - SyncForce 21 Reputation points

2020-12-22T13:50:15.6+00:00

anonymous user-msft

Just a small side question. Is it possible to create a wildcard url and return url?

As mentioned before we now have 74 sets of <customer>.<domain> and <customer><.domain>/saml-signin/. would it be possible to use * instead of <customer> in the URLs?
Alfredo Revilla (MSFT) 17,016 Reputation points Microsoft Employee

2020-12-22T20:17:54.373+00:00

Hello, it's not possible. Wildcards are not supported.
Frank Verheggen - SyncForce 21 Reputation points

2020-12-22T20:24:58.183+00:00

Would this be something that could be supported in the future?

I guess we are not the only company running multiple subdomains with SSO.
Alfredo Revilla (MSFT) 17,016 Reputation points Microsoft Employee

2020-12-22T22:45:08.277+00:00

Currently there are not plans for such feature but you can voice out your interest here.

Answer 2

Frank Verheggen - SyncForce 21

This workaround is working however the mentioned bugs still remain.

I created a script now to create the 4 environments with one script and used a dummy url to test. That worked as expected.

Trying to clean up I ran into the bugs again. When removing the dummy URLs in the web interface once again another reply URL was gone also. Also the multiple times needing to try to save the list of urls remains a problem in the interface.

Alfredo Revilla (MSFT) 17,016 Reputation points Microsoft Employee

2020-12-22T20:19:21.053+00:00

Thanks for the comment, I will forward this to the product team.
Continghiu, Ionut (Admin) 1 Reputation point

2021-07-30T09:03:18.727+00:00

Was there any progress done by the Product Team on this?
I've found the matter to pop up frequently but not consistently, I did have the unfortunate experience of having one connector being committed to Production and later finding out that the Reply URL was not being accepted since it was not "saved" even though it was defined in the UI at least.
Had to strip it out and refined it in order to get it to work.

Answer 3

Jari Leppänen 1

I'm encountering the same bug. I can't use the workaround either because it's a new Enterprise application that doesn't yet have SAML on, so that I could change the urls. I can't input the urls in the first place.

Answer 4

Checking in, issue is still present. We struggled with this migrating from another IDP to Azure AD in 2019 and the problem is still present nearly three years late. It can take dozens of attempts in the portal to save the saml URIs initially and they' often simply cannot be edited once saved. Every once in a while it behaves but most of the time you get to fight with it. And interacting with those URIs in the portal reverts changes made with the shell.

Azure AD enterprise applications save issue

3 additional answers

Activity