locked
Possible bug: Azure storage account rejects the issuer of a managed service identity RRS feed

  • Question

  • This is a cross-post from Stack overflow question in order to assess if this is a Azure bug.

    I'm using the Microsoft.Azure.Services.AppAuthentication library (v1.0.3) for .NET to connect from Azure Function app to blob storage using managed service identity. Auth code:

    var tokenProvider = new AzureServiceTokenProvider();
    string accessToken = await tokenProvider.GetAccessTokenAsync("https://storage.azure.com/");
    var tokenCredential = new TokenCredential(accessToken);
    var credentials = new StorageCredentials(tokenCredential);
    var storageUri = new Uri($"https://{accountName}.blob.core.windows.net");
    var client = new CloudBlobClient(storageUri, credentials);
    

    One existing storage account refuses to accept the MSI regardless of given RBAC roles:

    Microsoft.WindowsAzure.Storage.StorageException: Server failed to authenticate the request.
    Make sure the value of Authorization header is formed correctly including the signature.
       at Microsoft.WindowsAzure.Storage.Core.Executor.Executor.ExecuteAsyncInternal[T](RESTCommand`1 cmd, IRetryPolicy policy, OperationContext operationContext, CancellationToken token)
       at Microsoft.WindowsAzure.Storage.Blob.CloudBlobContainer.CreateIfNotExistsAsync(BlobContainerPublicAccessType accessType, BlobRequestOptions options, OperationContext operationContext, CancellationToken cancellationToken)
    

    Additional exception details of storageException.RequestInformation.ExtendedErrorInformation.AdditionalDetails complain that AuthenticationErrorDetail: Issuer validation failed. Issuer did not match.

    When decoding the failing jwt token, the issuer seems ok:

    {
      "aud": "https://storage.azure.com/",
      "iss": "https://sts.windows.net/<my directory guid>/",
      ...
    }
    

    When I created new identically set up storage accounts then the same function app MSI and auth code worked and even the issuer in token were exactly the same. So the client function app and it's MSI identity are not the culprit here.

    Why does this one storage account fail to authorize and how to get it to accept the MSI?

    EDIT: I could work around this by just copying out all data, dropping the problem account, creating new one and copying the data back. But it's a hassle to move it all and it would lose the repro case for the possible bug.
    • Edited by Imre Pühvel Thursday, January 3, 2019 1:10 PM Menitoned an undesirable workaround.
    Thursday, December 20, 2018 8:49 AM

Answers

All replies

  • Did you tried using the latest pre-released version (1.2.0-preview) of Microsoft Azure Services App Authentication NuGet package? If not, I would suggest you update for the latest pre-release version here and check the dependencies. Recently, Microsoft have added support for new functionalities.

    I would recommend you to refer the suggestions provided here and here to resolve Authorization header issues in code. See if the above suggestions help you.

    Thursday, December 20, 2018 10:29 AM
  • I tested again with 1.2.0-preview with no change in behavior. Connecting to the problem account fails with same error, connecting to all other storage accounts succeeds.

    I took a look at the provided links but they don't seem to help much:

    First link suggested skipping the Azure .net client and going straight HTTP. Considering that the same client code works perfectly when connecting with MSI to every other azure blob storage under that subscription then I'd deduce that the client code and it's HTTP request generation logic works as intended.

    Also, according to captured AuthenticationErrorDetail message, there is no HTTP syntax problem, but the server expects some other "issuer" compared to what the client is sending. Again, same issuer is accepted as valid when connecting to other storage accounts under the same subscription/directory, so I'd deduce that that this one storage account is somehow different. Also, I don't think capturing raw HTTP response would give out the details about which issuer the server expected, just change the repro code more custom and complex.

    The second link suggests there's a server time difference on the client. This is most likely not relevant in this case as:
    a) I don't have the "Request date header too old" error message, but "issuer is not valid". 
    b) test client is hosted in Azure Function App, hence I've no control over server time.
    c) again the same test client under Azure  Function App can connect to all other storage accounts so client server time is most likely ok.

    Any other suggestions?

    Friday, December 21, 2018 7:51 AM
  • Can you confirm that the storage account is part of a subscription in the same Azure AD tenant as the MSI?

    If so, could you please reach to me via AZCommunity[AT]microsoft.com with a link to this Issue as well as the storage account and function app ARM resource ID’s. Please mention "ATTN subm" in the subject field, we can investigate further on this issue.

    Tuesday, January 22, 2019 4:07 AM
  • Did you ever find a resolution to this?  I'm having exactly the same issue in Visual studio with Microsoft.Azure.Services.AppAuthentication library v1.0.3 and 1.2.0-preview3 

    Graham King

    Thursday, June 20, 2019 8:42 AM
  • @Graham King  Apologies for the delay! Can you share screen shot of the error message or error code?
    May I know what exactly are you trying to accomplish? Have you tried above mentioned troubleshooting steps?

    Tuesday, June 25, 2019 6:59 AM
  • @Graham King and @Imre PühvelJust checking in if you have had a chance to see the previous response. We need the previously asked information to understand/investigate this issue further.
    Wednesday, July 3, 2019 5:35 AM
  • For some unknown reason, the forum did not notify me of new posts. weird.

    SumanthMarigowda, we exchanged multiple messages with you in January in which I passed you everything you asked. It was left unresolved. To recap 

    1. we verified that the tenantIds were ok and it should have worked (but didn't)
    2. it was hinted that subscriptions being previously moved across tenants MAY be related to this.
    3. No solution was reached.

    By now, I have reorganized (just a few days ago actually) the affected subscriptions for business reasons and after directory move I no longer have been able to reproduce the issue.

    @GrahamKing, I still don't know what was wrong, but my experience may give you a workaround to try. You could move affected resources temporarily away and back and see if it helps. 

    Tuesday, November 5, 2019 3:28 PM
  • @Imre Pühvel Apologies for the delay response! I see you have posted similar query in Stack Over flow  forum and and the resolution provided has fixed your issue and the answer has be accepted( Marked it has helpful). Hence we are closing this thread and Marking it as answered. If you have any kind of issue related to Azure. Please feel free to contact us anytime: https://azure.microsoft.com/en-in/support/community/.
    Tuesday, November 26, 2019 6:23 AM