CIFS Hands-On Features For Demo - Netapp

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.
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
2 CIFS – Demo.NetApp.com
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
Page 3 of 187 CIFS – demo.NetApp.com

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
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
APPENDIX A: DOMAIN DISCOVERY ........................................................................................................... 150
APPENDIX B: CIFS SIZING FLOWCHART ...................................................................................................... 151
APPENDIX C: NETAPP CIFS ADVANCED OPTIONS ....................................................................................... 152
4 CIFS – Demo.NetApp.com
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

1 HANDS ON EXERCISES
When you see this:
HANDS-ON EXERCISE: DNS Setup
Prerequisite: <BATCH FILE(s) which must be Either perform the follow steps, or to automate
run before proceeding with the Exercise> 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, Vista.workgroup 192.168.10.150
Business edition
Windows 2003 32-bit platform, W2003.demo.netapp.com 192.168.10.100
Server Enterprise
Windows 2008 64-bit platform, W2008.workgroup 192.168.10.101
Server Enterprise
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).
Page 6 of 187 CIFS – Demo.NetApp.com

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 NetBIOS Alias, 24

Antivirus Scanning, 63 Network Time Protocol, 16
CIFS Performance Counters, 175 Northern Storage Suite Quota
Management, 86, 89
CIFS Sizing, 142
PKTrace, 133
DFS, 114
Quotas, 85
DNS Setup, 6, 14
Roaming User Profile, 97
File Screening, 56
SnapRestore, 117
GPO - Verify, 100
SSH Setup, 74
GPO Security, 98
SSL Setup, 78
Group Policy Object, 93
Storage-Level Access Guard, 59
Joining Active Directory, 21
Troubleshooting CIFS, 131
LDAP Authentication with Novell’s
eDirectory, 165 Useradmin Command Line Interface, 62
LDAP NSSWITCH.CONF, 102 Users’ Home Directories, 28
LDAP Permissions, 111 Verify Successful CIFS Installation, 23
Live-View Auditing, 68 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
Either perform the follow steps, or to automate
Prerequisite: none 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 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.
Description of the new share. CIFS clients see this
description when browsing the NetApp storage's shares. If
-comment description the description includes spaces, it must be enclosed in
double quotation marks. If you do not specify a description,
the description is blank.
Maximum number of simultaneous connections to the new
-maxusersuserlimit 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.
Name of the group to which files to be created in the share
-forcegroupgroupname belong. The groupname is the name of a group in the UNIX
group database.
Allow clients to follow symbolic links to destinations on this
- NetApp storage but outside of the current share. Do not
nosymlink_strict_security check that the client is authenticated to the symbolic link's
destination.
Allow clients to follow absolute symbolic links outside of this
share, subject to Windows NT security. This feature requires
-widelink an entry in the /etc/symlink.translations file and it requires
that the client supports Microsoft's Distributed File System
(DFS).
File mode creation mask for shares in qtrees with UNIX or
-umask mask set 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.
Allow Windows clients to cache user documents on this
-auto_document_caching 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.
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
Oplocks 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, the task, execute: CIFSJOIN.BAT. Then,
NTPTIME.BAT 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
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*> 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 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, Either perform the follow steps, or to automate

the task, execute: HOMEDIR.BAT. Then,
SHARESETUP.BAT 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

SERVER> cscript C:\CIFSDEMO\xcacls.vbs o:\ /g
SERVER> cscript C:\CIFSDEMO\xcacls.vbs p:\ /g
SERVER> cscript C:\CIFSDEMO\xcacls.vbs q:\ /g
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.

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_FA
S6000_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_mo
de,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

the task, execute: FPBLOCK.BAT. Then,
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:\

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

the task, execute: SLAG.BAT. Then, proceed
SHARESETUP.BAT 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

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
click on ‘Connect as Pebbles’
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.
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 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 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
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

