Why is Sharepoint Search 2013 Security Trimming not working?
-
09-10-2020 - |
質問
We have two fileshares (homedrive and a group drive) on a Microsoft Distributed File System based on Windows Server 2012R2 which are crawled with two content sources (with the default crawl account SP_Crawler).
The SharePoint Search 2013 shows the results of the group drive to users who should not have access to it. Results for homedrives are shown correctly.
I have activated verbose monitoring for the search components and discovered in the ULS logs that the crawler on the group drive cannot find or convert ACLs:
ULS logs for the group drive:
Microsoft.Ceres.ContentEngine.Processing.BuiltIn.MsPermissionProducer :Security MsPermission=
Microsoft.Ceres.ContentEngine.Processing.BuiltIn.ClaimsConverterProducer : DecodeSpAcl SpAclBytes is null
Microsoft.Ceres.ContentEngine.Processing.BuiltIn.ClaimsConverterProducer : GrantAllAccess ACL and anonymous claim.
Microsoft.Ceres.ContentEngine.Processing.BuiltIn.ClaimsConverterProducer : Security ClaimsConverter='all b10XXXXXXXXXXXXXXXXXXXXXq'
PS K:\> Get-Acl .\wget.exe | format-list
Path : Microsoft.PowerShell.Core\FileSystem::K:\wget.exe
Owner : VORDEFINIERT\Administratoren
Group : ZZZ\Domain Users
Access : ZZZ\OU_Data-ZZ Allow Modify, Synchronize
VORDEFINIERT\Administratoren Allow FullControl
ZZZ\SPPS_Search Allow ReadAndExecute, Synchronize
ZZZ\SP_Crawler Allow ReadAndExecute, Synchronize
Audit :
Sddl : O:BAG:DUD:AI(A;ID;0x1301bf;;;S-1-5-21-XXXXXX-8946)(A;ID;FA;;;BA)(A;ID;0x1200a9;;;S-1-
5-21-XXXXXX-9790)(A;ID;0x1200a9;;;S-1-5-21-XXXXXX-15005)
while the homedrive is crawled properly
ULS logs for the homedrive:
Microsoft.Ceres.ContentEngine.Processing.BuiltIn.MsPermissionProducer : Security MsPermission=waeXXXXXXXXXXXXXXXXXXXXX4hiaaa waeXXXXXXXXXXXXXXXXXXXXXcetcaaaa waeXXXXXXXXXXXXXXXXXXXXXwayaaa waeXXXXXXXXXXXXXXXXXXXXXhuaeaaa[...]
Microsoft.Ceres.ContentEngine.Processing.BuiltIn.ClaimsConverterProducer : DecodeSpAcl SpAclBytes is null
Microsoft.Ceres.ContentEngine.Processing.BuiltIn.ClaimsConverterProducer : Security ClaimsConverter= waeXXXXXXXXXXXXXXXXXXXXX4hiaaa waeXXXXXXXXXXXXXXXXXXXXXcetcaaaa waeXXXXXXXXXXXXXXXXXXXXXwayaaa waeXXXXXXXXXXXXXXXXXXXXXhuaeaaa[...]'
PS H:\> get-acl personalfile.pdf| format-list
Path : Microsoft.PowerShell.Core\FileSystem::H:\personalfile.pdf
Owner : ZZZ\theuser
Group : ZZZ\Domain Users
Access : ZZZ\SP_Crawler Allow ReadAndExecute, Synchronize
ZZZ\theuser Allow FullControl
VORDEFINIERT\Administratoren Allow FullControl
Audit :
Sddl : O:S-1-5-21- XXXXXX 4-4243G:DUD:AI(A;ID;0x1200a9;;;S-1-5-21- XXXXXX -15005)(A;ID;FA;;;S-1-5-21- XXXXXX -4243)(A;ID;FA;;;BA)
Has anybody a hint how i can further investigate the cause for this?
解決 2
We found the solution.
The group drive with the wrong ACL resolution has been crawled directly on the fileshare (\\dfs1.mydomain\group1), while the homedrive has been crawled from a dfs share (\\mydomain\homes\user1).
When i changed the startaddress for the group drive from \\dfs1.mydomain\group1 to \\mydomain\groups\group1 the ACLs were correctly processed.
他のヒント
Did you grant the Crawl account "Manage auditing and security log" on the WIndows 2012 R2 file server? https://support.microsoft.com/en-us/kb/2817731