Check connection-bound Windows authentication before proxying an intranet through Cloudflare

NTLM and Kerberos assumptions can cause repeated prompts when requests do not retain one origin connection.

Source facts

Cloudflare documents that Microsoft Integrated Windows Authentication, NTLM, and Kerberos are not compatible with its proxied DNS records. The explanation notes NTLM’s TCP-connection-level authentication and that consecutive client requests are not guaranteed to reuse one TCP connection to the origin. Repeated prompts or authentication loops can result.

Source: Cloudflare — Proxying limitations.

Applicability

This concerns the ordinary Cloudflare HTTP proxy described in the source.

DSE recommendation

DSE recommends inventorying the application’s authentication mechanism before changing proxy status. Separate modern browser sign-in or application authentication from legacy connection-bound negotiation. Select a supported access design with the application and identity owners rather than disabling authentication to remove a prompt loop. Keep a restricted recovery path and document how direct origin exposure is controlled if a DNS-only service is part of the approved design. Require the identity owner to identify the actual negotiation method from sanitized evidence before the proxy change. Test a multi-request application workflow, not only its initial landing page. Keep any alternate access plan subject to the same authorization requirement instead of using anonymous access as a diagnostic shortcut.

Verification

In a nonproduction deployment, test representative users across fresh sessions, repeated requests, and relevant browsers. Inspect the authentication exchange and origin behavior without collecting credentials. Confirm the selected design supports the intended login mechanism before production cutover, and record prompt loops as observations rather than assuming a bad user password.

Official reference

Cloudflare — Proxying limitations. Reviewed October 20, 2026.