{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/check-connection-bound-windows-authentication-before-proxying-an-intranet-through-cloudflare/", "item": { "id": "https://update.dsesecurity.com/updates/check-connection-bound-windows-authentication-before-proxying-an-intranet-through-cloudflare/", "slug": "check-connection-bound-windows-authentication-before-proxying-an-intranet-through-cloudflare", "url": "https://update.dsesecurity.com/updates/check-connection-bound-windows-authentication-before-proxying-an-intranet-through-cloudflare/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/check-connection-bound-windows-authentication-before-proxying-an-intranet-through-cloudflare.md", "json": "https://update.dsesecurity.com/api/v1/posts/check-connection-bound-windows-authentication-before-proxying-an-intranet-through-cloudflare/" }, "title": "Check connection-bound Windows authentication before proxying an intranet through Cloudflare", "summary": "NTLM and Kerberos assumptions can cause repeated prompts when requests do not retain one origin connection.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:16:51+00:00", "modified_at": "2026-10-20T18:34:36+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 254, "potentially_affected": "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.", "primary_source": { "name": "Cloudflare — Proxying limitations", "url": "https://developers.cloudflare.com/dns/proxy-status/limitations/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

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

\n

Source facts

\n

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.

\n

Source: Cloudflare — Proxying limitations.

\n

Applicability

\n

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

\n

DSE recommendation

\n

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.

\n

Verification

\n

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.

\n

Official reference

\n

Cloudflare — Proxying limitations. Reviewed October 20, 2026.

", "content_text": "NTLM and Kerberos assumptions can cause repeated prompts when requests do not retain one origin connection.\nSource facts\nCloudflare 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.\nSource: Cloudflare — Proxying limitations.\nApplicability\nThis concerns the ordinary Cloudflare HTTP proxy described in the source.\nDSE recommendation\nDSE 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.\nVerification\nIn 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.\nOfficial reference\nCloudflare — Proxying limitations. Reviewed October 20, 2026.", "content_markdown": "NTLM and Kerberos assumptions can cause repeated prompts when requests do not retain one origin connection.\n\n## Source facts\n\nCloudflare 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.\n\nSource: [Cloudflare — Proxying limitations](https://developers.cloudflare.com/dns/proxy-status/limitations/).\n\n## Applicability\n\nThis concerns the ordinary Cloudflare HTTP proxy described in the source.\n\n## DSE recommendation\n\nDSE 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.\n\n## Verification\n\nIn 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.\n\n## Official reference\n\n[Cloudflare — Proxying limitations](https://developers.cloudflare.com/dns/proxy-status/limitations/). Reviewed October 20, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/check-connection-bound-windows-authentication-before-proxying-an-intranet-through-cloudflare/", "url": "https://update.dsesecurity.com/updates/check-connection-bound-windows-authentication-before-proxying-an-intranet-through-cloudflare/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-20" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/check-connection-bound-windows-authentication-before-proxying-an-intranet-through-cloudflare/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Check connection-bound Windows authentication before proxying an intranet through Cloudflare", "item": "https://update.dsesecurity.com/updates/check-connection-bound-windows-authentication-before-proxying-an-intranet-through-cloudflare/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/check-connection-bound-windows-authentication-before-proxying-an-intranet-through-cloudflare/#article", "identifier": "https://update.dsesecurity.com/updates/check-connection-bound-windows-authentication-before-proxying-an-intranet-through-cloudflare/", "url": "https://update.dsesecurity.com/updates/check-connection-bound-windows-authentication-before-proxying-an-intranet-through-cloudflare/", "headline": "Check connection-bound Windows authentication before proxying an intranet through Cloudflare", "description": "NTLM and Kerberos assumptions can cause repeated prompts when requests do not retain one origin connection.", "abstract": "NTLM and Kerberos assumptions can cause repeated prompts when requests do not retain one origin connection.", "articleBody": "NTLM and Kerberos assumptions can cause repeated prompts when requests do not retain one origin connection.\nSource facts\nCloudflare 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.\nSource: Cloudflare — Proxying limitations.\nApplicability\nThis concerns the ordinary Cloudflare HTTP proxy described in the source.\nDSE recommendation\nDSE 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.\nVerification\nIn 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.\nOfficial reference\nCloudflare — Proxying limitations. Reviewed October 20, 2026.", "datePublished": "2026-10-20T18:16:51+00:00", "dateModified": "2026-10-20T18:34:36+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/check-connection-bound-windows-authentication-before-proxying-an-intranet-through-cloudflare/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/check-connection-bound-windows-authentication-before-proxying-an-intranet-through-cloudflare/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Check connection-bound Windows authentication before proxying an intranet through Cloudflare" }, "articleSection": [ "Cybersecurity", "Networks & Infrastructure" ], "keywords": [ "Cybersecurity", "Networks & Infrastructure", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 254, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Cloudflare — Proxying limitations", "url": "https://developers.cloudflare.com/dns/proxy-status/limitations/" } } ] } }