Looking to replace a traditional VPN for internal apps. Cloudflare Access with a hybrid AD identity provider seems like the right fit on paper.
Has anyone actually deployed this in production?
* What's your sync method (Azure AD Connect, other)?
* How are you handling group membership for Access policies? Are you syncing security groups or using nested groups in Cloudflare?
* Any major pitfalls with user lifecycle or authentication delays?
Our setup is mostly on-prem AD with a small Azure AD Connect sync to Azure AD for some SaaS apps. Wondering if pushing groups through Azure AD is the most reliable path.
—cp
—cp
We're using exactly this setup for about 200 users, replaced an aging Cisco VPN. Sync method is Azure AD Connect, standard sync to Azure AD. Cloudflare Access uses Azure AD as the SAML IdP.
For your group question: we're syncing on-prem security groups to Azure AD, then using those groups directly in Access policies. It works, but the delay can be annoying - a user added to a group can take up to 30 minutes to get access. Cloudflare's nested groups feature didn't feel mature enough when we evaluated.
Biggest pitfall we hit: if your hybrid setup has any funky attribute filtering in AAD Connect, Cloudflare might not get the group memberships it expects. Double-check your sync rules.
Also, watch out for authentication delays if your on-prem AD is geographically distant from your AAD Connect sync engine. We had some weird latency spikes for users in remote offices until we moved the sync server.
Data is the new oil - but it's usually crude.
Yes, it's production viable, but your specific sync setup is the deciding factor. Pushing groups through Azure AD is the most common and reliable path, as you guessed. That 30 minute delay user50 mentioned is real, but it's a sync latency issue, not a Cloudflare one.
Your biggest gotcha will be testing the group membership flow from end to end. Don't just assume your sync rules are correct. Validate that the exact groups you need are appearing in Azure AD and are being passed correctly in the SAML assertion to Cloudflare. A misconfigured claim rule is a frequent trip point.
—AF
We're looking at a similar setup. Have you considered the user experience with SSO timeouts? Our team complains about re-authenticating too often, but I'm not sure if that's a Cloudflare or Azure AD config issue. Might be something to test early.
That point about validating the SAML assertion is crucial. We burned a few hours because the claim was passing the group's display name instead of the object ID. Azure AD's default can be misleading.
We set up a test app registration in Azure as a dummy SAML endpoint to inspect the raw token. Saved us a lot of back-and-forth with Cloudflare support. You're spot on - you can't trust the sync until you see the exact claim data.
Still looking for the perfect one
Completely agree on the validation step being critical. That 30 minute sync window can actually mask deeper issues; we discovered our AAD Connect was configured to only sync groups with fewer than 1500 members due to an old default, which silently excluded a key policy group.
Your suggestion to inspect the raw SAML token is the only reliable method. I'd add that you should specifically check for the ` http://schemas.microsoft.com/ws/2008/06/identity/claims/groups` claim in the decoded token, not just the friendly name. Azure AD's SAML claim configuration UI can sometimes map to the wrong source attribute, leading to empty or mismatched values that only appear under actual load.
The delay is indeed an AAD Connect limitation. If that latency is problematic for your use case, like onboarding contractors who need immediate access, you might need to consider a secondary, direct AAD group managed in the cloud for time sensitive policies, which complicates the model.
Data never lies.
That 30 minute delay is the killer for us. Makes onboarding a pain. Is there any way to force a faster sync for just the critical groups, or do you just have to accept the standard cycle?
That's a smart idea, using a dummy endpoint to see the raw data. It sounds like the claim mapping in Azure is a consistent trap.
I'm curious, when you saw the display name being passed, was that because of the default claim rule Azure created for your Cloudflare app, or had you tried to customize it?