none
Error creating API App when having multiple Azure AD Directories RRS feed

  • Question

  • We are unable to create API Apps on subscriptions with multiple Azure AD Directories. In the web portal the creation silently fails with the "create" button left in a disabled mode. 

    When trying to publish to a new API App from Visual Studio we get the following error, indicating that the wrong Azure STS is chosen when authenticating. All other Azure components are created just fine, including Websites / Web Apps

    Azure API App provisioning failed:

    Details:

    Registering the Azure resource provider
    Creating the Azure resource group MartinDev
    Creating the API App ApiApp-martin
    Exception: Request to https://management.azure.com/subscriptions/c21f781d-4c01-4f73-8d07-3baaa3490b5e/providers/Microsoft.AppService/deploymenttemplates/Microsoft.ApiApp/listmetadata?api-version=2015-03-01-preview POST failed BadRequest 400 (Bad Request)

    Application error (System.UnauthorizedAccessException): Request to https://management.azure.com/subscriptions/c21f781d-4c01-4f73-8d07-3baaa3490b5e/resourcegroups/MartinDev/providers/Microsoft.AppService/apiapps?api-version=2015-03-01-preview GET failed Unauthorized 401 (Unauthorized):{"error":{"code":"AuthenticationFailed","message":"The access token is from the wrong issuer 'https://sts.windows.net/e1c4769f-981d-460e-8d73-18100d3fc93a/'. It must match the tenant 'https://sts.windows.net/91adce2d-f474-4574-a86d-7ef7f3106c49/' associated with this subscription. Please use the authority (URL) 'https://login.windows.net/91adce2d-f474-4574-a86d-7ef7f3106c49/' to get the token."}}.    at Microsoft.Azure.AppService.ApiApps.Service.HttpResponseMessageExtensions.VerifySuccess(HttpResponseMessage response) in c:\Users\sebros\Documents\My Projects\Thorp\EMA.Common\Shared\HttpResponseMessageExtensions.cs:line 85
       at EMA.Provisioning.ARMProvider.<GetResourceGroupResourcesAsync>d__2d`1.MoveNext() in c:\Users\sebros\Documents\My Projects\Thorp\EMA.Provisioning\ARMProvider.cs:line 108
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
       at EMA.Provisioning.Commands.GenerateMetadataCommand.<ExecuteAsync>d__8.MoveNext() in c:\Users\sebros\Documents\My Projects\Thorp\EMA.Provisioning\Commands\GenerateMetadataCommand.cs:line 35
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at EMA.ResourceProvider.Controllers.DeploymentTemplateController.<GetMicroserviceDeploymentTemplateMetadata>d__1.MoveNext() in c:\Users\sebros\Documents\My Projects\Thorp\ResourceProvider\EMA.ResourceProvider\Controllers\DeploymentTemplateController.cs:line 68
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at System.Threading.Tasks.TaskHelpersExtensions.<CastToObject>d__3`1.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
       at System.Web.Http.Controllers.ApiControllerActionInvoker.<InvokeActionAsyncCore>d__0.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
       at System.Web.Http.Filters.ActionFilterAttribute.<CallOnActionExecutedAsync>d__5.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Web.Http.Filters.ActionFilterAttribute.<CallOnActionExecutedAsync>d__5.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at System.Web.Http.Filters.ActionFilterAttribute.<ExecuteActionFilterAsyncCore>d__0.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
       at System.Web.Http.Filters.ActionFilterAttribute.<CallOnActionExecutedAsync>d__5.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Web.Http.Filters.ActionFilterAttribute.<CallOnActionExecutedAsync>d__5.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at System.Web.Http.Filters.ActionFilterAttribute.<ExecuteActionFilterAsyncCore>d__0.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
       at System.Web.Http.Controllers.ActionFilterResult.<ExecuteAsync>d__2.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
       at System.Web.Http.Controllers.ExceptionFilterResult.<ExecuteAsync>d__0.MoveNext()
    Azure API App provisioning failed

    It seems that the "wizard" gets confused over multiple Directories and selects the wrong STS when issuing tickets. 

    Please advise. Help needed!

    Monday, April 13, 2015 1:52 PM

All replies

  • I'll be investigating your VS experience.

    A few questions:

    • Could you provide your VS version and OS, just to isolate any potential environmental issues?
    • How many AAD directories exist in the subscription to which you're trying to publish?
    • How many subscriptions do you have set up in VS? 
    • Did the "attempted publish" target the subscription you intended to target? 
    • When you set up your project, did you use the API Apps template or did you have a pre-existing Web API project you converted? If it was the latter (the Web API/MVC) project, did you have "no authentication" enabled when you created the project, or did you enable AAD auth, individual auth, or something *other than* no auth?

    Is it a true statement that the desired subscription is the one VS tried to publish to? It seems like your subscription is associated with the tenant "91adce2d-f474-4574-a86d-7ef7f3106c49" but the publish is actually trying to use tenant "e1c4769f-981d-460e-8d73-18100d3fc93a".

    Thursday, April 16, 2015 5:48 AM
    Moderator
  • Suddenly it now works to create App APIs from the portal. However, it still fails when trying to create NEW App APIs form Visual Studio. Publishing to the already existing APIs created using the portal works ok.

    A few answers:

    • Visual Studio 2013 Premium Update 4, Windows 8.1 64-bit.
    • We're having multiple directories (3) associated with the subscription.
    • I don't see how to I can have multiple subscriptions in VS, so there is as far as I understand only one  active  subscription at any given time in VS.
    • The attempted publish targets the correct subscription but (somehow) uses the wrong Azure AD.
    • We're using the new API Apps template.

    Your statement is TRUE (1). We should be using tenant "91adce2d-f474-4574-a86d-7ef7f3106c49" but the publish process somehow chooses the wrong tenant "e1c4769f-981d-460e-8d73-18100d3fc93a" 

    Thursday, April 16, 2015 1:53 PM
  • That's very helpful information. I'll work with the VS tooling team to triage this and will get back to you once I learn more about the nature of this issue. 
    Thursday, April 16, 2015 6:22 PM
    Moderator
  • are there any news to this? looks like we run into the same issue
    Wednesday, May 13, 2015 2:12 PM
  • There are no further updates at this time but I'm opening an issue with the team to investigate this issue. 
    Tuesday, May 26, 2015 9:17 PM
    Moderator
  • I have been emailing with a few of the teams close to this area of the platform and we'd like to know more if at all possible. What would be very helpful would be if we could get a series of Fiddler traces and/or other diagnostic information so we could see more details. Feel free to send me an email (bradyg@msft) and we'll add the appropriate people. The first step would be to capture some of the logs of the conversations your VS instances are having with the Azure APIs so we can better trace what's happening. 
    Monday, June 1, 2015 4:08 PM
    Moderator