Hardening NetApp ONTAP. September 2017 SL10328 Version 1.2

Transcription

1 September 2017 SL10328 Version 1.2

2 TABLE OF CONTENTS 1 Introduction Basic ONTAP 9 Security Practices Lab Objectives Prerequisites Lab Environment Lab Activities Lab Preparation Route Event Messages and Command-History to an External Syslog Server Destination Exercise Administrative User Account Custom Roles Exercise Configuring Firewalls Exercise Configure SSH Exercise Configure CLI Session Timeouts Exercise Configure SSL/TLS Exercise NFS/CIFS Export Policies CIFS Exercise NFS Exercise SMB (CIFS) ACLs Exercise

3 3.10 SMB Signing and SMBv3 Encryption Exercise Configure NetApp Volume Encryption Exercise Review Syslog Events Exercise References Version History

4 1 Introduction This lab introduces several basic techniques for security hardening of NetApp ONTAP version 9. This lab utilizes as its starting point an environment that contains a virtualized, single node ONTAP 9 cluster, and several virtualized servers that allow you to perform and verify some simple steps to secure your data storage environment. This lab is not intended to be an all-encompassing best practices guide for securing ONTAP 9; there is no one size fits all security configuration that is ideal for every situation. Rather, this lab introduces many of the security features available to you in ONTAP 9 so that you can learn how they work. With this knowledge you can then decide if and how to best apply those features to meet the unique security needs of your own environment. 1.1 Basic ONTAP 9 Security Practices These days system administrators and end-users alike are justifiably very concerned about the security of their IT environments and the data they contain. These concerns stem from a constant stream of newly exploited vulnerabilities, and the discovery of data breaches occurring at an ever alarming rate. Although you may not be able to prevent all attempts at unauthorized incursion, you can better safe-guard your IT resources and your data through the use of some basic security practices. Security, itself, is a rather complex subject with many different facets. In this lab you will focus on a small list of basic security concepts, as described in the following table. Table 1 Table A Basic Security Concepts Security Concept Discussion 1 Is Big Brother watching? Accountability Is there a record of my actions (successful or failed)? Where is this record kept? 2 Access How do I access my IT resources? What protocols do I use? Will my on-line sessions automatically terminate if I am away from my workstation too long? 3 Identification Who am I? Where is my username stored? 4 Authentication How do I prove I m really me? What kind of secret can I provide to prove who I really am? 5 Authorization Now that I have access, what am I allowed to do? What are my restrictions? For ONTAP 9, there are two (2) major areas for security focus. These are Administrative access for management of the ONTAP 9 cluster, and the Storage Virtual Machines (SVMs) hosted on the cluster. User (data consumer) access to data hosted and served by the SVMs. For the first case, Administrative access, this lab limits the focus to Cluster/Storage administrators connecting to the ONTAP 9 cluster (or a hosted SVM) using the Secure Shell (SSH) protocol. This is just one of several access methods that can be employed, but for brevity this lab focuses only on SSH access. 4

5 For the second case, this lab focuses on two Network Attached Storage (NAS) protocols used to access stored data. These are CIFS (predominantly used by Windows), and NFS (predominantly used by Linux/UNIX). All of the concepts shown in Table A apply to NAS served data, as well as these three (3) additional concepts (as shown in Table B). These concepts sometimes go by the acronym CIA (not to be confused with the Company located in Langley, VA.) Table 2 Table B Additional Security Concepts Security Concept Discussion C Confidentiality Can any unauthorized persons or entities read my private data? I Integrity Can any unauthorized persons or entities modify or delete my private data? A Availability Is all of my data reliably accessible with minimal or no latency? All of the security concepts presented in these two tables are addressed by one or more sections in this lab. 1.2 Lab Objectives In this lab you will learn techniques for hardening the security of an ONTAP system. You will specifically learn how to Configure cluster command logging to an external syslog server. Create custom roles for administrative accounts. Configure firewall to protect cluster services. Restrict cluster SSH access to more secure encryption. Configure CLI session timeouts. Restrict cluster core web services. Create and test CIFS and NFS export policies. Create SMB (CIFS) shares ACLs. Enable SMBv3 encryption Review command history captured by syslog. 1.3 Prerequisites This lab assumes that you are familiar with the basic concepts of administering ONTAP 9. This lab makes extensive use of the ONTAP command line interface (CLI) because OnCommand System Manager, NetApp's graphical administration tool, does not support the features necessary to complete many of the exercises you will be performing. Experience with the ONTAP CLI is helpful but not required. The instructions are designed to allow a novice to complete the lab. This lab also uses Linux CLI commands, but again, experience is not required in order to complete the lab. 5

6 2 Lab Environment The following illustration depicts the lab environment Figure 2-1 Table 3 Table of Systems Server \ Resource 6 Purpose IP Address Username Password JUMPHOST Windows 2012R Remote Access Host DEMO\Administrator Netapp1! RHEL1 Red Hat 6.8 x64 Linux Host root Netapp1! RHEL2 Red Hat 6.8 x64 Linux Host root Netapp1! SYSLOG Red Hat 6.6 x64 Linux Syslog Server root Netapp1! WIN2K12R2 Windows 2012R2 Server DEMO\Administrator Netapp1! DC1 Active Directory and DNS Server DEMO\Administrator Netapp1! CLUSTER1 ONTAP 9 cluster admin Netapp1! CLUSTER1-01 ONTAP cluster node admin Netapp1! CIFS CIFS Server SVM vsadmin Netapp1! NFS NFS Server SVM vsadmin Netapp1!

7 Table 4 User IDs and Passwords User User Type Username or UID Group Membership or GID Login Password CIFS Data User # 1 Windows demo\datauser1 CIFS Data Users Netapp1! CIFS Data User # 2 Windows demo\datauser2 CIFS Data Users Netapp1! CIFS Data User # 3 Windows demo\datauser3 CIFS 2nd Data Users Netapp1! CIFS Data User # 4 Windows demo\datauser4 CIFS 2nd Data Users Netapp1! NFS Data User # 1 Linux ldatauser1 nfs_users1 Netapp1! (500) (5001) ldatauser2 nfs_users1 (501) (5001) ldatauser3 nfs_users2 (502) (5002) ldatauser4 nfs_users2 (503) (5002) NFS Data User # 2 NFS Data User # 3 NFS Data User # 4 7 Linux Linux Linux Netapp1! Netapp1! Netapp1!

8 3 Lab Activities This lab contains the following activities and tasks Lab Preparation on page 8 Configuring Firewalls on page 16 Route Event Messages and Command-History to an External Syslog Server Destination on page 10 Administrative User Account Custom Roles on page 11 Configure SSH on page 19 Configure CLI Session Timeouts on page 21 Configure SSL/TLS on page 22 NFS/CIFS Export Policies on page 26 SMB (CIFS) ACLs on page 41 Configure NetApp Volume Encryption on page 64 Review Syslog Events on page Lab Preparation In order to complete the exercises in this lab you need to establish a terminal session to cluster1. 1. On the desktop of the Jumphost, launch PuTTY by clicking the two-terminal icon on the taskbar. 1 Figure By PuTTY displays the Basic options for your PuTTY session view after launch. If you accidentally navigate away from this view just click on the Session category item in the left pane to return to this view. 3. In the Saved Sessions box, double-click the entry for cluster1. 8

9 3 Figure 3-2 The cluster1.demo.netapp.com - PuTTY window opens. 4. Log into cluster as the user admin, with the password Netapp1!. 5. You will need this terminal session throughout all the sections of this lab, so do not close it between exercises. If you do accidentally close it, you can come back to this procedure to open a new terminal session. If you are new to the ONTAP CLI, the length of the commands can seem a little intimidating. However, the commands are actually quite easy to use if you remember the following 3 tips Make liberal use of the Tab key while entering commands, as the ONTAP command shell supports tab completion. If you hit the Tab key while entering a portion of a command word, the command shell will examine the context and try to complete the rest of the word for you. If there is insufficient context to make a single match, it will display a list of all the potential matches. Tab completion also usually works with command argument values, but there are some cases where there is simply not enough context for it to know what you want, in which case you will just need to type in the argument value. You can recall your previously entered commands by repeatedly pressing the up-arrow key, and you can then navigate up and down the list using the up and down arrow keys. When you find a command you want to modify, you can use the left arrow, right arrow, and Delete keys to navigate around in a selected command to edit it. Entering a question mark character? causes the CLI to print contextual help information. You can use this character by itself, or while entering a command. If you would like to learn more about the features of the ONTAP CLI, the Advanced Concepts for NetApp ONTAP lab includes an extensive tutorial on this subject. 9

10 Caution The commands shown in this guide are often so long that they span multiple lines. When you see this, in every case you should include a space character between the text from adjoining lines. If you intend to copy and paste commands from the guide to the lab, and are dealing with multi-line commands, you can only copy one line at a time. If you try to copy multiple lines at once the commands will fail in the lab. 3.2 Route Event Messages and Command-History to an External Syslog Server Destination In this section, you configure ONTAP 9 to forward cluster and member node events to an external syslog server. New since clustered Data ONTAP 8.3.1, is the ability to also forward the command history log file entries to a designated syslog server. This works for commands entered through the ONTAP 9 CLI as well as through the NetApp Zephyr API (ZAPI), which means that management activities performed through System Manager, the NetApp PowerShell Toolkit, and the NetApp Management Software Development Kit (NMSDK) are also captured. For this lab, the designated syslog server is on a host running Red Hat Enterprise Linux version 6.6. The syslog server application is rsyslog v5, which is the standard remote syslog server daemon provided with this RHEL release. In production environments, other syslog applications may be used in place of the rsyslog. The destination IP address of this server syslog.demo.netapp.com is Once you configure remote syslog destination/routing for both the Event Management System (EMS) and the command history log entries, any ONTAP 9 configuration activities you perform in other sections of this lab will get logged to syslog. At the end of the lab you will revisit the syslog server to review those captured logs Exercise 1. In the PuTTY window for cluster1, display a list of the existing event notification destinations. An event notification destination is an address or location that receives event notifications. event notification destination show Name Type Destination snmp-traphost snmp - (from "system snmp traphost") Observe that there is no event notification destination listed for syslog. 2. Create an event notification destination named syslogger which uses the syslog server at , which corresponds to syslog.demo.netapp.com. event notification destination create -name syslogger -syslog syslog.demo.netapp.com 3. Display the updated list of event notification destinations. event notification destination show Name Type Destination snmp-traphost snmp - (from "system snmp traphost") syslogger syslog syslog.demo.netapp.com 2 entries were displayed. 4. Create an event notification filter that will be used to select (filter) which events are routed to the syslogger destination. You first create the filter, and then add a rule (or rules) that control event selection. event filter create -filter-name syslog-filter event filter rule add -filter-name syslog-filter -type include -message-name * -severity * -snmp-trap-type * 10

11 event filter test -filter-name syslog-filter 6772 events will be included in the given filter. 5. Display a list of the command-history log forwarding destinations. cluster log-forwarding show This table is currently empty. Note Notice that there are no defined destinations. 6. Create the syslog server as a new command-history log-forwarding destination. cluster log-forwarding create -destination port 514 -facility user Testing network connectivity to the destination host Display the updated list of command-history log-forwarding forwarding destinations. cluster log-forwarding show Verify Destination Host Port Protocol Server syslog.demo.netapp.com 514 udp-unencrypted false Syslog Facility user Sometimes in this lab the syslog server fails to accept the newly configured cluster logging messages. Restarting the rsyslog service on the syslog server rectifies this problem, so do that now to insure that you will have log messages available to examine at the end of this lab. 8. In PuTTY, open a session to the syslog host. Use the username root and password Netapp1!. 9. Execute the following command to restart the rsyslogd service [root@syslog ~]# service rsyslog restart Shutting down system logger [ OK ] Starting system logger [ OK ] [root@syslog ~]# Both EMS Events and Command-history records are now forwarded to the designated syslog server. Towards the end of the lab you will examine the command history captured by the syslog server. 3.3 Administrative User Account Custom Roles In this activity, you are introduced to administrative user account roles, and how you can use them to grant and restrict administrative privileges to users assigned to that role. In this exercise you will create a customized role, and then assign a newly created user account to that customized role. Every administrative user account must be assigned a role. That role specifies what capabilities your account has when you login to ONTAP 9. These capabilities dictate what you can access, what you can see, and most importantly, what you can change. ONTAP 9 includes several pre-defined roles that are used for managing account access to the cluster or SVMs. These pre-defined roles are listed in the following table. Table 5 Table Clustered Data ONTAP Pre-defines Roles 11 Cluster Pre-defined Roles Vserver (SVM) Pre-defined Roles admin vsadmin

