NetApp AltaVault Cloud-Integrated Storage Appliances

Transcription

1 Technical Report NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide Christopher Wong, NetApp April 2017 TR-4511 Abstract This SMBv3 deployment and troubleshooting guide provides detailed information about and considerations for the changes that occurred with the SMB protocol of the NetApp AltaVault cloud-integrated storage appliances starting with version 4.2. Use this guide to help plan for and address questions about the impacts of implementing AltaVault 4.2 within Windows environments. This technical report has been updated for AltaVault version

2 TABLE OF CONTENTS 1 AltaVault Appliance Overview AltaVault Introduction SMB (Server Message Block) Introduction SMB Protocol Changes SMB Protocol Feature Changes SMB Protocol Functional Changes SMB Permissions Realignment Depreciated CIFS commands Upgrade Actions and Considerations Upgrading AltaVault in Active Directory Domain Environments Upgrading AltaVault in Workgroup (Non-Active Directory Domain) Environments Access Control List (ACL) Upgrade Considerations Default ACL and Ownership Settings Performing SMB Tasks After Upgrading AltaVault Join AltaVault to the Windows Active Directory Domain Add a New SMB Share to AltaVault Create a Local User for the SMB Share Assign a Local User to the SMB Share Set the Local User Permissions on the SMB Share Enable Everyone Account on the SMB Share Connect to the SMB Share from Windows Configure Domain Users and Permissions to the SMB Share Leave the Windows Active Directory Domain AltaVault Best Practices for SMB AltaVault Best Practices SMB Best Practices Troubleshooting SMB Problems Version History LIST OF FIGURES Figure 1) Export the AltaVault configuration....8 Figure 2) Join AltaVault to a Windows domain in AltaVault version NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide 2017 NetApp, Inc. All rights reserved.

3 Figure 3) Specify preferred domain controllers in AltaVault version Figure 4) Add a SMB share to AltaVault Figure 5) Add a local user account for SMB access Figure 6) Assign a local user to an SMB share Figure 7) Configure permission for the local user account on an SMB share Figure 8) Connecting to an SMB share by using a local user account Figure 9) Connecting to an SMB share by using a domain user account Figure 10) Configure domain user access and assign permissions on a share NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide 2017 NetApp, Inc. All rights reserved.

4 1 AltaVault Appliance Overview 1.1 AltaVault Introduction With the never-ending demand to maintain the highest levels of data integrity for increasingly large datasets, companies are continuously being challenged to find effective data protection solutions that balance cost, data protection, and disaster recovery features. Historical approaches such as tape backup and disk-to-disk replication for protecting data and ensuring recoverability in disaster scenarios face enormous constraints. These constraints stem from the amount of human interaction, technical complexity, and costs involved in implementing such solutions to meet recovery requirements. NetApp AltaVault storage enables customers to securely back up data to any cloud at up to 90% less cost compared with on-premises solutions. AltaVault gives customers the power to tap into cloud economics while preserving investments in existing backup infrastructure and meeting backup and recovery SLAs. The AltaVault appliance is a disk-to-disk data storage optimization system with cloud storage integration. It easily integrates with existing backup and archival applications to securely protect critical production data off site. And it does so without the complexity of using tape management solutions and without the cost of using in-house disaster recovery sites and services. Add an AltaVault appliance as a target for your existing backup or archival infrastructure. The backup server simply connects to the AltaVault appliance by using SMB, NFS, or OST protocols. When you back up or archive to an AltaVault appliance, it performs inline variable-length deduplication of the backup data and securely replicates data into the cloud. AltaVault appliances use the local disk to store enough data for recovery of recent information. For example, with the recent release of the AVA800 appliance, you can store up to 384TB of deduplicated data per appliance. Such a mechanism provides LAN performance for the most likely restores. The AltaVault appliance then writes the deduplicated, compressed, and encrypted backup data to your public or private cloud storage provider. AltaVault appliances also optimize replication restores from the cloud because they move only deduplicated data over the WAN. AltaVault appliances are designed around the need for maintaining superior data integrity while delivering the performance and costs that companies need in such a backup and disaster recovery solution. AltaVault appliances are file-based data deduplication storage devices with SMB, NFS, or OST connectivity to back up applications and cloud storage connectivity to a variety of class-leading cloud storage providers. Data is ingested into AltaVault appliances by using multiple 1GbE or 10GbE connections. Data is inline deduplicated, compressed, and encrypted before it is written to the AltaVault local cache and is asynchronously replicated through secure Transport Layer Security connections to cloud storage. AltaVault appliances protect data by using class-leading deduplication technologies and by using scalable and cost-effective cloud storage to provide long-term data storage for backup data. AltaVault also implements a local disk cache for immediate restore needs. 1.2 SMB (Server Message Block) Introduction One of the primary AltaVault NAS protocols that is used to perform data protection movement from backup application servers to AltaVault is SMB. This Windows-based protocol allows Windows servers to communicate with other SMB-enabled systems, such as AltaVault. SMB is sometimes referred to as CIFS, but CIFS is the predecessor to SMB and is now considered as obsolete. All current development is performed by using the SMB protocol. SMB is currently enabled in two versions: SMBv2 and SMBv3. SMBv2 is the default protocol that is used with Windows 2000 and Windows 2008 systems, and SMBv3 is the default protocol that is used with Windows 2012 systems. Because AltaVault uses Linux as the underlying operating system, SMB services are provided through an SMB stack. In AltaVault 4.2, the SMB stack was updated to enable SMBv3 support and to enable features that are available with this version, such as SMB multichannel. 4 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide 2017 NetApp, Inc. All rights reserved.

