Hardening NetApp ONTAP - hol. · PDF fileHardening NetApp ONTAP 7 © 2017 NetApp, Inc. All rights reserved. NetApp Proprietary Table 4: User IDs and Passwords User User Type Username

Hardening NetApp ONTAP

September 2017 | SL10328 Version 1.2

Hardening NetApp ONTAP2 © 2017 NetApp, Inc. All rights reserved. NetApp Proprietary

TABLE OF CONTENTS

1 Introduction...................................................................................................................................... 4

1.1 Basic ONTAP 9 Security Practices..........................................................................................4

1.2 Lab Objectives........................................................................................................................... 5

1.3 Prerequisites.............................................................................................................................. 5

2 Lab Environment............................................................................................................................. 6

3 Lab Activities................................................................................................................................... 8

3.1 Lab Preparation......................................................................................................................... 8

3.2 Route Event Messages and Command-History to an External Syslog ServerDestination....................................................................................................................................... 10

3.2.1 Exercise.............................................................................................................................................................. 10

3.3 Administrative User Account Custom Roles........................................................................11

3.3.1 Exercise.............................................................................................................................................................. 13

3.4 Configuring Firewalls.............................................................................................................. 16

3.4.1 Exercise.............................................................................................................................................................. 18

3.5 Configure SSH......................................................................................................................... 19

3.5.1 Exercise.............................................................................................................................................................. 20

3.6 Configure CLI Session Timeouts...........................................................................................21

3.6.1 Exercise.............................................................................................................................................................. 21

3.7 Configure SSL/TLS.................................................................................................................. 22

3.7.1 Exercise.............................................................................................................................................................. 22

3.8 NFS/CIFS Export Policies....................................................................................................... 26

3.8.1 CIFS Exercise.....................................................................................................................................................27

3.8.2 NFS Exercise......................................................................................................................................................36

3.9 SMB (CIFS) ACLs.................................................................................................................... 41

3.9.1 Exercise.............................................................................................................................................................. 42


3.10 SMB Signing and SMBv3 Encryption..................................................................................56

3.10.1 Exercise............................................................................................................................................................ 56

3.11 Configure NetApp Volume Encryption................................................................................ 64

3.11.1 Exercise............................................................................................................................................................ 64

3.12 Review Syslog Events.......................................................................................................... 67

3.12.1 Exercise............................................................................................................................................................ 68

4 References......................................................................................................................................72

5 Version History.............................................................................................................................. 73


1 IntroductionThis lab introduces several basic techniques for security hardening of NetApp ONTAP® version 9. This labutilizes as its starting point an environment that contains a virtualized, single node ONTAP 9 cluster, andseveral virtualized servers that allow you to perform and verify some simple steps to secure your data storageenvironment.

This lab is not intended to be an all-encompassing best practices guide for securing ONTAP 9; there is no “onesize fits all” security configuration that is ideal for every situation. Rather, this lab introduces many of the securityfeatures available to you in ONTAP 9 so that you can learn how they work. With this knowledge you can thendecide 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 theirIT environments and the data they contain. These concerns stem from a constant stream of newly exploitedvulnerabilities, and the discovery of data breaches occurring at an ever alarming rate. Although you may not beable to prevent all attempts at unauthorized incursion, you can better safe-guard your IT resources and your datathrough the use of some basic security practices. Security, itself, is a rather complex subject with many differentfacets. 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 Accountability Is “Big Brother” watching?

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 myworkstation 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 tothe ONTAP 9 cluster (or a hosted SVM) using the Secure Shell (SSH) protocol. This is just one of several accessmethods that can be employed, but for brevity this lab focuses only on SSH access.