12 Cluster Pre-defined Roles Vserver (SVM) Pre-defined Roles autosupport vsadmin-backup backup vsadmin-protocol none vsadmin-readonly readonly vsadmin-volume Roles also control ONTAP 9 user account name and password policies through role attributes that you specify as command line parameters. You can see the details of these policy attributes in the following table Table 6 Table Role Configuration Attributes Useful for Implementing Password and Login Role Attribute Parameter Description Default Value -username-minlength Minimum username length 3 required 3 -username-alphanum Username alpha-numeric disabled -passwd-minlength Minimum password length 8 required 8 -passwd-alphanum Password alpha-numeric enabled enabled -passwd-min-special-chars Minimum number of special characters required in the password 0 1 -passwd-expiry-time Password Expires In (Days) unlimited (never) 60 -require-initial-passwdupdate Require password change disabled on 1st login enabled -max-failed-login-attempts Maximum number of failed 0 attempts 6 -lockout-duration Maximum lockout period (Days) 0 = (1 day) 30 -disallowed-reuse Disallow last 'N' passwords 6 6 -change-delay Delay between password changes (Days) 0 = (no delay) 0 disabled Recommended Value When defining customized roles, use the following CLI parameters to further specify the scope of the role. Table 7 Table Role Creation Parameters 12 Parameter Description -vserver This optionally specifies the Vserver name associated with the role. -role This specifies the name of the role that is to be created.

13 Parameter Description -cmddirname This specifies the command or command directory to which the role has access. To specify the setting, use the special value DEFAULT. -access This optionally specifies an access level for the role. Possible access level settings are none, readonly, and all. The setting is all. -query This optionally specifies the object that the role is allowed to access. The query object must be applicable to the command or directory name specified by -cmddirname. The query object must be enclosed in double quotation marks ( ), and it must be a valid field name Exercise In this exercise, you create a custom role called stats, and create a user account named stat_acct that is assigned the stats role. You then login to that user account and see which access capabilities are allowed for this user. 1. In the PuTTY window for cluster1, create a new role named stats that initially has no access to any of the administrative CLI commands. security login role create -role stats -cmddirname DEFAULT -access none 2. Grant the stats role access to all of the statistics CLI commands. security login role create -role stats -cmddirname statistics -access all 3. Grant the stats role access to the security login whoami command. security login role create -role stats -cmddirname "security login whoami" -access all 4. Display the hierarchy of the command access rules for the stats role. security login role show -role stats Role Command/ Vserver Name Directory Query cluster1 stats DEFAULT security login whoami statistics 3 entries were displayed. Access Level none all all The initial ordering of the rules listed is important, as the first entry takes away all access, and the second and third rules selectively add access back to the desired commands. The fact that the second and third commands show up in a different order than you entered them is unimportant, as there is no dependency between these two commands. 5. Display the configuration attribute settings for the stats role. security login role config show -role stats -instance Vserver cluster1 13

14 Role Name Minimum Username Length Required Username Alpha-Numeric Minimum Password Length Required Password Alpha-Numeric Minimum Number of Special Characters Required In The Password Password Expires In (Days) Require Initial Password Update on First Login Maximum Number of Failed Attempts Maximum Lockout Period (Days) Disallow Last 'N' Passwords Delay Between Password Changes (Days) Delay after Each Failed Login Attempt (Secs) Minimum Number of Lowercase Alphabetic Characters Required in the Password Minimum Number of Uppercase Alphabetic Characters Required in the Password Minimum Number of Digits Required in the Password Display Warning Message Days Prior to Password Expiry (Days) Account Expires in (Days) Maximum Duration of Inactivity before Account Expiration (Days) stats 3 disabled 8 enabled 0 unlimited disabled unlimited unlimited unlimited As you can see, the username and password complexity attributes all match the values shown in the Role Configuration Attributes Useful in Implementing Password and Login table. The values are fine for this lab, but if you want to modify then you can use the security login role config modify command, along with the attributes from the table to accomplish that task. 6. Create a new user account named stat_acct on cluster1 and assign it to the stats role. When prompted for the new account#s password, enter Netapp1!. security login create -user-or-group-name stat_acct -application ssh -authmethod password -role stats Please enter a password for user 'stat_acct' Netapp1! Please enter it again Netapp1! 7. Enter just the? character in your cluster1 PuTTY session to produce a list of the CLI commands available to the admin user account.? up cluster> event> exit history job> lun> man metrocluster> network> qos> redo rows run security> set snaplock> snapmirror> statistics> storage> failover system> top volume> mirrors vserver> Go up one directory Manage clusters Manage system events Quit the CLI session Show the history of commands for this CLI session Manage jobs and job schedules Manage LUNs Display the on-line manual pages Manage MetroCluster Manage physical and virtual network connections QoS settings Execute a previous command Show/Set the rows for this CLI session Run interactive or non-interactive commands in the nodeshell The security directory Display/Set CLI session settings Manages SnapLock attributes in the system Manage SnapMirror Display operational statistics Manage physical storage, including disks, aggregates, and The system directory Go to the top-level directory Manage virtual storage, including volumes, snapshots, and Manage Vservers 14

15 The admin user is assigned the admin role, which grants full access to all of the CLI commands, so you see quite a few commands listed. Now you will log into cluster1 using the stat_acct account to see how the stats role restricts the account#s command access. 8. Open a new PuTTY session. (Do not close your existing admin user PuTTY session to cluster1, as you will need that later in this exercise). 8 Figure Double-click the saved session for cluster1. 9 Figure Log in as the stat_acct user, using the password Netapp1!. 15

16 11. Verify your login identity. whoami (security login whoami) User stat_acct 12. Press the? key to see a list of the CLI commands available to the stat_acct account..? up exit history man redo rows security> statistics> top Go up one directory Quit the CLI session Show the history of commands for this CLI session Display the on-line manual pages Execute a previous command Show/Set the rows for this CLI session The security directory Display operational statistics Go to the top-level directory Observe that the list of available commands is quite short, limited to just the statistics command, and a few navigational commands. Compare this list to the list of commands you saw available in your admin user login session. 13. Exit out of your login session for the stat_acct account. exit 3.4 Configuring Firewalls This section introduces the configuration of firewalls. Firewalls control which network protocols (services) are allowed to pass data on ONTAP 9 s network interfaces. The firewalls are services running on each node in the cluster that determine which network traffic is allowed or disallowed for each specific node s network ports, according to defined firewall policies. Firewall policies are defined and maintained by cluster administrators. Note Firewalls do not control or influence NAS data traffic. They do control how administrators and external management applications may access the cluster for management purposes, and communications between cluster peers. There are three built-in policies defined in ONTAP 9. These policies cannot be removed, however cluster administrators can define new policies to use instead of the predefined policies. The network protocol services that can be used in a policy are listed in the following table. Table 8 Table Network Protocols Allowed in Firewall Policies 16 Protocol Description dns Use for Domain Name Services http Hyper-text transfer protocol (not recommended) https Secure Hyper-text transfer protocol (recommended over HTTP) ndmp Network Data Management Protocol ndmps Secure Network Data Management Protocol (recommended over NDMP) ntp Network Time Protocol

17 Protocol Description rsh Remote Shell (highly discouraged and not recommended, disabled by ) snmp Simple Network Management Protocol ssh Secure Shell telnet Telnet Protocol (highly discouraged and not recommended, disabled by ) The following table lists the configuration of the built-in firewall policies. Table 9 Table Built-in Firewall Policies Built-In Name Default Protocol Entries and Allowed Networks data dns /0 ndmp /0 ndmps /0 https /0 ndmp /0 ndmps /0 dns /0 http /0 https /0 ndmp /0 ndmps /0 ntp /0 snmp /0 ssh /0 intercluster mgmt Each policy will contain one (1) or more entries that specify which network protocol service to allow, and a list of the valid IP networks and IP addresses that are allowed to access that network service. The absence of a particular network protocol service entry prevents any access using that protocol over the network interfaces that rely on that firewall policy. The firewall commands are located in the system services firewall command sub-directory, and the system services firewall policy sub-directory beneath that. The following tables list the commands, and their purpose. Table 10 Table Cluster System Service Firewall Commands 17 Command Purpose modify Change the status of the firewall running on a cluster node. policy> Navigate into the policy commands sub-directory. show Show the current status of the firewall(s).

18 Table 11 Table Cluster System Service Firewall Commands Command Purpose clone Clone (copy) an existing firewall policy. create Create a firewall policy entry for a network service. delete Remove a service from a firewall policy. modify Modify a firewall policy entry for a network service. show Show firewall policies Exercise For this exercise, you will perform the following tasks Create two new firewall policies, one for the cluster management level, and one specifically for an SVM running in the cluster. Remove unwanted protocols from the policy. Restrict the remaining protocols to a specific network subnet. In practice, you would typically build upon these steps by applying these firewall polices to network interfaces, but you will not be taking that step in this lab. 1. Using your PuTTY session for cluster1, create a new policy named mgmt2 for the cluster SVM cluster1 that permits SSH protocol access to just the /24 subnet. system services firewall policy create -vserver cluster1 -policy mgmt2 -service ssh -allow-list /24 2. Add to the mgmt2 policy DNS protocol access for just the /24 subnet. system services firewall policy create -vserver cluster1 -policy mgmt2 -service dns -allow-list /24 3. Add to the mgmt2 policy https protocol https access for just the /24 subnet. system services firewall policy create -vserver cluster1 -policy mgmt2 -service https -allow-list /24 4. Add to the mgmt2 policy ntp protocol access for just the /24 subnet. system services firewall policy create -vserver cluster1 -policy mgmt2 -service ntp -allow-list /24 5. Create a new policy named cifs_mgmt2 for the SVM cifs_svm that permits SSH protocol access to just the /24 subnet. system services firewall policy create -vserver cifs_svm -policy cifs_mgmt2 -service ssh -allow-list /24 6. Add to the cifs_mgmt2 policy DNS protocol access for just the /24 subnet. system services firewall policy create -vserver cifs_svm -policy cifs_mgmt2 -service dns -allow-list /24 18

19 7. List the new policies you just created. system services firewall policy show Vserver Service Allowed cifs_svm cifs_mgmt2 dns /24 ssh /24 cluster1 data dns /0 ndmp /0 ndmps /0 cluster1 intercluster https /0 ndmp /0 ndmps /0 cluster1 mgmt dns /0 http /0 https /0 ndmp /0 ndmps /0 ntp /0 snmp /0 ssh /0 cluster1 mgmt2 dns /24 https /24 ntp /24 ssh /24 20 entries were displayed. 3.5 Configure SSH ONTAP administrators frequently use the Secure Shell (SSH) protocol for command line access to ONTAP controllers. How secure those network connections are depends on which key-exchange algorithms and encryption ciphers you are allowed to use. The basic SSH protocol supports a number of different algorithms and ciphers, some more secure than others. SSH services in ONTAP support four (4) different key-exchange algorithms, and seven (7) different ciphers. These are listed in the following table, ordered from most secure to least. Table 12 SSH Supported Encryption Ciphers and Key-Exchange Algorithms 19 Key Exchange Algorithms Encryption Ciphers MAC Algorithms diffie-hellman-group-exchangesha256 aes256-ctr hmac-sha1, hmac-sha1-96 diffie-hellman-group-exchange-sha1 aes192-ctr hmac-sha2-256 diffie-hellman-group14-sha1 aes128-ctr hmac-sha2-512 ecdh-sha2-nistp256 aes256-cbc hmac-sha1-etm ecdh-sha2-nistp384 aes192-cbc hmac-sha1-96-etm ecdh-sha2-nistp521 aes128-cbc hmac-sha2-256-etm curve25519-sha256 3des-cbc hmac-sha2-512-etm aes128-gcm hmac-md5, hmac-md5-96