5 2 SMB Protocol Changes NetApp AltaVault uses an SMB protocol stack within the AltaVault operating system to deliver SMB capabilities to users running in Microsoft Windows based environments. In versions earlier than 4.2, users interact with CIFS throughout the AltaVault user interfaces. Starting with AltaVault 4.2, users interact with SMB referenced throughout the user interfaces. The SMB protocol that AltaVault uses has been redesigned to take advantage of the latest technology features that are available with SMBv3, such as SMB multichannel. 2.1 SMB Protocol Feature Changes The CIFS/SMB protocol stack provides a different set of features, depending on the version of AltaVault that is used. Table 1 lists a summary of those changes. Table 1) CIFS and SMB feature changes. AltaVault 4.1.x and Earlier (CIFS) Supports CIFSv1, SMBv2 Supports Windows 2000, Windows 2008, Windows 2008 R2 Supports guest mode user access Supports hidden shares Supports sending when prepopulation is complete No support for SMBv3 features, including multichannel AltaVault 4.2 and Later (SMB) Supports SMBv2, SMBv3 Supports Windows 2008, Windows 2008 R2, Windows 2012, Windows 2012 R2 No support for guest mode user access; access is lost if guest mode was exclusively used to gain access to shares No support for hidden shares; previously hidden shares become normal shares No support for sending when prepopulation is complete Support for SMBv3 multichannel 2.2 SMB Protocol Functional Changes If AltaVault users upgrade from earlier versions of AltaVault to version 4.2 or later, they will see differences when they interact with the SMB protocol with AltaVault. Table 2 lists a summary of those changes. 5 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide 2017 NetApp, Inc. All rights reserved.

