Scenario:
You configure Office Online Server with SharePoint 2013 or SharePoint 2016 and have configured Kerberos Constrained Delegation to a data warehouse to pull business intelligence data for your users. You have two Active Directory domains in separate forests in a 2-way transitive trust configuration (We will call them DomainA in Forest 1 and DomainB in Forest 2). The SharePoint farm, data source and Office Online Server sit in Domain A, while only a specific set of users reside in Domain B. Users have no issues logging into the site and interacting with SharePoint.
Users that sit in DomainA configure Excel workbooks and are able to load them into SharePoint, render them in the browser and refresh without any issues. This proves KCD is working. Users from DomainB come over to the SharePoint site and attempt to refresh the same workbooks and receive the following failure:
“The data connection uses Windows Authentication and user credentials could not be delegated. The following connections failed to refresh: XXXXXXXX”
The first assumption is that there is an issue communicating between domains because we have proven that the KCD is functional. You may have also found that this worked (or still works) with Excel Services in SharePoint 2013. Unfortunately, this is not the case. You will find (through multiple means) that you can query users from the trusted domain without issues.
Digging Deeper:
If you dig deeper into this issue and pull Office Online Server logs, you will see the following chain in this scenario:
11/04/2016 11:25:38.51 w3wp.exe (0x4D94) 0x193C Excel Online Excel Calculation Services 6k5r Verbose CredentialsProvider.GetCredentials: Getting credentials for external source: EXAMPLEDATASOURCE, with CredentialsMethod Integrated
11/04/2016 11:25:38.51 w3wp.exe (0x4D94) 0x193C Excel Online Excel Calculation Services a2pb1 Verbose CredentialsProvider.TranslateSid: Trying to translate SID: s-1-0-00-000000000-0000000000-0000000000-0000
11/04/2016 11:25:38.79 w3wp.exe (0x4D94) 0x193C Excel Online Excel Calculation Services a2pb2 Verbose CredentialsProvider.TranslateSid: Searching domain: DomainA.lab
11/04/2016 11:25:38.79 w3wp.exe (0x4D94) 0x193C Excel Online Excel Calculation Services a2pb2 Verbose CredentialsProvider.TranslateSid: Searching domain: DomainA.lab
11/04/2016 11:25:38.79 w3wp.exe (0x4D94) 0x193C Excel Online Excel Calculation Services a2pb4 Medium CredentialsProvider.TranslateSid: SID not found on any domain
The above causes this:
11/04/2016 11:25:38.79 w3wp.exe (0x4D94) 0x193C Excel Online Excel Calculation Services a1tj8 Medium CredentialsProvider.TranslateSidToUpn translation elapsed 285ms
11/04/2016 11:25:38.79 w3wp.exe (0x4D94) 0x193C Excel Online Excel Calculation Services a1tj0 Verbose CredentialsDelegation.UpnLogon: upn is null (ok on DataCenter)
Thus, causing the Windows Identity Translation to fail:
11/04/2016 11:25:38.79 w3wp.exe (0x4D94) 0x193C Excel Online Excel Calculation Services c9la Medium CredentialsProvider.GetCredentials: Failed to get WindowsIdentity.
11/04/2016 11:25:38.79 w3wp.exe (0x4D94) 0x193C Services Infrastructure Services Infrastructure Logging ai2vt Verbose An event was fired: id: NoIntegratedConnectionsAllowed, eventId: 5252, eventType: Warning, eventMessage: Credential delegation failed because Excel Services Application was unable to obtain a Windows Identity. [Session: <<TRUNCATED>> User: i:0#.w|domainbuser1]
11/04/2016 11:25:38.81 w3wp.exe (0x4D94) 0x193C Excel Online Excel Calculation Services oyyh Verbose CredentialsProvider.ProcessCancel: Processing cancel of the credentials for external source with data connection name: EXAMPLEDATASOURCE
11/04/2016 11:25:38.81 w3wp.exe (0x4D94) 0x193C Excel Online Excel Calculation Services ajhkx Medium SessionUser.EnsureCredentialsForExternalData: Failed to get credentials. User=i:0#.w|domainbuser1, ConnectionIndex=0
You will also notice that there are no calls to the other forest from the Office Online server in network traces (at least in relation to this stack).
Diagnosis and Workarounds:
To perform any data refresh action, Office Online Server requires the Windows Identity of the user which is gathered by the Claims to Windows Token Service. You will notice in the logs above that Office Online Server did not even try to query DomainB. The product team confirmed that this is a product limitation. At the moment, Office Online Server will only attempt to query domains located within the same forest as itself.
From the domain level, you can workaround this issue by moving both domains into the same forest. From the Excel Online level, you can refresh data using the Secure Store instead of the Authenticated Users account. This will effectively bypass the need for Office Online Server to retrieve user credentials from the other domain.
NOTE: This post is specific to Office Online Server on-premise and does not reflect on or speak to the capabilities of Office Online, Office 365 or SharePoint Online.