20 Key Exchange Algorithms Encryption Ciphers MAC Algorithms aes256-gcm hmac-ripemd160 umac-64 umac-128 hmac-md5-etm hmac-md5-96-etm hmac-ripemd160-etm umac-64-etm umac-128-etm By restricting the available ciphers and algorithms, administrators can force the use of more secure SSH clients when connecting to the ONTAP 9 cluster, or SVM management network interfaces. Using algorithms and ciphers with larger key lengths will also help deter man-in-the-middle eaves-dropping on SSH connections, and possible disclosure of critical login credentials. ONTAP 9 maintains a configuration for the cluster administration SVM, and each other SVM that allows SSH access. In the ONTAP CLI you use the security ssh command to configure which SSH key-exchange algorithms, encryption ciphers, and MAC algorithms are permissible for SSH connections to the controller Exercise In this lab activity, you list the current SSH configuration for the ONTAP 9 cluster SVM (i.e., cluster1), and then modify that configuration to remove less secure ciphers. 1. In your PuTTY session to cluster1, view the cluster s current SSH configuration. security ssh show -vserver cluster1 Vserver cluster1 Key Exchange Algorithms diffie-hellman-group-exchange-sha256, diffie-hellman-group-exchange-sha1, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, curve25519-sha256 Ciphers aes256-ctr, aes192-ctr, aes128-ctr, aes256-cbc, aes192-cbc, aes128-cbc, 3des-cbc, aes128-gcm, aes256-gcm MAC Algorithms hmac-sha1, hmac-sha1-96, hmac-md5, hmac-md5-96, hmac-ripemd160, umac-64, umac-128, hmac-sha2-256, hmac-sha2-512, hmac-sha1-etm, hmac-sha1-96-etm, hmac-sha2-256-etm, hmac-sha2-512-etm, hmac-md5-etm, hmac-md5-96-etm, hmac-ripemd160-etm, umac-64-etm, umac-128-etm Note The command to simultaneously change key-exchange algorithms, ciphers, and hashing algorithms is very long, and prone to typing errors in this lab. For brevity, this exercise will only focus on changing the encryption ciphers; the procedure for changing key-exchange algorithms and hashing algorithms is very similar. 2. Refine the SSH configuration for the cluster1 SVM so it only accepts the more secure algorithms. security ssh modify -vserver cluster1 -ciphers aes256-ctr,aes192-ctr,aes128-ctr Warning You have updated the SSH configuration settings for admin Vserver "cluster1". All newly created data Vservers will inherit this new setting. To modify an individual data Vserver's configuration, use the "security ssh" commands. 20

21 Caution Modifications to the cluster SSH configuration become the for any newly created SVMs that enable SSH management access. Pre-existing SVMs retain their previous SSH configuration. 3. View the cluster's SSH configuration again. security ssh show -vserver cluster1 Vserver cluster1 Key Exchange Algorithms diffie-hellman-group-exchange-sha256, diffie-hellman-group-exchange-sha1, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, curve25519-sha256 Ciphers aes256-ctr, aes192-ctr, aes128-ctr MAC Algorithms hmac-sha1, hmac-sha1-96, hmac-md5, hmac-md5-96, hmac-ripemd160, umac-64, umac-128, hmac-sha2-256, hmac-sha2-512, hmac-sha1-etm, hmac-sha1-96-etm, hmac-sha2-256-etm, hmac-sha2-512-etm, hmac-md5-etm, hmac-md5-96-etm, hmac-ripemd160-etm, umac-64-etm, umac-128-etm Cluster1 now only accepts a more limited set of ciphers, but other SVMs still retains their previous SSH configuration. 3.6 Configure CLI Session Timeouts Because administrators routinely manage systems from centralized, remote locations, they may do a lot of multitasking and lose track of CLI sessions they have open on various systems and ONTAP 9 storage clusters. On other occasions, they may be called away from their workstations in order to deal with some other situations. Leaving an unattended, open connection to a critical resource can pose a serious security risk, as a passer-by may see or have access to something that they are not authorized to see. To help minimize this risk, ONTAP 9 allows you to configure an inactivity timeout feature for CLI type sessions. Since there is no session-lock feature in ONTAP 9, any logged in session that is idle for more than the inactivity time limit will be terminated Exercise In this exercise, you modify the CLI session timeout value (in minutes) from the ONTAP 9 of 30 minutes, to a new value of 10 minutes. 1. In your PuTTY session to cluster1, view your current timeout for CLI sessions. system timeout show CLI session timeout 0 minutes Your current system timeout is 0 minutes, which means the CLI session will never time out. (Newly installed ONTAP 9 will have a value of 30 minutes.) 2. Change the CLI timeout to 10 minutes. system timeout modify -timeout View your current CLI timeout again. system timeout show 21

22 CLI session timeout 10 minutes Note When a CLI session times out in this lab, the associated PuTTY window closes. To avoid the inconvenience of having console sessions close on you during this lab, you might want to consider disabling timeouts entirely by setting the timeout value to Configure SSL/TLS Some management features of ONTAP 9 require the existence of certain core web services running on cluster member nodes. The management features might include the following Web Browser access to the on-board OnCommand System Manager GUI. Access by other OnCommand products to the built-in ONTAP 9 ontapi interface (using HTTP, or HTTPS protocols). By, the core web services are enabled at time of installation. This allows external web clients access to the exported web content. Enabling these services does not guarantee visibility to clients, only that ONTAP is capable of exporting such content. The system services firewall policies actually determine which web protocols (HTTP, HTTPS, or both) are visible on a management interface. Note To enable HTTPS access only, use a custom firewall policy that excludes HTTP as a protocol. The HTTPS service supports the following SSL (Secure Socket Layer) capabilities TLSv1, TLSv1.1, TLSv1.2 (Transport Layer Security version 1) is enabled by. SSLv3 (Secure Socket Layer version 3) which is disabled by. SSL FIPS compliance which is disabled by. Note SSLv3 and FIPS are mutually exclusive. Enabling FIPS mode disables SSLv3. Assuming that HTTPS is allowed in the current firewall policies, access by an external HTTPS client is determined by the following rules Table 13 Table HTTPS Client Access Rules SSL Setting For Access, Client Must SSLv3 Enabled Client has access with SSLv3 or TLSv1/TLSv1.1/ TLSv1.2 (SSLv3 being enabled is not recommended) SSLv3 Disabled Client has access with TLSv1, TLSv1.1, and TLSv1.2 only (recommend enabling TLSv1.1 and TLSv1.2 only) FIPS Enabled Client has access with TLSv1.2 and TLSv1.1 if FIPS compliant Exercise In this exercise, you will perform the following tasks 22 View the current Web Core Services settings and status (both from a cluster and member node perspective). Disable web services. Try connection from a web browser. Enable web services. Try connection from a web browser.

23 View SSL/TLS configuration settings and status. 1. In your PuTTY session for cluster1, display the current availability of web services on the cluster. system services web show External Web Services true Status online HTTP Protocol Port 80 HTTPS Protocol Port 443 HTTP Enabled true 2. Display the operational configuration for the web server processes on the nodes in the cluster. system services web node HTTP HTTP Node External Enabled Port cluster1-01 true true 80 show HTTPS Total Total Port Status HTTP Requests Bytes Served online Disable remote client access to HTTP and HTTPS service content hosted on the cluster. system services web modify -external false 4. On the desktop of Jumphost, launch the Chrome web browser by clicking on the Chrome icon found on the taskbar. 4 Figure 3-5 The Chrome browser opens. 5. Chrome is preconfigured to automatically connect to cluster1 s OnCommand System Manager login page. Since you disabled web services to external clients, the browser should display a message stating This site can't be reached, cluster1 refused to connect. If Chrome does not display this message in your lab, place your cursor at the end of the URL and hit the Enter key to reload the page. This should correct the problem. 23

24 5 Figure In your PuTTY session to cluster1, re-enable web services. system services web modify -external true 7. Refresh your Chrome browser page. 24

25 7 Figure 3-7 The OnCommand System Manager login page now comes up successfully. 8. In your PuTTY session to cluster1, verify the current SSL/TLS/FIPS configuration of your ONTAP 9 cluster. To do this, you must first elevate your admin privilege to advanced, allowing access to the security/config commands. Then you may show the configuration. set -privilege advanced Warning These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel. Do you want to continue? {y n} y cluster1*> security config show Cluster Interface FIPS Mode Supported Protocols Supported Ciphers SSL false TLSv1.2, TLSv1.1 ALL!RC4!LOW!aNULL!EXP!eNULL 25 Cluster Security Config Ready yes

26 cluster1*> Notice that even though FIPS Mode is not enabled, only the protocols TLSv1.2 and TLSv1.1 are in use. Also notice that the!rc4 appearing in the supported ciphers indicates the RC4 ciphers are not allowed. 9. Now display the status of nodes in the ONTAP 9 cluster to verify that none require a reboot in order to implement the current configuration. cluster1*> security Nodes in Cluster cluster1-01 config status show Reboot Needed false cluster1*> 10. Return your CLI session back to admin privilege level. cluster1*> set -privilege admin 3.8 NFS/CIFS Export Policies This section introduces the topic of NAS (NFS and SMB) export policies. Export policies are used to restrict NAS access to specific clients. These access restrictions are based on the client host s identity (determined by the host s IP address or subnet), as opposed to an ACL which enforces restrictions based on the identity of the accessing user or group. As of Clustered Data ONTAP 8.2, assigning export policies for SMB (CIFS) access is optional. Many customers are able to sufficiently meet their CIFS access control requirements solely through the implementation of ACLs, but customers with more stringent CIFS security requirements can opt to use a combination of CIFS export policies and ACLs to enforce even greater protection. Export policies are mandatory for NFS. A client cannot mount an NFS volume or qtree if there is no associated export policy. When you create a volume for an SVM, ONTAP 9 automatically creates a export policy. It is not populated with any rules. You must explicitly add the rules required to allow client access to NAS data. When you create a CIFS service for an SVM, by the CIFS export policy is disabled. To enable the export policy, issue the vserver cifs options modify command at the advanced privilege level. If the CIFS service option for using export policies is disabled, then CIFS shares do not require an export policy to operate. Note You must still create CIFS shares to allow external client access to data over CIFS. Just creating an export policy does not automatically export the data through the CIFS protocol. On the other hand, data served through NFS is exported immediately after NFS-centric rules are added to an applied export policy. Export policies are simple containers that hold the rules used for access validation. The policy, itself, has a name and is associated with the SVM that owns it. Export policies contain zero (0) or more rules, and access rules must be added to an empty (0 rules) policy before any NAS data can be accessed by clients. These rules contain the following components Table 14 Table Export Rule Components 26 Component Purpose vserver SVM holding the export policy policy The export policy name rule index relative placement (index) of rule within the policy (starting at 1) client match How the client(s) is/are identified

27 Component Purpose access protocol Protocol used to access the exported/shared data read-only access rule (security type) (security type) any - Any current or future protocol nfs - Any current or future version of NFS nfs3 - The NFSv3 protocol nfs4 - The NFSv4 protocol cifs - The CIFS protocol flexcache The FlexCache protocol One or more authentication methods allowed for readonly access read/write access rule Hostname IPv4 address IPv6 address IPv4 subnet Ipv6 subnet Netgroup Domain sys - AUTH_SYS request krb5 - Kerberos v5 request krb5i - Kerberos v5 with integrity request ntlm - CIFS NTLM request any - match on all types of access request none - allow access as anonymous user never - disallow any type of access request Same access method requests as defined in the readonly access description. anonymous user map User ID to which anonymous users are mapped (65534 ) superuser access rule Same access method requests as defined in the readonly access description with the exception of "never". (security type) allow suid flag Honor SetUID bits in SETATTR when true () allow dev flag Allow creation of devices is true (). Access rules are processed sequentially in ascending index order. Placing more restrictive rules before others may prevent access being granted. In addition, a client can only get read-write access for a specific security type if the export rule also allows read-only access for that security type. If the read-only parameter is more restrictive than the read-write parameter, the client might not get read-write access CIFS Exercise In this exercise you enable CIFS export policy enforcement on the SVM cifs_svm, configure two CIFS export policies, and then apply them to the cifsdv1 and cisfdv2 SVM s volumes as detailed in the CIFS Exercise Export Policies table. You will also verify that these policies properly grant or deny access to two different Windows clients in the lab. 27

