Home > Storage > PowerScale (Isilon) > Product Documentation > Protocols > Dell PowerScale: Solution Design and Considerations for SMB Environments > SMB administration
This section discusses the considerations and common practices dealing with SMB security, management, and administration using PowerScale OneFS.
By default, the /ifs root directory is configured as an unrestricted SMB share in the system access zone with unlimited access for the Everyone account.
PowerScale cluster administrators must consider whether these configurations are suitable for their deployment and manage the security implications appropriately. It is recommended that you remove this share after initial PowerScale cluster configuration.
A role is a collection of OneFS privileges that are granted to members of that role as they log in to the cluster. Role-Based Access Control (RBAC) allows delegating specific administration tasks to users.
It is recommended to assign the following privileges for SMB administrators using RBAC:
Once the role and the privileges are set up, you can add members to it. Members can be any users from authentication providers such as AD, LDAP or NIS.
For other general considerations for RBAC, see OneFS Security Configuration Guide.
SMB signing can prevent man-in-the middle attacks within the SMB protocol. However, it will introduce performance degradation which can vary widely depending on the network and storage system implementation. Actual performance degradation can be verified only through tests in the real environment. See The Basics of SMB Signing for more details.
If SMB signing is desired, consider the following two aspects:
Enabling or disabling this feature requires two steps, one on the PowerScale side and the other on the client side. See OneFS: SMB Security Signatures for the detailed steps if the client is Windows.
For MAC OS X clients to access PowerScale data using SMB protocol, this setting is controlled with the dsconfigad –packetsign command.
You can audit SMB protocol access on a per-access zone basis and optionally forward the generated events to the Common Event Enabler (CEE) for export to third-party products. See OneFS File System Auditing with Dell PowerScale and Dell Common Event Enabler for a complete list of supported third-party products that can be used in CEE.
Because each audited event consumes system resources, it is recommended that you only configure audit zones for events that are needed by your auditing application.
Before OneFS 8, in the scenario when auditing feature is turned on and many operations for SMB workflow have been audited, SMB performance will be degraded. There may be no high CPU/memory/disk usage symptom, but SMB statistics response time shows slowness. For this case, it is recommended to open a support ticket to Dell Support. In OneFS 8, the values are set correctly by default.
OneFS leverages third-party antivirus software for file scanning. It sends files through Internet Content Adaptation Protocol (ICAP) to a server running third-party antivirus scanning software. These servers are referred to as ICAP servers. ICAP servers scan files for viruses.
There are two high level configurations and the considerations for file scanning as the followings.
On-access scanning
You can configure OneFS to send files to be scanned before they are opened, after they are closed, or both. The general common practice is to enable scan of files on close. It is recommended that you have at least one ICAP server for each node in the cluster. If those ICAP servers are unable to keep up with the workload on the cluster, more ICAP servers will need to be added. It is not uncommon for busy clusters to have two ICAP servers per node or more.
If OneFS is configured to ensure that files are scanned after they are closed, when a user creates or modifies a file on the cluster, OneFS queues the file to be scanned. OneFS then sends the file to an ICAP server to be scanned when convenient. In this configuration, users can always access files without any delay and this is the most prevalent implementation.
However, it is possible that after a user modifies or creates a file, a second user might access the file before the file is scanned. If a virus was introduced to the file from the first user, the second user can access the infected file.
If OneFS ensures that files are scanned before they are opened, when a user attempts to download a file from the cluster, OneFS first sends the file to an ICAP server to be scanned. The file is not sent to the user until the scan is complete. Scanning files before they are opened is more secure than scanning files after they are closed, because users can access only scanned files. However, scanning files before they are opened requires users to wait for files to be scanned, which affects the performance of the PowerScale cluster. For this reason, scan on open is not widely used on large busy PowerScale clusters.
If you configure OneFS to ensure that files are scanned before they are opened, it is recommended that you also configure OneFS to ensure that files are scanned after they are closed. Scanning files as they are both opened and closed will not necessarily improve security, but it will usually improve data availability when compared to scanning files only when they are opened. If a user wants to access a file, the file may have already been scanned after the file was last modified and will not need to be scanned again if the ICAP server database has not been updated since the last scan. Scanning on both open and close usually comes with a high-performance penalty and requires many more ICAP servers to be deployed. For this reason, scanning on both open and close is not widely used.
Policy scanning
Antivirus policies can be run manually at any time or configured to run according to a schedule, and they target a specific directory on the cluster. In order to have minimum performance impact, it is recommended to schedule the scanning during off-peak or off-duty hours based on the business requirements.
By leveraging this policy, it is recommended to have at least two ICAP servers per cluster. The number of ICAP servers required really depends on how virus scanning is configured, the amount of data a cluster processes and the processing power of the ICAP servers.
Pre-check and reconfigure unsupported SMB settings
Ensure that SMB settings on the cluster are supported by the version of OneFS to which you are upgrading.
If the SMB settings on the cluster are not supported by the version of OneFS to which you are upgrading, the upgrade might fail. Run the upgrade compatibility check utility to confirm whether your current settings are supported.
The upgrade compatibility check utility is included in the OneFS installation package. Start the upgrade compatibility check utility by running the following command, where <install-image-path> is the file path of the upgrade install image.
#isi upgrade cluster assess <install-image-path>
If the upgrade compatibility check utility detects unsupported SMB settings, remove or modify the unsupported SMB settings through the command-line interface or web administration interface before you upgrade. If you are upgrading from OneFS 6.0 or OneFS 5.5, remove or modify the settings by editing the /etc/mcp/override/smbd.xml file or the /etc/mcp/override/smbd_shares.xml file. After you modify your SMB settings, test the workflow.
Backup custom SMB settings
Most settings are preserved during OneFS upgrade. However, some customer settings might not be preserved. Backing up custom settings enables you to reapply any settings that are not preserved during the upgrade process.
The following setting shown in Table 6 is related to SMB and recommended to be backed up by dumping the setting into a text file before upgrading.
Setting | Description | Recommendation |
SMB audit logging | You have custom SMB logging settings configured | If you are upgrading from OneFS 7.0, you must reconfigure SMB audit logging based on the settings you have backed up. |
Configuration changes during a rolling upgrade
You can continue to manage data and can modify some cluster configurations during a rolling upgrade, when you absolutely have to. For example, you can modify SMB shares. However, you can only make configuration changes from a node that has not yet been upgraded. If you attempt to make configuration changes from an upgraded node, the changes will not take effect.
Client connections during rolling upgrades
SMB is a stateful protocol which means it maintains a session state for all the open files in the PowerScale node where the client connects. This session state is not shared across the nodes. For a stateful protocol like SMB, it is recommended to use static IP pools. When a node reboots during the rolling upgrades, the static IP on that node is not accessible and SMB1 and SMB2 clients will be forced to disconnect and reconnect to a different node on the PowerScale. Although this is usually instantaneous, it is still a brief disruption. In order to achieve fully non-disruptive operation, SMB3 continuous availability (CA) is required. The SMB CA feature needs to be enabled at share creation time; to enable SMB CA, the following preconditions need to be met:
For more information about SMB CA feature, see the SMB continuous availability and witness section in this paper.
In the case of a rolling upgrades, if your workflow requires the duration of the interruption to be further reduced, you can achieve this by forcing SMB connections to their CA pair before performing the node reboot. For details, see Reducing SMB client impacts during planned node reboots.