0

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?

Improve this question

2 Answers 2

Reset to default
0

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

Improve this answer
1
  • Thank you for the reply.On the dfs server is this group policy not set for the crawl account, but we don't have the error message The crawl account did not have sufficient privileges to access the security attributes of this file or folder. Ensure the crawl account has the 'Manage auditing and security log' privilege.. Since i'm not the dfs admin and the security trimming is now working, i don't want to change it.
    – Daniel Weiss
    Commented May 19, 2016 at 14:07
0

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.

Improve this answer
3
  • You should add a server name mapping for the drive so the end users see results with the DFS name.
    – Matthew McDermott
    Commented May 20, 2016 at 13:00
  • The path \\\\mydomain\groups\group1 is the path the users usually see in the Windows Explorer, so a Server Name mapping is not necessary for us. We had this path configured at first for the crawler some weeks ago. Because of temporary issues reaching the \\\\mydomain-Path from the demilitarized SharePoint Zone, i erroneously configured the crawl path directly to the share \\dfs1.mydomain. For me it is a little bit problematic, that SharePoint gives anonymous access to everbody, when the ACLs of a fileshare cannot be read correctly.
    – Daniel Weiss
    Commented May 23, 2016 at 7:44
  • I always use the local share rather than the DNS name. I have never seen the issue you describe about permissions.
    – Matthew McDermott
    Commented May 23, 2016 at 11:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.