28 Table 15 CIFS Exercise Export Policies Volume Export Rule Resulting Access cifs_svm_root 1 Grant read-write access to all CIFS clients in the lab IP subnet. cifsdv1 cifs_pol1 1 Grant read-only and read-write access to the client WIN2K12R2 2 Deny access to all other clients 1 Grant read-only access to the client "WIN2K12R2". 2 Deny access to all other clients cifsdv2 cifs_pol2 1. In the PuTTY session for cluster1, switch to advanced mode. set advanced -confirmations off cluster1*> 2. Determine whether CIFS export policy enforcement is enabled for the SVM cifs_svm. cluster1*> vserver cifs options show -vserver cifs_svm -fields is-exportpolicy-enabled vserver is-exportpolicy-enabled cifs_svm false cluster1*> 3. Enable CIFS export policy enforcement for the SVM cifs_svm. cluster1*> vserver cifs options modify -vserver cifs_svm -is-exportpolicy-enabled true cluster1*> Note You can still configure CIFS export policies and rules and apply them to volumes if the vserver s is-exportpolicy-enabled CIFS option is not enabled, but those policies, rules, and assignments will be ignored by ONTAP until the SVM's is-exportpolicy-enabled option is set to true. 4. Leave advanced mode. cluster1*> set admin 5. List the volumes that reside on the SVM cifs_svm. volume show -vserver cifs_svm Vserver Volume Aggregate State cifs_svm cifs_svm_root aggr_data1 online cifs_svm cifsdv1 aggr_data1 online cifs_svm cifsdv2 aggr_data1 online 3 entries were displayed. Type Size Available Used% RW 20MB 18.85MB 5% RW 10GB 9.50GB 5% RW 10GB 9.50GB 5% 6. View the export policy assignments for each volume. volume show -vserver cifs_svm -fields policy vserver volume policy cifs_svm cifs_svm_root cifs_svm cifsdv1 cifs_svm cifsdv2 3 entries were displayed. For CIFS, export policies can only be applied to volumes. The output lists three volumes, all of which are using the export policy. The volume names match those in the CIFS Exercise Export Rules 28

29 table shown earlier in this exercise, but if you look closely, the assigned export policies do not (yet) all match what is in that table. That is because you will configure these policies later in this exercise. 7. View the current list of export policies. vserver export-policy show Vserver Name cifs_svm nfs_svm 2 entries were displayed. A policy s scope is limited to a single SVM. As you can see, both cifs_svm and nfs_svm have an export policy named, but these are in fact two separate export policies. Clustered Data ONTAP automatically creates the policy when you create the SVM. 8. View the rules for cifs_svm's export policies. vserver export-policy rule show -vserver cifs_svm There are no entries matching your query. There are no export rules at present. When a policy is created it does not contain any rules, and without any rules all mount requests for a volume assigned that policy will be denied. 9. Create a rule in the export policy that will allow all CIFS clients on the lab s local network. vserver export-policy rule create -vserver cifs_svm -policyname -ruleindex 1 -protocol cifs -clientmatch /24 -rorule krb5 -rwrule krb5 10. View the rules for cifs_svm s export policies again. vserver export-policy rule show -vserver cifs_svm Rule Access Client Vserver Name Index Protocol Match cifs_svm 1 cifs /24 RO Rule krb5 Observe that this command only shows a partial set of the rule parameters you specified when you created the rule. 11. View the details of the rules for the export policy. vserver export-policy rule show -vserver cifs_svm -policyname -instance Vserver Name Rule Index Access Protocol Client Match Hostname, IP Address, Netgroup, RO Access Rule RW Access Rule User ID To Which Anonymous Users Are Mapped Superuser Security Types Honor SetUID Bits in SETATTR Allow Creation of Devices cifs_svm 1 cifs or Domain /24 krb5 krb none true true Now you can see the full set of rule properties. This rule grants read-only and read-write access to any CIFS host on the lab s local network ( /24). The krb5 value on the access rule authorizes Kerberos 5 authentication, which is the authentication method used by the Windows 2012 hosts in this lab. The properties that you did not explicity specify were populated with values, but since these extra properties are not important for this exercise, this guide does not explore them further here. Now create a new, more restrictive policy and assign it to the cifsdv1 share. 29

30 12. Create a new policy named cifs_pol1 for the SVM cifs_svm. vserver export-policy create -vserver cifs_svm -policyname cifs_pol1 13. Observe that this newly created export policy contains no rules. vserver export-policy rule show -vserver cifs_svm -policyname cifs_pol1 There are no entries matching your query. 14. Add a rule to this policy granting read and read-write access to the IP address assigned to the WIN2K12R2 host. vserver export-policy rule create -vserver cifs_svm -policyname cifs_pol1 -ruleindex 1 -protocol cifs -clientmatch rorule krb5 -rwrule krb5 15. Add another rule to this policy that denies access to all other hosts. vserver export-policy rule create -vserver cifs_svm -policyname cifs_pol1 -ruleindex 2 -protocol any -clientmatch /0 -rorule never -rwrule never While this rule is not strictly necessary, as the first rule will only grant explicit access to the host (implying that all others will be denied), it is good security practice to explicitly deny any hosts that you want to exclude as an extra layer of protection. 16. View the details of the rules for the cifs_pol1 export policy. vserver export-policy rule show -vserver cifs_svm -policyname cifs_pol1 -instance Vserver Name Rule Index Access Protocol Client Match Hostname, IP Address, Netgroup, RO Access Rule RW Access Rule User ID To Which Anonymous Users Are Mapped Superuser Security Types Honor SetUID Bits in SETATTR Allow Creation of Devices cifs_svm cifs_pol1 1 cifs or Domain krb5 krb none true true Vserver Name Rule Index Access Protocol Client Match Hostname, IP Address, Netgroup, RO Access Rule RW Access Rule User ID To Which Anonymous Users Are Mapped Superuser Security Types Honor SetUID Bits in SETATTR Allow Creation of Devices 2 entries were displayed. cifs_svm cifs_pol1 2 any or Domain /0 never never none true true As you saw in the CIFS Exercise Export Policies table, the cifs_pol1 policy grants read-only and read-write access to the host WIN2K12R2, and denies access to all others. 17. Apply this export policy to the volume cifsdv1. volume modify -vserver cifs_svm -volume cifsdv1 -policy cifs_pol1 Volume modify successful on volume cifsdv1 of Vserver cifs_svm. 30

31 18. Create the cifs_pol2 policy. vserver export-policy create -vserver cifs_svm -policyname cifs_pol2 19. Create a rule for this policy granting read-only access to the host WIN2K12R2. vserver export-policy rule create -vserver cifs_svm -policyname cifs_pol2 -ruleindex 1 -protocol cifs -clientmatch rorule krb5 -rwrule none 20. Add another rule to this policy denying access to all other hosts. vserver export-policy rule create -vserver cifs_svm -policyname cifs_pol2 -ruleindex 2 -protocol any -clientmatch /0 -rorule never -rwrule never 21. View the rules for the cifs_pol2 policy. vserver export-policy rule show -vserver cifs_svm -policyname cifs_pol2 -instance Vserver Name Rule Index Access Protocol Client Match Hostname, IP Address, Netgroup, RO Access Rule RW Access Rule User ID To Which Anonymous Users Are Mapped Superuser Security Types Honor SetUID Bits in SETATTR Allow Creation of Devices cifs_svm cifs_pol2 1 cifs or Domain krb5 none none true true Vserver Name Rule Index Access Protocol Client Match Hostname, IP Address, Netgroup, RO Access Rule RW Access Rule User ID To Which Anonymous Users Are Mapped Superuser Security Types Honor SetUID Bits in SETATTR Allow Creation of Devices 2 entries were displayed. cifs_svm cifs_pol2 2 any or Domain /0 never never none true true 22. Apply the cifs_pol2 export policy to the cifsdv2 volume. volume modify -vserver cifs_svm -volume cifsdv2 -policy cifs_pol2 Volume modify successful on volume cifsdv2 of Vserver cifs_svm. One method to test whether these policies and rules accomplish what you want is to log into the listed clients and attempt to access the applicable shares. However, this would be a labor-intensive exercise, especially if you are dealing with a large number of shares, rules, and clients. Alternately, you can test the processing of the rules directly from the ONTAP CLI using the vserver export-policy check-access command. 23. In the PuTTy session for cluster1, test to see if WIN2K12R2 has read access to the cifsdv1 share over the CIFS protocol using Kerberos 5 authentication. You have to use the client s IP address for this test, which in the case of WIN2K12R2 is vserver export-policy check-access -vserver cifs_svm -volume cifsdv1 -protocol cifs -authentication-method krb5 -client-ip access-type read Rule Path Owner Owner Type Index Access / cifs_svm_root volume 1 read 31

32 /cifsdv1 2 entries were displayed. cifs_pol1 cifsdv1 volume 1 read The output shows the complete access path to the volume, first through the root volume of the cifs_svm SVM's namespace (volume cifs_svm_root, path / ), then through the cifsdv1 volume. As you can see, the client has read access through each of those paths. 24. Test to see if WIN2K12R2 has read-write access to the cifsdv1 volume over the CIFS protocol using Kerberos 5 authentication. vserver export-policy check-access -vserver cifs_svm -volume cifsdv1 -protocol cifs -authentication-method krb5 -client-ip access-type read-write Rule Path Owner Owner Type Index Access / cifs_svm_root volume 1 read /cifsdv1 cifs_pol1 cifsdv1 volume 1 read-write 2 entries were displayed. WIN2K12R2 has read-write access to the path /cifsdv Test to see if Jumphost has read access to the cifsdv1 volume over the CIFS protocol using Kerberos 5 authentication. The IP address for Jumphost is vserver export-policy check-access -vserver cifs_svm -volume cifsdv1 -protocol cifs -authentication-method krb5 -client-ip access-type read Rule Path Owner Owner Type Index Access / cifs_svm_root volume 1 read /cifsdv1 cifs_pol1 cifsdv1 volume 2 denied 2 entries were displayed. Read access is denied at the /cifsdv1 volume level. 26. Test to see if Jumphost has read-write access to the cifsdv1 volume over the CIFS protocol using Kerberos 5 authentication. vserver export-policy check-access -vserver cifs_svm -volume cifsdv1 -protocol cifs -authentication-method krb5 -client-ip access-type read-write Rule Path Owner Owner Type Index Access / cifs_svm_root volume 1 read /cifsdv1 cifs_pol1 cifsdv1 volume 2 denied 2 entries were displayed. Write access is also denied at the /cifsdv1 level. 27. On the desktop of Jumphost, open Windows Explorer. 32

33 27 Figure In Windows Explorer, in the navigation pane select This PC. 29. On the menu bar click Computer. 30. Click Map Network Drive Figure 3-9 The Map Network Drive window opens. 31. Set the fields in the window as follows Drive X Folder \\cifs\cifsdv1 Leave the Reconnect at sign-in checkbox unchecked. In this lab, DNS is configured to use the hostname cifs for the IP address assigned to the SVM cifs_svm. 32. Click Finish. 33

34 31 32 Figure 3-10 The Windows Security window opens. 33. If you are prompted for login credentials, specify the account DEMO\Administrator and the password Netapp1!, then click OK. 34

35 33 Figure Note that the window reports Access is denied. Windows attempted to use your login credentials to access the share, but was unable to because the export policy rules denied access. Windows does not understand the reason for the denial, it just assumes that you need different credentials which is why it prompts you for a login and password. But regardless of which credentials you enter, the access policy rules prevent you from accessing this share from Jumphost. 35. Click the Cancel button Figure 3-12 The Windows Security window closes, and focus returns to the Map Network Drive window. 35

36 36. Click Cancel. 36 Figure 3-13 The Map Network Drive window closes. In order to save time, you will not check access to the cifsdv1 share from WIN2K12R2 host in this exercise because you will use that share in the SMB (CIFS) ACLs exercise later in this guide. This will clearly demonstrate that the host WIN2K12R2 can access that share NFS Exercise In this exercise you create an NFS export policies for the nfs_svm SVM and apply it to the qt1 qtree of the nfsdvs 1 volume, as detailed in the NFS Exercise Export Policies table. You also verify that this policy properly grants/ denies access to two different Linux clients in the lab. Table 16 NFS Exercise Export Policies 36 Volume Qtree Export Rule Resulting Access nfsdv1 1 Grant access to underlying qtrees, directories, and files to all NFS clients in the lab IP subnet. qt1 nfs_pol1 1 Grant read-write access to client rhel1 using protocol NFSv4 and AUTH_SYS security 2 Grant read-only access to client rhel1 using protocol NFSv3 and AUTH_SYS security

