Anyone actually using Cloudflare Access in production with hybrid AD?

I've been running a hybrid Kubernetes cluster setup for a while now, where some nodes are on-premise and others are in the cloud, and our identity provider has always been our on-premise Active Directory. We recently implemented Cloudflare Access to secure our internal web applications without a VPN, and I wanted to share our detailed experience, especially around the hybrid AD integration, as it had a few sharp edges that took some patience to smooth out.

Our primary goal was to protect several internal dashboards (like Prometheus, Grafana, and a custom admin panel) and a few legacy web apps hosted on-premise. The requirement was that authentication must tie back to our existing AD groups, and we needed zero-trust style access—no traditional network perimeter.

Here’s a breakdown of our architecture and the key configuration pieces:

* **On-premise AD Connector:** We deployed the Cloudflare `cloudflared` daemon as the "Access connector" on a small, hardened VM within our on-prem network. This connector doesn't sync passwords; it acts as a bridge for LDAP queries and authentication requests from Cloudflare's network to our AD domain controllers.
* **Application Configuration in Zero Trust Dashboard:** For each app (e.g., `grafana.internal.example.com`), we created an Access application policy. The most critical part was the **identity rule**. We configured it to use our integrated Azure AD (which is synced from our on-prem AD) as the primary IdP for a seamless user experience, but we *also* set up a fallback rule using the LDAP integration pointed at our connector for service accounts and any users not fully synced to Azure AD.
* **Service Token for Machine Access:** For our CI/CD pipelines that need to hit internal APIs, we used Service Auth tokens. This was cleaner than trying to use a machine account via LDAP every time.

The configuration for the `cloudflared` connector (its `config.yaml`) looked something like this:

```yaml
tunnel: your-tunnel-uuid
credentials-file: /etc/cloudflared/cert.pem

ingress:
- hostname: ldap.company.com
service: ldap://ad-dc1.company.com:389
originRequest:
noTLSVerify: true
- service: http_status:404
```

The real complexity came in the Zero Trust dashboard LDAP settings. You have to map AD attributes carefully:

* **User Group DN:** `CN=K8s-Admins,OU=Security,DC=company,DC=com`
* **Username attribute:** `sAMAccountName`
* **Email attribute:** `mail`

**Pitfalls we encountered:**

* **LDAP vs. Azure AD Group Latency:** When a user is added to an on-prem AD group, there's a delay before it reflects in Azure AD. Our Access policy for `prometheus.internal.example.com` required the group `CN=Monitor-Users...`. Users would sometimes be denied for an hour until Azure AD synced. We mitigated this by making the LDAP connector the primary auth source for the most time-sensitive apps.
* **Service Account Authentication:** Some of our legacy apps used service accounts stored in AD. These accounts had no `mail` attribute, which Cloudflare Access requires. We had to create a custom attribute mapping and use a proxy email domain for them.
* **Connector High Availability:** Running a single connector VM was a SPOF. We eventually deployed two connectors in different subnets, registered both in the Zero Trust dashboard, and used DNS round-robin for the connector hostname.

Overall, it's running stably now, but the "hybrid" aspect meant we were essentially integrating with two slightly different systems (raw on-prem AD *and* Azure AD) simultaneously. The documentation leans heavily towards the cloud IdP side. My advice is to test group memberships and attribute mappings exhaustively during the pilot phase.

Has anyone else gone through this hybrid AD journey with Cloudflare Access? I'm particularly curious about how you've handled high availability for the LDAP connector on-prem or if you've found a cleaner way to unify the group membership experience.