CIFS

NETAPP DEMONSTRATION FACILITY

CIFS Hands-On Features for demo.NetApp.com Linda Wu, Senior Manager, Product Management, WFS, NetApp

Reena Gupta, Technical Marketing Engineer, WFS, NetApp

Peter Henneberry, Global Systems Engineer, NetApp November 2008 | TR-3708i

Abstract

This paper provides an overview of how CIFS (Common Internet File System) and NetApp storage technologies interoperate. The users benefit from the added features provides by NetApp for CIFS such as Storage Level Access Guard, NetApp Snapshot, and fsecurity which provide faster CIFS ACL (Access Control Listing) updates, as well as Windows Server consolidation while maintaining high availability with NetApp’s Active Active configuration. These features take advantage of the robust storage management capabilities offered by NetApp storage.

This document is a collaborative effort to produce a consolidated working document, combining the many years of experience and insight of NetApp Technical Reports into one comprehensive document to be used with NetApp’s Demonstration Facility (NDF). The document may be used in conjunction with the NDF following each chapter and selecting one of over thirty hands-on demos, or following the last Appendix and setting up a similar environment to be able to go through each of the chapters to learn a better understanding of how NetApp’s storage leverages CIFS beyond a file sharing and authoring protocol.

CIFS – Demo.NetApp.com 2

TABLE OF CONTENTS

1 HANDS ON EXERCISES ........................................................................................................................... 6

1.1 DEMO SETUP ............................................................................................................................................. 6 1.2 AVAILABLE BATCH FILES ................................................................................................................................ 7

2 NETAPP MICROSOFT RELATIONSHIP ...................................................................................................... 8

2.1 OVERVIEW ................................................................................................................................................. 8 2.1.1 Microsoft Gold Partnership ............................................................................................................. 8 2.1.2 Microsoft Core Protocol Program ................................................................................................... 8 2.1.3 Microsoft TAM ................................................................................................................................ 9 2.1.4 Support and Escalation with NetApp and Microsoft....................................................................... 9 2.1.5 Compatibility Matrix ....................................................................................................................... 9

2.2 NETAPP TECHNICAL REPORT REFERENCE ............................................................................................... 9 2.3 ASSUMPTIONS .......................................................................................................................................... 10

3 CIFS SETUP .......................................................................................................................................... 11

3.1 OVERVIEW ............................................................................................................................................... 11 3.2 NETAPP CIFS VERSUS A WINDOWS SERVER ................................................................................................... 12 3.3 BEST PRACTICES ........................................................................................................................................ 13 3.3.1 Create Both a Host (“A” Record) and Reverse Lookup Name in DNS ............................................ 13 3.3.2 CIFS with Microsoft Windows Internet Naming Service ............................................................... 15 3.3.3 Site Awareness .............................................................................................................................. 15 3.3.4 Network Time Protocol (NTP) ....................................................................................................... 15 3.3.5 Create a New Active Directory OU to Manage the NetApp Storage Objects ................................ 16 3.3.6 Mixed and Native Mode Domains ................................................................................................ 17 3.3.7 NIS Group Lookup ......................................................................................................................... 17 3.3.8 Creating a CIFS Share .................................................................................................................... 18 3.3.9 NetApp Snapshot and SnapRestore .............................................................................................. 19 3.3.10 What You Can Do with Snapshot Copies ....................................................................................... 19

3.4 DEMO ..................................................................................................................................................... 20 3.4.1 CIFS Shares .................................................................................................................................... 20 3.4.2 Join Active Directory from NetApp Storage as a Windows Member Server ................................. 21 3.4.3 Verifying Successful CIFS Installation ............................................................................................ 23 3.4.4 NetApp Storage Windows (NetBIOS) Name ................................................................................. 24 3.4.5 Manage the CIFS Shares from the CLI and Microsoft Management Console ............................... 25 3.4.6 Qtree Implementation .................................................................................................................. 26 3.4.7 Create Users’ Home Directories .................................................................................................... 28

3.5 NETAPP TECHNICAL REPORT REFERENCE ............................................................................................. 32

4 SECURITY ............................................................................................................................................ 34

4.1 OVERVIEW ............................................................................................................................................... 34 4.1.1 Infrastructure Security .................................................................................................................. 34 4.1.2 File‐Level Security ......................................................................................................................... 35 4.1.1 Communication Security ............................................................................................................... 36 4.1.2 File Policy (FPolicy) ........................................................................................................................ 38 4.1.3 Role‐Based Access Control (RBAC) ................................................................................................ 38

4.2 MANAGING CIFS SECURITY WITH GROUPS (LOCAL AND GLOBAL) ..................................................................... 39 4.2.1 Domain Local Groups .................................................................................................................... 40 4.2.2 Global Groups ............................................................................................................................... 40 4.2.3 Universal Groups ........................................................................................................................... 40

CIFS – demo.NetApp.com Page 3 of 187

4.2.4 Built‐In (Nondomain) Local Groups ............................................................................................... 41 4.2.4.1 Built‐In Local Groups on NetApp Storage ................................................................................................. 41 4.2.4.2 Guidelines for Creating Local Groups ....................................................................................................... 41

4.2.5 Local NetApp Storage Groups ....................................................................................................... 42 4.2.6 Multiple Protocol Access ............................................................................................................... 45

4.2.6.1 Effects of Changing an NTFS‐Only Storage System to a Multiprotocol System ........................................ 45 4.2.6.2 Effects of Changing a Multiprotocol Storage System to an NTFS‐Only System ........................................ 45 4.2.6.3 Effects of Changing the Storage System's Domain ................................................................................... 46

4.2.7 Security Group Recommendations ................................................................................................ 46 4.3 CIFS FILE SECURITY, AND USER MAPPING ...................................................................................................... 46 4.3.1 Antivirus Management ................................................................................................................. 48 4.3.2 Auditing ........................................................................................................................................ 49 4.3.3 Access‐Based Enumeration ........................................................................................................... 50 4.3.4 Secure Configuration of Data ONTAP ........................................................................................... 51

4.4 BEST PRACTICES ........................................................................................................................................ 51 4.4.1 Using FPolicy ................................................................................................................................. 51 File Screening Overview ................................................................................................................................ 52 4.4.2 Antivirus Scanning Best Practices ................................................................................................. 53 4.4.3 Cross‐Protocol File Access (CIFS and NFS) ..................................................................................... 53 4.4.4 CIFS Auditing ................................................................................................................................. 54 4.4.5 Converting Qtree Security Styles ................................................................................................... 54 4.4.6 NetApp Operations Manager: Report on Security, Performance, and Trends .............................. 55 4.4.7 Access‐Based Enumerations Limitations ....................................................................................... 55

4.5 DEMO ..................................................................................................................................................... 56 4.5.1 File Screening with FPolicy ............................................................................................................ 56 4.5.2 Storage‐Level Access Guard .......................................................................................................... 57 4.5.3 Useradmin CLI (Role Based Access Control) .................................................................................. 62 4.5.4 Antivirus Scanning ........................................................................................................................ 63 4.5.5 Live‐View Auditing ........................................................................................................................ 67 4.5.6 Access‐Based Enumeration (ABE) ................................................................................................. 71 4.5.7 Configuring SSH and SSL ............................................................................................................... 74


5 FILE SYSTEM RESOURCE MANAGER ..................................................................................................... 81

5.1 OVERVIEW ............................................................................................................................................... 81 5.1.1 Quota Management ..................................................................................................................... 81

5.2 BEST PRACTICES ........................................................................................................................................ 81 5.2.1 Quota ............................................................................................................................................ 81

5.3 DEMO ..................................................................................................................................................... 82 5.3.1 Native Quota Configuration .......................................................................................................... 82 5.3.2 Quota Management using Northern Storage Suite ...................................................................... 86 5.3.3 Quota Management using NTP Software ..................................................................................... 89


6 INTEGRATION WITH WINDOWS SERVICES ........................................................................................... 92

6.1 OVERVIEW ............................................................................................................................................... 92 6.2 BEST PRACTICES ........................................................................................................................................ 92 6.2.1 Configuring Offline Folders ........................................................................................................... 92 6.2.2 Configuring Folder Redirection (Symbolic Links) ........................................................................... 93 6.2.3 Group Policy Objects (GPOs) ......................................................................................................... 94 6.2.4 Managing User Roaming Profiles ................................................................................................. 95

6.3 DEMO ..................................................................................................................................................... 98 6.3.1 Group Policy Object Security Configuration .................................................................................. 98

CIFS – Demo.NetApp.com 4

6.3.2 Integrating with Active Directory LDAP ...................................................................................... 101 6.3.2.1 Editing the /etc/nsswitch.conf File for LDAP .......................................................................................... 102 6.3.2.2 Extending the RFC 2307 Schema ............................................................................................................ 103 6.3.2.3 LDAP Authentication Requires Clear Text Passwords ............................................................................. 105 6.3.2.4 Testing Windows LDAP ........................................................................................................................... 106 6.3.2.5 Manage NetApp Storage Users in LDAP Mode ....................................................................................... 111

6.3.3 Integrating with DFS ................................................................................................................... 113 6.3.4 Integrating with VSS ................................................................................................................... 115

7 FILE‐LEVEL MIGRATION ..................................................................................................................... 119

7.1.1 Migrating Files While Preserving Their ACLs .............................................................................. 119 7.1.2 Data Migration: Server Consolidation to NetApp Storage .......................................................... 120 7.1.3 Planning Data Migration ............................................................................................................ 120 7.1.4 Migrating Data ........................................................................................................................... 122

7.2 BEST PRACTICES ...................................................................................................................................... 122 7.3 DEMO ................................................................................................................................................... 123 7.3.1 VFM ‐ Enables non‐disruptive expansion and consolidation........................................................ 123 7.3.2 Migrating Files with VFM ............................................................................................................ 124

7.4 NETAPP TECHNICAL REPORT REFERENCE ........................................................................................... 126

8 FUTURE OF NETAPP CIFS ................................................................................................................... 127

8.1 OVERVIEW ............................................................................................................................................. 127 8.1.1 SMB 2 and Diagnostics ............................................................................................................... 127

8.2 BEST PRACTICES ...................................................................................................................................... 128 8.3 DEMO ................................................................................................................................................... 128 8.3.1 SMB 2 Configuration ................................................................................................................... 128

8.4 NETAPP CIFS SMB VARIABLES .................................................................................................................. 129 8.5 SMB2 HIDDEN OPTIONS FOR TWEAKING PERFORMANCE ................................................................................ 130

9 TROUBLESHOOTING AND PACKET TRACES ......................................................................................... 131

9.1.1 CIFS Configuration Files .............................................................................................................. 132 9.1.2 Diagnostic Troubleshooting with PKTrace .................................................................................. 133

9.2 SLOW CIFS AUTHENTICATION .................................................................................................................... 137 9.3 MISCELLANEOUS TROUBLESHOOTING .......................................................................................................... 138 9.4 NETAPP TECHNICAL REPORT REFERENCE ........................................................................................... 139

10 SIZING AND PERFORMANCE .............................................................................................................. 140

10.1 OVERVIEW ............................................................................................................................................. 140 10.1.1 High Availability with NetApp Active‐Active Clustering .............................................................. 141 10.1.2 CIFS Sizing on NetApp Storage .................................................................................................... 142 10.1.3 Tuning Windows CIFS Performance ............................................................................................ 144 10.1.4 Advanced oplocks Settings.......................................................................................................... 145 10.1.5 Options CIFS.oplocks.opendelta .................................................................................................. 145 10.1.6 Options CIFS.max mpx and Citrix ................................................................................................ 145

10.2 BEST PRACTICES ...................................................................................................................................... 147 10.3 DEMO ................................................................................................................................................... 148 10.3.1 NetApp CIFS Sizing Tool Walk‐Through ...................................................................................... 148

10.4 NETAPP TECHNICAL REPORT REFERENCE ........................................................................................... 149

APPENDIX A: DOMAIN DISCOVERY ........................................................................................................... 150

APPENDIX B: CIFS SIZING FLOWCHART ...................................................................................................... 151

APPENDIX C: NETAPP CIFS ADVANCED OPTIONS ....................................................................................... 152


APPENDIX D: CIFS NETAPP SIZING GUIDELINE ........................................................................................... 157

GENERAL NETAPP STORAGE SPECIFICATIONS ............................................................................................................ 158 BACKEND SIZING INFORMATION ............................................................................................................................. 160 CUSTOM SIZER SPECIFIC INFORMATION ................................................................................................................... 160 CIFS HOME DIRECTORY SPECIFIC INFORMATION ....................................................................................................... 160

APPENDIX E: CIFS RESOURCE LIMITS ......................................................................................................... 163

APPENDIX F: USING NOVELL’S EDIRECTORY FOR LDAP AUTHENTICATION ................................................. 165

APPENDIX G: COMMONLY USED ADMINISTRATIVE INTERFACES FOR DATA ONTAP ................................... 171

ADMINISTRATIVE APPLICATIONS FOR DATA ONTAP ................................................................................................... 171 NETAPP JAVA SHELL ............................................................................................................................................ 172

APPENDIX H: SUPPORTED GPO’S .............................................................................................................. 173

SUMMARY OF GPO FEATURES ............................................................................................................................... 173

APPENDIX I: CIFS PERFORMANCE COUNTERS ............................................................................................ 175

CIFS COUNTERS FOR PERFMON ................................................................................................................ 175

CIFS OPERATIONS ............................................................................................................................................... 176 CIFS STATISTICS .................................................................................................................................................. 179 CIFS DOMAIN .................................................................................................................................................... 182 VSCAN STATISTICS ............................................................................................................................................... 182 VSCAN SERVER STATISTICS .................................................................................................................................... 184 SMB SIGNING STATISTICS ..................................................................................................................................... 185

CONCLUSION ............................................................................................................................................ 187

Page 6 of 187 CIFS – Demo.NetApp.com

1 HANDS ON EXERCISES When you see this:

HANDS-ON EXERCISE: DNS Setup

Prerequisite: <BATCH FILE(s) which must be run before proceeding with the Exercise>

Either perform the follow steps, or to automate the task, execute: <BATCH FILE>

Performed from Vista, W2003 or W2008 <which OS platform the work can be performed from>

The batch files are located on both the Windows 2003 Server (SERVER), and the Vista workstation (CLIENT) at: C:\CIFSDEMO\Scripts

NOTE: The objective of each batch file allows you to jump to the finished exercise to show or review what has been performed. The recommendation, as time permits, is to go throught the exercises following the hands-on guide without using the batch files – this will enhance your learning.

1.1 DEMO SETUP Hardware Configuration: Hardware Version DNS IP Windows Vista 32-bit platform,

Business edition Vista.workgroup 192.168.10.150

Windows 2003 Server

32-bit platform, Enterprise

W2003.demo.netapp.com 192.168.10.100

Windows 2008 Server

64-bit platform, Enterprise

W2008.workgroup 192.168.10.101

Novell NetWare 6.5 32-bit OES Bigred.demo.netapp.com 192.168.10.102 FAS2020 Data ONTAP 7.3.0 FAS1.demo.netapp.com 192.168.10.35 Preinstalled Software: Vista: Sun™ Java v.1.5.0.04 Windows 2003: Sun™ Java v.1.5.0.04

DNS – both forward and reverse zones Active Directory: demo.netapp.com TimeSync Daemon (using Tardis200nt.exe) OU=NetApp Storage created to place NetApp storage objects OU=ldapusers created for user testing User Context Group Administrator demo.netapp.com\Users\ Domain Admins Wilma demo.netapp.com\ldapusers\ Remote Desktop Users Fred demo.netapp.com\ldapusers\ Remote Desktop Users Root \ (NetApp local account) The password for all users is: netapp1 NOTE: Unless otherwise stated in the hands-on demo, always use demo\administrator to log onto SERVER (W2003), W2008 or CLIENT (Vista).


When FAS1> is specified, use: NetApp Storage FAS 2020 When CLIENT> is specified, use: Vista machine When SERVER> is specified, use: W2003 When NETWARE> is specified, use: BigRed For Windows command line interface, use the CMD.EXE tool (Start, Run, CMD)

For NetApp command line interface, use telnet (Start, Run, CMD, Telnet FAS1). A shortcut has been placed on the W2003 desktop.

The batch files are meant to be run once, i.e. If you run CIFSJOIN.BAT in one secton, you do not need to rerun the same batch file in another section. The batch files follow the order of the document. If you wish to either rerun a batch file, or move to a section prior to the current section you have completed, you will need to reset the virtual environment to the state before any scripts where executed.

1.2 AVAILABLE BATCH FILES

Access-Based Enumeration, 71

Antivirus Scanning, 63

CIFS Performance Counters, 175

CIFS Sizing, 142

DFS, 114

DNS Setup, 6, 14

File Screening, 56

GPO - Verify, 100

GPO Security, 98

Group Policy Object, 93

Joining Active Directory, 21

LDAP Authentication with Novell’s eDirectory, 165

LDAP NSSWITCH.CONF, 102

LDAP Permissions, 111

Live-View Auditing, 68

NetBIOS Alias, 24

Network Time Protocol, 16

Northern Storage Suite Quota Management, 86, 89

PKTrace, 133

Quotas, 85

Roaming User Profile, 97

SnapRestore, 117

SSH Setup, 74

SSL Setup, 78

Storage-Level Access Guard, 59

Troubleshooting CIFS, 131

Useradmin Command Line Interface, 62

Users’ Home Directories, 28

Verify Successful CIFS Installation, 23

VFM for File Migration, 124


2 NETAPP MICROSOFT RELATIONSHIP NetApp® storage systems are storage appliances powered by NetApp Data ONTAP® software. Data ONTAP optimizes file service by combining the WAFL® (Write Anywhere File Layout) file system and a microkernel design dedicated to network data access.

NetApp storage systems are compatible with Microsoft® Windows® environments, whether operating as network-attached storage (NAS), as a storage area network (SAN), or both. In Windows file-serving environments, storage systems look and act like Microsoft Windows member servers and can be monitored and administered using native Windows management components while providing highly available file service.

Storage systems use the Microsoft industry-standard CIFS/SMB protocol and support native implementations of the Lightweight Directory Access Protocol (LDAP) and the Kerberos authentication protocol without requiring any additional software. This paper discusses how storage systems can be seamlessly integrated in enterprise-class Windows data centers to utilize services and features such as Active Directory, access-based enumeration, offline file cache, auditing, file screening, and CIFS virus protection.

2.1 OVERVIEW

2.1.1 Microsoft Gold Partnership NetApp is strategically committed to architecting storage solutions that are highly compatible with Microsoft technologies. Tight integration of licensed Windows protocols and complete compatibility with Windows OS enhancements as well as Microsoft applications are NetApp development priorities. These solutions are backed by a global customer support infrastructure that integrates Microsoft Premier Support.

• NetApp is a Microsoft Gold Certified Partner. Out of 600,000 Microsoft partners, only 6,000 are Gold Certified.

• All NetApp Internet SCSI Small Computer System Interface (iSCSI) and Fibre Channel Protocol (FCP) storage systems with the Windows logo are fully supported by Microsoft.

• NetApp has more iSCSI storage systems with the Windows logo than any other vendor.

• NetApp storage solutions support many Microsoft storage technologies. This includes support for version 2.0 of its Windows iSCSI software initiator, Volume Shadow Copy Service (VSS), and Microsoft Multipath I/O (MPIO).

2.1.2 Microsoft Core Protocol Program NetApp is a licensee of the Microsoft Core Protocol Program, assuring support and interoperability of our Windows file serving (CIFS) products. Early in 2008, the Microsoft Core Protocol Program began evolving into an open access program. This means for Microsoft Core Protocol Program subscribers, submitting a defect or issue is covered as well as receiving priority response to open cases. Customers not it the Microsoft Core Protocol Program will pay per case.

NetApp licenses Microsoft protocols under the Microsoft Core Protocol Program (www.microsoft.com/about/legal/intellectualproperty/protocols/mcpp.mspx). This is a part of the Microsoft efforts to be more open and standardize its protocols. NetApp also has access to the Microsoft Interoperability Labs and participates in its Plugfest events to test the Microsoft Core Protocol Program (MCPP) protocol implementations.


2.1.3 Microsoft TAM NetApp solutions deployed within Microsoft environments are supported at various levels on a global 24x7 basis. As part of that support process, NetApp contracts a Microsoft OEM Technical Account Manager (TAM) focused on assuring interoperability between Microsoft and NetApp products. The TAM assists with engineering challenges associated with the compatibility of prerelease product from either Microsoft or NetApp. The TAM will open a case and track it through to resolution inside of Microsoft. This same process is in place for cases opened by NetApp Customer Support. In conjunction with an OEM Premier Support Agreement, NetApp is able to open a support case for NetApp or on behalf of a customer with Microsoft and utilize the OEM TAM to track the case to resolution. The primary focus of the Microsoft OEM TAM is on technical problem resolution between Microsoft and NetApp, not between Microsoft and the customer

2.1.4 Support and Escalation with NetApp and Microsoft OEM Premier Support Agreement: NetApp and Microsoft have support agreements in place providing seamless 24x7 global support to NetApp customers. This enables NetApp and Microsoft to work closely together to address enterprise customer support needs.

2.1.5 Compatibility Matrix Functional regression testing is carried out to verify that previously existing NetApp product functionality continues to operate as specified with the new service pack.

ZD Labs Netbench 7.0 is one of the several products used by NetApp to confirm improvements, obtain performance numbers, and do functional regression testing. Another industry standard program used is FSspec 2008. Several other tests include:

1. Custom-built scripts for the regression testing and stress testing in a NetApp test environment.

2. Windows API for testing all the Windows API calls.

3. Populate_data.pl, a script used by the NetApp DPG group to create a CIFS data set with maximum CIFS coverage, including DIRS|FILES|STREAMS|SPARSE|ATTRS operations. It can be run against two targets, for example, NetApp storage and Microsoft Windows 2003 Server, and compare data.

4. NetApp has approximately 1,725 test cases defined for functional and the stress testing.

Stress tests are also used to saturate different components of the NetApp product and the service pack.

Reliability tests are run on the NetApp platform in order to test long-term reliability of the product with a new service pack, patch, or operating system.

2.2 NETAPP TECHNICAL REPORT REFERENCE Microsoft and NetApp Escalation

www.netapp.com/us/solutions/solution-partners/global-alliance/ms-support.html#oem

www.netapp.com/us/solutions/solution-partners/global-alliance/microsoft-partnership.html


Configuring and using IOmeter for performance testing in an application environment

www.netapp.com/us/library/technical-reports/tr-3697.html

2.3 ASSUMPTIONS This paper assumes that you are knowledgeable at the administrative level with Microsoft Windows 2003 Server and Windows Server 2003 products and their features.

This paper also assumes that you are knowledgeable about NetApp storage system administration. For detailed information about storage system administration, refer to the NetApp Data ONTAP administration guides available at http://now.netapp.com.

Data ONTAP version 7.3.0, released July 24, 2008, is the version used in this document.


3 CIFS SETUP

3.1 OVERVIEW NetApp storage systems are commonly used to store an organization’s personal home directories for a variety of compelling reasons. One significant benefit of having the CIFS home directories on NetApp storage system is that it eases the administration of the storage system by creating only one share that resolves the location of all the users’ home directories. Users are offered a dynamic share with their matching directory name. From the CIFS client perspective, the home directory works the same way as any other share to which the user can connect. Each user can see and connect only to his or her home directory, not the home directories for other users. Compared to the traditional method, in which administrators have to create one share per user, the NetApp home directories feature uses fewer system resources and therefore improves overall system performance.

CIFS Setup

The CIFS setup command invokes a utility that prompts you for information such as authentication type, lookup services to be used, and so forth. In addition to performing initial CIFS configuration, the CIFS setup command enables you to perform the following tasks:

• Assign or remove Windows Internet Naming Service (WINS) servers.

• Enter the storage system Active Directory site information, if it is not already configured.

• Join the storage system to a domain, change domains, or choose an alternate authentication method.

• Automatically generate /etc/passwd and /etc/group files when NIS or LDAP is enabled.

To learn about using the CIFS setup program for initial CIFS configuration, including a list of the information you need when running CIFS setup, refer to the Data ONTAP Software Setup Guide.

CIFS Authentication

Data ONTAP CIFS services support four styles of user authentication.

(1) Active Directory domain authentication (Active Directory domains only)

(2) Windows NT® 4 domain authentication (Windows NT or Active Directory domains)

(3) Windows workgroup authentication using the NetApp storage's local user accounts

(4) /etc/passwd and/or NIS/LDAP authentication

Compatibility with Windows Vista and Windows Server 2008

Data ONTAP 7.2.4 and later releases are compatible with Windows Vista clients, Windows Server 2008 clients, and Windows Server 2008 domain controllers.


3.2 NETAPP CIFS VERSUS A WINDOWS SERVER • SMB authentication mechanism is the same.

• When CIFS is configured to join Active Directory, NetApp storage functions as a Windows member server for CIFS authentication and administration.

As defined by Microsoft, in Active Directory server roles, computers that function as servers within a domain can have one of two roles: member server or domain controller. A member server is a computer that runs an operating system in the Windows 2000, 2003, or 2008 Server family, and belongs to a domain, and is not a domain controller. Member servers typically function as the following types of servers: file servers, application servers, database servers, Web servers, certificate servers, firewalls, and remote-access servers.

• Time synchronization is automatic between Active Directory servers, but must be configured on the NetApp storage to point to the Active Directory NTP source.

• NetApp CIFS protocols:

o Kerberos

o NTLM v2

o LDAP

o Not a Windows and Kerberos key distribution center (KDC), just as a Windows member server cannot be a KDC.

• DC discovery and ordering are NetApp’s own invention, and allow DC to be manually listed in the priority NetApp will use to contact the DC.

Discovery for its first connection to a domain controller, Data ONTAP uses any available domain controllers that appear in the cifs prefdc list. If none of these “preferred” controllers is available, all domain controller addresses are discovered at once, then categorized, prioritized, and cached.

Prospective domain controller IP addresses are divided into the following three categories, and then sorted within each of these categories:

PREFERRED: IP address list entered using the cifs prefdc command.

FAVORED: IP addresses of servers identified by the following Windows AD site

queries: ldap._tcp.<site>._sites.dc.msdcs<fully qualified domain name> or ldap._tcp.Default-First-Site-Name._sites.dc.msdcs.<fully qualified domain name>

OTHER: IP addresses returned by the DNS SRV record query: ldap._tcp.dc.msdcs.<fully qualified domain name>

Preferred addresses are ordered as specified using the cifs prefdc command. “Favored” and “Other” categories are sorted according to the fastest response. Data ONTAP simultaneously pings all addresses listed in both categories and waits one second for responses. Addresses are separated into three groups: controllers that replied, controllers that didn't reply but are located on the local subnet, and all other controllers. Controller connections are then attempted in the following order, from best to worst:


3.3 BEST PRACTICES

3.3.1 Create Both a Host (“A” Record) and Reverse Lookup Name in DNS

NetApp storage systems query Domain Name Service (DNS) servers to locate domain controllers. Because the Active Directory service relies on DNS to resolve names and services to IP addresses, the DNS servers that are used with storage systems in an Active Directory environment must support service location (SRV) resource records (per RFC 2782). If DNS is not enabled or is not configured correctly, Data ONTAP will not be able to find the service records it needs to locate DCs, KDCs, LDAP servers, and KPASSWD servers, and so will not be able to join the AD domain.

Note: DNS servers that support dynamic updates (per RFC 2136) are recommended by Microsoft so that important changes to SRV records about domain controllers are automatically updated and available to clients immediately.


Determining If DNS Is Set Up Properly in AD

HANDS-ON EXERCISE: DNS Setup

Prerequisite: none Either perform the follow steps, or to automate the task, execute: DNSSETUP.BAT. Then, proceed to step #2

Performed from W2003

Since DNS is so important to Active Directory you may want to determine if DNS has been properly set up in the AD domain. Open the Microsoft DNS console. Verify that you have a DNS domain with the same name as your corresponding Active Directory domain. See that within it you have the four SRV record folders (child domains) (_msdcs/, _sites/, _tcp/ and _udp/).

1.

To adjust the DNS settings: FAS1> options dns.domainname demo.netapp.com

FAS1> options dns.enable on

FAS1*> priv set advanced

FAS1*> rm /etc/rc

FAS1*> wrfile -a /etc/rc hostname FAS1

FAS1*> wrfile -a /etc/rc ifconfig ns0 `hostname`-ns0

FAS1*> wrfile -a /etc/rc route add default 192.168.10.1 1

FAS1*> wrfile -a /etc/rc routed on

FAS1*> wrfile -a /etc/rc options dns.domainname demo.netapp.com

FAS1*> wrfile -a /etc/rc options dns.enable on

FAS1*> wrfile -a /etc/rc options nis.enable off

FAS1*> rm /etc/resolv.conf

FAS1*> wrfile -a /etc/resolv.conf nameserver 192.168.10.101

FAS1*> wrfile -a /etc/resolv.conf nameserver 192.168.10.102

FAS1*> priv set

To check the configuration of DNS from the NetApp storage, from the CLI, type:

2.

FAS1> dns info, or

Use getXXbyYY to verify forward and reverse lookups from the NetApp storage. FAS1> priv set advanced

FAS1*> getXXbyYY gethostbyaddr_r 192.168.10.100

FAS1*> getXXbyYY gethostbyname_r W2003


FAS1*> priv set

Note: Customers may use the “Priv Set Advanced” or “Priv Set Diag” command when instructed to do so by NetApp Technical Support or NetApp Professional Services. Otherwise, the advanced command set is not supported for a customers use in a production environment.

3.3.2 CIFS with Microsoft Windows Internet Naming Service The CIFS setup utility allows you to make your storage system accessible or inaccessible to systems using the Windows Internet Naming Service by specifying up to four Windows Internet Naming Service servers or by disabling the Windows Internet Naming Service. However, running CIFS setup requires that you halt CIFS. A nondisruptive way to modify Windows Internet Naming Service servers is to enter a comma-separated list of Windows Internet Naming Service servers using the CIFS.wins_servers option.

Note that this server list is not additive: if you are adding a third Windows Internet Naming Service server, you must enter all three IP addresses in a comma-separated list, or your existing two Windows Internet Naming Service servers are replaced by the server you intended to add. To add or change the Windows Internet Naming Service servers from the CLI, issue:

FAS1> options cifs.wins_servers <specify up to four IPv4 WINS servers>

3.3.3 Site Awareness Active Directory sites are used to logically represent an underlying physical network. A site is a collection of networks connected at LAN speed. Slower and less reliable wide area networks (WANs) are used between sites (locations) that are too far apart to be connected by LAN.

NetApp storage systems are Active Directory site-aware. Therefore, storage systems attempt to communicate with a domain controller in the same site instead of selecting a domain controller at a different location. It is important to place the storage system in the proper Active Directory site to use resources that are physically close to it.

3.3.4 Network Time Protocol (NTP) Match the storage system’s time and time zone settings to the one on the domain controller.

Caution: If the time settings on the storage system and the domain controller are more than five minutes apart, the CIFS setup fails. The Kerberos protocol requires that the time settings on the storage system and domain controller be nearly the same. Once CIFS is running, if time drifts more than 15 minutes from the NetApp storage and the authenticating DC, users will not be able to connect to their CIFS share(s). To eliminate this problem, the best practice is to configure NetApp storage to use an NTP source.


HANDS-ON EXERCISE: Network Time Protocol

Prerequisite: DNSSETUP.BAT Either perform the follow steps, or to automate the task, execute: NTPTIME.BAT . Then, proceed to step #2

Performed from Vista, W2003 or W2008

To configure NetApp storage for NTP time synchronization, from a CLI session, issue the following commands:

1. FAS1> Options timed.log off FAS1> Options timed.max_skew 5m FAS1> Options timed.min_skew 0 FAS1> Options timed.protontp FAS1> Options timed.sched hourly FAS1> Options timed.servers W2003

(For this lab, ‘W2003’ is the NTP Source) FAS1> Options timed.window 0s FAS1> Options timed.enable on

Refer to the Data ONTAP system maintenance for detailed information on “timed” or from the console, type: “man na_rdate” for detailed instructions.

To temporarily adjust the date and time with an NTP server, type:

2. FAS1> rdate W2003

3.3.5 Create a New Active Directory OU to Manage the NetApp Storage Objects

When using the Web CIFS setup wizard (FIlerView®), the NetApp storage object will be placed in the “Computer” Active Directory organizational unit (OU). When running the setup from the CLI, you are presented with available OUs to place the NetApp storage object in.

The best practice is to create a new OU in Active Directory: create an OU called NetApp Storage and either create the object in this context or move existing NetApp storage objects to this OU. The reason is twofold:

• Active Directory group policy objects (GPOs) cannot be applied to the Computer OU.

• Microsoft’s GPO best practice guide recommends creating an OU for a dedicated function, in this case for the NetApp storage.

Note: You can also precreate the NetApp object in the desired OU. Refer to section 3.4.2 under “NetApp storage” for a list of the steps. For a detailed explaination of each step, refer to the CIFS administration guide on precreating a NetApp object in Active Directory.


3.3.6 Mixed and Native Mode Domains The terms mixed and native mode refer to domain functional levels in Windows 2000 Server. Windows 2000 Server introduced two Active Directory modes, mixed and native, to support different deployment scenarios.

In Windows 2003 Server, the terms mixed and native have been superseded by raise function level. Windows 2003 introduced two additional nodes, Windows Server 2003 interim and Windows Server 2003 (also known as Windows 2003 Server native).

A NetApp device can be joined to and operate within an Active Directory whether in mixed, native, interim, or pure Windows 2003 Server mode. NetApp recommends that you consider implementing a native design and remain in mixed mode (or interim mode for Windows 2003) only as a stopgap until you can migrate your entire legacy domain.

Windows 2000 Server Modes

Windows 2000 Server mixed mode makes Active Directory function like a Windows NT primary domain controller (PDC), which enables cross-communication and interoperability with Windows NT domains and directly supports Windows legacy clients (Windows 3.x, 95, 98, and Me). These domains can emulate Windows NT or pre-Active Directory domain environments for legacy computers simultaneously with Active Directory.

Use Windows 2000 Server mixed mode when one of the following is true:

• You have a mixture of Windows 2000 and Windows 2003 domain controllers as well as Windows NT 4.0 backup domain controllers (BDCs)

• You want to slowly transfer your Windows NT 4 domains to native mode Active Directory (Windows 2000 Server native or Windows 2003 Server).

The limitations of a Windows 2000 Server are:

• No support for universal groups

• No support for group policies (only system policies)

• Active directory database is limited to 40MB (24,000 accounts vs. 3 to 10 million for AD)

Due to the limitations imposed by Windows 2000 Server mixed mode, your organization should consider going to native mode (2000 or 2003). There are many reasons to stay in mixed mode before going directly to native. One important reason is that during your migration to AD, the mixed mode provides the functionality that lets Windows NT 4 BDCs continue to offer domain services. Because Windows 2000 Server mixed mode allows a domain controller to emulate a PDC, mixed mode enables you to deploy a Windows Server 2000 or 2003 Active Directory domain controller in a Windows NT 4 domain or in a new domain. For example, you might want to upgrade your existing Windows NT 4 DCs to Windows Server 2003 over some period of time. Then, when all DCs have been upgraded, you have the option of switching to native mode at your convenience. Since each DC continues to interoperate with the others, you can take your time with the upgrade and follow a methodical implementation plan.

3.3.7 NIS Group Lookup If you use Network Information Service (NIS) for group lookup services, disabling NIS group caching can cause severe degradation in performance. Whenever you enable NIS lookups using the nis.enable option, it is strongly recommended that you also enable caching using the


nis.group_update.enable option. Failure to enable these two options together could lead to timeouts as CIFS clients attempt authentication.

For more information about configuring NIS, see the Network Management Guide.

3.3.8 Creating a CIFS Share After a CIFS-enabled NetApp storage is configured, the storage is viewable on the Windows network, but no data is shared yet, apart from the three default administrative shared (C$, HOME, ETC$). To share data, a NetApp CIFS share must be created. The share name must be unique for the server. A CIFS share is a named access point in a volume that enables CIFS clients to view, browse, and manipulate files on NetApp storage.

Note: By default, machine accounts have access to a newly created share.

When creating a share you must provide the complete path name of an existing folder or qtree to be shared and the name of the share used by users when they connect to the share. Share naming conventions for Data ONTAP are the same as for Windows, and share names are not case-sensitive. For example, share names ending with the $ character are hidden shares, and certain share names, such as ADMIN$ and IPC$, are reserved. Choose share names that reflect the type of data this share will contain or groups that will have access to it (for example, acct, engr, mktng, design, CAD, proj).

CIFS shares can be created either using the Windows Computer Management Microsoft Management Console or by using the cifs shares command in Data ONTAP. The flexibility to use the Microsoft Management Console allows Windows administrators to use tools they are familiar with. In the Path field of the New Share window be sure to type the complete path name of the folder or qtree, starting with the C:\vol\vol_name prefix. C: is ignored by the NetApp storage. All shares created on the NetApp storage have paths that begin with C: with the actual volume name appended. For instance a share on /vol/vol3 would have a path specified as C:\vol\vol3. To make it easier to create subsequent shares on NetApp storage volumes in the Microsoft Management Console it is recommended that you create a default “hidden” share at the root of each volume on the NetApp storage so administrators can browse for them and create additional shares from there.

For organizations that prefer to separate storage administrative duties from general Windows administrative duties, it is preferable to have default hidden shares that exist at the root of each volume on NetApp storage (for example, C$ for /vol/vol0, D$ for /vol/vol1 …). Having a hidden share at the root of each volume allows quick and straightforward access to each volume in case any Windows or storage administration is needed. One example might be setting the permissions on these shares to allow only domain administrators access to the root of each volume in case qtrees need to be changed (security type) or deleted. In addition, it probably makes sense to map to the root of each volume and add full NTFS permissions for the domain administrators.

The number of CIFS shares allowed to be created per NetApp storage is based on the system memory and is different for each platform. Check the NOW™ (NetApp on the Web). site for the resource constraint.

The directory path name can be up to 255 characters long. If there is a space in the path name, the entire string must be quoted (for example,"/new volume/mount here").

The following example creates a CIFS share named SHARE1. Its directory path is /u/eng. UNIX mode bits are explicitly set as 775 on files and 777 on directories.

FAS1:> cifs shares -add SHARE1 /u/eng –file_umask 775 –dir_umask 777


3.3.9 NetApp Snapshot and SnapRestore A Snapshot™ copy is a frozen, read-only image of a traditional volume, a FlexVol® volume, or an aggregate that reflects the state of the file system at the time the Snapshot copy was created. Snapshot copies are your first line of defense for backing up and restoring data.

Data ONTAP maintains a configurable Snapshot schedule that creates and deletes Snapshot copies automatically for each volume. Snapshot copies can also be created and deleted manually.

NetApp storage default schedule for each Volume Snapshot is:

6 daily, 2 nightly, 1 weekly

You can store up to 255 Snapshot copies at one time on each volume, and up to 200 Snapshot copies for each aggregate.

You can specify the percentage of disk space that Snapshot copies can occupy. The default setting is 20% of the total (both used and unused) space on the disk. For a full explanation of how Snapshot copies consume disk space, see Understanding Snapshot disk consumption.

