I've been attempting to integrate Cloudflare Zero Trust's DNS filtering (specifically the Gateway resolver) with our on-premise Active Directory environment for several weeks, with the goal of applying distinct DNS policies based on user group membership from AD. The documented process involving the Cloudflare Zero Trust agent (warp) and the `cloudflared` daemon for service authentication appears straightforward, but the implementation has been fraught with inconsistencies and a lack of detailed operational guidance.
My current architecture involves a standard Windows Server AD domain with integrated DNS. The goal is to have domain-joined machines route their DNS queries through Cloudflare Gateway for security filtering, while still resolving internal AD records (like `_ldap._tcp.dc._msdcs`) and other on-prem resources. The primary hurdle is the seamless integration of the Cloudflare Zero Trust identity provider (via the WARP agent) with AD user context. The agent authenticates the device, but mapping that device session to a specific user's AD group memberships for granular DNS policy application is not functioning as anticipated.
Here is a high-level summary of my configuration attempt:
1. **Service Authentication:** `cloudflared` is installed on a designated server, authenticated via a service token, and is successfully proxying DNS to Cloudflare's edge as per the dashboard metrics.
2. **WARP Deployment:** The WARP client (Zero Trust version) is deployed via GPO. It connects successfully, and the device appears in the Zero Trust dashboard as a managed entity.
3. **DNS Location Setup:** A DNS location is configured in the dashboard, pointing to the internal IP where `cloudflared` is listening for DNS (default 5054). The "Proxy over WARP" option is enabled for this location.
4. **AD Identity Provider:** The Active Directory identity provider is configured in Zero Trust, with the LDAP connector installed on-prem. User groups are successfully synced and visible.
The critical failure point is policy execution. Despite creating a DNS policy with an "Include" rule for a specific AD group, members of that group do not have the policy applied. All traffic seems to either fall through to the default policy or, at times, internal resolution breaks entirely. The documentation lacks sufficient detail on the following:
* The exact order of operations for DNS resolution on a WARP-enabled, AD-joined endpoint. Does the query go to the local stub resolver, then to `cloudflared`, or is it intercepted directly by the WARP virtual interface?
* The required configuration for the AD LDAP connector to pass real-time user context (not just group lists) for DNS queries. Are there specific attributes or filters that are mandatory?
* How to validate that a specific DNS query from a specific user is being evaluated against the correct policy in real-time. The Gateway logs show queries but lack definitive user/group attribution in failed cases.
Has anyone successfully achieved a stable configuration where Cloudflare Gateway DNS policies are applied dynamically based on on-prem AD group membership? I am particularly interested in the specific configuration nuances of the `cloudflared` DNS proxy and any necessary GPO settings for the WARP client that might differ from the standard deployment. A comparison of working configurations versus the documented steps would be invaluable.
Data never lies.
Mapping the WARP device session to dynamic AD user context is indeed the most brittle part of this architecture. The agent's default posture is machine-centric. You'll need to enforce user-level authentication via the WARP client settings, which often requires a always-on VPN posture that can interrupt user workflows.
Have you configured a Cloudflare Access application for the 'warp' service itself, with an AD identity provider and group membership rules? That's the piece that ties the session to user identity for Gateway policies. The `cloudflared` daemon is just for tunneling, it doesn't handle the user mapping.
Also, your internal DNS resolution will break unless you've explicitly defined those domains in your Zero Trust dashboard under DNS Local Domain Fallback. The resolver won't automatically forward `.internal` queries to your AD servers.
infrastructure is code
You're correct about the local domain fallback being a critical step. I'd add that the order of your DNS resolution policy rules matters more than the documentation implies. If you have a 'catch-all' rule directing traffic to Cloudflare's 1.1.1.1, it will intercept queries for your internal domains unless you create an explicit 'Local Domain' rule with a higher priority that points to your AD DNS servers' IPs.
On the user mapping, we found the WARP client's 'Switch Locked' mode necessary to force re-authentication on network changes, but it generated a significant volume of helpdesk tickets due to the perceived 'broken internet' during the auth handshake. The identity provider session lifetime has to be carefully tuned to match your AD token renewal policies.
data is the product