6 Table 2) CIFS to SMB functional changes. AltaVault 4.1.x and Earlier (CIFS) CIFS commands from the AltaVault CLI (command line) Default share is created during deployment called CIFS Local Path field during CIFS share creation should specify a / in the path (for example, /backups) Default local user administrator is created during deployment Can assign to, modify permissions for, and remove a group account called Everyone from an SMB share in the AltaVault GUI. AltaVault 4.2 and Later (SMB) SMB commands replace CIFS commands where appropriate; some CIFS commands have been deprecated (see section 2.4 below for further details) Default share is created during deployment called SMB (CIFS share is preserved if AltaVault was upgraded) Local Path field during SMB share creation does not need to specify a / in the path (for example, backups) No default users are created during deployment; any local user account can be granted admin status and gain full administrator access to the share The AltaVault GUI allows the Everyone group account to be added to an SMB share only at the time the SMB share is created, using the Allow Everyone access checkbox. If the SMB share is created without Everyone, the group can be added back to the SMB share later via the AltaVault CLI command described in section 4.6. Permissions for, and removal of this group can be done through the GUI. Add domain accounts and set permissions through the AltaVault GUI Permissions for local users are List Directory, Add File, Add Subdirectory, Read Extended Attributes, Write Extended Attributes, Traverse, Delete Child, Read Attributes, Write Attributes Permissions are not inherited on folders or files within a share Domain accounts and permissions are added to the share through Windows Explorer (right-click Share and select Properties) Permissions for local users are Read, Write, Modify Inheritance is enabled by default for new files and folders created on an SMB Share after the upgrade to or later. Specifically: Existing folders and files created on the SMB share prior to the upgrade with default access control lists (ACLs) will inherit permissions from the SMB share after the upgrade. Existing folders and files created on the SMB share prior to the upgrade with configured ACLs will not be initially affected by inheritance. If a modification of the folder or file ACL is performed after the upgrade is complete, the file will inherit permissions from the SMB share. Newly created folders and files on the SMB share created after the upgrade will inherit permissions from the SMB share. 6 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide 2017 NetApp, Inc. All rights reserved.

7 2.3 SMB Permissions Realignment As noted in section 2.2, share permission types that are available to assign to local user accounts are different in version 4.2 and later. Table 3 identifies the consolidation of those permissions to the three permission types that are available with 4.2 and later. Table 3) SMB permissions realignment. Permission in AltaVault 4.1.x and Earlier List Directory Add File Add Subdirectory Read Extended Attributes Write Extended Attributes Traverse Delete Child Read Attributes Write Attributes Equivalent Permission in AltaVault 4.2 and Later Read, Modify Write, Modify Write, Modify Read, Modify Write, Modify [Ignored] Modify Read, Modify Write, Modify 2.4 Depreciated CIFS commands With AltaVault 4.2 and later, certain CIFS commands have not been carried over as new SMB commands and have instead been removed from the AltaVault CLI. Those commands are discussed in the Commands section of the AltaVault 4.2 Release Notes, and are provided in Table 4.Refer to the CLI reference guide for details on new SMB commands available. Table 4) Deprecated CIFS commands. AltaVault v4.1.x and lower CIFS command cifs fips-mode cifs listen cifs permissions inherit Reason for removal All SMB operations are compliant with the appliance FIPS configuration. SMB is designed to listen to connections on all interfaces SMB performs permissions inheritance based on Windows file system rules cifs permissions migrate Was used for older permissions migration in AltaVault 4.1 and older only cifs smb-signing cifs user guest SMB signing is now always enabled Guest account access is insecure because it allows access to shares without any authentication 7 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide 2017 NetApp, Inc. All rights reserved.

8 3 Upgrade Actions and Considerations Because of the changes in the SMB protocol stack as described in section 2, NetApp AltaVault administrators should carefully consider whether to upgrade AltaVault from earlier versions to 4.2 or later. If any of the CIFS-based features discussed in section 2.1 are required for operations, an upgrade to 4.2 or later might not be advisable until those requirements can be satisfied by the updated features in AltaVault. 3.1 Upgrading AltaVault in Active Directory Domain Environments If AltaVault is currently configured in a Windows Active Directory domain, NetApp recommends that you perform the following steps to properly upgrade AltaVault to the latest release currently available. 1. Back up the current AltaVault configuration by using the Export Configuration Wizard. This wizard is in the Settings > Setup Wizard menu of the AltaVault GUI. Figure 1) Export the AltaVault configuration. 2. Perform the AltaVault software upgrade. For details about performing the upgrade, see the AltaVault Administration Guide, chapter 9, Upgrading Your Software section. NetApp recommends to update to the latest release to improve stability and accesibility of SMB related functions. 3. After the upgrade is complete, go to the Configure > SMB page, and rejoin the Windows domain. Provide the necessary credentials of a Windows domain account that has the authority to add hosts to the Windows domain. For more information, see section 4.1 in this report, Join AltaVault to the Windows Active Directory Domain. 4. Perform another backup of the new AltaVault configuration by using the Export Configuration Wizard. This wizard is in the Configure > Setup Wizard menu of the AltaVault GUI. 8 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide 2017 NetApp, Inc. All rights reserved.

