Why is Sharepoint Search 2013 Security Trimming not working?

Question

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?

Answer 1

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.

Answer 2

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