Snapshot files carry the same permissions and inode numbers as the original files, keeping the integrity of the security system intact. Inodes are data structures that hold information (including permissions information) about files on the storage system. There is an inode for each file, and a file is uniquely identified by the file system on which it resides and its inode number on that system.

3.3.10 What You Can Do with Snapshot Copies Snapshot copies enable system administrators to perform the following tasks:

• Create near-instantaneous backups

• For CIFS and NFS, NetApp quiesces the data before each Snapshot, guaranteeing a consistent recovery point

• Create a clone of a FlexVol volume*

• Replicate the Snapshot to a DR site

Note: See the Storage Management Guide for information about cloning a FlexVol volume.

CIFS and NFS volume Snapshot copies enable end users to do the following:

• Recover older versions or sets of files that were accidentally changed or deleted

• Restore their own files without needing a system administrator to restore files from tape

For a complete listing of NetApp Snapshot and SnapRestore® functions, refer to Chapter 2, Snapshot management in the NetApp Data Protection Online Backup and Recovery Guide.


3.4 DEMO

3.4.1 CIFS Shares CIFS shares displays one or more shares, edits a specified share, creates a share, deletes a share, or displays a total summary of the shares.

Listing Shares

To list all shares and their access control lists, use the command “CIFS shares” with no arguments. To list a single share and its access control list, use the command “CIFS shares sharename” where sharename is the name of the share.

To create a new share, use the -add option:

CIFS shares -add sharename path

Sharename Name of the new share; clients use this name to access the share

Path Full path name of the directory on the NetApp storage that corresponds to the root of the new share

-f Suppress confirmation dialogs, if any.

-comment description

Description of the new share. CIFS clients see this description when browsing the NetApp storage's shares. If the description includes spaces, it must be enclosed in double quotation marks. If you do not specify a description, the description is blank.

-maxusersuserlimit

Maximum number of simultaneous connections to the new share. userlimit must be a positive integer. If you do not specify a number, the NetApp storage does not impose a limit on the number of connections to the share.

-forcegroupgroupname Name of the group to which files to be created in the share belong. The groupname is the name of a group in the UNIX group database.

-nosymlink_strict_security

Allow clients to follow symbolic links to destinations on this NetApp storage but outside of the current share. Do not check that the client is authenticated to the symbolic link's destination.

-widelink

Allow clients to follow absolute symbolic links outside of this share, subject to Windows NT security. This feature requires an entry in the /etc/symlink.translations file and it requires that the client supports Microsoft's Distributed File System (DFS).

-umask mask set

File mode creation mask for shares in qtrees with UNIX or mixed security styles. The mask is an octal value which determines the initial permissions setting of a newly created file.

-novscan Do not perform a virus scan when clients open files on this share.


-novscanread Do not perform a virus scan when clients open files on this share for read access.

-no_caching Disallow Windows clients from caching any files on this share.

-auto_document_caching Allow Windows clients to cache user documents on this share. The actual caching behavior depends upon the Windows client.

-auto_program_caching Allow Windows clients to cache programs on this share. The actual caching behavior depends upon the Windows client.

Oplocks

This specifies that the share uses opportunistic locks, also known as client-side caching. Oplocks are enabled on shares by default; however, some applications do not work well when oplocks are enabled. In particular, database applications such as Microsoft Access are vulnerable to corruption when oplocks are enabled. An advantage of shares is that a single path can be shared multiple times, with each share having different properties. For instance, if a path named /dept/finance contains both a database and other types of files, you can create two shares to it, one with oplocks disabled for safe database access and one with oplocks enabled for client-side caching.

Browsable This specifies that the share can be browsed by Windows clients. This is the default initial property for all shares.

Showsnapshot This specifies that Snapshot copies can be viewed and traversed by clients.

3.4.2 Join Active Directory from NetApp Storage as a Windows Member Server

HANDS-ON EXERCISE: Joining Active Directory

Prerequisite: DNSSETUP.BAT,

NTPTIME.BAT

Either perform the follow steps, or to automate the task, execute: CIFSJOIN.BAT. Then, proceed to section 3.4.3 – Verifying Successful CIFS Installation

Performed from W2003 or W2008

First, make sure the domain controllers are not hidden, use the following command on each Windows 200x Server:

SERVER> net config server /hidden:no

The following checklist provides the steps that should be followed to install NetApp storage into an Active Directory domain. It’s outside the scope of this paper to explain each step in detail. However, information and guidance on joining NetApp storage to an Active Directory domain are in the guide “Best Practices for File Installation in an Active Directory Domain.”


From Windows Domain Controller

1. Determine mixed or native mode Active Directory domain style. (Click Start, Programs, Administrative Tools, Active Directory Users and Computers. Right click the domain name, select ‘Raise Domain Functional Level’ The GUI will display the current domain functional level, and provide the opportunity to raise the level.)

2. Retrieve Active Directory domain name. (Click Start, Programs, Administrative Tools, Active Directory Users and Computers. The domain name is displayed.)

3. If using Windows Internet Naming Service (WINS), retrieve the server address(es). 4. Retrieve NetApp storage account location in AD. ‘NetApp storage’ is used for the OU

in this document. 5. Make sure DNS is configured properly for Active Directory support. You should have

both Forward and Reverse Lookup Zones configured, and the NetApp storage host “A” recorded added.

6. Retrieve DNS name server IP address. From the Windows Console, you can type IPCONFIG /ALL

