NetApp Technical Report · This technical report has been updated for AltaVault version 4.3.1. ... Attributes, Write Extended Attributes, Traverse, Delete Child, Read Attributes,

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


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


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.


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.


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.


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


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.


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

http://www.netapp.com/us/services-support/ngs-contacts.aspx


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:


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.


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.


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.


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.


• 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.


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.


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.


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.


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:


• 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


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

http://mysupport.netapp.com/matrix/#search

http://www.netapp.com/TM

Documents

NetApp Technical Report · This technical report has been updated for AltaVault version 4.3.1. ... Attributes, Write Extended Attributes, Traverse, Delete Child, Read Attributes,