the task, execute: ABESETUP.BAT. Then,
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
click on ‘Connect as Fred’
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.
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.
click on ‘Connect as Fred’

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 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*> 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/qMH
H2AK9A5Kjd9dUBq7YudjakUiwZKvB7rucg7FaMbOZDqf/HvqdJf3Zem99LaolDWBpGJRNqe
8zmdWWnU/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
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

the task, execute: SSLSETUP.BAT. Then,
proceed to step #1 under Testing your
Certificate
To set up SSL, complete the following steps.

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>

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 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,
the task, execute: QUOTANSS.BAT. Then,
SHARESETUP.BAT
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
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
the task, execute: QUOTANTP.BAT. Then,
SHARESETUP.BAT
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
10. VISTA> Copy C:\CIFSDEMO\McAfee\*.* T:\

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.

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 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 the task, execute: none
6.3.1
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’
4. VISTA> Net use T: \\FAS1\DATA
5. Copy several files to the T: share
VISTA workstation.
Double-click on ‘Connect as Fred’
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
the task, execute: LDAPNSS.BAT. Then,
Prerequisite: none
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*> 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

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\para
meters, 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.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

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

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:

VISTA workstation.
Double-click on ‘Connect as Wilma’
3. Copy several files to the T: share
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 Fully supports drag-and-drop,
than old client, very limited 1-to-many operations
drag-and-drop support)
Integrated Logical-Physical No Yes
Namespace backup/restore No Yes
Must script command line Integrated UI
tools
Automate creation of DFS No Yes
Consolidation Root via wizard
DFS R2 VFM
Open file handling Only when file is closed Yes
Replication style Last-writer wins Master-slave
Replicate to shared cluster No Yes
storage
Graphical View of replication No Yes
topology

Local group processing No Yes, for files and directories
Auditing of actions and No Yes
operations
NetApp storage integration No Yes
Installing DFS
HANDS-ON EXERCISE: DFS

the task, execute: DFSSETUP.BAT. Then,
SHARESETUP.BAT 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.
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 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

the task, execute: VFMSETUP.BAT. Then,
SHARESETUP.BAT, DFSSETUP.BAT 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.

Virtual File Manager Best Practices – March 2008
Virtual File Manager Best Practices – June 2008


Integration of a NetApp Storage System with a UNIX Based LDAP Server – April 2006
Unified Windows and UNIX Authentication – November 2006


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
Prerequisite: none
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


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
Prerequisite: none
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\Tcp
WindowSize 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\Par
ameters\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.

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
Start
Step 1
Collect Perfstat/CIFS DCT during peak traffic
Step 2
Find out:
CPU utilization
Kahuna utilization
# of concurrent users
Yes NetApp storage too

Is CPU % < 30 ? lightly loaded.
Yes Possible problems need

Is CPU/Kahuna < 1.2
to be addressed first
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
Step 3
Adjust max # of users to account for headroom for peaks,

SnapMirror, AV scanning, SMB Signing, KRB reply cache and so on
Step 4
Need to size for Yes Refer to the platform

scaling table to estimate
other platforms the # of users supported
No on other platforms
Step 5
Determine the # of disks
Stop

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:
Values in Regular Values in Competitive

Parameters
Sizing Mode 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

100% 85%
database size
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
The maximum number of open connections to CIFS shares.
Connections
Max Open Files The maximum number of open CIFS file handles.
Max Locked Files The maximum number of locked files.
The maximum number of open locks, including both share and byte-
Max Locks
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 the task, execute: LDAPEDIR.BAT. Then,
W2003 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*> 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

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.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:
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 Copy the source file to the destination file.
dest_file
mv src_file Rename the source file to the destination file.
dest_file
ps [-l] List all the Java threads executing in the Java Virtual Machine.
Gc Run the garbage collector. Report memory heap usage.
classpath Change the “local” classpath used to load classes in a separate name space.
[extra_path]
syspath Append to the systems notion of CLASSPATH.
[extra_path]
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 Execute any of the builtin Data ONTAP commands (hostname and so on) and
command] 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.
Open/Close operations count as a percentage of total CIFS