For the second case, this lab focuses on two Network Attached Storage (NAS) protocols used to access storeddata. 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 (asshown 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 ObjectivesIn this lab you will learn techniques for hardening the security of an ONTAP system. You will specifically learnhow 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 PrerequisitesThis lab assumes that you are familiar with the basic concepts of administering ONTAP 9. This lab makesextensive use of the ONTAP command line interface (CLI) because OnCommand System Manager, NetApp'sgraphical administration tool, does not support the features necessary to complete many of the exercises you willbe performing.

Experience with the ONTAP CLI is helpful but not required. The instructions are designed to allow a novice tocomplete the lab .

This lab also uses Linux CLI commands, but again, experience is not required in order to complete the lab.


2 Lab EnvironmentThe following illustration depicts the lab environment:

Figure 2-1:

Table 3: Table of Systems

Server \ Resource Purpose IP Address Username Password

JUMPHOST Windows 2012R2Remote Access Host

192.168.0.5 DEMO\Administrator Netapp1!

RHEL1 Red Hat 6.8 x64Linux Host

192.168.061 root Netapp1!

RHEL2 Red Hat 6.8 x64Linux Host

192.168.0.62 root Netapp1!

SYSLOG Red Hat 6.6 x64Linux Syslog Server

192.168.0.63 root Netapp1!

WIN2K12R2 Windows 2012R2Server


DC1 Active Directory andDNS Server


CLUSTER1 ONTAP 9 cluster 192.168.0.101 admin Netapp1!

CLUSTER1-01 ONTAP cluster node 192.168.0.111 admin Netapp1!

CIFS CIFS Server SVM 192.168.0.131 vsadmin Netapp1!

NFS NFS Server SVM 192.168.0.141 vsadmin Netapp1!


Table 4: User IDs and Passwords

User User Type Username or UID GroupMembership orGID

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 DataUsers

Netapp1!

CIFS Data User # 4 Windows demo\datauser4 CIFS 2nd DataUsers

Netapp1!

NFS Data User # 1 Linux ldatauser1

(500)

nfs_users1

(5001)

Netapp1!


(501)

nfs_users1

(5001)

Netapp1!


(502)

nfs_users2

(5002)

Netapp1!


(503)

nfs_users2

(5002)

Netapp1!


3 Lab ActivitiesThis 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 67

3.1 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 3-1:

2. By default PuTTY displays the “Basic options for your PuTTY session” view after launch. If youaccidentally navigate away from this view just click on the Session category item in the left pane toreturn to this view.

3. In the “Saved Sessions” box, double-click the entry for cluster1.


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

If you are new to the ONTAP CLI, the length of the commands can seem a little intimidating. However, thecommands 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 tabcompletion. If you hit the Tab key while entering a portion of a command word, the command shell willexamine the context and try to complete the rest of the word for you. If there is insufficient context tomake a single match, it will display a list of all the potential matches. Tab completion also usually workswith command argument values, but there are some cases where there is simply not enough context forit 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 youcan then navigate up and down the list using the up and down arrow keys. When you find a commandyou want to modify, you can use the left arrow, right arrow, and Delete keys to navigate around in aselected command to edit it.

• Entering a question mark character ? causes the CLI to print contextual help information. You can usethis 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 NetAppONTAP” lab includes an extensive tutorial on this subject.


Caution: The commands shown in this guide are often so long that they span multiple lines. When yousee 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-linecommands, you can only copy one line at a time. If you try to copy multiple lines at once the commandswill fail in the lab.

3.2 Route Event Messages and Command-History to an External Syslog ServerDestination

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 adesignated syslog server. This works for commands entered through the ONTAP 9 CLI as well as through theNetApp Zephyr API (ZAPI), which means that management activities performed through System Manager, theNetApp 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 syslogserver application is rsyslog v5, which is the standard remote syslog server daemon provided with this RHELrelease. In production environments, other syslog applications may be used in place of the default rsyslog. Thedestination IP address of this server “syslog.demo.netapp.com” is 192.168.0.63.

Once you configure remote syslog destination/routing for both the Event Management System (EMS) and thecommand history log entries, any ONTAP 9 configuration activities you perform in other sections of this lab willget logged to syslog. At the end of the lab you will revisit the syslog server to review those captured logs.

3.2.1 Exercise

1. In the PuTTY window for cluster1, display a list of the existing event notification destinations. An eventnotification destination is an address or location that receives event notifications.

cluster1::> event notification destination showName Type Destination-------------- ---------- ---------------------snmp-traphost snmp - (from "system snmp traphost")cluster1::>

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 192.168.0.63,

which corresponds to syslog.demo.netapp.com.

cluster1::> event notification destination create -name syslogger -syslog syslog.demo.netapp.comcluster1::>

3. Display the updated list of event notification destinations.

cluster1::> event notification destination showName Type Destination-------------- ---------- ---------------------snmp-traphost snmp - (from "system snmp traphost")syslogger syslog syslog.demo.netapp.com2 entries were displayed.

cluster1::>

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

cluster1::> event filter create -filter-name syslog-filter

cluster1::> event filter rule add -filter-name syslog-filter -type include -message-name * -severity * -snmp-trap-type *


cluster1::> event filter test -filter-name syslog-filter6772 events will be included in the given filter.

cluster1::>

5. Display a list of the command-history log forwarding destinations.

cluster1::> cluster log-forwarding showThis table is currently empty.

cluster1::>

Note: Notice that there are no defined destinations.6. Create the syslog server as a new command-history log-forwarding destination.

cluster1::> cluster log-forwarding create -destination 192.168.0.63 -port 514 -facility userTesting network connectivity to the destination host 192.168.0.63.

cluster1::>

7. Display the updated list of command-history log-forwarding forwarding destinations.

cluster1::> cluster log-forwarding show Verify SyslogDestination Host Port Protocol Server Facility------------------------ ------ --------------- ------ --------syslog.demo.netapp.com 514 udp-unencrypted false user

cluster1::>

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 thatyou 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 restartShutting 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 andrestrict 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 accounthas when you login to ONTAP 9. These capabilities dictate what you can access, what you can see, and mostimportantly, 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

Cluster Pre-defined Roles Vserver (SVM) Pre-defined Roles

admin vsadmin


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 ascommand 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 Policy

Role AttributeParameter

Description Default Value Recommended Value

-username-minlength Minimum username lengthrequired

3 3

-username-alphanum Username alpha-numeric disabled disabled

-passwd-minlength Minimum password lengthrequired

8 8

-passwd-alphanum Password alpha-numeric enabled enabled

-passwd-min-special-chars Minimum number ofspecial charactersrequired in the password

0 1

-passwd-expiry-time Password Expires In(Days)

unlimited (never) 60

-require-initial-passwd-update

Require password changeon 1st login

disabled enabled

-max-failed-login-attempts Maximum number of failedattempts

0 6

-lockout-duration Maximum lockout period(Days)

0 = (1 day) 30

-disallowed-reuse Disallow last 'N'passwords

6 6

-change-delay Delay between passwordchanges (Days)

0 = (no delay) 0

When defining customized roles, use the following CLI parameters to further specify the scope of the role.

Table 7: Table: Role Creation Parameters

Parameter Description

-vserver This optionally specifies the Vserver name associatedwith the role.

-role This specifies the name of the role that is to becreated.


Parameter Description

-cmddirname This specifies the command or command directoryto which the role has access. To specify the defaultsetting, 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 default setting is all.

-query This optionally specifies the object that the roleis allowed to access. The query object must beapplicable to the command or directory name specifiedby -cmddirname. The query object must be enclosed indouble quotation marks (“ ”), and it must be a valid fieldname.

3.3.1 Exercise

In this exercise, you create a custom role called “stats”, and create a user account named “stat_acct” that isassigned the “stats” role. You then login to that user account and see which access capabilities are allowed forthis user.

1. In the PuTTY window for cluster1, create a new role named “stats” that initially has no access to any ofthe administrative CLI commands.

cluster1::> security login role create -role stats -cmddirname DEFAULT -access none

cluster1::>

2. Grant the “stats” role access to all of the statistics CLI commands.

cluster1::> security login role create -role stats -cmddirname statistics -access all

cluster1::>

3. Grant the “stats” role access to the security login whoami command.

cluster1::> security login role create -role stats -cmddirname "security login whoami" -access all

cluster1::>

4. Display the hierarchy of the command access rules for the “stats” role.

cluster1::> security login role show -role stats Role Command/ AccessVserver Name Directory Query Level---------- ------------- --------- ----------------------------------- --------cluster1 stats DEFAULT none security login whoami all statistics all3 entries were displayed.

cluster1::>

The initial ordering of the rules listed is important, as the first entry takes away all access, and thesecond and third rules selectively add access back to the desired commands. The fact that the secondand third commands show up in a different order than you entered them is unimportant, as there is nodependency between these two commands.

5. Display the configuration attribute settings for the “stats” role.

cluster1::> security login role config show -role stats -instance Vserver: cluster1


Role Name: stats Minimum Username Length Required: 3 Username Alpha-Numeric: disabled Minimum Password Length Required: 8 Password Alpha-Numeric: enabled Minimum Number of Special Characters Required In The Password: 0 Password Expires In (Days): unlimited Require Initial Password Update on First Login: disabled Maximum Number of Failed Attempts: 0 Maximum Lockout Period (Days): 0 Disallow Last 'N' Passwords : 6 Delay Between Password Changes (Days): 0 Delay after Each Failed Login Attempt (Secs): 4 Minimum Number of Lowercase Alphabetic Characters Required in the Password: 0 Minimum Number of Uppercase Alphabetic Characters Required in the Password: 0 Minimum Number of Digits Required in the Password: 0 Display Warning Message Days Prior to Password Expiry (Days): unlimited Account Expires in (Days): unlimited Maximum Duration of Inactivity before Account Expiration (Days): unlimited

cluster1::>

As you can see, the username and password complexity attributes all match the default values shown inthe “Role Configuration Attributes Useful in Implementing Password and Login Policy” table. The defaultvalues are fine for this lab, but if you want to modify then you can use the security login role configmodify 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. Whenprompted for the new account#s password, enter Netapp1!.

cluster1::> 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!

cluster1::>

7. Enter just the “?” character in your cluster1 PuTTY session to produce a list of the CLI commandsavailable to the admin user account.

cluster1::> ? up Go up one directory cluster> Manage clusters event> Manage system events exit Quit the CLI session history Show the history of commands for this CLI session job> Manage jobs and job schedules lun> Manage LUNs man Display the on-line manual pages metrocluster> Manage MetroCluster network> Manage physical and virtual network connections qos> QoS settings redo Execute a previous command rows Show/Set the rows for this CLI session run Run interactive or non-interactive commands in the nodeshell security> The security directory set Display/Set CLI session settings snaplock> Manages SnapLock attributes in the system snapmirror> Manage SnapMirror statistics> Display operational statistics storage> Manage physical storage, including disks, aggregates, and failover system> The system directory top Go to the top-level directory volume> Manage virtual storage, including volumes, snapshots, and mirrors vserver> Manage Vservers

cluster1::>


The “admin” user is assigned the “admin” role, which grants full access to all of the CLI commands, soyou see quite a few commands listed.

Now you will log into cluster1 using the “stat_acct” account to see how the “stats” role restricts theaccount#s command access.

8. Open a new PuTTY session. (Do not close your existing “admin” user PuTTY session to cluster1, as youwill need that later in this exercise).

8

Figure 3-3:

9. Double-click the saved session for cluster1.

9

Figure 3-4:

10. Log in as the stat_acct user, using the password Netapp1!.


11. Verify your login identity.

cluster1::> whoami (security login whoami)

User: stat_acct

cluster1::>

12. Press the “?” key to see a list of the CLI commands available to the “stat_acct” account..

cluster1::> ? up Go up one directory exit Quit the CLI session history Show the history of commands for this CLI session man Display the on-line manual pages redo Execute a previous command rows Show/Set the rows for this CLI session security> The security directory statistics> Display operational statistics top Go to the top-level directory

cluster1::>

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.

cluster1::> exit

3.4 Configuring Firewalls

This section introduces the configuration of firewalls. Firewalls control which network protocols (services) areallowed to pass data on ONTAP 9’s network interfaces. The firewalls are services running on each node inthe 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 administratorsand external management applications may access the cluster for management purposes, andcommunications between cluster peers.

There are three built-in policies defined in ONTAP 9. These policies cannot be removed, however clusteradministrators can define new policies to use instead of the predefined policies. The network protocol servicesthat can be used in a policy are listed in the following table.

Table 8: Table: Network Protocols Allowed in Firewall Policies

Protocol Description

dns Use for Domain Name Services

http Hyper-text transfer protocol (not recommended)

https Secure Hyper-text transfer protocol (recommendedover HTTP)

ndmp Network Data Management Protocol

ndmps Secure Network Data Management Protocol(recommended over NDMP)

ntp Network Time Protocol


Protocol Description

rsh Remote Shell (highly discouraged and notrecommended, disabled by default)

snmp Simple Network Management Protocol

ssh Secure Shell

telnet Telnet Protocol (highly discouraged and notrecommended, disabled by default)

The following table lists the default configuration of the built-in firewall policies.

Table 9: Table: Built-in Firewall Policies

Built-In Policy Name Default Protocol Entries and Allowed Networks

dns 0.0.0.0/0

ndmp 0.0.0.0/0

data

ndmps 0.0.0.0/0

https 0.0.0.0/0

ndmp 0.0.0.0/0

intercluster

ndmps 0.0.0.0/0

dns 0.0.0.0/0

http 0.0.0.0/0

https 0.0.0.0/0

ndmp 0.0.0.0/0

ndmps 0.0.0.0/0

ntp 0.0.0.0/0

snmp 0.0.0.0/0

mgmt

ssh 0.0.0.0/0

Each policy will contain one (1) or more entries that specify which network protocol service to allow, and a listof the valid IP networks and IP addresses that are allowed to access that network service. The absence of aparticular network protocol service entry prevents any access using that protocol over the network interfaces thatrely on that firewall policy.

The firewall commands are located in the system services firewall command sub-directory, and the systemservices firewall policy sub-directory beneath that. The following tables list the commands, and their purpose.

Table 10: Table: Cluster System Service Firewall Commands

Command Purpose

modify Change the status of the firewall running on a clusternode.

policy> Navigate into the policy commands sub-directory.

show Show the current status of the firewall(s).


Table 11: Table: Cluster System Service Firewall Policy 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.

3.4.1 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 SVMrunning 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, butyou 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 192.168.0.0/24 subnet.

cluster1::> system services firewall policy create -vserver cluster1 -policy mgmt2 -service ssh -allow-list 192.168.0.0/24

cluster1::>

2. Add to the “mgmt2” policy DNS protocol access for just the 192.168.0.0/24 subnet.

cluster1::> system services firewall policy create -vserver cluster1 -policy mgmt2 -service dns -allow-list 192.168.0.0/24

cluster1::>

3. Add to the “mgmt2” policy https protocol https access for just the 192.168.0.0/24 subnet.

cluster1::> system services firewall policy create -vserver cluster1 -policy mgmt2 -service https -allow-list 192.168.0.0/24

cluster1::>

4. Add to the “mgmt2” policy ntp protocol access for just the 192.168.0.0/24 subnet.

cluster1::> system services firewall policy create -vserver cluster1 -policy mgmt2 -service ntp -allow-list 192.168.0.0/24

cluster1::>

5. Create a new policy named “cifs_mgmt2” for the SVM cifs_svm that permits SSH protocol access to justthe 192.168.0.0/24 subnet.

cluster1::> system services firewall policy create -vserver cifs_svm -policy cifs_mgmt2 -service ssh -allow-list 192.168.0.0/24

cluster1::>

6. Add to the cifs_mgmt2 policy DNS protocol access for just the 192.168.0.0/24 subnet.

cluster1::> system services firewall policy create -vserver cifs_svm -policy cifs_mgmt2 -service dns -allow-list 192.168.0.0/24


cluster1::>

7. List the new policies you just created.

cluster1::> system services firewall policy showVserver Policy Service Allowed------- ------------ ---------- -------------------cifs_svm cifs_mgmt2 dns 192.168.0.0/24 ssh 192.168.0.0/24cluster1 data dns 0.0.0.0/0 ndmp 0.0.0.0/0 ndmps 0.0.0.0/0cluster1 intercluster https 0.0.0.0/0 ndmp 0.0.0.0/0 ndmps 0.0.0.0/0cluster1 mgmt dns 0.0.0.0/0 http 0.0.0.0/0 https 0.0.0.0/0 ndmp 0.0.0.0/0 ndmps 0.0.0.0/0 ntp 0.0.0.0/0 snmp 0.0.0.0/0 ssh 0.0.0.0/0cluster1 mgmt2 dns 192.168.0.0/24 https 192.168.0.0/24 ntp 192.168.0.0/24 ssh 192.168.0.0/2420 entries were displayed.

cluster1::>

3.5 Configure SSH

ONTAP administrators frequently use the Secure Shell (SSH) protocol for command line access to ONTAPcontrollers. How secure those network connections are depends on which key-exchange algorithms andencryption ciphers you are allowed to use. The basic SSH protocol supports a number of different algorithmsand ciphers, some more secure than others. SSH services in ONTAP support four (4) different key-exchangealgorithms, and seven (7) different ciphers. These are listed in the following table, ordered from most secure toleast.

Table 12: SSH Supported Encryption Ciphers and Key-Exchange Algorithms

Key Exchange Algorithms Encryption Ciphers MAC Algorithms

diffie-hellman-group-exchange-sha256

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


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 clientswhen connecting to the ONTAP 9 cluster, or SVM management network interfaces. Using algorithms and cipherswith larger key lengths will also help deter “man-in-the-middle” eaves-dropping on SSH connections, and possibledisclosure of critical login credentials. ONTAP 9 maintains a configuration for the cluster administration SVM, andeach 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.

3.5.1 Exercise

In this lab activity, you list the current SSH configuration for the ONTAP 9 cluster SVM (i.e., cluster1), and thenmodify that configuration to remove less secure ciphers.

1. In your PuTTY session to cluster1, view the cluster’s current SSH configuration.

cluster1::> security ssh show -vserver cluster1

Vserver: cluster1Key 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

cluster1::>

Note: The command to simultaneously change key-exchange algorithms, ciphers, and hashingalgorithms is very long, and prone to typing errors in this lab. For brevity, this exercise will onlyfocus on changing the encryption ciphers; the procedure for changing key-exchange algorithmsand hashing algorithms is very similar.

2. Refine the SSH configuration for the “cluster1” SVM so it only accepts the more secure algorithms.

cluster1::> 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.


cluster1::>

Caution: Modifications to the cluster SSH configuration become the default for any newlycreated SVMs that enable SSH management access. Pre-existing SVMs retain their previousSSH configuration.

3. View the cluster's SSH configuration again.

cluster1::> security ssh show -vserver cluster1

Vserver: cluster1Key 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::>

Cluster1 now only accepts a more limited set of ciphers, but other SVMs still retains their previous SSHconfiguration.

3.6 Configure CLI Session Timeouts

Because administrators routinely manage systems from centralized, remote locations, they may do a lot of “multi-tasking” and lose track of CLI sessions they have open on various systems and ONTAP 9 storage clusters. Onother 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-bymay 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.

3.6.1 Exercise

In this exercise, you modify the CLI session timeout value (in minutes) from the ONTAP 9 default of 30 minutes,to a new value of 10 minutes.

1. In your PuTTY session to cluster1, view your current timeout for CLI sessions.

cluster1::> system timeout showCLI session timeout: 0 minutes

cluster1::>

Your current system timeout is 0 minutes, which means the CLI session will never time out. (Newlyinstalled ONTAP 9 will have a value of 30 minutes.)

2. Change the CLI timeout to 10 minutes.

cluster1::> system timeout modify -timeout 10

cluster1::>

3. View your current CLI timeout again.

cluster1::> system timeout show


CLI session timeout: 10 minutes

cluster1::>

Note: When a CLI session times out in this lab, the associated PuTTY window closes. To avoidthe inconvenience of having console sessions close on you during this lab, you might want toconsider disabling timeouts entirely by setting the timeout value to 0.

3.7 Configure SSL/TLS

Some management features of ONTAP 9 require the existence of certain core “web” services running on clustermember 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 default, the core web services are enabled at time of installation. This allows external web clients access to theexported web content. Enabling these services does not guarantee visibility to clients, only that ONTAP is capableof exporting such content.

The system services firewall policies actually determine which web protocols (HTTP, HTTPS, or both) are visibleon 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 default.• SSLv3 (Secure Socket Layer version 3) which is disabled by default.• SSL FIPS 140-2 compliance which is disabled by default.

Note: SSLv3 and FIPS 140-2 are mutually exclusive. Enabling FIPS 140-2 mode disables SSLv3.

Assuming that HTTPS is allowed in the current firewall policies, access by an external HTTPS client is determinedby 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.2only (recommend enabling TLSv1.1 and TLSv1.2 only)

FIPS 140-2 Enabled Client has access with TLSv1.2 and TLSv1.1 if FIPS140-2 compliant

3.7.1 Exercise

In this exercise, you will perform the following tasks:

• View the current Web Core Services settings and status (both from a cluster and member nodeperspective).

• Disable web services.• Try connection from a web browser.• Enable web services.• Try connection from a web browser.


• View SSL/TLS configuration settings and status.

1. In your PuTTY session for cluster1, display the current availability of web services on the cluster.

cluster1::> system services web show External Web Services: true Status: online HTTP Protocol Port: 80 HTTPS Protocol Port: 443 HTTP Enabled: true

cluster1::>

2. Display the operational configuration for the web server processes on the nodes in the cluster.

cluster1::> system services web node show HTTP HTTP HTTPS Total TotalNode External Enabled Port Port Status HTTP Requests Bytes Served------------- -------- ------- ----- ----- -------- ------------- ------------cluster1-01 true true 80 443 online 58 69890

cluster1::>

3. Disable remote client access to HTTP and HTTPS service content hosted on the cluster.

cluster1::> system services web modify -external false

cluster1::>

4. On the desktop of Jumphost, launch the Chrome web browser by clicking on the Chrome icon found onthe 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 inyour lab, place your cursor at the end of the URL and hit the Enter key to reload the page. This shouldcorrect the problem.


5

Figure 3-6:

6. In your PuTTY session to cluster1, re-enable web services.

cluster1::> system services web modify -external true

cluster1::>

7. Refresh your Chrome browser page.


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 thesecurity/config commands. Then you may show the configuration.

cluster1::> 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 Cluster SecurityInterface FIPS Mode Supported Protocols Supported Ciphers Config Ready--------- ---------- ----------------------- ----------------- ----------------SSL false TLSv1.2, TLSv1.1 ALL:!RC4:!LOW: yes !aNULL:!EXP: !eNULL


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 toimplement the current configuration.

cluster1::*> security config status showNodes in Cluster Reboot Needed--------------------- -------------------cluster1-01 false

cluster1::*>

10. Return your CLI session back to “admin” privilege level.

cluster1::*> set -privilege admin

cluster1::>

3.8 NFS/CIFS Export Policies

This section introduces the topic of NAS (NFS and SMB) export policies. Export policies are used to restrictNAS access to specific clients. These access restrictions are based on the client host’s identity (determined bythe host’s IP address or subnet), as opposed to an ACL which enforces restrictions based on the identity of theaccessing user or group.

As of Clustered Data ONTAP 8.2, assigning export policies for SMB (CIFS) access is optional. Many customersare 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 exportpolicies 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 associatedexport policy.

When you create a volume for an SVM, ONTAP 9 automatically creates a default export policy. It is not populatedwith 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 default the CIFS export policy is disabled. To enable the exportpolicy, issue the vserver cifs options modify command at the “advanced” privilege level. If the CIFS serviceoption 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 creatingan export policy does not automatically export the data through the CIFS protocol. On the other hand, dataserved 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 nameand is associated with the SVM that owns it. Export policies contain zero (0) or more rules, and access rules mustbe added to an empty (0 rules) policy before any NAS data can be accessed by clients. These rules contain thefollowing components:

Table 14: Table: Export Policy Rule Components

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:


Component Purpose• Hostname• IPv4 address• IPv6 address• IPv4 subnet• Ipv6 subnet• Netgroup• Domain

access protocol Protocol used to access the exported/shared data

• 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

read-only access rule

(security type)

One or more authentication methods allowed for read-only access:

• 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

read/write access rule

(security type)

Same access method requests as defined in the read-only access description.

anonymous user map User ID to which anonymous users are mapped(65534 default)

superuser access rule

(security type)

Same access method requests as defined in the read-only access description with the exception of "never".

allow suid flag Honor SetUID bits in SETATTR when true (default)

allow dev flag Allow creation of devices is true (default).

Access rules are processed sequentially in ascending index order. Placing more restrictive rules before othersmay prevent access being granted. In addition, a client can only get read-write access for a specific security typeif the export rule also allows read-only access for that security type. If the read-only parameter is more restrictivethan the read-write parameter, the client might not get read-write access.

3.8.1 CIFS Exercise

In this exercise you enable CIFS export policy enforcement on the SVM cifs_svm, configure two CIFS exportpolicies, and then apply them to the cifsdv1 and cisfdv2 SVM’s volumes as detailed in the “CIFS Exercise ExportPolicies” table. You will also verify that these policies properly grant or deny access to two different Windowsclients in the lab.


Table 15: CIFS Exercise Export Policies

Volume Export Policy Rule Resulting Access

cifs_svm_root default 1 Grant read-write access to all CIFS clients in the lab IP subnet.

1 Grant read-only and read-write access to the client “WIN2K12R2”cifsdv1 cifs_pol1

2 Deny access to all other clients

1 Grant read-only access to the client "WIN2K12R2".cifsdv2 cifs_pol2

2 Deny access to all other clients

1. In the PuTTY session for cluster1, switch to “advanced” mode.

cluster1::> 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-enabledvserver 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 thevserver’s “is-exportpolicy-enabled” CIFS option is not enabled, but those policies, rules, andassignments will be ignored by ONTAP until the SVM's “is-exportpolicy-enabled” option is set totrue.

4. Leave “advanced” mode.

cluster1::*> set admin

cluster1::>

5. List the volumes that reside on the SVM cifs_svm.

cluster1::> volume show -vserver cifs_svmVserver Volume Aggregate State Type Size Available Used%--------- ------------ ------------ ---------- ---- ---------- ---------- -----cifs_svm cifs_svm_root aggr_data1 online RW 20MB 18.85MB 5%cifs_svm cifsdv1 aggr_data1 online RW 10GB 9.50GB 5%cifs_svm cifsdv2 aggr_data1 online RW 10GB 9.50GB 5%3 entries were displayed.

cluster1::>

6. View the export policy assignments for each volume.

cluster1::> volume show -vserver cifs_svm -fields policyvserver volume policy -------- ------------- ------- cifs_svm cifs_svm_root default cifs_svm cifsdv1 default cifs_svm cifsdv2 default 3 entries were displayed.

cluster1::>

For CIFS, export policies can only be applied to volumes. The output lists three volumes, all of whichare using the “default” export policy. The volume names match those in the CIFS Exercise Export Rules


table shown earlier in this exercise, but if you look closely, the assigned export policies do not (yet) allmatch 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.

cluster1::> vserver export-policy showVserver Policy Name--------------- -------------------cifs_svm defaultnfs_svm default2 entries were displayed.

cluster1::>

A policy’s scope is limited to a single SVM. As you can see, both cifs_svm and nfs_svm have an exportpolicy named “default”, but these are in fact two separate export policies. Clustered Data ONTAPautomatically creates the “default” policy when you create the SVM.

8. View the rules for cifs_svm's export policies.

cluster1::> vserver export-policy rule show -vserver cifs_svmThere are no entries matching your query.

cluster1::>

There are no export rules at present. When a policy is created it does not contain any rules, and withoutany rules all mount requests for a volume assigned that policy will be denied.

9. Create a rule in the “default” export policy that will allow all CIFS clients on the lab’s local network.

cluster1::> vserver export-policy rule create -vserver cifs_svm -policyname default -ruleindex 1 -protocol cifs -clientmatch 192.168.0.0/24 -rorule krb5 -rwrule krb5

cluster1::>

10. View the rules for cifs_svm’s export policies again.

cluster1::> vserver export-policy rule show -vserver cifs_svm Policy Rule Access Client ROVserver Name Index Protocol Match Rule------------ --------------- ------ -------- --------------------- ---------cifs_svm default 1 cifs 192.168.0.0/24 krb5

cluster1::>

Observe that this command only shows a partial set of the rule parameters you specified when youcreated the rule.

11. View the details of the rules for the default export policy.

cluster1::> vserver export-policy rule show -vserver cifs_svm -policyname default -instance

Vserver: cifs_svm Policy Name: default Rule Index: 1 Access Protocol: cifsClient Match Hostname, IP Address, Netgroup, or Domain: 192.168.0.0/24 RO Access Rule: krb5 RW Access Rule: krb5User ID To Which Anonymous Users Are Mapped: 65534 Superuser Security Types: none Honor SetUID Bits in SETATTR: true Allow Creation of Devices: true

cluster1::>

Now you can see the full set of rule properties. This rule grants read-only and read-write access to anyCIFS host on the lab’s local network (192.168.0.0/24). The “krb5” value on the access rule authorizesKerberos 5 authentication, which is the authentication method used by the Windows 2012 hosts in thislab. The properties that you did not explicity specify were populated with default values, but since theseextra 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.


12. Create a new policy named cifs_pol1 for the SVM cifs_svm.

cluster1::> vserver export-policy create -vserver cifs_svm -policyname cifs_pol1

cluster1::>

13. Observe that this newly created export policy contains no rules.

cluster1::> vserver export-policy rule show -vserver cifs_svm -policyname cifs_pol1There are no entries matching your query.

cluster1::>

14. Add a rule to this policy granting read and read-write access to the IP address assigned to theWIN2K12R2 host.

cluster1::> vserver export-policy rule create -vserver cifs_svm -policyname cifs_pol1 -ruleindex 1 -protocol cifs -clientmatch 192.168.0.41 -rorule krb5 -rwrule krb5

cluster1::>

15. Add another rule to this policy that denies access to all other hosts.

cluster1::> vserver export-policy rule create -vserver cifs_svm -policyname cifs_pol1 -ruleindex 2 -protocol any -clientmatch 0.0.0.0/0 -rorule never -rwrule never

cluster1::>

While this rule is not strictly necessary, as the first rule will only grant explicit access to the192.168.0.41 host (implying that all others will be denied), it is good security practice to explicitly denyany 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.

cluster1::> vserver export-policy rule show -vserver cifs_svm -policyname cifs_pol1 -instance

Vserver: cifs_svm Policy Name: cifs_pol1 Rule Index: 1 Access Protocol: cifsClient Match Hostname, IP Address, Netgroup, or Domain: 192.168.0.41 RO Access Rule: krb5 RW Access Rule: krb5User ID To Which Anonymous Users Are Mapped: 65534 Superuser Security Types: none Honor SetUID Bits in SETATTR: true Allow Creation of Devices: true

Vserver: cifs_svm Policy Name: cifs_pol1 Rule Index: 2 Access Protocol: anyClient Match Hostname, IP Address, Netgroup, or Domain: 0.0.0.0/0 RO Access Rule: never RW Access Rule: neverUser ID To Which Anonymous Users Are Mapped: 65534 Superuser Security Types: none Honor SetUID Bits in SETATTR: true Allow Creation of Devices: true2 entries were displayed.

cluster1::>

As you saw in the “CIFS Exercise Export Policies” table, the “cifs_pol1” policy grants read-only andread-write access to the host WIN2K12R2, and denies access to all others.

17. Apply this export policy to the volume “cifsdv1”.

cluster1::> volume modify -vserver cifs_svm -volume cifsdv1 -policy cifs_pol1Volume modify successful on volume cifsdv1 of Vserver cifs_svm.

cluster1::>


18. Create the cifs_pol2 policy.

cluster1::> vserver export-policy create -vserver cifs_svm -policyname cifs_pol2

cluster1::>

19. Create a rule for this policy granting read-only access to the host WIN2K12R2.

cluster1::> vserver export-policy rule create -vserver cifs_svm -policyname cifs_pol2 -ruleindex 1 -protocol cifs -clientmatch 192.168.0.41 -rorule krb5 -rwrule none

cluster1::>

20. Add another rule to this policy denying access to all other hosts.

cluster1::> vserver export-policy rule create -vserver cifs_svm -policyname cifs_pol2 -ruleindex 2 -protocol any -clientmatch 0.0.0.0/0 -rorule never -rwrule never

cluster1::>

21. View the rules for the “cifs_pol2” policy.

cluster1::> vserver export-policy rule show -vserver cifs_svm -policyname cifs_pol2 -instance

Vserver: cifs_svm Policy Name: cifs_pol2 Rule Index: 1 Access Protocol: cifsClient Match Hostname, IP Address, Netgroup, or Domain: 192.168.0.41 RO Access Rule: krb5 RW Access Rule: noneUser ID To Which Anonymous Users Are Mapped: 65534 Superuser Security Types: none Honor SetUID Bits in SETATTR: true Allow Creation of Devices: true

Vserver: cifs_svm Policy Name: cifs_pol2 Rule Index: 2 Access Protocol: anyClient Match Hostname, IP Address, Netgroup, or Domain: 0.0.0.0/0 RO Access Rule: never RW Access Rule: neverUser ID To Which Anonymous Users Are Mapped: 65534 Superuser Security Types: none Honor SetUID Bits in SETATTR: true Allow Creation of Devices: true2 entries were displayed.

cluster1::>

22. Apply the cifs_pol2 export policy to the “cifsdv2” volume.


cluster1::>

One method to test whether these policies and rules accomplish what you want is to log into the listedclients 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 testthe processing of the rules directly from the ONTAP CLI using the vserver export-policy check-accesscommand.

23. In the PuTTy session for cluster1, test to see if WIN2K12R2 has read access to the cifsdv1 share overthe 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 192.168.0.41.

cluster1::> vserver export-policy check-access -vserver cifs_svm -volume cifsdv1 -protocol cifs -authentication-method krb5 -client-ip 192.168.0.41 -access-type read Policy Policy RulePath Policy Owner Owner Type Index Access----------------------------- ---------- --------- ---------- ------ ----------/ default cifs_svm_root volume 1 read


/cifsdv1 cifs_pol1 cifsdv1 volume 1 read2 entries were displayed.

cluster1::>

The output shows the complete access path to the volume, first through the root volume of the cifs_svmSVM's namespace (volume “cifs_svm_root”, path “/”), then through the cifsdv1 volume. As you can see,the 192.168.0.41 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 usingKerberos 5 authentication.

cluster1::> vserver export-policy check-access -vserver cifs_svm -volume cifsdv1 -protocol cifs -authentication-method krb5 -client-ip 192.168.0.41 -access-type read-write Policy Policy RulePath Policy Owner Owner Type Index Access----------------------------- ---------- --------- ---------- ------ ----------/ default cifs_svm_root volume 1 read/cifsdv1 cifs_pol1 cifsdv1 volume 1 read-write2 entries were displayed.

cluster1::>

WIN2K12R2 has read-write access to the path /cifsdv1.25. 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 192.168.0.5.

cluster1::> vserver export-policy check-access -vserver cifs_svm -volume cifsdv1 -protocol cifs -authentication-method krb5 -client-ip 192.168.0.5 -access-type read Policy Policy RulePath Policy Owner Owner Type Index Access----------------------------- ---------- --------- ---------- ------ ----------/ default cifs_svm_root volume 1 read/cifsdv1 cifs_pol1 cifsdv1 volume 2 denied2 entries were displayed.

cluster1::>

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.

cluster1::> vserver export-policy check-access -vserver cifs_svm -volume cifsdv1 -protocol cifs -authentication-method krb5 -client-ip 192.168.0.5 -access-type read-write Policy Policy RulePath Policy Owner Owner Type Index Access----------------------------- ---------- --------- ---------- ------ ----------/ default cifs_svm_root volume 1 read/cifsdv1 cifs_pol1 cifsdv1 volume 2 denied2 entries were displayed.

cluster1::>

Write access is also denied at the /cifsdv1 level.27. On the desktop of Jumphost, open Windows Explorer.


27

Figure 3-8:

28. In Windows Explorer, in the navigation pane select This PC.29. On the menu bar click Computer.30. Click Map Network Drive.

28

29

30

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

32. Click Finish.


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.


33

Figure 3-11:

34. Note that the window reports “Access is denied”. Windows attempted to use your login credentials toaccess the share, but was unable to because the export policy rules denied access. Windows does notunderstand the reason for the denial, it just assumes that you need different credentials which is why itprompts you for a login and password. But regardless of which credentials you enter, the access policyrules prevent you from accessing this share from Jumphost.

35. Click the Cancel button.

34 35

Figure 3-12:

The “Windows Security” window closes, and focus returns to the “Map Network Drive” window.


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 exercisebecause you will use that share in the SMB (CIFS) ACLs exercise later in this guide. This will clearly demonstratethat the host WIN2K12R2 can access that share.

3.8.2 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 nfsdvs1 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

Volume Qtree Export Policy Rule Resulting Access

“” default 1 Grant access to underlying qtrees, directories, andfiles to all NFS clients in the lab IP subnet.

1 Grant read-write access to client “rhel1” usingprotocol NFSv4 and AUTH_SYS security

nfsdv1

qt1 nfs_pol1

2 Grant read-only access to client “rhel1” using protocolNFSv3 and AUTH_SYS security


Volume Qtree Export Policy Rule Resulting Access

3 Grant read-only access to client “rhel2” using protocolNFSv4 and AUTH_SYS security

4 Prohibit access to client “rhel2” if protocol is otherthan NFSv4

qt2 default 1 Grant access to underlying qtrees, directories, andfiles 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 hasalso 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 192.168.0.61) and“rhel2” (IP address 192.168.0.62).

