This project has moved. For the latest updates, please go here.

Get windows token from claims identity

Nov 9, 2016 at 7:34 AM
Edited Nov 9, 2016 at 7:35 AM
Hello Yvan,

I've faced the strange issue when trying to open Excel file located in SharePoint library using Excel Services.

The error logs are (cropped):

Name=Request (POST:https://reports.XXXX.com:443/_vti_bin/EwaInternalWebService.json/RefreshAll)
WebServiceHelperMethods.ExecuteWebServiceRequestHandler: started processing 'RefreshAll' web method call
ServerSession.ExecuteWebMethodCore: sending request of type RefreshAll, to server=http://XXXXXXX:32843/b3c816b6aab2438caf801a7b5a505800/ExcelService*.asmx, session=1.V23.330s7yxJ0k1j0uIr3+qC9U014.5.en-US5.en-US36.b60b859c-b823-4f96-87c1-0bf53937c8451.A1.N, state id=-1, health score=3.891348E-18, error delta=1.297116E-17

User=0e.t|adfs|sergey_solovyev@XXXX.com
BaseIdentityResolver.SetUserPrincipalForUserRequest: UserPrincipal 0e.t|adfs|sergey_solovyev@XXXX.com successfully set on the thread
Document=https://reports.XXXXXXXX.com/sitecollectiondocuments/delegationtest.xlsx
ExcelServiceBase.BeginProcessOperation: Microsoft.Office.Excel.Server.CalculationServer.Operations.RefreshAllDataConnectionsOperation, WebMethod: RefreshAll is queued on SessionOperationQueue

MossHost.TryGetUserNameFromIdentity: Caught exception. exception: System.ArgumentException: Exception of type 'System.ArgumentException' was thrown. Parameter name: claim at Microsoft.SharePoint.Administration.Claims.SPActiveDirectoryClaimProvider.GetNTAccountFromClaim(SPClaim claim) at Microsoft.Office.Excel.Server.MossHost.MossHost.TryGetUserNameFromIdentity(IIdentity userIdentity, Boolean windowsOnly, String& userName)

MossHost.TryGetWindowsIdentity: Cannot get WindowsIdentity: identity is a Claims identity, but does not have a Windows token.
CredentialsProvider.GetCredentials: Failed to get WindowsIdentity.

Credential delegation failed because Excel Services Application was unable to obtain a Windows Identity. [Session: 1.V23.330s7yxJ0k1j0uIr3+qC9U014.5.en-US5.en-US36.b60b859c-b823-4f96-87c1-0bf53937c8451.A1.N User: 0e.t|adfs|sergey_solovyev@XXXX.com]
MossHost.TryGetWindowsIdentity: Cannot get WindowsIdentity: identity is a Claims identity, but does not have a Windows token.
CredentialsProvider.GetCredentials: Failed to get WindowsIdentity.

Credential delegation failed because Excel Services Application was unable to obtain a Windows Identity. [Session: 1.V23.330s7yxJ0k1j0uIr3+qC9U014.5.en-US5.en-US36.b60b859c-b823-4f96-87c1-0bf53937c8451.A1.N User: 0e.t|adfs|sergey_solovyev@XXXX.com]

SessionUser.EnsureCredentialsForExternalData: Failed to get credentials. User=0e.t|adfs|sergey_solovyev@XXXX.com, ConnectionIndex=1
SessionUser.EnsureCredentialsForExternalData: Failed to get credentials. User=0e.t|adfs|sergey_solovyev@XXXX.com, ConnectionIndex=0


While searching the web i've found that according to Microsoft,

"Windows authentication is required because the Analysis Services data engine in a PowerPivot for SharePoint deployment supports only Windows authentication. Excel Services establishes connections to Analysis Services via the MSOLAP OLE DB provider using a Windows user identity that was authenticated via NTLM or the Kerberos protocol."

However i've seen that some guys are succeeded with this issue by injecting (and later augmenting) additional claims like:
protected override void FillClaimsForEntity(Uricontext,SPClaim entity, List<SPClaim>claims)

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)
Assuming this isn't possible in our case, i have also found that (obviously according to Microsoft) "shadow accounts" can be used to resolve this issue:

"Notice that Claims authentication is not supported. You cannot use a Windows Claims token to access Analysis Services. The Analysis Services client libraries only work with Windows security principles. If your BI solution includes claims identities, you will need Windows identity shadow accounts for each user, or use stored credentials to access Analysis Services data."

Could you please shed some light on this issue?

LDAPCP ver is 3.10
SharePoint 2013 with implemented SSO using AD FS

Thanks,
Sergey
Coordinator
Nov 15, 2016 at 2:20 PM
Hi Sergey,
Business Intelligence is a scenario that doesn't work well with federated authentication, and LDAPCP cannot do much to fix that.
I was not aware of the "workaround" that you mention, which adds some claims to make SharePoint "think" the current user is a Windows user. It seems to me like a dangerous approach since obviously you cheat against the logic of the product, so I'm not going to implement that in LDAPCP.
Regarding the shadow acccount, I think this refers to Secure Store service, and that sounds like the best option to consider, assuming only a small portion of users need to use BI services.
thanks,
Yvan