Microsoft Authenticator issue

Hi,

I was using today the Microsoft Authenticator app on my iPhone (via the home WiFi, with Cloudflare DNS 172.64.36.1 as forwarder) and got errors while tryin to access some M365 service:

It worked while using the cell data.

Finding strange, I tried accessing the URL directly in a Web browser and got this error page (sorry, can post only one embedded object):

Access restricted
Site: mobileappcommunicator.auth.microsoft.com
This site is blocked. Please contact your administrator for further assistance.

A Microsoft login page (Sign in to your account…) opens when using another network.

So, could it be some wrong security classification in the Cloudflare service (ex: DNS)?

Tks.

Here is also the web page error message:

Now the situation changed… a certificate authority issue?

It sounds like you’re using Gateway. It also sounds similar to this issue, which includes a suggested fix:

A few days ago I started to “play” with the Gateway from Cloudflare for Teams, for DNS resolution (protection, logging, etc.)… not for http(s) inspection.
But now it seems that (at least some of the) web traffic gets forwarded to a proxy.
I just re-tested and the initial link ‘mobileappcommunicator.auth.microsoft.com’ used by the MA app gets redirected to ‘login.microsoftonline.com’, but via the proxy (as the cert is the Cloudflare one)… and I checked and still have disabled the HTTP traffic filtering in the Secure Web Gateway, including disabled TLS decryption

You have to look at the Gateway logs. Search for the domain mobilappcommunicator… and see why the domain was blocked.

The certificate certainly shows that the HTTP policy is configured for TLS Decrypt. You should a create a HTTP policy to skip Microsoft from inspection. If it still doesn’t work you can create a policy for this domain specifically.

1 Like

This hostname and/or one of the CNAME targets for it is being blocked based on a DNS policy you have configured in Teams. In your Teams dashboard go to Logs | Gateway | DNS and filter on Blocked for Actions taken. likely one or more of the following will show as being blocked:

mobileappcommunicator.auth.microsoft.com. 226 IN CNAME prda.aadg.msidentity.com. prda.aadg.msidentity.com. 226 IN CNAME www.tm.a.prd.aadg.akadns.net.

If I had to make a guess I’d assume new or newly seen domain will be reported as the category for one or more of the records (the link to the Radar report will tell you for sure). You can explicitly allow the host and/or modify your DNS filtering policies as need.

It’s also possible to see the Cloudflare Gateway cert when using ‘custom block page’ even without HTTP filtering enabled as the only way to show a custom block page for a blocked DNS request without it showing a certificate error (since the cert won’t match) is to have that installed.

Of course. Sorry, forgot about that.

I get caught by it almost daily… :slight_smile:

The thing is I started my reply going on about DNS because of the OP saying “not for HTTP(s) inspection” but then got thrown off because of the certificate and I didn’t think of the custom block page.

Doh.

Sorry for the delay.

The issue seemed to be the resolution treatment for ‘mobileappcommunicator.auth.microsoft.com’, which seemed to have also checking the alias ‘prda.aadg.msidentity.com’ and this one was blocked by the CF rule Query categories=Security Risks, Unreachable (why?), with the Resolver decision=Blocked By Query Name , which seems strange at least and I don’t understand this behavior (some abnormal decision in the CF classification logic?).

I set some Gateway DNS policies to “ Allow ” the domains ‘.microsoft.com’ and ‘.msidentity.com’, and set an HTTP policy for ‘.microsoft.com’ to ‘ Do Not Inspect ’, and I no longer received the error, but I feel this doesn’t have to be the case… how many other similar tweaks should we do for how many other domains?

And I was not getting the ‘custom block page’, but some default CF one (per the first image).

I understand the necessity to show the blocked page for human consumption, but for applications/APIs calls this creates issues. And I still believe the issue reside within the DNS filtering engine in the first place.

Many thanks.

That’s a custom block page. The other option (if custom block page is not enabled) is that we will return 0.0.0.0 for the address and there’s no block page.

The domain is classified as unreachable because … it’s unreachable… there isn’t anything shown on a web page for that host. Not my favorite classification category (not as clear cut as say a phishing domain). You can submit domains/hosts you believe are miscategorized through radar.cloudflare.com.

There’s no one size fits all set for filters to apply. In some organizations an aggressive approach to allowed domains make sense. In others… not as much.

The ‘custom block page’ matter… if I correctly understood it… the own I configured has a different wording (and even color, to pop in a glimpse of an eye).

What I do not understand is why the errors seems to have been initiated due to the CNAME ‘prda.aadg.msidentity.com’ (unreachable – as in nothing answering to the http(s) requests), while the MA API calls would get sent to ‘mobileappcommunicator.auth.microsoft.com’…

Also, I see this not as a specific item for my setting, as the MA is a widely used app/system.

Tks.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.