7. Determine which Microsoft sites are defined. (Click Start, Programs, Administrative Tools, Active Directory Sites and Services. NetApp storage will determine this automatically, and display found sites to select from during the CLI setup. If you use the CIFS Wizard, the default site is used. For this lab, we will use the site: San-Diego

From NetApp Storage

1. Verify the licenses on the NetApp storage: FAS1> license Verify that both a CIFS and NFS license have been installed. If not, download an evaluation license from the NOW.NetApp.com website.

2. Check version of Data ONTAP and update if necessary: FAS1> version

3. Get NetApp storage Windows (NetBIOS) name: FAS1> hostname

4. Set time services on the NetApp storage and perform a manual synchronization. Set options.timed: FAS1> rdate W2003 (Refer to steps in section 2.3.5 to schedule automatic time synchronization.)

5. Make sure you have domain administrator privileges in Active Directory.

6. Configure DNS on the NetApp storage: FAS1> options dns.domainname demo.netapp.com FAS1> options dns.enable on

7. From the CLI, FAS1> cifs setup Select the option to join Active Directory (option 1). Answer the questions with the information provided in the previous steps. Otherwise precreate the NetApp storage object in the correct OU so that the FilerView CIFS wizard will not place the object in the Computers OU.

a. In the Active Directory Users and Computers View menu, make sure that the Advanced Features menu item is checked.

b. In the Active Directory tree, locate the OU for your NetApp storage, right-click, and choose New > Computer.

c. Enter the NetApp storage name (FAS1).


d. Specify the name of the NetApp storage administrator account to be allowed to "add this computer to the domain.“

e. Right-click the computer account you just created and choose Properties from the pop-up menu.

f. Click the Security tab.

g. Select the user or group that will add the NetApp storage to the domain.

h. In the Permissions list, make sure that the following check boxes are enabled: "Change Password" and "Write Public Information.”

i. Run cifs setup. At the prompt "Please enter the new hostname," enter the NetApp storage name you specified in step C.

. Note: For additional information, from the CLI issue:

FAS1> man na_cifs_setup

3.4.3 Verifying Successful CIFS Installation HANDS-ON EXERCISE: Verify Successful CIFS Installation

Prerequisite: CIFSJOIN.BAT Either perform the follow steps, or to automate the task, execute: none


Verify AD join with NetApp CIFS. To verify that CIFS setup has successfully joined the NetApp storage to your Active Directory domain, type the following on the NetApp storage command line:

FAS1> cifs domaininfo, or

FAS1> cifs sessions, or

FAS1> priv set advanced

FAS1*> registry walk auth

FAS1*> priv set

You should see the following items in the output listed below:

• A successful registration into a Windows 2000 domain, including the domain name

• A list of Windows Internet Naming Service servers (if defined)

• A currently selected domain controller for Kerberos authentication

Note: The “successful registration into a Windows 2000 domain” tag does not change if the domain controller is Windows 2003 or 2008.


3.4.4 NetApp Storage Windows (NetBIOS) Name NetBIOS aliasing is a feature in Data ONTAP that allows administrators to configure NetApp storage in such a way as to broadcast and register multiple NetBIOS names within a domain. The primary benefit of this feature is that it allows an organization to retain legacy Windows server names after physically retiring the legacy server. This feature can make migrating data an easy process because retaining legacy names within an environment maintains existing desktop shortcuts, links, and embedded paths intact.

Use the NetBIOS aliasing option when there are no share name conflicts and you have a small number of Windows servers whose names you still want to retain for client access purposes. NetApp recommends that you eventually create a DFS global namespace to mitigate the use of NetBIOS aliasing.

It is recommended that you keep the same name of the NetApp storage for both UNIX® and Windows environments for ease of administration.

For more information about NetBIOS aliases, see the Data ONTAP File Access and Protocols Management Guide at http://now.netapp.com/NOW/knowledge/docs/ontap/ontap_index.shtml.

Note: You can enter up to 200 NetBIOS aliases in the file, using either ASCII or Unicode characters. Each name can be no longer than 15 characters. If you are installing a NetApp cluster, the host name must be unique for each NetApp storage in the cluster.

HANDS-ON EXERCISE: NetBIOS Alias

Prerequisite: CIFSRUN.BAT Either perform the follow steps, or to automate the task, execute: BIOSFOO.BAT. Then, proceed to step # 3


If you need to add a NetBIOS alias to the NetApp storage:

1. Edit /etc/cifs_nbalias.cfg

2. If CIFS is already running on the NetApp storage, map a drive to \\FAS1\C$ to \etc\cifs_nbalias.cfg, otherwise

Follow the steps to create a new cifs_nbalias.cfg file:

a. FAS1> priv set advanced

b. FAS1*> java netapp.cmds.jsh

c. FAS1*> rdfile /etc/cifs_nbalias.cfg

d. FAS1*> cp /etc/cifs_nbalias.cfg /etc/cifs_nbalias.cfg.original

e. FAS1*> wrfile /etc/cifs_nbalias.cfg

<Add one NetBIOS name per line>

FOOBAR

Ctrl+C to end file


A message will display stating: “read: error reading standard input: Interrupted system call” After you create the file, you can view the contents with the command.

f. FAS1*> rdfile /etc/cifs_nbalias.cfg g. FAS1*> exit h. FAS1*> priv set

3. FAS1> cifs nbalias load

4. FAS1> cifs nbalias

Note: When creating a name for the NetApp storage in an Active Directory domain the NetBIOS name you select will be appended with the DNS name.

3.4.5 Manage the CIFS Shares from the CLI and Microsoft Management Console

A Microsoft Windows administrator can create and manage a share on a storage system by using the Microsoft Computer and Users Microsoft Management Console snap-in or by using the CLI command ‘useradmin’ covered in section 4.2.5.

Connecting Microsoft Management Console to the Storage System

You can connect the Microsoft Management Console to the NetApp storage system using the Microsoft Management Console menu commands.

Steps:

1. On your Windows server, go to the Microsoft Management Console.

For example, choose Run from the Start menu; then enter the following command: mmc

2. On the left panel, select Computer Management.

3. From the Action menu, choose “Connect to another computer.”

4. The Another Computer box appears.

5. Type the name of the storage system or click Browse to browse for the storage system.

6. Click OK.

7. Management options available: a. Create a share on the storage system b. Create a local group on the storage system c. Add users to or remove them from a local group d. Manage the CIFS sessions on the storage system


3.4.6 Qtree Implementation Within a volume you have the option of creating qtrees to provide another level of logical file systems. Qtrees support a sophisticated file and space quota system that you can use to apply soft or hard space usage limits on individual users, or groups of users.

A maximum of 4,995 qtrees, which is 4,995 virtually independent file systems, are supported per volume.

You can create a qtree to assign user- or workgroup-based soft or hard usage quotas to limit the amount of storage space that a specified user or group of users can use on the qtree to which they have access.

In general, qtrees are similar to flexible volumes. However, they have the following differences:

• Snapshot copies can be enabled or disabled for individual flexible volumes, but not for individual qtrees.

• Only qtrees support quota management.

• Qtrees do not support space reservations or space guarantees.

Using Qtrees for Projects

One way to group files is to set up a qtree for a project, such as one maintaining a database. Setting up a qtree for a project provides you with the following capabilities:

Set the security style of the project without affecting the security style of other projects.

For example, you use NTFS-style security if the members of the project use Windows files and applications. Another project in another qtree can use UNIX files and applications, and a third project can use Windows as well as UNIX files.

If the project uses Windows, set CIFS oplocks (opportunistic locks) as appropriate to the project, without affecting other projects.

For example, if one project uses a database that requires no CIFS oplocks, you can set CIFS oplocks to Off on that project qtree. If another project uses CIFS oplocks, it can be in another qtree that has oplocks set to On.

Use quotas to limit the disk space and number of files available to a project qtree so that the project does not use up resources that other projects and users need.

Back up and restore all the project files as a unit.

Creating a Qtree

To create a qtree, complete the following step. FAS1> qtree create path

path is the path name of the qtree. If path does not begin with a slash (/), the qtree is created in the root volume.

Note: If you want to create the qtree in a volume other than the root volume, include the volume in the name.


Determining the Status of Qtrees

To find the security style, oplocks attribute, and SnapMirror® status for all volumes and qtrees on the NetApp storage, or for a specified volume, complete the following step.

FAS1> qtree status [-i] [path]

The -i option includes the qtree ID number in the display.

FAS1> qtree stats [ -z ] [ path ]

The -z option clears the counter for the designated qtree, or clears all counters if no qtree is specified.


3.4.7 Create Users’ Home Directories Creating directories in a home directory path (domain-naming style):

HANDS-ON EXERCISE: Users’ Home Directories

Prerequisite: CIFSRUN.BAT,

SHARESETUP.BAT

Either perform the follow steps, or to automate the task, execute: HOMEDIR.BAT. Then, proceed to step #7


The following steps will create the aggregate, volumes and shares which will be used for the users home directories. These steps are included in the SHARESETUP.BAT file, and are included here for your reference.

FAS1> aggr create CIFSDEMO -t raid_dp 5

FAS1> vol create DATA CIFSDEMO 1g

FAS1> vol create HOMEDIR CIFSDEMO 1g

FAS1> vol create BOOKS CIFSDEMO 1g

FAS1> vol create PROFILE CIFSDEMO 1g

FAS1> vol create REDIRECT CIFSDEMO 1g

FAS1> snap reserve DATA 0

FAS1> snap reserve HOMEDIR 0

FAS1> snap reserve BOOKS 0

FAS1> snap reserve PROFILE 0

FAS1> snap reserve REDIRECT 0

FAS1> vol options DATA create_ucode on

FAS1> vol options HOMEDIR create_ucode on

FAS1> vol options BOOKS create_ucode on

FAS1> vol options PROFILE create_ucode on

FAS1> vol options REDIRECT create_ucode on

FAS1> vol options DATA convert_ucode on

FAS1> vol options HOMEDIR convert_ucode on

FAS1> vol options BOOKS convert_ucode on

FAS1> vol options PROFILE convert_ucode on

FAS1> vol options REDIRECT convert_ucode on


FAS1> snap sched DATA 0 0 0

FAS1> snap sched HOMEDIR 0 0 0

FAS1> snap sched BOOKS 0 0 0

FAS1> snap sched PROFILE 0 0 0

FAS1> snap sched REDIRECT 0 0 0

FAS1> vol options DATA guarantee none

FAS1> vol options HOMEDIR guarantee none

FAS1> vol options BOOKS guarantee none

FAS1> vol options PROFILE guarantee none

FAS1> vol options REDIRECT guarantee none

FAS1> cifs shares -add DATA /vol/DATA

FAS1> cifs shares -add HOMEDIR /vol/HOMEDIR

FAS1> cifs shares -add BOOKS /vol/BOOKS

FAS1> cifs shares -add PROFILE /vol/PROFILE

FAS1> cifs shares -add REDIRECT /vol/REDIRECT

FAS1> options wafl.default_security_style ntfs

FAS1> qtree security /vol/DATA mixed

FAS1> qtree security /vol/HOMEDIR mixed

FAS1> qtree security /vol/BOOKS mixed

FAS1> qtree security /vol/PROFILE mixed

FAS1> qtree security /vol/REDIRECT mixed

SERVER> net use u: \\FAS1\data /persistent:no

SERVER> net use v: \\FAS1\homedir

SERVER> mkdir u:\TEMPLATES

SERVER> mkdir v:\Fred

SERVER> mkdir v:\Wilma

SERVER> net use u: /delete /yes

SERVER> net use v: /delete /yes

REM The following section sets the permissions on each share

SERVER> cscript C:\CIFSDEMO\xcacls.vbs m:\ /g "demo\Administrator:F;F" "Everyone:F;F" /SPEC B /Q

SERVER> cscript C:\CIFSDEMO\xcacls.vbs n:\ /g "demo\Administrator:F;F" "Everyone:F;F" /SPEC B /Q


SERVER> cscript C:\CIFSDEMO\xcacls.vbs o:\ /g "demo\Administrator:F;F" "Everyone:F;F" /SPEC B /Q

SERVER> cscript C:\CIFSDEMO\xcacls.vbs p:\ /g "demo\Administrator:F;F" "Everyone:F;F" /SPEC B /Q

SERVER> cscript C:\CIFSDEMO\xcacls.vbs q:\ /g "demo\Administrator:F;F" "Everyone:F;F" /SPEC B /Q

Why Use CIFS HOMEDIR:

If you are a SysAdmin with a large number of users and you want each of them to have a home directory, there are a couple of ways to go. You can create a separate share for each of your users. But that would be time consuming and puts stress on the NetApp storage. The method used by many customers is to make use of the NetApp storage CIFS Home Directory feature.

CIFS Home Directories work like this

The sysadmin specifies one or more paths to be used by the NetApp storage to resolve the location of user CIFS homedirs. Suppose there is one path, /vol/HOMEDIR. Now user “Fred” connects to the NetApp storage. If the directory /vol/HOMEDIR/Fred exists, then that is Fred’ homedir. If it does not exist, then Fred has no CIFS homedir. If there is more than one path, the NetApp storage checks them in sequence and assigns the user CIFS homedir as soon as it finds a match on the directory name.

What a CIFS homedir looks like to the user

When a user browses to the NetApp storage in a GUI they will see a share with their name on it. For example, user Fred will see a share “Fred”. User Wilma will see a share called “Wilma”. Neither of them will see the other's homedir share. If you list out the NetApp storage shares you will not see “Fred” or “Wilma”. The CIFS homedir shares are visible only to their users.

If the CIFS.home_dir_namestyle option is domain, you can create home directories by editing the /etc/CIFS_homedir.cfg, creating the directories, and setting the permissions on the directories.

Steps

1. From the Windows machine, map a drive to the NetApp storage C$ share, i.e.

SERVER> net use T: \\FAS1\c$

2. We will create a home directory for both Wilma and Fred in the HOMEDIR volume

Use Notepad.exe, and edit: T:\etc\CIFS_homedir.cfg

In the CIFS_homedir.cfg, add: /vol/HOMEDIR/ (We will use a volume called HOMEDIR to store the home directory for each user.)

3. The folders for Wilma and Fred need to be created in the HOMEDIR volume.

Make each user the owner of his or her home directory.


1. SERVER> Select Programs, Administrative Tools, Active Directory Users and Computers.

2. Select the desired user(s). 3. Right-click, select Properties. 4. Select the Profile tab. 5. In the “User Folder” section, select “Connect.” Assign a drive letter, for example,

Z, and the path to the users’ home directory. You can use the wildcard option. Example of a share named: HOMEDIR on vol0:

/vol/HOMEDIR/%u%

This will make Fred Flintstone the owner of the /vol/HOMEDIR/Fred directory and Wilma Flintstone the owner of the /vol/HOMEDIR/Wilma directory.

4. Load the new CIFS homedir configuration into the storage system.

For example, enter the following command: FAS1> cifs homedir load -f

5. Make sure that the CIFS homedir domain name style is working by entering the following command:

FAS1> cifs homedir showuser <user_name>

For example, enter one of the following commands: FAS1> cifs homedir showuser Fred FAS1> cifs homedir showuser Wilma

6. When completed, disconnect drive T: SERVER> net use T: /delete /yes

7. Testing the home directory mapping with Fred or Wilma SERVER> From the desktop, double click on the DEMO.MSC shortcut. This will allow you to remotely connect to the VISTA workstation. On the left colume of the MSC, expand ‘Remote Desktop’. Double-click on either ‘Connect as Fred’ or ‘Connect as Wilma’ Once connect, launch Explorer, and you will see a drive Z: connected to FAS1\<user name> Log off the Vista machine.

Additonal Options FAS1> options cifs.home_dirs_public_for_admins (default: on)

Allows Administrator to access other’s home directories

FAS1> options cifs.home_dirs_public (hidden option, default: off) Like the cifs.home_dirs_public_for_admin described above, but it applies to all users

FAS1> options cifs.home_dir_namestyle (see the next section)


Considerations for Heterogeneous Home Directory Environments

Data within users’ home directories is generally not shared out for other users’ access, except for possibly the same owner’s nonnative access. In most environments it is best to pick the domain and security style (UNIX or NTFS) and set that for the qtree where the users’ home directories reside. If any nonnative access is required, rely on the NetApp storage’s user mapping process to grant permissions to files within the user’s individual home directory. Mixed security could be used here, but it’s generally not advised unless the user has complete understanding and control over the data (from a permissions perspective).

Consider using cifs.home_dir_namestyle to specify how the name portion of the path to a user's home directory is determined. The following options are:

• Set this option to ntname if a user's Windows login name is to be used.

• Set this option to hidden when a user's Windows login name is used. However, users must append a dollar sign to their user names when connecting to the NetApp storage, and the NetApp storage will append a dollar sign to the user's name when enumerating the home directory share name.

• Set this option to mapped when the user's UNIX name is used. The UNIX name is obtained by mapping the user's Windows login name using the file /etc/usermap.cfg.

• Set this option to domain when the user's name includes both the user's domain and Windows login name separated by a slash.

• The default value for this option is the null string, which acts like ntname with the exception that symlinks are followed in any direction. To set this option to the default value (a null string), use a pair of double quotes ("") as the argument.

3.5 NETAPP TECHNICAL REPORT REFERENCE NetApp Storage Systems in a Microsoft Windows Environment – June 2008

http://media.netapp.com/documents/tr-3367.pdf

CIFS Support Matrix

http://now.netapp.com/NOW/knowledge/docs/olio/guides/ntsp.shtml

Sizing of CIFS-Based Home Directories – April 2007

http://media.netapp.com/documents/tr-3564.pdf (Internal)

File Access and Protocol Management Guide – Data ONTAP 7.2

http://now.netapp.com

Maximum Number of CIFS Shares per NetApp Storage

http://now.netapp.com/NOW/knowledge/docs/ontap/rel724/html/ontap/filesag/accessing/concept/c_oc_accs_limits_for_the_FAS6000_series_storage_systems.html#c_oc_accs_limits_for_the_FAS6000_series_storage_systems


Data ONTAP Man Pages

You can use the Data ONTAP manual (man) pages to access technical information. They are grouped into sections according to standard UNIX naming conventions.

• By entering the following command at the storage system command line:

FAS1> man command_or_file_name

• By clicking the manual pages button on the main Data ONTAP navigational page in the FilerView user interface

• By using the Commands: Manual Page Reference, Volumes 1 and 2 (which can be downloaded or ordered through the NOW site)

Note: All Data ONTAP man pages are stored in the storage system in files whose names are prefixed with the string "na_" to distinguish them from client man pages. The prefixed names are used to distinguish storage system man pages from other man pages and sometimes appear in the NAME field of the man page, but the prefixes are not part of the command, file, or services.


4 SECURITY

4.1 OVERVIEW NetApp storage is designed to be capable of operating in both UNIX and CIFS networking environments. One of the goals of the storage design is to allow pure UNIX and pure CIFS sites to work transparently in "native" mode without the worry of other client types. Whenever possible, using only native security for NetApp storage clients results in an easier administration job. However, many sites have a need for multiprotocol support, which often introduces the need for both client types to be able to access the same files.

The NetApp approach is to simultaneously support multiple security models. One concept that is common to all security models is the notion of a user, which makes that an intuitive choice for bridging the different models. When a user wants to access a file which has "nonnative" security the user's mapped identity is used to validate the access.

User security on NetApp storage is divided into three categories.

4.1.1 Infrastructure Security

Security engineering functions to provide preventative actions and solutions to interruptions to business functions resulting from known risks and incidents. The definition of a security disaster, then, is any breach that causes an extended disruption of business functions. A security disaster has low probability of happening due to the use of layered security measures.

Some high-level security requirements are given below:

Performance: Consistent and predictable performance measured and revealed with the introduction of perimeter or layer security when compared with documented and later measured application response time.

Resiliency: Security solutions shall not change the availability of authorized data delivery. The solution should be resilient if high availability is required. Application performance should be maintained according to SLA during as-built security component layer outage. Systems should be designed and managed so that in the event of breakdown or compromise the least possible damage and inconvenience is caused.

Scalability: The system should scale as business expands to add new functionality and applications without significant investment, redesign, or downtime.

Accountability: Security solution shall be securely designed, monitored, and audited to protect NetApp’s intellectual property and systems. Security system should secure against random and determined attacks that aim to degrade NetApp communications and applications. All significant system and process events should be traceable to the originator. An independent expert has the ability to verify that the system conforms to the security policy. Systems must be able to record security related events in a tamper-proof audit log.

Exceptions: Policy exceptions should always have senior management approval and be recorded for audit trail. During emergency and maintenance, controls must only be by-passed in predetermined and secure ways. Procedures and controls to minimize the level of risk during exceptions caused by maintenance or incident management.

Security Automation: Simple, fast, and reliable automatic controls should be used when possible rather than administrator management dependent on human schedule and vigilant.


Layered Defense: Controls should follow defense in depth or layered such that if one layer of control should fail, there is another different type of control at the next layer that will prevent a security breach. Controls should still be effective even if an opponent knows of their existence and mode of operations.

4.1.2 File-Level Security Customers are becoming more concerned about the higher threat of intellectual property theft, and much of that threat comes from internal sources that already have some level of access to the systems. Domain administrators (and users that map to root) have traditionally been able to reset security permissions in any way they choose. This potentially gives an administrator the ability to take ownership of a file or directory and remove permission constraints against them, and potentially remove auditing settings as well.

Storage administrators would like to have the ability to set a minimum level of security or auditing that cannot be revoked from a client, even by an administrator. NetApp’s new level of security, named Storage-Level Access Guard, is designed to be set on a storage object, currently a qtree or a volume.

With this feature in place, any storage object can contain up to three pieces of security:

NTFS, UNIX, and NFSv4 security (Normal file-level security)

Applies to the directory representing the storage object; this is the same security that you would otherwise set from the appropriate client.

Storage-Level Access Guard file security

Applies to every file within the storage object, and may only be set using tools provided by NetApp. This will not affect access to or auditing of directories in any way.

Storage-Level Access Guard directory security

Applies to every directory within the storage object, and may only be set using tools provided by NetApp. This will not affect access to or auditing of files in any way.

The fact that there are two Storage-Level Access Guard security descriptors is an internal design detail. They will look like a single security descriptor in the definition file.

The security style used for client communication can be set at a volume or qtree level. Most administrators will choose to designate specific sections of a NetApp storage volume as an NTFS qtree, a UNIX qtree, or a mixed qtree. (A qtree is simply a designated subtree within a NetApp storage volume.) Placing similar types of data in separate qtrees, volumes, or flexible volumes will make security configuration simpler. The security style determines what permissions are applied to files and directories in that qtree, volume, or flexible volume. For any given file or directory, one (and only one) security style is in effect at a time.

• The NTFS security style is based on ACLs. To a Windows client, this security model behaves exactly like an NTFS file system on a Windows file server and is more natural for Windows users.

• The UNIX security style is based on UNIX permissions. To an NFS client, this security model behaves exactly like a UNIX NFS server and is more natural for UNIX users. It should be noted that the default security type set on a new volume or qtree is UNIX by default. The default security style on newly created volumes can be changed by setting the following NetApp storage option: FAS1> options wafl.default_security_style unix


• The mixed security style is determined on a file-by-file basis (not qtree). Files created by Windows users get Windows NT ACLs, and files created by UNIX users get UNIX permissions. A file's security style may be changed from one style to another by NFS set attribute (i.e., chown, chmod) or Windows NT set ACL (i.e., Security tab in Explorer) requests, assuming that the requestor has the appropriate permissions. This style is ideal for users who actively use both Windows and UNIX and want access to both styles of security.

4.1.1 Communication Security NetApp storage systems can operate in Windows workgroup mode or Windows domain mode. Workgroup authentication allows local Windows client access and does not rely on a domain controller. In domain authentication, the client negotiates the highest possible security level when a connection to the storage system is established. There are two primary levels of security that can be chosen:

• Basic security, based on such as Windows NT LAN Manager (NTLM) or NTLMv2

• Extended security using Windows 2000 Kerberos implementation

By default, Windows Vista, Windows 2003, Windows XP, and Windows 2000 computers that are part of an Active Directory domain try to use Kerberos authentication first and then NTLM-based authentication. Windows NT 4.0, Windows NT 3.x, and Windows 95/98 clients always authenticate using NTLM-based authentication.

Data ONTAP includes native implementations of the NTLM and Kerberos protocols and thus provides full support for the Active Directory and legacy authentication methods.

Kerberos Communication

The Kerberos server, or Kerberos Key Distribution Center (KDC) service, stores and retrieves information about security principles in the Active Directory. Unlike the NTLM model, Active Directory clients that want to establish a session with another computer, such as a storage system, contact a KDC directly to obtain their session credentials.

Using Kerberos, clients (users) contact the KDC service that runs on Windows 2000, Windows 2003, or Windows 2008 domain controllers. The client asks for the admission to the TGT (Ticket Granting Ticket) for the domain. This is an authentication service exchange between the Kerberos SSP and the KDC on the user’s domain (KRB_AS_REQ and KRB_AS_REP). The result is a TGT that the client can use to request session keys to services.

The client uses the TGT to ask for admission to the NetApp storage system’s domain. This is a TGS exchange between the Kerberos SSP on the computer and the KDC for the computer’s account domain. The result is a session ticket that the client can present when requesting access to the system services on the computer. Clients then pass the authenticator and encrypted session ticket to the storage system.

Windows NT LAN Manager Communication

Using NTLM, the NetApp storage system contacts the Windows NT 4.0 or Windows 2000 mixed-mode domain controller to verify a user’s supplied credentials, consisting of username, challenge sent to the client, and response received from the client. The domain controller retrieves the user’s password from the Security Account Manager database and uses it to encrypt the challenge. The domain controller then compares that encrypted challenge with the response computed by the


client. If these are identical, the NTLM authentication is successful. Then the domain controller sends the response back to the storage system for successful authentication, and the storage system allows the user to access the file system based on the access permissions.

Minimum Session Security for NTLM Communication

Session security for NTLM authentication determines which challenge/response authentication protocol is used for net logons. There are five levels to negotiate the challenge/response through the “option cifs.LMCompatibilityLevel <level>”:

Level 1: accept LM, NTLM, NTLMv2 session security, NTLMv2, Kerberos (default) Level 2: accept NTLM, NTLMv2 session security, NTLMv2, Kerberos Level 3: accept NTLMv2 session security, NTLMv2, Kerberos Level 4: accept NTLMv2, Kerberos Level 5: accept Kerberos only

SMB Signing Support

Data ONTAP supports Server Message Block (SMB) signing when requested by the client. SMB signing helps to make sure that network traffic between the storage system and the client has not been compromised by preventing “man in the middle” attacks.

When SMB signing is enabled on the storage system, it is the equivalent of the Microsoft network server policy “Digitally sign communications (if client agrees).” It is not possible to configure the storage system to require SMB signing communications from clients, which is the equivalent of the Microsoft network server policy “Digitally sign communications (always).” SMB signing is disabled by default on the storage system for performance reasons. To enable it, turn the options cifs.signing.enable on.

Most Windows clients negotiate SMB signing by default if it is enabled on the server. When SMB signing is enabled, all CIFS communications to and from Windows clients incur a significant impact on performance, which affects both the clients and the server (the storage system running Data ONTAP). The performance degradation shows as increased CPU usage on both the client and the server, although the amount of network traffic does not change.

Depending on your network and your storage system implementation, the performance impact of SMB signing can vary widely and can be verified only through testing in your network environment. If you require SMB protection for some of your Windows clients, and if SMB signing is causing performance issues, you can disable SMB signing on any of your Windows clients that do not require protection against replay attacks.

LDAP Signing and Sealing Support

Signing Lightweight Directory Access Protocol (LDAP) traffic guarantees that the packaged data comes from a known source and that it has not been tampered with. Sealing is the encryption of all the LDAP traffic. Beginning with Data ONTAP 7.0.1, LDAP signing and sealing are supported on NetApp storage systems.

SSH Communication

Secure Shell is a security protocol for logging into a remote server. SSH provides an encrypted session for transferring files and executing server programs. Also serving as a secure client/server connection for applications such as database access and e-mail, SSH allows SSH clients to log into the NetApp storage without being prompted for a password, which is useful for running scripts and scheduled jobs.


4.1.2 File Policy (FPolicy) The NetApp FPolicy feature allows you to create file policies that specify file operation permissions according to file type. For example, you can restrict certain file types, such as .jpg and .mpg files, from being stored on the storage system.

A file policy determines how the storage system handles requests from individual client systems for operations such as open, rename, create, and delete. The storage system maintains a set of properties for a file policy, including, for example, the policy name and whether that file policy is active. You can set these properties for a file policy using storage system console commands.

The Data ONTAP file screening policy is set on the storage system, and specifies the types of files you want to screen.

File screening in Data ONTAP can be enabled in two ways:

• Using third-party file screening software. The file screening software runs on a client that functions as a file screening server. File screening software provides flexible control and filtering of file content.

Note: For optimal performance, it is strongly recommended that the FPolicy server be configured on the same subnet as the storage system.

• Using native file blocking. The file screening software runs natively on the storage system. Native file blocking provides simple denial of restricted file types.

Job Definition File Format

The job definition file, which is used for providing security descriptors and paths, can be in either UTF8 or Unicode file format representing an entire job with one or more subtasks. The security definition format is defined as follows:

security_type,security_level,security_target_object_path,propagation_mode,security_definition

security_type: 1 = NTFS security

security_level: 0 = file/directory-level security; 1 = storage-level security

propagation_mode: (Ignored for storage-level security)

4.1.3 Role-Based Access Control (RBAC) Role-based access controls is a method for managing the set of actions that a user or administrator may perform in a computing environment.

In addition to file access, there are other actions that should be managed for security reasons. For example, only the system administrator should be allowed to add new user accounts to the system. From this it becomes clear that the users who access a system fall into at least two categories, or roles: administrators and nonadministrators.

Role-based access controls solve this management problem by allowing you to define sets of capabilities (roles) that are not assigned to any particular user. Users are assigned to groups based on their job functions, and each group is granted the set of roles required to perform those functions. Using this method, the only configuration required for an individual administrator is to make sure that that administrator is a member of the appropriate groups; that administrator will inherit all the correct capabilities because of the group membership and the roles assigned to those groups.


In Data ONTAP 7G, you can use the useradmin role add or useradmin role modify commands to define and modify the capabilities of roles that can be assigned to a group. For example:

FAS1> useradmin role add myrole -a cli-vol*

This would give a group with the role “myrole” access to all commands in the VOL subset. The “cli” option grants the specified role the ability to execute one or more Data ONTAP command line interface (CLI) commands.

• cli-* grants the specified role the capability to execute all supported CLI commands. • cli-cmd* gives the specified role the capability to execute all commands associated with

the CLI command cmd.

Note: Users with CLI capability also require at least one login capability to execute CLI commands.

Putting It All Together

Users are members of groups, groups have one or more roles, and each role grants a set of capabilities. In this way Data ONTAP allows you to create flexible security policies that match your organizational needs.

All configuration for role-based access controls occurs using the useradmin command provided by Data ONTAP. For example, users are added or modified with the useradmin user add or useradmin user modify commands. Because users and domain users must be members of groups, and because groups must be assigned one or more roles, the best sequence for configuration tasks is to create the roles first; then create groups and assign roles to them; and finally create users and domain users, providing them with appropriate group membership.

4.2 MANAGING CIFS SECURITY WITH GROUPS (LOCAL AND GLOBAL) Groups are used to organize individual user or computer accounts. Mainly they are used for security purposes. Best practices dictate that most of your security administration should be done using groups. Groups simplify administration by allowing you to assign permissions and rights to a group of users rather than to each user account individually. They also remove the complexity of giving the same set of privileges again and again to new users when they are inducted into a specific set of rules. It’s also recommended that you give each group a name that describes the group’s function or purpose (for example, naming a group MrktInfo if the people in it are given access to marketing information).

The groups we are mainly interested in are the “security” groups. These are the groups you use to grant permissions to resources. For instance, if you want to grant users permissions to a network share, you would create a group, grant the group appropriate permissions to the share, and then add the users (or other groups) as members of that group. Windows 2000 Server and above provide the following three domain security group types:

• Domain local groups • Global groups • Universal groups


4.2.1 Domain Local Groups Do not confuse this type of group with regular “built-in local groups” (ones that reside locally on a Windows member server or NetApp storage). These groups can reside only inside a single domain (cannot cross domains) and only on domain controllers. They are typically used to grant permission to resources in that domain only. However, the members in the group can be from any domain (although this is not used much since domain local groups are not visible outside their own domain). Use domain local groups when you want to grant permissions to resources that exist within a specific domain. Domain local groups are useful in a multiple domain where you add a global group to a domain local group so you can access resources in another domain: "parent and child domains."

4.2.2 Global Groups These groups can grant permissions to objects located in many domains, and they are visible to all trusted domains as well. Global groups are group accounts at the domain level used to organize domain users. They can include only user and other group accounts in the same domain. Global groups cannot contain local groups or other global groups and are not assigned to local resources. Assigning resources is done by placing global groups within local groups on Windows NT workstations or standalone servers. The benefit of using global groups is that you can, on the domain level, assign users to a global group, and add the entire group to a local group already on a local computer. In other words, an administrator can change the domain user global group (for example, when a new hire comes in) without having to reset any permissions on a local workstation or server.

Global groups are most often used to organize users who share similar network access requirements. It is highly recommended that you implement global groups to contain users in a particular domain, especially if there is only one Active Directory domain. For environments with multiple domains you would still employ global groups but include them in universal groups.

The appealing thing about global groups is that they can be nested (only if your AD domain is in native mode, however). Nesting allows a global group to contain other global groups, which can simplify administration immensely. Using nested groups in Windows 2000 Server or above alleviates the old 5,000-member limit, but more importantly allows you to apply “most restrictive” and “most inclusive” nesting strategies to make administering resources easier. An example of this is a situation where all members of an organization need access to the same resource such as employee information. Not all members will have authority to view all employee information (for example, salary grade), and yet most will need access to office phone numbers and e-mail addresses. Simply create two global groups with different access rights and members and then nest them. The effect is a blend of the two that gives you the desired security and an easier administration model. There is no limit to the level of nesting that can be applied, but tracing permissions can become problematic and some applications (for example, backup) will drill down only so far.

Note: Groups created in Active Directory should be global groups most of the time, especially for user accounts.

4.2.3 Universal Groups Universal groups are similar to global groups. They can be used to assign permissions to related resources in multiple domains. The major difference is universal groups can contain user and group accounts from any trusted domain in the forest. Universal security groups are not available in mixed mode, only native mode. Universal groups can contain user accounts, universal groups, and global groups from any domain. Though it is possible to create universal groups in the Active


Directory with any domain structure, it is generally not required or recommended for single domain structures. Instead you should employ global groups because they use fewer resources.

By default the NetApp storage includes membership in nested groups and membership in universal groups from other domains in the forest. Using the following option controls this behavior:

FAS1> options cifs.universal_nested_groups.enable on | off

When cifs.universal_nested_groups.enable is off, the NetApp storage does not include membership in nested groups or membership in universal groups from other domains in the forest. The default is on. This option is pertinent to all NFS clients accessing a file or directory with Windows security and does not affect CIFS clients. Changes to the option take effect immediately, affecting all new NFS connections thereafter; it is not necessary to restart the CIFS. This option will be deprecated in a future release when the NetApp storage will always include the above memberships.

Note: All group memberships are retrieved from Active Directory only when (a) user and NetApp storage are in the same domain tree or (b) user's domain tree has a two-way transitive trust with the NetApp storage's domain tree.

4.2.4 Built-In (Nondomain) Local Groups These groups are not the same as domain local groups. A local group is a collection of user accounts on a computer. Use local groups to assign permissions to resources residing on the computer (or NetApp storage) on which the local group is created. You can add local users, global users, and global groups to local groups. However, you cannot add local users and groups to a global group.

Note: A maximum of 97 users are allowed to be defined per NetApp storage. This restriction was put in place by Microsoft. To add local users to the NetApp storage, you must use the NetApp storage useradmin command. In later versions of Data ONTAP you will be able to add users with the Microsoft Server Manager Microsoft Management Console snap-in.

4.2.4.1 Built-In Local Groups on NetApp Storage You can define a local group on the NetApp storage that consists of users or global groups from any trusted domains. Members of a local group can be given access to files and resources.

Membership in certain well-known local groups confers special privileges on the NetApp storage. For example, members of BUILTIN\Power Users can manipulate shares, but have no other administrative capabilities. You should not create your own local groups on member servers or the NetApp storage. It will make future migrations and server consolidations more difficult with transferring the proper security (SIDs) of the local group.

4.2.4.2 Guidelines for Creating Local Groups The following are guidelines for creating local user groups and their limitations compared to global user groups:

• Use local groups on computers that do not belong to a domain (for example, a workgroup). • Use local groups only on the computer on which they are created; this makes them very

inflexible.


• Although local groups are available on member servers and NetApp storage, do not use local groups on computers or NetApp storage that are part of a domain. This prevents you from centralizing group administration, which is the reason you went with a domain structure in the first place.

• Local groups do not appear in the Active Directory service, and you must administer them separately for each computer.

• You can assign permissions to local groups to access only the resources on the computer on which you create the local groups.

• You cannot create local groups on domain controllers because domain controllers cannot have a security database that is independent of the database in Active Directory.

• Local groups cannot belong to any other group.

Again, best practice dictates not creating local groups and just using the defaults. With respect to the NetApp storage you can use its local administrator group to add other members of the domain to it for administration purposes or for applications that require nondomain authentication (SnapDrive®, SnapManager® for Exchange, and so on). When a Windows NT workstation or standalone server or NetApp storage becomes a member of a domain, that domain's primary global groups (the users group and the administrators group) are automatically added to the local groups of the computer or NetApp storage that joins the domain. This is done by design but is not necessary.

Local users and groups is an important security feature because you can limit the ability of users and groups to perform certain actions by assigning them rights and permissions. For instance, you might want to authorize a user to perform certain actions on a computer, such as backing up files and folders. You could place a global group of users with backup duties inside the default local “Backup Operators” group on the NetApp storage. This would give that set of users the right to back up and restore files on the local system regardless of the permissions on the individual files.

4.2.5 Local NetApp Storage Groups The useradmin command is used to control NetApp storage access privileges. For each category of access grantee -- user, group and role -- privileges can be added or listed. The following definitions apply:

user

An authenticated person who can be placed into one or more groups.

domainuser

A nonlocal user who belongs to a Windows domain and is authenticated by the domain. This type of user can only be put into groups if CIFS has been set up. These users can only use their administrative capabilities using the ONTAP API RPC interface and cannot login using any other mechanism.

group

A collection of users and domain users that can be granted one or more roles.

role

A collection of capabilities.

capability

The privilege granted to execute commands or take other specified actions.


USAGE FAS1> useradmin user add login_name [-c comments] -g group1[,group2,...,groupN]

FAS1> useradmin user modify login_name [-c comments] [-g group1,group2,...,groupN]

“user add” and “user modify” are used to add and modify administrative users. The user name can be up to 32 characters long. The user name can contain any alphanumeric character, a space, or a punctuation character that is not one of:" * + , / : ; < = > ? [ ].

The -g requirement for add specifies which groups contain this user. A user inherits all the privileges of the groups he is in. This option completely replaces this user's current groups with the new ones.

The -c option specifies a comment about the user. Comments about the user should be no longer than 128 characters and should not contain the character “:” (colon).

When you add a user, you will be prompted to create the user's password and then verify it. A password is case-sensitive and defaults with the following restrictions:

• It must be at least 8 characters long (default, but can be changed).

• It must contain at least two alphabetic characters.*

• It must contain at least one digit.*

* If the setting of the security.passwd.rules.enable option is off, then the restrictions will not be enforced.

FAS1> useradmin user list [login_name ] [-g group_name ]

Useradmin user list displays all nonroot users if no user name is provided. Specifying a user name displays full information about that user. The -g groupname option displays all of the users in a particular group.

The user entries will each be printed in list format as follows:

Name: Barney

Info: This is a comment for Barney Rubble

Groups: audit

A single user extended format will be printed as follows:

Name: Barney

Info: This is a comment for Barney Rubble

Groups: audit

Full Name:

Rid: 131343

Allowed Capabilities: login-http-admin,api-snmp-get,api-snmp-get-next


The Info field is the comment (or the Windows NT user description), if any, entered for the user.

The Full Name field might exist if the user account was added using tools based on Windows.

The Rid is a unique integer associated with each user. This value is generated automatically by Data ONTAP when the user record is created.

The Groups field displays all of the groups this user is associated with.

The Allowed Capabilities field indicates this user's privileges. If a capability is Allowed, then the user can only use this capability. In this case, "fred" can log in using http and call the API functions snmp-get and snmp-get-next.

Capabilities

There are four categories of capabilities: login-*, cli-*, api-*, and security-*.

The “*” character is used similar to a wildcard, with a couple of restrictions: It must be used at the end of the capability. It must be used alone or in conjunction with one of the categories. If used with cli-, It must be used with the full name of the CLI command.

The login-* category includes logging in using login_telnet, login-console, login-rsh, login-ssh, and login-http-admin.

The cli-* category includes all of the commands that can be run after a user is logged in with telnet, console, rsh, or ssh. The format for this is cli-<command>*, which means allow all the commands and subcommands. (cli-<command> just means the command and NO subcommands.) The capability for a specific command, like exportfs, would have the following syntax: cli-exportfs* This means allow command line accesses to the exportfs command and all of its subcommands. cli-export* might look valid but is NOT allowed.

The api-* type includes all of the Data ONTAP API calls. These commands are only available using login-httpadmin, so in general, any api-* command must also include this login. The format for this is api-<ontap-api-command> which means allow a specific command/subcommand. Here, it is possible to list only subcommands, like api-system-get-info or a command and its subcommands, like api-systemget-*, or even api-system-*.

The security-* type currently only has a couple of elements:

• security-passwd-change-others which is used specifically to control if a user can change another user's password without knowing their previous password. By default, only root and members of the Administrators group have this capability.

• security-priv-advanced which is necessary to run advanced commands that are not used for normal administration. Please talk to a NetApp representative before using advanced commands. By default, only root and members of the Administrators group have this capability.

• security-load-lclgroups which is necessary to run the useradmindomainuser load command. This command changes all group membership. By default, only root and members of the Administrators group have this capability.


4.2.6 Multiple Protocol Access

4.2.6.1 Effects of Changing an NTFS-Only Storage System to a Multiprotocol System

Although you can change the storage system from NTFS-only to multiprotocol using CIFS setup, you can achieve the same effects more easily by simply setting the wafl.default_security_style option to unix.

The following list describes the effects of changing an NTFS-only storage system to a multiprotocol system:

• Existing ACLs remain unchanged.

• The security style of all volumes and qtrees remains unchanged.

• When you create a volume, its default security is unix.

• The wafl.default_security_style option is set to unix.

Note: Because the security style of the root volume remains NTFS after you change the storage system to multiprotocol, you might be denied access to the root volume when you connect from UNIX as root. You can gain access if the ACL for the root volume allows full control for the Windows user that maps to root. You can also gain access by setting the cifs.nfs_root_ignore_acl option to on.

Enhanced Multiprotocol Support

• Better support for UNIX permissions management in mixed security environments.

• Allows user to view and set UNIX permissions from the security tab in Windows Explorer, provided, the CIFS.preserve_unix_security option is enabled on the NetApp storage.

• UNIX permissions are mapped to hard-coded SIDs (referred to as Perm SIDs).

• Replaces the SecureShare® access tool to manage UNIX permission from Windows side.

• Setting separate umasks for directories and files using dir_umask or file_umask with the command cifs shares -add or cifs shares –change.

4.2.6.2 Effects of Changing a Multiprotocol Storage System to an NTFS-Only System

The following list describes the effects of changing a multiprotocol storage system to an NTFS-only storage system:

• If ACLs already exist on the storage system root directory (/etc) and on files in the /etc directory, the ACLs remain unchanged. Otherwise, these ACLs are created such that the BUILTIN\Administrators group has full control; any in the /etc/http directory are assigned "Everyone Read.”

• ACLs on other files and directories remain unchanged. • The security style of all volumes, except read-only volumes, is changed to NTFS. • If the /etc directory is a qtree, its security style is changed to NTFS. • Security style for all other qtrees remains unchanged.


• When you create a volume or qtree, its default security style is NTFS. • The wafl.default_security_style option is set to NTFS.

4.2.6.3 Effects of Changing the Storage System's Domain After you change the storage system's domain, Data ONTAP updates the membership of the BUILTIN\Administrators group to reflect the new domain. This change assures that the new domain's Administrators group can manage the storage system even if the new domain is not a trusted domain of the old domain.

4.2.7 Security Group Recommendations Microsoft recommends the following procedure for granting permissions across multiple domains:

1. Create a global group in each domain, and add the appropriate users as members. 2. Create a universal group and grant the appropriate permissions. 3. Add the global groups as members of the universal group.

If you have only a single domain structure, obviously you would simply use global groups (maybe domain local) and not necessarily universal groups.

In general, object permissions should be assigned to domain local groups, whereas user and computer accounts should be placed in global groups. Then these global groups can be (not necessarily) placed or nested in domain local groups to gain access to network resources. Note, however, that in order to place the global group in a domain local group, you will need to be running a native mode domain.

Ordinarily, if you are going to use domain local groups, you will use the built-in defaults and maybe create new ones if your environment requires it. The default ones should satisfy most of your requirements. One example might be a global group of users that have higher security requirements. You would add this global group to the domain local “Administrators” group.

4.3 CIFS File Security, and User Mapping The process of creating a CIFS cred from a UID, or a UNIX cred from a Windows account, always involves checking a user mapping file called /etc/usermap.cfg. The user mapping process allows a lot of flexibility, but it also must be used carefully because it is possible to create confusing scenarios.

It is important to note that it is not always necessary to have any entries in the usermap file. The default actions that take place when creating creds are adequate for many (if not most) situations. For reference, here are the steps for creating nonnative creds:

UID to CIFS Cred (NFS Request for File with NTFS-Style Security) Lookup numeric UID in /etc/passwd or NIS yielding UNAME Lookup UNAME in /etc/usermap.cfg yielding NTDOMAIN and NTNAME If NTNAME is null ("") access is denied


If UNAME is not matched in usermap.cfg If LDAP usermap option is enabled, try LDAP usermapping If LDAP usermap option is NOT enabled or LDAP usermapping failed set NTNAME equal to UNAME Lookup NTNAME in NTDOMAIN yielding NT_SID + GROUP_MEMBERSHIP_SIDs If NTNAME not found set NTNAME to wafl.default_nt_user

Note that in the last lookup step NTDOMAIN might be wildcarded, in which case NTNAME is looked for in all trusted domains (or in the domains listed in the CIFS.search_domains).

NTNAME to UNIX Cred (Performed Whenever CIFS Clients Log In) Lookup NTDOMAIN+NTNAME in usermap.cfg yielding UNAME If UNAME is null ("") access is denied If NTDOMAIN+NTNAME is not matched in usermap.cfg set UNAME to lowercased NTNAME Lookup UNAME in UNIX password database yielding UID + GROUP_IDs if UNAME not found If LDAP usermap option is enabled, try LDAP usermapping If LDAP usermap option is NOT enabled or LDAP usermapping failed set UID to wafl.default_unix_user If wafl.nt_priv_map_to_root option is set AND NT_GROUPS includes BUILTIN\Administrator set UID to 0 (root)

As can be seen, the default actions are adequate in many situations. However, there are situations where it is useful to be able to customize the mapping process with entries in the usermap.cfg file. Examples of this are where the user names are not the same in both client types, or where access must be controlled based on the client's IP address, or where the default domain mapping is not adequate.

Basic Usage

The usermap file consists of a series of entries that specify a pattern to match and a replacement to use when a match is found. Entries in the usermap.cfg file are one per line with this basic syntax:

NT_account direction UNIX_account

The "NT_account" is the name of a Windows NT domain account, "direction" is either:

"==" meaning bidirectional mapping "<=" meaning mapping from UNIX to Windows NT only "=>" meaning mapping from Windows NT to UNIX only or blank, which is the same as "=="

"UNIX_account" is the name of an entry found in the UNIX password database. "*" can be used to indicate wildcard entries. The pattern matches are done in the order they appear in the file. Here are some simple example entries:


# Sample usermap.cfg entries "Bob Garj" == bobg # NTNAME not same as UNAME mktg\Roy => nobody # allow mktg\Roy to login, but no unix privs, # assuming unix user 'nobody' exists but has no privs engr\Tom => "" # disallow NT login by engr\Tom uguest <= * # all unix names not yet matched map to NT user 'uguest' *\root => "" # disallow NT logins using the name 'root' # from all domains. These examples show several different ways the usermap.cfg file can be used to customize the mapping process. For a full description of all the details of setting up the /etc/usermap.cfg file, including restricting access based on client's IP address.

Note that it is possible to set up maps that result in confusing, but technically correct, behavior. To avoid that, you should try to follow these guidelines:

• Keep user names identical for both clients whenever possible. That avoids having to create individual entries in the map file.

• Mapping Windows NT user "Tom S" to UNIX user "tjs" and UNIX user "tjs" to Windows NT user "bill" will confuse everyone mightily. Avoid such maps.

• It is usually inadvisable to use IP qualifiers to map users differently. For example, if UNIX user "tjs" from UHOST1 maps to Windows NT user "Tom S" but "tjs" coming from UHOST2 maps to Windows NT user "Smith" things can get very confusing. Stick with using IP qualifiers to restrict access only.

4.3.1 Antivirus Management CIFS virus protection is a Data ONTAP feature that allows a virus-scanning computer running compliant antivirus applications to provide on-access virus scanning of files on a storage system. On-access virus scanning means that a file is scanned before a CIFS client is allowed to open it.

Note: From Data ONTAP 7.2 onward, Trend Micro 5.62 and above uses async scanning, this means the file is committed to the client before the vscan request is over.

The virus-scanning application watches for requests from the storage system. Whenever a file of any of the types that you specify is opened or changed on the storage system, Data ONTAP sends the Windows client a request to scan the file.

The Data ONTAP virus-scanning process can scan multiple storage systems from a single Windows client.

The NetApp antivirus solution uses an authenticated CIFS connection and RPCs to communicate with the antivirus scanning servers. CIFS provides a secure, authenticated connection and supports byte-range reads. The ability to perform byte-range reads streamlines the scanning process, resulting in quicker file access.

NetApp has partnered with Symantec, Trend Micro, McAfee, Sophos, and Computer Associates to deliver integrated antivirus solutions.

AV Compatibility Matrix on the NOW site:

http://now.netapp.com/NOW/knowledge/docs/olio/guides/avmatrix.shtml


4.3.2 Auditing Event Log and Audit policy settings are applied differently to storage systems than to Windows systems because the underlying logging and auditing technologies are different. Event Log and Audit GPOs are applied to storage systems by mapping and setting corresponding Data ONTAP options. The effect of mapping these options is similar but not identical to Event Log and Audit Policy settings. For more information, see Event Log and Audit Policy Mapping in the Data ONTAP administration manual, or refer to Section 3 of Auditing Quick Start Guide at http://media.netapp.com/documents/tr-3595.pdf.

NetApp integrates with third-party products for auditing support including Symantec™, NIE, and Varonis.

The following types of events are logged and displayed when auditing is enabled:

• Network logon

• Unsuccessful network logon

• Network logoff

• Windows file access

• UNIX file access

• Unsuccessful file access

• Lost record event

• Clear audit log event

NFS Auditing

NFS auditing refers to auditing access events for files and directories only from UNIX clients that access data on the storage system using the NFS protocol.

CIFS must be licensed and enabled on the storage system before enabling NFS auditing. Event auditing is turned off by default. To identify events for auditing, you must enable individual options and enable auditing.

Refer to Section 4 of Auditing Quick Start Guide at http://media.netapp.com/documents/tr-3595.pdf for detailed information.

CIFS Auditing

CIFS must be licensed and enabled on the storage system before enabling CIFS auditing.

The cifs audit save command saves the audit records stored internally by CIFS to a Windows NT OS–formatted file readable by the Windows NT Event Viewer application. The name of the file to which records are saved is specified by the cifs.audit.saveas option. If the file exists, it will not be overwritten unless the -f option is specified to force the save.

Audit/Logging Enhancements in Data ONTAP 7.2.1 and Above

• Full Support for NFS Audit

• Conversion of evt to txt format

o EvtToText utility produces text-format output


o Collapses some events into higher-level events (for example, runs of “read”)

o Versions based on Windows executable and Linux available

• Streamlined the audit captures, auditing precedence over performance in order to capture accurate information.

• The name of the audit log .evt file now reflects the timestamp of the first record in the file. This allows administrators to quickly locate the .evt file that covers a time period of interest.

• Added account management event auditing for NetApp storage local group and users.

• Added more Windows events IDs 517, 560, 563, 567, 612, 624, 630, 635, 637, 638.

Live View: Real-Time Display of Event Log file

In Data ONTAP 7.2, a new feature called Live View was added to CIFS auditing. This feature allows the user to use the Microsoft Event Viewer (a Microsoft Management Console snap-in) and connect to a storage system to retrieve the security audit records in real time. When the Live View feature is enabled, the EVT event log file is automatically saved and refreshed every minute, providing a continuous up-to-date view in Event Viewer of the 5,000 most recent audit events. The Live View feature also manages the log file, providing automatic backup to prevent newer events from overwriting older ones. For more information on configuring Live View, see Configuring Live View in the Administration guide.

If you do not enable Live View, you must manage the EVT event log yourself, either manually or by setting up automatic saving. Therefore Event Viewer can display only the most recently saved version of the log file contents, depending on how you manage the file.

Note: To use the Live View feature, your Windows client must be Windows 2000 or later.

4.3.3 Access-Based Enumeration Data ONTAP 7.2 and later releases provide storage system support for Access Based Enumeration, a shared resource security feature introduced in Microsoft Windows Server 2003 Service Pack 1. This feature allows administrators to control the display of folders and other shared resources according to a user's access rights.

Conventional share properties allow you to specify which users (individually or in groups) have permission to view or modify shared resources. However, they do not allow you to control whether shared folders or files are visible to users who do not have permission to access them. This could pose problems, if the names of shared folders or files describe sensitive information, such as the names of customers or new products under development.

Access-Based Enumeration extends share properties to include the enumeration of shared resources. When ABE is enabled on a CIFS share, users who do not have permission to access a shared folder or file underneath it, whether through individual or group permission restrictions. They also do not see that shared resource displayed in their environment. ABE therefore enables you to filter the display of shared resources based on user access rights.

Note: This feature required NetApp CIFS to be joined to an Active Directory domain running Windows 2003 SP1 or higher. ABE is a CIFS function, and has no affect on NFS mountpoints.


4.3.4 Secure Configuration of Data ONTAP Before designing or installing a NetApp storage system, you should perform a complete network assessment. A good network assessment looks at all parts of the proposed storage system, from physical cabling to protocols to current policies. The goal of the assessment is to provide detailed documentation to the design phase of the storage system. This is even more important when the storage system is being put into an existing network environment that was not designed with a storage system in mind.

• Interfaces

• Serves and data

• Protocols

• Existing access

Secure Storage Design

• Physical access

• Management access

• Logical design

• Protocol considerations

• Client access

Data ONTAP has many security-related options that should be properly set in a secure storage environment. Many of these options allow compliance with corporate security policies. NetApp strongly recommends that you use secure administration methods for Data ONTAP and that you disable any unsecure administrative protocols.

Client access to a secure storage system is vitally important. NetApp recommends the use of secure authentication and authorization in addition to the various protocol-dependent methods of secure data transfer.

4.4 BEST PRACTICES

4.4.1 Using FPolicy • FPolicy requires CIFS to be licensed and running, even in NFS-exclusive

environments. To apply file policies to NFS files, you must also have NFS licensed and running. These licenses are required regardless of whether you are using third-party screening software or native file blocking.

• File screening server. If you are using third-party screening software, FPolicy implementation requires a server with file screening software that is supported by Data ONTAP. You can check for client file screening software on the NetApp Partners Web page at www.netapp.com/partners.

The following limitations apply to FPolicy:

• Policies are applied to NFS and CIFS files only; policies will not be applied to files accessed by clients using other protocols.


• You can create and use up to 20 file screening policies at one time.

• Names for screening policies and policy types can have up to 80 characters.

File Screening Overview • File screening operations are set on a specified volume using the “fpolicy vol”

command.

• Using CLI, you can display or change the list of included and excluded volumes for screening.

• Native File Blocking.

• File screening software runs natively on the NetApp storage.

• Simple denial of restricted file types defined by the policies created on the NetApp storage.

• The enforcement is based solely on the file extension, not file contents.

• Works for vFiler storage as well.

• “fpolicy monitor” command used for setting the list of monitored operations for native file blocking.

You use file screening policies to specify files or directories with restrictions to be placed on them. Upon receiving a file operation request (such as open, write, create, or rename), Data ONTAP checks its file screening policies before permitting the operation.

• You can enable or disable file screening by setting the fpolicy.enable option to on or off, respectively.

• You can create a file policy using the fpolicy create command.

• You can enable a specific file policy using the fpolicy enable command.

• You can disable a specific file policy using the fpolicy disable command.

• You can delete a file policy using the fpolicy destroy command.

• You can display information for a specific file policy or all file policies by entering the appropriate command.

• You can use the fpolicy options command to require files to be screened before they can be accessed.

• You can enable the file policy with Data ONTAP default lists or you can specify lists of file extensions to include or exclude.

Screening by File Extension

The file policy specifies which files to screen using a list of file extensions to include for screening or to exclude from screening. From the command line, you can display or change the list of included and excluded file extensions.


Screening by Volume

The file policy can optionally specify a list of volumes on the storage system in which screening will take place or which will be excluded from screening. From the command line, you can display or change the list of included and excluded volumes.

Managing File Screening Servers

You can manage file screening servers by displaying file screening server status, designating secondary file screening servers, disabling the connection to a file screening server, and enabling native file blocking.

4.4.2 Antivirus Scanning Best Practices 1. Antivirus scanners typically do not require high-end servers. As a rule of thumb, 2GB of

RAM and a fast NIC with a 3 GHZ Xeon dual processor should work fine. Refer to page 5 of the Antivirus sizing Internal TR-3617i for further details.

2. Avoid large AV scanning farms with too many NetApp storage systems served by too many AV scanner servers. Instead, choose a “Pod design.”

3. Dedicate the AV scanner server for antivirus scanning and do not use this server for other jobs such as backup.

4. Connect the AV scanner server using NetApp storage over the IP address and not the NetApp Storage NetBIOS name.

4.4.3 Cross-Protocol File Access (CIFS and NFS) The CIFS security style can be set at a volume or qtree level. Most administrators will choose to designate specific sections of the NetApp storage volume as an NTFS qtree, a UNIX qtree, or a mixed qtree. (A qtree is simply a designated subtree within a NetApp storage volume.) Placing similar types of data in separate qtrees, volumes, or flexible volumes will make security configuration simpler. The security style determines what permissions are applied to files and directories in that qtree, volume, or flexible volume. For any given file or directory, one (and only one) security style is in effect at a time.

• The NTFS security style is based on ACLs. To a Windows client, this security model behaves exactly like an NTFS file system on a Windows NT file server and is more natural for Windows users.

• The UNIX security style is based on UNIX permissions. To an NFS client, this security model behaves exactly like a UNIX NFS server and is more natural for UNIX users. It should be noted that the default security type set on a new volume or qtree is UNIX by default. The default security style on newly created volumes can be changed by setting the following NetApp storage option: FAS1> options wafl.default_security_style unix

• The mixed security style is determined on a file-by-file basis (not qtree). Files created by Windows users get Windows NT ACLs, and files created by UNIX users get UNIX permissions. A file's security style may be changed from one style to another by NFS set attribute (i.e., chown, chmod) or Windows NT set ACL (i.e., Security tab in Explorer) requests, assuming that the requestor has the appropriate permissions. This style is ideal


for users who actively use both Windows and UNIX and want access to both styles of security.

Which Security Type Should I Select?

The first thing to realize is that regardless of which security style you choose, both UNIX and Windows clients will have access to the same data. The security style is the security scheme in effect for a file or directory, which controls who has access, not who can access. It really boils down to who can apply security to a file, not who can access a file. This is a large point of confusion since most administrators incorrectly assume that “mixed security” must be chosen to allow both UNIX and Windows clients access to data. In many cases there is no need to support access to the same files from both clients, and in such cases it is not necessary to worry about multiprotocol issues. In this way each client type sees a native view of security for their files. This can be accomplished on a single NetApp storage by creating separate volumes or qtrees with UNIX or NTFS qtree types, then exporting or sharing those directories to their respective clients.

System administrators should determine the dominant security style for a given qtree (or volume) using the following scenarios:

1. If a qtree (or volume) will be predominantly accessed by NFS clients, select the UNIX security style. Windows clients will still have access to this qtree/volume using the user mapping process for Windows NT to UNIX.

2. If a qtree (or volume) will be predominantly accessed by Windows clients, select the NTFS security style. UNIX clients will still have access to this qtree/volume using the user mapping process for UNIX to Windows NT.

3. If a volume or qtree is to be accessed by both NFS and Windows clients and each of the clients need full control over file access security, select the mixed style.

4.4.4 CIFS Auditing When you turn on auditing for NetApp storage, a performance hit will occur as you are turning on an extra feature. Essentially auditing has two distinct sections, one section covers checking the file SACL every time an operation is performed on the that file. The section basically determines whether the action on that file performed by a certain user should be audited. If the check finds that this access should be audited then an entry is placed in the queue. All this is done in WAFL. The second section is the ALF section which is a Daemon which basically collects all the data from the audit queue, adds some extra info and stores it.

The performance impact will be relative to the number/type of events being monitored, therefore turn on only the events you wish to audit rather than every event.

4.4.5 Converting Qtree Security Styles The security model for any qtree (or volume) can be changed using the qtree command. The syntax is: qtree security qtree [unix|ntfs|mixed].

When a UNIX qtree is converted to an NTFS qtree, shares are advertised as NTFS instead of FAT. The files themselves are not converted to Windows NT style files, so they still retain their UNIX permissions. Thus Windows NT requests will still be handled as nonnative requests. The owner(s) of these files can now set ACL on them, converting the files to Windows NT style. A Windows utility such as cacls.exe (Windows 2000 Resource kit) can do this automatically by


allowing ACL editing from within a Windows command shell. This can be useful for scripting large-scale security changes.

When an NTFS qtree is converted to a UNIX qtree, shares are advertised as FAT instead of NTFS, and any Windows NT ACLs in the qtree are simply ignored. The ACLs are not actually deleted, so if the qtree is converted back to NTFS, the ACLs will still be present. These files can now have UNIX permissions set on them, converting the files to UNIX-style files. This can be done using the chown command as root to change the existing owner and chmod command to set UNIX security attributes (rwx) on the file. It might be easier to write a script that runs as root and chowns and chmods each file. By virtue of running a chown or chmod on a file will delete any existing Windows NT ACL on a file. If an NTFS or mixed qtree is changed to UNIX, the permissions used will revert to a minimally permissive set such that the allowed permissions will be at least as strict as the ACL. Changing the qtree type should not be undertaken lightly since it has the potential to allow inadvertent changes to the underlying security.

4.4.6 NetApp Operations Manager: Report on Security, Performance, and Trends

NetApp Operations Manager (formerly DataFabric® Manager) delivers comprehensive monitoring and management for NetApp storage. From a central point of control, Operations Manager provides alerts, reports, and configuration tools to keep your storage infrastructure in line with business requirements, for maximum availability and reduced total cost of ownership (TCO).

Operations Manager overview:

• Operations Manager automatically discovers and monitors NetApp storage infrastructure. It enables management of multiple systems from a single console, helping reduce manual effort, complexity, and costs.

• Automated configuration management reduces manual effort and assures adherence to corporate standards.

• Centralized Asset management. • Detailed asset management reports provide information for improved resource and

capacity utilization. Also provides detailed performance monitoring, data characterization, trending, and storage utilization reports.

• Operations Manager generates infrastructure reports in relation to capacity utilization, performance management according to line of business.

• Storage chargeback based on either allocated or used capacity.

4.4.7 Access-Based Enumerations Limitations

• Users who are administrators will be able to see every file and folder in a share even with ABE enabled and even when they have Deny ACE on these items.

• ABE does not apply to users who can log on interactively to the server, regardless of whether they are administrators or not. This means ABE isn't really suitable for Terminal Services environments.

ABE is built into Windows Vista and 2008 Server platforms and is enabled by default and needs absolutely no configuration on those platforms. Therefore, a folder shared on a Vista machine will only show its contents to users who have permissions to access items within it.


4.5 DEMO

4.5.1 File Screening with FPolicy

File Screening

Enabling Native File Blocking

HANDS-ON EXERCISE: File Screening


SHARESETUP.BAT

Either perform the follow steps, or to automate the task, execute: FPBLOCK.BAT. Then, proceed to step #4


You can enable file screening to use native file blocking.

Enter the following command: FAS1> fpolicy servers show PolicyName

Data ONTAP returns the status of the file screening server(s) for the policy you specified.

1. Create a file policy.

Example: To create a policy to prevent CIFS users from placing MP3 files on the storage system, enter the following commands: FAS1> fpolicy create mp3blocker screen

FAS1> fpolicy ext inc set mp3blocker mp3

FAS1> fpolicy options mp3blocker required on

2. Set the operations and protocols monitored by the policy using the fpolicy monitor command.

Example: Specify the create option to prevent creation of MP3 files. In addition, to make sure that an MP3 file is not copied onto the storage system with a different extension and renamed, also specify the rename option. Enter the following command: FAS1> fpolicy monitor set mp3blocker -p cifs,nfs –f create,rename

3. Make sure that the new policy is enabled.

Enable the profile, -f forces it because there are no screening servers: FAS1> fpolicy enable mp3blocker -f

When a user tries to create or rename a file with an MP3 extension, the operation fails. They might see a message indicating that the operation cannot be completed or that access is denied.

4.

SERVER> net use T: \\FAS1\DATA

SERVER> Copy C:\CIFSDEMO\MP3\*.* T:\


SERVER> net use T: /delete /yes

Display the profile: FAS1> fpolicy show mp3blocker

To undo the FPolicy settings: FAS1> fpolicy disable mp3blocker

FAS1> fpolicy destroy mp3blocker

Designating Secondary File Screening Servers

You can use the FPolicy options command to designate a list of secondary servers to be used when the primary file screening server is unavailable.

Enter the following command:

FAS1> fpolicy options PolicyName secondary_servers IPaddr[,IPaddr,...]

This command configures a set of IP addresses. Any FPolicy server connecting from one of these IP addresses is classified by the storage system as a secondary server. Any FPolicy server not classified as a secondary is considered a primary server. The storage system never uses any secondary server as long as a primary server is available. If all primary servers are unavailable, the storage system uses any secondary servers connected to the storage system, until a primary server becomes available again.

For CIFS share level reporting, use "cifs shares."

For file level reporting, use "fsecurity show" (requires Data ONTAP 7.2.2 or above).

4.5.2 Storage-Level Access Guard Storage-Level Access Guard security provides a third type of security layer for a storage object:

• NTFS, UNIX, and NFSv4 security (native file-level security): Exists on any directory or file that represents a storage object. This is the same security that you can set from a client.

• Export (NFS) and share (CIFS) security: Applies to client accesses to a given NFS export or CIFS share.

• Can be managed by CIFS and NFS clients with administrative privileges.

• Storage-Level Access Guard:

o Applies to all accesses from all protocols to the storage object to which the Storage-Level Access Guard has been applied.


o Applies to all the files and/or all the directories in a storage object, although settings are maintained separately for files versus directories.

• File security:

o Applies to every file in the storage object. Does not affect access to or auditing of directories.

• Directory security:

o Applies to every directory in the storage object. Does not affect access to or auditing of files.

Note: At this time, only NTFS style access permissions are supported for Storage-Level Access Guard, but it can be applied to a UNIX security volume/qtree as well. For a UNIX user to perform a security check on a qtree or volume where Storage-Level Access Guard has been applied, the UNIX user must be mapped to a Windows user in a NetApp system. It doesn’t apply to an environment that is UNIX only, where CIFS is not enabled. In other words, if a UNIX user does not map to a Windows user in this situation, the NTFS style Storage-Level Access Guard will be ignored.

BEHAVIOR • Storage-Level Access Guard security applies to all files and/or directories in a

storage object, but is not inherited or propagated by them. If you view the security settings on a file or directory, you do not see the Storage-Level Access Guard security. It’s applied at the storage object level and stored in the metadata, used to determine the effective permissions.

• Volumes and qtrees are independent storage objects; Storage-Level Access Guard permissions are not inherited from a volume to any qtrees underneath.

• Access to a file or directory in Data ONTAP is determined by the combined effect of both the native permissions applied to files and/or directories and the Storage-Level Access Guard permissions set on qtrees and/or volumes. For CIFS/NFS client access, three levels of security checks are performed to determine effective permissions. The checks are performed in this order:

1) Storage-Level Access Guard permissions

2) CIFS share or NFS export-level permissions

3) NTFS file/folder access control lists (ACLs) or UNIX mode bits

All accesses must pass all levels of security checks.

• Storage-level security cannot be revoked from a client, even by a system (Windows or UNIX) administrator. It is designed to be modified by storage administrators only, which precedes the share/export permission and the Windows ACLs or UNIX mode bits.

• A qtree cannot be deleted unless Storage-Level Access Guard is removed from it.

• Qtree SnapMirror® does not propagate the Storage-Level Access Guard security descriptor with the data replication; volume SnapMirror does. NetApp recommends volume SnapMirror for replicating Storage-Level Access Guard security.

• Special dispensation for virus scanners and FPolicy servers; exceptional access is allowed to these servers to screen the files and folders, even if Storage-Level Access Guard denies access to the object.


• Special dispensation also applies to MultiStore environment for the storage objects owned by the virtual storage systems.

• Storage-Level Access Guard security checks have a small performance impact.

CONFIGURATION HANDS-ON EXERCISE: Storage-Level Access Guard


SHARESETUP.BAT

Either perform the follow steps, or to automate the task, execute: SLAG.BAT. Then, proceed to step #7

Performed from W2003, and VISTA

To apply Storage-Level Access Guard to a storage object, follow these steps:

1) Create a job definition file, using either a text editor or Storage Security Editor Tool (secedit.exe), a Windows tool provided by NetApp. The job definition file is a Unicode text file that contains various pieces of information such as security descriptors and paths.

2) SERVER> Start Active Directory Users and Computers GUI

1. Create a user in the ‘ldapusers’ context called Pebbles, full name: Pebbles Flintstone, password: netapp1

2. From a Windows machine, launch secedit.exe (C:\CIFSDEMO\secedit.exe)

3. Click Add, Change the option to ‘Apply to File/Directory’

NOTE: Normally you would select ‘Apply to Storage’ so that the permissions you set apply to all of FAS1, but we do not want to replace permissions which have been setup on other volumes.

4. For the path, specify the DATA volume (/vol/DATA), OK

5. Click Add, type: demo\Pebbles, OK

6. For Pebbles’ permissions, specify full control

7. Click Add, type: demo\Administrator

8. For Administrator permissions, specify full control

9. Click OK

10. Click ‘Save Unicode,’ and say YES to overwrites

11. Close secedit.exe

12. Rename ‘Untitled’ to ‘security-base.sec’

3) After creating the job definition file, copy it to a location on the storage system. There are no specific requirements for the name and location of this file.

4) SERVER> Net use T: \\FAS1\DATA

5) SERVER> Move C:\CIFSDEMO\security-base.sec T:\data\templates


6) SERVER> Net use T: /delete /yes

7) Use the fsecurity apply command on the NetApp storage system console to validate and apply the security definitions. This command creates a job that runs in the background on the storage system. FAS1> fsecurity apply /vol/DATA/TEMPLATES/security-base.sec -v

8) Check the status of the job that is running or the history of 15 jobs at once, by using the fsecurity status command. Once you execute the fsecurity status, it will also show job #s. For more detail, you can also execute: FAS1> fsecurity status <job number>

9) Grant Pebbles the right to logon to the Vista machine via terminal services. We will add Pebbles to both the Domain Controller as well as the VISTA local group, Remote Desktop Users.

SERVER> net localgroup “Remote Desktop Users” demo\Pebbles /add

SERVER> From the desktop, double click on the DEMO.MSC shortcut. This will allow you to remotely connect to the VISTA workstation. On the left colume of the MSC, expand ‘Remote Desktop’. Double-click on ‘Connect as Administrator’ Once connect, click start, run, cmd. VISTA> net localgroup “Remote Desktop Users” demo\Pebbles /add

VISTA> logoff

10) Map Pebbles’ to the Data volume

SERVER> From the desktop, double click on the DEMO.MSC shortcut. This will allow you to remotely connect to the VISTA workstation. On the left colume of the MSC, expand ‘Remote Desktop’. Double-click on ‘Connect as Pebbles’ Once connect, click start, run, cmd. VISTA> net use t: \\FAS1\data

11) Create a text file at the root of the DATA volume

12) VISTA> Logoff Pebbles