cifs_open_close_ops_pct
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.
Total observed CIFS operations to be used as a base counter for

cifs_latency_base
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 Information operations (SMB Code = 0x32, SubCode =

query_fs_info_ops
0x03).
Query Path Information operations (SMB Code = 0x32, SubCode =

query_path_info_ops
0x05).
Set Path Information operations (SMB Code = 0x32, SubCode =

set_path_info_ops
0x06).
Query File Information operations (SMB Code = 0x32, SubCode =

query_file_info_ops
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).
Query NTAP Extended Attribute operations (SMB Code = 0x32,

get_ntap_ext_attr_ops
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).
Create with extended attributes operations (SMB Code = 0x32,

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

Resume search for files operations (SMB Code = 0x32, SubCode =
find_next_ops
0x02).
Create Directory with extended attributes operations (SMB Code =

create_dir_ext_ops
0x32, SubCode = 0x0D).
search_ops Search operations (SMB Code = 0x81).
find_close_ops FindClose2 operations (SMB Code = 0x34).
Start directory watch operations (SMB Code = 0x25, SubCode =

nt_trans_notify_ops
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 Security Descriptor operations (SMB Code = 0x25, SubCode =

set_sec_ops
0x03).
Query Security Descriptor operations (SMB Code = 0x25, SubCode =

query_sec_ops
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).
Report DFS inconsistency operations (SMB Code = 0x32, SubCode =

dfs_report_ops
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.
Number of session terminations initiated by both client and NetApp

dup_disc_sess_cnt
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.
High water mark for number of simultaneous messages attached

max_msg_sess_cnt
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.
Number of times an attempt is made to fold a file with the version

fold_attempt_cnt
in a snapshot.
Number of times an entry in the queue of files awaiting folding has

fold_rename_cnt
to be renamed.
Number of times an attempt to find a rename match on the queue

fold_rename_failure_cnt
of files awaiting folding fails.
Number of times an entry can't be added to the queue of files

fold_overflow_cnt
awaiting folding due to its length limit.
Number of times when an entry can't be added to the queue of

fold_duplicate_cnt
files awaiting folding due to a duplicate.
Number of times the maximum limit of WAFL concurrent folds has

fold_wafl_too_busy_cnt
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.
Number of times waiting for the memory control block to be

wait_mem_ctrl_blk_cnt*
allocated.
Number of times a request for memory control block can not be

exhaust_mem_ctrl_blk_cnt*
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.
Total time spent waiting for netlogon requests to be used as a base

netlogon_latency_base
counter for netlogon average latency calculation.
Average latency for lsa (local security authority) operations in

lsa_latency
milliseconds.
Total time spent waiting for lsa requests to be used as a base counter
lsa_latency_base
for lsa average latency calculation.
Average latency for samr (security account manager RPC service)

samr_latency
operations in milliseconds.
Total time spent waiting for samr requests to be used as a base counter
samr_latency_base
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.
Count of requests with at least one status RPCs issued for

request_timeout_inquiries_unique
timeout.
Count of scans avoided because file is marked already

scanrequests_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.
Most simultaneous scan requests delayed because all vscan

scanrequests_throttled_max
servers are busy.
Total scan requests delayed because all vscan servers are

scanrequests_throttled_total
busy.
Total scan requests returned to the delay list a second time

scanrequests_throttled_again
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.
Active scan requests delayed because all vscan servers are

scanrequests_throttled_current
busy.
Age of oldest active scan request delayed because all vscan

scanrequests_throttled_oldest
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.
Total time spent waiting for virus scan requests to be

latency_base used as a base counter for vscan average latency
calculation.
scanrequests_total_server Count of scan request RPCs issued to the vscan server.
Count of scan requests which did not successfully

scanfailures_total_server
conclude.
virus_detections_total_server Count of scan completions which reported viruses.
Count of status RPCs issued for requests which timed

scanrequest_timeout_inquiries_server
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.
Total time spent waiting for virus scan requests to be

vscan_ops_server_latency_base 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
Counter
Description
Name
conn_time Total time of a connection to the NetApp storage in milliseconds.
Total time spent calculating security signatures for incoming CIFS requests in
time_in
milliseconds.
Total time spent calculating security signatures for outgoing CIFS requests in
time_out
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.

CIFS Hands-On Features For Demo - Netapp

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

CIFS Hands-On Features For Demo - Netapp

Загружено:

Авторское право:

Доступные форматы

NETAPP DEMONSTRATION FACILITY

CIFS Hands-On Features for demo.NetApp.com

Page 3 of 187 CIFS – demo.NetApp.com

Page 5 of 187 CIFS – demo.NetApp.com

1.1 DEMO SETUP

Hardware Version DNS IP

User Context Group

The password for all users is: netapp1

Page 6 of 187 CIFS – Demo.NetApp.com

1.2 AVAILABLE BATCH FILES

Access-Based Enumeration, 71 NetBIOS Alias, 24

Page 7 of 187 CIFS – demo.NetApp.com

2.1.1 Microsoft Gold Partnership

2.1.2 Microsoft Core Protocol Program

Page 8 of 187 CIFS – Demo.NetApp.com

2.1.4 Support and Escalation with NetApp and Microsoft

2.1.5 Compatibility Matrix

2.2 NETAPP TECHNICAL REPORT REFERENCE

Page 9 of 187 CIFS – demo.NetApp.com

Page 10 of 187 CIFS – Demo.NetApp.com

Compatibility with Windows Vista and Windows Server 2008

Page 11 of 187 CIFS – demo.NetApp.com

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

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

¾ OTHER: IP addresses returned by the DNS SRV record query:

Page 12 of 187 CIFS – Demo.NetApp.com

Page 13 of 187 CIFS – demo.NetApp.com

Page 14 of 187 CIFS – Demo.NetApp.com

3.3.2 CIFS with Microsoft Windows Internet Naming Service

3.3.3 Site Awareness

3.3.4 Network Time Protocol (NTP)

Page 15 of 187 CIFS – demo.NetApp.com

3.3.5 Create a New Active Directory OU to Manage the NetApp

Page 16 of 187 CIFS – Demo.NetApp.com

Windows 2000 Server Modes

The limitations of a Windows 2000 Server are:

3.3.7 NIS Group Lookup

Page 17 of 187 CIFS – demo.NetApp.com

3.3.8 Creating a CIFS Share

Page 18 of 187 CIFS – Demo.NetApp.com

3.3.10 What You Can Do with Snapshot Copies

Page 19 of 187 CIFS – demo.NetApp.com

3.4.1 CIFS Shares

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

Page 20 of 187 CIFS – Demo.NetApp.com

-no_caching Disallow Windows clients from caching any files on this

-auto_program_caching Allow Windows clients to cache programs on this share. The

Browsable This specifies that the share can be browsed by Windows

Showsnapshot This specifies that Snapshot copies can be viewed and

3.4.2 Join Active Directory from NetApp Storage as a Windows

HANDS-ON EXERCISE: Joining Active Directory

Page 21 of 187 CIFS – demo.NetApp.com

From NetApp Storage

Page 22 of 187 CIFS – Demo.NetApp.com

3.4.3 Verifying Successful CIFS Installation

Page 23 of 187 CIFS – demo.NetApp.com

HANDS-ON EXERCISE: NetBIOS Alias

Ctrl+C to end file

Page 24 of 187 CIFS – Demo.NetApp.com

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

3. FAS1> cifs nbalias load

Connecting Microsoft Management Console to the Storage System

FAS1> options cifs.home_dirs_public (hidden option, default: off)

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