9 3.2 Upgrading AltaVault in Workgroup (Non-Active Directory Domain) Environments If AltaVault is not configured in a Windows Active Directory domain and will be used and accessed only by local Windows systems in a workgroup environment, AltaVault can be upgraded normally. For information about a normal upgrade, see the AltaVault Administration Guide, chapter 9, Upgrading Your Software section. After the upgrade is complete, perform a backup of the new AltaVault configuration by using the Export Configuration Wizard. This wizard is in the Configure > Setup Wizard menu of the AltaVault GUI. 3.3 Access Control List (ACL) Upgrade Considerations AltaVault automatically imports existing CIFS shares when upgrading to 4.2 or later. AltaVault also migrates user and group permissions (also known as access control lists, or ACLs) for shares, folders and files to a new format when upgrading from versions of AltaVault prior to 4.2. Depending on the upgrade path taken, ACL migration may be done automatically, or may have to be done manually. Determining the AltaVault Upgrade History The version history of AltaVault is recorded in the Upgrade page of AltaVault. For versions of AltaVault prior to 4.2, access the upgrade page from Settings > Software Upgrade. For versions of AltaVault at 4.2 and later, access the upgrade page from Maintenance > Software Upgrade. Manually Migrating ACL Permissions AltaVault versions prior to 4.2 that are upgraded directly to or later will not need manual migration of ACLs. AltaVault will automatically migrate ACLs to the new format. However, if AltaVault versions prior to 4.2 are upgraded first to 4.2.0, 4.2P1, or 4.2D1, and then upgraded to or later, AltaVault permissions will not be migrated automatically, and will need to be migrated manually after the upgrade as follows: 5. Use SSH to login to the AltaVault CLI and enter configure terminal mode: CLI > enable CLI # configure terminal CLI (config) # 6. Check the migration status of SMB using the following command: CLI (config) # show smb migrate domain-acls status Based on the status message, take the appropriate action: If the migration status is Migration not required Auto migration completed Manual migration completed Manual migration allowed but not migrated Migration failed with errors Failed to initialize migration state Auto migration required Take the following action Stop here. The upgrade is complete. Go to step 3 to complete the ACL migration for a share. Contact technical support for assistance. 7. If you are manually migrating ACLs for individual shares, use the following command for each share you will migrate: CLI (config) # smb migrate domain_acls name <sharename> force override 9 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide 2017 NetApp, Inc. All rights reserved.

10 If you are migrating ACLS for all shares, use the following command: CLI (config) # smb migrate domain_acls all override Use the name parameter to specify a share name. Use the all parameter to specify all SMB shares on the AltaVault. The override parameter overwrites any existing share-level ACLs with the ACL present prior to Default ACL and Ownership Settings If a folder or file in a SMB share does not have any ACL information when the upgrade to or later occurs, AltaVault will not migrate any ACL information. Instead, AltaVault will have the folder or file inherit the ACL information from the SMB share. AltaVault will also attempt to maintain the ownership of the folder or file during upgrade to or later. If ownership information is not able to be determined when the upgrade occurs, AltaVault will set the ownership information of the folder or file to the builtin Windows Backup Operators group. You will then need to modify the ownership information if required through Windows Explorer.This will ensure that access is always available to a well defined domain group that can then set the permissions correctly based on the requirements of the business. 4 Performing SMB Tasks After Upgrading AltaVault Interacting with NetApp AltaVault SMB shares after an upgrade is different than interacting with AltaVault CIFS shares before the upgrade. This section describes how common SMB actions are addressed in AltaVault 4.2 and later. 4.1 Join AltaVault to the Windows Active Directory Domain AltaVault can be joined to a Windows 2008, Windows 2008 R2, Windows 2012, or Windows 2012 R2 Active Directory domain. To join to the Windows Active Directory domain, use the Domain section of the Configure > SMB page. Provide a domain user credential that has sufficient delegated authority to join computers to the domain to add AltaVault to the domain. Figure 2) Join AltaVault to a Windows domain in AltaVault version To join the domain using the AltaVault CLI, enter the following command: 10 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide 2017 NetApp, Inc. All rights reserved.

