Step 1. Check requirements
Make sure the Windows File Servers you want to monitor meet the requirements listed in the Supported Data Sources section.
Step 2. Decide on audit data to collect
- Review the list of objects and attributes that can be monitored by Netwrix Auditor: Actions, Object Types and Attributes Monitored on File Servers.
- Plan for the file servers and shares you want to audit. Consider the following:
- If you have multiple file shares frequently accessed by a significant number of users, it is reasonable to audit object changes only. Tracking all events may result in too much data written to the audit logs, whereas only some part of it may be of any interest.
NOTE: Audit flags must be set on every file share you want to audit.
- If your file shares are stored within one folder (or disk drive), you can configure audit settings for this folder only. As a result, you will receive reports on all required access types applied to all file shares within this folder.
NOTE: It is not recommended to configure audit settings for system disks.
- By default, Netwrix Auditor will monitor all shares stored in the specified location, except for hidden shares (both default and user-defined). If you want to monitor user-defined hidden shares, select the related option in the monitored item settings. See Add Items for Monitoring for more information.
NOTE: Administrative hidden shares like default system root or Windows directory (ADMIN$), default drive shares (D$, E$), etc. will not be monitored.
The following considerations and limitations refer to data collection:
- To collect data from 32-bit operating systems, network traffic compression must be disabled.
- To collect data from Windows Failover Cluster, network traffic compression must be enabled.
- Scale-Out File Server (SOFS) cluster is not supported.
- Several constraints apply to DFS auditing. See the DFS-related constraints section below.
The following considerations and limitations refer to reporting:
- For Windows File Servers running Windows Server 2008, changes to the file shares will be reported without exact initiator's account in the who field— instead, system is reported.
- If a file server is running Windows Server 2008 SP2, Netwrix Auditor may be unable to retrieve workstation name for the failed read attempts.
- In the reports and search results, Netwrix Auditor displays not the actual time when the event occurred but data collection time.
- Netwrix Auditor may report on several unexpected changes with who (initiator's account) reported as system due to the native Windows File Servers audit peculiarities. If you do not want to see these changes, exclude them from the audit. See Fine-tune File Servers Monitoring Scope for more information.
- Due to Windows limitations, the copy/rename/move actions on remote file shares may be reported as two sequential actions: copying – as adding a new file and reading the initial file; renaming/moving – as removing the initial file and adding a new file with the same name.
- To report on copy actions on remote file shares, make sure that audit of successful read operations is enabled. See Configure Object-Level Access Auditing for details.
If planning to audit DFS files and folders, mind the following:
- Netwrix Auditor supports auditing of DFS and clustered file servers if Object Access Auditing is enabled on DFS file shares or on every cluster node.
- When adding a cluster file server for auditing, it is recommended to specify a server name of the Role server or a UNC path of the shared folder located on the Role server.
- When adding a DFS file share for auditing, specify a Windows file share item and provide the UNC path of the whole namespace or UNC path of the DFS link (folder). For example:
- "\\domain\dfsnamespace\" (domain-based namespace)
- "\\server\dfsnamespace\" (in case of stand-alone namespace);
- Auditing of files and folders placed directly into the DFS namespace root is not supported, as such configuration is not recommended by Microsoft. See Placing files directly in the namespace share section of the Microsoft article for details. Make sure the UNC path of a shared folder is placed under the DFS folders.
- For recommendations on configuring DFS replication, refer to this Knowledge Base article. Remember that replication of namespace roots is not supported.
NOTE: If your Netwrix Auditor version is earlier than 9.9, consider that DFS namespace processing logic differs from the current (implemented in line with Microsoft recommendations).
Step 4. Apply required audit settings
Depending on your auditing requirements, you may need to audit your file server objects for:
- Successful read attempts
- Successful modifications
- Failed read and modification attempts
- Failed modification attempts
For that, object-level audit settings and appropriate audit policies should be set up. Besides, the following should be configured for your Windows file servers:
- Windows Event log size and retention settings
- Remote registry service
- Inbound connection rules for Windows firewall
You can apply required audit settings to your Windows file servers in one of the following ways:
Automatically when creating a monitoring plan
In this case, the audit settings will be applied automatically, then they will be periodically checked and adjusted if necessary. See Settings for Data Collection for more information.
Manually. To configure your Windows File Servers for monitoring manually, perform the following procedures:
NOTE: With automatically applied settings, initial SACL configuration for DFS replication links may take longer than with manual configuration — however, automatic configuration will help to minimize the impact on the DFS backlog and replication process in general.
Step 5. Configure Data Collecting Account
Follow the instructions in the Data Collecting Account section.
Step 6. Configure required protocols and ports
Set up protocols and ports as described in the Protocols and Ports Required for Monitoring File Servers section.
File Servers and Antivirus
It is strongly recommended that you add the following executables to the list of exclusions for your antivirus:
Otherwise, significant delays and performance issues may occur while collecting data.
This happens because these executables access a large number of file server objects (files, folders), fetching audit data — and your antivirus may treat this as a suspicious behavior.
NOTE: For some antiviruses (for example, Trend Micro) you may need to specify the folders to exclude, that is, C:\Windows\SysWOW64\NwxExeSvc\. Refer to your antivirus documentation for details.