13) Map Wilma to the Data volume

14) SERVER> From the desktop, double click on the DEMO.MSC shortcut. This will allow you to remotely connect to the VISTA workstation.

15) On the left colume of the MSC, expand ‘Remote Desktop’. Double-click on ‘Connect as Wilma’

16) Once connect, click start, run, cmd. 17) VISTA> net use t: \\FAS1\data 18) Have Wilma open the text file Pebbles’ created – you should be successful. Now, have

Wilma create a new text file – you should have no success.

19) VISTA> Logoff Wilma

20) To display the Storage Level Access Guard permissions:

FAS1> fsecurity show /vol/DATA

21) To remove an active fsecurity Storage-Level Access Guard policy, type: FAS1> fsecurity cancel <all> or <Job #>


Note: This will cancel jobs which have a status of “working” but does not clear job history.

fsecurity on-box permission utility: • Customers requested for the ability to view and set the security on the

files/directories on the NetApp storage itself (in Data ONTAP 7.2.1, for NTFS ACLs only).

• Data ONTAP supports an additional layer of security which applies to an entire storage object (volume or qtree) and which cannot be overridden.

• This new additional layer of security is called Storage-Level Access Guard security, applicable to a storage object.

• Files and directories within the volume or qtree will not inherit the security set using Storage-Level Access Guard. This level of security cannot be revoked from a client, even by an administrator.

• “fsecurity” command allows the storage admins to apply the security over huge directories directly on the NetApp storage, hence avoid the permissions issues inherent with going over the wire.

• “fsecurity” command can also be leveraged by provisioning scripts to set the security.

Benefit: No more dependency on managing the folder based ACLs from a client side. Data ONTAP has the built in tool now called “fsecurity.” Also gives additional layer of security called Storage-Level Access Guard.

How Will It Work?

Storage-Level Access Guard Security is comprised of several components, including the following:

• Data ONTAP console command

• Job definition files

• Windows client interface

When an administrator decides that they want to apply Storage-Level Access guard security to a storage object, they must first generate the job definition file. This is a Unicode text file that contains various pieces of information such as security descriptors and paths. The file format will be open, allowing customers to write scripts that generate them.

Customers might also use the Windows client interface to generate the files. This interface resembles the Security tab you find in Windows Explorer, and will generate a correctly formatted file.

Once the file is generated, it is copied to a location on the NetApp storage. From there, a console command validates and applies the Storage-Level Access Guard security by creating a job that runs on the NetApp storage in the background. This job can be monitored and cancelled as desired.

Once the job is complete, the results can be viewed from the console. It's important to keep in mind that Storage-Level Access Guard security is not managed or even visible directly from a client.


Example of fsecurity command: FAS1> fsecurity show /vol/DATA

The output will look similar to the following:

[/vol/r2 - Directory (inum 64)]

Security style: NTFS

Effective style: NTFS

Unix security:

uid: 0 (root)

gid: 0 (daemon)

mode: 0777 (rwxrwxrwx)

NTFS security descriptor:

Owner: BUILTIN\Administrators

Group: BUILTIN\Administrators

DACL:

Allow - Everyone - 0x001f01ff (Full Control)

Allow - Everyone - 0x10000000 - OI|CI|IO

Notes:

• Storage-Level Access Guard Security descriptor must be removed before a qtree can be deleted.

• Volume root is qtree id 0; Storage-Level Access Guard is not inherited from volume root to other qtrees.

• “Secedit.exe”: A Windows client application for constructing security settings for the “fsecurity apply” command, provided on an as-needed basis to customers from http://now.netapp.com/NOW/download/tools/secedit/.

4.5.3 Useradmin CLI (Role Based Access Control) HANDS-ON EXERCISE: Useradmin Command Line Interface

Prerequisite: none Either perform the follow steps, or to automate the task, execute: CLIUSER.BAT. Then, proceed to step #2


Creating a User Who Only Administers SNMP

1.

FAS1> options security.passwd.rules.minimum 7 (This changes the minimum password length from the default of 8 to 7 characters)


FAS1> useradmin role add rsh_help -a login-rsh,cli-help*

FAS1> useradmin role add snmp_commands -a login-*,cli-snmp*,api-snmp-*

FAS1> useradmin group add snmp_admins -r rsh_help,snmp_commands

FAS1> useradmin user add Dino -g snmp_admins

2.

FAS1> useradmin user list

FAS1> useradmin group list snmp_admins

This creates two roles, one which can rsh into the NetApp storage and run the help command, and another which is allowed to log in using any login method and run any snmp command. The "snmp_admins" group is allowed to log into the NetApp storage and run the help command using telnet, rsh, etc, and run snmp commands. The user "Dino" inherits these capabilities from the group.

Creating/Modifying a User Without Console Access

This is a common issue that arises for appliances running in Windows domains. A user without console access cannot execute any NetApp storage CLI commands. These local users should be placed in local groups (or even no groups at all) that do not have any roles which contain these capabilities. To see if a user has access, list the user and check the Allowed Capabilities. If a user is in a group with the capabilities: "cli-*" and "login-*,” then that user has console access. The following command places a user into a group with no capabilities, which will revoke all privileges.

3. FAS1> useradmin user modify Dino -g "Guests"

FAS1> useradmin user list Dino

4.5.4 Antivirus Scanning HANDS-ON EXERCISE: Antivirus Scanning

Prerequisite: CIFSRUN.BAT Either perform the follow steps, or to automate the task, execute: ANTIVIRUS.BAT. Then, proceed to step #2


Installation of McAfee Antivirus for NetApp Version 7.1.0

1. SERVER> C:\CIFSDEMO\Anti-Virus\McAFEE\setup.exe

2. Read the license, then click Next.

3. If you have the desktop shortcut of DEMO.MSC open, close it or setup will timeout.


4. Click “I accept the terms in the License agreement,” followed by OK.

5. Select Custom installation, followed by Next.

6. Click Yes to accept the Registry Key Change.

7. Leave Alert Manager unchecked, click Next.

8. Accept the default Product Configuration, click Next.

9. On Security Configuration, enter a password (netapp1) (x2), followed by Next.

10. Add NetApp storage name – click Add, use the IP address and not NetBIOS name (192.168.10.35), Enter domain name <demo\Administrator> and password (netapp1) for the Administrator account, click Next.

11. Click Install.

12. Uncheck both Update Now and Run Scan, and click Finish.

13. Select Yes to reboot the server when prompted.

The scanner registers with the Storage Appliance. At the NetApp console each time the Windows machine reboots, you will see a message similar to:

[vscan.server.connecting.successful:info]: CIFS: Vscan server \\W2003 registered with the storage unit successfully.

Troubleshooting: If you do not see a message similar to this, on the Windows Server, click Program -> Network Associates -> VirusScan Console. Right click “Network Appliance AV Scanner” and select enable.

For this exercise, you will not see the message as the Telnet session to the NetApp storage closes each time the Windows machine reboots.

At the NetApp storage, to enable scanning, type: FAS1> vscan on

For the status of the scanner, type: FAS1> vscan

• Scanner waits for requests to come from the NetApp appliance.

• Several scanners can register with the Storage Appliance, for performance and reliability (recommended).

• A single scanner can scan multiple Storage Appliances.

• Scanner will ping the Storage Appliance from time to time to detect and recover from reboots/takeovers.

To Test Your Installation

Type the following line into its own file, then save the file with the name EICAR.COM.

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*


Or

SERVER> Notepad C:\CIFSDEMO\AVTEST.TXT

Edit the file so that the two separate lines become one line (just like the above example), save the file as C:\EICAR.COM

If VirusScan is running and configured correctly, when you try to save the file, VirusScan will detect the virus. If VirusScan is not running, start it and scan the directory that contains EICAR.COM. When your software scans this file, it will report finding the EICAR test file.

Virus Scanning Process

Once a file is successfully scanned, the Storage Appliance marks it "OK" and does not scan it again. Two exceptions exist:

• If the file is written to, the file could contain a virus, for this reason, the file is again scanned when closed.

• If the scanner is updated, updated DAT files contain new viruses to check for. In this case if the Storage Appliance receives an RPC from the scanner that it has been updated, the Storage Appliance will remove the OK flag for all files.

This might result in slower CIFS access for future opens.

VSCAN commands

• vscan help

Print list of vscan commands.

• vscan extensions

Displays the current list of extensions to scan and not to scan.

• vscan extensions include add mp3

Adds mp3 to the include list to scan.

• vscan extensions include set txt

Sets the list of files to scan to only files with the txt extensions.

• vscan extensions exclude add wmv

Adds wmv to the files not to be scanned list.


• vscan ext reset

Resets the list of extensions to scan to the default values.

• vscan options timeout set 15

Sets the timeout value to 15 seconds.

VSCAN on/off The vscan on/off will enable and disable the vscan option.

Caution: If you turn vscan on, and there are no scanners registered with the NetApp storage, NetApp storage will not allow access to the file(s) that have the listed extension(s) unless the mandatory_scan is set to off.

VSCAN options

FAS1> vscan options vscan options timeout: 10 sec vscan options abort_timeout: 10000 sec vscan options mandatory_scan: on vscan options client_msgbox: off

Timeout displays the current virus scan timeout value in seconds. This value determines how long the Storage Appliance will wait for the scanning client to perform a virus scan request. The timeout value may be reset to a default value provided by NetApp. It is also possible to set the timeout.

Mandatory_scan displays the current setting for the mandatory_scan option. If set to "on,” then access to files will be denied if a virus scan cannot be performed, for example, because no scanners are available. If this option is set to "off" then access to files is allowed if it is not possible to scan the file. NetApp Professional Services recommends customers set this to off.

VSCAN scanners

FAS1> vscan scanners Virus scanners (IP and Name) Connect time (dd:hh:mm) Reqs Fails 192.168.10.100 \\W2003 00:00:01 0 0


Client Message Box With the MsgBox set to on, the client will get a clear explanation why file access has failed:

FAS1> vscan options client_msgbox [on | off]

MsgBoxes are throttled in case you encounter a virus storm. The NetApp storage will send no more than 5 vscan MsgBoxes every 30 seconds.

Virus Scan Options for CIFS shares cifs shares -add <sharename> <path>

– novscan

– novscanread

Example: FAS1> cifs shares –add data /vol/DATA –novscan

FAS1> cifs shares –change <sharename>

– novscanread | vscanread

– vscan | novscan

Example: FAS1> cifs shares –change DATA - vscan

For additional information, refer to FAS1> man na_vscan

4.5.5 Live-View Auditing Prerequisites for CIFS auditing:

• CIFS must be licensed and enabled on the storage system before auditing can be enabled.

• The file or directory to be audited must be in a mixed or NTFS volume or qtree. You cannot audit CIFS events for a file or directory in a UNIX volume or qtree unless Storage-Level Access Guard is enabled.

• Event auditing is turned off by default. To identify events for auditing, you must enable individual options and enable auditing.


Configuration

HANDS-ON EXERCISE: Live-View Auditing

Prerequisite: CIFSRUN.BAT Either perform the follow steps, or to automate the task, execute: none

Performed from Vista, W2003 or W2008 You must specify the file access events to record. Configure the following options in Data ONTAP for CIFS auditing. File access events

FAS1> options cifs.audit.file_access_events.enable on Logon/logoff events

FAS1> options cifs.audit.logon_events.enable on Account management events

FAS1> options cifs.audit.account_mgmt_events.enable on Enable CIFS audit

FAS1> cifs audit start FAS1> options cifs.audit.enable on

On Individual Files and Directories To audit access events on individual files and directories, you can set SACLs in two ways:

• Using the Windows Explorer GUI: Select the file or directory for which you want to enable auditing access. Right-click the file or directory and select Properties. Select the Security tab and click Advanced. Select the Auditing tab. Add, edit, or remove the auditing options you want, or

• Using the fsecurity permission command, as explained in section 4.4.7.

Note: Be sure to select only the events that you need to audit, because selecting too many audit options might affect system performance.

On Volumes and Qtrees

To audit access events on all files and directories within a volume or qtree, NetApp recommends that you set SACLs by applying Storage-Level Access Guard security as explained in section 4.4.7.

Note: SACLs can also be set on the volume or qtree directly by using the Windows Explorer GUI, similar to an individual file or directory. The only caution would be, if you have SACLs applied to the child objects of that volume or qtree, then any user who has the privilege to modify the SACLs at those levels can unset the settings, and that specific subfolder or file will be skipped from auditing, whereas SACLs applied through the Storage-Level Access Guard on the volume or qtree cannot be changed by the users at the child object level.

SAVING AUDIT EVENTS

Audit event information is stored in an internal log file, /etc/log/cifsaudit.alf. By default, the external event log is /etc/log/adtlog.evt. Audit events can be saved manually by using the cifs audit save command or by enabling automatic saving.


Automatic Saving Based on Size of the Internal Log File

The default size threshold for the internal log file is 75%, so that whenever the internal log file is 75% full, the contents are automatically saved to the external event file. You can specify the size threshold as a percentage (%), kilobytes (k), megabytes (m), or gigabytes (g).

FAS1> options cifs.audit.autosave.onsize.enable on

FAS1> options cifs.audit.autosave.onsize.threshold Nsuffix

N is the value of the size threshold, suffix is the unit of measure.

As an example for this lab, use 640k

Automatic Saving Based on a Time Interval

The default time interval is one day. You can specify the time interval as seconds (s), minutes (m), hours (h), or days (d).

FAS1> options cifs.audit.autosave.ontime.enable on

FAS1> options cifs.audit.autosave.ontime.interval Nsuffix

N is the value of the time interval, suffix is the unit of measure.

Automatically Saved Event File Extensions

Each time the internal log file is automatically saved to the external event file, an extension is added to the base name of the event file.

Counter extensions: FAS1> options cifs.audit.autosave.file.extension counter

Examples: eventlog.evt, eventlog1.evt, eventlog2.evt and so on.

Timestamp extension: FAS1> options cifs.audit.autosave.file.extension timestamp

Format: base name of event file YYYYMMDDHHMMSS.evt

Maximum Number of Automatically Saved Event Files FAS1> options cifs.audit.autosave.file.limit value

value is a number from 0 to 999.


DISPLAYING AUDIT EVENTS

Real-Time Display: Live View

To view the event logs from the storage system in real time from the Windows client, complete the following steps:

1. To enable or disable Live View on your storage system, set FAS1> options cifs.audit.liveview.enable on

2. SERVER> Start Event Viewer from Administrative Tools or from Microsoft Management Console.

3. From the Action menu, select Connect to Another Computer. Enter the name of the storage system you want to audit (FAS1) and click OK.

4. On the left side of the application, select the Security entry. The right side of the application is populated with the latest audit events captured on the storage system (up to 5,000 events).

Static Display

To view the external event log (.evt file) saved on the storage system, complete the following steps:

1. SERVER> Start Event Viewer from Administrative Tools or from Microsoft Management Console.

2. From the Action menu, select Open Log File. Select the event log file saved on the storage system.

Note: Do not try to open the event log by selecting Select Computer from the Log menu and double-clicking the storage system name. If you do, Event Viewer displays the error message "The RPC server is unavailable," because Data ONTAP does not communicate with Event Viewer with RPC calls unless Live View is enabled.

CONVERTING A EVENT LOG TO A TEXT FILE

The EVT2TXT Converter tool converts a standard Microsoft type event (.evt) file to a text (.txt) file format. This tool is available from the NOW site: http://now.netapp.com/NOW/download/tools/evt2text.

The tool has also been copied to C:\CIFSDEMO\EVT2TEXT for your convenience. Refer to the C:\CIFSDEMO\EVT2TEXT\README.txt file for details on how to use the tool.


4.5.6 Access-Based Enumeration (ABE) ABE (Access-Based Enumeration) for a CIFS share on a NetApp storage system can be managed by:

FAS1> cifs shares <sharename> option [–accessbasedenum | -noaccessbasedenum]

NetApp storage systems require CLI (no FilerView support) to enable ABE on CIFS shares. There is no option on the NetApp storage system to enable or disable ABE on all shares.

The cmd tool from Microsoft (abecmd.exe) provides the capability to enable/disable ABE on shares located on NetApp storage controllers from a Windows server. The syntax for abecmd.exe is:

SERVER> abecmd [/enable | /disable] [/server <servername>] {/all | <sharename>}

To enable ABE on a particular share use: SERVER> abecmd /enable /server FAS1 <share name>

Note: The ABEUI.msi package, which can be downloaded from Microsoft’s Web site must first be installed on all Windows 2003 servers prior to R2, which will use the abecmd tool, as well as all DFS servers.

Access-Based Enumeration Example HANDS-ON EXERCISE: Access-Based Enumeration


SHARESETUP.BAT

Either perform the follow steps, or to automate the task, execute: ABESETUP.BAT. Then, proceed to step #17

Performed from W2003, and VISTA

First of all, you must set up your regular file shares as you normally would. You must set the permissions on the share, and the NTFS permissions on the file system. Take note of the NTFS permissions - you will need these later. These will indicate who gets to see the share once the configuration is complete.

1. We will use a share called DATA, located at /vol/DATA. SERVER> Net use T: \\FAS1\DATA

2. At the root of the share, make a folder called \Software. SERVER> MKDIR T:\SOFTWARE

3. Underneath \SOFTWARE, create three directories: FilerView, SnapManager, and NDA. SERVER> MKDIR T:\SOFTWARE\FilerView SERVER> MKDIR T:\SOFTWARE\SnapManager SERVER> MKDIR T:\SOFTWARE\NDA

4. We have two users which were previously created in Active Directory, Fred and Wilma.


5. SERVER> Start Explorer, go to drive T:, select properties on each of the folders specified and assign the following permissions.

Create Folder: Assign Fred Assign Wilma \FilerView Full Control Full Control \SnapManager Full control Full Control \NDA No access Requires the following as a minimum:

List Folder /Read Data, Read Attributes, Read Extended Attributes (Traverse), Read Permissions

6. Disconnect from drive T:

SERVER> Net use T: /delete /yes

7. Map Fred to the DATA share

SERVER> From the desktop, double click on the DEMO.MSC shortcut. This will allow you to remotely connect to the VISTA workstation. On the left colume of the MSC, expand ‘Remote Desktop’. Double-click on ‘Connect as Fred’ Once connect, click start, run, cmd.

8. VISTA> net use T: \\FAS1\data 9. Open the SOFTWARE folder.

10. Fred will see all three sub-folders even though he doesn’t have access rights to the NDA folder.

11. Verify this by clicking on each sub-folder.

12. VISTA> Logoff Fred

13. Connect Wilma.

SERVER> From the desktop, double click on the DEMO.MSC shortcut. This will allow you to remotely connect to the VISTA workstation. On the left colume of the MSC, expand ‘Remote Desktop’. Double-click on ‘Connect as Wilma’ Once connect, click start, run, cmd. VISTA> net use T: \\FAS1\data

14. Open the SOFTWARE folder.

Notice Wilma can also see all folders.

15. Verify Wilma has access to each folder by clicking on each folders name

16. Enable Access Based Enumeration

FAS1> cifs shares –change data –accessbasedenum

17. Wilma can still access all three folders, as she was given permission.

18. VISTA> Logoff Wilma

19. Reconnect Fred to the DATA share.

SERVER> From the desktop, double click on the DEMO.MSC shortcut. This will allow you to remotely connect to the VISTA workstation. On the left colume of the MSC, expand ‘Remote Desktop’. Double-click on ‘Connect as Fred’ Once connect, click start, run, cmd.


VISTA> net use t: \\FAS1\data 20. Notice Fred now can only see the folders he has access to.

21. VISTA> Logoff Fred

Enable/Disable ABE Through the NetApp Storage CLI

To enable ABE on an existing share: FAS1> cifs shares -change <sharename> -accessbasedenum

To disable ABE on an existing share: FAS1> cifs shares -change <sharename> -noaccessbasedenum

To create a share with ABE enabled: FAS1> cifs shares -add <sharename> <path> -accessbasedenum

The console output when a share has ABE enabled:

FAS1> cifs shares data

Name Mount Point Description

---- ----------- -----------

data /vol/data

... access based enum supported

everyone / Full Control


4.5.7 Configuring SSH and SSL Configure SecureAdmin™ to enable SSH2:

Usage:

secureadmin setup [-f] ssh

secureadmin setup [-f] [-q] ssl

secureadmin addcert ssl [path to CA signed cert]

secureadmin enable all|ssh|ssh1|ssh2|ssl

secureadmin disable all|ssh|ssh1|ssh2|ssl

secureadmin status

secureadmin version

SSH Setup HANDS-ON EXERCISE: SSH Setup

Prerequisite: CIFSRUN.BAT Either perform the follow steps, or to automate the task, execute: SSHSETUP.BAT. Then, proceed to step #10


1. FAS1> secureadmin setup ssh

SSH server supports both ssh 1.x and ssh 2.0 protocols.

SSH server needs two RSA keys to support ssh1.x protocol. The host key is generated and saved to file /etc/sshd/ssh_host_key during setup. The server key is regenerated every hour when SSH server is running.

SSH server needs a RSA host key and a DSA host key to support ssh 2.0 protocol.

SSH Setup will now ask you for the sizes of the host and server keys.

Note: Accept the defaults when it comes to selecting key size.

For SSH1.0 protocol, key sizes must be between 384 and 2048 bits.

For SSH2.0 protocol, key sizes must be between 768 and 2048 bits.

The size of the host and server keys must differ by at least 128 bits.

Please enter the size of host key for ssh1.x protocol [768] :

Please enter the size of server key for ssh1.x protocol [512] :

Please enter the size of host keys for ssh2.0 protocol [768] :

Is this correct? [yes]


Setup will now generate the host keys in the background. It will take a few minutes. After Setup is finished, you can start SSH server with command secureadmin enable ssh. A syslog message will be generated when Setup is complete.

FAS1> Wed Oct 25 05:59:56 GMT [rc:info]: SSH Setup: SSH Setup is done. Host keys are stored in /etc/sshd/ssh_host_key, /etc/sshd/ssh_host_rsa_key and /etc/sshd/ssh_host_dsa_key.

Enable the ssh2 protocol: 2.

FAS1> secureadmin enable ssh2

Make sure your host is able to send commands to the NetApp storage. RSH is the easiest method.

a. Add your host and user name to the /etc/hosts.equiv file

For example, if we wanted to allow the Administrator using the host: W2003, FAS1> priv set advanced

FAS1*> wrfile –a /etc/hosts.equiv W2003 Administrator

FAS1*> priv set

or

b. Use the option rsh –l to specify the user and password for RSH access

Test SSH with:

3. SERVER> rsh FAS1 ?

SERVER> rsh FAS1 -l root:netapp1 ?

If it works, you are ready to configure SSH, otherwise refer to the NetApp storage console for the error message, and take appropriate steps as described in the Troubleshooting section of this document.

Do not forget to remove the hosts.equiv entry once you have tested, and switch: FAS1> options httpd.admin.hostsequiv.enable off

Configure SSH

Using an Internet search engine such as Google, download both plink.exe and puttygen.exe for testing. (Both of these tools have been downloaded and placed in the folder C:\CIFSDEMO\plink.)


SERVER> C:\CIFSDEMO\plink\plink.exe root@FAS1 ?

The first time you use plink, you will be asked if you agree with the license, select Y for yes.

Here you can see the NetApp storage has accepted the connection and is now prompting for a password.

Next, generate keys by using puttygen.exe. Be sure you DO NOT enter a passphrase when generating the keys.

4. SERVER> C:\CIFSDEMO\plink\puttygen.exe

5. Select SSH-2 RSA radio button.

6. Accept the 1024 default for key size; the key size on the host does not have to match that of the NetApp storage, but it does need to be larger.

7. Click Generate and you will be prompted to move your mouse in the key area.

8. Once the Keys have been generated, select save public key and save private key. Save them to the directory C:\CIFSDEMO\plink.

Public key name = rsa_pub_key

Private key name = rsa_priv_key.ppk

Create an authorized_keys file. As a general rule the authorized_keys file is very sensitive; it does not want any line breaks. Do not edit this file with notepad; instead use wordpad or textpad.

When you open the public key file generated by puttygen it will look like this.

---- BEGIN SSH2 PUBLIC KEY ----

Comment: "rsa-key-20070119"

AAAAB3NzaC1yc2EAAAABJQAAAIEAyQ8pESW3f2dRNNtnioOTPD0dyTVfW1TcIrFY

1aC/qMHH2AK9A5Kjd9dUBq7YudjakUiwZKvB7rucg7FaMbOZDqf/HvqdJf3Zem99

LaolDWBpGJRNqe8zmdWWnU/SXV9weWjsx6W+JeT9Urhfp/hbgidI8D6HxyJO/028

1Yro2XM=

---- END SSH2 PUBLIC KEY ----

You need to strip all line breaks and extra text from this file to look like this. Note: After “ssh-rsa” there should be a space and then the key.

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAyQ8pESW3f2dRNNtnioOTPD0dyTVfW1TcIrFY1aC/qMHH2AK9A5Kjd9dUBq7YudjakUiwZKvB7rucg7FaMbOZDqf/HvqdJf3Zem99LaolDWBpGJRNqe8zmdWWnU/SXV9weWjsx6W+JeT9Urhfp/hbgidI8D6HxyJO/0281Yro2XM=

Notice that ssh-rsa is appended to the beginning of the file. Save this file as authorized_keys; do not overwrite the original public key.


Next, a drive will be mapped to the NetApp storage, so that you will be able to create a directory structure and place a file in the directory.

9.

SERVER> net use T: \\FAS1\C$

Create the following directory structure on the NetApp storage:

/etc/sshd/root/.ssh

We use the name root, as the key will be used by the user:root. If you planned to use a different login name, you create a directory structure with the appropriate name.

If you are doing this from a Windows host you will not be able to create the .ssh folder. Instead, create /etc/sshd/root/ssh.

Copy the authorized_keys file into this directory; once copied use the mv command on the NetApp storage to rename the ssh directory:


FAS1*> mv /etc/sshd/<username>/ssh /etc/sshd/<username>/.ssh

FAS1*> priv set

SERVER> net use T: /delete /yes

Run plink.exe, on the host:

10. The following command should be typed as one line

SERVER> c:\CIFSDEMO\plink\plink.exe -v –i c:\CIFSDEMO\plink\rsa_priv_key.ppk root@FAS1 ?

The first time you use plink, you will be asked if you agree with the license, select Y for yes.

The -v flag is used to give a verbose output regarding the connection negotiation. This can be removed from future commands once you are satisfied; it is a useful flag when trying to troubleshoot the connection.

Managing SSL for SecureAdmin

You can manage the SSL portion of SecureAdmin in the following ways:

• Set up and start SSL.

• Reinitialize SSL.

• Disable and enable SSL.


SSL uses a certificate to provide a secure connection between the storage system and a Web browser. SecureAdmin allows two types of certificates:

• Self-signed certificate

A certificate generated by Data ONTAP. Self-signed certificates can be used as is, but they are less secure than certificate-authority signed certificates, because the browser has no way of verifying the signer of the certificate. This means the system could be spoofed by an unauthorized server.

• Certificate-authority signed certificate

A certificate-authority signed certificate is a self-signed certificate that is sent to a certificate authority to be signed. The advantage of a certificate-authority signed certificate is that it verifies to the browser that the system is the system to which the client intended to connect.

SETTING UP AND STARTING SSL HANDS-ON EXERCISE: SSL Setup

Prerequisite: CIFSRUN.BAT

Either perform the follow steps, or to automate the task, execute: SSLSETUP.BAT. Then, proceed to step #1 under Testing your Certificate


To set up SSL, complete the following steps.

Enter the following command: FAS1> secureadmin setup ssl

Enter information when Data ONTAP prompts you:

(To use the default settings, press Enter at each of the prompts.)

Data ONTAP generates one file and places it in three locations:

/etc/keymgr/cert, /etc/keymgr/key, and /etc/keymgr/csr

Installing a Certificate-Authority-Signed Certificate

(This section is presented at a high level, as it is outside the scope of this document)

To install a certificate-authority-signed certificate, complete the following steps.

1. Send the certificate signing request, secureadmin.pem, to the certificate authority.

2. Back up the secureadmin.pem file by making a copy.

3. When the certificate authority returns the signed certificate, copy the signed certificate into a temporary location on the storage system.

4. Install the certificate by entering the following command:


FAS1> secureadmin addcert ssl <directory_path>

5. Disable SSL by entering the following command: FAS1> secureadmin disable ssl

6. Enable SSL by entering the following command: FAS1> secureadmin enable ssl

FAS1> options httpd.admin.hostsequiv.enable on

Testing Your Certificate

To verify that your certificate is installed correctly, complete the following steps.

Note: These steps can verify either a self-signed certificate or a certificate-authority-signed certificate.

1. Start your Web browser.

2. Enter the following URL:

https://FAS1/na_admin

Click ‘Continue to this website’. This message appears as the NetApp storage certificate has not been imported into the trusted certificates of your web browser.

When prompted, enter the username <root> and password <netapp1>

4.6 NETAPP TECHNICAL REPORT REFERENCE Antivirus Sizing Guide – October 2007

HTTP://MEDIA.NETAPP.COM/DOCUMENTS/TR-3617i

Antivirus Scanning Best Practices Guide – April 2006


http://now.netapp.com/NOW/knowledge/docs/olio/guides/avmatrix.shtml

(Requires NOW account)

LDAP


Unified Windows and UNIX Authentication Using Microsoft Active Directory Kerberos – May 2006


Auditing Quick Start Guide – May 2008



Multiprotocol Data Access: NFS, CIFS and HTTP – 2005


Role Based Access Controls in Data ONTAP – October 2004


CIFS Best Practices with a NetApp Filer – March 2005


Reallocate Best Practice Guide – July 2007


Best Practices for Secure Configuration of Data ONTAP 7G – May 2008


Refer to man na_useradmin - Administer NetApp storage access controls.

Storage-Level Access Guard Quick Start Guide – May 2008


Bulk Security Guard Quick Start – May 2008



5 FILE SYSTEM RESOURCE MANAGER

5.1 OVERVIEW This chapter provides practical guidelines for implementing quotas on NetApp storage. The chapter outlines deploying native Data ONTAP quotas. The advantage of native quota management is it is works in a multiprotocol environment. Usage can be tracked irregardless if a UNIX user manipulates data or a Windows user manipulates data.

5.1.1 Quota Management Partner integration with Quota/SRM includes products from NTP Software®, Veritas®, Northern Software Suite®, and Intermine®.

Use quotas to control disk space usage. Always set a default quota on the volume.

NetApp quotas may be reported on qtree based, user based, and volume based.

5.2 BEST PRACTICES

5.2.1 Quota Value of using third-party quota manage software to manage NetApp storage quotas:

The NetApp storage quota management functionality has the current limitations:

• Only one quota (hard or soft) is allowed to be place at the volume root.

• Only one threshold message allowed which is not customizable.

NetApp quotas can only be placed on qtrees, volumes and users; and you’re limited in the amount of thresholds and reporting you can perform.

NTP and NSS software allows for as many volumes, share or directory level quotas as you desire.

With third-party tools:

• Quotas may be overlapping; (example: you can place a 100GB limit on the volume root and then 100MB user home directory limits on all subfolders)

• You’re allowed as many thresholds as you want; you can notify the user at 75%, 80%, 85%, 90%, 95% 100%; Overdraft, etc…

• Both third-party tools have a report module which can generate canned or custom reports (example: You may run a Usage by User report to determine how much space your users are consuming.)


NTP Software NTP Installation and configuration

• When upgrading the current NTP version, it is better to reinstall the whole package instead of upgrading. This is as there are possibilities of version mismatch between the other software components (within NTP).

• NTP accepts NetBIOS name only, NOT the IP address of the NetApp storage

• In case of problems connecting NTP and NetApp storage, check the user credentials which is the most common issue.

• Check ‘Event Viewer’ to diagnose and troubleshoot NTP issues as the NTP log messages are well defined with less complexity. This helps to arrive at the solution quickly.

NTP Post installation

• NTP Software QFS for NAS Admin Reports doesn’t update the NetApp storage volume information in real time. It needs a service restart to obtain the latest info from the NetApp storage. This is because the NTP architecture fetches info from the NetApp storage only when the service is started, thereby providing no dynamic update of changes.

• NTP doesn’t support more than one quota server to connect with NetApp storage for load balancing or redundancy.

5.3 DEMO

5.3.1 Native Quota Configuration A quota limits the amount of disk space and the number of files that a particular user or group can consume. A quota can also restrict the total space and files used in a qtree, or the usage of users and groups within a qtree. A request that would cause a user or group to exceed an applicable quota fails with a ``disk quota exceeded” error. A request that would cause the number of blocks or files in a qtree to exceed the qtree's limit fails with an ``out of disk space” error.

User and group quotas do not apply to the root user or to the Windows Administrator account; tree quotas, however, do apply even to root and the Windows Administrator account.

The quota command controls quotas, and the /etc/quotas file describes the quotas to impose. All quotas are established on a per-volume basis. For further information on the format of the /etc/quotas file, refer to

FAS1> man na_quotas

With no arguments, the quota command indicates the quota status (on, off, disabled, and so on) for each volume. This form of the command is deprecated - use the quota status command instead. The following list describes how to use the various quota commands:

FAS1> quota on <volume>

Activates quotas in the specified volume based on the contents of /etc/quotas. When quotas are first turned on, NetApp storage scans the file system to determine current file and space usage for each user and group with a quota. This might take several minutes during which quotas are


not in effect, although the file system is still accessible. Executing quota with no arguments during this period indicates that quotas are initializing and reports how much of the initialization process has completed.

When run with the -w option, quota on will not return until NetApp storage has finished scanning the /etc/quotas file and any errors will be printed to the console. When run without the -w option, quota on will return immediately and any errors will be reported through EMS.

FAS1> quota off <volume> turns quotas off on the specified volume. The volume name may be omitted if the system has only one volume. FAS1> quota resize volume

This adjusts currently active quotas in the specified volume to reflect changes in the /etc/quotas file. For instance, if you edit an entry in /etc/quotas to increase a user's quota, quota resize will cause the change to take effect. The volume name may be omitted if the system has only one volume. quota resize can be used only when quotas are already on. Because it does not rescan the file system to compute usage, quota resize is faster than turning quotas off and then on again. quota resize will apply all updated entries in /etc/quotas; however, it will generally ignore newly added entries. A newly added entry will only take effect if the corresponding user or group has an active quota as a result of updating a file subject to default quotas.

FAS1> quota allow volume

Enables quotas on the specified volume. FAS1> quota disallow <volume>

Disables quotas on the specified volume. FAS1> quota status [ volume ]

Prints the quota status (on, off, disabled, and so on) for the specified volume. If no volume name is specified, the quota status for all volumes in the system is printed.

FAS1> quota report

Prints the current file and space consumption for each user or group with a quota and for each qtree. With a path argument, quota report displays information about all quotas that apply to the file. Space consumption and disk limits are rounded up and reported in multiples of 4 Kbytes.

The formatting options are defined as:

-q

If this option is given, the quota target's ID is displayed in a numeric form. No lookup of the name associated with the target ID is done. For UNIX user IDs and group IDs, the ID is displayed as a number. For Windows IDs, the textual form of the SID is displayed.

-s

If this option is given, the soft limit values are printed in the output along with the hard limits.


-t

If this option is given, the warning threshold of the quota entry is included in the quota report output. If this option is omitted, the warning threshold is not included. This option is ignored if the -x option is used.

-v

If this option is given, the name of the vFiler controller is included in the quota report output. It is only valid if MultiStore® is licensed.

-u

If a quota target consists of multiple IDs, the first ID is listed on the first line of the quota report for that entry. The other IDs are listed on the lines following the first line, one ID per line. Each ID is followed by its original quota specifier, if any. Without this option, only one ID is displayed for quota targets with multiple IDs.

-x

If a quota target consists of multiple IDs, all IDs are listed on the first line of the quota report for that entry. They are listed as a comma separated list. Each column of the report output will be separated by a tab character. The threshold column will also be included.

quota logmsg

Allows the user to specify a time interval for a volume during which quota messages for that volume will be disabled. With no arguments, the quota logmsg command displays the current interval settings.


Configuring Quotas on a User’s Volume

Background:

HANDS-ON EXERCISE: Quotas

Prerequisite: CIFSRUN.BAT Either perform the follow steps, or to automate the task, execute: QUOTA.BAT. Then, proceed to step #10


This will be for a user’s volume called DATA, allowing quotas to have a soft limit of 150MB for each user, and a hard limit of 175MB per user.

From NetApp FilerView**:

1. Select Volumes, Quotas, Add.

2. Select User.

3. Select “data” for the volume, and check to make this the default quota for this volume, followed by Next.

4. For “Disk space soft limit,” use 150MB.

5. For “Disk space hard limit,” use 175MB.

6. Click Next.

7. Commit followed by close.

8. From Quota, Manage, check “data” volume.

9. Click On, followed by OK.

10. From the console:

FAS1> quota report

You can use the Quota report function to report on individual users, groups or volumes.

Support Qtree quota and user quota (soft and hard limit).

Enhanced quota notification and reporting in available in NetApp Operations Manager.

** System Manager is the replacement for FilerView. Currently, System Manager 1.0 runs in a Windows environment only. This includes:

Windows XP, Windows Vista, Windows 2003, and Windows 2008

System Manager implements an MMC plug-in so it depends on MMC 3.0 and .NET 2.0.

The System Manager software will:

• Discover unprovisioned NetApp storage using SNMP

• Perform basic controller setup (DNS, NIS, Networking, AutoSupport, SNMP, Security, Date/Time/Time Zone)


• Perform aggr, volume and lun provisioning along with CIFS server and share provisioning (ACL shares too)

• Perform host discovery (hosts running sw initiator)

• Provide igroup and host connections

• Provide improved monitoring and health diagnostics (ie. status dashboard, interpretive advice, system health tray) via SNMP

• Will have ONLINE HELP support. This online help will also include task based instructions. The application will also have a Quick Start/Setup Guide.

The software will be available from the NetApp NOW software download pages, targeted for release in the February 2009 time frame.

A copy of the beta software is located at: C:\CIFSDEMO\SETUP\System_Manager.exe

5.3.2 Quota Management using Northern Storage Suite (www.Northern.net)

HANDS-ON EXERCISE: Northern Storage Suite Quota Management

Prerequisite: CIFSRUN.BAT, SHARESETUP.BAT

Either perform the follow steps, or to automate the task, execute: QUOTANSS.BAT. Then, proceed to step #2, under Installation

Performed from W2003 and Vista

Install this on the Windows 2003 Server. Modifications must be made to install on Windows 2008, which are outside the scope of this lab.

Installation

1. If you have not already installed the Microsoft SQL Server Desktop Edition for VFM, install MSDE now with the following switches:

SERVER> C:\CIFSDEMO\Northern\MSDE\setup SECURITYMODE=SQL SAPWD=netapp1

Note: A reboot IS required before proceeding with the installation of Northern Software.

2. Following the reboot, login and on the tool bar (bottom right side of desktop), right click SQL Server Agent. Select “Open SQL Server Service Manager.” Under Services, select “SQL Server Agent.” Click Start. Check Auto-start service when OS starts. Close the dialogue.

3. Execute Northern Software Suite setup:

SERVER> C:\CIFSDEMO\Northern\setup

