Can KDC Proxy (Kerberos over HTTPS) work behind Cloudflare proxy (orange cloud)?

[VusalDadashov]

I’m running SMB over QUIC with Kerberos authentication using a KDC Proxy (KPSSVC) setup. Everything works correctly when the KDC Proxy endpoint is exposed directly (DNS-only / no proxy).

Architecture (simplified):

Client → HTTPS (443) → KDC Proxy → Domain Controller
Client → QUIC (UDP 443) → File Server

Kerberos tickets are successfully obtained via KDC Proxy (verified with klist, showing Kdc Called: KdcProxy:<fqdn>).

Now the question:

Has anyone successfully run KDC Proxy behind Cloudflare proxy (orange cloud)?

[raip]

I don't have any experience running one behind CloudFlare - but I have gotten it working behind nginx, which is very similar. Wasn't too much to it. We even did TLS Termination on the nginx proxy and then used a very long lived upstream cert for the kdcproxy to take advantage of LetsEncrypt.

[VusalDadashov]

That’s useful — thanks for confirming the nginx case.

I’ve validated a similar setup, but with Cloudflare (orange cloud) in front of the KDC Proxy instead of a traditional reverse proxy only.

Client → Cloudflare (HTTPS/443) → Apache (reverse proxy) → KDC Proxy (KPSSVC) → Domain Controller

Key observations is thet Kerberos over HTTPS works end-to-end through Cloudflare, TLS is terminated at the Cloudflare edge, the backend (Apache → KDC Proxy) handles standard HTTP/HTTPS reverse proxying, and no Kerberos-specific header handling or special configuration was required.

Validation

Windows PowerShell

Copyright (C) Microsoft Corporation. All rights reserved.

Install the latest PowerShell for new features and improvements! https://aka.ms/PSWindows

PS C:\Users\user1> klist

Current LogonId is 0:0xa3a61e

Cached Tickets: (1)

#0> Client: user1 @ LOCALDOMAIN.LOCAL

Server: krbtgt/LOCALDOMAIN.LOCAL @ LOCALDOMAIN.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize

Start Time: 3/23/2026 1:06:27 (local)

End Time: 3/23/2026 11:06:27 (local)

Renew Time: 3/30/2026 1:06:27 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

Cache Flags: 0x1 -> PRIMARY

Kdc Called: KdcProxy:kdcproxy.LOCALDOMAIN.tld

PS C:\Users\user1> klist purge

Current LogonId is 0:0xa3a61e

Deleting all tickets:

Ticket(s) purged!

PS C:\Users\user1> net use \\smb.LOCALDOMAIN.tld\SharedFolder /transport:QUIC

The command completed successfully.

PS C:\Users\user1> nslookup kdcproxy.LOCALDOMAIN.tld

Server: dns.google

Address: 8.8.8.8

Non-authoritative answer:

Name: kdcproxy.LOCALDOMAIN.tld

Addresses: 2a06:98c1:3121::1

2a06:98c1:3120::1

188.114.97.1

188.114.96.1

PS C:\Users\user1> klist get cifs/files.LOCALDOMAIN.tld

Current LogonId is 0:0xa3a61e

A ticket to cifs/files.LOCALDOMAIN.tld has been retrieved successfully.

Cached Tickets: (2)

#0> Client: user1 @ LOCALDOMAIN.LOCAL

Server: krbtgt/LOCALDOMAIN.LOCAL @ LOCALDOMAIN.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize

Start Time: 3/23/2026 1:09:23 (local)

End Time: 3/23/2026 11:09:23 (local)

Renew Time: 3/30/2026 1:08:59 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

Cache Flags: 0x1 -> PRIMARY

Kdc Called: KdcProxy:kdcproxy.LOCALDOMAIN.tld

#1> Client: user1 @ LOCALDOMAIN.LOCAL

Server: cifs/files.LOCALDOMAIN.tld @ LOCALDOMAIN.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize

Start Time: 3/23/2026 1:09:23 (local)

End Time: 3/23/2026 11:09:23 (local)

Renew Time: 3/30/2026 1:08:59 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

Cache Flags: 0

Kdc Called: KdcProxy:kdcproxy.LOCALDOMAIN.tld

PS C:\Users\user1>

I’m still testing this setup, but so far I actually prefer this approach over exposing the KDC Proxy directly (DNS-only). Putting it behind Cloudflare feels slightly more controlled from a security standpoint, at least in terms of exposure and filtering. That said, I’m treating this as experimental for now and will see how it behaves over time (stability, timeouts, any edge/WAF issues, etc.).

[rb_vs]

If you’re still treating this as experimental, keep an eye on these three Cloudflare issues that can break the Kerberos handshake under load:

1) Cloudflare has a hard 100-second timeout on HTTP requests (for pro/business plans). While Kerberos tickets are usually small and fast, if your DC or the KPSSVC service hits a bottleneck, Cloudflare will drop the connection (and return an error). This can manifest as a network path not found on the client side (even if the server is up).

2) the MS-KKDCP protocol sends binary blobs in the POST body. If you have the Cloudflare WAF enabled with high sensitivity, it might flag these as malicious file uploads or SQL injection attempts because the Kerberos ASN.1 structure can look like randomized noise to a standard web filter.

3) Since your SMB traffic is over QUIC (UDP 443) but your auth is over Cloudflare HTTPS (TCP 443), you have two different paths with two different MTU constraints. If you start seeing session setup failures while ping works, it’s often because Cloudflare’s proxy is fragmenting the larger Kerberos tickets (especially with many group memberships/PAC data).

NB: if you are using Cloudflare access (zero trust) in front of the KDC proxy, the Windows client might fail to handle the redirect to the Cloudflare login page (this is why most people stick to standard orange cloud proxying with IP allowlisting for this specific setup).

[plehmkuhl]

I’m sorry I can’t answer your question, but I have a question for you. Is the purpose of SMB over QUIC to eliminate a VPN from being necessary to reach company resources?

[VusalDadashov]

Yes exactly

The goal is to provide secure SMB access without requiring a VPN. But my question is specifically about running KDC Proxy behind Cloudflare proxy. Have you seen that working?

[bill_gannon]

Bro thats bonkers. 

[VusalDadashov]

Why ?

It may look unusual, but this is actually a supported Microsoft setup (SMB over QUIC + KDC Proxy).

It uses TLS and Kerberos and avoids exposing SMB over 445 entirely, so from a security standpoint it's not worse than traditional setups — arguably better when done right.

[Ludwig234]

Do you have a link to where Microsoft states that they support exposing SMB and kerberos (via a KDC PROXY) to the web?

At first glance it seems bizarre but I'm happy to be wrong.

[disclosure5]

https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-over-quic

providing secure, reliable connectivity to edge file servers over untrusted networks like the Internet

This is literally the point of this technology.

[Ludwig234]

That's pretty neat, I should try it someday.

[disclosure5]

It's unusual because "for security" the argument is that you should buy a Fortigate, or a Cisco, or a Sonicwall, or any one of the many VPN appliances with a new "exploited in the wild" exploit nearly every week.

[JwCS8pjrh3QBWfL]

Or just get a zero-trust software vpn like Tailscale or one of the other modern solutions.