SP 2010, ADFS 2.0, SSRS 2012 Report Data Source (Windows Auth) and C2WTS Error

Question

I am unable to establish a SSRS 2012 Report Data Source connection to Analysis Services using ADFS 2.0 as the STS Provider. I receive error:

Can not convert claims identity to windows token. This may be due to user not logging in using windows credentials.

In the ULS logs is the following:

08/21/2012 13:21:35.77  w3wp.exe (0x09BC)                        0x2E88 SQL Server Reporting Services  Report Server Web Server       0000 Unexpected Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ClaimsToWindowsTokenLoginTypeException: , Microsoft.ReportingServices.Diagnostics.Utilities.ClaimsToWindowsTokenLoginTypeException: Can not convert claims identity to windows token. This may be due to user not logging in using windows credentials.; 0f663098-054c-4206-8b8a-4d26b96654b6

08/21/2012 13:21:35.77  w3wp.exe (0x09BC)                        0x2E88 SQL Server Reporting Services  Report Server Processing       0000 Unexpected Throwing Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: , Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: Cannot impersonate user for data source ''. ---> Microsoft.ReportingServices.Diagnostics.Utilities.ClaimsToWindowsTokenLoginTypeException: Can not convert claims identity to windows token. This may be due to user not logging in using windows credentials.     --- End of inner exception stack trace ---; 0f663098-054c-4206-8b8a-4d26b96654b6

Specifically I am using the Microsoft BI Semantic Model for Power View as the Data Source Type. I have not tried any other data source types. Using SharePoints Integrated Windows Authentication as the claims provider I am able to establish a connection. I have all of the SPN's setup correctly. I've also ensured the account that SSRS runs under has the same privileges as the C2WTS service as I've read that is a requrement. The C2WTS appears to be working properly. I've ensured that ADFS is passing a valid UPN claim about the logged in user which is all C2WTS should need to get a windows identity. I've tried running C2WTS under both the local network service and also as a domain account. I've tested all three service accounts with the C2WTS tool found here which returns successful. What am I missing?

Any help would be much appreceiated. I've exaushted all of the troubleshooting techniques I've found thus far.

Thanks,

Brett

Answer 1

What version of Analysis Services?  Is this PowerPivot (SP AS) or SQL native AS?

---

http://sharepoint.nauplius.net

Answer 2

It is Analysis Services 2012 in Tabular Mode, SSRS 2012 for SharePoint, not Native.

Answer 3

Looks like it the Semantic BI model requires Classic Auth Web Apps:

http://technet.microsoft.com/en-us/library/hh230972.aspx

"PowerPivot for SharePoint must be accessed via web applications that use classic authentication mode. BI semantic model connections to external data sources have a dependency on classic mode sign-in."

---

http://sharepoint.nauplius.net

Answer 4

I'm not using a BI semantic model data source content type. That content type requires Analysis Services for PowerPivot installed which I know requires classic auth. I am using a Report Data Source content type which only requires SSRS. I can sucessfully make a connection using Claims Auth but only with SharePoint's Integrated Windows authentication as the provider. It's when I try and use ADFS as the Trusted Identity provider that I run into this error.

Answer 5

None the less, AS itself only supports Windows Auth

---

http://sharepoint.nauplius.net

Answer 6

True, but isn't that the whole point of C2WTS? SQL Server doesn't support claims auth either but SSRS should still be able to delegate authentication to it because SSRS support claims auth and uses C2WTS to authenticate to the SQL server. Why should AS or any other windows auth data source be any different?

Answer 7

PowerPivot 2012/InfoPath also do not support Claims :)  The application has to be built for it.

---

http://sharepoint.nauplius.net

Answer 8

Yes, but I am using SSRS 2012 which does support Claims. I am not using PowerPivot 2012 or InfoPath.

Answer 9

But you are using AS which doesn't support claims.

---

http://sharepoint.nauplius.net

Answer 10

I am directly interfacing with SSRS which is claims aware. SSRS, because it's claims aware, is supposed to use the C2WTS to translate the clam to a windows identity anytime access needs to be made to a windows auth data source that doesn't support claims. So from SP I login using a claim. SSRS uses that claim and the C2WTS to translate that into a windows account which it uses to authenticate to the windows service using the identity provided by the C2WTS. SSRS should not use the claim to authenticate to the underlying windows auth data source. If SSRS tries to use the claim to authenticate then that is a bug in SSRS or false advertising on Microsofts part because MS claims SSRS uses C2WTS to translate the claim to a windows identity.

Answer 11

http://msdn.microsoft.com/en-us/library/hh231678

Answer 12

Update:

I tried using Microsoft SQL Server as the Data Source Type after setting up the proper SPN's and privileges and received the same error. When I login using Claims with SharePoint's built in windows auth STS provider it works but when I use ADFS as the provider it fails.

Answer 13

when you setup SharePoint web application as ADFS relying party, does you configure SharePoint to receive a UPN claim emitted by ADFS? please take a look at http://blogs.msdn.com/b/bradleycotier/archive/2012/03/27/adfs-c2wts-identity-impersonation-failure-after-an-iis-reset.aspx

Answer 14

I did not set mapToWindows="true" or useWindowsTokenService="true". I am is using the default settings defined by SharePoint. When I tried using the setting described in that document SharePoint threw an access denied error which in turn threw an excption on the error page itself. I have SharePoint setup to use UPN as the IdentifierClaim:

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\certs\ADFS Signing.cer")
New-SPTrustedRootAuthority -Name "ADFS Token Signing Cert" -Certificate $cert
$map = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" –SameAsIncoming
$map2 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" –SameAsIncoming
$map3 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -IncomingClaimTypeDisplayName "UPN" –SameAsIncoming
$map4 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname" -IncomingClaimTypeDisplayName "Windows Account Name" –SameAsIncoming
$realm = "urn:sp:site"
$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS" -Description "ADFS SAML" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2,$map3,$map4 -SignInUrl "https://adfs.site.com/adfs/ls" -IdentifierClaim "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"