1. In the PuTTY session for cluster1, display the list of policies for the svm nfs_svm.

cluster1::> vserver export-policy show -vserver nfs_svmVserver Policy Name--------------- -------------------nfs_svm default

cluster1::>

When you first create an SVM, ONTAP 9 automatically creates an empty export policy named “default”.When you create a new volume, ONTAP 9 automatically assigns the “default” export policy to thatvolume. When you create a qtree, that qtree inherits the parent volume’s export policy assignment.

2. Display the list of rules of the default policy for the SVM nfs_svm.

cluster1::> vserver export-policy rule show -vserver nfs_svm -policyname defaultThere are no entries matching your query.

cluster1::>

The “default” export policy contains no rules, as is the case for any newly created export policy.3. Add a rule to the “default” policy that grants read-only access to any client on the labs local network

(192.168.0.0/24).

cluster1::> vserver export-policy rule create -vserver nfs_svm -policyname default -clientmatch 192.168.0.0/24 -protocol any -rorule any -rwrule never -superuser none -anon 65534 -ruleindex 1

cluster1::>

4. Display the updated list of rules for the default policy.

cluster1::> vserver export-policy rule show -vserver nfs_svm -policyname default Policy Rule Access Client ROVserver Name Index Protocol Match Rule------------ --------------- ------ -------- --------------------- ---------nfs_svm default 1 any 192.168.0.0/24 any