4. At the “Welcome to the Northern Storage Suite” dialogue, click Next

5. Choose Evaluation Installation, click Next

6. Choose NAS Evaluation, click Next

7. On the License Agreement dialogue, click Yes

8. On the Choose Destination Location, click Next


9. Enter Account: DEMO\Administrator, Password: netapp1, Confirm Password: netapp1, click Next

10. Check ‘Create a database for Northern Storage Suite’s usage statisticas, click Next

11. Enter Server: W2003, Account: sa, Password: netapp1, Confirm Password: netapp1

12. Start Copying Files dialogue, click Next

13. Finish

Configuration

1. Start NSS by clicking Start -> All Programs -> NORTHERN -> Storage Suite -> Northern Storage Suite

2. If prompted to accept the “Northern Certified Software, choose Install.

3. Click Config (Top right), Host Management (Left side, third menu item)

4. Click Add, Next, and select NetApp Managed Host

Note: There is a bug in this version of the software – you will need to click NetApp Managed Host, then click on EMC, and then back to NetApp Managed Host – this is to enable the Next button, otherwise the Next button is not selectable.

5. Select the Host where NSS is installed (W2003). (This is NOT the NetApp storage)

6. Select Northern Storage Report, click Next x2

7. On the properties of the Scan Dialogue, select to repeat the scan every 5 minutes. Click Next x3, followed by Finish.

Note: In a production environment, you would normally set the scan to be at a higher level than this. In a lab environment we want to ensure the changes we make can be reported upon much sooner.

8. On the top right, click the left square. (It should read Home: Dashboard under the square when you move the mouse over the square.)

9. Click User Interaction (left side)

10. Under Status, click Change Server

11. Select the server where NSS is installed (DEMO -> W2003)

12. On the top right, click the middle (orange square) It should read Quota under the square when you move the mouse over the square.

13. On the left panel, click File System Quotas

14. Under the middle pane, expand the NT Servers list and select the NetApp storage (FAS1). Right click and select ‘Add NetApp Filer’

15. A NetApp Configuration Wizard will begin, click Next

16. A dialogue will open, asking which Quota Server server – use the default of W2003, click Next

17. A dialogue will open, asking Do you wish to add additional Filers, click Next

18. A dialogue will open, asking the type of connection. Use HTTP user name: root, password: netapp1, click Next, Finish, then Close


19. Under the NetApp Storage name, expand ‘Shares’

20. Select the BOOKS share. Right click and select ‘Add Quota or Template’.

21. A wizard will begin, click Next

22. Select add Quota, Next

23. Select NetApp, Next

24. Select User, Next

25. The next screen shows the host server where NSS is installed (W2003), click Next

26. Select Next to leave the default to apply the quota to the entire share

27. Click the browse [Elipse] button, expand the Users container and add Wilma, and remove Everyone, click OK, then Next

28. Change the size to 50 MB, then Next

29. Under Threshold Settings, click Level 1 which will enable additional options. Under User Notification, for Level 2 and 3, select Popup, Next

30. In the User Settings, in Popup Receiver, type: %User, followed by Next

31. Click Next again, followed by Apply and Close, Minimize NSS Internet Explorer window

32. Map Wilma to the BOOKS share

SERVER> From the desktop, double click on the DEMO.MSC shortcut. This will allow you to remotely connect to the VISTA workstation.

On the left colume of the MSC, expand ‘Remote Desktop’. Double-click on ‘Connect as Wilma’

Once connect, click Start, Run and type CMD.exe

33. VISTA> Net use T: \\FAS1\BOOKS

34. VISTA> Copy C:\CIFSDEMO\NORTHERN\*.* T:\

35. VISTA> Net use T: /delete /yes

36. Log off the Vista machine

37. Return to the NSS Internet Explorer windows and notice the % used bar.

VIEWING END-USER PAGES IN STORAGE PORTAL

1. Choose: Start -> All Programs > NORTHERN > Storage Suite > Components -> Storage Portal.

2. If prompted to accept the “Northern Certified Software, choose Install.

3. In the Storage Portal Client, click the Users button in the top left-hand banner.

4. On the Users page, in the Path type: \\FAS1\BOOKS, for User, type: demo\wilma, click GO

5. The user’s Storage Portal Page appears.


5.3.3 Quota Management using NTP Software (www.NTPSoftware.com)

HANDS-ON EXERCISE: Northern Storage Suite Quota Management

Prerequisite: CIFSRUN.BAT, SHARESETUP.BAT

Either perform the follow steps, or to automate the task, execute: QUOTANTP.BAT. Then, proceed to step #2, under Installation


Install this on the Windows 2003 Server.

Installation

1. SERVER> C:\CIFSDEMO\NTP\setup.exe

2. Choose Yes to install Smart Policy Manager

3. On the Welcome to NTP, click Next

4. Check, “I accept the terms of the license agreement,” click Next

5. Accept the default location, click Next

6. Accept the default features, click Next

7. For the service account, use:

Service: DEMO\Administrator

Password: netapp1

Confirm: netapp1

8. Accept the default location for the Smart Policy Database, click Next

9. Choose, First Time Installation, click Next

10. Organization Info:

Organization: NDF

Location: San-Diego <- Do not change this name, as it matches the AD site.

11. On the Start copying file dialogue, click Next

12. Uncheck, “Yes, I want to view the readme file,” click Finish

13. On the Welcome to the NTP Software Installation, click Next

14. Check, “I accept the terms of the license agreement,” click Next

15. Accept the default Destination Location, click Next

16. Accept the default features, click Next

17. User Information:

Company Name: NDF

Check Install Evaluation Version, click Next

18. On the Account Type, choose “Specify an account to use,” click Next

19. Service account, use:


Service: DEMO\Administrator

Password: netapp1

Confirm: netapp1

20. Use the default for “Select program Folder,” click Next

21. On the Start Copying File dialogue, click Next

22. Uncheck, “Yes, I want to view the readme file,” click Finish

23. Click Next to gather NAS device information

24. QFS connector:

NetBIOS name: FAS1

NetBIOS name of your hosting Filer: <leave blank>

25. On the Email Notification dialogue, uncheck, “Yes, We do want email notification enabled,” click Finish

26. FAS1> fpolicy create NTPSoftware_QFS screen

Configuration

1. SERVER> All Programs -> NTP Software QFS for NAS -> NTP Software QFS for NAS Admin

2. Maximize Quota & File Sentinal dialogue

3. Expand San-Diego, fas1, Quota & File Sentinal

4. Right click Disk Quota Policies, select New -> Folder Policy using Shares

5. New Quota Share Policy:

a. Policy Name: Books Quota

b. Description: Historical Data

6. Click the Quota Tab

a. Absolute Quota limit of 50 MB

b. Under Quota Limit Properties, enable Deny Write, select 100%

7. Click the Shares Tab

a. Click Add, type BOOKS

b. Click OK

8. Map Wilma to the BOOKS share SERVER> From the desktop, double click on the DEMO.MSC shortcut. This will allow you to remotely connect to the VISTA workstation. On the left colume of the MSC, expand ‘Remote Desktop’. Double-click on ‘Connect as Wilma’ Once connect, click Start, Run and type CMD.exe


10. VISTA> Copy C:\CIFSDEMO\McAfee\*.* T:\


11. VISTA> Net use T: /delete /yes


13. Return to the Quota & File Sentinal

14. Expand San-Diego, fas1, Quota & File Sentinal, Disk Quota Policies. Click Books Quota

15. On the right side of the dialogue, expand BOOKS, and you will see the % of individual usage.

5.4 NETAPP TECHNICAL REPORT REFERENCE Quota Use Guide for NetApp Storage Systems – October 2005

(Includes QFS information)



6 INTEGRATION WITH WINDOWS SERVICES

6.1 OVERVIEW NetApp file services solutions simplify the growing complexity and reduce costs of storing and serving files in organizations by almost 40%. NetApp’s solution integrates with customer’s existing Active Directory, so they can consolidate with little effort. Migrate and manage their Windows files with Virtual File Manager with little to no disruption. And take advantage of a wide portfolio of certified solutions: Offline folders, group policy objects, roaming profiles and more.

6.2 BEST PRACTICES When connecting to a Windows 2008 Domain, with an existing 2003 DC, no issue should arise if the NetApp Storage is using Data ONTAP 7.2.4 or higher. The problem arises when you have a native Windows 2008 domain and NetApp storages with earlier versions of Data ONTAP.

Windows 2008 runs CIFS version 2.0, and keeping a Windows 2003 domain in the loop keeps CIFS 1.x active, which is what the upgraded DATA ONTAP versions fix (inclusion of CIFS 2.0). The behavior seen with Windows 2008 native mode and incompatible Data ONTAP versions is an inability to authenticate with Kerberos key and the "unable to acquire NetApp storage credentials," very similar to the behavior seen with a time skew greater than 5 minutes.

For the Kerberos ticket cache, there is no local cache maintained on the NetApp storage, as the ticket expiry kind of information is mentioned on the ticket itself and when the ticket expires, the NetApp storage will ask the client to come back with a valid session ticket again and the whole authentication process will be repeated.

6.2.1 Configuring Offline Folders Offline Folders (Client-Side Caching)

NetApp storage systems support the Microsoft Offline Folders feature, or client-side caching, which allows files to be cached for offline use on Windows 2000, XP, 2003, and Vista clients.

You may also specify whether Windows user documents and programs are automatically cached on a share or whether the files must be manually selected for caching. Manual caching is enabled by default for new shares.

Use the following CIFS shares options to manage client-side caching: FAS1> cifs shares (–change or –add) <share name>

[-no_caching | - auto_document_caching | -auto_program_caching]

The folders that are made available offline are synchronized to the Windows local disk. Synchronization occurs when network connectivity to a specific storage system share is restored.

To enable the Offline Folders options on a Windows client, in Windows Explorer, select Folder Options from the Tools menu. To force this feature on a specific file or folder, right-click the selected network drive or subfolder and select Make Available Offline. For more information, see the Microsoft TechNet article: “Make a file or folder available offline.”


6.2.2 Configuring Folder Redirection (Symbolic Links) NetApp storage systems support Microsoft folder redirection, one of the key components of Microsoft IntelliMirror technology. This option is intended only for organizations that have already deployed home directories and that want to maintain compatibility with their existing home directory environment.

Folder redirection can be set manually by the user, or be set through a GPO configuration on the Windows server.

Configuring Folder Redirection through a GPO

HANDS-ON EXERCISE: Group Policy Object


SHARESETUP.BAT Either perform the follow steps, or to automate the task, execute: none


1. On the Windows server, open the Active Directory Users and Computers tree.

2. Right-click the Organization Unit (OU) that contains the users desired (ldapusers). Remember a GPO cannot be applied to the default Computers OU.

3. Select the Group Policy tab, and select New.

4. Enter a name for the new GPO, i.e. Folder Redirect

5. Highlight the new GPO and select Edit. This opens the Group Policy Object Editor.

6. Expand User Configuration > Windows Settings > Folder Redirection.

7. Under Folder Redirection, select the folder that you want to redirect, we will use Desktop for this lab, and then click Properties.

8. Click the Target tab, and then in the Settings box, select Basic - Redirect everyone’s folder to the same location.

9. Under Target folder location, select Create a folder for each user under the root path.

10. In the Root Path box, type a Universal Naming Convention (UNC) path, For this example we will use \\FAS1\redirect and then click OK.

11. In the Properties dialog box for the special folder, click OK.

12. Close the Group Policy Editor and the OU Properties dialog box.

The user name and folder name are appended to the UNC path automatically.

Note: If you allow Folder Redirection to create the redirected folders on a specified network, the folders that are created in this way have proper permissions assigned to them. If you create the folders manually, you must make sure that permissions are properly assigned.


Selecting Advanced redirection allows you to apply the redirection to users that belong in a specified security group.

Testing the Folder Redirect GPO will be performed at the end of this chapter.

6.2.3 Group Policy Objects (GPOs) To enable additional management in Active Directory, group policy objects (GPOs) may be applied to users, computers, and servers in the domain. A GPO is a set of rules that are applicable to users and computers in an Active Directory environment and defined centrally for ease of administration and increased security. Settings that you control with GPOs include environmental settings, user rights assignment, account policies, folder redirection, script assignment, security settings, and software distribution.

NetApp storage systems fully support GPOs that apply to users and users computers. Beginning with Data ONTAP version 6.4, GPO support is included in NetApp storage systems. Although few GPOs are applicable to a NetApp storage system, the storage system is able to recognize and process a certain set of GPOs. The following GPOs are currently supported:

• Startup and shutdown scripts

• The GPO refresh time interval for computer

• File System Security settings

• Restricted Group Security

• Event Log support

• Auditing support

• User Rights Assignment

• GPO refresh time interval random offset

• Refer to Appendix G for additional supported GPOs in Data ONTAP 7.3

GPO support can be easily enabled on a NetApp storage system with the CLI. The option is: FAS1> options cifs.gpo.enable on | off

Make sure that CIFS is licensed and configured on the storage system and that it is already associated with an Organizational Unit (OU).

When GPOs have been enabled on a storage system and specified in the Active Directory domain, startup and shutdown scripts are applied to a group of systems in the following way:

• When CIFS starts on a storage system, it retrieves GPOs from the domain controller--including startup and shutdown scripts--and runs the retrieved startup scripts. Scripts are limited to a maximum of 4k.

• The storage system accesses the scripts from the Domain Controller's sysvol directory and saves these files locally in the /etc/ad directory.

Startup scripts: /etc/ad/startup.txt

Shutdown scripts: /etc/ad/shutdown.txt


• During a CIFS shutdown, CIFS executes the last retrieved shutdown script.

Note: Although the storage system periodically retrieves updates to the startup and shutdown scripts, startup scripts are not applied until the next time CIFS restarts.

Managing GPOs

To display GPOs that are currently in effect for the storage system and the results of those GPOs, use the cifs gpresult [ -r | -v | -d] command, which simulates the output of the Windows 2000, XP, Vista gpresult.exe /force command.

All GPOs are verified every 90 minutes. By default, Data ONTAP queries Active Directory for changes to GPOs. If the GPO version numbers recorded in Active Directory are higher than those on the storage system, Data ONTAP retrieves and applies the new GPOs. If the version numbers are the same, GPOs on the storage system are not updated.

By default, computer Group Policy is updated in the background every 90 minutes, with a random offset of 0 to 30 minutes. In addition to background updates, Group Policy for the computer is always updated when the system starts. If you select 0 minutes, the computer tries to update Group Policy every 7 seconds. However, because updates might interfere with users' work and increase network traffic, very short update intervals are not appropriate for most installations.

A random offset has been added to the refresh interval to prevent all clients from requesting Group Policy at the same time. The range of the random offset is from 0 to 1440 minutes (24 hours). The random offset prohibits all of the servers from polling the domain controllers at the same time.

Security Settings GPOs are refreshed every 16 hours. Data ONTAP retrieves and applies Security Setting GPOs every 16 hours, whether or not these GPOs have changed.

All GPOs can be updated on demand with a Data ONTAP command ”cifs gpupdate.”

6.2.4 Managing User Roaming Profiles Windows profiles are stored in the user's My Documents directory.

Roaming profiles should not be enabled for Offline Files. For more information, refer to Microsoft Knowledge Base article 287566, “The Cache Option for Offline Files Must Be Disabled on Roaming User Profile Shares.”

Roaming profiles that are replicated using FRS to multiple link targets might lead to data loss (due to FRS conflict resolution) if a user logs into multiple workstations, makes changes to the same file on different targets, and then logs off both workstations.

Windows files are stored in the user's My Documents directory.

Enabling Offline Files on DFS link targets is supported only on client computers running Windows XP Windows Server 2003 and Windows Vista. For more information, refer to Microsoft Knowledge Base article 262845, “Support for DFS-Based Shares for Offline Files.”

FRS does not provide distributed file locking. Depending on the update patterns of users, the lack of distributed locking might cause one user's update to override another user's update. If the collaboration is such that end users are not writing to the same files simultaneously, this most likely would not be an issue.



Configuring a Roaming User Profile

HANDS-ON EXERCISE: Roaming User Profile




You can configure a roaming profile by using the following procedure.

For this example, we will use an existing share on the NetApp storage where user profiles will be stored. The share is called, “Profile”, and we will use it for Wilma Flintstone.

1. Give all users Full Control permissions to the share (this is the default).

2. Open the Active Directory Users and Computers snap-in and navigate to the OU called, ldapusers.

3. Right-click on the user Wilma Flintstone, and select Properties from the menu

4. Click the Profile tab.

5. For the Profile Path:, type \\FAS1\Profile\%username%

The variable %username% will automatically create the Profile for the select user(s).

Things to remember with User Profiles:

• Do not use Encrypted File System (EFS) with Roaming User Profiles, Offline Folders, or the File Replication Service (FRS).

• If a user’s disk quotas are set too low, roaming profile synchronization might fail. Make sure enough disk space is allocated to allow the system to create a temporary duplicate copy of a user’s profile. The temporary profile is created in the user’s context as part of the synchronization process, so it debits his or her quota.

• Do not use offline folders on roaming profile shares.

• If storing Roaming Profiles on the same NetApp storage as redirected folders that have caching enabled, Make sure that Offline Folders are set to synchronize at logon and logoff.

• When a share is unavailable, Offline Folders considers the whole server to be unavailable until the offline cache is manually synchronized. Roaming profiles are not synchronized with the NetApp storage while Offline Folders considers the NetApp storage to be unavailable. If you are using Offline Folders in conjunction with Folder Redirection and roaming user profiles, for the best experience you should make sure that you leave the default setting of synchronizing Offline Files at logoff enabled.


6.3 DEMO

6.3.1 Group Policy Object Security Configuration HANDS-ON EXERCISE: GPO Security



Performed from Vista, W2003

To create a File System security GPO, complete the following steps.

On the NetApp storage, issue the following command:

FAS1> options cifs.gpo.enable on

1. A CIFS share has been created for you, as well as two users. In the example we will use:

Share: DATA, located at /vol/DATA

Active Directory User: Wilma, password: netapp1

Active Directory User: Fred, password: netapp1

Organization Unit where the NetApp Storage is located: NetApp Storage

2. On the Windows server, open the Active Directory Users and Computers MMC.

3. Right-click the Organization Unit (OU) NetApp Storage, and select Properties. Remember a GPO cannot be applied to the default Computers OU.

4. Select the Group Policy tab, and select New.

5. Enter a name for the new GPO, i.e. CIFS DATA access.

6. Highlight the new GPO and select Edit. This opens the Group Policy Object Editor.

7. Expand Computer Configuration > Windows Settings > Security Settings.

8. Right-click File System and select “Add File.” This opens the "Add a file or folder" dialog box. Note: Do not select the option to browse the local server's drives.

9. In the Folder field, enter the storage system path on which to apply the GPO (/vol/DATA) and click OK. Result: The Database Security window opens.

10. In the Database Security window, set the permissions you want and click OK. Result: The Add Object window opens. Add:

Wilma Flintstone, and give full control.

Fred Flintstone, and give the default of read, execute and list permissions.

Click OK

11. In the Add Object dialogue, accept the default settings, and click OK. Result: The Group Policy Editor displays the new object name.

12. Close the Group Policy Editor and the OU Properties dialog box.

Note: The format of target file or directory names must be recognized by Data ONTAP and must be in absolute or relative form.


• Absolute pathname—for example, /vol/vol0/DATA

When an absolute pathname is supplied, Data ONTAP applies File System security settings to the specified target file or files within the target directories. In this example, the settings are applied to the /home directory in the storage system root volume.

• Relative pathname—for example, /DATA

When a relative pathname is supplied (any pathname that does not begin with /vol), Data ONTAP applies File System security settings to any target file or directory containing the specified element. This is a convenient way to apply settings to multiple parallel targets in a single storage system; in this example, the settings are applied to all vFiler units with /home directories.

In case the NetApp storage belongs to another site, cifs resetdc should correct the site entry.

There should be a rule based on subnets to determine the current site for the NetApp storage. If the rule does not exist, then a CIFS terminate followed by CIFS setup will give an option to choose the site for the NetApp storage. The option to choose a site is shown only if there are multiple sites configured.

When multiple sites are present and the NetApp storage is unable to choose its site based on rules, then during CIFS setup, it will present the option to choose a site to associate with the NetApp storage. If there is only one site, and its site name has been changed from the default of: Default-First-Site. The follow message will be displayed:

[cifs.gpo.processing.ldap:warning]: CIFS GPO LDAP: Filer tries to search for GPO list. Error code: 32: No such object

On the storage system, enter the following command to retrieve and apply the new GPO:

FAS1> cifs gpupdate

Note: If you do not explicitly apply the new GPO with the cifs update command, the storage system applies the new GPO the next time it queries the Active Directory server (that is, within 90 minutes).

The cifs gpresult command takes the following options.

None Displays information about the GPOs currently applicable to the storage system, including name, version and location. -r Displays the results of applying current GPOs to the storage system. -v Generates a verbose display, including information about applicable GPOs and the results of applying them. -d Dumps the output from cifs gpresult -v to the file /etc/ad/gpresult_timestamp file.


Verify the GPO Works

HANDS-ON EXERCISE: GPO - Verify


Follow lab exercise in sections 6.2.2, 6.2.4 and 6.3.1

Either perform the follow steps, or to automate the task, execute: none


Map a drive to the data share with the user name Wilma:

1. SERVER> gpupdate /force 2. FAS1> cifs gpupdate 3. SERVER> From the desktop, double click on the DEMO.MSC

shortcut. This will allow you to remotely connect to the VISTA workstation. On the left colume of the MSC, expand ‘Remote Desktop’. Double-click on ‘Connect as Wilma’ Once connect, click Start, Run and type CMD.exe

4. VISTA> Net use T: \\FAS1\DATA

5. Copy several files to the T: share 6. Log off the Vista machine

7. SERVER> From the desktop, double click on the DEMO.MSC shortcut. This will allow you to remotely connect to the VISTA workstation.

On the left colume of the MSC, expand ‘Remote Desktop’. Double-click on ‘Connect as Fred’

Once connect, click Start, Run and type CMD.exe

8. VISTA> Net use T: \\FAS1\DATA

9. Open a file, and you should be able to read the contents. Now try to delete one of the files, and you should be denied access.


11. SERVER> Net use T: \\FAS1\REDIRECT

12. SERVER> Net use U: \\FAS1\PROFILE

13. Open Windows Explorer, you will see a sub-folder for each user who has logged onto the Vista machine.

14. SERVER> Net use * /delete /yes

By supporting this Policy, administrators will be able to define access permissions on DACLs and audit settings on SACLs for the file system objects that exist in NetApp storage through Active Directory.

For Example, on NetApp storage where the customer stores source code for application installs, they could limit full control to source code administrators and read/execute rights to software installers. This allows them to give local admin rights to people in order to support the hardware


without giving them the ability to change security settings on directories. Ultimately the power to ACL directories then stays with the people who can edit the policies.

6.3.2 Integrating with Active Directory LDAP Using LDAP Services

Data ONTAP supports LDAP for authentication, file access authorization, and user lookup and mapping services between NFS and CIFS.

For the steps to use Novell’s eDirectory for LDAP authentication, refer to Appendix F.

NetApp LDAP Servers Supported Data ONTAP LDAP support includes the following types of LDAP servers:

• Netscape (support ended December 28, 2007)

http://blog.netscape.com/2007/12/28/end-of-support-for-netscape-web-browsers/

• iPlanet / SUN – www.sun.com

• OpenLDAP - www.openldap.org/

• Windows Active Directory -

• Novell eDirectory/Novell Directory Services (NDS) – www.novell.com

Specifying the General Search Base and Scope

The LDAP base is the distinguished name of the LDAP tree in which user information is stored. All lookup requests sent to the LDAP server will be limited to the search base and scope specified by the ldap.base option value, unless further restricted by a more specific base and scope lookup value.

In this exercise, we have created the following structure:

• Active Directory domain: demo.netapp.com • The context for users, groups and passwords will be restricted to:

ldapusers.demo.netapp.com • The administrative account is located in the default Users domain OU


6.3.2.1 Editing the /etc/nsswitch.conf File for LDAP HANDS-ON EXERCISE: LDAP NSSWITCH.CONF

Prerequisite: none

Either perform the follow steps, or to automate the task, execute: LDAPNSS.BAT. Then, proceed to step #2, under Enabling or Disabling LDAP


Resetting the Environment If you wish to proceed to other exercises once you complete the LDAP AD lab, you will need to switch the NetApp storage back to AD authentication. To accomplish this, execute the CIFSRERUN.BAT

SERVER> C:\CIFSDEMO\SCRIPTS\CIFSRERUN.BAT

Modify the /etc/nsswitch.conf file as follows

1. FAS1> priv set advanced

FAS1*> java netapp.cmds.jsh

FAS1*> cp /etc/nsswitch.conf /etc/nsswitch.conf.original

FAS1*> wrfile /etc/nsswitch.conf

passwd: ldap files nis netgroup: ldap files nis group: ldap files nis hosts: files dns nis shadow: files nis

Ctrl+C to end file

A message will display stating: “read: error reading standard input: Interrupted system call”

FAS1*> wrfile –a /etc/usermap.cfg demo\* == *

After you create the file, you may view the contents with the command

FAS1*> rdfile /etc/usermap.cfg FAS1*> rdfile /etc/nsswitch.conf FAS1*> exit FAS1*> priv set


Enabling or Disabling LDAP 2.

To enable or disable LDAP on your NetApp storage, complete the following step. FAS1> options ldap.enable on

LDAP Authorization for NFS File Access from Windows Clients On the NetApp storage to be accessed, verify that every CIFS user who needs to access UNIX files is mapped to an associated UNIX user name in the usermap.cfg file.

Verify that every associated UNIX user name has an entry in the LDAP database.

6.3.2.2 Extending the RFC 2307 Schema By default, Data ONTAP supports LDAP servers that comply with RFC 2307, which specifies a Network Information Service (NIS)-style schema. You can replace the default values of LDAP options with your custom attribute names to configure Data ONTAP to query your custom (not RFC 2307-compliant) schema.

In Windows Server versions prior to Windows 2003 R2, it is necessary to extend the LDAP schema from AD with the UNIX attributes. This is accomplished by installing "Windows Services for UNIX" from Microsoft (use version 3.5) www.microsoft.com/windows/sfu/:

1. SERVER> Launch the UNIX 3.5 setup program (C:\CIFSDEMO\LDAP\unix\setup.exe).

2. On the Welcome screen, click Next.

3. Accept the default information for User name /Organization and click Next.

4. Check “I accept the license agreement” and click Next.

5. Choose Standard Installation, click Next.

6. On “Security Settings” page, leave both options unchecked, click Next.

7. On “User Name Mapping,” accept the default and click Next.

8. Accept the default on the next “User Name Mapping” dialog and click Next.

9. The installation will take an average of 4 minutes to complete.

10. When prompted click Finish, and choose Yes to reboot.

Note: If an error occurres which suspends installation, i.e. NIS server could not start; simply restart the setup.exe.

Although in Windows Server 2003 R2, the Active Directory schema is already extended with an RFC2307-compliant schema, the Windows Services for UNIX must still be installed to support the Active Directory Users and Computers tool with the UNIX Attributes tab to allow GUI editing of UNIX attributes for users, groups and computers.


Note: Every user who needs to have LDAP authentication must have a unique UID assigned, as well as a Primary Group Name/GID assigned. Both of these are assigned by selecting the User properties in Microsoft Management Console, select the UNIX tab, then assign the following:

• Unique UID assigned

• Primary Group Name/GID assigned

Groups must be assigned a GID before a User can be assigned the GID of a group.

Steps to assign GID’s: 1. Open Active Directory Users and Computers.

2. Navigate to the ldapusers context.

3. Create a group called HR, with the following settings:

Group scope: Global

Group type: Security

Click OK

4. Right click HR, and select Properties. Select the Members tab, add Fred and Wilma

5. Select the UNIX Attributes tab:

NIS Domain: DEMO

GID (Group ID): 100

6. Click OK.

7. Right click Wilma, and select Properties, select the UNIX Attributes tab:

Select NIS Domain: DEMO

UID: 200

Click OK

8. Right click Fred, and select Properties, select the UNIX Attributes tab:

Select NIS Domain DEMO

UID: 201

Click OK

9. Right click HR, and select Properties, select the UNIX Attributes tab:

Under the Members section, click Add

Select both Fred and Wilma, click Add, OK

Click OK


6.3.2.3 LDAP Authentication Requires Clear Text Passwords NOTE: The registry settings have been placed in the LDAPWINSETUP.BAT. You may execute the batch file instead of manually changing the registry. A reboot is required following the change.

Since LDAP authentication transmits unencrypted passwords, Windows clients require a registry edit to enable them to send passwords without encryption. Clients that are not properly configured to send clear text passwords to the storage system will be denied access and display an error message similar to the following:

System error 1240 has occurred

or

The account is not authorized to login from this station.

The SMB redirector does not send an unencrypted password unless you add a registry entry to enable unencrypted passwords.

RESOLUTION

Windows Vista, Windows 2003, Windows XP and Windows 2000 clients

• In HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters, add a REG_DWORD value called EnablePlainTextPassword and set it to 1.

OR

• Run Local Security Policy (under Administrative Tools). Under Security Settings->Local Policies->Security Options, enable Microsoft network client: Send unencrypted password to third-party SMB servers (for Windows 2003 and XP) or, Send unencrypted password to third-party SMB servers (for Windows 2000).

Windows NT clients

• In HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\parameters, add a REG_DWORD value called EnablePlainTextPassword and set it to 1.

Windows 98 clients

• In HKLM\System\CurrentControlSet\Services\VxD\VNETSUP, change EnablePlainTextPassword to 1.

OR

• On the Windows 98 CD, right click \tools\mtsutil\Ptxt_on.inf and click install.

If the following error message occurs,


"System error 86 has occurred. The specified network password is not correct."

• Open the Run command and type “secpol.msc.” • Click on "Local Policies" --> “Security Options.” • Navigate to the policy "Network Security: LAN Manager authentication level" and open it. • By default Windows sets the policy to “NTVLM2 responses only.” Change this to “LM and

NTLM – use NTLMV2 session security if negotiated.”

Note: This step must also occur on all Windows domain controllers used for LDAP authentication.

6.3.2.4 Testing Windows LDAP Prior to removing the NetApp storage from the Active Directory domain, we will test the LDAP configuration on the Windows domain controller.

1. SERVER> C:\CIFSDEMO\LDAP\LDAPBrowser\lbe.bat

2. After a few moments a Java screen will show the default connection Session List, click New.

3. For name, type: demo.netapp.com, click on the Connection tab.

4. Host: W2003.demo.netapp.com

Port: 389

Version: 3

Base DN: DC=demo,DC=netapp,DC=com

SSL: Off

Anonymous bind: Off

User DN: CN=Administrator,CN=Users,DC=demo,DC=netapp,DC=com

Password: netapp1

Click SAVE, followed by Connect

5. On the left column, you should see the default context you specified. Navigate to the ldapusers folder. Notice this folder’s context is OU. Now navigate to the Users folder, this context is CN. Active Directory uses CN for the default context, but any additional OUs created will always be referenced with OU.

6. When finished exploring, exit the LDAP browser.

NOTE: For NetWare eDirectory LDAP browsing, the Host name will be BigRed.demo.netapp.com, leave the Base DN blank, and enable Anonymous bind. For the balance of the settings, use the options specified for AD.


Custom LDAP Schema Options in Data ONTAP Make the appropriate LDAP changes:

NOTE: The following LDAP settings have been placed in the LDAPWINSCHEMA.BAT. You may execute the batch file instead of manually typing these commands.

FAS1> options ldap.ADdomain "dc=demo,dc=netapp,dc=com"

FAS1> options ldap.base "ou=ldapusers,dc=demo,dc=netapp,dc=com"

FAS1> options ldap.base.group "ou=ldapusers,dc=demo,dc=netapp,dc=com"

FAS1> options ldap.base.netgroup "ou=ldapusers,dc=demo,dc=netapp,dc=com"

FAS1> options ldap.base.passwd "ou=ldapusers,dc=demo,dc=netapp,dc=com"

FAS1> options ldap.enable on

FAS1> options ldap.minimum_bind_level anonymous

FAS1> options ldap.name "cn=Administrator,cn=Users,dc=demo,dc=netapp,dc=com"

FAS1> options ldap.nssmap.attribute.gecos name

FAS1> options ldap.nssmap.attribute.gidNumber msSFU30GidNumber

FAS1> options ldap.nssmap.attribute.groupname cn

FAS1> options ldap.nssmap.attribute.homeDirectory msSFU30HomeDirectory

FAS1> options ldap.nssmap.attribute.loginShell msSFU30LoginShell

FAS1> options ldap.nssmap.attribute.memberNisNetgroup memberNisNetgroup

FAS1> options ldap.nssmap.attribute.memberUid msSFU30MemberUid

FAS1> options ldap.nssmap.attribute.netgroupname cn

FAS1> options ldap.nssmap.attribute.nisNetgroupTriple

FAS1> options ldap.nssmap.attribute.uid sAMAccountName

FAS1> options ldap.nssmap.attribute.uidNumber msSFU30uidNumber

FAS1> options ldap.nssmap.attribute.userPassword msSFUPassword

FAS1> options ldap.nssmap.objectClass.nisNetgroup nisNetgroup

FAS1> options ldap.nssmap.objectClass.posixAccount User

FAS1> options ldap.nssmap.objectClass.posixGroup Group

FAS1> options ldap.passwd netapp1

FAS1> options ldap.port 389

FAS1> options ldap.servers

FAS1> options ldap.servers.preferred

FAS1> options ldap.ssl.enable off

FAS1> options ldap.usermap.attribute.unixaccount Unixaccount

FAS1> options ldap.usermap.attribute.windowsaccount Windowsaccount


FAS1> options ldap.usermap.base

FAS1> options ldap.usermap.enable off

Verify each setting was correctly changed by typing:

FAS1> options ldap

A reboot of the NetApp storage is required before continuing. FAS1> reboot

Testing LDAP Communications FAS1> priv set advanced

Use “GetXXbyYY” to test that LDAP is functioning correctly on the NetApp storage. The syntax for getXXbyYY is in the next section.

FAS1> getXXbyYY gethostbyname_r demo.netapp.com

produces:

name: demo.netapp.com

aliases:

addresses: 192.168.10.100

FAS1> getXXbyYY getpwbyname_r Fred

produces something like

pw_name = Fred

pw_passwd = {{******}}

pw_uid = 201, pw_gid = 100

pw_gecos = Fred Flintstone

pw_dir = /home/fred

pw_shell = /bin/sh

Once testing is complete, return the NetApp storage back to standard administration with: FAS1*> priv set


getXXbyYY: Advanced Name Resolution Test Commands getXXbyYY gethostbyname_r host_name

Given a host's name, prints information on that host by resolving the hostname.

getXXbyYY gethostbyaddr_r inet_address

Given a host's IP address, prints information on that host by reverse resolving the hostname. This information is derived from DNS, NIS/NIS+, and the NetApp storage's /etc/hosts file.

getXXbyYY netgrp netgroup_name client_name

Given a netgroup name and a client name, prints whether client is a member of netgroup. This information is derived from NIS/NIS+ and the NetApp storage's /etc/netgroup file.

getXXbyYY getspwbyname_r user_name

Given a user name, returns shadow password information on that user. This information is derived from NIS/NIS+ and the NetApp storage's /etc/shadow file.

getXXbyYY getpwbyname_r user_name

Given a user name, returns password information on that user. This information is derived from NIS/NIS+ and the NetApp storage's /etc/passwd file.

getXXbyYY getpwbyuid_r user_id_number

Given a user ID number, returns password information on that user. This information is derived from NIS/NIS+ and the NetApp storage's /etc/shadow file.

getXXbyYY getgrbyname group_name

Given a group name, returns group information on that group. This information is derived from NIS/NIS+ and the NetApp storage's /etc/group file.

getXXbyYY getgrbygid group_id_number

Given a group ID number returns group information on that group. This information is derived from NIS/NIS+ and the NetApp storage's /etc/group file.

getXXbyYY getgrlist user_name

Given a user name, returns the group ID of every group which includes that user. This information is derived from NIS/NIS+ and the NetApp storage's /etc/group and /etc/passwd files.


LDAP-Based Windows Client Authentication Note: This is an optional step, as the previous section on troubleshooting demonstrates that LDAP is communicating correctly.

You can authenticate Windows clients through an LDAP server. To enable authentication of Windows clients only through an LDAP server, complete the following operations.

FAS1> cifs terminate –t 0

FAS1> cifs setup

Specify NIS/LDAP as the authentication method (option 4) to be used for CIFS clients on the NetApp storage.

Configure for Mixed authentication, and not NTFS.

Any Workgroup name may be used, as LDAP does not use a Workgroup name.

Make sure that all CIFS shares have “mixed” security selected; you cannot use only NTFS with LDAP authentication. New shares should be created. If you have existing shares which was used with Active Directory, former users and groups will now be listed as unknown SIDs. Permissions must be assigned at the share level and file/folder level by Groups. Individual user names cannot be used with LDAP.


6.3.2.5 Manage NetApp Storage Users in LDAP Mode HANDS-ON EXERCISE: LDAP Permissions

Prerequisite: none Either perform the follow steps, or to automate the task, execute: none

Performed from W2003 and VISTA

Using Computer Management to add a user, group or change permissions on a NetApp storage share might fail with "The credentials supplied conflict with an existing set of credentials" or “The following error occurred while reading the list of shares for Windows clients: Error 5: Access is denied.”

First make sure you have no existing connections to the NetApp storage SERVER> Net use * /delete /yes

Next, create a NetApp storage BUILTIN account which will match the name and password of the account you are using on the Windows machine. I.E. if your Windows account is Administrator with a password of netapp1, then from the NetApp storage CLI, type:

FAS1> useradmin user list administrator

If you do not already have a local administrator account follow the next two steps to create one. FAS1> options security.passwd.rules.minimum 7

FAS1> useradmin user add administrator –n “Local Admin” –g administrators

Once you press enter, you will be prompted twice for the password you wish to associate to this account.

Next, to allow the local administrator to connect to NetApp storage default shares, we need to assign the permission.

FAS1> cifs access c$ builtin\administrator full control

SERVER> Net use T: \\FAS1\C$

Use ‘Computer Management’ to manage the NetApp storage.

When completed, disconnect the mapped drive:

SERVER> Net use T: /delete /yes

NOTE: The management must be performed from a Windows server, and not a Windows Professional, XP or Vista workstation or the Error 5: Access is denied message will continue when attempting to modify permissions.


Testing User Shared Access Using LDAP Authentication From a Windows workstation which has had the registry change to allow clear-text passwords, we will map a drive to the BOOKS share with the user name Wilma:

1. SERVER> From the desktop, double click on the DEMO.MSC shortcut. This will allow you to remotely connect to the VISTA workstation. On the left colume of the MSC, expand ‘Remote Desktop’. Double-click on ‘Connect as Wilma’ Once connect, click Start, Run and type CMD.exe


3. Copy several files to the T: share 4. VISTA> Net use T: /delete /yes 5. Log off the Vista machine

Enabling LDAP Nested Groups Currently, there are five common ways to represent group memberships in LDAP per RFC2307-bis specification.

1. posixGroup with memberUid with uidSyntax

