Upload
others
View
26
Download
0
Embed Size (px)
Citation preview
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 4.3.1.
2 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide © 2017 NetApp, Inc. All rights reserved.
TABLE OF CONTENTS
1 AltaVault Appliance Overview ............................................................................................................. 4
1.1 AltaVault Introduction ......................................................................................................................................4
1.2 SMB (Server Message Block) Introduction .....................................................................................................4
2 SMB Protocol Changes ........................................................................................................................ 5
2.1 SMB Protocol Feature Changes .....................................................................................................................5
2.2 SMB Protocol Functional Changes .................................................................................................................5
2.3 SMB Permissions Realignment .......................................................................................................................7
2.4 Depreciated CIFS commands .........................................................................................................................7
3 Upgrade Actions and Considerations ................................................................................................ 8
3.1 Upgrading AltaVault in Active Directory Domain Environments ......................................................................8
3.2 Upgrading AltaVault in Workgroup (Non-Active Directory Domain) Environments ..........................................9
3.3 Access Control List (ACL) Upgrade Considerations .......................................................................................9
3.4 Default ACL and Ownership Settings ............................................................................................................ 10
4 Performing SMB Tasks After Upgrading AltaVault ......................................................................... 10
4.1 Join AltaVault to the Windows Active Directory Domain ............................................................................... 10
4.2 Add a New SMB Share to AltaVault .............................................................................................................. 12
4.3 Create a Local User for the SMB Share ........................................................................................................ 12
4.4 Assign a Local User to the SMB Share ......................................................................................................... 13
4.5 Set the Local User Permissions on the SMB Share ...................................................................................... 13
4.6 Enable Everyone Account on the SMB Share............................................................................................... 14
4.7 Connect to the SMB Share from Windows .................................................................................................... 14
4.8 Configure Domain Users and Permissions to the SMB Share ...................................................................... 16
4.9 Leave the Windows Active Directory Domain ............................................................................................... 16
5 AltaVault Best Practices for SMB ..................................................................................................... 17
5.1 AltaVault Best Practices ................................................................................................................................ 17
5.2 SMB Best Practices ...................................................................................................................................... 17
6 Troubleshooting SMB Problems ....................................................................................................... 19
Version History ......................................................................................................................................... 20
LIST OF FIGURES
Figure 1) Export the AltaVault configuration. ..................................................................................................................8
Figure 2) Join AltaVault to a Windows domain in AltaVault version 4.2.1. ................................................................... 10
3 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide © 2017 NetApp, Inc. All rights reserved.
Figure 3) Specify preferred domain controllers in AltaVault version 4.2.2. ................................................................... 11
Figure 4) Add a SMB share to AltaVault. ...................................................................................................................... 12
Figure 5) Add a local user account for SMB access. .................................................................................................... 12
Figure 6) Assign a local user to an SMB share. ........................................................................................................... 13
Figure 7) Configure permission for the local user account on an SMB share. .............................................................. 13
Figure 8) Connecting to an SMB share by using a local user account. ........................................................................ 15
Figure 9) Connecting to an SMB share by using a domain user account. .................................................................... 15
Figure 10) Configure domain user access and assign permissions on a share. ........................................................... 16
4 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide © 2017 NetApp, Inc. All rights reserved.
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.
5 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide © 2017 NetApp, Inc. All rights reserved.
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) AltaVault 4.2 and Later (SMB)
Supports CIFSv1, SMBv2 Supports SMBv2, SMBv3
Supports Windows 2000, Windows 2008, Windows 2008 R2
Supports Windows 2008, Windows 2008 R2, Windows 2012, Windows 2012 R2
Supports guest mode user access No support for guest mode user access; access is lost if guest mode was exclusively used to gain access to shares
Supports hidden shares No support for hidden shares; previously hidden shares become normal shares
Supports sending e-mail when prepopulation is complete
No support for sending e-mail when prepopulation is complete
No support for SMBv3 features, including multichannel
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.
6 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide © 2017 NetApp, Inc. All rights reserved.
Table 2) CIFS to SMB functional changes.
AltaVault 4.1.x and Earlier (CIFS) AltaVault 4.2 and Later (SMB)
CIFS commands from the AltaVault CLI (command line)
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 CIFS Default share is created during deployment called SMB
(CIFS share is preserved if AltaVault was upgraded)
Local Path field during CIFS share creation
should specify a / in the path (for example,
/backups)
Local Path field during SMB share creation does not need
to specify a / in the path (for example, backups)
Default local user administrator is created during deployment
No default users are created during deployment; any local user account can be granted admin status and gain full administrator access to the share
Can assign to, modify permissions for, and remove a group account called Everyone from an SMB share in the AltaVault GUI.
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
Domain accounts and permissions are added to the share through Windows Explorer (right-click Share and select Properties)
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 for local users are Read, Write, Modify
Permissions are not inherited on folders or files within a share
Inheritance is enabled by default for new files and folders created on an SMB Share after the upgrade to 4.2.1 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.
7 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide © 2017 NetApp, Inc. All rights reserved.
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 Equivalent Permission in AltaVault 4.2 and Later
List Directory Read, Modify
Add File Write, Modify
Add Subdirectory Write, Modify
Read Extended Attributes Read, Modify
Write Extended Attributes Write, Modify
Traverse [Ignored]
Delete Child Modify
Read Attributes Read, Modify
Write Attributes 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 Reason for removal
cifs fips-mode All SMB operations are compliant with the appliance FIPS configuration.
cifs listen SMB is designed to listen to connections on all interfaces
cifs permissions inherit 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 SMB signing is now always enabled
cifs user guest Guest account access is insecure because it allows access to shares without any authentication
8 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide © 2017 NetApp, Inc. All rights reserved.
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.
9 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide © 2017 NetApp, Inc. All rights reserved.
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 4.2.2 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 4.2.1 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… Take the following action…
Migration not required
Auto migration completed
Manual migration completed
Stop here. The upgrade is complete.
Manual migration allowed but not migrated Go to step 3 to complete the ACL migration for a share.
Migration failed with errors
Failed to initialize migration state
Auto migration required
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
10 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide © 2017 NetApp, Inc. All rights reserved.
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 4.2.
3.4 Default ACL and Ownership Settings
If a folder or file in a SMB share does not have any ACL information when the upgrade to 4.2.1 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 4.2.1 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 4.2.1.
To join the domain using the AltaVault CLI, enter the following command:
11 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide © 2017 NetApp, Inc. All rights reserved.
smb domain join name fully.qualified.domain.name username ‘username’ password
<userpassword>
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.
Note: 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 4.2.1. Refer to the AltaVault 4.2.2 release notes for more details.
Figure 3) Specify preferred domain controllers in AltaVault version 4.2.2.
12 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide © 2017 NetApp, Inc. All rights reserved.
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.
13 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide © 2017 NetApp, Inc. All rights reserved.
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.
14 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide © 2017 NetApp, Inc. All rights reserved.
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.
15 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide © 2017 NetApp, Inc. All rights reserved.
• 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.
C:\> net use \\altavaultdatainterface\sharename /user:domainname\username *
C:\> net use
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 2000. 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.
16 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide © 2017 NetApp, Inc. All rights reserved.
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.
17 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide © 2017 NetApp, Inc. All rights reserved.
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 Recommendation
Mixing local and domain users 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).
Everyone account access 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.
SMB share name and local path
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.
Clock time must be in sync between Windows and AltaVault
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.
ACL administration 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 Recommendation
Use a supported Windows operating system
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.
18 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide © 2017 NetApp, Inc. All rights reserved.
Item Recommendation
Map the network share using the AltaVault data interface DNS name established in the domain
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.
NTLMv1 authentication is not supported by SMB shares
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
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.
Make sure that the backup application uses the same credentials that were established with the share during setup
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.
Use AltaVault with a Windows domain
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.
19 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide © 2017 NetApp, Inc. All rights reserved.
Item Recommendation
Everyone account access 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:
20 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide © 2017 NetApp, Inc. All rights reserved.
• 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,
\\10.10.10.10\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 4.2.1 release
Version 1.2 November 2016 Updated for 4.2.2 release
Version 1.3 April 2017 Updated for 4.3.1 release
21 NetApp AltaVault Cloud-Integrated Storage Appliances SMB Deployment Guide © 2017 NetApp, Inc. All rights reserved.
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 © 1994–2017 NetApp, Inc. All Rights Reserved. NETAPP, the NETAPP logo, and the marks listed at http://www.netapp.com/TM 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 252.277-7103 (October 1988) and FAR 52-227-19 (June 1987). TR-4511-0417