cluster1::>

5. Create a new policy named nfs_pol1.

cluster1::> vserver export-policy create -vserver nfs_svm -policyname nfs_pol1

cluster1::>

6. Add a rule to the “nfs_pol1” policy that grants NFSv4 read-write access to rhel1 (IP address192.168.0.61).

cluster1::> vserver export-policy rule create -vserver nfs_svm -policyname nfs_pol1 -clientmatch 192.168.0.61 -protocol nfs4 -rorule sys -rwrule sys -allow-suid true -allow-dev false -superuser sys -anon 65534 -ruleindex 1


cluster1::>

7. Add a rule to the “nfs_pol1” policy that grants NFS v3 read access to rhel1.

cluster1::> vserver export-policy rule create -vserver nfs_svm -policyname nfs_pol1 -clientmatch 192.168.0.61 -protocol nfs3 -rorule sys -rwrule never -allow-suid false -allow-dev false -superuser none -anon 65534 -ruleindex 2

cluster1::>

8. Add a rule to the “nfs_pol1” policy that grants NFS v4 read access to rhel2 (IP address 192.168.0.62).

cluster1::> vserver export-policy rule create -vserver nfs_svm -policyname nfs_pol1 -clientmatch 192.168.0.62 -protocol nfs4 -rorule sys -rwrule never -allow-suid false -allow-dev false -superuser none -anon 65534 -ruleindex 3

