I had an interesting case that was presented to me by our friends in the SharePoint support team. The issue was that when they go to use a Data Source for Reporting Services that is set to use Windows Authentication, they saw the following:
Within the SharePoint ULS logs we see the following:
Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ClaimsToWindowsTokenException: , Microsoft.ReportingServices.Diagnostics.Utilities.ClaimsToWindowsTokenException: Cannot convert claims identity to windows token. ---> System.InvalidOperationException: Could not retrieve a valid Windows identity. ---> System.ServiceModel.Security.SecurityAccessDeniedException: Access is denied. Server stack trace: at System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter) at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOpera... 25d0478e-1e06-4a1d-bf57-2f5a675805ad
Throwing Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: , Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: Cannot impersonate user for data source 'AdventureWorks2012.rsds'. ---> Microsoft.ReportingServices.Diagnostics.Utilities.ClaimsToWindowsTokenException: Cannot convert claims identity to windows token. ---> System.InvalidOperationException: Could not retrieve a valid Windows identity. ---> System.ServiceModel.Security.SecurityAccessDeniedException: Access is denied. Server stack trace: at System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter) at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOpera... 25d0478e-1e06-4a1d-bf57-2f5a675805ad
Claims Authentication bz7l Medium SPSecurityContext.WindowsIdentity: Could not retrieve a valid windows identity for NTName='CYLONS\numberone', UPN='NumberOne@cylons.local'. UPN is required when Kerberos constrained delegation is used. Exception: System.ServiceModel.Security.SecurityAccessDeniedException: Access is denied. Server stack trace: at System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter) at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout) at System.ServiceModel.C... 25d0478e-1e06-4a1d-bf57-2f5a675805ad
Of note, we have a One Way Transitive Trust setup between the BATTLESTAR domain, where the Windows Services reside, and CYLONS domain where the users reside.
My initial reaction to this was that this would not work. My thinking was that because the Claims to Windows Token Services (C2WTS) would be making the call to Logon the User to get the Windows Credential and due to Constrained Delegation that would not end up being successful.
To help try and validate that, I enabled Kerberos Event Logging, did an IISReset and restarted the C2WTS Windows Service. I then saw the following in the Event Log:
A Kerberos Error Message was received:
on logon session BATTLESTAR.LOCAL\claimsservice
Client Time:
Server Time: 17:59:46.0000 8/20/2012 Z
Error Code: 0x44 KDC_ERR_WRONG_REALM
Extended Error:
Client Realm: CYLONS.LOCAL
Client Name:
Server Realm: BATTLESTAR.LOCAL
Server Name: krbtgt/BATTLESTAR.LOCAL
Target Name: krbtgt/BATTLESTAR.LOCAL@BATTLESTAR.LOCAL
Error Text:
File: e
Line: 9fe
Error Data is in record data.A Kerberos Error Message was received:
on logon session
Client Time:
Server Time: 17:59:46.0000 8/20/2012 Z
Error Code: 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN
Extended Error:
Client Realm:
Client Name:
Server Realm: BATTLESTAR.LOCAL
Server Name: krbtgt/CYLONS.LOCAL
Target Name: krbtgt/CYLONS.LOCAL@BATTLESTAR.LOCAL
Error Text:
File: 9
Line: f09
Error Data is in record data.
The KDC_ERR_WRONG_REALM indicates that we failed when trying to call the Client Realm (CYLONS.LOCAL). Then the overall login failed with KDC_ERR_S_PRINCIPAL_UNKNOWN.
One question that came up was whether this would work with a Two Way Transitive Trust or not. Based on my original assumption, my thought was no. But I wanted to validate that as well. So, I reconfigured my domains for a Two Way Transitive Trust and what do you know? It worked!
So, this wasn’t a case of Constrained Delegation really. It was just a Trust relationship issue, and for Kerberos to work properly in the this scenario, we have to have a Two Way Transitive Trust.
Adam W. Saxton | Microsoft Escalation Services
https://twitter.com/awsaxton