API connection to Service Bus in Standard Logic Apps stop working suddenly

Akhil Kumar 6 Reputation points
2022-10-28T14:05:56.197+00:00

We have logic apps which were previously using 'Access Key' based API Connections to connect to the Azure Service Bus. Lately, we have started moving them to API connection based on User Assigned Identity based API connections.

It works but only for a day or two and then it will stop working suddenly. Only thing that works is to create a new API connection with the same User Managed Identity, which is exactly the same as the previous one. It just stops working on its own.

Not able to identify what the issue is and it does not make sense that a new API connection starts to work.

In the Trigger History, triggers shows 'Failed' Status and when you go in details and 'output' links gives the following details

{  
        "statusCode": 401,  
        "headers": {  
            "Cache-Control": "no-store, no-cache",  
            "Pragma": "no-cache",  
            "x-ms-request-id": "00bd6bfb-0f6e-41d2-827c-e12c439167dc",  
            "Strict-Transport-Security": "max-age=31536000; includeSubDomains",  
            "X-Content-Type-Options": "nosniff",  
            "X-Frame-Options": "DENY",  
            "Timing-Allow-Origin": "*",  
            "x-ms-apihub-cached-response": "false",  
            "x-ms-apihub-obo": "false",  
            "Date": "Fri, 28 Oct 2022 12:55:20 GMT",  
            "Content-Length": "1109",  
            "Content-Type": "application/json",  
            "Expires": "-1"  
        },  
        "body": {  
            "status": 401,  
            "message": "40100: Unauthorized : Unauthorized access for 'Receive' operation on endpoint 'sb://xxxxxxxxxxxxxxxx.servicebus.windows.net/sbq-xxxxxxxxxxx'. Tracking Id: 92726aae-0ef3-4444-xxxxxxxxxxxxxxxx, Resource:sb://xxxxxxxxxxxxxxx.servicebus.windows.net/sbq-xxxxxxxxxxx. TrackingId:xxxxxxxxx-0ef3-4444-xxxxxxxxxxxxxxxx, SystemTracker:xxxxxxxxxxxxxxxxxx.servicebus.windows.net:sbq-xxxxxxxxxxxxxxx, Timestamp:2022-10-28T12:55:21\r\nclientRequestId: 00bd6bfb-0f6e-41d2-xxxxxxxxxxxxxxxxxx",  
            "error": {  
                "message": "40100: Unauthorized : Unauthorized access for 'Receive' operation on endpoint 'sb://xxxxxxx.servicebus.windows.net/sbq-xxxxxxx'. Tracking Id: xxxxxx-0ef3-4444-xxxxxxxxxxxxxxxxxxxxxxxxxx, Resource:sb://xxxxxxxxxxxxxxxxxx.servicebus.windows.net/sbq-xxxxxxxxxx. TrackingId:92726aae-xxxxxxxxxxx-xxxxxxxxxxxxx, SystemTracker:xxxxxxxxxxx.servicebus.windows.net:sbq-xxxxxxxxxxxxxxx, Timestamp:2022-10-28T12:55:21"  
            },  
            "source": "servicebus-uks.azconn-uks-002.p.azurewebsites.net"  
        }  
    }  

Does any one know what could be going on here ?

Azure Logic Apps
Azure Logic Apps
An Azure service that automates the access and use of data across clouds without writing code.
3,542 questions
{count} votes

2 answers

Sort by: Most helpful
  1. MayankBargali-MSFT 70,936 Reputation points Moderator
    2022-10-31T08:21:49.923+00:00

    @Akhil Kumar Thanks for reaching out. As per the error it looks like the user that was used to authenticate the connector doesn't have the right (read) permission to perform the operation. Can you please confirm if there were any changes to the permission at the identity end due to which you have observed this behavior. Only in scenario when there is change in permission you should observe this behavior, but it is strange that if you change any other configuration and save the logic app then it works fine.

    This would need to be troubleshooted further from identity and logic app end. I would like to connect with you offline if you have confirmed that there were no changes of permission at the identity end so I can review it and it would be great if we can have a repro. Please refer to my private comment so I can connect with you offline to assist you further.

    1 person found this answer helpful.
    0 comments No comments

  2. Peter Olofsson 6 Reputation points
    2022-12-01T10:58:05.263+00:00

    I'm going to hitch my proverbial wagon to this post as I'm facing sort of the same issue.
    I was tasked with making an bunch of logic apps and their resources conform to the same naming standard.
    When I reached the ServiceBus connectors in my LogicApps (trigger and actions) I also figured I'd take the opportunity
    to switch from connection string based connections to Managed Identity based connections, as this is something we've discussed.
    So I deleted the existing connection string based api connection, and straight away recreated it, using the same name
    but opting to go with Managed Identity instead of Access Key.
    After that I turned on Identity for a Logic App and made sure to assign that identity to the "Azure Service Bus Data Receiver" role
    when used in the trigger step of the logic app, and to the "Azure Service Bus Data Sender" role when used in an action sending a message to a Service Bus queue.

    This is when I started seeing the same error messages as the original poster.
    For some Logic Apps, I've been able to make it work again, but I can't tell you how. I've tried "everything" and it seems like one or more of the following actions
    fixes it; disabling/enabling the identity of the logic app or switching and switching back the connection. I really can't say for sure, sometimes I can make it work again and other times not.

    Then today, I've tried this multiple times for a Logic App, and I can't make it work. I've tried to give the Logic App managed identity "Receiver" role permissions
    on the queue level and on the namespace level. I've tried giving it "Data Owner" role permissions on the queue and namespace levels. Nothing works.
    I've tried to, within the same resource group, as the other Logic Apps, to create a new service bus queue and a new Logic App, enabled Managed Identity, and added it to the correct role on the new queue. Still the 401 error.

    Switching over to using a connection string connection works just fine, but we're aiming to move away from that in favour of managed identity connections instead.
    Any input is greatly appreciated.

    1 person found this answer helpful.

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.