37 Volume Qtree qt2 Export Rule Resulting Access 3 Grant read-only access to client rhel2 using protocol NFSv4 and AUTH_SYS security 4 Prohibit access to client rhel2 if protocol is other than NFSv4 1 Grant access to underlying qtrees, directories, and files to all NFS clients in the lab IP subnet. The nfs_svm SVM, the nfsdv1 volume, and the qt1 and qt2 qtrees have all been pre-created for you. NFS has also been pre-configured for the nfs_svm to support the NFSv3, NFSv4, and NFSv4.1 protocols. The Linux clients for which you configure the export policies to support are rhel1 (IP address ) and rhel2 (IP address ). 1. In the PuTTY session for cluster1, display the list of policies for the svm nfs_svm. vserver export-policy show -vserver nfs_svm Vserver Name nfs_svm When you first create an SVM, ONTAP 9 automatically creates an empty export policy named. When you create a new volume, ONTAP 9 automatically assigns the export policy to that volume. When you create a qtree, that qtree inherits the parent volume s export policy assignment. 2. Display the list of rules of the policy for the SVM nfs_svm. vserver export-policy rule show -vserver nfs_svm -policyname There are no entries matching your query. The export policy contains no rules, as is the case for any newly created export policy. 3. Add a rule to the policy that grants read-only access to any client on the labs local network ( /24). vserver export-policy rule create -vserver nfs_svm -policyname -clientmatch /24 -protocol any -rorule any -rwrule never -superuser none -anon ruleindex 1 4. Display the updated list of rules for the policy. vserver export-policy rule show -vserver nfs_svm -policyname Rule Access Client RO Vserver Name Index Protocol Match Rule nfs_svm 1 any /24 any 5. Create a new policy named nfs_pol1. vserver export-policy create -vserver nfs_svm -policyname nfs_pol1 6. Add a rule to the nfs_pol1 policy that grants NFSv4 read-write access to rhel1 (IP address ). vserver export-policy rule create -vserver nfs_svm -policyname nfs_pol1 -clientmatch protocol nfs4 -rorule sys -rwrule sys -allow-suid true -allow-dev false -superuser sys -anon ruleindex 1 37

38 7. Add a rule to the nfs_pol1 policy that grants NFS v3 read access to rhel1. vserver export-policy rule create -vserver nfs_svm -policyname nfs_pol1 -clientmatch protocol nfs3 -rorule sys -rwrule never -allow-suid false -allow-dev false -superuser none -anon ruleindex 2 8. Add a rule to the nfs_pol1 policy that grants NFS v4 read access to rhel2 (IP address ). vserver export-policy rule create -vserver nfs_svm -policyname nfs_pol1 -clientmatch protocol nfs4 -rorule sys -rwrule never -allow-suid false -allow-dev false -superuser none -anon ruleindex 3 9. Add a rule to the nfs_pol1 policy that denies access to rhel2 via any other protocol than NFSv4. vserver export-policy rule create -vserver nfs_svm -policyname nfs_pol1 -clientmatch protocol any -rorule never -rwrule never -allow-suid false -allow-dev false -superuser none -anon ruleindex Display the updated list of rules for the nfs_pol1 policy. vserver export-policy rule show -vserver nfs_svm -policyname nfs_pol1 Rule Access Client RO Vserver Name Index Protocol Match Rule nfs_svm nfs_pol1 1 nfs sys nfs_svm nfs_pol1 2 nfs sys nfs_svm nfs_pol1 3 nfs sys nfs_svm nfs_pol1 4 any never 4 entries were displayed. 11. List the qtrees on the nfs_svm SVM, along with their assigned export policy. volume qtree show -vserver nfs_svm -fields export-policy vserver volume qtree export-policy nfs_svm nfs_svm_root "" nfs_svm nfsdv1 "" nfs_svm nfsdv1 qt1 nfs_svm nfsdv1 qt2 4 entries were displayed. The volume qtree show command output does not ordinarily include export policy assignment information, but as you have seen, you can print all of the available fields in a non-table format by using the -instance parameter. The -fields parameter you used here allows you to selectively list the names of just the specific fields you want to display while retaining the table format. The output shows that the all the qtrees are currently assigned the export policy. When a qtree is created it inherits the export policy associated with it's parent volume. 12. Change the export policy assignment for qtree qt1 to nfs_pol1. volume qtree modify -vserver nfs_svm -volume nfsdv1 -qtree qt1 -export-policy nfs_pol1 13. Display the updated qtree export policy assignments. volume qtree show -vserver nfs_svm -fields export-policy vserver volume qtree export-policy nfs_svm nfs_svm_root "" 38

39 nfs_svm nfsdv1 "" nfs_svm nfsdv1 qt1 nfs_svm nfsdv1 qt2 4 entries were displayed. nfs_pol1 Now test the proper configuration and application of these export policies relative to the rhel1 NFS client by issuing the vserver export-policy check-access command. 14. Test to see if rhel1 has read access to the qt1 qtree over the NFSv4 protocol using sys authentication. You have to use the client s IP address for this test, which in the case of rhel1 is vserver export-policy check-access -vserver nfs_svm -volume nfsdv1 -authentication-method sys -client-ip qtree qt1 -protocol nfs4 -access-type read Rule Path Owner Owner Type Index Access / nfs_svm_root volume 1 read /nfsdv1 nfsdv volume 1 read /nfsdv1/qt1 nfs_pol1 qt1 qtree 1 read 3 entries were displayed. Access is allowed. 15. Test to see if rhel1 has read-write access to the qt1 qtree over the NFSv4 protocol using sys authentication. vserver export-policy check-access -vserver nfs_svm -volume nfsdv1 -authentication-method sys -client-ip qtree qt1 -protocol nfs4 -access-type read-write Rule Path Owner Owner Type Index Access / nfs_svm_root volume 1 read /nfsdv1 nfsdv1 volume 1 read /nfsdv1/qt1 nfs_pol1 qt1 qtree 1 read-write 3 entries were displayed. Access is allowed. 16. Test to see if rhel1 has read access to the qt1 qtree over the NFSv3 protocol using sys authentication. vserver export-policy check-access -vserver nfs_svm -volume nfsdv1 -authentication-method sys -client-ip qtree qt1 -protocol nfs3 -access-type read Rule Path Owner Owner Type Index Access / nfs_svm_root volume 1 read /nfsdv1 nfsdv1 volume 1 read /nfsdv1/qt1 nfs_pol1 qt1 qtree 2 read 3 entries were displayed. Access is allowed. 17. Test to see if rhel1 has read-write access to the qt1 qtree over the NFSv3 protocol using sys authentication. vserver export-policy check-access -vserver nfs_svm -volume nfsdv1 -authentication-method sys -client-ip qtree qt1 -protocol nfs3 -access-type read-write Rule Path Owner Owner Type Index Access / nfs_svm_root volume 1 read /nfsdv1 nfsdv1 volume 1 read /nfsdv1/qt1 nfs_pol1 qt1 qtree 2 denied 3 entries were displayed. 39

40 Access is denied. Now test the proper configuration and application of these export policies relative to the rhel2 NFS client, again by issuing the vserver export-policy check-access command. 18. Test to see if rhel2 has read access to the qt1 qtree over the NFSv4 protocol using sys authentication. vserver export-policy check-access -vserver nfs_svm -volume nfsdv1 -authentication-method sys -client-ip qtree qt1 -protocol nfs4 -access-type read Rule Path Owner Owner Type Index Access / nfs_svm_root volume 1 read /nfsdv1 nfsdv1 volume 1 read /nfsdv1/qt1 nfs_pol1 qt1 qtree 3 read 3 entries were displayed. Access is allowed. 19. Test to see if rhel2 has read-write access to the qt1 qtree over the NFSv4 protocol using sys authentication. vserver export-policy check-access -vserver nfs_svm -volume nfsdv1 -authentication-method sys -client-ip qtree qt1 -protocol nfs4 -access-type read-write Rule Path Owner Owner Type Index Access / nfs_svm_root volume 1 read /nfsdv1 nfsdv1 volume 1 read /nfsdv1/qt1 nfs_pol1 qt1 qtree 3 denied 3 entries were displayed. Access is denied. 20. Test to see if rhel2 has read access to the qt1 qtree over the NFSv3 protocol using sys authentication. vserver export-policy check-access -vserver nfs_svm -volume nfsdv1 -authentication-method sys -client-ip qtree qt1 -protocol nfs3 -access-type read Rule Path Owner Owner Type Index Access / nfs_svm_root volume 1 read /nfsdv1 nfsdv1 volume 1 read /nfsdv1/qt1 nfs_pol1 qt1 qtree 4 denied 3 entries were displayed. Access is denied. 21. Test to see if rhel2 has read-write access to the qt1 qtree over the NFSv3 protocol using sys authentication. vserver export-policy check-access -vserver nfs_svm -volume nfsdv1 -authentication-method sys -client-ip qtree qt1 -protocol nfs3 -access-type read-write Rule Path Owner Owner Type Index Access / nfs_svm_root volume 1 read /nfsdv1 nfsdv1 volume 1 read /nfsdv1/qt1 nfs_pol1 qt1 qtree 4 denied 3 entries were displayed. 40

41 Access is denied. If you would like to test access to these qtrees directly from rhel1 and rhel2, that activity is not covered in this lab guide, but you are welcome to do so on your own. You can use PuTTY to establish Linux terminal sessions to rhel1 and rhel SMB (CIFS) ACLs In the previous section, you learned how to control access to NAS exports from client servers and workstations. This section introduces how to control share and file access by users and user groups (data consumers). ACLs have always been a fundamental part of the Microsoft Windows NTFS file system. More recently, ACLs have become a feature in NFS file systems, starting with their introduction in NFSv4. CIFS ACLs are commonly implemented at the SMB (CIFS) share level, but may also be implemented at the NTFS directory and file level. Share ACLs and NTFS directory and file level ACLs are not mutually exclusive, meaning they can be used together. When they are used together, the most restrictive ACL takes precedence, so to avoid confusion you should generally make your file/folder ACLs more restrictive than their containing share ACLs. For example, if your share ACL denies write access to all users, you will not be able to write to a folder on the share even if that folders ACL grants Full Control to everyone, a scenario that is often very confusing for end users. When you first create an SMB (CIFS) share, ONTAP 9 automatically creates a share level ACL for the share. This ACL grants full control to the Windows built-in group Everyone. If this ACL does not provide the exact level of access control you desire, you may use System Manager or the ONTAP 9 CLI to modify and/or delete the ACL, and add in new ACLs that better meet your needs. Note Once you mount a share on a Windows client, it is possible to manage the share-level ACLs from that client using the Microsoft Management Console (MMC) Computer Management plug-in. You should use caution, because it is possible to modify the ACLs so that the client no longer has access to the share, in which case you will have to resort to using System Manager, or the ONTAP CLI to recover. The base CLI command for managing share-level ACLs is vserver following sub-commands. cifs share access-control, and it has the create modify delete show When you issue the create, modify, and delete commands, you specify the vserver hosting the share, the share name, the user or group to which the ACL pertains, the type of user or group (Windows, Unix-user, Unix group), and a specific permission (access) type from the following table Table 17 Table Share-Level ACL Permissions Permission Type Description 41 No_access All access is denied. Read Can see, open, execute, and view permissions and attributes of the item. Can also list contents of folder. Change Can create items; see, open, read, write, synchronize and delete the item. Viewing permissions and attributes is also allowed. Full_Control Can create items; see, open, read, write, delete the item; modify access rights and attributes and take ownership of the item.

42 NTFS directory and file level ACLs refer to the ACLs on individual files and folders within a share. You are most likely already familiar with managing these kinds of ACLs for NTFS file systems by using Windows Explorer (by viewing a file or folder s properties and going to the Security tab), or perhaps by using the Windows ICACLS command line utility. You can use these same tools to manage the ACLs for individual folders and files hosted on NetApp SMB (CIFS) shares, provided that the underlying volume is using the NTFS security style. The ONTAP 9 command line interface (CLI) also provides the vserver security file-directory commands for managing directory and file level access control lists. Using these commands to manipulate ACLs requires a deeper understanding of how Microsoft implements security descriptors, ACLs, and Access Control Entries (ACE), a discussion that falls outside the scope of this lab guide. This lab exercise will also not address managing directory and file ACLs using the vserver security file-directory commands. 3.9 ACL References Using ACLs to control or restrict access, as well as control the authorized access permissions of users and groups can be a very complex undertaking. Before you attempt to implement ACLs in your own environment, we strongly recommend that you learn more about managing ACLs by reading the following guides ONTAP 9.0 CIFS Reference ONTAP 9.0 Commands Manual Page Reference Exercise In this exercise, you create several SMB (CIFS) shares, then view the shares to see how the share-level ACL was created for each. You will add several share-level ACLs to each share, and modify/remove the Everyone ACL. You will then be able to mount (map to Windows drive letters) the shares you have created. 1. In the PuTTY session to cluster1, view a list of the current shares for the SVM cifs_svm. vserver cifs share show -vserver cifs_svm Vserver Share Path Properties Comment cifs_svm admin$ / browsable cifs_svm c$ / oplocks Full Control browsable changenotify cifs_svm cifsdv1 /cifsdv1 oplocks browsable changenotify cifs_svm cifsdv2 /cifsdv2 oplocks browsable changenotify cifs_svm ipc$ / browsable cifs_svm test_folder /cifsdv2/test_ oplocks Folder browsable changenotify 6 entries were displayed. ACL BUILTIN\Administrators / Everyone / Full Control Everyone / Full Control Everyone / Full Control The admin$, c$, and ipc$ shares are automatically created at SVM creation time. They have no direct bearing on shares created for user data. The cifsdv1, cifsdv2, and test_folder shares were pre-created for this lab. 2. Display a list of the existing share-level ACLs for the SVM cifs_svm. vserver cifs share access-control show -vserver cifs_svm Share User/Group User/Group Access Vserver Name Name Type Permission cifs_svm c$ BUILTIN\Administrators windows Full_Control cifs_svm cifsdv1 Everyone windows Full_Control cifs_svm cifsdv2 Everyone windows Full_Control cifs_svm test_folder Everyone windows Full_Control 4 entries were displayed. 42