11 smb domain join name fully.qualified.domain.name username username password <userpassword> Note: Note: Starting with version 4.2.1, you may optionally set the AltaVault hostname value and domain controller name to contact for authentication. The Hostname field identifies the name AltaVault will be registered in the Windows domain as, if you do not want to use the current hostname configured in the Configure > Host Settings page. This value must be 15 characters or less. The Domain Controller Name field identifies a specific Windows domain controller to contact for AltaVault registration into the Windows domain. You can use this field if DNS or reverse DNS is not properly configured for DCs in the environment, or if the normal DC is unavailable. Starting with version 4.2.2, AltaVault can specify and use up to 3 preferred domain controllers. NetApp recommends specifying the preferred domain controllers prior to joining the Windows domain. This replaces the Domain Controller Name field in the Advanced Settings section in AltaVault version Refer to the AltaVault release notes for more details. Figure 3) Specify preferred domain controllers in AltaVault version NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide 2017 NetApp, Inc. All rights reserved.

12 4.2 Add a New SMB Share to AltaVault AltaVault SMB shares are created by using the Configure > SMB page. For details about adding an SMB share, see the AltaVault Administration Guide, chapter 4, Configuring SMB section. Figure 4) Add a SMB share to AltaVault. 4.3 Create a Local User for the SMB Share AltaVault SMB shares can be assigned local user accounts that are created on AltaVault. However, those local user accounts must first be created by using the Add a User section of the Configure > SMB page. For details about adding an SMB share, see the AltaVault Administration Guide, chapter 4, To Add a Local User to Access the Share section. Figure 5) Add a local user account for SMB access. 12 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide 2017 NetApp, Inc. All rights reserved.

13 4.4 Assign a Local User to the SMB Share To assign a local user, you must first create an SMB share and a local user account on AltaVault, as mentioned in the preceding sections. Then you can expand the SMB share in the AltaVault GUI and assign the local user to the SMB share in the share s subsection Add a User. Only local user accounts that have been created show in the User drop-down field. Figure 6) Assign a local user to an SMB share. 4.5 Set the Local User Permissions on the SMB Share After the local user is assigned to the SMB share, you can establish the effective permissions for that user in the user s subsection of the SMB share. Figure 7) Configure permission for the local user account on an SMB share. 13 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide 2017 NetApp, Inc. All rights reserved.

14 4.6 Enable Everyone Account on the SMB Share In certain cases, an administrator will want to add the Everyone group account to an SMB share at a later date. This situation can occur if Everyone is not initially added during SMB share creation. AltaVault 4.2 and later does not provide the ability to add Everyone for an existing SMB share through the GUI. To add Everyone to an SMB share, issue the following CLI command: smb share permission add name <SMBsharename> user Everyone access allow 4.7 Connect to the SMB Share from Windows NetApp recommends that you first connect to the SMB share, using either Windows Explorer or the Windows command prompt, preferably with the user account that will be performing backups. Initial access can be performed using any user account, and this initial user account will be allowed to set security permissions on the share, including the addition of domain users or groups. From that point onwards, only authorized users or groups can access and modify permissions on the share. Domain administrators always have access to any resource and can modify permissions, including on AltaVault SMB shares. After you access the share and confirm that you can successfully write, read, and delete files, reconfigure the backup application to run using these credentials. 14 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide 2017 NetApp, Inc. All rights reserved.

