Earlier today I was troubleshooting something for a customer where some end-users were getting issues when trying to connect to an Azure blob storage using the Azure web portal. This also recently stopped working and impacted some of the users. This was the error message that they were getting when trying to connect.
“Unable to load data” Network request failed – cannot access storage endpoint. As seen in the screenshot below.
Nifty! That was something that I hadn’t seen before, usually, I would start to check for private endpoints and DNS lookups, but this error message also applied to storage accounts that were publicly available as well. Just as a side note, when you have private endpoints the browser will try to do a CNAME lookup and find the local IP addresses defined in DNS to connect to the resource, but that was not the case here.
Firstly we checked the DNS lookup on the client and it was working as intended, and it was properly resolving to the IP address for the storage account service (both internal and external)
So I decided to dig a bit deeper into the logs to try and figure out what was going on. I dug into the Storage Blob logs on the storage account to see if I could see which IP Address was trying to connect to the Blob account.
Oddly enough, I saw a 404 error message that said authorization failed. I also saw the SAS URL that was generated to try and access the account. Fun fact: When you try and browse a storage account container within the Azure Portal, it will automatically generate a SAS key that will be used as part of the session and try and access it.
Similar to this URL as an example https://storageaccount.blob.core.windows.net/container?restype=container&comp=list&prefix=&delimiter=%2F&marker=&maxresults=30&include=metadata&sv=2022-11-02&ss=bqtf&srt=sco&sp=rwdlacuptfxiy&se=2023-10-22T05:20:30Z&sig=fnnhMxnoinZnhwAUZ7iKUwBGKjsR4wAO5PM9tGQtElw%
Now you can also open this URL directly outside of the Azure Portal and it will list out the results in XML. The URL will only just chunks of metadata in XML, but you can at least use this to verify connectivity for a publicly available storage account
The interesting part here is that I was able to open this URL but not by the person testing who got this similar error message from his web browser.
Okay, so something was prohibiting the SSL/TLS session from being established, which makes sense given the initial error message that we got from the Azure Portal. Then I noticed that I was using Microsoft Edge, and the one that was testing was using Chrome, hence I asked them to test with Edge and then suddenly the pieces began to fall in place.
NOTE: Since I didn’t take a screenshot I borrowed this from another website, given it has the same error message.
When they tested with Microsoft Edge, we got this error message.
This is Microsoft Defender SmartScreen, which is a feature in Windows that blocks access to non-safe websites. This can be websites flagged by Microsoft or websites that have been flagged/blocked by the organization. SmartScreen only works in Microsoft Edge, however for Google Chrome browsers, Microsoft will block the network traffic on the Operating system level using built-in features.
So something is making the client block traffic to these endpoints from an OS level. Then I decided to take a look through Microsoft Defender for Cloud Apps and noticed that Microsoft Blob Storage was set as an unsanctioned app. So what happens when you have Defender for Endpoint, integrated with Defender for cloud apps and network protection feature enabled, and you set an app to be unsanctioned?
Defender for Cloud Apps will add the domains as a custom indicator in Defender for Endpoint which will then start and block access to the different URLs. For users with Edge, it will trigger SmartScreen and for users with Chrome, it will block SSL/TLS session to be enabled.
You can custom indicators that are added to the network protection feature which will block access to any URL within the given domains. The picture below shows the specific URLs that were automatically blocked because of this. This was also the reason why they were unable to access the storage account, either directly or via the Azure portal.
So after we set the app to sanctioned again and removed the custom indicators, everything started working again.