BCS安全修剪与ADFS登录SharePoint 2013不适合我与自定义连接器。通过不工作，我的意思是，当通过windows身份验证登录时，有权访问这些BCS记录的用户可以在搜索中看到它们(这是正确的)。使用ADFS登录的同一用户无法在搜索中看到这些相同的记录(这是不正确的)。
我的设置是在Windows 2012 R2上使用ADFS的SharePoint 2013。一个SQL server数据库正在通过BCS使用一个自定义的。net连接器进行爬行。连接器通过添加acl在爬行时提供安全调整。acl是基于一个AD安全组创建的，该安全组有多个AD用户作为成员(登录用户是其中一个成员)。AD安全组是声明的一部分，显示如下:
<saml:Attribute AttributeName="Group"AttributeNamespace="http://schemas.xmlsoap.org/claims">
<saml:AttributeValue>BCSSecurityGroup1</saml:AttributeValue>
</saml:Attribute>
BCSSecurityGroup1为包含用户的AD安全组。
奇怪的是，即使我允许每个人访问ACL中的这些记录(即使用WellKnownSidType.WorldSid)， ADFS登录仍然没有在搜索中返回这些项目。更奇怪的是，如果我访问有问题的记录的BCS配置文件页面的url, ADFS用户确实有访问权限。
问题在这里。我需要做些什么才能使搜索结果反映在爬行时添加的ACL安全性?
事实证明，这实际上是非常简单的工作。首先，为了进行故障排除，将AD安全组更改为单个AD用户(域用户名)。看看如何在连接器中构建ACL，使用域帐户获取SID，然后使用SID构建ACL。啊哈!因此，缺少的环节是，在AD FS声明中，SID没有被映射。这是通过使用Fiddler插件在检查器选项卡下显示索赔来确定的- http://identitymodel.codeplex.com/releases/view/52187。
在AD FS中添加SID声明作为声明规则完成。从"通过或过滤传入索赔"模板中添加索赔规则。给它一个名称，为Incoming索赔类型选择"Primary SID"，并确保选中"Pass through all claim values"。重新启动AD FS服务以确保安全。此外，这假设SharePoint中的可信身份令牌颁发者是用SID声明映射创建的。
在我的情况下，由于从AD安全组更改回用户名，我不得不在BCS内容源上运行另一次抓取。虽然我还没有对此进行测试，但AD安全组应该以相同的方式工作，但是通过组SID传递。希望这对将来的人有所帮助。干杯!