I originally started this lab with a simple goal: learn more about identity and access management by
integrating Microsoft Entra ID with Cloudflare Zero Trust.
On paper, the project looked straightforward. Configure Entra ID as an identity provider, connect
Cloudflare Zero Trust, protect a few applications, and test the sign-in experience. I expected to learn
the basics of single sign-on and maybe pick up a few Cloudflare concepts along the way.
As with many of my lab projects, things quickly became more interesting than expected.
The first challenge appeared while configuring OpenID Connect between Cloudflare and Microsoft Entra ID.
Everything seemed to be configured correctly. The application registration existed, the client secret
was created, and the tenant information was entered into Cloudflare. When I attempted to test
authentication, however, Microsoft responded with an error: AADSTS500113. No reply address was
registered for the application.
That error sent me down the first rabbit hole.
Redirect URIs weren't new to me, but this project reminded me how critical they are to modern
authentication. Everything else appeared to be configured correctly, yet a single missing callback address
was enough to stop the entire sign-in process in its tracks.
Once the proper callback URL was added to the application registration, authentication immediately began
working. One of the most valuable lessons from the project came from that single error message.
Understanding why something failed proved far more educational than simply following a setup
guide.
With authentication working, I moved on to authorization and began creating Cloudflare Access
applications. Initially, I configured a policy that allowed only a single email address to access a
protected application. The result was exactly what I expected. One user could access the application,
while another user from the same tenant was denied.
Authentication and authorization are not the same thing.
Microsoft Entra ID successfully authenticated both users. Cloudflare Access then evaluated policy and
determined which user was authorized to proceed. I was able to clearly see the
separation between proving identity and granting access. It seems obvious in hindsight, but seeing it
happen in a real environment made the distinction much easier to understand.
Just when everything appeared to be working, another issue appeared.
One of my protected applications refused to load and returned a DNS_PROBE_FINISHED_NXDOMAIN error. At
first, I assumed the problem was Cloudflare. After all, I had recently created the DNS records and
configured the applications. It felt like the most likely culprit.
After digging deeper, I discovered the problem had nothing to do with Cloudflare at all. The DNS server
configured on my workstation simply didn't know about the new record yet. Testing against Cloudflare's
public DNS servers immediately returned the correct result.
That rabbit hole taught me another lesson about DNS.
The authoritative DNS server and the DNS server your computer is using are two completely different
things. Once I understood that distinction, the troubleshooting process made far more sense. It also
gave me a much better appreciation for how DNS resolution actually works behind the scenes.
The final surprise came while working with Cloudflare Workers. I had a Worker deployed and functioning,
yet attempts to access the protected application resulted in a 522 Host Error. Once again, I assumed
something far more complex was wrong.
The actual problem was surprisingly simple. The subdomain had never been attached to the Worker. After
adding the domain association, everything immediately started working as expected.
Looking back, very little of this project involved clicking buttons. Most of the learning happened while
investigating why those buttons didn't produce the results I expected.
What began as a simple single sign-on project became a hands-on lesson in OpenID Connect, redirect URIs,
identity providers, authentication, authorization, DNS architecture, Cloudflare Access policies, and
application protection.
More importantly, it reinforced a lesson I've encountered repeatedly throughout my technology
journey.
The best learning rarely comes from success.
The best learning comes from the moment something breaks and you're forced to discover why.
By the end of the project, I had successfully integrated Microsoft Entra ID with Cloudflare Zero Trust,
protected applications behind Cloudflare Access, and gained a far deeper understanding of modern
identity and access management than I expected when I started.
Not bad for a lab that was originally supposed to be a quick couple hour project. 🐦🐦