2

BCS Security trimming with an ADFS login to SharePoint 2013 is not working for me with a custom connector. By not working I mean that when logged in via windows authentication, a user that has access to these BCS records can see them in search (this is correct). The same user logged in with ADFS cannot see these same records in search (this is not correct).

The setup I have is SharePoint 2013 on Windows 2012 R2 with ADFS. A SQL server database is being crawled via BCS with a custom .NET connector. The connector provides security trimming at crawl time by adding ACLs. The ACLs are created based on an AD Security Group that has a number of AD users as members (the logged in user is one of these members). The AD Security group is included as part of the claim and shows up as follows:

<saml:Attribute AttributeName="Group"AttributeNamespace="http://schemas.xmlsoap.org/claims">
    <saml:AttributeValue>BCSSecurityGroup1</saml:AttributeValue>
</saml:Attribute>

BCSSecurityGroup1 is the AD Security Group that contains the users.

The odd thing is that even if I give everyone access to these records within the ACL (i.e. using WellKnownSidType.WorldSid), the ADFS logins still do not get these items returned in search. Even stranger is that if I go to the url for the BCS profile page for the record(s) in question, the ADFS user does have access.

Here is the question. What do I need to do to have search results reflect the ACL added security at crawl time?

user3821609
  • 31
  • 3

1 Answers1

1

As it turns out, this is actually pretty straightforward to get working. First, the AD Security Group was changed to individual AD users for troubleshooting purposes (domain\username). Looking at how the ACL is built in the connector, the domain account is used to get the SID, and the SID is then used to build the ACL. Ah ha! so the missing link is that with the AD FS claim, the SID is not being mapped. This was determined by using the Fiddler plugin to show claims under the inspector tab - http://identitymodel.codeplex.com/releases/view/52187.

Adding the SID claim in AD FS is done as a claim rule. Add a claim rule from the "Pass Through or Filter an Incoming Claim" template. Give it a name, select "Primary SID" for the Incoming claim type, and ensure that "Pass through all claim values" is selected. Restart the AD FS service for peace of mind. Also, this assumes that the Trusted Identity Token Issuer in SharePoint was created with a SID claims mapping.

In my case, I had to run another crawl on the BCS content source due to changing back to user names from AD security groups. Although I have not yet tested this, AD security groups should work the same way, but by passing through the Group SID. Hope this helps someone in the future. Cheers!

user3821609
  • 31
  • 3