43 The cifsdv1, cifsdv2, and test_folder shares all grant Full Control to Everyone, which is the ACL configuration for a newly created share. In the next portion of this exercise you will deploy more restrictive ACLs on these shares. 3. Grant Domain Admins Full Control of each of the the cifsdv1, cifsdv2, and test_folder shares. vserver cifs share access-control create -vserver cifs_svm -user-group-type windows -user-or-group "Domain Admins" -permission Full_Control -share cifsdv1 vserver cifs share access-control create -vserver cifs_svm -user-group-type windows -user-or-group "Domain Admins" -permission Full_Control -share cifsdv2 vserver cifs share access-control create -vserver cifs_svm -user-group-type windows -user-or-group "Domain Admins" -permission Full_Control -share test_folder 4. Add a change permissions ACL to the cifsdv1 share for the CIFS Data Users group. vserver cifs share access-control create -vserver cifs_svm -user-group-type windows -user-or-group "CIFS Data Users" -permission change -share cifsdv1 5. Add a change permissions ACL to the cifsdv2 share for the CIFS 2nd Data Users share. vserver cifs share access-control create -vserver cifs_svm -user-group-type windows -user-or-group "CIFS 2nd Data Users" -permission change -share cifsdv2 6. Add a change permissions ACL to the test_folder share for the CIFS Data Users group. vserver cifs share access-control create -vserver cifs_svm -user-group-type windows -user-or-group "CIFS Data Users" -permission change -share test_folder 7. Remove Everyone from each of the cifsdv1, cifsdv2, and test_folder shares. vserver cifs share access-control delete -vserver cifs_svm -user-or-group "Everyone" -share cifsdv1 vserver cifs share access-control delete -vserver cifs_svm -user-or-group "Everyone" -share cifsdv2 vserver cifs share access-control delete -vserver cifs_svm -user-or-group "Everyone" -share test_folder If you removed the Everyone ACLs before adding the other ACLs, then you would have cut off all access to anyone using the share. By adding the new ACLs first, your targeted users can (at least) still access the share through the ACL change. 8. Display a list of all the share-level ACLs for the SVM cifs_svm. vserver cifs share access-control show -vserver cifs_svm Share User/Group User/Group Access Vserver Name Name Type Permission cifs_svm c$ BUILTIN\Administrators windows Full_Control cifs_svm cifsdv1 CIFS Data Users windows Change cifs_svm cifsdv1 Domain Admins windows Full_Control cifs_svm cifsdv2 CIFS 2nd Data Users windows Change cifs_svm cifsdv2 Domain Admins windows Full_Control cifs_svm test_folder CIFS Data Users windows Change 43

44 cifs_svm test_folder Domain Admins 7 entries were displayed. windows Full_Control Now log into the WIN2K12R2 host as two different users ( datauser1 and datauser3 ) to observe these ACLs in action. These accounts both have the shares in the Share Info table pre-mapped. The Share ACL permissions column of this table describes which accounts are granted access to this share by the ACLs you just created, Table 18 Table Share Info Drive Letter Share Share ACL permissions X \\cifs\cifsdv1 Change Control for group "CIFS Data Users", of which datauser1 is a member. Y \\cifs\cifsdv2 Change Control for group "CIFS 2nd Data Users", of which datauser3 is a member. Z \\cifs\test_folder Change Control for group "CIFS Data Users", of which datauser1 is a member. 9. On the desktop of Jumphost, double-click the shortcut named WIN2K12R2, that launches Remote Desktop Connection Manager for that system. 9 Figure 3-14 The WIN2K12R2 - Remote Desktop Connection Manager window opens. 10. In the left pane, select WIN2K12R2 > Datausers. The view in the right pane should now only show boxes for datauser1 and datauser Right-click on Datausers in the left pane, and select Connect group... from the context menu. 44

45 11 10 Figure Remote Desktop Connection Manager initiates two RDP sessions to the host WIN2K12R2, one for each of the users DEMO\datauser1 and DEMO\datauser3. It may take a few moments, but eventually the application will display a thumbnail for each desktop session in the right pane. In the left pane of Remote Desktop Connection Manager, expand the list of hosts that are part of the Datausers connection group by clicking on the + sign just to the left of Datausers. You should now see entries for both datauser1 and datauser3 in the left pane. Initiate a remote desktop session to WIN2K12R2 as datauser1 by clicking on the datauser1 entry in the left pane. This will open the remote desktop session for datauser1 on WIN2K12R2 in the right pane. On the WIN2K12R2 desktop for datauser1, open Windows Explorer. In the left pane of Windows Explorer, expand This PC. Observe that the X and Z drives are accessible for this account, but the Y drive is not. This matches the permissions described in the Share Info table.

46 Figure In the left pane of Windows Explorer, select the X drive. 18. Right-click in the background of the right pane, and select New > Text Document from the context menu. 46

47 17 18 Figure Name the file newfile. 47

48 19 Figure 3-18 As you would expect from the data in the Share Info table, you are able to create the file successfully. 20. Navigate to the Z drive. 21. Right-click in the main pane, and select New > Text Document from the context menu. 48

49 20 21 Figure 3-19 A Destination Folder Access Denied window opens, explaining that you need permission to perform this action. Notice, you created the same ACLs for both the cifsdv1 and test_folder shares, so why is datauser1 able to write to cifsdv1, and not to test_folder? The error message provides no information why permission is denied; it only indicates that you need permission. The answer lies in the export policy you created in the CIFS Export Policies exercise. Recall that the cifsdv1 volume is using the cifs_pol1 export policy that grants read and write access to the host WIN2K12R2. The test_folder share is hosted on the cifsdv2 volume, which is using the cifs_pol2 policy that only grants read access to the host WIN2K12R2. So, although the share ACL says you have write permission, the export policy for the share s containing volume takes precedence and restricts you to read-only access. This example illustrates some of the complexities that arise when you deploy both CIFS export polices and share ACLs, and is why CIFS export policy implementations are uncommon. 22. Click Cancel. 49

50 22 Figure 3-20 The read-only export policy used for the cifsdv2 volume also interferes with the rest of this exercise, so you need to remove this restriction by having the cifsdv2 volume use the same export policy used for cifsdv In the PuTTy session for cluster1, configure the cifsdv2 volume to use the cifs_pol1 export policy. volume modify -vserver cifs_svm -volume cifsdv2 -policy cifs_pol1 Volume modify successful on volume cifsdv2 of Vserver cifs_svm In the left pane of the Remote Desktop Manager window, select the entry for datauser3. Open Windows Explorer. In the left pane of Windows Explorer, expand This PC. Observe that the Y drive is accessible to this account, but that the X and Z drives are not. This matches the desired result described in the Share Info table.

51 Figure Select the Y drive. 29. In the main pane of Windows Explorer, right-click and select New > Text Document from the context menu. 51

52 28 29 Figure Name the file anotherfile, and observe that you are able to create it successfully. 31. Double-click Test_Folder to open it. 52

53 31 30 Figure Right-click in this folder, and select New > Text Document from the context menu. 53

54 32 Figure Name this file yetanotherfile. You are able to create this file too. 54

55 33 Figure 3-25 Once again, you may wonder why this works given that you set up a share ACL for the Test_Folder share that only grants change control to members of the CIFS Data Users group. The datauser3 account is not a member of that group, so why can it write here? Take a look at the share mappings for datauser3 again, and notice that this account is not able to map to the test_folder share. This is correct behavior based on the share ACLs you configured to meet the requirements listed in the Share Info table. So, access was not granted that way, meaning you must have gained access through some other share. In this example the only mounted share is cifsdv2, which is coincidentally the volume on which Test_Folder resides. Share ACLs are enforced when you mount the exact share to which the ACL is assigned. When you have nested shares, and mount the parent share as you did here, it's the parent share's ACL that gets enforced; the share ACLs on the nested shares never come into play. While this is expected behavior, it creates the potential for unintended access, which is why you should avoid deploying nested shares that utilize different export polices unless you also utilize other compensating access controls, such as file system ACLs. 34. In the left pane of Remote Desktop Manager, select Datausers. The right pane will once again show thumbnails for datauser1 and datauser3 remote desktop session. 35. Right-click on Datausers, and select Log off group from the context menu. 36. Close Remote Desktop Manager. 55

56 Figure SMB Signing and SMBv3 Encryption SVMs in your ONTAP 9 cluster, that are offering CIFS (SMBv3) data services, can be configured so that data flow between the CIFS server and Windows clients mounting the CIFS shares will be encrypted. This helps to ensure that the communications remain confidential. You can configure the encryption requirement at either the SVM level (all CIFS shares are encrypted), or at the individual CIFS share level. Note Any changes to enable/disable the CIFS encryption settings for the CIFS SVM or an individual CIFS share will not take effect until the next connection is made. Note SMB signing has already been enabled for the CIFS SVM in this exercise Exercise In this exercise you will perform the following activities Examine the current SMBv3 encryption setting for the SVM cifs_svm, which is offering CIFS data services. Open a session to the Win2k12R2 client as Administrator and examine the SMB Connection Properties of the pre-mapped CIFS shares. Examine those same CIFS sessions from cifs_svm's point of view. Enable SMB encryption on cifs_svm. Open a new session to the Win2k12R2 client and examine the SMB Connection Properties of the premapped CIFS shares. Once again examine those same CIFS sessions from cifs_svm's point of view. 1. In the PuTTY session for cluster1, display the CIFS server security settings for the SVM cifs_svm. vserver cifs security show -vserver cifs_svm -instance Vserver cifs_svm Kerberos Clock Skew Kerberos Ticket Age Kerberos Renewal Age Kerberos KDC Timeout minutes hours days seconds

57 Is Signing Required Is Password Complexity Required Use start_tls For AD LDAP connection Is AES Encryption Enabled LM Compatibility Level Is SMB Encryption Required Client Session Security SMB1 Enabled for DC Connections SMB2 Enabled for DC Connections true true false true lm-ntlm-ntlmv2-krb false none system- system- 2. On the desktop of Jumphost, double-click the shortcut named WIN2K12R2 to launch the Remote Desktop Connection Manager for that system. 2 Figure 3-27 The WIN2K12R2 - Remote Desktop Connection Manager window opens. 3. In the left pane, navigate to WIN2K12R2 > Administrative > DEMO\Administrator. The right pane should now only display the text Disconnected from DEMO\Administrator (WIN2K12R2). 4. Right-click on DEMO\Administrator, and select Connect server from the context menu. 57

58 3 4 Figure 3-28 Remote Desktop Connection Manager initiates an RDP session to the host WIN2K12R2, and eventually displays in the right pane the DEMO\Administrator account's desktop on that host. 5. Launch File Explorer on the Win2K12R2 client s taskbar. 6. In the left pane of File Explorer you will see three shares from the SVM \\CIFS that are pre-mapped to the X, Y, and Z drives. They should all indicate good connections. 7. Launch Windows Power-Shell on the Win2K12R2 client s taskbar. 58