cluster1::>

9. Add a rule to the “nfs_pol1” policy that denies access to rhel2 via any other protocol than NFSv4.

cluster1::> vserver export-policy rule create -vserver nfs_svm -policyname nfs_pol1 -clientmatch 192.168.0.62 -protocol any -rorule never -rwrule never -allow-suid false -allow-dev false -superuser none -anon 65534 -ruleindex 4

cluster1::>

10. Display the updated list of rules for the “nfs_pol1” policy.

cluster1::> vserver export-policy rule show -vserver nfs_svm -policyname nfs_pol1 Policy Rule Access Client ROVserver Name Index Protocol Match Rule------------ --------------- ------ -------- --------------------- ---------nfs_svm nfs_pol1 1 nfs4 192.168.0.61 sysnfs_svm nfs_pol1 2 nfs3 192.168.0.61 sysnfs_svm nfs_pol1 3 nfs4 192.168.0.62 sysnfs_svm nfs_pol1 4 any 192.168.0.62 never4 entries were displayed.

cluster1::>

11. List the qtrees on the nfs_svm SVM, along with their assigned export policy.

cluster1::> volume qtree show -vserver nfs_svm -fields export-policyvserver volume qtree export-policy ------- ------------ ----- ------------- nfs_svm nfs_svm_root "" default nfs_svm nfsdv1 "" default nfs_svm nfsdv1 qt1 default nfs_svm nfsdv1 qt2 default 4 entries were displayed.

cluster1::>

The volume qtree show command output does not ordinarily include export policy assignmentinformation, but as you have seen, you can print all of the available fields in a non-table format by usingthe -instance parameter. The -fields parameter you used here allows you to selectively list the names ofjust the specific fields you want to display while retaining the table format.

The output shows that the all the qtrees are currently assigned the “default” export policy. When a qtreeis created it inherits the export policy associated with it's parent volume.

12. Change the export policy assignment for qtree qt1 to nfs_pol1.

cluster1::> volume qtree modify -vserver nfs_svm -volume nfsdv1 -qtree qt1 -export-policy nfs_pol1

cluster1::>

13. Display the updated qtree export policy assignments.

cluster1::> volume qtree show -vserver nfs_svm -fields export-policyvserver volume qtree export-policy ------- ------------ ----- ------------- nfs_svm nfs_svm_root "" default


nfs_svm nfsdv1 "" default nfs_svm nfsdv1 qt1 nfs_pol1 nfs_svm nfsdv1 qt2 default 4 entries were displayed.

cluster1::>

Now test the proper configuration and application of these export policies relative to the rhel1 NFSclient 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 192.168.0.61.

cluster1::> vserver export-policy check-access -vserver nfs_svm -volume nfsdv1 -authentication-method sys -client-ip 192.168.0.61 -qtree qt1 -protocol nfs4 -access-type read Policy Policy RulePath Policy Owner Owner Type Index Access----------------------------- ---------- --------- ---------- ------ ----------/ default nfs_svm_root volume 1 read/nfsdv1 default nfsdv volume 1 read/nfsdv1/qt1 nfs_pol1 qt1 qtree 1 read3 entries were displayed.

cluster1::>

Access is allowed.15. Test to see if rhel1 has read-write access to the qt1 qtree over the NFSv4 protocol using sys

authentication.

cluster1::> vserver export-policy check-access -vserver nfs_svm -volume nfsdv1 -authentication-method sys -client-ip 192.168.0.61 -qtree qt1 -protocol nfs4 -access-type read-write Policy Policy RulePath Policy Owner Owner Type Index Access----------------------------- ---------- --------- ---------- ------ ----------/ default nfs_svm_root volume 1 read/nfsdv1 default nfsdv1 volume 1 read/nfsdv1/qt1 nfs_pol1 qt1 qtree 1 read-write3 entries were displayed.

cluster1::>

Access is allowed.16. Test to see if rhel1 has read access to the qt1 qtree over the NFSv3 protocol using sys authentication.

cluster1::> vserver export-policy check-access -vserver nfs_svm -volume nfsdv1 -authentication-method sys -client-ip 192.168.0.61 -qtree qt1 -protocol nfs3 -access-type read Policy Policy RulePath Policy Owner Owner Type Index Access----------------------------- ---------- --------- ---------- ------ ----------/ default nfs_svm_root volume 1 read/nfsdv1 default nfsdv1 volume 1 read/nfsdv1/qt1 nfs_pol1 qt1 qtree 2 read3 entries were displayed.

cluster1::>


authentication.

cluster1::> vserver export-policy check-access -vserver nfs_svm -volume nfsdv1 -authentication-method sys -client-ip 192.168.0.61 -qtree qt1 -protocol nfs3 -access-type read-write Policy Policy RulePath Policy Owner Owner Type Index Access----------------------------- ---------- --------- ---------- ------ ----------/ default nfs_svm_root volume 1 read/nfsdv1 default nfsdv1 volume 1 read/nfsdv1/qt1 nfs_pol1 qt1 qtree 2 denied3 entries were displayed.


cluster1::>

Access is denied.

Now test the proper configuration and application of these export policies relative to the rhel2 NFSclient, 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.

cluster1::> vserver export-policy check-access -vserver nfs_svm -volume nfsdv1 -authentication-method sys -client-ip 192.168.0.62 -qtree qt1 -protocol nfs4 -access-type read Policy Policy RulePath Policy Owner Owner Type Index Access----------------------------- ---------- --------- ---------- ------ ----------/ default nfs_svm_root volume 1 read/nfsdv1 default nfsdv1 volume 1 read/nfsdv1/qt1 nfs_pol1 qt1 qtree 3 read3 entries were displayed.

cluster1::>


authentication.


cluster1::>

Access is denied.20. Test to see if rhel2 has read access to the qt1 qtree over the NFSv3 protocol using sys authentication.

cluster1::> vserver export-policy check-access -vserver nfs_svm -volume nfsdv1 -authentication-method sys -client-ip 192.168.0.62 -qtree qt1 -protocol nfs3 -access-type read Policy Policy RulePath Policy Owner Owner Type Index Access----------------------------- ---------- --------- ---------- ------ ----------/ default nfs_svm_root volume 1 read/nfsdv1 default nfsdv1 volume 1 read/nfsdv1/qt1 nfs_pol1 qt1 qtree 4 denied3 entries were displayed.

cluster1::>

Access is denied.21. Test to see if rhel2 has read-write access to the qt1 qtree over the NFSv3 protocol using sys

authentication.


cluster1::>


Access is denied.

If you would like to test access to these qtrees directly from rhel1 and rhel2, that activity is not coveredin this lab guide, but you are welcome to do so on your own. You can use PuTTY to establish Linuxterminal sessions to rhel1 and rhel2.

3.9 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). ACLshave always been a fundamental part of the Microsoft Windows NTFS file system. More recently, ACLs havebecome 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 theNTFS 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 shareACLs. For example, if your share ACL denies write access to all users, you will not be able to write to a folder onthe share even if that folders’ ACL grants Full Control to everyone, a scenario that is often very confusing for endusers.

When you first create an SMB (CIFS) share, ONTAP 9 automatically creates a share level ACL for the share.This default ACL grants full control to the Windows built-in group “Everyone”. If this default ACL does not providethe exact level of access control you desire, you may use System Manager or the ONTAP 9 CLI to modify and/ordelete the default 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 fromthat client using the Microsoft Management Console (MMC) Computer Management plug-in. You shoulduse 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 cifs share access-control, and it has thefollowing sub-commands.

• create

• modify

• delete

• show

When you issue the create, modify, and delete commands, you specify the vserver hosting the share, the sharename, 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

No_access All access is denied.

Read Can see, open, execute, and view permissions and attributesof the item. Can also list contents of folder.

Change Can create items; see, open, read, write, synchronize anddelete the item. Viewing permissions and attributes is alsoallowed.

Full_Control Can create items; see, open, read, write, delete the item;modify access rights and attributes and take ownership of theitem.


