Discover Scans do not show access information (ACL) or owner

book

Article ID: 159556

calendar_today

Updated On:

Products

Data Loss Prevention Network Discover

Issue/Introduction

When the FQDN (fully qualified domain name 'server.company.com' ) is used as a scan target name, the ACL is not retreived from a DFS share.

FQDN => owner is retrieved, but no ACL

Resolution

As a workaround you can use the NetBIOS name ( 'server_name' ) instead of the FQDN ( 'servername.company.com' ).

FQDN => owner is retrieved, but no ACL
NetBIOS => owner is retrieved as well as ACL

This is related to whether the file server is able to determine if the calling machine is within the domain or not.   This scenario is touched on in MS KB http://support.microsoft.com/kb/816818.

An issue has also been discovered with DFS where it can not resolve the owner or ACL. The native call LookupAccountSid fails with the error: "The RPC server is unavailable". This call is trying to resolve the SID on the DFS server host, so it doesn't seems that there's anything specific to DFS but a general behavior when the SID can not be resolved. This might tie into the MS KB mentioned above. As reference Etrack-1386264 and Etrack-1310001 are tracking this issue

In case both approaches fail ( NetBIOS vs. FQDN) you can also set where the SID gets resolved (Discover Server or the actual File Server).

On the Discover Server go to Vontu\Protect\config\Crawler.properties and modify the setting from

# Should the SID be resolved on the discover server ?
filesystemcrawler.localusernamelookup = false

To

# Should the SID be resolved on the discover server ?
filesystemcrawler.localusernamelookup = true

If the setting is set to false, the ACL and owner information is retrieved from the share ( = File Server ).  If it is set to true the Discover server will try to resolve the information.