Very recently, we’ve had an abundant amount of issues around environments using unconstrained delegations failing. What is unconstrained delegations you might ask? It’s what we call “Full Trust” delegations, and my former Escalation Engineer nicely details the differences between constrained delegations and unconstrained delegations in his post My Kerberos Checklist.


Consider the scenario:

You are using unconstrained delegations for your Reporting Services environment, and users on Windows 8 and older machines are able to connect to your Report Manager URL, and run their reports using Windows Authentication connecting to a back-end data source (SQL, for example). When a user on a Windows 10 machine tries to run the same report (it could be the same user as the one tested on Win8), it would fail. The error we were getting when we tested the report data source connection is ‘NT AUTHORITY\ANONYMOUS LOGON’. I won’t go into too much details about this error as it’s easily searchable, but what this means is that either:

1. We’ve failed to login to Report Server with Kerberos, hence failed to NTLM.
2. The Report Server Service Account is not able to delegate to the back-end service, and/or the back-end service does not have an SPN.


Initially, we were seeing that the second-hop between Report Server and a back-end database was failing. We could tell from network traces that we were authenticated to the Report Server with a Kerberos token, and also can confirm that we can connect to the back-end database with Kerberos. A simple query I’ve always used when verifying Kerberos authentication with SQL Server using SSMS (or your tool of choice) is:

SELECT * FROM sys.dm_exec_connections WHERE session_id = @@SPID

The auth_scheme column will tell you whether you are connected via NTLM or Kerberos.

Since we know that both Reporting Service and SQL Server is connectable with Kerberos, the only explanation is that Reporting Services was not able to delegate to SQL.

We turned on Kerberos Event Logging and took Kerberos ETW traces. Kerberos Event Logging shows the error, “KDC_ERR_BADOPTION”. This represents a constrained delegation error, which is odd because our environment is setup for unconstrained “Full Trust” delegations. Furthermore, looking at the Kerberos ETW traces, we are seeing S4U2Proxy being called. This means that Reporting Services is trying to call constrained delegations to the KDC, but we’re obviously going to fail because we’re not setup for constrained delegations. So what was breaking our Kerberos configuration?

Cause

It turns out Credential Guard was the issue. As per our documentation, https://docs.microsoft.com/en-us/windows/access-protection/credential-guard/credential-guard-requirements:


Solution

You have 2 options:

1. Disable Credential Guard.
2. Configure constrained delegations for Reporting Services.