NTFS directory and file level ACLs refer to the ACLs on individual files and folders within a share. You are mostlikely already familiar with managing these kinds of ACLs for NTFS file systems by using Windows Explorer (byviewing a file or folder’s properties and going to the Security tab), or perhaps by using the Windows ICACLScommand line utility. You can use these same tools to manage the ACLs for individual folders and files hosted onNetApp 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 commandsfor managing directory and file level access control lists. Using these commands to manipulate ACLs requiresa 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 managingdirectory and file ACLs using the vserver security file-directory commands.

3.9 ACL ReferencesUsing ACLs to control or restrict access, as well as control the authorized access permissions of users andgroups can be a very complex undertaking. Before you attempt to implement ACLs in your own environment, westrongly 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

3.9.1 Exercise

In this exercise, you create several SMB (CIFS) shares, then view the shares to see how the default share-levelACL was created for each. You will add several share-level ACLs to each share, and modify/remove the default“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.

cluster1::> vserver cifs share show -vserver cifs_svmVserver Share Path Properties Comment ACL-------------- ------------- ----------------- ---------- -------- -----------cifs_svm admin$ / browsable - -cifs_svm c$ / oplocks - BUILTIN\Administrators / Full Control browsable changenotifycifs_svm cifsdv1 /cifsdv1 oplocks - Everyone / Full Control browsable changenotifycifs_svm cifsdv2 /cifsdv2 oplocks - Everyone / Full Control browsable changenotifycifs_svm ipc$ / browsable - -cifs_svm test_folder /cifsdv2/Test_ oplocks - Everyone / Full Control Folder browsable changenotify6 entries were displayed.

cluster1::>

The admin$, c$, and ipc$ shares are automatically created at SVM creation time. They have no directbearing 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.

cluster1::> vserver cifs share access-control show -vserver cifs_svm Share User/Group User/Group AccessVserver Name Name Type Permission-------------- ----------- --------------------------- ----------- -----------cifs_svm c$ BUILTIN\Administrators windows Full_Controlcifs_svm cifsdv1 Everyone windows Full_Controlcifs_svm cifsdv2 Everyone windows Full_Controlcifs_svm test_folder Everyone windows Full_Control4 entries were displayed.


cluster1::>

The cifsdv1, cifsdv2, and test_folder shares all grant Full Control to Everyone, which is the defaultACL configuration for a newly created share. In the next portion of this exercise you will deploy morerestrictive ACLs on these shares.

3. Grant Domain Admins Full Control of each of the the cifsdv1, cifsdv2, and test_folder shares.

cluster1::> vserver cifs share access-control create -vserver cifs_svm -user-group-type windows -user-or-group "Domain Admins" -permission Full_Control -share cifsdv1

cluster1::> vserver cifs share access-control create -vserver cifs_svm -user-group-type windows -user-or-group "Domain Admins" -permission Full_Control -share cifsdv2

cluster1::> vserver cifs share access-control create -vserver cifs_svm -user-group-type windows -user-or-group "Domain Admins" -permission Full_Control -share test_folder

cluster1::>

4. Add a change permissions ACL to the cifsdv1 share for the “CIFS Data Users” group.

cluster1::> vserver cifs share access-control create -vserver cifs_svm -user-group-type windows -user-or-group "CIFS Data Users" -permission change -share cifsdv1

cluster1::>

5. Add a change permissions ACL to the cifsdv2 share for the “CIFS 2nd Data Users” share.

cluster1::> vserver cifs share access-control create -vserver cifs_svm -user-group-type windows -user-or-group "CIFS 2nd Data Users" -permission change -share cifsdv2

cluster1::>

6. Add a change permissions ACL to the test_folder share for the “CIFS Data Users” group.

cluster1::> vserver cifs share access-control create -vserver cifs_svm -user-group-type windows -user-or-group "CIFS Data Users" -permission change -share test_folder

cluster1::>

7. Remove “Everyone” from each of the cifsdv1, cifsdv2, and test_folder shares.

cluster1::> vserver cifs share access-control delete -vserver cifs_svm -user-or-group "Everyone" -share cifsdv1

cluster1::> vserver cifs share access-control delete -vserver cifs_svm -user-or-group "Everyone" -share cifsdv2

cluster1::> vserver cifs share access-control delete -vserver cifs_svm -user-or-group "Everyone" -share test_folder

cluster1::>

If you removed the “Everyone” ACLs before adding the other ACLs, then you would have cut off allaccess to anyone using the share. By adding the new ACLs first, your targeted users can (at least) stillaccess the share through the ACL change.

8. Display a list of all the share-level ACLs for the SVM cifs_svm.

cluster1::> vserver cifs share access-control show -vserver cifs_svm Share User/Group User/Group AccessVserver Name Name Type Permission-------------- ----------- --------------------------- ----------- -----------cifs_svm c$ BUILTIN\Administrators windows Full_Controlcifs_svm cifsdv1 CIFS Data Users windows Changecifs_svm cifsdv1 Domain Admins windows Full_Controlcifs_svm cifsdv2 CIFS 2nd Data Users windows Changecifs_svm cifsdv2 Domain Admins windows Full_Controlcifs_svm test_folder CIFS Data Users windows Change


cifs_svm test_folder Domain Admins windows Full_Control7 entries were displayed.

cluster1::>

Now log into the WIN2K12R2 host as two different users (“datauser1” and “datauser3”) to observe theseACLs in action. These accounts both have the shares in the “Share Info” table pre-mapped. The “ShareACL permissions” column of this table describes which accounts are granted access to this share by theACLs 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 isa member.

Y: \\cifs\cifsdv2 Change Control for group "CIFS 2nd Data Users", of whichdatauser3 is a member.

Z: \\cifs\test_folder Change Control for group "CIFS Data Users", of which datauser1 isa member.

9. On the desktop of Jumphost, double-click the shortcut named WIN2K12R2, that launches RemoteDesktop 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 datauser2.11. Right-click on Datausers in the left pane, and select Connect group... from the context menu.


10

11

Figure 3-15:

Remote Desktop Connection Manager initiates two RDP sessions to the host WIN2K12R2, one foreach of the users DEMO\datauser1 and DEMO\datauser3. It may take a few moments, but eventuallythe application will display a thumbnail for each desktop session in the right pane.

12. In the left pane of Remote Desktop Connection Manager, expand the list of hosts that are part of theDatausers connection group by clicking on the + sign just to the left of Datausers. You should now seeentries for both datauser1 and datauser3 in the left pane.

13. Initiate a remote desktop session to WIN2K12R2 as datauser1 by clicking on the datauser1 entry in theleft pane. This will open the remote desktop session for datauser1 on WIN2K12R2 in the right pane.

14. On the WIN2K12R2 desktop for datauser1, open Windows Explorer.15. In the left pane of Windows Explorer, expand This PC.16. 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.


12 13

14

15

16

Figure 3-16:

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


17

18

Figure 3-17:

19. Name the file newfile.


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.


20

21

Figure 3-19:

A “Destination Folder Access Denied” window opens, explaining that you need permission to performthis action.

Notice, you created the same ACLs for both the cifsdv1 and test_folder shares, so why is datauser1able to write to cifsdv1, and not to test_folder? The error message provides no information whypermission 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 thatthe cifsdv1 volume is using the cifs_pol1 export policy that grants read and write access to the hostWIN2K12R2. The test_folder share is hosted on the cifsdv2 volume, which is using the cifs_pol2 policythat only grants read access to the host WIN2K12R2. So, although the share ACL says you have writepermission, the export policy for the share’s containing volume takes precedence and restricts you toread-only access. This example illustrates some of the complexities that arise when you deploy bothCIFS export polices and share ACLs, and is why CIFS export policy implementations are uncommon.

22. Click Cancel.


22

Figure 3-20:

The read-only export policy used for the cifsdv2 volume also interferes with the rest of this exercise, soyou need to remove this restriction by having the cifsdv2 volume use the same export policy used forcifsdv1.

23. In the PuTTy session for cluster1, configure the cifsdv2 volume to use the cifs_pol1 export policy.


cluster1::>

24. In the left pane of the Remote Desktop Manager window, select the entry for datauser3.25. Open Windows Explorer.26. In the left pane of Windows Explorer, expand This PC.27. 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.


24

25

26

27

Figure 3-21:

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

menu.


28

29

Figure 3-22:

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


30

31

Figure 3-23:

32. Right-click in this folder, and select New > Text Document from the context menu.


32

Figure 3-24:

33. Name this file yetanotherfile. You are able to create this file too.


33

Figure 3-25:

Once again, you may wonder why this works given that you set up a share ACL for the Test_Foldershare that only grants change control to members of the “CIFS Data Users” group. The datauser3account 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 mapto the test_folder share. This is correct behavior based on the share ACLs you configured to meet therequirements listed in the Share Info table. So, access was not granted that way, meaning you musthave 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 youhave nested shares, and mount the parent share as you did here, it's the parent share's ACL that getsenforced; 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 sharesthat utilize different export polices unless you also utilize other compensating access controls, such asfile system ACLs.

34. In the left pane of Remote Desktop Manager, select Datausers. The right pane will once again showthumbnails 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.


34 35

36

Figure 3-26:

3.10 SMB Signing and SMBv3 Encryption