Answer 15

I delved into the code using Reflector and found that SSRS is using SPSecurityContext.GetWindowsIdentity() to retreive the currently logged in user. In that method is the following code block:

if (!SPClaim.EqualClaimValues(claimValueOne, SPIdentityProviderTypes.Windows))
{
    return null;
}

This prevents the GetWindowsIdentity method from ever being able to return a valid windows identity unless you are using SharePoint's built in windows trust provider even if you use another provider that has all of the claims necessary to get a windows identity. WHY???

Answer 16

according to http://blogs.technet.com/b/speschka/archive/2011/08/07/using-saml-claims-sharepoint-wcf-claims-to-windows-token-service-and-constrained-delegation-to-access-sql-server.aspx , there really isn’t a technological reason why you cannot. 

Answer 17

Hi all,

Any updates on this issue? I seem to have the exact same problem trying to use SSRS 2012 to generated reports from a claims-based SP application. I have looked around the web and tried everything suggested to no avail.

Thanks

Answer 18

The code Brett Prucha posted is still there in SPSecurityContext.GetWindowsIdentity() in SharePoint 2013 preview.

I had not done any change impact analysis, but i wonder what if just set the IdentityProvider type claim to Windows for a trusted identity provider.

According to,http://blogs.msdn.com/b/besidethepoint/archive/2012/05/10/ws-federation-authentication-module-wsfam-and-sharepoint-extensions.aspx :

In the PostAuthenticateRequest stage, WSFAM checks if a Claims principal has been properly set on the current HTTP context. If authentication succeeded in the AuthenticateRequest stage some principal will have been set on the context, though this principal could be a Windows or Forms principal and not a Claims principal. In that case, the WSFAM converts them into a Claims Principal at this stage. If no principal has been set (i.e. authentication has not yet succeeded), an anonymous Claims principal is set for the context now. In SharePoint, either a Claims principal should already have been set at this point (if authentication has completed, i.e. during the second pass) or the anonymous principal will be set.

After a proper Claims principal has been set on the context, any custom Claims Authentication Manager configured for the application is called. For SharePoint web applications, no Claims Authentication Manager is configured; however, there is a custom Claims Authentication Manager for service applications. Claims Authentication Managers can modify or augment claims set for the incoming principal, or even entirely replace that principal. This may be a valid extensibility point even in a SharePoint web application; however, a custom ClaimProvider would generally be more appropriate.

Answer 19

for a custom ClaimProvider, the http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.claims.sptrustedclaimprovider.aspx is a sealed class, so, you cannot inherit from it, you may have to inherit http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.claims.spclaimprovider.aspx, in your implementation, you just set identityprovider claim type to Windows, although it is Trusted actually.

for a custom Claims Authentication Manager, here are an example: http://msdn.microsoft.com/en-us/library/hh987036.aspx

Answer 20

By the way, in my test environment, i have configured a web application zone using ADFS v2 as trusted identity provider and enabled ADFS for FBA. But in your production environment, if you already have windows authentication, why do you use ADFS?

Update: http://social.technet.microsoft.com/Forums/en-US/sharepointadmin/thread/b8506466-9072-45f1-9478-28a26bc9b183

Answer 21

Hello

I found a solution !

Obviously there is a need for Kerberos Constrained configuration .

After,  In your custom SPClaimProvider you must do "Claims Augmentation".

in the procedure: protected override void FillClaimsForEntity(Uricontext,SPClaim entity, List<SPClaim>claims)

You must Add 4 new Claims ("eg : Windows").

http://schemas.microsoft.com/sharepoint/2009/08/claims/identityprovider (SecurityTokenService)
http://schemas.microsoft.com/sharepoint/2009/08/claims/userlogonname (Windows)
http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid (Windows)
http://schemas.microsoft.com/sharepoint/2009/08/claims/userid (SecurityTokenService)

Sample :

claims.add(new SPClaim(SPClaimTypes.IdentityProvider, "windows", Microsoft.IdentityModel.Claims.ClaimValueTypes.String, SPOriginalIssuers.Format(SPOriginalIssuerType.SecurityTokenService, AssociatedTrustedLoginProviderName)));

claims.Add(new SPClaim("http://schemas.microsoft.com/sharepoint/2009/08/claims/userlogonname", @"domain\username", Microsoft.IdentityModel.Claims.ClaimValueTypes.String, SPOriginalIssuers.Format(SPOriginalIssuerType.Windows, AssociatedTrustedLoginProviderName)));

claims.Add(new SPClaim("http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", "S-1-5-21-2247756126-2648838247-177963430-1104", Microsoft.IdentityModel.Claims.ClaimValueTypes.String, SPOriginalIssuers.Format(SPOriginalIssuerType.Windows, AssociatedTrustedLoginProviderName)));

claims.Add(new SPClaim("http://schemas.microsoft.com/sharepoint/2009/08/claims/userid", @"0#.w|domain\username", Microsoft.IdentityModel.Claims.ClaimValueTypes.String, SPOriginalIssuers.Format(SPOriginalIssuerType.SecurityTokenService, AssociatedTrustedLoginProviderName)));

With this, no errors on the "Windows" data sources.

It works also with SP2013 

Best Regards