What real-world apps strictly require Kerberos Protocol Transition ("Use any authentication protocol")

Question

What real-world apps strictly require Kerberos Protocol Transition ("Use any authentication protocol")

Prabhjot Singh 255

Hey everyone,

We are currently auditing our Active Directory delegation settings and found several accounts configured with Constrained Delegation + Kerberos Protocol Transition ("Use any authentication protocol").

Our goal is to lock these accounts down to Kerberos Only to reduce our attack surface. However, another internal team wants to see a list of actual, real-world use cases where Protocol Transition is strictly required before we make any changes in production.

Aside from basic web apps with forms-based logins or Entra Private Network Connectors, what specific applications or backend setups in your environment broke when you switched them to Kerberos Only?

Trying to gather real-world examples before we talk to application owners.

Appreciate any insights!

0 comments

2 answers

Your answer

Answer 1

Hi Prabhjot Singh,

Outside of basic forms-based websites and Entra connectors, reporting and collaboration platforms are the most frequent workloads to break. SharePoint Server environments that authenticate users via SAML or federated claims rely on the Windows Identity Foundation Claims to Windows Token Service (c2wts), controlled by C:\Program Files\Windows Identity Foundation\v3.5\c2WTShost.exe.config (the configuration file that specifies which local service identities are allowed to translate claims into Windows credentials). Similarly, when standalone SQL Server Reporting Services (SSRS) or Power BI Report Server instances are configured for Integrated Windows Authentication via RSWindowsNegotiate inside rsreportserver.config (the main reporting configuration file) and published externally through Windows Server Web Application Proxy (WAP), the WAP server's computer account must translate incoming OAuth or AD FS tokens into Kerberos tickets. Switching either the c2wts service account or the WAP computer account to "Use Kerberos only" prevents them from impersonating federated users to backend SQL Server (MSSQLSvc) or Analysis Services (MSOLAPSvc) databases, resulting in immediate login failures for NT AUTHORITY\ANONYMOUS LOGON.

Active Directory Certificate Services (AD CS) Certificate Enrollment Web Service (CES) and edge reverse proxies also break when they terminate client certificates or multi-factor tokens before reaching Active Directory. When CES is configured for Client Certificate Authentication so domain computers or VPN-less devices can renew certificates over HTTPS, IIS authenticates the client's existing X.509 certificate via the Windows TLS Schannel provider rather than Kerberos. The CES service account must then use protocol transition to impersonate that client to the Enterprise Issuing Certification Authority over Remote Procedure Call services (HOST and rpcss SPNs); removing "Use any authentication protocol" causes certificate renewals to fail with Access Denied (0x80070005). The exact same outage occurs on hardware load balancers like F5 BIG-IP APM and Citrix NetScaler, or IIS gateways using Client Certificate Mapping inside C:\Windows\System32\inetsrv\config\applicationHost.config (the master IIS configuration file that maps incoming smart cards or client certificates to Active Directory accounts), whenever they terminate smart card (PIV/CAC), RADIUS, or SAML authentication at the network edge in front of Kerberos-protected SAP or .NET backend services.

To identify which production accounts actively rely on protocol transition before talking to application owners, enable "Audit Kerberos Service Ticket Operations" on your Domain Controllers and inspect C:\Windows\System32\winevt\Logs\Security.evtx (the Windows Security Event Log file) for Event ID 4769. Active protocol transition produces a self-directed 4769 event (S4U2Self) where the Service Name and Client Address match the delegated front-end service while the Account Name shows the impersonated user, followed immediately by a second 4769 event (S4U2Proxy) targeting the backend SPN with the front-end service listed under Transited Services. When testing "Use Kerberos only" in a staging window, you can also navigate to the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters on the application server and set the LogLevel REG_DWORD value to 0x1, which turns on detailed Kerberos diagnostic logging in the System Event Log (C:\Windows\System32\winevt\Logs\System.evtx) without requiring a reboot.

Hope this answer has brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

VPHAN

Answer 2

Protocol transition is strictly required when the front-end cannot present a Kerberos-authenticated user identity to Active Directory, but still needs to obtain a Kerberos ticket to a back-end service on that user’s behalf.

Supported real-world cases in the provided material:

Forms-based or other non-Kerberos front ends accessing Kerberos back ends If clients do not always connect with Kerberos, constrained delegation must be set to Use any authentication protocol. The Windows Server guidance states that Use Kerberos only is appropriate only when clients always use Kerberos; if some clients use other methods such as NTLM or forms-based authentication, Use any authentication protocol is required.
Microsoft Entra Application Proxy / Private Network Connector for IWA apps For on-premises applications that use Integrated Windows Authentication behind Application Proxy, the private network connector impersonates the user in Active Directory to obtain a Kerberos token for the application. The documented same-domain KCD configuration explicitly uses Trust this computer for delegation to specified services only together with Use any authentication protocol.
Cross-domain resource-based constrained delegation (RBCD) In cross-domain scenarios, resource-based constrained delegation does not use the older Trusted-to-Authenticate-for-Delegation control in the same way. The KDC always allows protocol transition when performing RBCD as though that bit were set. That makes protocol transition part of the design for these cross-domain delegation patterns.
Front-end access brokers and reverse proxies Microsoft documents front-end services such as ISA Server, Forefront Threat Management Gateway, Exchange Outlook Web Access, and SharePoint Server as practical applications of constrained delegation to authenticate to servers in other domains. These are established examples of front-end services brokering user access to back-end services, which is the class of scenario where protocol transition is relevant when the incoming auth is not Kerberos end to end.
Web Enrollment proxy / similar IIS front ends with mixed client authentication The Windows Server troubleshooting guidance for Web Enrollment explicitly says to select Use any authentication protocol if some clients use authentication methods other than Kerberos, such as NTLM or forms-based authentication. This is a concrete example where switching to Kerberos only would break clients that do not arrive with Kerberos.

What can be concluded for an audit:

Safe candidate for Kerberos only: services where clients are guaranteed to authenticate to the front end with Kerberos every time.
Do not switch to Kerberos only without testing:
- forms-based front ends
- NTLM-accepting front ends
- Entra Application Proxy / private network connector KCD scenarios
- mixed-auth IIS applications
- cross-domain RBCD designs

Security note: delegation increases impersonation risk, and unconstrained delegation is especially risky. Where delegation is needed, constrained delegation or resource-based constrained delegation is the more secure pattern than unconstrained delegation.