SVMs in your ONTAP 9 cluster, that are offering CIFS (SMBv3) data services, can be configured so that data flowbetween the CIFS server and Windows clients mounting the CIFS shares will be encrypted. This helps to ensurethat the communications remain confidential. You can configure the encryption requirement at either the SVMlevel (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 individualCIFS 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.

3.10.1 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 dataservices.

• Open a session to the Win2k12R2 client as “Administrator” and examine the SMB ConnectionProperties 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 pre-

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

cluster1::> vserver cifs security show -vserver cifs_svm -instance

Vserver: cifs_svm

Kerberos Clock Skew: 5 minutes Kerberos Ticket Age: 10 hours Kerberos Renewal Age: 7 days Kerberos KDC Timeout: 3 seconds


Is Signing Required: true Is Password Complexity Required: true Use start_tls For AD LDAP connection: false Is AES Encryption Enabled: true LM Compatibility Level: lm-ntlm-ntlmv2-krb Is SMB Encryption Required: false Client Session Security: none SMB1 Enabled for DC Connections: system-default SMB2 Enabled for DC Connections: system-defaultcluster1::>

2. On the desktop of Jumphost, double-click the shortcut named WIN2K12R2 to launch the RemoteDesktop 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.


3

4

Figure 3-28:

Remote Desktop Connection Manager initiates an RDP session to the host WIN2K12R2, and eventuallydisplays 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.


5

6

7

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 : DefaultContinuouslyAvailable : FalseCredential : DEMO.NETAPP.COM\AdministratorDialect : 3.00Encrypted : FalseNumOpens : 1Redirected : FalseServerName : CIFSShareName : cifsdv1UserName : DEMO\AdministratorPSComputerName :CimClass : ROOT/Microsoft/Windows/SMB:MSFT_SmbConnectionCimInstanceProperties : {ContinuouslyAvailable, Credential, Dialect, Encrypted...}CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties

SmbInstance : DefaultContinuouslyAvailable : FalseCredential : DEMO.NETAPP.COM\AdministratorDialect : 3.00Encrypted : FalseNumOpens : 1Redirected : FalseServerName : CIFSShareName : cifsdv2UserName : DEMO\AdministratorPSComputerName :CimClass : ROOT/Microsoft/Windows/SMB:MSFT_SmbConnectionCimInstanceProperties : {ContinuouslyAvailable, Credential,Dialect, Encrypted...}CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties

SmbInstance : DefaultContinuouslyAvailable : False


Credential : DEMO.NETAPP.COM\AdministratorDialect : 3.00Encrypted : FalseNumOpens : 1Redirected : FalseServerName : CIFSShareName : test_folderUserName : DEMO\AdministratorPSComputerName :CimClass : ROOT/Microsoft/Windows/SMB:MSFT_SmbConnectionCimInstanceProperties : {ContinuouslyAvailable, Credential, Dialect, Encrypted...}CimSystemProperties : 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 themapped share sessions is encrypted.

9. In the PuTTY session for cluster1, display the CIFS session information for the DEMO\Administratoruser.

cluster1::> vserver cifs session show -vserver cifs_svm -windows-user “DEMO\Administrator” -instance

Vserver: cifs_svm

Node: cluster1-01 Session ID: 12342959203738976290 Connection ID: 4162662167 Incoming Data LIF IP Address: 192.168.0.131 Workstation IP Address: 192.168.0.41 Authentication Mechanism: Kerberos User Authenticated as: domain-user Windows User: DEMO\Administrator UNIX User: root Open Shares: 3 Open Files: 3 Open Other: 0 Connected Time: 7m 11s Idle Time: 1m 49s Protocol Version: SMB3 Continuously Available: Yes Is Session Signed: true NetBIOS Name: CIFS SMB Encryption Status: unencrypted Connection Count: 1 cluster1::>

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, andselect Log off server from the context menu.


10

Figure 3-30:

Remote Desktop Connection Manager logs out the DEMO\Administrator account's RDP session toWIN2K12R2, but Remote Desktop Connection Manager remains open.

11. In the PuTTY session for cluster1, enable SMBv3 encryption on the SVM cifs_svm.

cluster1::> vserver cifs security modify -vserver cifs_svm -is-smb-encryption-required true

cluster1::>

12. Once again examine the CIFS server security settings for the SVM cifs_svm.

cluster1::> vserver cifs security show -vserver cifs_svm -instance

Vserver: cifs_svm

Kerberos Clock Skew: 5 minutes Kerberos Ticket Age: 10 hours Kerberos Renewal Age: 7 days Kerberos KDC Timeout: 3 seconds Is Signing Required: true Is Password Complexity Required: true Use start_tls For AD LDAP connection: false Is AES Encryption Enabled: true LM Compatibility Level: lm-ntlm-ntlmv2-krb Is SMB Encryption Required: true Client Session Security: none

cluster1::>

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.


13

Figure 3-31:

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

14

15

16

Figure 3-32:


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 : DefaultContinuouslyAvailable : FalseCredential : DEMO.NETAPP.COM\AdministratorDialect : 3.00Encrypted : TrueNumOpens : 1Redirected : FalseServerName : CIFSShareName : cifsdv1UserName : DEMO\AdministratorPSComputerName :CimClass : ROOT/Microsoft/Windows/SMB:MSFT_SmbConnectionCimInstanceProperties : {ContinuouslyAvailable, Credential, Dialect, Encrypted...}CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties

SmbInstance : DefaultContinuouslyAvailable : FalseCredential : DEMO.NETAPP.COM\AdministratorDialect : 3.00Encrypted : TrueNumOpens : 1Redirected : FalseServerName : CIFSShareName : cifsdv2UserName : DEMO\AdministratorPSComputerName :CimClass : ROOT/Microsoft/Windows/SMB:MSFT_SmbConnectionCimInstanceProperties : {ContinuouslyAvailable, Credential, Dialect, Encrypted...}CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties

SmbInstance : DefaultContinuouslyAvailable : FalseCredential : DEMO.NETAPP.COM\AdministratorDialect : 3.00Encrypted : TrueNumOpens : 1Redirected : FalseServerName : CIFSShareName : test_folderUserName : DEMO\AdministratorPSComputerName :CimClass : ROOT/Microsoft/Windows/SMB:MSFT_SmbConnectionCimInstanceProperties : {ContinuouslyAvailable, Credential, Dialect, Encrypted...}CimSystemProperties : 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.

cluster1::> vserver cifs session show -vserver cifs_svm -windows-user “DEMO\Administrator” -instance

Vserver: cifs_svm

Node: cluster1-01 Session ID: 12342959203738976292 Connection ID: 4162662173 Incoming Data LIF IP Address: 192.168.0.131 Workstation IP Address: 192.168.0.41 Authentication Mechanism: Kerberos User Authenticated as: domain-user Windows User: DEMO\Administrator UNIX User: root Open Shares: 3 Open Files: 2 Open Other: 0 Connected Time: 6m 16s Idle Time: 6m 1s Protocol Version: SMB3 Continuously Available: Yes Is Session Signed: false


NetBIOS Name: CIFS SMB Encryption Status: encrypted Connection Count: 1

cluster1::>

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.

19

20

Figure 3-33:

The Remote Desktop Manager Window closes.

3.11 Configure NetApp Volume EncryptionNetApp Volume Encryption (NVE) is a software-based, data-at-rest encryption solution available starting withNetApp ONTAP® 9.1. NVE allows ONTAP to encrypt data (using AES-256 bit encryption) per volume forgranularity, without requiring self-encrypting drives. The encryption key is only accessible from the storagesystem, so data cannot be recovered from the device from any other system. This provides protection of yourvaluable data in the event that the device is redeployed to another system, lost, stolen, or returned to NetApp forreplacement. 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.

3.11.1 Exercise

In this exercise you will perform the following activities:


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

cluster1::> system license show

Serial Number: 1-80-000054Owner: cluster1Package Type Description Expiration----------------- -------- --------------------- -------------------Base license Cluster Base License -

Serial Number: 1-81-0000000000000000000000070Owner: cluster1-01Package 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.

cluster1::>

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 256characters long. For this lab exercise we recommend you use the passphrase“hardening_netapp_ontap_lab_nve_exercise”.

cluster1::> security key-manager setupWelcome 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 default or omit a question, do not enter a value. Would you like to configure onboard key management? {yes, no} [yes]: yesEnter the cluster-wide passphrase for onboard key management. To continue the configuration, enter the passphrase, otherwisetype "exit": hardening_netapp_ontap_lab_nve_exerciseRe-enter the cluster-wide passphrase: hardening_netapp_ontap_lab_nve_exerciseAfter configuring onboard key management, save the encrypted configuration datain a safe location so that you can use it if you need to perform a manual recoveryoperation. To view the data, use the “security key-manager backup show” command.

cluster1::>

For a production deployment you should record your passphrase in a secure location outside the storagesystem for future use.

All key management information is automatically backed up to the ONTAP replicated database (RDB) forthe cluster, but you should also save a copy outside the cluster in case of disaster.


3. Back up the key manually for use in the event of disaster recovery..

cluster1::> security key-manager backup show--------------------------BEGIN BACKUP--------------------------TmV0QXBwIEtleSBCbG9iAAEAAAAEAAAAcAEAAAAAAAA46banAAAAACEAAAAAAAAAQAAAAAAAAAAMRHgZAAAAAK1uvne73mJTKCfnPgGeuqleZ/NuqHj07h6sKN0DIpJM1dwsFzKyTW4VT+mjG4Nr6tebM/CzHt7i2Dm1ibDVkJQiAAAAAAAAACgAAAAAAAAA3WTh7gAAAAAAAAAAAAAAAAIAAAAAAAgAZJEIWvdeHr5RCAvHGclo+wAAAAAAAAAAIgAAAAAAAAAoAAAAAAAAAEOTcR0AAAAAAAAAAAAAAAACAAAAAAAJAGr3tJA/LRzUQRHwv+1aWvAAAAAAAAAAACQAAAAAAAAAgAAAAAAAAACMuT+cAAAAAIHMxUELFsaMwNoYX2RzYLrqf1+ve9vxTP75h8pZtRsoDZn8ArEx8rwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABOZXRBcHAgS2V5IEJsb2IAAQAAAAMAAAAYAQAAAAAAAPZ70gQAAAAAIgAAAAAAAAAoAAAAAAAAAEOTcR0AAAAAAAAAAAAAAAACAAAAAAAJAGr3tJA/LRzUQRHwv+1aWvAAAAAAAAAAACIAAAAAAAAAKAAAAAAAAAA5NPttAAAAAAAAAAAAAAAAAgAAAAAAAQCa2JUrbjkFNiRtj/UfVMDyAAAAAAAAAAAkAAAAAAAAAIAAAAAAAAAA8KewEwAAAADMupZXSe/Ti2lYyeatBlKaZajjCJbI85jVEblCQw/5xrQ38Wl90tHfAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE5ldEFwcCBLZXkgQmxvYgABAAAAAwAAABgBAAAAAAAAEQD3rgAAAAAiAAAAAAAAACgAAAAAAAAAQ5NxHQAAAAAAAAAAAAAAAAIAAAAAAAkAave0kD8tHNRBEfC/7Vpa8AAAAAAAAAAAIgAAAAAAAAAoAAAAAAAAAICiZ1wAAAAAAAAAAAAAAAACAAAAAAABANe0Gq7uZQWiBN/NJSND/4MAAAAAAAAAACQAAAAAAAAAgAAAAAAAAABVfla0AAAAADbNIgER0Jxq22OT5ckR+hJey+xoH9s2F+ae7Yblgl91LdQM75NRmMsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA---------------------------END BACKUP---------------------------

cluster1::>

In a production environment you should copy and paste this information into a file that resides outsidethe cluster. As with any private key, you would want to store that file in a highly secure location to protectagainst unauthorized access, theft, or data loss.

4. Create a new volume named “nve”, and enable volume encryption on it.

cluster1::> cluster1::> volume create -vserver cifs_svm -volume nve -aggregate aggr_data1 -encrypt true -size 1g[Job 475] Job succeeded: Successfulcluster1::>

The Onboard Key Manager creates an encryption key for the volume. Any data you put on the volume isencrypted.

5. Verify that the volume is enabled for encryption.

cluster1::> volume show -is-encrypted trueVserver Volume Aggregate State Type Size Available Used%--------- ------------ ------------ ---------- ---- ---------- ---------- -----cifs_svm nve aggr_data1 online RW 1GB 972.6MB 5%

cluster1::>

You can also enable NVE on a volume that was initially created without encryption. This requiresperforming a volume move operation on the volume, and selecting to encrypt the volume at the movedestination.

6. Create a unencrypted volume (i.e., a regular volume).

cluster1::> volume create -vserver cifs_svm -volume nve2 -aggregate aggr_data2 -size 1g[Job 476] Job succeeded: Successful

cluster1::>


7. Verify that the new nve2 volume is not encrypted by querying ONTAP for the list of volumes that areencrypted.

cluster1::> volume show -is-encrypted trueVserver Volume Aggregate State Type Size Available Used%--------- ------------ ------------ ---------- ---- ---------- ---------- -----cifs_svm nve aggr_data1 online RW 1GB 972.6MB 5%

cluster1::>

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.

cluster1::> 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.

cluster1::>

9. Monitor the status of the move operation until it is complete.

cluster1::> volume move show -vserver cifs_svm -volume nve2

Vserver Name: cifs_svm Volume Name: nve2 Actual Completion Time: Wed Sep 06 21:30:10 2017 Bytes Remaining: - Destination Aggregate: aggr_data1 Detailed Status: Successful Estimated Time of Completion: - Managing Node: cluster1-01 Percentage Complete: 100% Move Phase: completed Estimated Remaining Duration: - Replication Throughput: - Duration of Move: 00:00:14 Source Aggregate: aggr_data2 Start Time of Move: Wed Sep 06 21:29:56 2017 Move State: done Is Source Volume Encrypted: false Encryption Key ID of Source Volume: - Is Destination Volume Encrypted: trueEncryption Key ID of Destination Volume: -

cluster1::>

The move operation should complete quite rapidly given that the volume is small and empty, but if youissue the vol move show command very quickly then it might be necessary to run this command morethan once before it finally reports that the move has completed. Note that the “Is Destination VolumeEncrypted” 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.

cluster1::> volume show -is-encrypted trueVserver Volume Aggregate State Type Size Available Used%--------- ------------ ------------ ---------- ---- ---------- ---------- -----cifs_svm nve aggr_data1 online RW 1GB 972.6MB 5%cifs_svm nve2 aggr_data1 online RW 1GB 972.5MB 5%2 entries were displayed.

cluster1::>

The nve2 volume is now listed in the output.

3.12 Review Syslog Events

In this section, you connect to the Host that functions as the external syslog server for this lab environment. Onceconnected, you will navigate to the directory or directories where the log files for the ONTAP 9 cluster are stored.


Examine the contents of these log files to see an audit record of everything you did during your activities in thislab.

The rsyslog daemon running on the syslog server utilizes a custom configuration designed to filter your CLIactivities into a separate log file to make them easier to find and understand. You may find a directory named forthe ONTAP 9 cluster in general (cluster1), and may also find a directory named for each member node (in thiscase cluster1-01, as this is a single node cluster). Of particular interest are log files within those directories withnames beginning with “command-history”.

3.12.1 Exercise

This exercise shows you where to locate and view auditing log files for your ONTAP 9 cluster. You may see somevariance from the examples shown here in your lab depending on what specific activities you performed in thelab.

1. On the desktop of Jumphost, right-click the PuTTY icon on the task bar, and select syslog from the listof 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


total 144-rw------- 1 root root 68023 Aug 17 05:42 command-history-audit.log-rw------- 1 root root 68023 Aug 17 05:42 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 systemgenerated commands. This includes commands entered through the ONTAP 9 CLI, as wellas management activities initiated through NetApp's Zephyr API (ZAPI). OnCommand SystemManager and the ONTAP 9 PowerShell Toolkit utilize ZAPI, so management activities initiatedthrough 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 easilyview the CLI commands you entered in this lab. If you made configuration changes throughtools that use ZAPI, like System Manager, then this file would contain some record of thoseactivities too, although you would need to refer to the syslog.log file to view some additionalcontext 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.logAug 16 04:46:20 cluster1 cluster1-01: cluster1-01: 00000020.00000d5f 0000856c Tue Aug 16 2016 04:46:19 +00:00 [kern_audit:info:1979] 8003e800000006b7:8003e8000000077b :: cluster1:ssh :: 192.168.0.61:48976 :: cluster1:admin :: cluster log-forwarding create -destination 192.168.0.63 -port 514 -facility user :: SuccessAug 16 04:46:43 cluster1 cluster1-01: cluster1-01: 00000020.00000d62 00008651 Tue Aug 16 2016 04:46:42 +00:00 [kern_audit:info:1979] 8003e800000006b7:8003e8000000077d :: cluster1:ssh :: 192.168.0.61:48976 :: cluster1:admin :: exit :: PendingAug 16 04:46:43 cluster1 cluster1-01: cluster1-01: 00000020.00000d63 00008651 Tue Aug 16 2016 04:46:42 +00:00 [kern_audit:info:1979] 8003e800000006b7:8003e8000000077d :: cluster1:ssh :: 192.168.0.61:48976 :: cluster1:admin :: exit :: SuccessAug 16 04:46:43 cluster1 cluster1-01: cluster1-01: 00000020.00000d64 00008651 Tue Aug 16 2016 04:46:42 +00:00 [kern_audit:info:1979] 8003e800000006b7:8003e8000000077e :: cluster1:ssh :: 192.168.0.61:48976 :: cluster1:admin :: Logging outAug 16 05:03:36 cluster1 cluster1-01: cluster1-01: 00000020.00000da6 0000ade2 Tue Aug 16 2016 05:03:35 +00:00 [kern_audit:info:1979] 0000000000000000 :: cluster1:ssh :: 192.168.0.61:48978 :: cluster1:admin :: Authentication failed.Aug 16 05:03:44 cluster1 cluster1-01: cluster1-01: 00000020.00000dab 0000ae2d Tue Aug 16 2016 05:03:43 +00:00 [kern_audit:info:1979] 8003e80000000966:8003e80000000967 :: cluster1:ssh :: 192.168.0.61:48978 :: cluster1:admin :: Logging inAug 16 05:04:21 cluster1 cluster1-01: cluster1-01: 00000020.00000dad 0000afa1 Tue Aug 16 2016 05:04:20 +00:00 [kern_audit:info:1979] 8003e80000000966:8003e80000000978 :: cluster1:ssh :: 192.168.0.61:48978 :: cluster1:admin :: security login role create -role stats -cmddirname DEFAULT -access none :: Pending--More--(2%)[root@syslog cluster1-01-logs]#

The more command displays the file contents one screen at a time. You can page forward using thespace 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.

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


• The second field contains information about the vector used to enter the command. Thestring “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 aconfiguration change through System Manager.

• The third field is the IP address of the client host that initiated the activity. In this lab192.168.0.5 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 ONTAPcommand. In the case of an ontapi entry, this field contains some indication of theconfiguration activity, but you would need additional context from surrounding entries, andprobably 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 inprogress, “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 mannerused in this lab, this exercise does not explicitly cover that material, but you are welcome to review theconfiguration on your own. That configuration is managed through the /etc/rsyslog.conf file on the Linuxhost 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://www.rsyslog.com/doc/troubleshoot.html

#### 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 default timestamp format$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# File syncing capability is disabled by default. 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 sourceif $fromhost-ip != '127.0.0.1' then ?FILENAME# Filter out non-interactive command history messagesif $fromhost-ip != '127.0.0.1' and $msg contains 'console :: console :: root ::' and $syslogfacility-text == 'user' then ~


if $fromhost-ip != '127.0.0.1' and $syslogfacility-text == 'user' and $msg contains '[kern_audit:info:' then ?FILENAME2# If message is external, then we are done. Suppress from further processing.:fromhost-ip, !isequal, "127.0.0.1" ~

#################################################################################### 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 stuffcron.* /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.loglocal7.* /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/ip:port, e.g. 192.168.0.1:514, port optional#*.* @@remote-host:514# ### end of the forwarding rule ###

# A template for higher precision timestamps + severity logging$template SpiceTmpl,"%TIMESTAMP%.%TIMESTAMP:::date-subseconds% %syslogtag% %syslogseverity-text%:%msg:::sp-if-no-1st-sp%%msg:::drop-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.


4 ReferencesWe used the following references to write this lab guide. All guides related to Clustered Data ONTAP are specificto the version used in this lab.

Table 19: Table: Lab References

Guide Title Publish Date NetApp P/N

ONTAP 9.0 System Administration Reference June 2016 215-11148_AO

ONTAP 9.0 Commands: Manual Page Reference June 2016 215-11145_AO

ONTAP 9.0 CIFS and NFS Multiprotocol Configuration Express Guide

ONTAP 9.0 CIFS Reference

June 2016

June 2016

215-11171_A0

215-11156_A0

ONTAP 9.0 NFS Configuration Express Guide

ONTAP 9.0 NFS Reference

June 2016

June 2016

215-11172_A0

215-11157_A0

ONTAP 9.0 Network Management Guide June 2016 215-11141_A0


5 Version History

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

Refer to the Interoperability Matrix Tool (IMT) on the NetApp Support site to validate that the exactproduct 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 constructconfigurations that are supported by NetApp. Specific results depend on each customer's installation inaccordance with published specifications.

NetApp provides no representations or warranties regarding the accuracy, reliability, or serviceability of anyinformation or recommendations provided in this publication, or with respect to any results that may be obtainedby the use of the information or observance of any recommendations provided herein. The information in thisdocument is distributed AS IS, and the use of this information or the implementation of any recommendations ortechniques herein is a customer’s responsibility and depends on the customer’s ability to evaluate and integratethem into the customer’s operational environment. This document and the information contained herein may beused 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 consentof 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 registeredtrademarks of NetApp, Inc. in the United States and/or other countries. All other brands or products are trademarks orregistered trademarks of their respective holders and should be treated as such.

http://support.netapp.com/matrix/mtx/login.do

Documents

Hardening NetApp ONTAP - hol. · PDF fileHardening NetApp ONTAP 7 © 2017 NetApp, Inc. All rights reserved. NetApp Proprietary Table 4: User IDs and Passwords User User Type Username