2. posixGroup with uniqueMember with uniqueMemberSyntax

3. groupOfUniqueNames with uniqueMember with uniqueMemberSyntax (uniqueMember takes DN+(optional)ID syntax)

4. groupOfNames with member with DNSyntax

5. organizationalRole with roleOccupant and DNSyntax

Before Data ONTAP 7, NetApp only supported syntax 1, which implies that Data ONTAP LDAP search does not search for the embedded group membership.

With Data ONTAP 7 and above, Syntax3 is also supported, which gives Data ONTAP LDAP feature the following advantage:

When the customer maps uniqueMember to the Windows member attribute, he can effectively unify Windows and UNIX group membership. This has the large advantage that Windows and UNIX group membership automatically synchronized.

The customer does not have to keep two membership lists in sync.

A member can be added to a group using the Microsoft Management Console.

You can use nested groups.

Limitations:

Maximum number of UNIX groups is limited to 32 per user.

When setting ldap.rfc2307bis.enable option to “on” for RFC2307bis support, only the first root in the search string is searched To enable this feature, on the NetApp storage:

FAS1> options ldap.rfc2307bis.enable on


FAS1> options ldap.nssmap.attribute.uniqueMember Member

FAS1> options ldap.nssmap.objectClass.groupOfUniqueNames Group

6.3.3 Integrating with DFS Distributed File System (DFS) is a technology supported by Microsoft, Novell, and UNIX that enables administrators to build a single namespace consisting of multiple shares on different servers. DFS is to files what DNS is to networking, providing the ability to organize network shares and load share, as well as increase data availability. For Microsoft, DFS is a strategic component that has been included in all Windows Server products since Windows NT 4.0.

DFS roots appear as a network share and can be hosted on Windows servers. These roots contain DFS links that reference targets (shares or directories) where data reside. DFS clients are included in Windows 98, ME, Windows NT 4, 2000, XP Pro, and Vista. Native management tools for DFS include the Microsoft Management Console snapin (dfsgui.msc), dfscmd.exe, dfsutil.exe.

Shares on NetApp storage can be the target of DFS links referred to as “leaf nodes,” but cannot host DFS roots. Beginning with version 5.0 of NetApp VFM in combination with the Data ONTAP “wide link” feature, the DFS namespace of an existing DFS root can be synchronized to a share on a NetApp storage as a wide link, such that users can access the global namespace (DFS root) from the NetApp storage rather than accessing it from a Windows server. This eliminates the need to maintain Windows servers for the purpose of hosting the DFS root (global namespace infrastructure), thereby saving hardware and administration costs.

DFS VFM

Client MMC Rich Client

Ease of Use Limited (only slightly better than old client, very limited drag-and-drop support)

Fully supports drag-and-drop, 1-to-many operations

Integrated Logical-Physical No Yes

Namespace backup/restore No

Must script command line tools

Yes

Integrated UI

Automate creation of DFS Consolidation Root via wizard

No Yes

DFS R2 VFM

Open file handling Only when file is closed Yes

Replication style Last-writer wins Master-slave

Replicate to shared cluster storage

No Yes

Graphical View of replication topology

No Yes


Local group processing No Yes, for files and directories

Auditing of actions and operations

No Yes

NetApp storage integration No Yes

Installing DFS HANDS-ON EXERCISE: DFS


SHARESETUP.BAT

Either perform the follow steps, or to automate the task, execute: DFSSETUP.BAT. Then, proceed to step #2, in section Test Drive DFS


1. From the Windows Server, Click Start, point to Programs, point to Administrative Tools, and then click Distributed File System.

2. Right-click Distributed File System in the left pane, and click New Root. The Create New DFS Root wizard appears, then click Next.

3. Make sure that Create a domain DFS root is selected, and then click Next.

4. Select the host domain for the DFS root; in our example, this is demo.netapp.com, and then click Next.

5. For the Server name, use W2003,demo.netapp.com. Click Next.

6. For the example we will call our DFS root name MASTER, and in the comments field, type: Demo NetApp Data. Click Next. For the Folder to Share, type: C:\DFSROOT. Click Next.

7. If the specified folder does not exist, you are asked if you want to create it. Click Yes to continue.

8. Click Finish to create the DFS root. After the Create New DFS Root wizard has completed, you are ready to administer your DFS root.

At this point, you have an empty DFS root in Active Directory. For this share to be interesting to users, you need to publish nonlocal shares in the DFS namespace.

To Publish Non-Local Shares

1. Right-click your DFS Root name (left side) and then click New DFS Link.

2. Specify:

Link name: Literature

Locate: \\FAS1\books

Comment: Literature from the 19th Century

Click OK.


The time-out value is the number of nonuse seconds that individual clients have to cache the referral, after which they must retrieve a fresh referral from one of the hosting DFS servers.

Test Drive DFS

Any user of Windows logged on to your domain can now access the DFS. Assuming they have proper access privileges, they can negotiate the individual junctions by using the following commands.

1.

Click Start, click Run, type cmd into the Open box, and click OK. Then type: SERVER> Net use <drive letter>: \\<your domain name>\<DFS root name>

2.

In the example used in the document, the command would be: SERVER> Net use T: \\demo.netapp.com\MASTER

To Access the DFS Root Using Windows Explorer

Click Start, click Run, and type \\demo.netapp.com\MASTER in the Open box. Click OK.

Click the DFS tab in Windows Explorer to view.

3. SERVER> Net use T: /delete /yes

6.3.4 Integrating with VSS Volume Shadow Copy Service (VSS) offers two features that can save you time and peace of mind. The first is a snapshot—think of it as a short-term backup—of all the files on an NTFS volume. This snapshot, or shadow copy, lets your users restore files for themselves—for example, if they accidentally delete a file or choose Save when they meant Save As. The second feature is VSS's ability to back up files that are currently open or locked by an application such as Microsoft SQL Server or Microsoft Exchange.

Microsoft's VSS works by using three pieces a requester, writer and provider. The requester is your traditional backup solution. Requesters send collection inquiries to the application you want to protect. This application must understand the collection inquiry sent to it by the requester and needs a writer designed to support the application data and data types. The writer is written by the application developers, not the backup vendor, to assure the most stable and consistent recoveries.

Enhanced backup using VSS-aware backup software can greatly enhance the quality of your backups. Backing up the snapshots assures that there are no open file conflicts which can result in incomplete backups.


A highly effective alternative to traditional tape-based protection is to make point-in-time shadow copies. Use of point-in-time shadow copies with Active Directory configurations allows rapid recovery from a number of specific system problems, including:

• Accidental deletion or overwrite by a user • Corruption of a user’s file • A virus that has affected a system component

Volume Shadow Copy Service supports creation of single point-in-time shadow copies—also known as snapshots—of single or multiple volumes without impacting production server performance. Used for managing data, from Direct Attached Storage (DAS) to Storage Area Networks (SANs), Volume Shadow Copy Service coordinates with business applications, backup applications, and storage hardware to enable application-aware data management. Volume Shadow Copy Service also supports backups of open files.

NetApp works with Microsoft’s VSS on both the storage level as well as on the application level. On the storage level, a LUN is presented to the Windows server, and managed through NetApp’s SnapDrive software which provides dynamic volume resizing, reporting and integration with Wndows VSS APIs to be able to create a quiesced Snapshot copy of a volume, no matter of its size, almost instantaneously.

On the application level, NetApp has several SnapManager products which work with NetApp SnapDrive and Microsoft’s VSS specific to the application to provide the same level of ease and time saving. NetApp currently offers:

• SnapManager for Microsoft Exchange

• SnapManager for Microsoft SQL Server

• SnapManager for Microsoft SharePoint®

• SnapManager for Oracle®

• SnapManager for SAP®

• SnapManager for Lotus Domino®

Just as quickly as the Snapshot copy is created, both the SnapManager and the SnapDrive product provide the ability to rapidly restore the data back to a previous point in time, usually in just seconds.

How the Client User Interface Works Shadow copies can be accessed by computers running any version of Windows 98 or newer, on which Shadow Copies of Shared Folders is a native function.

Note: Both Windows 98 and Windows 2000 Professional will require the Shadow Copies of Shared Folders client be installed – search Microsoft’s site for ShadowCopyClient.msi. The Shadow Copies of Shared Folders client pack installs a Previous Versions tab in the Properties dialog box of files and folders on network shares. Users access shadow copies with Windows Explorer and by selecting one of three options—View, Copy, or Restore, which are located on the Previous Versions tab. When users view a network folder hosted on NetApp storage, they can ask to see all old versions of a file or directory. Viewing the properties of the file or folder will present users with the folder or file history—a list of read-only, point-in-time copies of the file or folder contents that users can


then open and explore like any other file or folder. Users can view files in the folder history, copy files from the folder history, and so on.

Recovery of Files or Folders End users should be notified regarding how frequently shadow copies of the selected volume will be made. When Shadow Copies are made with Windows Servers, there is a maximum limit of 64 shadow copies, but when Shadow Copies are accessed from NetApp storage, a maximum of 255 Snapshot copies per volume are supported, which display as Shadow Copies.

Recovering a Deleted File

HANDS-ON EXERCISE: SnapRestore


SHARESETUP.BAT, SNAPNOW.BAT Either perform the follow steps, or to automate the task, execute: none

Performed from Vista

To recover a deleted file, use the following procedure: 1. J:\Setup.pdf had been deleted via the batch file. Your goal is to recover the file.

2. Navigate to the share in which the deleted file had been stored. SERVER> Open Explorer, navigate to J:\

3. Right-click the root of J:\, and select Properties from the menu. 4. Select the Previous Versions tab.

5. Select the version of the folder that contains the file before it was deleted. Notice you have three options: View, Copy and Restore. Click View.

6. View the folder and select the file that will be recovered (setup.pdf).

7. Drag and drop, or cut and paste, the file to the desktop or to the original location (J:\). SERVER> Net Use J: /delete /yes

If you wish to restore the entire folder, just select a parent folder, or select the properties of the Share name, allowing you to navigate to the folder to be restored.


Previous Version Tab On the Users desktop, the previous version tab can be enabled or disabled for viewing NetApp Snapshot copies.

From a CLI session, to remove the .snapshot or ~snapshot directory from appearing issue: FAS1> vol options <volumename> nosnapdir on

This setting turns off the ~snapshot directory from appearing to CIFS and NFS regardless of the above setting. This is the default behavior.

FAS1> options cifs.showsnapshot off

When you turns off the ability to access Snapshot copies using the previous versions feature, the volume/share might need to be remounted before these settings come into effect.

FAS1> options cifs.ms_snapshot_mode off


7 FILE-LEVEL MIGRATION

7.1.1 Migrating Files While Preserving Their ACLs VFM® (Virtual File Manager™), an OEMed product produced by Brocade, implements a sophisticated DFS (Distributed File System) management, migration, archiving, and replication solution for your DFS infrastructure. While not required to implement or manage your DFS infrastructure (with or without NetApp storage) VFM can aid significantly in creating, managing, and monitoring your DFS infrastructure. For a migration, it enables you to stage the data migration operation. You can automatically run repeated data copy operations before running the final copy and cut over users to the new location. You control when the migration operation moves from one phase to another (initial, incremental, and final phases). The feature is available for archival migration, migration and storage load-balancing policies.

Some of the other features VFM provides are:

Namespace Management

Locate and identify existing and newly created shares, volumes, and qtrees, and add them automatically to a namespace using administrator-defined policies. These policies typically filter the objects to be added based upon search string or permission based criteria.

Multiprotocol Namespace

Allow access to a namespace from both NFS and CIFS clients. The administrator can choose whether to have the CIFS namespace replicate the NFS namespace, or visa versa. In either case, they are synchronized periodically. For CIFS, manages Windows DFS and allows the NetApp storage to be configured as a target leaf-node in DFS.

Virtualize User Home Directories

Add users' home directories to a namespace and update Active Directory so that users will access their home directories through the namespace.

Make Data Highly Available

Periodically replicate the data referenced by the namespace to a secondary storage device, and failover to the secondary storage device in case the data in the namespace becomes unavailable.

Data Backup

Back up data on NetApp storage that participate in the namespace and backup the logical structure of the namespace targeting the data.

Reporting

Create and publish reports for groups of storage objects they are interested in.


Note: If you need to preserve the File SID, you will need to use a migration tool such as ADMT (resources kit). CIFS setup will destroy the original, and create a new one in the new domain.

7.1.2 Data Migration: Server Consolidation to NetApp Storage Your primary goal when implementing a consolidation project, no matter how complex or simple, should be to minimize the end-user impact during migration. The objective should be to provide a migration that satisfies your organization’s consolidation objectives, while causing as little disruption as possible.

The following three steps help you achieve the objective:

1. Create a plan for your organization’s migration and consolidation. Make sure you have a rollback scenario to rely on if things don’t go as planned. Having a premigration strategy can help administrators avoid many common mistakes.

2. Create or establish the new consolidated infrastructure by installing new servers, installing new NetApp storage, moving from Windows NT domain to Active and upgrading your network.

3. Migrate the data.

7.1.3 Planning Data Migration Your migration strategy should include an analysis of the following:

• Number of Windows file servers that will be consolidated • Amount of data to be migrated (number of files, size of files) • User/group ownership and file- and directory-level ACLs • Host and file share naming conventions, including home directory shares • User logon scripts, desktop shortcuts/links, OLE links (Microsoft Word, Excel), or other

embedded Universal Naming Convention (UNC) paths that directly access mapped drive letters

Understanding how much data and how many files need to be migrated will give you some idea of how much time will be required to perform the migration. Consider also that it will take a greater amount of time to migrate a larger number of smaller files than a smaller number of larger files. Having this information can be useful when planning how much time an administrator will need to prepare for in the data transfer portion of the migration. The speed and available bandwidth on the existing network will also limit the amount of data that can be migrated within a certain time period. Consider using private, out-of-band Gigabit networks or Gigabit crossover links for data migration purposes. In addition to the time required for migration, other factors that affect migration administration and complexity are the number of Windows servers to be consolidated, number of shares, host/share name contention, home directories, and explicitly mapped network drives from clients and applications.

Windows NT 4 to Active Directory Migration Tools

The following is a list of the most commonly used tools

• ADMT 2.0 – Active Directory Migration Tool (ADMT) 2.0

• Aelita – Aelita Domain Migration Wizard

• BindView – BindView by Admin for Windows Migration


• NetIQ – NetIQ Domain Migration Administrator

• Microsoft – The Microsoft Windows Server 2003 Resource Kit

Data Migration Tools

1. Backup/Restore from Tape - Although backing up to a tape and restoring from it could be considered a valid migration, it is highly discouraged. Tape is regarded as an archive medium, and the integrity of it cannot be guaranteed. This method requires more manual administration and is more prone to error.

2. SnapMirror, qtree SnapMirror, NDMPcopy and Volcop – refer to Data ONTAP Documentation for best-practices.

3. Xcopy, Scopy, and RoboCopy - utilities that are freely available from the Windows NT 4.0 and Windows 2003 Resource Kits or from the Microsoft Web site.

4. NTSEC Software from Pedestal Software.

5. Small Wonders Secure Copy from ScriptLogic.

6. NetIQ Server Consolidator from NetIQ.

7. Quest Consolidator from Quest Software.

8. VFM from NetApp.

9. Rainfinity Rainstorage for Windows Storage Consolidation Solution.

10. Microsoft 2003 Resource Kit - Many useful tools and utilities for doing simple domain migrations including subinacl.exe to check and find and replace ACLs if necessary, sample syntax of commands, and test modes before committing.

11. Hyena - Used mainly for migrating local groups from one NetApp storage to the other. Hyena will quickly copy all of the groups to the destination NetApp storage while keeping the SIDs the same.

12. FILEACL V2.8.0.1 - FILEACL is a Windows command-line tool that allows an administrator to change, replace, and manipulate ACLs on NTFS volumes (or qtrees for the NetApp storage).

NetApp recommends using the Microsoft recommended method of assigning rights to file systems, that is UGLR.

Users belong to ... Global groups, which belong to ... Local groups, which are assigned access to ... Resources.

The problem is that Local groups have a nonglobal SIDs between machines. That is, each NetApp storage assigns its own local SIDs to local groups in its /etc/lclgroups.cfg on the root volume. That SID gets moved with the ACL data to the destination, but the destination machine can't resolve its membership with its local groups.

Import Local Groups into other NetApp Storage If you are migrating local groups from NetApp storage to NetApp storage, copy the localgroups.cfg file from the source to the destination and run the following to import all the local groups:

FAS1> useradmin domainuser load <fullpath to localgroups.cfg>


This will create local groups with the same name but a different SID. The group SID is dependent on the NetApp storage SID. So this is fine as long as those local groups are not used for file level security permissions. If the user did use the local NetApp groups on file level security you have two options;

1) The supported method is using securecopy which will retain the SIDS during migration. Refer to the HDMNAS Decision Tree Matrix for further information: http://ps-web.corp.netapp.com/cv/nsdatamigration.htm (Internal)

2) The unsupported method is to copy over filersid.cfg and lclgroups.cfg from the old NetApp storage to the new and reboot. Both storage units cannot have CIFS running at the same time due to conflicting SIDs. The advantage here is you can use SnapMirror for the data migration. The downside is there is a lot more risk if you don’t know what you’re doing.

7.1.4 Migrating Data Refer to the internal Windows NT to Active Directory Domain and Data Migration with NetApp storage (TR3380) for specific guidance, recommendations, and tools for data migration to a NetApp storage.

One of the most commonly used Microsoft tools for data migration is Microsoft's cacls.exe, xcacls.exe and the later xcacls.vbs. Using the VBS is significantly faster than using the EXE.

http://support.microsoft.com/kb/318754 (old)

http://support.microsoft.com/kb/825751 (current)

The VBscript version here: http://download.microsoft.com/download/win2000platform/webpacks/1.00.0.1/nt5/en-us/xcacls.exe.

7.2 BEST PRACTICES When renaming user accounts with home directories, use WAFL Credential Cache (WCC).

wcc -x will flush the credential cache immediately. You can also specify account names to delete if needed.

WCC won't clear the SIDcache, but that is a mapping of the SID to the username (cosmetic) so we don't need to go back to a DC to display that name properly. You could set the timeout to 1 or 0 or some low number so it expires quickly, or as suggested, disable it; in most situations this shouldn’t be required.

For more information, refer to FAS1> man na_cifs_sidcache


7.3 DEMO

7.3.1 VFM - Enables non-disruptive expansion and consolidation VFM enables you to seamlessly consolidate data from multiple heterogeneous file servers across heterogeneous file storage platforms. By first deploying a global namespace, you can use VFM data movement features to quickly and easily consolidate or expand storage resources. The global namespace masks physical changes from users during consolidation, and VFM storage policies significantly reduce operator activities during the consolidation. VFM enables one-step data migration between storage devices to optimize capacity and achieve server consolidation even when devices are from different vendors and are geographically dispersed. By using VFM, you can perform multiple simultaneous consolidation jobs and reconfigure file storage without affecting how users access the files, because VFM automatically and transparently redirects users to the files in their new locations.

Migration Options:

• Include or exclude subfolders

• Delete orphaned files

• Allow loss of security and alternate file streams

• Selectable criteria for file transfers including inclusion and exclusion lists.

• Configurable retries for failures during transfer of a file

• Threshold for continual failures

• Event Log details

• Script execution before and after replication to provide solutions such as e-mail notifications, cleanup, zip or unzip files and posting event log entries

• Optional differential replication only transmits blocks of changed data

Best Practices

• Migration does not require Windows DFS namespace, but DFS provides the layer to allow future storage changes to remain transparent to users.

• Each migration task is run as a thread

o Can speed up migration by combining with Replication

o By default, 20 threads available

• Turn off vscan during bulk migration

• Don’t setup overlapping replication / migration jobs


7.3.2 Migrating Files with VFM HANDS-ON EXERCISE: VFM for File Migration


SHARESETUP.BAT, DFSSETUP.BAT

Either perform the follow steps, or to automate the task, execute: VFMSETUP.BAT. Then, proceed to step #3


Installing VFM 1. The account which will be used for VFM requires “Logon as a service” be enabled. This step

has already been performed as a reboot is required to active the change. 2. If you have not already installed the Microsoft SQL Server Desktop Edition from the Northern

Storage Suite lab exercise, install MSDE now with the following switches: SERVER> C:\CIFSDEMO\Northern\MSDE\setup SECURITYMODE=SQL SAPWD=netapp1

Note: A reboot IS required before proceeding with the installation of VFM.

3. Following the reboot, login and on the tool bar (bottom right side of desktop), right click SQL Server Agent. Select “Open SQL Server Service Manager.” Under Services, select “SQL Server Agent.” Click Start. Check Auto-start service when OS starts. Close the dialogue.

SERVER> C:\CIFSDEMO\VFM\VFMInstall.exe 4. Welcome to the NetApp VFM 6.1.1 Installation Wizard, click Next 5. On the Accept License Agreement dialogue, click, "I accept the license agreement", click

Next 6. On the NetApp VFM 6.1.1 Release Notes dialogue, click Next 7. On the Compnenent Selection dialgoue, accept the default and click Next 8. On the Destination Lcoation dialogue, accpet the default and click Next 9. On the Application Data Storage dialogue, accept the default and click Next 10. Enter the License Information, followed by Next

Serial Number: NETAPP_VFM_DEMO_14_NOT_FOR_PRODUCTION_USE_10232008 License Type: Evaluation Activation Number: VFME1-1BL06-LV8E7-TNI6A-UYZ2H


11. On the Desktop Shortcut Configration, accept th create a desktop shortcut, click Next 12. On the NetApp VFM Service Account Credential, for domain\Username use:

demo\administator, passowrd use netapp1, click Next 13. Accept to use an existing Microsoft SQL Server instance, click Next 14. On the Microsoft SQL Server Name: localhost, 15. On the Connect using, select Microsoft SQL Server authentication. For the Login ID, use sa,

and for password use netapp1, click Next 16. Use SX for the Database Name, click Next 17. Click Next on the Review Installation Settings dialogue 18. NetApp VFM Setup Completed screen will appear, click Finish Configure VFM 1. FAS1> options cifs.show_snapshot off 2. W2003> Open VFM console (Use the Desktop shortcut) 3. A dialogue will open Displaying Existing DFS Root’s. Expand DEMO, select

demo.netapp.com\MASTER 4. Click Tools (on the menu bar), select Options, Click + to expand the System Options. 5. Click Remote Shell. On the right side under Shell Credentials, enter the Username: root,

and password: netapp1. Click OK 6. Expand the Admin View (left side) and expand the Data Movement Policies folder. 7. Right-click the Replication Policies and choose New Replication Policy. 8. Name the policy Software Distribution. 9. Click Browse to browse for the source link located at

\\W2003.Demo.netapp.com\c$\CIFSDEMO\Northern Double click Physical Resources Double click Microsoft Windows Networks Double click DEMO Double click Domain Controllers Double click W2003.demo.netapp.com Double click C$ Double click CIFSDEMO Click Northern, then click OPEN

10. To add the target, click Add, then type: \\demo.netapp.com\MASTER\Literature followed by tab

11. On the left side, click Replication Filters. 12. In the Exclude Files field type: ”*.htm” ”*.mp3” and click OK. 13. Highlight the policy you created and choose Start Replication Now. 14. Verify that the *.htm and *.mp3 files were not replicated. 15. Look at the TR recommended in the following section to guide you through other VFM

configurations, reporting and integration with DFS.


7.4 NETAPP TECHNICAL REPORT REFERENCE Virtual File Manager Best Practices – March 2008


Virtual File Manager Best Practices – June 2008


Best Practices for Secure Configuration of Data ONTAP 7G – May 2008


Integration of a NetApp Storage System with a UNIX Based LDAP Server – April 2006

http://media.netapp.com/documents/tr-3464.pdf Unified Windows and UNIX Authentication – November 2006 http://media.netapp.com/documents/tr-3458.pdf


8 FUTURE OF NETAPP CIFS

8.1 OVERVIEW Microsoft launched an initiative in 1996 to rename SMB (Server Message Block) to Common Internet File System (CIFS), and added more features, including support for symbolic links, hard links, larger file sizes, and an initial attempt at supporting direct connections over TCP port 445 without all the NetBIOS trimmings (a largely experimental effort that required further refinement).

Whenever files are copied between Windows systems, the SMB protocol is used. Version 1 of this protocol, which is still in use today, was developed 15 years ago and was introduced with Windows 3.11 for Workgroups. Since the fastest networks in use at the time generally offered a maximum transfer rate of 10 Mb/s, the protocol has become out of date. Indeed, with Gigabit Ethernet interfaces now a common feature even on budget motherboards.

With Windows Vista (released in 2006), Microsoft introduced Server Message Block 2.0.

8.1.1 SMB 2 and Diagnostics Microsoft introduced a new version of the SMB. SMB 2.0 improves prior versions of SMB for Windows by adding the ability to compound multiple actions into a single request, which significantly reduces the number of round-trips the client needs to make to the server, improving performance as a result. SMB1 also has a compounding mechanism — known as AndX — to compound multiple actions, but Microsoft clients rarely use AndX.

• SMB2 supports larger buffer-sizes, which can provide better performance with large file-transfers.

• SMB2 introduces the notion of "durable file handles": these allow a connection to an SMB server to survive brief network-outages, such as might occur in a wireless network, without having to construct a new session.

• SMB2 includes support for symbolic links.

• SMB 2.0 greatly grows the restrictive constants in the protocol, so we never need to worry about the protocol itself being the limiting factor for scalability. This includes increasing the number of concurrent open file handles on the server, and the number of shares that a server can share out, among other things.

• The SMB 1 protocol often uses 16-bit sizes. SMB2 uses 32 or 64 bits for many of these, and 16 bytes in the case of file-handles.

• Support for sending multiple SMB commands within the same packet. This reduces the number of packets sent between an SMB client and server, a common complaint against SMB 1.0.

• Increases the restrictive constants within the protocol design to allow for scalability. Examples include an increase in the number of concurrent open file handles on the server and the number of file shares that a server can have.

• Stronger end-to-end data integrity protection, using the SHA256 hash algorithm instead of MD5 for signing.

• Improved throughput across networks that have disparate characteristics.

• Higher scalability of the number of files that a client may open simultaneously, as well as the number of shares and user sessions that servers may maintain.

• Quality of Service guarantees from the server for the number of requests that can be outstanding against a server at any specified time.


o Client may request credits for simultaneous operations

o Server should grant credits based on available resources

o Server can adjust client-granted credits in responses

o More credits allow more parallel operations

o Server sends an interim response for a request that could block for a long time

Durable Handles:

Durable Handles are the file handles that persist across SMB 2.0 sessions. They are designed to prevent data loss caused by short network outages - by absorbing writes cached on the client on a different SMB 2.0 session. When a client opens a file, it specifies if it needs the file handle to be durable. If the current connection goes away, the client would try to use the durable handle on a different connection if it is still valid on the server. The server on it's part issues a durable handle only if it supports the functionality. Upon session disconnection, the server makes the handles available for reclaim by the same user on a different a connection.

8.2 BEST PRACTICES SMB 2.0 will ship in Data ONTAP 7.3.1, December 2008.

8.3 DEMO

8.3.1 SMB 2 Configuration Copying from \\Server Share: A Classic Application for the SMB Protocol

In specifying and creating version 2.0 of SMB, Microsoft has brought the protocol up to date. Among its benefits is that it can combine several requests in one data packet, meaning that more requests can be sent using fewer packets. Effectively, this reduces the overhead and consequently improves data throughput. Besides, more connections can be kept alive simultaneously, which in turn means more files can be open at the same time, improving the quality of the connection.

Bandwidth Comparison: SMB1 vs. SMB2 on the Internet

In order for the protocol to be used, both the server and the client need to support SMP 2.0. Windows Vista already uses SMB 2.0 and can thus benefit from the higher performance. The protocol is chosen automatically when a file transfer is initiated without requiring any additional settings by the user.

Microsoft claims that: with its improved TCP stack, just upgrading clients to Windows Vista can yield throughput and time-to-completion improvements of up to 2.5X over Windows XP. Complete migration servers to Longhorn, to also take advantage of the enhanced SMB2, can yield throughput and time-to-completion improvements of up to 3.5X over Windows XP/Windows Server 2003.

The version of SMB used for file sharing is determined during the SMB session negotiation. If both the client and server support SMB 2.0, then SMB 2.0 is selected during the initial negotiation. Otherwise SMB 1.0 preserving backward compatibility. The table below shows the version of SMB that will be used in different client/server scenarios:


Currently Microsoft supports SMB 2.0 on Windows 2008 and Vista; earlier versions of Windows support only SMB 1.0.

Both SMB 1.0 and 2.0 are enabled by default on Windows Vista and Windows Server 2008. In some testing and troubleshooting scenarios it might be necessary to disable either SMB 1.0 or SMB 2.0. However, it should be noted that this is not a recommended practice. To disable SMB 1.0 for Windows Vista or Windows Server 2008 systems that are the “client” systems (accessing the network resources), run the following commands:

To disable SMB 2.0 for Windows Vista or Windows Server 2008 systems that are the “client” systems run the following commands:

sc config lanmanworkstation depend= bowser/mrxsmb10/nsi

sc config mrxsmb20 start= disabled

Note: there's an extra " " (space) after the "=" sign.

To enable back SMB 2.0 for Windows Vista or Windows Server 2008 systems that are the “client” systems run the following commands:

sc config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi

sc config mrxsmb20 start= auto

Note: there's an extra " " (space) after the "=" sign.

To disable SMB 1.0 on a Windows Vista or Windows Server 2008 system that is acting as the “server” system (hosting the network resources), a registry modification is required. Navigate to the HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters key. If there is no REG_DWORD value named Smb1, you will need to create it. This value does not exist by default. Once the value is created, set the value to 0 to disable SMB 1.0 or 1 to enable SMB 1.0.

Finally, to disable SMB 2.0 on Windows Vista or Windows Server 2008 systems that are acting as the “server,” navigate to the registry key listed above. Instead of creating the Smb1 REG_DWORD value, you would create a REG_DWORD value called Smb2. Set the value to 0 to disable SMB 2.0 and 1 to enable SMB 2.0.

8.4 NETAPP CIFS SMB VARIABLES (Available in Data ONTAP 7.3.1 and above)

Options

– cifs.smb2.enable (default vaule will be “off”)

– cifs.smb2.signing.required (default vaule will be “off”)

– cifs.smb2.client.enable (default vaule will be “off”)

– cifs.smb2.durable_handle.enable (default vaule will be “on”)


– cifs.smb2.durable_handle.timeout (default vaule will be 16 minutes)

Command

– cifs sessions –p [smb|smb2]

New option "cifs.smb2.enable" to enable/disable this feature. When this option is disabled NetApp storage will not accept any new SMB 2.0 sessions but the existing sessions will not be terminated.

New option "cifs.smb2.signing.required" to enforce signing on all SMB 2.0 sessions.

New option "cifs.smb2.client.enable" to enable/disable SMB 2.0 client capability on NetApp storage. When this option is enabled, NetApp storage initiated connections to Windows servers will use SMB 2.0 protocol. In case the Windows server does not support SMB 2.0 protocol then NetApp storage will fall back to using SMB. If a session had been established over SMB 2.0 and later this option is disabled, existing sessions will not be terminated, NetApp storage will continue to use SMB 2.0 for the existing sessions but no new sessions will attempt to use SMB 2.0.

New option "cifs.smb2.durable_handle.enable" to enable/disable the durable handle functionality for SMB 2.0 clients. If this option is enabled, the open files from a client are preserved when the client gets disconnected from the NetApp storage. These open files can be reclaimed when the client reconnects to the NetApp storage.

New option "cifs.smb2.durable_handle.timeout" to configure the duration in seconds for which NetApp storage will preserve the durable handle after a temporary network failure. This timer has a default value of 16 minutes, but its value could be changed by system policy to any range between 5 seconds and infinite (4,294,967,295 seconds)

“cifs sessions” command will take a new option, ‘-p’. This option filters the sessions on the basis of protocol version used. When -p option is used with 'smb' as the argument, only SMB 1.0 sessions are displayed. When -p option is used with 'smb2' as the argument, only SMB 2.0 sessions are displayed. When -p option is not used, both SMB 1.0 and SMB 2.0 sessions are displayed. The -p option can be used along with -c and -s options

8.5 SMB2 HIDDEN OPTIONS FOR TWEAKING PERFORMANCE (Available in Data ONTAP 7.3.1 and above)

Change negotiated buffer sizes

cifs.smb2.max_read_size

cifs.smb2.max_write_size

cifs.smb2.max_transact_size

Change the max number of outstanding requests sent by a client without receiving a response.

cifs.smb2.max_credits_granted


9 TROUBLESHOOTING AND PACKET TRACES HANDS-ON EXERCISE: Troubleshooting CIFS



• For CIFS AD Domain status (Windows 2000 and later) one should not be using "cifs

testdc" but FAS1> cifs domaininfo

• All DCs addresses are discovered at once.

• After CIFS Setup, to force a domain rediscovery, type: FAS1> cifs reset dc

• CIFS Cached in the registry: FAS1> Priv set advanced

FAS1*> registry walk auth

FAS1*> options cifs.trace_dc_connection <on or off>

• Stop CIFS service: FAS1> cifs terminate

• Stop CIFS on particular volume: FAS1> cifs terminate –v <volume>

• Start CIFS service: FAS1> cifs restart

• Start CIFS on particular volume: FAS1> cifs restart –v <volume>

• Test domain response using Packet INterrupt Groper (PING): FAS1> ping –s <IP or DNS>


Gathering More Information

What remote diagnostics/scripts should be run to gather troubleshooting information?

• Use "sysstat -x 1" to determine how many CIFS ops/s and how much CPU is being utilized.

• Check /etc/messages for any abnormal messages, especially for oplock break timeouts.

• Use perfstat to gather data and analyze CIFS performance (note information from ifstat, statit, CIFS stat, SMB_hist, messages, and general CIFS info).

• A network trace using pktt might be necessary to determine what is being sent/received over the network.

• Client troubleshooting may include review of event logs, ping of NetApp storage, test using a different NetApp storage or Windows server.

• If it is a network issue, check ifstat -a, netstat -in for any I/O errors or collisions.

• If it is a gigabit issue check to see if the flow control is set to FULL on the NetApp storage and the switch.

• On the NetApp storage if it is one volume having an issue, do df to see if the volume is full.

• Do df -i to see if you are running out of inodes.

• From statit output if it is one volume that is having an issue check for disk fragmentation.

• Try the netdiag -dv command to test NetApp storage side duplex mismatch.

• If the slowness only happens at certain times of the day, check if the times coincide with other heavy activity like SnapMirror, Snapshot copies, dump, backups, and so on on the NetApp storage.

• Check if they have antivirus application running on the client. This can cause performance issues especially when you are copying multiple small files.

• Check cifs stat to see if the Max Multiplex value is near the cifs.max_mpx option value. Common situations where this might need to be increased are when the NetApp storage is being used by a Windows Terminal Server or any other kind of server that might have many users opening new connections to the NetApp storage. NetApp Internal Knowledge base article ntapcs4193 describes the issue further.

• Check the value of OpLkBkNoBreakAck in CIFS stat. Nonzero numbers indicate oplock break timeouts, which cause performance problems.

9.1.1 CIFS Configuration Files Internal (editing is not supported):

o cifsconfig_setup.cfg

o cifsconfig_share.cfg

o cifssec.cfg

o filersid.cfg

o krb*


o filersid.cfg

o lclgroups.cfg

Manually Editable:

o cifs_nbalias.cfg

o cifs_homedir.cfg

o usermap.cfg

9.1.2 Diagnostic Troubleshooting with PKTrace HANDS-ON EXERCISE: PKTrace



Collect a Network Trace with pktt FAS1> pktt start <interface>|all [-d dir] [-s size] [-m pklen] [-b bsize] [-iipaddr ...] [-v]

pktt pause <interface>|all

pktt dump <interface>|all [-d dir]

pktt stop <interface>|all

pktt status [<interface>|all] [-v]

Each of the subcommands must be followed by an interface name or the word "all." A small exception to this is that "pktt status -v" is equivalent to "pktt status all -v.” The available interface names can be found using "ifconfig -a" or "pktt status."

pktt start

The "start" subcommand is used to start tracing, (or restart if it has been paused). The packet trace data is stored in "tcpdump" format in a circular buffer in memory. The flags that can optionally be supplied are as follows:

-d dir

This specifies the path to an existing directory in which the trace data file will be written. The file will always have the name "<interface>.trc" where "<interface>" is the interface name (for example, e4, fa3, and so on). If this option is missing, the trace data will only be collected in memory, and after the buffer fills, new packets will replace existing packets. However, it is always possible to dump the contents of the buffer at any time using the "pktt dump" command. One thing to be aware of when writing trace data to disk is that if the file system cannot keep up with the network traffic you might not log all packets. This will show up in the "dropped" counts when looking at status. Along with this, you should remember that logging all traffic may generate a heavy write load on the


NetApp storage which might bog it down. If possible, use the IP filter to reduce the amount of data to log. Note that the default value of the -b flag is too small when logging to disk if there is much traffic. You should set -b 128k or larger. (But not too large! See below.)

-s size

This allows you to set a maximum size of the trace file. If you don't specify this the file can grow to 32GB, so set it to a reasonable value if you think there is a chance you might forget you have left the trace going. This parameter is only useful in conjunction with the "-d" option. After the maximum size has been reached, packets continue to be logged to the buffer, but not to disk.

-mpklen

This sets the length at which packets will be truncated. The default is 1500 bytes, which results in full packets for Ethernet. Note that in 5.3 the default of 1500 is incorrect for Ethernet. You must override with "-m 1514" to get the full packets. It is sometimes useful to limit the data stored when every byte of the packet is not critical. However, for many debugging tasks it is useful to have the entire packet. In the case where the packet size can be larger than 1500 you might want to specify a larger maximum. However, many of the decoders refuse to deal with packets larger than 1500 bytes so you should only specify a larger value if that seems critical to finding the problem.

-bbsize

This sets the buffer size, which may be specified as a number with an optional trailing “k” or “m” multiplier. The default is 32K, which should be large enough to find "packet of death" bugs and similar problems. You should use a value of at least 128K when using the -d option. The value may range from 8K to 128M, but only in the most exceptional cases would it be necessary to increase the size beyond 1-2M. In cases where the network is very busy and it is not practical to log all the traffic to disk you might need to use a larger buffer.

WARNING! Do not specify a value larger than 3MB. You might hang the system console or cause WAFL to run out of memory.

-iipaddr [-iipaddr] ?

This allows limited filtering capability. Up to four IP address may be specified, which causes only traffic to or from any of those IP addresses to be logged. This will prevent logging of any non-IP (for example, arp/rarp) traffic.

-v

This causes "pktt status -v" information to be displayed as tracing starts.

Examples of "pktt start" pktt start e0

This will start capturing network traffic from the "e0" interface. All traffic will be logged to a 32K circular buffer. Or, if tracing had been suspended previously it would be restarted.


pktt start fa3 -d / -s 100m -b 128k

This starts capturing traffic on the "fa3" interface, writing to a file called "/fa3.trc" which will be allowed to grow to a maximum size of 100MB, with a 128K buffer.

pktt start el10 -d /home -m 10k -b 1m -i ehost1 -i ehost2

