Securing Clustered Data ONTAP - NetApp | NetApp … · 2 Securing Clustered Data ONTAP © 2015...

Securing Clustered Data ONTAP

December 2015 | SL10250 Version 1.0

2 Securing Clustered Data ONTAP © 2015 NetApp, Inc. All rights reserved. NetApp Proprietary

TABLE OF CONTENTS

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

1.1 Basic Clustered Data ONTAP 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.................................................................................................................. 21

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

3.8 NFS/CIFS Export Policies....................................................................................................... 25

3.8.1 CIFS Exercise.....................................................................................................................................................26

3.8.2 NFS Exercise......................................................................................................................................................35

3.9 NFS and SMB (CIFS) ACLs.................................................................................................... 40

3.9.1 Exercise.............................................................................................................................................................. 41


3.10 Review Syslog Events.......................................................................................................... 53

3.10.1 Exercise............................................................................................................................................................ 54

4 References......................................................................................................................................57

5 Version History.............................................................................................................................. 58


1 IntroductionThis lab introduces several basic techniques for Securing Clustered Data ONTAP® version 8.3.1. This labutilizes, as its starting point, an environment that contains a virtualized, single node Data ONTAP cluster, andseveral virtualized servers that allow you to perform and verify some simple steps in securing your data storageenvironment.

This lab is not intended to be an all-encompassing best practices guide for securing clustered Data ONTAP; thereis no “one size fits all” security configuration that is ideal for every situation. Rather, this lab introduces many ofthe security features available to you in clustered Data ONTAP so that you can learn how they work. With thisknowledge you can then decide if and how to best apply those features to meet the unique security needs of yourown environment.

1.1 Basic Clustered Data ONTAP Security Practices

These days system administrator and end-users alike are justifiibly 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 Clustered Data ONTAP, there are two (2) major areas for security focus. These are:

