Unable to configure SQL Reporting Services to use Kerberos

We are trying to enable Kerberos with our SQL Server Reporting Services reports manager website (for ex, instructions in the article "Configure Windows Authentication on the Report Server ") without any success so far, unfortunately. What we've done up to now: - We've used the Kerberos Configuration Manager for SQL Server to ensure things are OK regarding our SQL Server (The SSRS DB is in the default instance, and the reports manager website is also hosted on the same server). This tool shows no errors or problems with delegation - We've created a domain account to run the SSRS service under, and enabled delegation for it in AD - We originally updated the SSRS configuration file's authentication types to look like this: - Though we have also attempted the above config with only the RSWindowsKerberos node under AuthenticationTypes. I agree with J.D in the comments below - this part is confusing, as it appears to say NTLM will be picked if RSWindowsNegotiate is present, yet this link says to include it to enable Kerberos. - And we've created SPNs for our domain account Regarding SPNs, when we've tried to run SSRS under a domain account, we created SPNs using the following setspn commands: setspn -S HTTP/servername.abc.local abc\SsrsSvc setspn -S HTTP/servername abc\SsrsSvc setspn -S HTTP/reports.abc.com abc\SsrsSvc setspn -S HTTP/reports abc\SsrsSvc Some explanation on the above: clearly, the names have been obscured, but if the company domain is "abc", the network admins have set up "abc.local" internally in AD. For the reports manager website, it's publicly accessible via reports.abc.com (ports 443 and 80 - standard http stuff here). Several of the walkthroughs regarding SPNs for SQL and SSRS linked to an article that SqlMag used to host (still viewable here on wayback machine). The issue we're seeing is that only NTLM is being used by any browser connection, and if we force only Kerberos, we see 401s when accessing reports. (Auth headers for NTLM start with "TlR" - and we're clearly seeing that in Fiddler as we examine the requests.) For troubleshooting, we've logged out the User Account Control attribute in the SSRS trace file, and it's 590336 (which, as far as I can tell, is fine). Alternatively, we have also attempted to run SSRS as the Network Service account (which MS docs say won't need SPNs in this case) - but we get the same result. I'm looking for input on what we try next, or on what we've missed. I'd also be curious to know if the SSRS service should be listed in the Kerberos Configuration Manager for SQL Server (in the SPN tab) - as I only see two line items - both for the SQL Server default instance itself (which both show they're OK). This post has a screenshot showing SSRS listed there (under "Examples of the SPN validations" towards the end).