15 If you use a local user account as configured in the previous sections, make sure that you specify the local user name and password during the map network drive process. Figure 8) Connecting to an SMB share by using a local user account. C:\> net use \\altavaultdatainterface\sharename /user:\username * C:\> net use If you use a domain user account from a Windows Active Directory domain, make sure that you specify the domain, domain account name, and password during the map network drive process. Figure 9) Connecting to an SMB share by using a domain user account. Mapping AltaVault SMB Shares Mapping AltaVault SMB share connections with DNS hostnames will be validated by Windows using Kerberos authentication. This is the NetApp recommended method as it offers the most security for SMB connections. Mapping AltaVault SMB share connections with IP values will be validated by Windows using NTLMv2. This is an older standard supported by Windows server 2012, 2008 and AltaVault supports NTLMv2. SMB share connection attempts can fail with an invalid authentication attempt error if NTLMv1 is used. NTLMv1 is old and insecure by Windows standards, and is not supported by AltaVault. NTLMv1 is configured at a security policy level, under the configuration setting LAN Manager Authentication Level. Refer to Chapter 5 for details on configuring NTLMv2 in Windows. C:\> net use \\altavaultdatainterface\sharename /user:domainname\username * C:\> net use 15 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide 2017 NetApp, Inc. All rights reserved.

16 4.8 Configure Domain Users and Permissions to the SMB Share If AltaVault is in a domain, you can add, remove, or modify domain users or groups to the share. Each domain user can have specific permissions as allowed by Windows. Make sure that the backup application will be included, or use the account or group that is established in this section. Figure 10) Configure domain user access and assign permissions on a share. 4.9 Leave the Windows Active Directory Domain If AltaVault must be configured to leave a Windows AD domain, you can do so in a fashion very similar to joining the Windows AD domain. To leave to the Windows Active Directory domain, use the Domain section of the Configure > SMB page. Provide a domain user credential that has sufficient delegated authority to remove computers from the domain to allow AltaVault to leave the domain. To leave the domain using the AltaVault CLI, enter the following command: smb domain join name fully.qualified.domain.name username username password <userpassword> If you specify a specific AltaVault hostname and/or specific Windows domain controller when joining the domain (as outlined in section 4.1 above), it is recommended to use the same hostname and/or Windows domain controller when leaving the domain. This ensures that the appropriate DCs in the environment will update their records correctly indicating the removal of the AltaVault appliance from the domain. If the DC is not reachable, or you forget the AltaVault hostname used, you can still leave the Windows domain without specifying credentials of a domain admin or domain account that has the authority to remove hosts to the Windows domain. However, you will need to manually remove the AltaVault computer name entry from specific domain controller. 16 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide 2017 NetApp, Inc. All rights reserved.

17 5 AltaVault Best Practices for SMB The following sections describe best practices for configuring NetApp AltaVault with SMB. Follow these recommendations to promote a superior experience when you use AltaVault in Windows environments. 5.1 AltaVault Best Practices Implement these best practices on AltaVault to grant proper use of SMB shares. Table 5) AltaVault best practices. Item Mixing local and domain users Everyone account access SMB share name and local path Clock time must be in sync between Windows and AltaVault ACL administration Recommendation NetApp does not recommend mixing local and domain users on AltaVault SMB shares because this adds complexity to configurations. So that the configuration and operations can properly mirror a production setup, if possible, configure AltaVault according to how it will be placed into potential production use (It will be either in a workgroup environment or a domain environment). NetApp does not recommend providing the Everyone account access to the share for production use, but this option can be enabled when initially creating a new share for use in heavily regulated Windows domain environments. This step allows initial administration access to the share in order to configure user and group accounts. After connecting to the share and configuring user access as outlined in sections 4.7 and 4.8, you can remove the Everyone account from AltaVault GUI or CLI. If AltaVault is not used in domain environments, you can deselect the checkbox and assign local users and permissions individually to the share. NetApp recommends having the share name and the local path name match. For example, if the share is called backups, use backups as the local path. Joining the domain requires that the AltaVault appliance time be within 5 minutes of the domain controller time, as per Microsoft Kerberos requirements. Make sure that times are in sync, such as through the use of a Network Time Protocol (NTP) server. Domain users are added, modified, and removed through Windows Explorer. Local users and Everyone account access are added, modified, and removed through the AltaVault GUI and CLI. 5.2 SMB Best Practices Implement these best practices when connecting and using SMB shares from a Windows server system. Table 6) SMB best practices. Item Use a supported Windows operating system Recommendation AltaVault has been tested with Windows server based operating systems. Although using client-based operating systems such as Windows 10 and Windows 7 should work without any problems, they have not officially been qualified and are not guaranteed to work. 17 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide 2017 NetApp, Inc. All rights reserved.