• Administrative access for management of the Data ONTAP 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 connectingto the Data ONTAP cluster (or a hosted SVM) using the Secure Shell (SSH) protocol. This is just one of severalaccess methods 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 (which should not 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 a clustered Data ONTAP system. You willspecifically learn how to:

• Configure cluster command logging to an external syslog server.• Create custom roles for administrative accounts.• Configure firewall to protect cluster services.• Restrict cluster SSH access to more secure encryption.• Configure CLI session timeouts.• Restrict cluster core web services.• Create and test CIFS and NFS export policies.• Create SMB (CIFS) shares ACLs.• Review command histrory captured by syslog.

1.3 PrerequisitesThis lab assumes that you are familiar with the basic concepts of administering clustered Data ONTAP 8.3. Thislab makes extensive use of the clustered Data ONTAP comand line interface (CLI) because OnCommand SystemManager, NetApp's graphical administration tool, does not support the features necessary to complete many ofthe exercises you will be performing.

Experience with the clustered Data ONTAP CLI is helpful but not required. The instructions are designed to allowa novice to complete 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 2012R2 Remote Access Host 192.168.0.5 DEMO\Administrator Netapp1!

RHEL1 Red Hat 6.6 x64 Linux Host 192.168.061 root Netapp1!

RHEL2 Red Hat 6.6 x64 Linux Host 192.168.0.62 root Netapp1!

SYSLOG Red Hat 6.6 x64 Linux Syslog Server 192.168.0.63 root Netapp1!

WIN2K12R2 Windows 2012R2 Server 192.168.0.41 DEMO\Administrator Netapp1!

DC1 Active DIrectory and DNS Server 192.168.0.253 DEMO\Administrator Netapp1!

CLUSTER1 Data ONTAP 8.3.1 cluster 192.168.0.101 admin Netapp1!

CLUSTER1-01 Data 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!


User User Type Username or UID GroupMembership orGID

Login Password

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 21• NFS/CIFS Export Policies on page 25• NFS and SMB (CIFS) ACLs on page 40• Review Syslog Events on page 53

3.1 Lab Preparation

You need to establish a terminal session to cluster1 in order to complete the exercises in this lab.

1. On the desktop of 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.


2

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 clustered Data ONTAP CLI, the length of the commands can seem a little initimidating.However, the commands are actually quite easy to use if you remember the following 3 tips:

• Make liberal use of the Tab key while entering commands, as the clustered Data ONTAP commandshell supports tab completion. If you hit the Tab key while entering a portion of a command word,the command shell will examine the context and try to complete the rest of the word for you. If thereis insufficient context to make a single match, it will display a list of all the potential matches. Tabcompletion also usually works with command argument values, but there are some cases where thereis simply not enough context for it to know what you want, in which case you will just need to type in theargument 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 Data ONTAP CLI, the “Advanced Concepts for ClusteredData ONTAP 8.3.1” 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 use copy/paste of commands from the guide to the lab, when dealing with multi-linecommands you can only copy one line at a time. If you try to copy multiple lines at once then thecommands will fail in the lab.

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

In this section, you will configure Clustered Data ONTAP to forward cluster and member node events to anexternal syslog server. New to Clustered Data ONTAP 8.3.1 is the ability to also forward the command history logfile entries to a designated syslog server. This works for commands entered through the clustered Data ONTAPCLI as well as through the NetApp Zephyr API (ZAPI), which means that management activities performedthrough System Manager, the NetApp PowerShell Toolkit, and the NetApp Management Software DevelopmentKit (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've configured remote syslog destination/routing for both the Event Management System (EMS) and thecommand history log entries, any clustered Data ONTAP configuration activities you perform in other sections ofthis lab will get logged to syslog. At the end of the lab you will revisit the syslog server to review those capturedlogs.

3.2.1 Exercise

1. In the PuTTY window for cluster1, display a list of the existing event destinations. An event destination isa list of addresses that receive event notifications.

cluster1::> event destination show HideName Mail Dest. SNMP Dest. Syslog Dest. Params---------------- ----------------- ------------------ ------------------ ------allevents - - - falseasup - - - falsecriticals - - - falsepager - - - falsetraphost - - - false5 entries were displayed.

cluster1::>

Observe that there is no syslog destination listed for “allevents”.2. Modify the “allevents” destination to use the syslog server at 192.168.0.63, which corresponds to

syslog.demo.netapp.com.

cluster1::> event destination modify -name allevents -syslog 192.168.0.63 -syslog-facility default -hide-parameters false

cluster1::>

3. Display the updated list of event destinations.

cluster1::> event destination show HideName Mail Dest. SNMP Dest. Syslog Dest. Params---------------- ----------------- ------------------ ------------------ ------allevents - - syslog.demo.netapp.com


falseasup - - - falsecriticals - - - falsepager - - - falsetraphost - - - false5 entries were displayed.

cluster1::>

4. Add the “allevents” destination to all the defined types of events.

cluster1::> event route add-destination -messagename * -destinations allevents7873 entries were acted on.

cluster1::>

5. Display a list of the log forwarding destinations.

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

cluster1::>

Note that there are no defined destinations.6. Create the syslog server as a new forwarding destination.

cluster1::> cluster log-forwarding create -destination 192.168.0.63 -port 514 -facility user

cluster1::>

7. Display the updated list of log forwarding destinations.

cluster1::> cluster log-forwarding show

SyslogDestination Host Port Facility------------------------- ------ --------192.168.0.63 514 user

cluster1::>

Both EMS Events and Command-history records are now forwarded to the designated syslog server. Towards theend of the lab exercise 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 they can be used 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 account haswhen you login to Data ONTAP. These capabilities dictate what you can access, what you can see, and mostimportantly, what you can change.

Clustered Data ONTAP includes several pre-defined roles that are used for managing account access to thecluster 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

autosupport vsadmin-backup

backup vsadmin-protocol


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

none vsadmin-readonly

readonly vsadmin-volume

Roles also control clusterd Data ONTAP user account name and password policies via role atrributes that youspecify as command line parameters. You can see the details of these policy attributes in the following table:

Table 6: Table: Role Configuration Attributes Useful for Implementing Password and Login 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, you utilize 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 role that is to be created.

-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, andall. The default setting is all.


Parameter Description

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

For this exercise, you will create a custom role called “stats”, and create a user account called “stat_acct” thatwill be assigned the “stats” role. You will then login to that user account and see which access capabilities areallowed for this user.

3.3.1 Exercise

1. In the PuTTY window for cluster1, create a new role named “stats” that initially has no access to any ofthe adminitrative 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 nonecluster1 stats security login whoami allcluster1 stats 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 back in access 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: enabledMinimum Number of Special Characters Required In The Password: 0 Password Expires In (Days): unlimitedRequire 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

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 wanted to modify then then you could use the security login roleconfig modify command along with the attributes from the table to accomplish that task.

6. Create a new user account named stat_acct on cluster1 and assign it to the “stats” role. 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': Please enter it again:

cluster1::>

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

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 dashboard> (DEPRECATED)-Display dashboards event> Manage system events exit Quit the CLI session export-policy Manage export policies and rules 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 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.

8. Open a new PuTTY session. (Don't 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 anda 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 Cluster Data ONTAP’s network interfaces. The firewalls are services running on eachnode in the cluster that determine which network traffic is allowed or disallowed for each specific node’s networkports, 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 Clustered Data ONTAP. These policies cannot be removed, howevercluster administrators can define new policies to use instead of the predfined policies. The network protocolservices that 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

rsh Remote Shell (highly discouraged and notrecommended)

snmp Simple Network Management Protocol

ssh Secure Shell

telnet Telnet Protocol (highly discouraged and notrecommended)

The next table the default comfiguration 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 specifying which network protocol service to allow, and a list of thevalid IP networks and IP addresses that are allowed to access that network service. The absence of a particularnetwork protocol service entry prevents any access using that protocol over the network interfaces relying on thatfirewall 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 Systerm 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.

For this exercise, you will:


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

3.4.1 Exercise

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. Display a listing of 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/0Vserver Policy Service Allowed------- ------------ ---------- -------------------cluster1 mgmt 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

For administrative management connections to Clustered Data ONTAP, the Secure Shell (SSH) protocol isfrequently used. The effectiveness of maintaining a secured network connection is very dependent on which key-exchange algorithms and encryption ciphers are used. The basic SSH protocol supports a number of differentalgorithms and ciphers, some more secure than others. SSH services in Clustered Data ONTAP support four (4)different key-exchange algorithms, and seven (7) different ciphers. These are listed in the following table orderedfrom most secure to least.

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

Encryption Ciphers Key-Exchange Algorithms

aes256-ctr diffie-hellman-group-exchange-sha256

aes192-ctr diffie-hellman-group-exchange-sha1

aes128-ctr diffie-hellman-group14-sha1

aes256-cbc diffie-hellman-group1-sha1

aes192-cbc

aes128-cbc

3des-cbc

By restricting the available ciphers and algorithms, administrators can force the use of more secure SSH clientswhen connecting to the Data ONTAP cluster, or SVM management network interfaces. Using algorithms andciphers with larger key lengths will also help deter “man-in-the-middle” eaves-dropping on SSH connections,and possible disclosure of critical login credentials. Data ONTAP maintains a configuration for the clusteradministration SVM and each other SVM allowing SSH access.

Configuration of which SSH key-exchange algorithms and encryption ciphers are to be allowed is accomplishedby commands found in the security ssh commands sub-directory.

For this exercise, you will list the current SSH configurations, and then modify the cluster’s SSH configuration toonly include the three (3) most secure encryption ciphers, and the two (2) most secure key-exchange algorithms.


3.5.1 Exercise

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

cluster1::> security ssh showVserver Ciphers Key Exchange Algorithms--------------- ---------------- --------------------------------------------cifs_svm aes256-ctr, diffie-hellman-group-exchange-sha256, aes192-ctr, diffie-hellman-group-exchange-sha1, aes128-ctr, diffie-hellman-group14-sha1, aes256-cbc, diffie-hellman-group1-sha1 aes192-cbc, aes128-cbc, 3des-cbccluster1 aes256-ctr, diffie-hellman-group-exchange-sha256, aes192-ctr, diffie-hellman-group-exchange-sha1, aes128-ctr, diffie-hellman-group14-sha1, aes256-cbc, diffie-hellman-group1-sha1 aes192-cbc, aes128-cbc, 3des-cbcnfs_svm aes256-ctr, diffie-hellman-group-exchange-sha256, aes192-ctr, diffie-hellman-group-exchange-sha1, aes128-ctr, diffie-hellman-group14-sha1, aes256-cbc, diffie-hellman-group1-sha1 aes192-cbc, aes128-cbc, 3des-cbc3 entries were displayed.

cluster1::>

Observe that there are independent ssh configuration settings for each SVM.2. Refine the SSH configuration for cluster1 so it only accepts the more secure algorithms.

cluster1::> security ssh modify -vserver cluster1 -key-exchange-algorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1 -ciphers aes256-ctr,aes192-ctr,aes128-ctr

cluster1::>

Note: Modifications to the cluster SSH configuration become the default for any newly createdSVMs that enable SSH management access. Pre-existing SVMs retain their previous SSHconfiguration.

3. View the cluster's SSH configuration again.

cluster1::> security ssh showVserver Ciphers Key Exchange Algorithms--------------- ---------------- --------------------------------------------cifs_svm aes256-ctr, diffie-hellman-group-exchange-sha256, aes192-ctr, diffie-hellman-group-exchange-sha1, aes128-ctr, diffie-hellman-group14-sha1, aes256-cbc, diffie-hellman-group1-sha1 aes192-cbc, aes128-cbc, 3des-cbccluster1 aes256-ctr, diffie-hellman-group-exchange-sha256, aes192-ctr, diffie-hellman-group-exchange-sha1 aes128-ctrnfs_svm aes256-ctr, diffie-hellman-group-exchange-sha256, aes192-ctr, diffie-hellman-group-exchange-sha1, aes128-ctr, diffie-hellman-group14-sha1, aes256-cbc, diffie-hellman-group1-sha1 aes192-cbc, aes128-cbc, 3des-cbc3 entries were displayed.

cluster1::>

Cluster1 now only accepts a more restrictive set of cipher and key-exchange algorthims, but other SVMsstill retains their previous SSH configuration.


3.6 Configure CLI Session Timeouts

As 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 system and Data ONTAP storage clusters.On other occasions, they may be called away from their workstations in order to deal with some other situations.Leaving an unattended, open connection to a critical resource can pose a serious security risk, as a passer-bymay see or have access to something which they are not authorized.

To help minimize this risk, Clustered Data ONTAP allows you to configure an “inactivity” timeout feature for CLItype sessions. Since there is no “session-lock” feature in ONTAP, any logged in session that is idle for more thanthe “inactivity” time limit will be terminated.

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

3.6.1 Exercise

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.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 showCLI 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 Clustered Data ONTAP require the existence of certain core “web” servicesrunning on cluster member nodes. The management features might include the following:

• Web Browser access to the “on-board” OnCommand System Manager GUI• Access by other OnCommand products to the built-in Data ONTAP “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 will actually determine which web protocols (HTTP, HTTPS, or both) arevisible on a management interface.

Note: To enable HTTPS access only, use a custom firewall policy which excludes HTTP as a protocol.


The HTTPS service supports the following SSL (Secure Socket Layer) capabilities:

• TLSv1 (Transport Layer Security version 1) which is enabled by default and cannot be turned off.• SSLv3 (Secure Socket Layer version 3) which is enabled 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 will bedetermined by the following rules:

Table 13: Table: HTTPS Client Access Rules

SSL Setting For Access, Client Must…

SSLv3 Enabled Client has access with SSLv3 or TLSv1

SSLv3 Disabled Client has access with TLSv1 only

FIPS 140-2 Enabled Client has access with TLSv1 if FIPS 140-2 compliant

For this exercise, you will perform the following tasks:

• View the current SSL/TLS settings and status (both from a cluster and member node perspective).• Disable web services.• Try connection from a web browser.• Enable web services.• Try connection from a web browser.• Disable the use of SSLv3.• Enable FIPS 140-2 compliance.• View modified SSL/TLS settings and status.

3.7.1 Exercise

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 TLSv1 Enabled: true SSLv3 Enabled: trueSSL FIPS 140-2 Enabled: false

cluster1::>

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

cluster1::> system services web node show Total TotalNode External HTTP Port HTTPs Port Status HTTP Requests Bytes Served------------- -------- --------- ---------- -------- ------------- ------------cluster1-01 true 80 443 online 5 2728

cluster1::>

3. Disable remote client access to HTTP and HTTPS service content hosted on the cluster. This commandwill prompt you if you want to continue; respond y.

cluster1::> system services web modify -external false

Warning: Modifying the cluster configuration will cause pending web service requests to be interrupted as the web servers are restarted.Do you want to continue? {y|n}: y


cluster1::>

4. On the desktop of JUMPHOST, launch the Chrome web browser by clicking on the Chrome icon foundon the taskbar.

4

Figure 3-5:

The Chrome browser opens.5. Chrome is preconfigured to automatically connect to cluster1’s OnCommand System Manager login

page. Since you disabled web services to external clients, the browser should display a message stating“This web page is not available”. If Chrome does not display this message in your lab, place your cursorat the end of the URL and hit the Enter key to reload the page, which should correct the problem.

Figure 3-6:

6. In your PuTTY session to cluster1, re-enable web services. Once again, when prompted whether youwant to continue, respond y.

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, disable SSLv3 by enabling FIPS 140-2 compliance mode. Respond y

both times when asked if you want to continue.

cluster1::> system services web modify -ssl-fips-enabled true


Warning: SSLv3 will be disabled for FIPS compatibility.Do you want to continue? {y|n}: y

cluster1::>

9. Again, display the current availablility 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 TLSv1 Enabled: true SSLv3 Enabled: falseSSL FIPS 140-2 Enabled: true

cluster1::>

10. Also display again the the operational configuration for the web server processes on the nodes in thecluster.

cluster1::> system services web node show Total TotalNode External HTTP Port HTTPs Port Status HTTP Requests Bytes Served------------- -------- --------- ---------- -------- ------------- ------------cluster1-01 true 80 443 online 1 680


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 sufficently 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, clustered Data ONTAP automatically creates a default export policy. It isnot populated with any rules. You must explicitly add the rules required to allow client access to NAS data.

When you create a CIFS service for an SVM, by default the CIFS export policy is disabled. You can enabled theexport policy via the vserver cifs options modify command, which must be issued at the “advanced” privilegelevel. If the CIFS service option for using export policies is disabled, then CIFS shares do not require an exportpolicy to operate.

Note: You must still create CIFS shares to allow external client access to data over CIFS. Just creating anexport policy does not automatically export the data via the CIFS protocol. On the other hand, data servedthrough NFS is exported immediately after NFS centric rules are added to an applied export policy.

Export policies are simple containers which hold the rules that are used for access validation. The policy, itself,has a name and is associated with the SVM which owns it. Export policies contain zero (0) or more rules, andaccess rules must be added to an empty (0 rules) policy before any NAS data can be accessed by clients. Theserules contain the following 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:

• 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


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

This exercise consists of two (2) parts, one for CIFS export policies, and one for NFS export policies. For brevity,some customized export policies have been pre-created for the CIFS SVM. You will create customized exportpolicies for the NFS SVM and apply them to several qtrees existing in a volume owned by that SVM. In bothcases, you will use the vserver export-policy check-access command to validate that these policies will achievethe proper access requirements desired.

3.8.1 CIFS Exercise

In this exercise you will enable CIFS export policy enforcement on the SVM cifs_svm, configure three CIFS exportpolicies, and then apply them to several of the SVM's volumes as detailed in the CIFS Exercise Export Policiestable. You will also verify that these policies properly grant/deny access to two different Windows clients in thelab.

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


Volume Export Policy Rule Resulting Access

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 clustered Data ONTAP until the SVM's “is-exportpolicy-enabled”option is set to true.

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 Rulestable shown earlier in this exercise, but if you look closely, the assigned export policies don’t (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 gets created it does not contain any rules, andwithout any 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 will not explore them further here.

You will 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 denying 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 and read-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 clustered Data ONTAP CLI using the vserver export-policy check-access command.

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

In this lab, DNS is configured to use the hostname “cifs” for the IP address assigned to the SVMcifs_svm.

32. Click Finish.


32

Figure 3-10:

The “Windows Security” window opens.33. Note that the window reports “Access is denied”. Windows attempted to use your login credentials to

access the share, but was unable to because the export policy rules denied access. Windows does 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 tegardless of which credentials you enter, the access policyrules prevent you from accessing this share from JUMPHOST.

34. Click the Cancel button.


3433

Figure 3-11:

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


35

Figure 3-12:

The “Map Network Drive” window closes.

In the interest of saving time, you won't check access to the “cifsdv1” share from WIN2K12R2 host in this exercisebecause you will use that share in the next exercise. This will clearly demonstrate that the host WIN2K12R2 canaccess 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 one of the nfsdv volumes’two qtrees, as detailed in the NFS Exercise Export Policies table. You will also verify that this policy properlygrants/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

nfsdv

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 nfsdv volume, and the qt1 and qt2 qtrees have all been pre-created for you. NFS has alsobeen pre-configured for the nfs_svm to support the NFSv3, NFSv4, and NFSv4.1 protocols.

The Linux clients you configure the export policies to support are “rhel1” (IP address 192.168.0.61) and “rhel2” (IPaddress 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, clustered Data ONTAP automatically creates an empty export policynamed “default”. When you create a new volume, clustered Data ONTAP automatically assigns the“default” export policy to that volume. When you create a qtree, that qtree inherits the parent volume'sexport 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 nfsdv "" default nfs_svm nfsdv qt1 default nfs_svm nfsdv 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 nfsdv -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 nfsdv "" default nfs_svm nfsdv qt1 nfs_pol1 nfs_svm nfsdv qt2 default 4 entries were displayed.

cluster1::>

Now test the proper configuration and application of these export policies relative to the rhel1 NFSclient by using 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 nfsdv -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/nfsdv default nfsdv volume 1 read/nfsdv/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 nfsdv -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/nfsdv default nfsdv volume 1 read/nfsdv/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::>


authentication.

cluster1::> vserver export-policy check-access -vserver nfs_svm -volume nfsdv -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/nfsdv default nfsdv volume 1 read/nfsdv/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 using 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::>


authentication.

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

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 nfsdv -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/nfsdv default nfsdv volume 1 read/nfsdv/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::> vserver export-policy check-access -vserver nfs_svm -volume nfsdv -authentication-method sys -client-ip 192.168.0.62 -qtree qt1 -protocol nfs3 -access-type read-write Policy Policy Rule


Path Policy Owner Owner Type Index Access----------------------------- ---------- --------- ---------- ------ ----------/ default nfs_svm_root volume 1 read/nfsdv default nfsdv volume 1 read/nfsdv/qt1 nfs_pol1 qt1 qtree 4 denied3 entries were displayed.

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 the PuTTY to establish linuxterminal sessions to rhel1 and rhel2.

3.9 NFS and 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.

To keeping the length of this exercise manageable, this section will primarily focus on CIFS ACLs.

For 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 a SMB (CIFS) share, clustered Data ONTAP automatically creates a share level ACL forthe share. This default ACL grants full control to the Windows built-in group “Everyone”. If this default ACL doesnot provide the exact level of access control you desire, you may use System Manager or the clusterd DataONTAP CLI to modify and/or delete the default ACL, and add in new ACLs as appropriate to 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 shoulddo so with caution however, as ii is possible to modify the ACLs such that the client will no longer haveaccess to the share, in which case you will have to resort to using System Manager or the clustered DataONTAP CLI to recover.

The base CLI command for managing share-level ACLs is vserver cifs share access-control, and it has thefollowing subcommands.

• create

• modify

• delete

• show

When you issue the create, modify, and delete commands, you will specify the vserver hosting the share, theshare name, the user or group to which the ACL pertains, the type of user or group (windows, Unix-user, Unixgroup), 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.


Permission Type Description

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.

NFSv4 ACLs (both v4.0 and v4.1) are actually created from the client, but the clustered Data ONTAP vserver nfsmodify command includes options that allow you to control whether NFSv4 options are enabled or disabled at thevserver level.

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 clustered Data ONTAP command line interface (CLI) also provides the vserver security file-directorycommands for managing directory and file level access control lists. Using these commands to manipulate ACLsrequires a deeper understanding of how Microsoft implements security descriptors, ACLs, and Access ControlEntries (ACE), a discussion that falls outside the scope of this lab guide. This lab exercise will also not addressmanaging directory and file ACLs using the vserver security file-directory commands.

System Manager does not support managing directory and file level ACLs.

Using 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:

• Clustered Data ONTAP 8.3 File Access Management Guide for CIFS• Clustered Data ONTAP 8.3 File Access Management Guide for NFS• Clustered Data ONTAP 8.3 Commands: Manual Page Reference

3.9.1 Exercise

In this exercise, you create several SMB (CIFS) shares, and then view the shares to see how the default share-level ACL was created for each. You will next add several share-level ACLs to each share and modify/removethe default “Everyone” ACL. You will then be able to mount (map to windows drive letters) the shares you havecreated.

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

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 had 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 Changecifs_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 observethese ACLs in action. These accounts both have the shares in the Share Info table pre-mapped. The“Share ACL permissions” column of this table describes which accounts are granted access to this shareby the ACLs you just created,

Table 18: Table: Share Info

Drive Letter Share Share ACL permissions

X: \\cifs\cifsdv1 Change Control for group "CIFS Data Users", of which datauser1 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, which will launch RemoteDesktop Connection Manager for that system.

9

Figure 3-13:

The “WIN2K12R2 - Remote Desktop Connection Manager” window opens.10. Right-click on WIN2K12R2 in the left pane.


11. Select Connect group... from the context menu.

10

11

Figure 3-14:

Remote Desktop Connection Manager initiates two RDP sessions to the host WIN2K12R2, one foreach of the users DEMO\datauser1 and DEMOdatauser3. However, at this point the application willonly display a thumbnail window for each desktop session.

12. Expand the desktop session for datauser1 by clicking on the datauser1 entry in the left pane.

12

Figure 3-15:

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


14

13

15

Figure 3-16:

16. In the left pane of Windows Explorer, select the X: drive .17. Right-click in the main pane.18. Select New > Text Document from the context menu.19. Name the file "newfile".

As expected from the data in the Share Info table, you are able to create the file successfully.


16

17

18

Figure 3-17:

20. Navigate to the Z: drive.21. Right-click in the main pane.22. Select New > Text Document from the context menu.


20

21

22

Figure 3-18:

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

Wait, you created the same ACLs for both the cifsdv1 and test_folder shares, so why is datauser1 ableto write to cifsdv1 and not to test_folder? The error message gives no indication as to why permission isdenied, all it says is that you need permission, which on it's own isn't very illuminating.

The answer lies in the export policy you created in the last exercise. Recall that the cifsdv1 volumeis using the cifs_pol1 export policy that grants read and write access to the host WIN2K12R2. Thetest_folder share is hosted on the cifsdv2 volume, which is using the cifs_pol2 policy that only grantsread access to the host WIN2K12R2. So, although the share ACL says you have write permission, theexport policy for the share's containing volume takes precedence and restricts you to read-only access.This example illustrates some of the complexities that arise when you deploy both CIFS export policesand share ACLs, which is why CIFS export policy implementations are uncommon.

23. Click the Cancel button.


23

Figure 3-19:

The read-only export policy being used for the cifsdv2 volume will also interfere with the rest of thisexercise, so you need to remove this restriction by having the cifsdv2 volume use the same exportpolicy being used for cifsdv1.

24. In the Putty session for cluster1, configure the cifsdv2 volume to use the cifs_pol1 export policy.


cluster1::>

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


25

26

27

28

Figure 3-20:

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

menu.


29

30

Figure 3-21:

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


31

Figure 3-22:

32. Right-click in this folder.33. Select New > Text Document from the context menu.


32

33

Figure 3-23:

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


Figure 3-24:

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, which 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 mount share is cifsdv2, whichis 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.

3.10 Review Syslog Events

In this section, you connect to the Host functioning as the external syslog server for this lab environment. Onceconnected, you will navigate to the directory where the log files for the Data ONTAP cluster are stored. Byexamining the contents of these log files, you will see an audit record of everything you did during your activitiesin this lab.


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.

3.10.1 Exercise

1. On the desktop of JUMPHOST, right-click the PuTTY icon on the task bar.2. Select syslog from the list of recent sessions.3. Log in with the username root and the password Netapp1!.4. 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]#

5. List the contents of the log directory.

[root@syslog cluster1-01-logs]# ls -ltotal 324-rw------- 1 root root 29971 Sep 27 04:23 command-history-audit.log-rw------- 1 root root 289267 Sep 27 04:23 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 Data ONTAP EMS events, as well as all user and systemgenerated commands. This includes commands entered through the clustered Data ONTAPCLI as well as management activities initiated tools like through System Manager and the DataONTAP PowerShell Toolkit that utilize ZAPI API calls.

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

6. Use the more command to review the contents of the command-history-audit.log file.

[root@syslog cluster1-01-logs]# more commands-history-audit.logSep 27 03:08:18 cluster1-01 cluster1-01: 00000015.00005e52 00023ff9 Sun Sep 27 2015 03:08:16 +00:00 [kern_command-history:info:909] ssh :: 192.168.0.61 :: admin :: cluster log-forwarding create -destination 192.168.0.63 -port 514 -facility user :: PendingSep 27 03:08:18 cluster1-01 cluster1-01: 00000015.00005e54 00023ff9 Sun Sep 27 2015 03:08:16 +00:00 [kern_command-history:info:909] ssh :: 192.168.0.61 :: admin :: cluster log-forwarding create -destination 192.168.0.63 -port 514 -facility user :: SuccessSep 27 03:09:19 cluster1-01 cluster1-01: 00000015.00005e5e 00024264 Sun Sep 27 2015 03:09:18 +00:00 [kern_command-history:info:909] ssh :: 192.168.0.61 :: admin :: security login role create -role stats -cmddirname DEFAULT -access none :: PendingSep 27 03:09:19 cluster1-01 cluster1-01: 00000015.00005e61 00024264 Sun Sep 27 2015 03:09:18 +00:00 [kern_command-history:info:909] ssh :: 192.168.0.61 :: admin :: security login role create -role stats -cmddirname DEFAULT -access none :: SuccessSep 27 03:09:50 cluster1-01 cluster1-01: 00000015.00005ee8 00024399 Sun Sep 27 2015 03:09:49 +00:00 [kern_command-history:info:909] ssh :: 192.168.0.61 :: admin :: security login role create -role stats -cmddirname statistics -access all :: PendingSep 27 03:09:50 cluster1-01 cluster1-01: 00000015.00005eeb 00024399 Sun Sep 27 2015 03:09:49 +00:00 [kern_command-history:info:909] ssh :: 192.168.0.61 :: admin :: security login role create -role stats -cmddirname statistics -access all ::[7m--More--(4%)

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 the configurationactivity, but you'would need additional context from surrounding entries, and probably from thefull 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.

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


if $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_command-history: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 ReferencesThe following references were used in writing this lab guide. All guides related to Clustered Data ONTAP arespecific to the version used in this lab.

Table 19: Table: Lab References

Guide Title Publish Date NetApp P/N

Clustered Data ONTAP 8.3 System Administration Guide June 2015 215-10116_AO

Clustered Data ONTAP 8.3 Commands: Manual Page Reference June 2015 215-10102_AO

Clustered Data ONTAP 8.3 File Access Management Guide for CIFS June 2015 215-10104_AO

Clustered Data ONTAP 8.3 File Access Management Guide for NFS June 2015 215-10105_AO

Clustered Data ONTAP 8.3 Network Management Guide March 2015 215-09157_BO


5 Version History

Version Date Document Version History

Version 1.0 Oct 2015 Initial Release for Insight 2015

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 product components and versions that can be used to construct configurationsthat are supported by NetApp. Specific results depend on each customer's installation in accordancewith 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®

© 2015 NetApp, Inc. All rights reserved. No portions of this presentation may be reproduced without prior writtenconsent of NetApp, Inc. Specifications are subject to change without notice. NetApp and the NetApp logo areregistered trademarks of NetApp, Inc. in the United States and/or other countries. All other brands or products aretrademarks or registered trademarks of their respective holders and should be treated as such.

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

Securing Clustered Data ONTAP - NetApp | NetApp … · 2 Securing Clustered Data ONTAP © 2015...

Documents

Transcript of Securing Clustered Data ONTAP - NetApp | NetApp … · 2 Securing Clustered Data ONTAP © 2015...