This starts capturing traffic to and from the hosts "ehost1" and "ehost2,” storing the traces into the file "/home/el10.trc.” Up to 10K of each packet will be stored, in a 1MB buffer.

pktt start all -b 128k -i 172.20.4.1

All interfaces will start capturing traffic to and from the specified IP address. This is a quick way to look at traffic if you're not sure which interface to use but you want to see the packets from one or more IP addresses.

pktt pause

The "pause" subcommand is used to temporarily stop capturing traffic from one or all interfaces. If any unwritten data is in the trace buffer it will be flushed to disk. Use "pktt start" without any options to restart a paused interface.

pktt dump

The "dump" subcommand causes the contents of the packet trace buffer to be written to a file. If the "-d [dir]" option is used the file will be written to that directory, otherwise it will be written to the root directory of the root volume. The name of the file is always <interface>.trc and the contents are in "tcpdump" format. If a file by that name already exists it will be overwritten.

pktt stop

This causes all tracing to stop on the named interface, or all interfaces. If any unwritten data is in the trace buffer it will be flushed to disk. If you have not dumped the trace data and you were not tracing to a disk file, the trace data will be lost. This action is not confirmed, so be careful when using this command.

pktt status

This can be used to display the buffer and file status of an existing trace. Using "pktt status -v" will give you full tracing status for all interfaces.

Collect pktt data from the appliance. An example of the pktt command usage is: FAS1> pktt start all -b 128k -d /dir -s max_file_size[k|m] -m mtu_size -iclient_IP_or_hostname

This will create a packet trace file called interface.trc that is less than or equal to max_file_size[k|m]. The file will be stored in the directory dir after capturing network data seen between the appliance and the client interface client_IP_or_hostname.



Working with a Packet Trace

1. Start the packet trace by executing the customized command from the previous step.

2. Reproduce the network related problem.

3. Enter pktt stop all.

This stops the capturing and flushes the data to the file /dir/interface.trc.

An interface.trc file will be created for each appliance interface.

4. To fetch the trace file from the NetApp storage, map the drive using CIFS or NFS, and then download the file.

5. For assistance in reading the packet trace, contact NetApp Technical Support.

Note: The .trc files are in tcpdump format, so any software capable of manipulating these files (for example, tcpdump, tcpview, ethereal) can open a file generated with pktt.

The “capconv” utility is used to convert the PKTT file to Netmon format. For more information, see http://now.netapp.com/NOW/download/tools/capconv/.

Once the data is extracted, use a Netmon format compatible network packet analyzer (such as Windows Netmon and Ethereal) to analyze the packet trace.

9.2 SLOW CIFS AUTHENTICATION Items to look at:

• Slow or overloaded Domain Controller

• Wrong Domain Controller

• Massive amounts of authentication traffic

• Poor NIS or LDAP performance, i.e. NIS group caching

• Large group memberships in CIFS credentials

• Gather:

o pktt filtered for client and DCs (NIS, LDAP) o FAS1> cifs DOMAININFO <domain>

o FAS1> cifs STAT output

o FAS1> cifs SESSIONS –t

o Size estimate for /etc/lclgroups.cfg

• For CIFS mapping failures, gather:

o Pktt with client, DC (NIS and LDAP)

o Output of wcc –s and wcc –u for troublesome user. Turn options CIFS.trace_login on.

o Pktt during wcc commands above, filtered for DC, NIS, and LDAP servers

• For NTLM failures, gather:


o pktt with client, DC (NIS and LDAP)

o Console output during failure with options CIFS.trace_login on

o Output of CIFS DOMAININFO

9.3 MISCELLANEOUS TROUBLESHOOTING To retain more than the normal six weeks of /etc/messages files, here are two options:

• You can configure the syslog.conf file to log to a remote server that has a more configurable syslogd.

• Utilize Snapshot copies and go back to the normal six weeks from the snap schedules.

Using RSH to Log Out an Active NetApp Telnet User/Session

Since Data ONTAP only allows a single user to login at a time through telnet or SSH, it can be a hassle when you need to log in for an emergency and someone is already logged in. You can log the individual off with the following command:

CLIENT> rsh FAS1 -l root:netapp1 logout telnet

The following commands can help you find the offender, if you didn’t want to log the individual off with the previous command.

CLIENT> rsh FAS1 -l root:netapp1 netstat -an | findstr "\.22

\.23 " This gives you the IP address of the machine that is connected over port 22 (ssh) or 23 (telnet).

Once you have the IP address, you can then find out the HOST name by issuing the following string.

CLIENT> nbtstat -A <IP-ADDR>

i.e. CLIENT> nbtstat -A 192.168.10.101 Example of nbtstat output:

Local Area Connection 9:

Node IpAddress: [192.168.10.101] Scope Id: []

NetBIOS Remote Machine Name Table

Name Type Status

---------------------------------------------

W2008 <00> UNIQUE Registered

W2008 <20> UNIQUE Registered

WORKGROUP <00> GROUP Registered

MAC Address = 00-0C-29-97-71-29


9.4 NETAPP TECHNICAL REPORT REFERENCE Best Practices for Secure Configuration of Data ONTAP 7G – May 2008



10 SIZING AND PERFORMANCE

10.1 OVERVIEW Sizing of CIFS home directories has always been a complex task as there are numerous factors that need to be considered while carrying out a sizing exercise. There are no industry-standard workload and benchmarks for CIFS home directory deployments. Work load analysis and benchmarks have been carried out based on different customers' data.

Sizing Affects Performance

In typical home directory environments, read and write operations form only a small part of the overall traffic. Operations such as openX, closeX, attribute operations (for example, getattr, query_path_info, query_file_info), directory operations (for example, find_first2 and Windows NT Trans Notify), and other operations are also present in significant proportions.

Since operations other than Read and Write form a significant proportion of the CIFS operations observed at typical home directory deployments, to size properly for such deployments, the cost of all the other operations in the mix has to be taken into account.

Depending upon the level of information about the traffic available, we suggest the following three sizing methodologies:

• Method 1: Sizing using predefined user models to be used when very little information is known about the customer deployment

• Method 2: Sizing for existing third-party CIFS deployment where it is possible to collect some workload information.

• Method 3: Sizing at a preexisting NetApp deployment where detailed CIFS information can be collected

Additional Performance Factors That Affect Sizing

(These are built into the NetApp CIFS sizer)

• No degradation on failover requirement

When sizing with clusters many customers require no performance degradation when a cluster failover occurs. To size for these scenarios you need to account for at least 50% headroom in CPU.

• Virus Scanning

10% overhead should be added to the sizing calculation based on the virus scanning rates to be in the range of 50-100 files per second (which is what NetApp observed in many real-life deployments).

• SnapMirror

To account for the SnapMirror CPU impact, increase the concurrent user count by 20% to 30% and size for that many number of users.

Note: If SnapMirror activity can be scheduled to happen during nonpeak hours then you need not worry about any extra overheads.

• SMB signing

SMB signing is not supported in pre-7.0.1 releases. Turning on SMB signing in 7.0.1 adds a CPU overhead of about 40%, whereas in 7.0.2–7.2.5.1 the CPU overhead is about 23%.


10.1.1 High Availability with NetApp Active-Active Clustering In today’s competitive environment, data is the key asset of many businesses, and assuring that data is always available and readily accessible is absolutely essential. Loss of data service could lead to lost productivity, revenue, and even customer loyalty. Organizations with a data availability strategy that relies on a single hardware device risk losing data access if that device goes offline.

NetApp clustered failover delivers a robust and highly available data service for business-critical environments. Installed on a pair of NetApp storage controllers, NetApp clustered failover assures data availability by transferring the data service of an unavailable storage controller to the other controller in the cluster.

Delivering greater than 99.999% data availability, NetApp clustered failover can benefit any enterprise, workgroup, or e-commerce application that has stringent uptime requirements. Clustered failover administration tasks are simple, intuitive, and easy to use, minimizing management overhead and reducing operator error.

Automatic and Manual Failover and Giveback

NetApp clustered failover constantly monitors the health of the clustered storage. If it detects a failure, it automatically initiates a failover operation to transfer the data service to its partner controller. Data integrity is assured during the transfer. Once the failover operation completes, the takeover controller will immediately resume data service for the failed NetApp storage. The data service of the takeover controller is never impacted and is fully available during the entire failover operation. The takeover controller maintains this dual data-serving mode until an administrator initiates action to restore data service to its original state. The entire failover process is automatic, with no manual intervention required at any point.

Active-Active Configuration An active-active configuration is two storage systems (nodes) whose controllers are connected to each other either directly or through switches. You can configure the active-active pair so that they share access to a common set of disks, subnets, and tape drives, or you can configure them to have two distinct sets of storage, each owned by one of the controllers.

The nodes are connected to each other through a cluster adapter or an NVRAM adapter, which allows one node to serve data to the disks of its failed partner node. Each node continually monitors its partner, mirroring the data for each other’s nonvolatile RAM (NVRAM).

Benefits of Active-Active Configuration

Configuring storage systems in an active-active configuration provides the following benefits:

• Fault tolerance

When one node fails or becomes impaired a takeover occurs, and the partner node continues to serve the failed node’s data.


Note: CIFS is session oriented. In order to have transparent failover for a CIFS client during CFO, SMB 2.0 must be enabled and be used for both the NetApp storage and the client. (Refer to section 8.1.1 on SMB 2.0). Otherwise, when a clustered failover occurs, all CIFS sessions on the failed node are terminated. The CIFS client will certainly notice, but whether a user will notice depends on how abstracted the user is from the CIFS session. For example, is the user's application is cluster aware, and will it automatically try to reestablish the session and pick up where it left off? Or does it complain of error?

• Nondisruptive software upgrades

When you halt one node and allow takeover, the partner node continues to serve data for the halted node while you upgrade the node you halted.

For more information about nondisruptive software upgrades, see the Data ONTAP Upgrade Guide.

• Nondisruptive hardware maintenance

When you halt one node and allow takeover, the partner node continues to serve data for the halted node while you replace or repair hardware in the node you halted.

10.1.2 CIFS Sizing on NetApp Storage The NetApp CIFS sizer is located at http://perf-build.lab.netapp.com/CIFSSizer/CIFSizer.jsp (internal access only).

HANDS-ON EXERCISE: CIFS Sizing



NetApp CIFS Home Directory Sizer Version 3.8.4

Refer to Appendix C for explanations of each field.

Section 1 of Sizer: CIFS Home Directory Sizer FAQs

General Information

Customer Name:

Location:

Region:

SE/CSE/PSE(s):

Field Specialist:

Requester E-Mail:

Notes:

Sizing Request Identifier:


Vantive # (if applicable):

Section 2 of Sizer: General NetApp Storage Specifications

Data ONTAP Version: (7.0.x, 7.1.x, 7.2.x or 7.3)

Local Cluster:

Failed-Over Performance:

NetApp storage Platform:

Max # of Clusters (optional):

CPU Headroom:

Min # of Clusters (optional):

Section 3 of Sizer: Backend Specifications

Preferred Drive Type:

Capacity Reserve:

RAID group Size: 16 (default)

RAID Type: RAID-DP® or RAID 4

Map to Full Shelves: Yes/No

Section 4 of Sizer: HomeDir Specifications

Sizing Options: Fresh Install or Migration from third party or Upgrading existing NetApp

Virus Scanning: Disabled/Enabled

SnapMirror: Disabled/Enabled

SMB Signing: Disabled/Enabled

Section 5 of Sizer: User Profiles in Target System

# of Profiles (1 – 10)

User Type: Light, low, medium or heavy

Desired # of Users:

Concurrency % (10, 20, 30, 40, 50, 60, 70, 80, 90 or 100%)

Home Directory Size/User (GB)

Each home directory deployment is unique in the way it has been deployed, users supported, the number of concurrent users, roaming profiles, disk and network traffic, presence of Citrix environment, antivirus scanners, use of multiple protocols, and so on. The inherent complexity of this architecture makes it extremely difficult to size and deploy to the desired levels.


10.1.3 Tuning Windows CIFS Performance

The following are the performance tuning guidelines for both the NetApp storage and Windows clients which might help in improving overall CIFS performance. The actual benefit of each setting varies depending on the workload and many other system parameters. Note that the issues covered here are related mainly to CIFS, though some of them might be relevant to NFS too. Client-Side Issues Make sure that the Windows server is optimized for proper network throughput:

1. Set window size - Large window size increases the number of messages that can be in flight. The maximum window size that is supported on the NetApp storage is 64,240. Increasing this on both the NetApp storage and clients can dramatically improve performance for large transfers. Use the following option on the NetApp storage options cifs.tcp_window_size to 64240. The window size on the client is controlled by adding the registry value (DWORD) \\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpWindowSize and setting it 64240 (0xFAF0 in hex).

2. Consider hardware and OS dependencies - CIFS performance is quite sensitive to client performance (mostly due to opportunistic locking). Therefore, in general, the faster the clients are, the better the overall performance. Also, the larger the client memory the better the performance.

3. Make sure oplocks are turned on for the Windows clients. This is usually turned ON by default (unless someone explicitly set it off). The registry entry that controls oplocks is: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\UseOpportunisticLocking.

NetApp Storage-Side Issues

1. Oplocks should be enabled: Make sure that cifs.oplocks.enable is ON. (In certain database environments this cannot be set to ON for other reasons.)

2. Changing the open delta setting. Under certain workloads setting cifs.oplocks.opendelta to 0 can improve CIFS throughput performance by 3-5%. If setting this value to 0 results in client disconnects reset it back to 8 (which the default value).

3. If the workload being tested is random in nature set minra to ON. If it is more sequential set minra to OFF.

4. For workloads that are purely sequential increasing wafl_read_ahead to 18 chunks from default value of 3 chunks can help (by using "setflag wafl_read_ahead 18").

5. Setting “vol options <volume> no_atime_update ON” can improve CPU performance if accurate access times are not important.

Common Problems

Common problems that are typically reported as performance problems are:

1. Duplex mismatches: Make sure that the duplex settings match on the NetApp storage, the switch, and the clients.

2. Redirector breakages: If a very heavy load is placed on the CIFS client, the redirector can potentially break the session. Certain fixes have gone into recent Data ONTAP releases that fix this problem but this problem does occur occasionally. If this happens the best solution is to reduce the load on the client and redistribute this to other clients. One way to check whether this is happening is to monitor the “current commands” counter under the redirector object on the client side using Windows NT performance monitor.


3. On back-to-back configurations using Gigabit cards, flow control mismatches could show up as network performance problems.

Also see http://web.netapp.com/engineering/performance/projects/perf-tuning/CIFS/tuning.htm (internal).

10.1.4 Advanced oplocks Settings The CIFS.oplocks.enable option enables and disables CIFS oplocks for the entire storage system.

Setting the CIFS.oplocks.enable option has the following effects:

• If you set the CIFS.oplocks.enable option to Off, all CIFS oplocks on all volumes and qtrees on the storage system are turned off.

• If you set the CIFS.oplocks.enable option back to On, CIFS oplocks are enabled for the storage system, and the individual setting for each qtree and volume takes effect.

10.1.5 Options CIFS.oplocks.opendelta This option defines the length of artificial delay before sending an opportunistic lock break request to a client that has recently sent the NetApp storage an open request. This is done to work around a bug in Microsoft Windows clients that can cause the client to ignore an oplock break request if it is received at a certain time.

The units of this option are in milliseconds. The default is 8 milliseconds. Changes to the option take effect immediately; it is not necessary to restart anything.

For example, when opendelta is 8, the NetApp storage will make sure that at least 8 milliseconds have elapsed after receiving or responding to an open-file request before it sends an oplock break on that session.

This option should not be set higher than 35 milliseconds without consulting NetApp Customer Support. Also if set too low, it can have adverse affects on Windows services; for example, setting this to 0 can cause a Windows 2003 Web server to crash.

Recommended increments from the default: 20, 30, 40. . . Shouldn't need to go above 100.

The OpLkBkNoBreakAck statistic reported by CIFS stat keeps track of the number of nonresponsive oplock break occurrences. The goal is to try to find the lowest opendelta value that eliminates most or all of the nonresponsive oplock breaks.

10.1.6 Options CIFS.max mpx and Citrix This option is used when responding to client connection requests to tell the client the maximum number of outstanding requests the server will accept. There are a number of considerations regarding this option:

The default value of 50 is the same as Windows servers use. However, there are many situations where this number needs to be increased.

• Windows Terminal Server or Citrix boxes multiplex many CIFS sessions on a single TCP connection. That greatly increases the number of outstanding requests that the client would like to send. In most cases, NetApp recommends a value of 1124 for CIFS.max_mpx when using Windows Terminal Server or Citrix.


• Certain applications do many Change Notify requests. Each one of these counts as a pending operation for the client. If the total number of pending Change Notify requests exceeds the max_mpx value, the applications will either fail or go into a very CPU-intensive mode, issuing QueryFileInfo requests for all the objects that they would normally monitor using Change Notify. Applications that do this are Visual C++ and IIS.

• Applications such as SQL Server™ might encounter problems if the max_mpx value is exceeded under heavy loads. Unfortunately the exact symptoms are poorly characterized at the moment, but we have seen problems clear up when max_mpx is increased.

Windows servers have an option corresponding to CIFS.max_mpx in the Windows registry. It is called MaxMpxCt.

Windows clients have a value that controls the maximum number of outstanding requests they will attempt, regardless of how many the server says it can handle. This client parameter is called MaxCmds. The actual number of outstanding requests is the minimum of those two values. Due to bugs in the Microsoft clients, you might get a hard coded limit of 50 for MaxCmds. See http://support.microsoft.com/default.aspx?scid=kb;EN-US;271148 and http://support.microsoft.com/kb/810886/.

The maximum number of simultaneous, active requests between an SMB client and the server is determined when a client/server session is negotiated. The maximum number of requests that a client supports is determined by the MaxCmds registry value. The maximum number of requests that a server supports is determined by the MaxMpxCt registry value. For a particular client and server pair, the number of simultaneous, active requests is the lesser of these two values.

No problems have been seen when using very large values of max_mpx. However, NetApp recommend staying with the values recommended above as they are known to work with a large number of customers with varying client types.

When trying to determine whether or not we need to increase max_mpx, if a client has a large number of change notifications pending and it runs out of max_mpx slots it can cause application problems and/or performance problems. The number of change notifications pending can be seen using the "-c" option with the "CIFS sessions" command.

Following are some of the other features provided by NetApp storage with CIFS:

• Deleting existing shares

• Changing the settings of existing shares

• CIFS home directories

• For a count of all the shares, use:

FAS1> cifs shares -t

For a complete listing of all CIFS options, from the NetApp storage console, type:

“man na_cifs” or “man na_cifs_access” (The man commands are case-sensitive.)


10.2 BEST PRACTICES Using best practices when deploying active-active configurations: Review this list of configuration tips to make sure you are using best practices to make sure your active-active configuration is robust and operational.

1. Use VIFs (virtual interfaces) to provide redundancy and improve availability of network communication.

2. Maintain consistent configuration between the two nodes. An inconsistent configuration is often the cause of failover problems (NetApp Operations Manager will report and recommend optimal settings for both controllers).

3. Test the failover capability routinely (for example, during planned maintenance) to assure proper configuration.

4. Make sure that each node has sufficient resources to adequately support the workload of both nodes during takeover mode.

5. Higher numbers of traditional and FlexVol volumes on your system can affect takeover and giveback times. When adding traditional or FlexVol volumes to an active-active configuration, consider testing the takeover and giveback times to make sure that they fall within your requirements.

6. Schedule weekly WAFL Reallocate to optimize block layout. Refer to “man na_reallocate.”

CIFS Home Directory Deployment Best Practices

1. In environments with a large number of open files, to reduce ChangeNotify overheads it is better to:

a. Spread files over different volumes.

b. Spread files over different vFiler™ controllers and over different volumes owned by the vFiler controller.

c. Spread files over different NetApp storages and over different volumes owned by each NetApp storage.

2. If Kahuna domain utilization limits the overall performance, upgrade to a newer Data ONTAP release should be considered. Data ONTAP 7.2 has a separate CIFS domain - this can provide up to 15% improvement in performance in Kahuna limited scenarios for certain workloads.

CIFS, Wafl and Snapmirror all run in the Kahuna domain (versions of Data ONTAP prior to 7.2), which allows no overlap of their processing. The Kahuna domain could become a bottleneck.

3. Increasing the default value of cifs.max_mpx (set to be 50) can sometimes result in improvements in overall performance. Clients like Windows terminal server or IIS are examples of setups where this value can be increased. The approved values for this parameter are 126, 253, and 1124. The most accurate way to determine which number to use is to measure the Redirector Current Commands statistic on the client with Windows NT perfmon and to increase the number until Current Commands does not hit the negotiated limit. For more information see Microsoft Knowledge Base articles Q191370 and Q232890.

4. In Citrix setups set the cifs.max_mpx value to 1124 by default.


5. It is important to note that turning on Kerberos reply cache has significant performance impact. On a medium enterprise system with 3 new logins per second (approx. 10,000 logins per hour) turning on this feature has a 15% CPU overhead. If this feature is to be supported, please make sure that you size with sufficient headroom.

6. To know the limit of various CIFS resources (for example, Max. number of open TCP connections on any platform, Max. number of open files and so on), refer to the following link:

http://wikid.netapp.com/w/CIFS_resource_limits (Internal) or refer to Appendix D

10.3 DEMO

10.3.1 NetApp CIFS Sizing Tool Walk-Through Case Study

A customer needs to consolidate all his clients and deploy a CIFS-based home directory solution. He has 10,300 users total. As the data he has is critical he needs a high-availability solution. As he is expected to deploy more applications in the near future, the CPU utilization should not be more than 60% at its peak. The customer is not sure about the number of concurrent users. At present, the customer does not have antivirus scanning in the deployment. He needs a backup infrastructure which would take place during nonpeak hours (nights and weekends). The total storage capacity is 6TB.

The following are the steps described to size accurately for the deployment required:

Step 1 – Gather relevant information

Total number of users: 10,300

Concurrent/active users: Not known

CPU Utilization: 60% High Availability: Needed

Sizing Overhead Information: Antivirus: Not Present

SnapMirror: Needed, off peak hours

Total Storage Capacity: 6TB

Assumptions:

Degradation on failover: yes

User Type: Medium Concurrency %: 50

Compute the number of concurrent users.

Number of concurrent users = Total users * Concurrency %

Number of Concurrent Users: (Assuming 50%) 10,300 * 50% = 5150

Step 2 – Account for headroom required for other activities

Antivirus: not needed


Reduce the value for concurrent users by 10% and resize number of concurrent users: 5150 – (5150 * 10%) = 4635

SnapMirror: As this is going to be used during off-peak hours, we are not taking SnapMirror into account. Any requests which need a headroom other than 20% would result in a change in the users supported.

In this case, the customer requires a headroom of 40% (60% CPU utilization).

Step 3 – Narrow down storage systems that would support the required number and type of concurrent users

The NetApp CIFS sizer show that the FAS3040c and series beyond support the user requirements.

FAS3040c:

At 80% CPU utilization, users supported: 6250

At 60% CPU utilization, users supported: (6250*60)/80 = 4687.50

Clearly a FAS3040c can support more than 4635 users with CPU utilization of less than 60%. This clearly fits the customer's requirements.

Another way to find out which storage appliance would support the requirement would be to calculate the users supported at 60% utilization by each of the platforms, then compare with the concurrent users required by the customers and identify which platforms would suit the customer's needs.

10.4 NETAPP TECHNICAL REPORT REFERENCE High File-Count Environment Best Practices – January 2007

HTTP://MEDIA.NETAPP.COM/DOCUMENTS/TR-3537 (Internal)

Active/Active Controller Configuration Overview and Best Practices Guidelines – January 2007

HTTP://MEDIA.NETAPP.COM/DOCUMENTS/TR-3450 (Internal)

CIFS Performance Tuning in Data ONTAP

https://now.netapp.com/Knowledgebase/solutionarea.asp?id=3.0.1098760.2570911 (Internal)


APPENDIX A: DOMAIN DISCOVERY


APPENDIX B: CIFS SIZING FLOWCHART

Find out:

CPU utilization Kahuna utilization # of concurrent users

Is CPU % < 30 ?

Is CPU/Kahuna < 1.2

Based on the CPU and Kahuna

Headroom, determine the factor by

Max. # of concurrent users that can be supported =

# of users currently supported * scaling factor

NetApp storage too lightly loaded.

Possible problems need

to be addressed first

Yes

Yes

Adjust max # of users to account for headroom for peaks,

SnapMirror, AV scanning, SMB Signing, KRB reply cache and so on

Determine the # of disks

Stop

Need to size for

other platformsNo

Refer to the platform scaling table to estimate the # of users supported on other platforms

Yes

Start

Collect Perfstat/CIFS DCT during peak traffic

Step 1

Step 2

Step 3

Step 4

Step 5


APPENDIX C: NETAPP CIFS ADVANCED OPTIONS Commonly used CIFS options and some recommended settings and guidance for each one. Note: NetApp’s Operations Manager provides the feature to capture, compare and set optional settings, on all NetApp Storage. cifs.audit.enable When this option is on, CIFS audit events may be generated for file access or for logon and logoff. For file access events to be generated, the option cifs.audit.file_access_events.enable must also be selected. For logon and logoff events to be generated, the option cifs.audit.logon_events.enable must also be selected. This option default is off. cifs.audit.file_access_events.enable When both this option and the cifs.audit.enable option are selected, file access events will be audited when a file is accessed by an account for an operation and the file has a system access control list (SACL) entry that matches the access. If no SACL entry matches the access, no event will be generated. The default is on. cifs.audit.logon_events.enable When both this option and the cifs.audit.enable option are on, logon and logoff events will be generated. Logon and logoff events reflect CIFS session connects and disconnects, respectively. The default is on. cifs.audit.logsize Specifies the maximum event log file size. The default is 524288. The minimum is 524288 and maximum is 68719476736. cifs.audit.saveas Specifies the active event log file. The file must be in an existing directory in a network share. The default log file is /etc/log/adtlog.evt. cifs.bypass_traverse_checking When on (the default), directories in the path to a file are not required to have the X (traverse) permission. This option does not apply in UNIX qtrees. cifs.guest_account Enables a user to get access to the NetApp storage provided that either the NetApp storage uses a domain controller for authentication and the user is not in a trusted domain, or the NetApp storage uses the /etc/passwd file or the NIS password database for authentication and the user has no entry in the /etc/passwd file or the NIS password database. If this option is set to the name of an account in the password database, users logging into the NetApp storage will be assigned to the guest account if their names are not listed in the password database (when using /etc/passwd file or NIS) or if the user is not from a trusted domain (when using a domain controller). The configured user name will be used for the UNIX user ID, group ID, and group set of the specified account. If the option is a null string, guest access is disabled. The default value for this option is a null string. cifs.homedirs_public_for_admin This specifies whether members of the NetApp storage's Built-in\Administrators group can connect to the CIFS home directories of other users. If no argument is supplied, the current value of this option is displayed. If this option is set to on, an administrator can connect to the CIFS home directory of user username by specifying the share ~username (tilde username). This can be useful when setting a user profile to map the user's CIFS home directory on the NetApp storage. Windows 2000 Active Directory does not allow a system administrator to set a user's


profile to a nonexistent share, and normally a user's CIFS home directory can be accessed only by that user and not by the administrator. The default is on. cifs.idle_timeout Specifies the amount of idle time in seconds before the NetApp storage disconnects a session. An idle session is a session in which a user does not have any files opened on the NetApp storage. The value of this option ranges from 600 to 4,000,000 (effectively infinite). The default is 1800. cifs.max_mpx Controls how many simultaneous operations the NetApp storage reports that it can process. An operation is each I/O the client believes is pending on the NetApp storage, including outstanding change notify operations. This value defaults to 50, but there are many situations where this number needs to be increased (for example, clients such as Windows Terminal Server or IIS might require that this number be increased to avoid errors and performance delays). This option is used when responding to client connection requests to tell the client the maximum number of outstanding requests the server will accept. There are a number of considerations regarding this option: The approved values for this parameter are 126, 253, and 1124. The most accurate way to determine which number to use is to measure the Redirector Current Commands statistic on the client with Windows NT perfmon and to increase the number until Current Commands does not hit the negotiated limit. For more information see Microsoft Knowledge Base articles Q191370 and Q232890.

• This number should be changed only while CIFS is terminated.

• Use the only approved values as discussed in Microsoft Knowledge Base article Q232890.

• This value affects allocations in the clients. Use the smallest value necessary for correct

behavior. Windows Terminal Server or Citrix. These applications multiplex many CIFS sessions on a single TCP connection. That greatly increases the number of outstanding requests that the client would like to send. In most cases, we recommend a value of 1124 for cifs.max_mpx when using Windows Terminal Server or Citrix. Change Notify requests. Certain applications do many Change Notify requests and each one of these counts as a pending operation for the client. If the total number of pending Change Notify requests exceeds the max_mpx value, the applications will either fail or go into a very CPU-intensive mode, issuing QueryFileInfo requests for all the objects that they would normally monitor using Change Notify. Applications that typically do this are Visual C++ and IIS. Windows servers have an option corresponding to cifs.max_mpx in the Windows registry. It is called MaxMpxCt. Determining whether you need to increase max_mpx. If a client has a large number of change notifications pending and it runs out of max_mpx slots, it can cause application and/or performance problems. Starting with the Data ONTAP 6.5 release, the number of change notifications pending can be seen using the -c option with the cifs sessions command.