18 Item Map the network share using the AltaVault data interface DNS name established in the domain NTLMv1 authentication is not supported by SMB shares Recommendation AltaVault shares in domain based environments are recommended to be connected using hostnames and not IP addresses. Using DNS hostnames will enable Kerberos authentication, while using IP addresses will use older NTLMv2 authentication. As a prerequisite to using hostnames, DNS must be configured correctly in the domain. For example, use \\datainterfacename\sharename, rather than \\10.x.x.x\sharename. If DNS is not configured in the environment and you must connect to AltaVault shares by using an IP address (which triggers NTLM authentication requests), make sure that the Windows server is using NTLMv2. NTLMv2 is the default authentication model for Windows server 2000 and higher, and must be enabled on the Windows server that connects to the AltaVault share, otherwise AltaVault rejects connections. Establish NTLMv2 through the local security policy option Network Security: LAN Manager Authentication Level, which must be set to Send NTLMv2 Response Only or a higher level. Alternatively, it can be established in the registry key lmcompatibilitylevel, which is in the registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\L sa. The value should be set to 3 or higher. A value of 2 or lower is insufficient to satisfy this requirement. Make sure that this value will not be overridden by the global security policy. Check with your domain administrator if you are unsure about what the global security policy setting for this field is. Clock time must be in sync between Windows and AltaVault Make sure that the backup application uses the same credentials that were established with the share during setup Use AltaVault with a Windows domain AltaVault, the domain controller, and the Windows server that maps the share require that the AltaVault appliance time be within 5 minutes of the domain controller time, as per Microsoft Kerberos requirements. Make sure that times are in sync, such as through the use of an NTP server. As described in section 4, make sure that the backup application is properly configured to use the same user or group account and password as were established during the setup of the share. This task might require multiple Windows services for the backup application that is being configured. Or it might require configuring permissions for the user to be included in a group that has sufficient permissions when assigned to the share. If a Windows domain is present it is recommended to use AltaVault with domain users and groups. It is not recommended to use local users and groups. Starting with version 4.2.2, specify up to 3 preferred domain controllers. 18 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide 2017 NetApp, Inc. All rights reserved.

19 Item Everyone account access Recommendation NetApp does not recommend providing the Everyone account access to the share for production use, but this option can be enabled when initially creating a new share for use in heavily regulated Windows domain environments. This step allows initial administration access to the share in order to configure user and group accounts. After connecting to the share and configuring user access as outlined in sections 4.7 and 4.8, you can remove the Everyone account from AltaVault GUI or CLI. If AltaVault is not used in domain environments, you can deselect the checkbox and assign local users and permissions individually to the share. 6 Troubleshooting SMB Problems NetApp AltaVault implementation of the updated SMB protocol can result in user interaction experiences that are different from experiences with previous AltaVault versions. This section discusses common troubleshooting techniques to isolate and resolve SMB-related problems. Adding AltaVault to the Active Directory domain fails Make sure that you correctly specify the domain information to AltaVault: Specify the fully qualified domain name (FQDN), for example, corp.companyname.com. Specify a domain administrator or a domain user credential that has sufficient delegated authority to add machines to the domain. Confirm that you can ping the domain controller by hostname and FQDN from AltaVault CLI. Ensure that DNS and reverse DNS entries are configured properly for the DCs that AltaVault will contact for domain operations. Starting with version 4.2.2, domain user names should be specified using the username or username@realm format. AltaVault will not accept the domain\username format. If a specific domain user is not a member of the domain admins group, the domain user must be delegated control of the Computers object in Active Directory Users and Computers. When using the Delegation of Control Wizard in Windows, the specific permissions that must be granted for the Computers object to the user are: Write All Properties Change Password Reset Password Validated Write to DNS Host Name Validated Write to Service Principal Name Read and Write DNS Host Name Attributes Connecting to a network drive fails with the system log error clock skew too great All the systems in the Active Directory domain and in AltaVault must be within 5 minutes of each other. Verify that the time is set correctly. The time and date can be configured from the GUI menu path Configure > Date and Time. Authentication fails with invalid user or password when connecting to an AltaVault SMB share by using domain user accounts Authentication that uses domain user accounts requires the following: 19 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide 2017 NetApp, Inc. All rights reserved.

