Today, a colleague discovered that if we are disconnected from the VPN, we can login into portal.azure.com successfully but then get an network error accessing the Azure AD blade, conditional access, etc.
If we connect to the Pulse VPN using SAML auth and try accessing the blades again, boom we’re straight in.
I’ve not altered any Conditional Access rules and there is nothing in there to say that you have to be connected to a VPN or Trusted Location. We use split tunnelling anyway so Trusted Locations wouldn’t apply (I’m working from home).
Access to the blades worked fine before I setup this up yesterday. I just can’t understand what has happened.
The sign-in logs look OK.
We’ve logged a call with MS but as we are able to access it via VPN, we have till Monday for someone to call back.
It’s most likely has to do with your AD token. If AAD is setup to authenticate with your on prem AD then that is what will issue your token. I would look into how AAD and AD are setup. If you have o365 there is a chance that the configuration was done during that setup process.
Thanks for the reply.
You are right, we have AAD Connect in place but authenticating into all portals with MFA is fine. It’s when you try to dig down into the blades.
Are you able to elaborate a bit more on what I should be looking for on AAD Connect?
Are you guys going through an on prem firewall regardless of the split tunneling?
Additional thought could be that it’s a firewall rules issue. We had a situation similar, in that when you were VPN’ed in you couldn’t access some of the blades but is you were in the office it worked just fine. Turned out to be how the firewall rules were configured.
We are yes and I am not sure whether this problem has existed before I played with the VPN on Friday.
It seems that it doesn’t matter what VPN I am connected to (legacy auth/SSO), I can access the blades, and I can always access the blades via machines in the network.
I wonder if it maybe something to do with the Pass-Through Authentication in AD Connect and when accessing that part of the portal, its doing some sort of extra check.
I’ve managed to find my problem! My Pi-Hole… (facepalm)
So DNS was resolving main.iam.ad.ext.azure.com correctly whilst on VPN, soon as I came off… blocked! I then tried my phone off Wi-Fi and it worked perfectly.
I know! I feel like an idiot but these things are sent to test us.
Not sure what my colleague said to MS support (also happened to him), he jokingly said he was going to say to them “it’s now working, what did you do?” for a windup.
LoL. I am actually having a conversation around this with using selected networking with ACRs. After we found out that private endpoints aren’t supported with app services.