cifs.ms_snapshot_mode This option specifies the mode for Snapshot access from a Microsoft Shadow Copy client. Valid values for this option are off, pre-xp and xp. off disables Snapshot access from all Windows Shadow Copy clients. xp allows access to Snapshot copies from Windows XP and later Shadow Copy clients only. Pre-xp also allows access to Snapshot copies from Windows 2000 Shadow Copy clients. Note that the downlevel pre-xp mode should be used only if Windows 2000 Snapshot copy access is required as it might introduce a very slight performance hit when there is a heavy load on the NetApp storage and very long pathnames are in use. cifs.nfs_root_ignore_acl When on, ACLs will not affect root access from NFS. The option defaults to off. cifs.per_client_stats.enable Turning this option on causes the NetApp storage to start gathering statistics on a per-client basis. This allows use of the CIFS top command, as well as the -u and -h options of cifs stat. Administrators should be aware that there is overhead associated with collecting the per-client stats. This overhead might noticeably affect NetApp storage performance. If the option is turned off, any existing per-client statistics are discarded. The value may be changed at any time without restarting CIFS. The default value of this option is off. cifs.perm_check_ro_del_ok Windows NT delete rules do not allow you to delete a file with the DOS read-only bit set. However, a number of multiprotocol applications require UNIX delete semantics (w-x permissions in parent directory without regard to the file's permissions). This option controls this behavior. By default it is off, which yields Windows NT behavior. cifs.perm_check_use_gid This option affects security checking for Windows clients of files with UNIX security where the requester is not the file owner. In all cases Windows client requests are checked against the share-level ACL, then if the requester is the owner, the "user" permissions are used to determine the access. If the requester is not the owner and if perm_check_use_gid is on it means files with UNIX security are checked using normal UNIX rules, i.e., if the requester is a member of the file's owning group the "group" permissions are used, otherwise the "other" permissions are used. If the requester is not the owner and if perm_check_use_gid is off, files with UNIX security style are checked in a way that works better when controlling access using share-level ACLs. In that case the requester's desired access is checked against the file's "group" permissions, and the "other" permissions are ignored. In effect, the "group" permissions are used as if the Windows client were always a member of the file's owning group, and the "other" permissions are never used. The default setting is on for new installations. For existing installations, this has the opposite effect of the old "PC-mode" installation setting. If you do not plan to use share-level ACLs to control access to UNIX security style files (for example, in a UNIX qtree), you might wish to change this setting to on. cifs.restrict_anonymous.enable Controls the ability of nonauthenticated sessions to enumerate shares and groups. The default is off.


cifs.save_case This will force all created file names to lowercase for better compatibility between 16-bit applications and certain UNIX tools. The default is on. cifs.scopeid NetBIOS scope IDs allow the system administrator to create small workgroups out of a network by partitioning the NetBIOS name space; only clients with the same NetBIOS scope ID as the NetApp storage will be able to use the NetApp storage as a CIFS server. The default scope ID is a null string, but if the NetApp storage is to run in a NetBIOS scope other than the default one, its scope ID must be set to the scope ID of that scope. The scope ID can be changed only when cifs is not running. cifs.search_domains Specifies a list of domains that trust each other to search for a mapped account. The argument for the option is a comma-separated list that is searched in order. The default value for this option is the null string. If this option is set to a null string, all domains are searched. You use this option to control searches if you used an asterisk for a domain name in the usermap.cfg file. cifs.show_snapshot By default this option is FALSE. The snapshot directory ~snapshot is no longer shown at the root of a share. This is a change in behavior from previous versions. Setting this to TRUE will restore the old behavior. On Windows NT 4 or Windows 95 clients, the user can access Snapshot copies by entering \\NetApp storage\share\.Snapshot (or ~Snapshot) in the Start->Run menu. Snapshot copies can also be accessed lower in the share by providing a path to a lower directory. Snapshot copies can be accessed through DOS on any system by changing to the ~Snapshot directory. Note: When this option is TRUE it can confuse programs like FastFind that don't know about Snapshot copies. cifs.shutdown_msg_level Normally a message is broadcast to all clients when cifs is terminating. This option can be set to control this behavior. The value 0 results in never sending such broadcast messages. The value 1 results in sending broadcast messages only to sessions that have open files. The value 2 causes the messages to be sent to all open connections, which is the default behavior. cifs.sidcache.enable By default this option is TRUE. This options controls whether CIFS will cache SID-to-name translation information that it has received from the domain controllers. cifs.sidcache.lifetime By default this option is 1440, which is 24 hours specified in minutes. The option controls how long a SID-to-name cache entry is used before it becomes stale. The SID-to-name mapping functions in the NetApp storage will query the appropriate domain controller to update the cached mapping when it is needed but has become stale. This option is specified in minutes. cifs.snapshot_file_folding.enable By default this option is FALSE. This option controls whether CIFS will attempt to “fold” files on close with previous snapshot versions of themselves to minimize disk usage. Disk space is saved by sharing unchanged file blocks between the active version of the file, and the version of the file in the latest Snapshot, if any. The NetApp storage must compare block contents when folding a file, so there is a performance vs. space utilization tradeoff to consider with this option.


cifs.symlinks.cycleguard The cifs.symlinks.cycleguard option (on by default), eliminates the possibility of traversing directories cyclically during the process of following symbolic links. With this option set to on, if the target of the symlink resolves to a directory that is directly above the symlink's parent directory, it is disallowed. With this option set to off, many standard Windows apps (such as Find in Windows 95 and Windows NT 4.0) will not operate correctly when a symlink points to a parent directory. This is because they do not understand symbolic links and will repeatedly loop on them. Users should use caution when changing this option. cifs.symlinks.enable When cifs.symlinks.enable is on (the default), if the object being accessed by a CIFS client is a symbolic link (whether absolute or relative), the NetApp storage follows the link with the proviso that the ultimate target turns out to reside within the originating share (thus assuring that the client has access permission to the target). cifs.trace_dc_connection When cifs.trace_dc_connection is on (the default is off), the NetApp storage logs all domain controller address discovery and connection activities. This can be used to diagnose DC connection problems on the NetApp storage. cifs.trace_login When cifs.trace_login is on (the default is off), the NetApp storage logs all login-related activities. This can be used to diagnose access problems on the NetApp storage. cifs.weekly_W2K_password_change This option affects only NetApp storage installed in Windows 2000 domains. When on, this option causes the NetApp storage to change its domain password once a week, as is current practice for the NetApp storage in Windows NT 4 domains. The password change occurs at approximately 1:00 a.m. on Sunday mornings. For Windows 2000 domains with multiple DCs, a password change might inhibit CIFS connections for a short time while the new password is propagated among the DCs. The default for this option is off. This option has no effect on NetApp storage installed in domains earlier than Windows 2000. cifs.widelink.ttl When a CIFS client accesses a wide symbolic link (widelink), the NetApp storage returns both a path referral and a time-to-live value. The CIFS client can cache the widelink path referral for the time-to-live time period. This option allows the system administrator to set the value which the NetApp storage returns for time-to-live.


APPENDIX D: CIFS NETAPP SIZING GUIDELINE General Information

Customer Name (Required)

Customer name is a required field. This name will be used to track this request (in combination with some date information).

Location (Info Only)

This field is primarily for customers who have multiple sites. List the specific site where the configuration will be installed.

Region (Info Only)

Simply select the appropriate NetApp sales region.

SE/CSE/PSE(s) (Info Only)

List all SEs, CSEs, and PSEs involved with the sizing/sales/deployment of the sized system.

Field Specialist (Info Only)

If you are working with a Field Specialist, list the name here.

Sizing Request Identifier (Info Only)

This field is intended to help identify individual sizing requests submitted during the sizing exercise for a particular opportunity/customer. This field becomes part of the "Subject" line of the email containing the configuration suggested and can help in sorting /arranging /searching for various configurations.

Requester E-Mail (Required)

This field is required for two reasons

• Used as part of the request tracking and history mechanism. • The email address listed will receive an email of the sizing output AND any future emails

regarding this particular sizing.

Notes (Info Only)

Describe the customer situation or any information that is potentially useful when reviewing the inputs or outputs. Describe any unusual configuration or setup requirements. Be creative.

Vantive # (If Applicable) (Info Only)

If this sizing is associated with a customer case in any way list the case # here for cross-reference.

Data ONTAP Version (Impacts Sizing)


Select the Data ONTAP version to be used in the installation. Map the planned version to one of the listed options.

GENERAL NETAPP STORAGE SPECIFICATIONS NetApp Storage Platform (Impacts Sizing)

This field allows the sizing to be restricted to a sub-set of all possible platforms. If "Any" is selected, all platforms will be considered. If one or more platforms are selected, then just those platforms will be considered as valid configurations.

Max # of Heads (Impacts Sizing)

This field allows the sizing to be limited to a maximum number of heads (or clusters). For instance, if the customer is specifically interested in only single head cluster solutions, please select 1 (one) for input. All valid configurations will contain exactly one cluster head.

Min # of Heads (Impacts Sizing)

This field allows the sizing to be started from a minimum number of heads (or clusters). Can be used if the situation, for some reasons other than sizing considerations, dictates a certain minimum number of heads or clusters OR can be used simply to explore various "what-if" scenarios with more heads than the sizer suggests.

Sizing Option

This option allows the user to choose the sizing method.

Drive Perf Curves

This options allows user to do sizing using following disk curves:

• Prev. Generation - Sizing is done using performance characteristics of older generation of disks.

• Regular - In this case, drive performance characteristics assume full stroking. • Competitive - In this case, drive performance characteristics assume mild short stroking.

Application Defaults

In this option application's default parameters are changed if "Competitive" Mode is chosen. The parameters changed are:

Parameters Values in Regular Sizing Mode

Values in Competitive Sizing Mode

CPU Headroom 30% 20%

Single Instance Ratio 1 1.25

NTFS hard link No Yes

Concurrent Users 100% 90%


Deleted Item/Mbox Cache 15% 10%

Read and Write working set size as a % of database size 100% 85%

Fractional Space Reserve 1 0.8

Cache Factor 0.33 0.37

CPU Headroom (Impacts Sizing)

This field allows the customer to specify how much headroom (or CPU idle %) is requested under normal load circumstances. A headroom selection of 30% means that all valid configurations will have projected maximum CPU utilization of 70% or less. Note that this is approximate and that many variables can impact the actual deployed CPU utilization. Think of this as a general approximation of CPU usage, not a hard projection.

Local Cluster (Impacts Sizing)

This field specifies whether or not NetApp storage clusters should be sized or not. If "No" is selected, then all valid configurations will be single head NetApp storages (or multiple single head NetApp storages). If "Yes" is selected, then all valid configurations will be clustered solutions only (or multiple clustered solutions). Typically, the decision to cluster or not is a customer business decision based on the availability requirements of the application environment.

Failed-Over Performance (Impacts Sizing)

If the local cluster option is selected, the customer must decide what expectations exist during a failover scenario when only one head is operational. There are two choices:

• Performance is expected to be the same as normal operation (no performance degradation).

• Performance degradation is expected and tolerable during the failover scenario..

The impact this setting has on sizing is simple: if no degradation is expected, then both heads in the cluster must operate below 50% CPU utilization during normal mode. The "CPU Headroom" value selected above then applies to the 50% utilization target.

MetroCluster (Impacts Sizing - Not available currently)

This value is currently not used in sizing calculations. This field specifies whether or not a MetroCluster solution is required. If "No" is selected then the sizing occurs based on the NetApp storage cluster or not setting. If "Yes" is selected, then the sizing occurs for clusters only, assuming that each cluster pair is split over the metro interface.

Failed-Over Performance (Impacts Sizing - Not available currently)

If the MetroCluster option is selected, the customer must decide what expectations exist during a failover scenario when only one head is operational. There are two choices:


• Performance is expected to be the same as normal operation (no performance degradation).

• Performance degradation is expected and tolerable during the failover scenario.

The impact this setting has on sizing is simple: if no degradation is expected, then both heads in the cluster must operate below 50% CPU utilization during normal mode. The "CPU Headroom" value selected above then applies to the 50% utilization target.

BACKEND SIZING INFORMATION Capacity Reserve

Capacity Reserve is the extra capacity that needs to added during the sizing process for growth purposes. It is expressed as a % of "Data Size GB (usable)."

Age of System

A simple parameter that takes into account the effect of aging on system behavior. This parameter controls the expected fragmentation level of the system that is being sized. Be careful of sizings that are done using this parameter as not all systems that are X% full having the same level of fragmentation. This should be used only as an indicator of likely performance.

Vol Type (optional)

This parameter provides a way to specify a common Volume type for all the workloads. The meaning of various options are:

• "Per Workload" -- Specify the Vol Type field for each workload individually (thereby providing a way for different workloads to have different Vol Types).

• "Trad" -- The Vol Type will be traditional volumes for all the workload(s). • "Flex" -- The Vol Type will be flexible volumes for all the workload(s). • "Any" -- Sizing will be performed for both "Flex" and "Trad" Vol types for all the

workload(s).

CUSTOM SIZER SPECIFIC INFORMATION Random Read/Write Working Set Size (Impacts Sizing)

These fields determine the amount of metadata reads and writes generated. They denote the amount of space actively accessed by the users. The worst case can be the whole file space, or database size and so on, depending upon the application. Usually, it will be much lower than that. If you are unable to figure out the active space, use the whole file space (for worst case).

Random Read Latency (ms)

Desired NetApp storage latency for random reads. This is an optional parameter (default value is 20 ms) and should be between 10 ms and 40 ms.

CIFS HOME DIRECTORY SPECIFIC INFORMATION


Virus Scanning

This option lets you size with Virus Scanning Enabled or Disabled. Please refer to the CIFS guide for more details.

SnapMirror

This option lets you size with SnapMirror Enabled or Disabled. Please refer to the CIFS guide for more details.

SMB Signing

This option lets you size with SMB Signing Enabled or Disabled. Please refer to the CIFS guide for more details.

User Type

A user type for this sizing method is categorized as a Light, Medium or Heavy User Type.

Desired # of Users

This is the number of users expected to be supported on the target deployment.

Concurrency Percentage

This is the percentage of desired users expected to be concurrently using the target deployment.

Home Directory Sizer in GB per User

This is the space allocated per user in GB on the target deployment.

Number of Servers

This is the number of existing servers from which we extract KB In per second and KB Out per second information.

Current Platform

This is the current NetApp Platform you have and want to upgrade from.

Observed CPU Percentage

This is the CPU% observed in the current deployment. This number is not more than 100%.


Number of Drives in Existing Set Up

This is the existing number of drives in the current NetApp Deployment.

Memory Utilization

This is an output value that shows the memory utilization that the system is experiencing. If you have to choose a specific system it is always better to choose one with the lowest memory utilization.

• Systems with low memory utilization correspond to ones with diskops/host_ops < 1.5. These systems are highlighted with green color.

• Systems with medium memory utilization correspond to ones with diskops/host_ops >= 1.5 and < 1.75. These systems are highlighted with yellow color.

• Systems with high memory utilization correspond to ones with diskops/host_ops >= 1.75. These systems are highlighted with red color.

Disk Read Ops/Host Read Op

This value indicates the memory utilization of the system. It is a number typically between 1 and 2.

• A value of 1 implies that each incoming read operation to the NetApp storage translates to only one disk read operation. In other words, all the metadata needed for the incoming read operations to the NetApp storage are already cached in NetApp storage memory.

• A value of 2 indicates that each incoming read operation to the NetApp storage translates to two disk read operations. First to read the metadata for the data block(s) and then second to read the actual data block(s). In other words, no metadata caching.


APPENDIX E: CIFS RESOURCE LIMITS This describes the theoretical limits that exist for certain CIFS data structures. These limits vary depending on the hardware platform. In practice, these limits depend on how much memory is generally available, so your mileage will vary. For real world sizing, please refer to:

Home Directory Capacity Planning Guide – December 2004

http://perf-web.corp.netapp.com/twiki/pub/Perfweb/TechLibrary/FileServingSizingGuide-2004.pdf (Internal)

Description

Limit Description

Max Connections The maximum number of open CIFS TCP connections.

Max Shares The maximum number of directories shared using CIFS.

Max Share Connections The maximum number of open connections to CIFS shares.

Max Open Files The maximum number of open CIFS file handles.

Max Locked Files The maximum number of locked files.

Max Locks The maximum number of open locks, including both share and byte-range locks.

Limits FAS6000 Series

FAS6000 Series Limit FAS6030 (16GB) FAS6070 (32GB)

Max Connections 96,000 96,000

Max Shares 192,000 192,000

Max Share Connections 384,000 384,000

Max Open Files 1,920,000 1,920,000

Max Locked Files 2,116,608 2,116,608

Max Locks 4,233,216 4,233,216

FAS3000 Series


FAS3000 Series Limit FAS3020 (2GB) FAS3040 (4GB) FAS3050 (4GB) FAS3070 (8GB)

Max Connections 32,000 64,000 64,000 96,000

Max Shares 64,000 128,000 128,000 192,000

Max Share Connections 128,000 256,000 256,000 384,000

Max Open Files 640,000 1,280,000 1,280,000 1,920,000

Max Locked Files 705,536 1,411,072 1,411,072 2,116,608

Max Locks 1,411,072 2,822,144 2,822,144 4,233,216

FAS2000 Series

FAS2000 Series Limit FAS2020 (1GB) FAS2050 (2GB)


Max Shares 26,400 54,400


Max Open Files 264,000 544,000

Max Locked Files 292,672 601,344

Max Locks 585,344 1,202,688

FAS200 Series

FAS200 Series Limit FAS250 (512MB) FAS270 (1024MB)


Max Shares 12,400 26,400


Max Open Files 124,000 264,000

Max Locked Files 138,336 292,672

Max Locks 276,672 585,344


APPENDIX F: USING NOVELL’S EDIRECTORY FOR LDAP AUTHENTICATION

HANDS-ON EXERCISE: LDAP Authentication with Novell’s eDirectory

Prerequisite: NWSETUP.BAT required on W2003

Either perform the follow steps, or to automate the task, execute: LDAPEDIR.BAT. Then, proceed to stage #2, section ‘Preparing the NetApp storage’

Performed from: W2003

Stage 1: Preparing eDirectory NetApp supports Novell’s eDirectory versions 6.7.3 to 8.8.x for LDAP authentication on NetApp storage (Novell eDirectory running on NetWare 6.5, Windows 2000, or 2003 Server, Suse Linux® OES 9.x, 10.x, or 11.0). The following 5 steps have already been performed.

.

1. Install Novell Native File Access Protocol. Refer to “Novell Native File Access Protocols Installation and Administration Guide” for detailed steps.

2. For NetWare, configure the CIFS search context: NETWARE> sys:\etc\cifsctxs.cfg with the correct CIFS context search

i.e. ou=USERS.ou=SUNNYVALE.o=CA

ou=SERVERS.ou=SUNNYVALE.o=CA

3. Create simple passwords for your users. Users may use iManager, Novell Remote Manager, or Novell’s Virtual Office for self-administration. To automate the process for large customers, use Novell’s Identity Manager or Novell’s Account Manager.

4. From Novell ConsoleOne, select the UNIX Profile tab, assign UNIX User Identification Number (UID) and UNIX Group Identification Number (GID) to your Users and Groups

Or

Use iManager to assign the UNIX UID and GID to both the users and groups.


Note: Both the UNIX UID and UNIX GID to the User and Group accounts must be set, as well as a simple password for each user you wish to authenticate to eDirectory (LDAP) to access the NetApp storage. If you are not using the Home Directory mapping, place a forward slash in the field, as illustrated in the above figure.

5. On the properties of the eDirectory “LDAP Group – BIGRED”, turn off “Require TLS for simple binds with password.”

Stage 2: Preparing the NetApp Storage Once the Novell NetWare 32-bit client has been installed on the W2003, and the machine has been rebooted, to log back into Windows:

a. Check the box for “Workstation only”

b. Type your Username: administrator, password: netapp1

c. Click OK

d. Disregard the service control manager error message, which appears when you log in. This is to warn you that IP load balancing is not supported with the Novell client.

Once you have logged in, to continue with this exercise, from the menu bar, on the bottom far right, right click the N, select “Novell Login.”

User: admin

Password: netapp1

Click the Advanced button

Tree: NETAPP

Context: USERS.SUNNYVALE.CA


Server: 192.168.10.102

Novell’s eDirectory tree is designed as follows for this demonstration:

Tree = NETAPP

Users reside = ou=USERS.ou=SUNNYVALE.o=CA

Servers reside = ou=SERVERS.ou=SUNNYVALE.o=CA

The Novell NetWare server name = bigred

Administrator = cn=admin,ou=USERS.ou=SUNNYVALE.o=CA

This appendix assumes you are familiar with using Novell’s ConsoleOne, a shortcut for ConsoleOne has been placed on your desktop.

Preparing CIFS for eDirectory authentication on NetApp storage: FAS1> cifs terminate –t 0

FAS1> cifs setup

1. Select LDAP authentication (Option 4), with multimode rather than NTFS.

2. If you have run the LDAPEDIR.BAT, move to step #3, otherwise, Modify the /etc/nsswitch.conf file to make sure passwd, group and netgroup all say “ldap nis files”:


FAS1*> java netapp.cmds.jsh

FAS1*> cp /etc/nsswitch.conf /etc/nsswitch.conf.original

FAS1*> wrfile /etc/nsswitch.conf

passwd: ldap files nis netgroup: ldap files nis group: ldap files nis hosts: files dns nis shadow: files nis

Ctrl+C to end file

A message will display stating: “read: error reading standard input: Interrupted system call” After you create the file, you may view the contents with the command:

FAS1*> rdfile /etc/nsswitch.conf FAS1*> exit FAS1*> priv set


4. Configure the NetApp storage for DNS name resolution (FilerView, Network, Configure Host Name Resolution). You must be able to resolve the FQDN of the LDAP server, bigred.demo.netapp.com

Stage 3: Extending the Schema on eDirectory

To simplify the connection to the NetWare console, a copy of remote console (freecon2006.exe) has been placed in C:\CIFSDEMO\Novell\. Please install the software using the default settings.

From the Master Replica eDirectory Server (BIGRED), extended the schema with the NetApp RFC2307 files (rfc2307-usergroup.sch and rfc2307-nis.sch).

SERVER> Please use freecon2006 to connect to the NetWare console.

NETWARE> nwconfig

Select Directory options

Extend Schema, authenticate with user: admin.users.sunnyvale.ca, password:netapp1

Press F3, and type the path to the schema files (SYS:\Schema)

When the schema import completes, select to Return to the previous menu, then exit.

NETWARE> dsrepair –a

Select Advanced options menu,

Global schema operations, authenticate with user: admin.users.sunnyvale.ca, password:netapp1

Select Post NetWare 5 schema update. Respond with Yes, I’m sure. When this completes press ESC.

Select Optional Schema Enhancements. Respond with Ues, I’m sure. When this completes press ESC until you are at the main menu.

Select to Run ‘Unattended full repair’, when this complets press ESC until you exit the DSRepair program.

Set the Correct LDAP Options on the NetApp Storage Make the appropriate changes. Once completed, to verify each setting was correctly changed, type:

FAS1> options ldap


NOTE: The following LDAP settings have been placed in the LDAPNWSCHEMA.BAT. You may execute the batch file instead of manually typing the following commands.

FAS1> options ldap.ADdomain "o=ca"

FAS1> options ldap.base "ou=users,ou=sunnyvale,o=ca"

FAS1> options ldap.base.group "ou=users,ou=sunnyvale,o=ca"

FAS1> options ldap.base.netgroup "ou=users,ou=sunnyvale,o=ca"

FAS1> options ldap.base.passwd "ou=users,ou=sunnyvale,o=ca"

FAS1> options ldap.enable on

FAS1> options ldap.minimum_bind_level anonymous

FAS1> options ldap.name admin.users.sunnyvale.ca

FAS1> options ldap.nssmap.attribute.gecos gecos

FAS1> options ldap.nssmap.attribute.gidNumber gidNumber

FAS1> options ldap.nssmap.attribute.groupname cn

FAS1> options ldap.nssmap.attribute.homeDirectory homeDirectory

FAS1> options ldap.nssmap.attribute.loginShell loginShell

FAS1> options ldap.nssmap.attribute.memberNisNetgroup memberNisNetgroup

FAS1> options ldap.nssmap.attribute.memberUid memberUid

FAS1> options ldap.nssmap.attribute.netgroupname cn

FAS1> options ldap.nssmap.attribute.nisNetgroupTriple nisNetgroupTriple

FAS1> options ldap.nssmap.attribute.uid uid

FAS1> options ldap.nssmap.attribute.uidNumber uidNumber

FAS1> options ldap.nssmap.attribute.userPassword userPassword

FAS1> options ldap.nssmap.objectClass.nisNetgroup nisNetgroup

FAS1> options ldap.nssmap.objectClass.posixAccount posixAccount

FAS1> options ldap.nssmap.objectClass.posixGroup posixGroup

FAS1> options ldap.passwd netapp1

FAS1> options ldap.port 389

FAS1> options ldap.servers bigred

FAS1> options ldap.servers.preferred bigred

FAS1> options ldap.ssl.enable off

FAS1> options ldap.usermap.attribute.unixaccount Unixaccount

FAS1> options ldap.usermap.attribute.windowsaccount Windowsaccount

FAS1> options ldap.usermap.base

FAS1> options ldap.usermap.enable off


Stage 4: Testing LDAP Communications

SERVER> Use ConsoleOne, create a group called:

SysOp in the following context = USERS.SUNNYVALE.CA

SERVER> Use ConsoleOne, create two users:

Betty in the following context = USERS.SUNNYVALE.CA

Barnie in the following context = USERS.SUNNYVALE.CA

SERVER> Use ConsoleOne, add both Betty and Barnie to the SysOp group.

Ensure both users and the group have been assigned UNIX UID and GID. From ConsoleOne, select the Login Methods tab, and assign passwords for both users, using all three options:

NDS Password – used for eDirectory, and is mandatory

Enhanced Password – used for Kerberos key ticket exchange

Simple Password – used for LDAP

For LDAP testing, refer to section 6.3.2.4, getXXbyYY: Advanced Name Resolution Test Commands.

Once you have success with LDAP communication, configure the NetApp storage CIFS shares with user or Group access based on eDirectory accounts. For this example,

We will assign the group SysOp full control to the share C$, and change the Default Security Style from ntfs to mixed.

FAS1> cifs access C$ -g SysOp full control

FAS1> options wafl.default_security_style mixed

SERVER> From FilerView, select CIFS -> Configure -> Security, Use Group ID Permissions, set to “Yes.”

Test connectivity for both Betty to the C$ share. i.e.

SERVER> Net use T: \\FAS1\C$ /user:Betty netapp1


APPENDIX G: COMMONLY USED ADMINISTRATIVE INTERFACES FOR DATA ONTAP

ADMINISTRATIVE APPLICATIONS FOR DATA ONTAP • FilerView, provisioning:

o http://<NetApp storage>/na_admin

o Storage system At-A-Glance

o Documentation

o Manual Pages

o Submit a support case

o Written in HTML and Javascript, which works on most browsers

o Instructions for installation:

http://web.netapp.com/engineering/design-depot/appliance-mgmt/filerview/faq/ (Internal)

• NetApp Operations Manager

• SnapManager

• SnapDrive Host-side

• CLI (Command Line Interface)

o RSH

o SSH

o Telnet

o Serial console

o RLM

o Test CLI command. http://web.netapp.com/engineering/design-depot/appliance-mgmt/zephyr/

• SNMP

• Syslog, Autosupport

• HTTP/HTTPS

• Vscan/FPolicy

• RPC (Windows authentication)

• ZAPI

o Data ONTAP APIs (ONTAPI™) are used internally by FilerView, Operations Manager and interstorage communication, i.e. SnapManager

o Manage Data ONTAP SDK for 3rd parties (C, Java, and Perl)

o Data ONTAP Developer writes API code and docs in one place in the Data ONTAP source tree


NETAPP JAVA SHELL To load the Java Shell:

FAS1> priv set advanced FAS1*> java netapp.cmds.jsh

To Exit the Java Shell:

FAS1*> exit FAS1*> priv set

Supports file system tree traversal and basic file utilities similar to the UNIX shell. Commands to copy, remove, move, and list files are available, along with the ability to execute any Data ONTAP built-in command. In addition, the Java shell can execute any Java application specified on the command line.

cd [directory] Change the current directory to that specified. “/” is used if no directory is specified. The directory specified may be either absolute or relative.

Pwd Print the current working directory.

ls [-l] List the contents of the current directory. If the -l flag is used a longer listing of each file is produced.

cat file Print the contents of the specified file. You better hope the contents are ASCII friendly.

rm file [file2 ...]

Remove the files specified. Sorry, no wild card support.

cp src_file dest_file

Copy the source file to the destination file.

mv src_file dest_file

Rename the source file to the destination file.

ps [-l] List all the Java threads executing in the Java Virtual Machine.

Gc Run the garbage collector. Report memory heap usage.

classpath [extra_path]

Change the “local” classpath used to load classes in a separate name space.

syspath [extra_path]

Append to the systems notion of CLASSPATH.

Threads Print a stack traceback of all Java threads on the console.

Monitors Print a report of all the Java monitors on the console.

Heap Print a report of the Java heap on the console (prof kernels only).

[DATA ONTAP command]

Execute any of the builtin Data ONTAP commands (hostname and so on) and wait for completion.

Syncdb Sync the Jivetech JIT database, and create a copy in /etc/java/jit.db.

java_application [&]

Execute the given Java application. If “&” is specified, don't wait for the application to complete. If a package name isn't used, netapp.cmds is assumed.


APPENDIX H: SUPPORTED GPO’S

SUMMARY OF GPO FEATURES

• Data ONTAP 6.4 o GPO is introduced - as a hidden feature o Startup and Shutdown scripts o GPO refresh time interval for computer

• Data ONTAP 7.0 o GPO is remained as a hidden feature o GPO File System security policy, with no ACL propagation implemented

• Data ONTAP 7.0.1 o GPO is remained as a hidden feature o A seperate GPO security policy framework o A complete GPO File System security policy support

• Data ONTAP 7.1 o GPO support is official o GPO Event Log support

Maximum application log size (Not Applicable) Maximum-security log size Maximum system log size (N/A) Restrict guest access to application log (N/A) Restrict guest access to security log Restrict guest access to system log (N/A) Retain application log (N/A) Retain security log Retain system log (N/A) Retention method for application log (N/A) Retention method for security log Retention method for system log (N/A)

o GPO Auditing support Audit account logon events Audit account management (N/A) Audit directory service access Audit logon events Audit object access Audit policy change (N/A) Audit privilege use (N/A) Audit process tracking (N/A) Audit system events (N/A)

• Data ONTAP 7.2 o Restricted Group

Restricted Groups automatically provides security memberships for default Windows 2000 groups that have predefined capabilities, such as Administrators, Power Users, Print Operators, Server Operators, and Domain Admins. You can later add any groups that you consider sensitive or privileged to the Restricted Groups security list. For example, the Power Users group is automatically part of Restricted Groups, since it is a default Windows 2000 group. Assume it contains two users: Alice and Bob. Bob adds Charles to the group, through the Active Directory Users and Computers snap-in, to cover for him while he is on vacation. However, no one remembers to remove Charles


from the group when Bob comes back from vacation. In actual deployments, over time, these situations can add up, resulting in extra members in various groups, members who should no longer have these rights. Configuring security through Restricted Groups can prevent this situation. Since only Alice and Bob are listed in the Restricted Groups node for Power Users, when Group Policy settings are applied, Charles is removed from the group automatically.

• Data ONTAP 7.2.1 o User Rights Assignment

Take ownership of files or other objects o GPO refresh time interval random offset

• GPOs in the roadmap o Most of GPO Security policies, such as:

Local Policies User Rights Assignment Access this computer from the network Backup files and directories Bypass traverse checking Deny access to this computer from the network EMC Virus Checking Generate security audits Increase quotas Manage auditing and security log Restore files and directories Security Options

Digitally sign client communication (always) Digitally sign server communication (always)

Kerberos Maximum tolerance for computer clock synchronization (clock

skew) Maximum lifetime for user ticket

o Other applicable registry settings, such as: Disable background refresh of Group Policy

• GPOs to consider in the Future o Customized NetApp GPOs o Implementation of Active Directory GPO in generic LDAP


APPENDIX I: CIFS PERFORMANCE COUNTERS To track CIFS performance, from a Windows Server 2003 or above, start Performance Monitor (cmd, perfmon.exe). For realtime capture, on the left pane, select Performance Monitor. On the right pane, from the menu bar, click the X to delete existing Counters. Then click the + to add Counters.

HANDS-ON EXERCISE: CIFS Performance Counters



To capture data from NetApp storage, under available servers, type \\FAS1 followed by TAB which will cause the available counters to update to the specific ones which are supported by NetApp.

The follow tables listed in this Appendix provides both the available counter names and a description of what each counter would capture.

CIFS COUNTERS FOR PERFMON

Counter Name Description

cifs_get_attr_ops_pct GetAttr operations count as a percentage of total CIFS operations.

cifs_read_ops_pct Read operations count as a percentage of total CIFS operations.


cifs_write_ops_pct Write operations count as a percentage of total CIFS operations.

cifs_lock_ops_pct Lock operations count as a percentage of total CIFS operations.

cifs_open_close_ops_pct Open/Close operations count as a percentage of total CIFS operations.

cifs_directory_ops_pct Directory operations count as a percentage of total CIFS operations.

cifs_other_ops_pct Other operations count as a percentage of total CIFS operations.

cifs_latency Average latency for CIFS operations in milliseconds.

cifs_latency_base Total observed CIFS operations to be used as a base counter for CIFS average latency calculation.

CIFS OPERATIONS


get_attr_ops Query Information operations (SMB Code = 0x08).

set_attr_ops Set Information operations (SMB Code = 0x09).

get_attr_ext_ops Query Information2 operations (SMB Code = 0x23).

set_attr_ext_ops Set Information2 operations (SMB Code = 0x22).

query_fs_info_ops Query FS Information operations (SMB Code = 0x32, SubCode = 0x03).

query_path_info_ops Query Path Information operations (SMB Code = 0x32, SubCode = 0x05).

set_path_info_ops Set Path Information operations (SMB Code = 0x32, SubCode = 0x06).

query_file_info_ops Query File Information operations (SMB Code = 0x32, SubCode = 0x07).

set_file_info_ops Set File Information operations (SMB Code = 0x32, SubCode = 0x08).

query_disk_info_ops Query Disk Information operations (SMB Code = 0x80).

get_ntap_ext_attr_ops Query NTAP Extended Attribute operations (SMB Code = 0x32, SubCode = 0x05, Info = 0x04).

set_ntap_ext_attr_ops Set NTAP Extended Attribute operations (SMB Code = 0x32,


SubCode = 0x06, Info = 0x02).

read_ops Read operations (SMB Code = 0x0A).

readx_ops ReadAndX operations (SMB Code = 0x2E).

read_raw_ops Read Raw operations (SMB Code = 0x1A).

write_ops Write operations (SMB Code = 0x0B).

writex_ops WriteAndX operations (SMB Code = 0x2F).

write_raw_ops Write Raw operations (SMB Code = 0x1D).

queued_write_raw_ops Queued Write Raw operations (SMB code = 0x1D).

flush_ops Flush operations (SMB Code = 0x05).

open_ops Open operations (SMB Code = 0x02).

create_ops Create operations (SMB Code = 0x03).

close_ops Close operations (SMB Code = 0x04).

open_ext_ops Create with extended attributes operations (SMB Code = 0x32, SubCode = 0x00).

openx_ops OpenAndX operations (SMB Code = 0x2D).

nt_create_ops NTCreateAndX operations (SMB Code = 0xA2).

nt_trans_create_ops NTTransactCreate operations (SMB Code = 0x25, SubCode = 0x01).

create_dir_ops Create Directory operations (SMB Code = 0x00).

delete_dir_ops Delete Directory operations (SMB Code = 0x01).

check_dir_ops Check Directory operations (SMB Code = 0x10).

delete_ops Delete operations (SMB Code = 0x06).

rename_ops Rename operations (SMB Code = 0x07).

nt_rename_ops NT Rename operations (SMB Code = 0xA5).

seek_ops Seek operations (SMB Code = 0x12).

transact_ops Transact operations (SMB Code = 0x25).

find_first_ops Begin search for file operations (SMB Code = 0x32, SubCode = 0x01).


find_next_ops Resume search for files operations (SMB Code = 0x32, SubCode = 0x02).

create_dir_ext_ops Create Directory with extended attributes operations (SMB Code = 0x32, SubCode = 0x0D).

search_ops Search operations (SMB Code = 0x81).

find_close_ops FindClose2 operations (SMB Code = 0x34).

nt_trans_notify_ops Start directory watch operations (SMB Code = 0x25, SubCode = 0x04).

lock_byte_range_ops Lock Byte Range operations (SMB Code = 0x0C).

unlock_byte_range_ops Unlock Byte Range operations (SMB Code = 0x0D).

lockx_ops LockingAndX operations (SMB Code = 0x24).

lock_read_ops Lock and Read operations (SMB Code = 0x13).

write_unlock_ops Write and Unlock operations (SMB Code = 0x14).

negotiate_ops Negotiate operations (SMB Code = 0x72).

sess_setup_ops Session setup operations (SMB Code = 0x73).

sess_logoff_ops Session logoff operations (SMB Code = 0x74).

set_sec_ops Set Security Descriptor operations (SMB Code = 0x25, SubCode = 0x03).

query_sec_ops Query Security Descriptor operations (SMB Code = 0x25, SubCode = 0x06).

reject_ops Unrecognized SMB command code.

no_support_ops Non supported SMB operations.

total_ops Total number of SMB operations since NetApp storage was started.

dfs_refer_ops Get DFS referral operations (SMB Code = 0x32, SubCode = 0x10).

dfs_report_ops Report DFS inconsistency operations (SMB Code = 0x32, SubCode = 0x11).

echo_ops Echo operations (SMB Code = 0x2B).

tree_conn_ops Tree Connect operations (SMB Code = 0x70).


tree_conn_and_disc_ops Tree Connect with a tree Disconnect operations (SMB Code = 0x70)

tree_disc_ops Tree Disconnect operations (SMB Code = 0x71).

ioctl_ops Device IOCTL operations (SMB Code = 0x25, SubCode = 0x02).

cancel_ops Cancel operations (SMB Code = 0xA4).

CIFS STATISTICS


curr_sess_cnt Number of current sessions.

max_sess_cnt High water mark for number of sessions.

multi_user_sess_cnt Number of sessions with more than one user.

sig_sess_cnt Number of sessions with signature signing.

client_disc_sess_cnt Number of session terminations initiated by client side.

filer_disc_sess_cnt Number of session terminations initiated by NetApp storage side.

dup_disc_sess_cnt Number of session terminations initiated by both client and NetApp storage.

max_cred_sess_cnt High water mark for number of credentials attached to a session.

max_tree_sess_cnt High water mark for number of trees attached to a session.

max_msg_sess_cnt High water mark for number of simultaneous messages attached to a session.

curr_conn_user_cnt Number of currently connected users on the NetApp storage.

logon_cnt Number of logon on the NetApp storage.

map_null_user_cnt Number of times a 'null' or 'blank' user was successfully mapped.

uid_hash_alloc_cnt Number of times a new hash table for UIDs is allocated.

curr_share_cnt Number of current shares.

max_share_cnt High water mark for number of shares.

curr_tree_cnt Number of current trees.


max_tree_cnt High water mark for number of trees.

max_fid_tree_cnt High water mark for number of FIDs attached to one tree.

max_search_tree_cnt High water mark for number of searches attached to one tree.

max_core_search_tree_cnt High water mark for number of core searches attached to one tree.

tid_hash_alloc_cnt Number of times a new hash table for TIDs is allocated.

curr_open_file_cnt Number of currently open files and directories.

max_open_file_cnt High water mark for number of open files and directories.

curr_open_dir_cnt Number of currently open directories.

max_open_dir_cnt High water mark for number of open directories.

curr_watch_dir_cnt Number of currently watched directories.

max_watch_dir_cnt High water mark for number of watched directories.

fid_hash_alloc_cnt Number of times a new hash table for FIDs is allocated.

fold_attempt_cnt Number of times an attempt is made to fold a file with the version in a snapshot.

fold_rename_cnt Number of times an entry in the queue of files awaiting folding has to be renamed.

fold_rename_failure_cnt Number of times an attempt to find a rename match on the queue of files awaiting folding fails.

fold_overflow_cnt Number of times an entry can't be added to the queue of files awaiting folding due to its length limit.

fold_duplicate_cnt Number of times when an entry can't be added to the queue of files awaiting folding due to a duplicate.

fold_wafl_too_busy_cnt Number of times the maximum limit of WAFL concurrent folds has been reached.

curr_lock_cnt Number of currently allocated locks.

max_lock_cnt High water mark for number of allocated locks.

x_or_batch_to_l2_cnt Number of OpLock Break from exclusive or batch to level 2.

x_or_batch_to_none_cnt Number of OpLock Break from exclusive or batch to none.


l2_to_none_cnt Number of OpLock Break from level 2 to none.

no_break_ack_cnt Number of OpLock Break ACK before timeout.

no_break_ack_95_cnt Number of Oplock Break ACK before timeout from Win95 clients.

no_break_ack_nt_cnt Number of Oplock Break ACK before timeout from NT clients.

ignored_ack_cnt Number of Oplock Break ACK ignored (e.g. late).

delayed_break_cnt Number of Oplock Break which must be delayed.

pdc_auth_cnt Number of authentication requests to Domain Controllers.

curr_cred_cnt Number of currently active credentials.

max_cred_cnt High water mark for number of allocated credentials.

max_sid_cred_cnt The most group SIDs found on one credential.

built_lgrp_cnt Number of built-in local groups.

user_lgrp_cnt Number of user-defined local groups.

sid_lgrp_cnt Number of defined SIDs for local groups.

curr_mem_ctrl_blk_cnt* Number of current memory control blocks.

max_mem_ctrl_blk_cnt* High water mark for number of memory control blocks.

wait_mem_ctrl_blk_cnt* Number of times waiting for the memory control block to be allocated.

exhaust_mem_ctrl_blk_cnt* Number of times a request for memory control block can not be granted.

wait_mem_buf_cnt Number of times waiting for the memory buffer to be allocated.

auth_qlength* High water mark for no. of queued authentication requests.

block_qlength* High water mark for no. of blocking worker threads.

timer_qlength* High water mark for no. of timer worker threads.

alf_qlength* High water mark for no. of auditing log worker threads.

rpc_qlength* High water mark for no. of SMB RPC worker threads.

offload_qlength* High water mark for no. of VSCAN worker threads.


copy_align_cnt Count of times a buffer is copied for header alignment.

small_buffer_align_cnt Count of times a small buffer is used for header alignment.

large_buffer_align_cnt Count of times a large buffer is used for header alignment.

read_pipe_busy_error_cnt Count of read errors due to the 'busy pipe' condition.

write_pipe_busy_error_cnt Count of write errors due to the 'busy pipe' condition.

trans_pipe_busy_error_cnt Count of transaction errors due to the 'busy pipe' condition.

read_pipe_broken_error_cnt Count of read errors due to the 'broken pipe' condition.

write_pipe_broken_error_cnt Count of write errors due to the 'broken pipe' condition.

trans_pipe_broken_error_cnt Count of transaction errors due to the 'broken pipe' condition.

CIFS DOMAIN


netlogon_latency Average latency for netlogon operations in milliseconds.

netlogon_latency_base Total time spent waiting for netlogon requests to be used as a base counter for netlogon average latency calculation.

lsa_latency Average latency for lsa (local security authority) operations in milliseconds.

lsa_latency_base Total time spent waiting for lsa requests to be used as a base counter for lsa average latency calculation.

samr_latency Average latency for samr (security account manager RPC service) operations in milliseconds.

samr_latency_base Total time spent waiting for samr requests to be used as a base counter for samr average latency calculation.

VSCAN STATISTICS


scanrequests_total Count of scan requests issued.

scanfailures_total Count of scan requests which did not successfully conclude.


virus_detections_total Count of scan completions which reported viruses.

scanrequests_needed_total Count of client accesses which might cause a virus scan.

scanrequest_timeout_inquiries Count of status RPCs issued for requests which timed out.

request_timeout_inquiries_unique Count of requests with at least one status RPCs issued for timeout.

scanrequests_already Count of scans avoided because file is marked already scanned.

scanrequests_already_reset Count of files whose already scanned status was cleared.

scanrequests_duplicate Count of files accessed while a scan was already in progress.

scanrequests_noscan No scan for file access that would normally cause a scan.

scanrequests_noscan_deny Client request denied because no scan could be performed.

scanrequests_throttled_max Most simultaneous scan requests delayed because all vscan servers are busy.

scanrequests_throttled_total Total scan requests delayed because all vscan servers are busy.

scanrequests_throttled_again Total scan requests returned to the delay list a second time because all vscan servers are busy.

disconnect_by_vscanserver Count of disconnections initiated by vscan server.

disconnect_by_filer Count of disconnections initiated by NetApp storage.

scantime_total Total time spent for virus scans in milliseconds.

scantime_count Count of virus scans for scan_time_total.

scanrequests_current Count of scan requests in progress.

scanrequests_oldest Age of oldest request in progress.

scanrequests_throttled_current Active scan requests delayed because all vscan servers are busy.

scanrequests_throttled_oldest Age of oldest active scan request delayed because all vscan servers are busy.

scantime_avg_latency Average latency for virus scans in milliseconds.

scantime_latency_base Base counter for vscan scantime latency calculation.


scanrequests_started Rate of scan requests issued by the NetApp storage.

scanrequests_completed Rate of scan completions received from the vscan server.

scanrequest_timeout_abort Count of requests which timed out.

virus_detections_total Count of scan completions which reported viruses.

VSCAN SERVER STATISTICS


avg_latency Average latency for virus scan operations in milliseconds.

latency_base Total time spent waiting for virus scan requests to be used as a base counter for vscan average latency calculation.

scanrequests_total_server Count of scan request RPCs issued to the vscan server.

scanfailures_total_server Count of scan requests which did not successfully conclude.

virus_detections_total_server Count of scan completions which reported viruses.

scanrequest_timeout_inquiries_server Count of status RPCs issued for requests which timed out.

scanrequests_max_server Most simultaneous scan requests to this vscan server.

scanrequests_current_server Count of scan requests in progress to this vscan server.

scanrequests_oldest_server Age of oldest request in progress to this vscan server.

scantime_total_server Total time spent for virus scans in milliseconds.

scantime_count_server Count of virus scans for scan_time_total.

scantime_avg_latency_server Average latency for virus scans in milliseconds.

scantime_latency_base_server Base counter for scantime latency calculation.

vscan_ops_server_latency Average latency for virus scan operations in milliseconds.

vscan_ops_server_latency_base Total time spent waiting for virus scan requests to be used as a base counter for vscan average latency calculation.


vscan_server_latency Average latency for virus scans in milliseconds.

vscan_server_latency_base Base counter for scantime latency calculation.

scanrequests_timeout_abort_server Count of requests which timed out.

scancompletions_from_server_rate Rate of scan completions received from the vscan server.

scanrequests_to_server_rate Rate of scan requests issued to the vscan server.

SMB SIGNING STATISTICS


conn_time Total time of a connection to the NetApp storage in milliseconds.

time_in Total time spent calculating security signatures for incoming CIFS requests in milliseconds.

time_out Total time spent calculating security signatures for outgoing CIFS requests in milliseconds.



CONCLUSION NetApp storage systems are built on the principles of simplicity, scalability, high data availability, and easy integration with the existing environment. The storage systems support a broad range of Windows client types and client features, fully leverage the management and authentication framework provided by Active Directory, and allow administrators to continue to utilize the native Microsoft administration tools with which they are familiar. As result, the storage systems better protect information assets, dramatically simplify the file-serving environment, and increase overall corporate productivity.

© 2008 NetApp. All rights reserved. Specifications are subject to change without notice. NetApp, the NetApp logo, Go further, faster, DataFabric, Data ONTAP, FilerView, FlexVol, MultiStore, NOW, ONTAPI, RAID-DP, SecureAdmin, SecureShare, SnapDrive, SnapManager, SnapMirror, SnapRestore, Snapshot, vFiler, VFM, Virtual File Manager, and WAFL are trademarks or registered trademarks of NetApp, Inc. in the United States and/or other countries. Microsoft, Windows, Windows NT, and SharePoint are registered trademarks and SQL Server is a trademark of Microsoft Corporation. Linux is a registered trademark of Linus Torvalds. Java and Sun are trademarks of Sun Microsystems, Inc. Oracle is a registered trademark of Oracle Corporation. Symantec is a trademark of Symantec Corporation or its affiliates in the U.S. and other countries. SAP is a registered trademark of SAP AG. UNIX is a registered trademark of The Open Group. All other brands or products are trademarks or registered trademarks of their respective holders and should be treated as such.

Date post:	01-Nov-2014
Category:	Documents
Upload:	ajay2345
View:	172 times
Download:	2 times