Sep 12, 2014 at 11:21 AM
Hi Guys,

I'm trying to get ADFS working with SSRS via C2WTS and I'm requiring to create a custom claims provider, however with using LDAPCP I'm struggling to see how this can be achieved 'out of the box' and might require some custom code?

following this discussion: http://social.technet.microsoft.com/Forums/office/en-US/c1ae8cb0-fa39-4b7d-bb09-62e2a9e04bda/sp-2010-adfs-20-ssrs-2012-report-data-source-windows-auth-and-c2wts-error?forum=sharepointgeneralprevious

I am trying to stick in the Claim Argument below:

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)

Suggested Code:
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)));
Can this be achieved via some specific claims mapping?

Any help would be much appreciated.

Sep 12, 2014 at 11:54 AM
about LDAPCP, it is not initially designed to make claims augmentation (what you want to achieve), but you can do this by setting property SupportsEntityInformation to true and override method FillClaimsForEntity.
But about your need, it is not possible (supported) to use SAML (ADFS) authentication with SSRS, SharePoint doesn't allow that.
The solution you found may actually work, but this is a hack because you make SharePoint "think" that current user is a Windows user (so it will call C2WTS to get a Kerberos token for the current "Windows" user).
But you need to understand that this is absolutely not supported and despite it might work, it may cause very bad side effects, so I strongly discourage you to do so.
The only supported option is Windows claims (SSRS 2008 R2 only supported Windows classic).
Sep 12, 2014 at 12:07 PM
That is the first time I have read about it being directly "unsupported".

SSRS in 2012 supports Claims.

This is the only solution I have found that will allow C2WTS to function via ADFS.

but you can do this by setting property SupportsEntityInformation to true and override method FillClaimsForEntity.
How would I go about doing this?

Sep 15, 2014 at 11:34 AM
Look at the proposed "solution": it adds claims that SharePoint would only add for Windows claims users. Do you think those claims make sense for a SAML user? Don't you think it may generate bad side effects like SharePoint being confused with actual identity of the user?
I say it again, this is absolutely not supported. SSRS 2012 only supports Windows claims (SSRS 2008 R2 only supported Windows classic).

With that said, to achieve augmentation with LDAPCP, you need to download package "LDAPCP for Developers" and inherit the class (based on the samples).
From there you'll be able to override method FillClaimsForEntity and set property SupportsEntityInformation.
But this is something I never tried though.
Oct 13, 2014 at 5:59 PM
Background: I just finished setting up a test farm, with SSRS 2012 SP1, SharePoint 2013 SP1, August CU, with a single trusted identity provider (AD FS 3.0) (e.g. I removed the Window Auth, so all users authenticate via ADFS 3.0). We have multiple forests with trusts set up, and it is accessible externally via the ADFS Web App Proxy in the DMZ.

The point of my project is to allow ADFS authenticated users to run SSRS reports, and I was planning on implementing ldapcp so that my people picker controls are usable, when I saw this thread about SSRS not supporting SAML claims.

Unless I'm missing something (entirely possible, as this is the first time I've set something like this up), it appears to me that SSRS does in fact support SAML claims. That is, I can connect remotely, and run an SSRS report as an ADFS 3.0 authenticated user.

In the release notes for SSRS 2012 SP1 ( http://technet.microsoft.com/en-us/library/ms170438(SQL.110).aspx#bkmk_sharepoint ) there is a statement: "The new Reporting Services service applications support Claims based authentication." While it doesn't explicitly say only Windows claims are supported, it seems to imply that SSRS supports whatever claims auth you have SharePoint set up for.

So I'm wondering if the fact that SSRS doesn't support SAML claims was fixed in SP1? Or, am I going to run into weird problems somewhere?

Mike Sharp
Oct 13, 2014 at 11:37 PM
Well, after reading some more on this, I think what is not supported is the case where the user's claims are passed through to the data source. So if my data sources are all using a static account, then there's no problem, right?

Mike Sharp
Oct 14, 2014 at 10:52 AM
SSRS 2010 introduced the supportability of Windows Claims (SSRS 2008 R2 only supports Windows classic), but federated scenarios (ADFS authN) are not supported, whatever the version of SharePoint/SSRS is.
But yes, there are workarounds:
  • Specify an unattended account (in the data source) that will be used by everyone.
  • Explicitely ask for credentials when users load the report, that SSRS will use to connect to the datasource.
    The "workaround" suggested above (make SharePoint "think" that current user is a Windows user by augmenting him with Windows claims) is not supported.