59 6 7 5 Figure 3-29 A PowerShell windows opens. 8. In PowerShell, retrieve a list of this client s established SMB connections to the SMB servers. PS C\Users\Administrator.DEMO> get-smbconnection select-object -property * SmbInstance ContinuouslyAvailable Credential Dialect Encrypted NumOpens Redirected ServerName ShareName UserName PSComputerName CimClass CimInstanceProperties CimSystemProperties Default False DEMO.NETAPP.COM\Administrator 3.00 False 1 False CIFS cifsdv1 DEMO\Administrator SmbInstance ContinuouslyAvailable Credential Dialect Encrypted NumOpens Redirected ServerName ShareName UserName PSComputerName CimClass CimInstanceProperties CimSystemProperties Default False DEMO.NETAPP.COM\Administrator 3.00 False 1 False CIFS cifsdv2 DEMO\Administrator ROOT/Microsoft/Windows/SMBMSFT_SmbConnection {ContinuouslyAvailable, Credential, Dialect, Encrypted...} Microsoft.Management.Infrastructure.CimSystemProperties ROOT/Microsoft/Windows/SMBMSFT_SmbConnection {ContinuouslyAvailable, Credential,Dialect, Encrypted...} Microsoft.Management.Infrastructure.CimSystemProperties SmbInstance Default ContinuouslyAvailable False 59

60 Credential Dialect Encrypted NumOpens Redirected ServerName ShareName UserName PSComputerName CimClass CimInstanceProperties CimSystemProperties DEMO.NETAPP.COM\Administrator 3.00 False 1 False CIFS test_folder DEMO\Administrator ROOT/Microsoft/Windows/SMBMSFT_SmbConnection {ContinuouslyAvailable, Credential, Dialect, Encrypted...} Microsoft.Management.Infrastructure.CimSystemProperties PS C\Users\Administrator.DEMO> You will see that the Encrypted property is set to False for all three shares, meaning none of the mapped share sessions is encrypted. 9. In the PuTTY session for cluster1, display the CIFS session information for the DEMO\Administrator user. vserver cifs session show -vserver cifs_svm -windows-user DEMO\Administrator -instance Vserver cifs_svm Node Session ID Connection ID Incoming Data LIF IP Address Workstation IP Address Authentication Mechanism User Authenticated as Windows User UNIX User Open Shares Open Files Open Other Connected Time Idle Time Protocol Version Continuously Available Is Session Signed NetBIOS Name SMB Encryption Status Connection Count cluster Kerberos domain-user DEMO\Administrator root m 11s 1m 49s SMB3 Yes true CIFS unencrypted 1 Notice that the SMB Encryption Status field shows unencrypted ; however, the Is Session Signed field shows the session is signed. 10. In the left pane of Remote Desktop Connection Manager, right-click on DEMO\Administrator, and select Log off server from the context menu. 60

61 10 Figure 3-30 Remote Desktop Connection Manager logs out the DEMO\Administrator account's RDP session to WIN2K12R2, but Remote Desktop Connection Manager remains open. 11. In the PuTTY session for cluster1, enable SMBv3 encryption on the SVM cifs_svm. vserver cifs security modify -vserver cifs_svm -is-smb-encryption-required true 12. Once again examine the CIFS server security settings for the SVM cifs_svm. vserver cifs security show -vserver cifs_svm -instance Vserver cifs_svm Kerberos Clock Skew Kerberos Ticket Age Kerberos Renewal Age Kerberos KDC Timeout Is Signing Required Is Password Complexity Required Use start_tls For AD LDAP connection Is AES Encryption Enabled LM Compatibility Level Is SMB Encryption Required Client Session Security true true false true lm-ntlm-ntlmv2-krb true none minutes hours days seconds SMBv3 encryption is now listed as required for the SVM cifs_svm. 13. In the left pane of Remote Desktop Connection Manager, right-click on DEMO\Administrator, and select Connect server from the context menu. 61

62 13 Figure 3-31 Remote Desktop once again logs into WIN2K12R2 as DEMO\Administrator. 14. Launch File Explorer from the taskbar of WIN2K12R Verify that the 3 shares to \\CIFS are mapped successfully. 16. Launch PowerShell from the taskbar of WIN2K12R Figure

63 A PowerShell window opens. 17. In PowerShell, retrieve a list of this client's established SMB connections to the SMB servers. PS C\Users\Administrator.DEMO> get-smbconnection select-object -property * SmbInstance ContinuouslyAvailable Credential Dialect Encrypted NumOpens Redirected ServerName ShareName UserName PSComputerName CimClass CimInstanceProperties CimSystemProperties Default False DEMO.NETAPP.COM\Administrator 3.00 True 1 False CIFS cifsdv1 DEMO\Administrator SmbInstance Credential Dialect Encrypted NumOpens Redirected ServerName ShareName UserName PSComputerName CimClass CimInstanceProperties CimSystemProperties DefaultContinuouslyAvailable False DEMO.NETAPP.COM\Administrator 3.00 True 1 False CIFS cifsdv2 DEMO\Administrator SmbInstance ContinuouslyAvailable Credential Dialect Encrypted NumOpens Redirected ServerName ShareName UserName PSComputerName CimClass CimInstanceProperties CimSystemProperties Default False DEMO.NETAPP.COM\Administrator 3.00 True 1 False CIFS test_folder DEMO\Administrator ROOT/Microsoft/Windows/SMBMSFT_SmbConnection {ContinuouslyAvailable, Credential, Dialect, Encrypted...} Microsoft.Management.Infrastructure.CimSystemProperties ROOT/Microsoft/Windows/SMBMSFT_SmbConnection {ContinuouslyAvailable, Credential, Dialect, Encrypted...} Microsoft.Management.Infrastructure.CimSystemProperties ROOT/Microsoft/Windows/SMBMSFT_SmbConnection {ContinuouslyAvailable, Credential, Dialect, Encrypted...} Microsoft.Management.Infrastructure.CimSystemProperties PS C\Users\Administrator.DEMO> Notice that all three (3) SMB connections show as being encrypted. 18. In the PuTTY session for cluster1, examine the CIFS session for the DEMO\Administrator user. vserver cifs session show -vserver cifs_svm -windows-user DEMO\Administrator -instance Vserver cifs_svm Node Session ID Connection ID Incoming Data LIF IP Address Workstation IP Address Authentication Mechanism User Authenticated as Windows User UNIX User Open Shares Open Files Open Other Connected Time Idle Time Protocol Version Continuously Available Is Session Signed 63 cluster Kerberos domain-user DEMO\Administrator root m 16s 6m 1s SMB3 Yes false

64 NetBIOS Name CIFS SMB Encryption Status encrypted Connection Count 1 Notice that the session shows as being encrypted. Since it is encrypted, the SMB session is not signed. 19. In the left pane of Remote Desktop Connection Manager, right-click on DEMO\Administrator, and select Log off server from the context menu. 20. Close Remote Desktop Connection Manager Figure 3-33 The Remote Desktop Manager Window closes Configure NetApp Volume Encryption NetApp Volume Encryption (NVE) is a software-based, data-at-rest encryption solution available starting with NetApp ONTAP 9.1. NVE allows ONTAP to encrypt data (using AES-256 bit encryption) per volume for granularity, without requiring self-encrypting drives. The encryption key is only accessible from the storage system, so data cannot be recovered from the device from any other system. This provides protection of your valuable data in the event that the device is redeployed to another system, lost, stolen, or returned to NetApp for replacement. NVE is also supported for storage devices in ONTAP Select. NVE also allows customers to leverage ONTAP storage efficiency features like deduplication and compression, that would be lost if the customer decided to encrypt data at the application layer Exercise In this exercise you will perform the following activities 64

65 Create encryption keys. Create a new volume that utilizes NVE. Convert an existing volume to utilize NVE. Export the NVE encryption key for DR purposes. 1. Verify that the NVE license is installed by displaying all the ONTAP licenses on the cluster. system license show Serial Number Owner cluster1 Package Type Description Expiration Base license Cluster Base License Serial Number Owner cluster1-01 Package Type Description Expiration NFS license NFS License CIFS license CIFS License iscsi license iscsi License FCP license FCP License SnapRestore license SnapRestore License SnapMirror license SnapMirror License FlexClone license FlexClone License SnapVault license SnapVault License SnapLock license SnapLock License SnapManagerSuite license SnapManagerSuite License SnapProtectApps license SnapProtectApp License V_StorageAttach license Virtual Attached Storage License Insight_Balance license OnCommand Balance VE license Volume Encryption License 15 entries were displayed. The license package for NVE is named VE. 2. Launch the onboard key management setup wizard. Note The passphrase you choose for the new key must range from 32 and 256 characters long. For this lab exercise we recommend you use the passphrase hardening_netapp_ontap_lab_nve_exercise. security key-manager setup Welcome to the key manager setup wizard, which will lead you through the steps to add boot information. Enter the following commands at any time "help" or "?" if you want to have a question clarified, "back" if you want to change your answers to previous questions, and "exit" if you want to quit the key manager setup wizard. Any changes you made before typing "exit" will be applied. Restart the key manager setup wizard with "security key-manager setup". To accept a or omit a question, do not enter a value. Would you like to configure onboard key management? {yes, no} [yes] yes Enter the cluster-wide passphrase for onboard key management. To continue the configuration, enter the passphrase, otherwise type "exit" hardening_netapp_ontap_lab_nve_exercise Re-enter the cluster-wide passphrase hardening_netapp_ontap_lab_nve_exercise After configuring onboard key management, save the encrypted configuration data in a safe location so that you can use it if you need to perform a manual recovery operation. To view the data, use the security key-manager backup show command. For a production deployment you should record your passphrase in a secure location outside the storage system for future use. All key management information is automatically backed up to the ONTAP replicated database (RDB) for the cluster, but you should also save a copy outside the cluster in case of disaster. 65

66 3. Back up the key manually for use in the event of disaster recovery.. security key-manager backup show BEGIN BACKUP TmV0QXBwIEtleSBCbG9iAAEAAAAEAAAAcAEAAAAAAAA46banAAAAACEAAAAAAAAA QAAAAAAAAAAMRHgZAAAAAK1uvne73mJTKCfnPgGeuqleZ/ NuqHj07h6sKN0DIpJM1dwsFzKyTW4VT+mjG4Nr6tebM/ CzHt7i2Dm1ibDVkJQiAAAAAAAAACgAAAAAAAAA3WTh7gAAAAAAAAAAAAAAAAIAAA AAAAgAZJEIWvdeHr5RCAvHGclo+wAAAAAAAAAAIgAAAAAAAAAoAAAAAAAAAEOTcR 0AAAAAAAAAAAAAAAACAAAAAAAJAGr3tJA/ LRzUQRHwv+1aWvAAAAAAAAAAACQAAAAAAAAAgAAAAAAAAACMuT+cAAAAAIHMxUEL FsaMwNoYX2RzYLrqf1+ve9vxTP75h8pZtRsoDZn8ArEx8rwAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABOZXRBcHAgS2V5IEJs b2iaaqaaaamaaaayaqaaaaaaapz70gqaaaaaigaaaaaaaaaoaaaaaaaaaeotcr0a AAAAAAAAAAAAAAACAAAAAAAJAGr3tJA/ LRzUQRHwv+1aWvAAAAAAAAAAACIAAAAAAAAAKAAAAAAAAAA5NPttAAAAAAAAAAAA AAAAAgAAAAAAAQCa2JUrbjkFNiRtj/ UfVMDyAAAAAAAAAAAkAAAAAAAAAIAAAAAAAAAA8KewEwAAAADMupZXSe/ Ti2lYyeatBlKaZajjCJbI85jVEblCQw/ 5xrQ38Wl90tHfAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAE5ldEFwcCBLZXkgQmxvYgABAAAAAwAAABgBAAAAAAAAEQD3rgAAAAAiAAAAAAA AACgAAAAAAAAAQ5NxHQAAAAAAAAAAAAAAAAIAAAAAAAkAave0kD8tHNRBEfC/ 7Vpa8AAAAAAAAAAAIgAAAAAAAAAoAAAAAAAAAICiZ1wAAAAAAAAAAAAAAAACAAAA AAABANe0Gq7uZQWiBN/NJSND/ 4MAAAAAAAAAACQAAAAAAAAAgAAAAAAAAABVfla0AAAAADbNIgER0Jxq22OT5ckR+ hjey+xoh9s2f+ae7yblgl91ldqm75nrmmsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAA END BACKUP In a production environment you should copy and paste this information into a file that resides outside the cluster. As with any private key, you would want to store that file in a highly secure location to protect against unauthorized access, theft, or data loss. 4. Create a new volume named nve, and enable volume encryption on it. volume create -vserver cifs_svm -volume nve -aggregate aggr_data1 -encrypt true -size 1g [Job 475] Job succeeded Successful The Onboard Key Manager creates an encryption key for the volume. Any data you put on the volume is encrypted. 5. Verify that the volume is enabled for encryption. volume show -is-encrypted true Vserver Volume Aggregate State Type Size Available Used% cifs_svm nve aggr_data1 online RW 1GB 972.6MB 5% You can also enable NVE on a volume that was initially created without encryption. This requires performing a volume move operation on the volume, and selecting to encrypt the volume at the move destination. 6. Create a unencrypted volume (i.e., a regular volume). volume create -vserver cifs_svm -volume nve2 -aggregate aggr_data2 -size 1g [Job 476] Job succeeded Successful 66