20 The system time of AltaVault, the Windows domain controller, and the Windows systems performing backups to AltaVault, must be within 5 minutes of each other. If you use IP address values in the Uniform Naming Convention (UNC) path (for example, \\ \sharename), make sure that NTLMv2 or later is enabled on the Windows systems and group security policy. To set the correct entry in the security policy, see section 0, AltaVault Best Practices for SMB, in this document. If you use DNS address values in the UNC path, make sure that forward and reverse lookup DNS entries are present and are correct for the DC and DNS server systems. You should confirm by using ping and nslookup that all the Windows backup servers, the DC, the DNS server, and AltaVault can see each other. If ping succeeds, use the Windows net view \\IPAddressOrDnsOfAltaVault command. If you see AltaVault SMB shares listed, this confirms that the AltaVault SMB service is listening on port 445 of the IP address that answered the ping. If this command fails, this could mean the SMB service is not listening on this port, or there may be a firewall preventing access to this port. You should confirm that you are using an account that has sufficient permissions to connect to the share. If upgrading a domain connected AltaVault from version 4.1 or earlier to 4.2 or later, you will need to add the Everyone account and re-enable the account permissions. Domain accounts are not carried over by the 4.2 upgrade. Refer to sections 4.6 to 4.8 for details on performing these activities. Authentication fails with invalid user or password when connecting to an AltaVault SMB share by using local user accounts Authentication that uses local user accounts requires the following: The AltaVault local user account must be enabled and associated with the SMB share. The AltaVault local user account must have the sufficient read, write, or modify privilege to the share. If performing a disaster recovery test, the AltaVault SMB configuration must be imported by using a full import of the configuration. Using the Import shared data only option does not preserve the SMB user configuration. Version History Version Date Document Version History Version 1.0 May 2016 Initial release Version 1.1 August 2016 Updated for release Version 1.2 November 2016 Updated for release Version 1.3 April 2017 Updated for release 20 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide 2017 NetApp, Inc. All rights reserved.

21 Refer to the Interoperability Matrix Tool (IMT) on the NetApp Support site to validate that the exact product and feature versions described in this document are supported for your specific environment. The NetApp IMT defines the product components and versions that can be used to construct configurations that are supported by NetApp. Specific results depend on each customer's installation in accordance with published specifications. Copyright Information Copyright NetApp, Inc. All Rights Reserved. NETAPP, the NETAPP logo, and the marks listed at are trademarks of NetApp, Inc. Other company and product names may be trademarks of their respective owners. Printed in the U.S. No part of this document covered by copyright may be reproduced in any form or by any means graphic, electronic, or mechanical, including photocopying, recording, taping, or storage in an electronic retrieval system without prior written permission of the copyright owner. Software derived from copyrighted NetApp material is subject to the following license and disclaimer: THIS SOFTWARE IS PROVIDED BY NETAPP "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WHICH ARE HEREBY DISCLAIMED. IN NO EVENT SHALL NETAPP BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. NetApp reserves the right to change any products described herein at any time, and without notice. NetApp assumes no responsibility or liability arising from the use of products described herein, except as expressly agreed to in writing by NetApp. The use or purchase of this product does not convey a license under any patent rights, trademark rights, or any other intellectual property rights of NetApp. The product described in this manual may be protected by one or more U.S. patents, foreign patents, or pending applications. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS (October 1988) and FAR (June 1987). TR NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide 2017 NetApp, Inc. All rights reserved.