67 7. Verify that the new nve2 volume is not encrypted by querying ONTAP for the list of volumes that are encrypted. volume show -is-encrypted true Vserver Volume Aggregate State Type Size Available Used% cifs_svm nve aggr_data1 online RW 1GB 972.6MB 5% The nve2 volume is not listed in the output, meaning it is not encrypted. 8. Move the nve2 volume to the aggr_data1 aggregate, and encrypt it during the move. vol move start -vserver cifs_svm -volume nve2 -destination-aggregate aggr_data1 -encrypt-destination true [Job 477] Job is queued Move "nve2" in Vserver "cifs_svm" to aggregate "aggr_data1". Use the "volume move show -vserver cifs_svm -volume nve2" command to view the status of this operation. 9. Monitor the status of the move operation until it is complete. volume move show -vserver cifs_svm -volume nve2 Vserver Name Volume Name Actual Completion Time Bytes Remaining Destination Aggregate Detailed Status Estimated Time of Completion Managing Node Percentage Complete Move Phase Estimated Remaining Duration Replication Throughput Duration of Move Source Aggregate Start Time of Move Move State Is Source Volume Encrypted Encryption Key ID of Source Volume Is Destination Volume Encrypted Encryption Key ID of Destination Volume cifs_svm nve2 Wed Sep aggr_data1 Successful cluster % completed aggr_data2 Wed Sep done false true - The move operation should complete quite rapidly given that the volume is small and empty, but if you issue the vol move show command very quickly then it might be necessary to run this command more than once before it finally reports that the move has completed. Note that the Is Destination Volume Encrypted line reports as true, indicating the volume is now encrypted. 10. Verify that the nve2 volume is encrypted by querying ONTAP for the encrypted volumes again. volume show -is-encrypted true Vserver Volume Aggregate State cifs_svm nve aggr_data1 online cifs_svm nve2 aggr_data1 online 2 entries were displayed. Type Size Available Used% RW 1GB 972.6MB 5% RW 1GB 972.5MB 5% The nve2 volume is now listed in the output Review Syslog Events In this section, you connect to the Host that functions as the external syslog server for this lab environment. Once connected, you will navigate to the directory or directories where the log files for the ONTAP 9 cluster are stored. 67

68 Examine the contents of these log files to see an audit record of everything you did during your activities in this lab. The rsyslog daemon running on the syslog server utilizes a custom configuration designed to filter your CLI activities into a separate log file to make them easier to find and understand. You may find a directory named for the ONTAP 9 cluster in general (cluster1), and may also find a directory named for each member node (in this case cluster1-01, as this is a single node cluster). Of particular interest are log files within those directories with names beginning with command-history Exercise This exercise shows you where to locate and view auditing log files for your ONTAP 9 cluster. You may see some variance from the examples shown here in your lab depending on what specific activities you performed in the lab. 1. On the desktop of Jumphost, right-click the PuTTY icon on the task bar, and select syslog from the list of recent sessions. 1 Figure 3-34 A PuTTY session opens to the syslog host. 2. Log in with username root, and the password Netapp1!. 3. Change your working directory to the directory where syslog is capturing the log files for cluster1. [root@syslog ~]# cd /var/log/cluster1-01-logs [root@syslog cluster1-01-logs]# 4. List the contents of the log directory. [root@syslog cluster1-01-logs]# ls -l 68

69 total 144 -rw root root Aug command-history-audit.log -rw root root Aug syslog.log [root@syslog cluster1-01-logs]# The two files you see listed are the product of a custom syslog configuration created for this lab. The syslog.log file captures all of the ONTAP 9 EMS events, as well as all user and system generated commands. This includes commands entered through the ONTAP 9 CLI, as well as management activities initiated through NetApp's Zephyr API (ZAPI). OnCommand System Manager and the ONTAP 9 PowerShell Toolkit utilize ZAPI, so management activities initiated through these tools are logged too. The command-history-audit.log file contains a subset of the entries in the syslog.log file. Specifically, it filters out the EMS and system generated commands so you can more easily view the CLI commands you entered in this lab. If you made configuration changes through tools that use ZAPI, like System Manager, then this file would contain some record of those activities too, although you would need to refer to the syslog.log file to view some additional context information. 5. Use the more command to review the contents of the command-history-audit.log file. [root@syslog cluster1-01-logs]# more command-history-audit.log Aug cluster1 cluster1-01 cluster d5f c Tue Aug [kern_auditinfo1979] 8003e b78003e b cluster1ssh cluster1admin cluster log-forwarding create -destination port 514 facility u ser Success Aug cluster1 cluster1-01 cluster d Tue Aug [kern_auditinfo1979] 8003e b78003e d cluster1ssh cluster1admin exit Pending Aug cluster1 cluster1-01 cluster d Tue Aug [kern_auditinfo1979] 8003e b78003e d cluster1ssh cluster1admin exit Success Aug cluster1 cluster1-01 cluster d Tue Aug [kern_auditinfo1979] 8003e b78003e e cluster1ssh cluster1admin Logging out Aug cluster1 cluster1-01 cluster da6 0000ade2 Tue Aug [kern_auditinfo1979] cluster1ssh cluster1ad min Authentication failed. Aug cluster1 cluster1-01 cluster dab 0000ae2d Tue Aug [kern_auditinfo1979] 8003e e cluster1ssh cluster1admin Logging in Aug cluster1 cluster1-01 cluster dad 0000afa1 Tue Aug [kern_auditinfo1979] 8003e e cluster1ssh cluster1admin security login role create -role stats -cmddirname DEFAULT -access none Pe nding --More--(2%) [root@syslog cluster1-01-logs]# The more command displays the file contents one screen at a time. You can page forward using the space bar, and you can terminate the more command at any time by hitting the q key. Each line in the file contains a number of fields separated by double colons. 69 The first field starts with a timestamp, followed by some information about the reporting host, more timestamp information, and then in brackets details about the syslog logging facility for this message.

70 The second field contains information about the vector used to enter the command. The string ssh means this entry represents a CLI command entered over ssh. The string ontapi would indicate an activity issued over ZAPI, such as would be the case if you were applying a configuration change through System Manager. The third field is the IP address of the client host that initiated the activity. In this lab is the IP address of Jumphost. The fourth field indicates the Data ONTAP user ID under which the operation was performed. In this lab you issued all CLI commands as the admin user. In the case of a CLI command, the fifth field represents the actual clustered Data ONTAP command. In the case of an ontapi entry, this field contains some indication of the configuration activity, but you would need additional context from surrounding entries, and probably from the full syslog.log file, to fully understand the activity. The sixth field indicates the overall status of the activity/command. Pending for an activity in progress, success for one that succeeded, and so on. 6. If you are interested in how this syslog server was configured to segregate log messages in the manner used in this lab, this exercise does not explicitly cover that material, but you are welcome to review the configuration on your own. That configuration is managed through the /etc/rsyslog.conf file on the Linux host syslog. [root@syslog cluster1-01-logs]# cat /etc/rsyslog.conf # rsyslog v5 configuration file # For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html # If you experience problems, see http// #### MODULES #### $ModLoad imuxsock # provides support for local system logging (e.g. via logger command) $ModLoad imklog # provides kernel logging support (previously done by rklogd) #$ModLoad immark # provides --MARK-- message capability # Provides UDP syslog reception $ModLoad imudp $UDPServerRun 514 # Provides TCP syslog reception $ModLoad imtcp $InputTCPServerRun 514 #### GLOBAL DIRECTIVES #### # Use timestamp format $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # File syncing capability is disabled by. This feature is usually not required, # not useful and an extreme performance hit #$ActionFileEnableSync on # Include all config files in /etc/rsyslog.d/ $IncludeConfig /etc/rsyslog.d/*.conf #### LOCAL TEMPLATES #### # Template to separate logs by host names $template FILENAME,"var/log/%HOSTNAME%-logs/syslog.log" # Template to capture cdot nteractive command history to a separate file $template FILENAME2,"var/log/%HOSTNAME%-logs/command-history-audit.log" ################################################################################ #### RULES #### ################################################################################ ################################################################################ #### Rules for external sources #### ################################################################################ # Log all external source messages to appropriate directory named for source if $fromhost-ip!= ' ' then?filename # Filter out non-interactive command history messages if $fromhost-ip!= ' ' and $msg contains 'console console root ' and $syslogfacility-text == 'user' then ~ 70

71 if $fromhost-ip!= ' ' and $syslogfacility-text == 'user' and $msg contains '[kern_auditinfo' then?filename2 # If message is external, then we are done. Suppress from further processing. fromhost-ip,!isequal, " " ~ ################################################################################ #### Rules for local host server #### ################################################################################ # Log all kernel messages to the console. # Logging much else clutters up the screen. #kern.* /dev/console # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* -/var/log/maillog # Log cron stuff cron.* /var/log/cron # Everybody gets emergency messages *.emerg * # Save news errors of level crit and higher in a special file. uucp,news.crit /var/log/spooler # Save boot messages also to boot.log local7.* /var/log/boot.log #Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none;cron.none /var/log/messages ################################################################################ ### begin forwarding rule ### # The statement between the begin... end define a SINGLE forwarding # rule. They belong together, do NOT split them. If you create multiple # forwarding rules, duplicate the whole block! # Remote Logging (we use TCP for reliable delivery) # # An on-disk queue is created for this action. If the remote host is # down, messages are spooled to disk and sent when it is up again. #$WorkDirectory /var/lib/rsyslog # where to place spool files #$ActionQueueFileName fwdrule1 # unique name prefix for spool files #$ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible) #$ActionQueueSaveOnShutdown on # save messages to disk on shutdown #$ActionQueueType LinkedList # run asynchronously #$ActionResumeRetryCount -1 # infinite retries if host is down # remote host is name/ipport, e.g , port optional # ### end of the forwarding rule ### # A template for higher precision timestamps + severity logging $template SpiceTmpl,"%TIMESTAMP%.%TIMESTAMPdate-subseconds% %syslogtag% %syslogseveritytext%%msgsp-if-no-1st-sp%%msgdrop-last-lf%\n" programname, startswith, "spice-vdagent" /var/log/spice-vdagent.log;spicetmpl [root@syslog cluster1-01-logs]# This concludes the activities for this lab. 71

72 4 References We used the following references to write this lab guide. All guides related to Clustered Data ONTAP are specific to the version used in this lab. Table 19 Table Lab References 72 Guide Title Publish Date NetApp P/N ONTAP 9.0 System Administration Reference June _AO ONTAP 9.0 Commands Manual Page Reference June _AO ONTAP 9.0 CIFS and NFS Multiprotocol Configuration Express Guide June _A0 ONTAP 9.0 CIFS Reference June _A0 ONTAP 9.0 NFS Configuration Express Guide June _A0 ONTAP 9.0 NFS Reference June _A0 ONTAP 9.0 Network Management Guide June _A0

73 5 Version History 73 Version Date Document Version History Version 1.0 Oct 2015 Initial Release for Insight 2015 Version 1.1 Sep 2016 Updated Release for Insight 2016 Version 1.2 Sep 2017 Insight 2017 Update upgraded to ONTAP 9.2, added NVE

74 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. NetApp provides no representations or warranties regarding the accuracy, reliability, or serviceability of any information or recommendations provided in this publication, or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS, and the use of this information or the implementation of any recommendations or techniques herein is a customer s responsibility and depends on the customer s ability to evaluate and integrate them into the customer s operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document. Go further, faster 2017NetApp, Inc. All rights reserved. No portions of this document may be reproduced without prior written consent of NetApp, Inc. Specifications are subject to change without notice. NetApp, the NetApp logo, Data ONTAP, ONTAP, OnCommand, SANtricity, FlexPod, SnapCenter, and SolidFire are trademarks or registered trademarks of NetApp, Inc. in the United States and/or other countries. All other brands or products are trademarks or registered trademarks of their respective holders and should be treated as such.