CIFS Administration On Data ONT - NetApp University

NetApp University
Data ONTAP 7.3

CIFS Administration on
Student Guide
NetApp University - Do not distribute or duplicate

NETAPP UNIVERSITY
CIFS Administration on Data ONTAP 7.3

Version Number: Version 5.0
Release Number: Release 7.3
Course Number: STRSW-ED-ILT-CIFSAD-REV03
Catalog Number: STRSW-ED-ILT-CIFSAD-REV03-SG


0-2 CIFS Administration on Data ONTAP 7.3: M00_Welcome
2008 NetApp. This material is intended for training use only. Not authorized for re-production purposes.
ATTENTION
The information contained in this guide is intended for training use only. This guide contains information
and activities that, while beneficial for the purposes of training in a closed, non-production environment,
can result in downtime or other severe consequences and therefore are not intended as a reference guide.
This guide is not a technical reference and should not, under any circumstances, be used in production
environments. To obtain reference materials, please refer to the NetApp product documentation located
at www.now.com for product information.
COPYRIGHT
2008 NetApp. All rights reserved. Printed in the U.S.A. Specifications subject to change
without notice.
No part of this book covered by copyright may be reproduced in any form or by any meansgraphic,
electronic, or mechanical, including photocopying, recording, taping, or storage in an electronic retrieval
systemwithout prior written permission of the copyright owner.
NetApp reserves the right to change any products described herein at any time and without notice.
NetApp assumes no responsibility or liability arising from the use of products or materials described
herein, except as expressly agreed to in writing by NetApp. The use or purchase of this product or
materials does not convey a license under any patent rights, trademark rights, or any other intellectual
property rights of NetApp.
The product described in this manual may be protected by one or more U.S. patents, foreign patents,
or pending applications.
RESTRICTED RIGHTS LEGEND
Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph
(c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.277-7103
(October 1988) and FAR 52-227-19 (June 1987).
TRADEMARK INFORMATION
NetApp, the NetApp logo, and Go further, faster, FAServer, NearStore, NetCache, WAFL, DataFabric,
FilerView, SecureShare, SnapManager, SnapMirror, SnapRestore, SnapVault, Spinnaker Networks,
the Spinnaker Networks logo, SpinAccess, SpinCluster, SpinFS, SpinHA, SpinMove, SpinServer, and
SpinStor are registered trademarks of Network Appliance, Inc. in the United States and other countries.
Network Appliance, Data ONTAP, ApplianceWatch, BareMetal, Center-to-Edge, ContentDirector, gFiler,
MultiStore, SecureAdmin, Smart SAN, SnapCache, SnapDrive, SnapMover, Snapshot, vFiler, Web Filer,
SpinAV, SpinManager, SpinMirror, and SpinShot are trademarks of NetApp, Inc. in the United States and/or
other countries.
Apple is a registered trademark and QuickTime is a trademark of Apple Computer, Inc. in the United States
and/or other countries.
Microsoft is a registered trademark and Windows Media is a trademark of Microsoft Corporation in the
United States and/or other countries.
RealAudio, RealNetworks, RealPlayer, RealSystem, RealText, and RealVideo are registered trademarks
and RealMedia, RealProxy, and SureStream are trademarks of RealNetworks, Inc. in the United States
and/or other countries.
All other brands or products are trademarks or registered trademarks of their respective holders and should
be treated as such.
NetApp is a licensee of the CompactFlash and CF Logo trademarks.


TABLE OF CONTENTS
COURSE INTRODUCTION ............................................................................................................ 0-1
MODULE 1: OVERVIEW .............................................................................................................. 1-1
MODULE 2: WORKGROUPS ...................................................................................................... 2-1
MODULE 3: SHARES AND SESSIONS ...................................................................................... 3-1
MODULE 4: ACCESS CONTROL ............................................................................................... 4-1
MODULE 5: DOMAINS ................................................................................................................ 5-1
MODULE 6: ADVANCED ADMINISTRATION ............................................................................ 6-1
MODULE 7: PERFORMANCE ..................................................................................................... 7-1
MODULE 8: TROUBLESHOOTING ............................................................................................ 8-1



This page is intentionally left blank.


CIFS Administration
on Data ONTAP 7.3
Version 5.0
Course#: STRSW-ED-ILT-CIFSAD-REV03

CIFS ADMINISTRATION ON DATA ONTAP 7.3


2 2008 NetApp. All rights reserved.
Logistics
Introductions
Schedule (start time, breaks, lunch, close)
Telephones and messages
Food and drinks
Restrooms

LOGISTICS


Safety
Alarm signal
Evacuation route
Assembly area
Electrical safety

SAFETY


Course Objectives
At the end of this course, you should be able to
Identify the appropriate server environment for
your storage system to support Windows
client users
Configure the CIFS environment on your
storage system by licensing CIFS, setting up
CIFS, and setting options
Administer and manage a storage system in a
CIFS environment
Troubleshoot basic CIFS problems

COURSE OBJECTIVES


Course Agenda
Day 1
Introductions
Module 1: Overview
Module 2: Workgroups
Module 3: Shares and Sessions
Module 4: Access Control
Module 5: Domains
Day 2
Module 6: Advanced Administration
Module 7: CIFS Performance
Module 8: CIFS Troubleshooting

COURSE AGENDA


Information Sources
NOW
TM
(NetApp on the Web) Site
http://NOW.NetApp.com
NetApp Training Schedules
http://www.netapp.com/us/services/university/
NetApp University Support
http://netappusupport.custhelp.com

INFORMATION SOURCES



TYPOGRAPHIC CONVENTIONS

2008 Network Appliance, Inc. All rights reserved. Specifications are subject to change without notice. NetApp, the Network Appliance logo,
NearStore, SnapLock, and SnapVault are registered trademarks and Network Appliance, DataFort, FlexClone, and FlexVol are trademarks of
Network Appliance, Inc. in the U.S. and/or other countries. Windows is a registered trademark of Microsoft Corporation. UNIX is a registered
trademark of The Open Group. Oracle is a registered trademark of Oracle Corporation. All other brands or products are trademarks or registered
trademarks of their respective holders and should be treated as such.
O
v
e
r
v
i
e
w
1-1 CIFS Administration on Data ONTAP 7.3: M01_Overview
MODULE 1: OVERVIEW
Overview
Data ONTAP 7.3

OVERVIEW

Module Objectives
Describe basic CIFS features
Describe the following network environments:
Microsoft Windows workgroup
Non-Windows workgroup
Windows domains
Describe how a storage system authenticates
users in each server environment
Explain the advantages and disadvantages of
each server environment
NetApp Confidential - Internal Use only

MODULE OBJECTIVES

CIFS Features

CIFS FEATURES

CIFS Definition
What is Common Internet File System (CIFS)?
A Microsoft network file-sharing protocol that
evolved from the Server Message Block (SMB)
protocol
How does CIFS work?
Access and manipulate files and folders on
remote servers as if they are on a local machine

CIFS DEFINITION

The Common Internet File System (CIFS) is a Microsoft network file-sharing protocol that
evolved from the Server Message Block (SMB) protocol.
When using CIFS, any application that processes network I/O can access and manipulate files and
folders (directories) on remote servers in a way similar to that for accessing and manipulating
files and folders on the local system.

CIFS: Basic Functions
Network browsing to locate:
Machines within an environment (provided by a
browse list)
Shared resources that are available on a given
machine (provided by that machine)
User authentication
Authorization
Shared Resource Access
Folder and File Access

CIFS BASIC FUNCTIONS

The following are some CIFS features available in a Windows workgroup and domain:
Network browsing to locate machines within a domain or workgroup (provided by a
browse list) and shares that are available on each machine (provided by that machine).
User authentication.
Authorization at the share level and folder and file level.

CIFS: Basic Functions (Cont.)
Basic file attributes
Read-only
Archive
System
Hidden
Extended NTFS file attributes of indexing,
compression, and encryption
Unicode support
File locking (opportunistic locks)
Dialect negotiation

CIFS BASIC FUNCTIONS (CONT.)
EXTENDED ATTRIBUTES
Extended NTFS file attributes are not generally supported on a storage system. However,
Encrypted File Systems (EFS) are supported with Open Systems SnapVault.
UNICODE SUPPORT
The universal character encoding standard provides a unique number for every character, no
matter what the platform, program, or language.
Characters are represented by more than eight bits.
OPPORTUNISTIC LOCKS (OPLOCKS FOR DOMAINS ONLY)
Guarantee to the client that file content is not allowed to be changed by the server or, if some
change is imminent, the client is notified before the change proceeds.
Oplocks are used to synchronize data and enhance performance.

DIALECT NEGOTIATION
Each protocol version is referred to as a dialect and assigned a unique string identifier.
Dialect Identifier Comments
PC NETWORK
PROGRAM 1.0
The original protocol, also known as the core protocol.
PCLAN1.0 Some define this as an alternative to the core protocol.
MICROSOFT
NETWORKS 1.03
This extended the core protocol and is known as core plus
protocol.
MICROSOFT
NETWORKS 3.0
This protocol is known as Extended 1.0 Protocol or LAN Manager
1.0 and was created when IBM and Microsoft were working
together on OS/2.
LANMAN1.0
Identical to the MICROSOFT NETWORKS 3.0 dialect except that
it was intended for use with OS/2 clients.
Windows for Workgroups
3.1a
Windows for Workgroups Version 1.0 (similar to LANMAN1.0
dialect).
DOS LM1.2X002
This protocol is known as Extended 2.0 Protocol or LAN Manager
2.0.
LM1.2X002 This dialect represents OS/2 LANMAN version 2.0.
DOS LANMAN2.1
This protocol is known as LAN Manager 2.1 and is documented in
a paper titled Microsoft Networks SMB File Sharing Protocol
Extensions, Document Version 3.4.
LANMAN2.1 This dialect represents OS/2 LANMAN2.1.
NT LM 0.12
This dialect is sometimes called NT LANMAN and was developed
for use with Windows NT. All Windows 9x clients and Windows
2000 servers and XP clientscan communicate with this dialect.

See Common Internet File System (CIFS) Technical Reference Revision 1.0 by the Storage
Networking Industry Association (SNIA) for more information.
Updates for SMB 2.0
SMB 2.0
Next Generation of CIFS
NTLM v2
SMB 2.0 supported in:
Data ONTAP 7.3 and later
Windows Vista and later clients
Window Server 2008 and later servers

UPDATES FOR SMB 2.0

Data ONTAP 7.3 is compatible with Windows Vista clients and the new Windows Server 2008.
Among the Windows Server 2008 features that are compatible with 7.3, NetApp supports SMB
2.0 and NTLM v2, and matches all performance gains from using folder synchronization.

9 2008 NetApp. All rights reserved. 9
SMB 2.0 Features
Increased performance
Folder synchronization is 50% faster
More reliable
Increased scalability
Increased number of file handles
Compatible with Microsoft's new Transactional
NTFS (TxF) for Vista and Windows Server
2008 applications

FEATURES

The new Server Message Block 2.0 protocol provides a number of communication enhancements,
including greater performance when connecting to file shares over high-latency links and better
security through the use of mutual authentication and message signing. Data ONTAP 7.3 is fully
compatible with SMB 2.0.
The following are some of the advantages that SMB2.0 provides. SMB 2.0 supports a way of
compounding operations to reduce round trips, making it less chatty than SMB 1.0. This reduces
network traffic and increases performance over slow WAN links. SMB 2.0 is more resilient to
small network outages making it more reliable. According to Microsoft, re-directed folder
synchronization will be 50 percent faster for Windows Vista clients accessing a Windows Server
2008. Data ONTAP matches any performance gains introduced by Microsoft for their Windows
Server 2008.
SMB 2.0 is more scalable because it supports much larger buffer sizes and an increase in the
number of concurrent open file handles. A file handle is a temporary file that is assigned by the
operating system when a user opens a file. A special area of main memory is reserved for file
handles and determines how many files can be open at once. The increase in concurrent file
handles means that a server can have a larger list of shares.
Another feature of SMB 2.0 is Microsofts new Transactional NTFS (TxF) capabilities in
Windows Vista and Windows Server 2008. Transactional NTFS allows file operations on an
NTFS file system volume to be performed in a transaction. Transactions can be used to both
preserve data integrity and handle error conditions reliably. TxF requires clients to use and
deploy SMB 2.0. TxF allows all file operations to be performed as transactions to preserve the
integrity of data on disk in case of unexpected error conditions.

NetApp Supporting SMB 2.0
Data ONTAP 7.3 supports SMB 2.001.
The SMB version is negotiated between the
client and Data ONTAP automatically.
Data ONTAP will fall back to SMB 1.0 when
the client is using 1.0.
Vista /
Windows Server 2008
SMB 2.0
Windows XP /
Windows Server 2003
SMB 1.0
Windows 98 or previous /
Windows Server 2000 or previous
SMB 1.0

NETAPP SUPPORTING SMB 2.0

Data ONTAP 7.3 support SMB 2.001. When a client requests that a drive be mapped, the storage
system and the client negotiate the version of SMB. If the client cannot use SMB 2.001 then it
falls back to SMB 1.0, preserving the connectivity of Windows Vista or Windows Server 2008.
When a client tries to discover whether a server supports SMB 2.001, it initiates a TCP session to
port 445 on the server and issues a normal SMB negotiate protocol request to the storage system
specifying the new dialect SMB 2.001. Windows Vista clients remember which servers support
SMB 2.001, so further sessions attempt SMB 2.001 immediately.
As customers would expect, existing NetApp storage systems upgraded to Data ONTAP 7.3
support Windows Vista and Windows Server 2008 from both an interoperability standpoint and a
functionality standpoint. Data ONTAP 7.3 supports SMB 2.001 for Windows Server 2008 and
Windows Vista desktop clients as well as SMB 1.0 for legacy servers and other desktop clients.

1. SMB_COM_NEGOTIATE
Client requests CIFS dialect, a list of strings with dialects supported.
2. SMB_COM_NEGOTIATE
Server responds with clients requested CIFS dialect. An 8-byte random string is sent back,
which is used in the next step to authenticate the client during logon.
3. SMB_COM_SESSION_SETUP_ANDX
Client sends its user name and password to obtain a Users Security ID (SID).
4. SMB_COM_SESSION_SETUP_ANDX
If the username and password are accepted, a valid SID is included in the packet. If not, an
error code is sent and access is denied.
5. SMB_COM_TREE_CONNECT_ANDX
Client requests access to the share. The packet contains the fully specified path in Uniform
Naming Convention (UNC) form.
Client-Server Communications
Client Server

CLIENT-SERVER COMMUNICATIONS

This example demonstrates client-server communications for session, share access, and file
authorization. The following are the basic steps.
The client contacts the server and requests a CIFS dialect.
The server responds with the supported CIFS dialect and the next logon step.

Together, these two steps are called dialect negotiation.

The client responds with its username and password.
The server sends a Security ID (SID) if the username and password are accepted or an error
message if they are not accepted.

Together, these two steps are called user authentication.
The client requests access to a share. The storage system caches all security IDs (SIDs) and
usernames received from the domain controller at boot time.

6. SMB_COM_TREE_CONNECT_ANDX
If access to the share is granted, the server returns the 16-bit tree ID (TID) corresponding to
the share. If the path is not found or there are insufficient credentials, an error is sent.
7. SMB_COM_OPEN_ANDX
Client requests to open a file on a share. The name of the file is included.
8. SMB_COM_OPEN_ANDX
If access to the file is granted, the server returns the file ID of the requested file. If the file
does not exist or there are insufficient credentials, an error is sent.
9. SMB_COM_READ_ANDX
The client requests that the server read the data and return its contents. The file ID obtained
by the client when the client was opened is included.
10. SMB_COM_READ_ANDX
The requested data is returned.
Client-Server Communications (Cont.)
Client Server

CLIENT-SERVER COMMUNICATIONS (CONT.)

The server responds with a tree ID to the requested share (if access is allowed).

Together, steps 5 and 6 are called shared resource authorization.
The client requests to open a file on a share.
If access is allowed, the server responds with the ID of the requested file.

Together, these two steps are called folder/file authorization.
The client requests that the server read the data and return its contents.
The server sends the requested data. During this process, the Access Control Lists (ACLs) are
checked for permissions.

Together, these two steps are called folder/file I/O.

CIFS Environments

CIFS ENVIRONMENTS

Network Environments
Storage systems can participate in:
Workgroups
Windows workgroup
Domains
Windows NT 4.0
Windows Active Directory

NETWORK ENVIRONMENTS

Client Requirements
Each client in a CIFS environment must:
Locate other computers
Request resources from a server
Requires user authentication
Requires resource authorization
Share permissions
File-level permissions
NOTE: Implementation differs depending on the CIFS environment.

CLIENT REQUIREMENTS

In a network, a Windows client user requires the ability to:
Find other machines (computers)
Request resources from a server (any machine in the role of a server)

Requesting resources requires user authentication (verification of a users identity) to establish a
session with a server and user authorization (permission) to access a share and resources (folders
and files) in a share.

Windows Workgroups

WINDOWS WORKGROUPS

Windows Workgroup
A Windows workgroup:
Logical grouping of networked machines
Shares resources, such as folders and files
Each machine in the workgroup authenticates
and authorizes users via a local security
database
NOTE: Users must have an account on the machine they wish to
access.

WINDOWS WORKGROUP

A Windows workgroup is a simple, logical group of networked machines (computers) that share
resources, such as folders and files.
Each machine has its own Security Accounts Manager database (for Windows NT) or a local security
database (for Windows 2000 or later) that is used to perform user authentication and user
authorization.
Each user that wants to access resources on a machine must have a user account on that machine.

Storage System Joins a Workgroup
For a storage system to join a Windows workgroup
It must broadcast its name to the network
The master browser must update the master browse
list
It must broadcasts the browse list to all members of
the domain
15-minute delay possible
NOTE: Storage systems do not pull the master browse list
Storage
System
Master
Browser
Machine
B
List List List
Im a storage system,
and Im new!

STORAGE SYSTEM JOINS A WORKGROUP

Although workgroup machines normally pull the updated master browse list to their local
machines, the storage system does not. The browse list is a mechanism for members of the
workgroup to find other members. The storage system always acts in a server role. Therefore,
there is no need to discovery other members in the workgroup.

Name Resolution in a Workgroup
Machine name to IP resolution:
A user broadcasts a name query on the
network
The requested machine responds to the name
query by returning its IP address
Storage
System
Machine
A
Machine
B
List List List
Storage systems IP
What is the IP address
of the storage system?

NAME RESOLUTION IN A WORKGROUP

How does workgroup machine-name resolution work?
A machine broadcasts a name query to other machines in the network. For example, Machine A
may broadcast a query for the IP address of the storage system. The storage system responds to
the name query by broadcasting its IP address back to Machine A.

Storage System User Authentication
Storage system user authentication is performed
locally:
Users are added to a storage system
Authentication is performed locally
Authenticated users are provided with a
session
Storage
System
Authenticates
Machine B
Machine
Accounts
User Info
username
password
group info
user rights
Master
Browser
Machine
B
User
Info
User
Info
List
User
Info
List List
Local User
Accounts
Machine B requests user
session authentication
Session with
Machine B

STORAGE SYSTEM USER AUTHENTICATION

How does user authentication work on a storage system in a workgroup?
Users (local-user accounts) are added to a storage system and user authentication is performed
locally on the storage system. User session authentication with a user name and password enables
a user to establish a session with the storage system.
Data access on a storage system requires a network logon to the storage system. A user can
administer a storage system through the network (for example, by way of a Telnet session) using
a local account on the storage system; however, a user cannot log on locally to a storage system
to access data.
The Machine B user requests user session authentication from the storage system. The storage
system authenticates the Machine B user by using the user name and password found in the
storage system local-user account. After the Machine B user is successfully authenticated, a
session is established with the Machine B user and the storage system.
Authenticated users can browse a storage system for available resources, but must be authorized
to access a share and resources in a share.

Non-Windows
Workgroups

NON-WINDOWS WORKGROUPS

Non-Windows Workgroups
A non-Windows workgroup:
Support for Windows client machines when
there is no Windows workgroup or domain
Share resources with Windows client users
This environment is also referred to as:
UNIX password workgroup
/etc/passwd-style workgroup

NON-WINDOWS WORKGROUPS

A non-Windows workgroup is a logical group of networked machines that share resources with
Windows client users; the networked machines are members of neither a Windows workgroup
nor a Windows domain.
This network environment also is called:
UNIX password workgroup
/etc/passwd-style workgroup

Non-Windows Workgroup Storage System
Provides user authentication by one or more of the
following:
Storage system local /etc/passwd file
Network Information Services (NIS) server
Lightweight Directory Access Protocol (LDAP) server
Provides name to IP resolution by one or more of the
following:
Storage system local /etc/hosts file
NIS server
Domain Name System (DNS) server
NOTE: /etc/nsswitch.conf sets the order of precedence for the
mechanism used

NON-WINDOWS WORKGROUP STORAGE SYSTEM

When a storage system becomes a non-Windows workgroup server, it provides services to
clients. An example is an all-UNIX work environment with many UNIX workstations and a few
Windows clients with users that need CIFS resources. Note that any UNIX reference also
includes LINUX.
Servers functioning as directory stores for user information (user names, passwords, and group
information):
Storage systems local /etc/passwd file
Network Information Services (NIS) server
Lightweight Directory Access Protocol (LDAP) server

Servers that can provide machine (host) name resolution:
Storage systems local /etc/hosts file
NIS server
Domain Name System (DNS) server

Windows Workgroup Advantages
Does not require running Windows Domain
Controller
Advantageous for small organizations
Simple to design and implement
Convenient for a limited number of machines
in close proximity
Limited to 96 local clients

WINDOWS WORKGROUP ADVANTAGES

Non-Windows Workgroup Advantages
In a mostly UNIX environment, CIFS shares
made available to the few Windows client
users
User authentication performed by existing:
NIS
LDAP server
/etc/passwd file
Name to IP resolution performed by existing:
NIS
DNS server
/etc/hosts

NON-WINDOWS WORKGROUP ADVANTAGES

Workgroup Disadvantages
Administrative overhead in maintaining a list of
user accounts on multiple machines
Any changes to a user account (for example,
passwords) could be made on each machine
Joining or leaving a workgroup must be
replicated by the master browse list
Delay up to 15 minutes
Generally, a browse list cannot span subnets
Workgroup depends on subnet broadcasting

WORKGROUP DISADVANTAGES

Windows Domains

WINDOWS DOMAINS

Window Domains
A Windows domain:
A logical grouping of networked machines
Share a central directory of resources
A domain controller centralizes:
User/Group/Machine account management
User authentication
Group policy management across the domain
NOTE: In this module, we will consider NT4 and Active Directory
domains together.

WINDOWS DOMAINS

Typical Machines in a Domain
Type of machines in a domain:
Clients
Clients requires resources from a server
Member servers
Servers that provide resources to clients
Domain controllers (DCs)
Servers that each maintain a copy of a centralized
database
Domain name resolution servers
Windows Internet Name Service (WINS) for Windows NT
4.0 domains
Domain Name System (DNS) for Windows 2000 (or later)
domains

TYPICAL MACHINES IN A DOMAIN

NOTE: There are other potential machines in a Windows domain environment, including a
global catalog server, PDC emulator, schema master, RID master, domain naming master,
bridgehead server, as well as others.

Storage System Joins a Domain
When a storage system joins a domain:
Domain controller adds the storage system to
a domain database
Becomes a member server
Clients Member
Server
Joining a domain
Domain
Controller
Machine
Accounts
Machine
name
Directory

STORAGE SYSTEM JOINS A DOMAIN

When a storage system joins a domain, it becomes a member server that provides services to
clients. The storage system (member server) goes to a domain controller and the domain
controller adds the machine account to the directory database.

Domain-Name-to-IP Resolution
When a client attempts to access a storage
systems resources:
Requests the browse list from the DC
Contacts DNS/WINS server for the IP address
Communicates with the storage system
Clients DNS/WINS Member
Server
What machines are available?
Domain
Controller
Here is the browse list
What is the storage systems IP?
Here is the storage systems IP

DOMAIN-NAME-TO-IP RESOLUTION

When a storage system joins a domain, it becomes a member server that provides services to
clients. The storage system (member server) goes to a domain controller and the domain
controller adds the machine account to the directory database.

User Authentication
User Authentication on a storage system in a
domain
Domain users created on DC
User session authentication occurs at the DC
Authenticated users must be authorized to
access a share and resources
Client A Client B Domain
Controller
Member
Server
User
Info
Session with Client B
Client B requests user
session authentication
Authenticates Client B

USER AUTHENTICATION

How does user authentication work on a storage system in a domain?
Domain users (already added to the domain controller) can browse the storage system for
available shares and then request access to the storage system and its shares and resources in a
share.
User session authentication with a user name and password is performed centrally on the domain
controller; this establishes a user session with the storage system. Users must be authorized to
access a share and resources in a share.
Data access to a storage system requires a network logon to the storage system. A user can
administer a storage system through the network (for example, by way of a Telnet session) using
a local account on the storage system; however, a user cannot log on locally to a storage system
to access data.
The Client B user requests user session authentication with the member server (storage system).
The member server goes to the domain controller to authenticate the Client B user. The domain
controller authenticates the Client B user and a session is established with the Client B user and
the member server (storage system).

Domain Advantages / Disadvantages
Advantages
Centralized administration of all user information
A centralized mechanism for authentication
Scalable
Disadvantages
Administrative overhead
Complexity

DOMAIN ADVANTAGES / DISADVANTAGES

Module Summary

MODULE SUMMARY

Module Summary
In this module, you should have learned to:
Describe basic CIFS features
Describe the following network environments:
Microsoft Windows workgroup
Windows domains
Describe how a storage system authenticates
users in each server environment
Explain the advantages and disadvantages of
each server environment

MODULE SUMMARY

Exercise
Module 1: CIFS Overview
Estimated Time: 15-60 minutes

EXERCISE

Please refer to your Exercise Guide for more instruction.

W
o
r
k
g
r
o
u
p

2-1 CIFS Administration on Data ONTAP 7.3: M02_Workgroups
MODULE 2: WORKGROUPS
Workgroups
Data ONTAP 7.3

WORKGROUPS


Module Objectives
By the end of this module, you should be able to:
License CIFS on a storage system
Join a storage system to a Windows
workgroup environment using the cifs
setup command
Observe the results of cifs setup
Manage newly created configuration files for
the CIFS workgroup environment

MODULE OBJECTIVES


Setup Overview

SETUP OVERVIEW


Preparing a Storage System
To prepare a storage system to support
Windows Clients, perform the following:
License CIFS
Set up the CIFS environment
Configure CIFS
Manage CIFS

PREPARING A STORAGE SYSTEM

To prepare a storage system to support Windows client users, perform the following:
1. License CIFS
2. Set up the CIFS environment
3. Configure CIFS
4. Manage CIFS

CLI or FilerView
The CIFS service on a storage system can be
configured from either:
Command Line Interface (CLI)
Console
Telnet
RSH
SSH
FilerView
Navigate to:
http://[storage_system_name_or_ip]/na_admin
Click the FilerView icon

CLI OR FILERVIEW

For more information on how to access the storage systems console via the command line, please
see the Data ONTAP Fundamental course.
FilerView is the graphical user interface for a storage system.
To access FilerView
Open an Internet browser and type the following address:
http://storage_system_name/na_admin

where storage_system_name is the name or IP address of the storage system.
The FilerView main navigational page appears.
Click the FilerView icon.

FilerView Main Navigational Page


License

LICENSE


Licensing CIFS
From CLI:
Enter the license add command with the license
code.
system> license add license_code
A cifs site license has been installed.
Run cifs setup to enable cifs.
From FilerView
Go to the Manage Licenses window
NOTE: CIFS license may have been preinstalled at the factory

LICENSING CIFS

To license CIFS on the storage system, you can use either the Data ONTAP command line
interface or FilerView.
From the Data ONTAP command line interface (CLI) on the storage system, enter the license
add command with the CIFS license code.
Format: license add license_code
system> license add XXYYZZA
A cifs site license has been installed.
Run cifs setup to enable CIFS.

From the FilerView interface for the storage system, do the following:
In the left column, select Filer and then Manage Licenses.
Enter the CIFS license.
Click the Apply button located at the bottom of the window.

NOTE: The CIFS license may have been preinstalled at the factory.


Joining a CIFS Environment
To join a storage system to a CIFS environment:
From CLI, run the cifs setup command
NOTE: If the CIFS license was preinstalled at the factory, the
cifs setup script is run automatically at the end of storage
system setup script.
From FilerView, choose the CIFS Setup
Wizard
FilerView->CIFS->Configure->Setup Wizard
NOTE: Upon completion of setup, the CIFS service is started.

JOINING A CIFS ENVIRONMENT

To join a storage system to a CIFS environment, you can use either the Data ONTAP CLI or
FilerView:
From the Data ONTAP CLI, run the cifs setup command.
Format: cifs setup
NOTE: If the CIFS license was preinstalled at the factory, the cifs setup script is run
automatically
at the end of storage system setup script.

From FilerView, choose the CIFS Setup Wizard.
FilerView->CIFS->Configure->Setup Wizard

Upon completion of the setup, the CIFS service is started.


CLI cifs setup

CLI CIFS SETUP


During cifs setup
system> cifs setup
This process will enable CIFS access to the filer
from a Windows system.
Note: Use "?" for help at any prompt and Ctrl C to
exit without committing changes.
Your filer does not have WINS configured and is
visible only to clients on the same subnet.
Do you want to make the system visible via WINS?
[n]:
CLI cifs setup: WINS

CLI cifs setup: WINS

Windows Internet Name Service (WINS) is Microsofts implementation of NetBIOS Name
Server on Windows. As of Windows 2000, DNS is preferred over WINS, particularly for Active
Directory. WINS servers usually support only installs prior to Windows 2000 and mixed
Windows 2000 installs.


CLI cifs setup: Initial Questions
During cifs setup (Cont.)
A filer can be configured for multiprotocol access,
or as an NTFS-only filer. Since NFS, DAFS, VLD,
FCP, and iSCSI are not licensed on this filer, we
recommend that you configure this filer as an NTFS-
only filer
(1) NTFS-only filer
(2) Multiprotocol filer
Selection (1-2)? [1]:
This list varies depending
on other licensed protocols.
Note: Key protocol is NFS.

CLI cifs setup: INITIAL QUESTIONS

If the storage system will be in a Windows only environment, selecting the NTFS-only configures
the storage system to be most compliant with Microsoft environments.

NOTE: All existing volumes will be converted to NTFS, but qtrees are unaffected.

If the storage will participate in both Windows and non-Windows environment, the storage
system should be configured as multiprotocol.


Results of NTFS-only
NTFS-only security style changes as a result of
cifs setup.
Verify by options wafl command
Option Defaults
Before
Values
After
wafl.default_security_style unix ntfs
wafl.nt_admin_priv_map_to_root on off

RESULTS OF NTFS-ONLY

After running the cifs setup command, the options wafl command is run. The option
wafl.default_security_style is changed from UNIX to NTFS. This causes all new
volumes to default to NTFS security style.

Additionally, the nt_admin_priv_map_to_root option changes from on to off.


Switching Back to Multiprotocol
To switch back to multiprotocol:
Use cifs setup
wafl.default_security_style unix
Results of switching NTFS-only to multiprotocol:
ACLs are unchanged
Security style of volumes and qtrees remains
unchanged
New volumes have security style of UNIX

SWITCHING BACK TO MULTIPROTOCOL

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

The effects of changing an NTFS-only storage system to a multiprotocol storage system are the
following:
Existing ACLs remain unchanged.
The security style of all volumes and qtrees remains unchanged.
When you create a volume, its default security style is UNIX.
The wafl.default_security_style option is set to UNIX.


Switching Back to Multiprotocol (Cont.)
Root volume security style will remain ntfs
UNIX root user might be denied access
You can gain access:
Map of Windows user to UNIX root
Discussed in Module 3
cifs.nfs_root_ignore_acl on

SWITCHING BACK TO MULTIPROTOCOL (CONT.)

Because the security style of the root volume remains as ntfs after you change the storage system
from NTFS-only 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 the root.
You also can gain access by setting the cifs.nfs_root_ignore_acl option to on.
When this option is on, ACLs will not affect root access from the Network File System (NFS).


CLI cifs setup: Root User
During cifs setup (Cont.):
CIFS requires local /etc/passwd and /etc/group files and
default files will be created. The default passwd file
contains entries for 'root','pcuser', and 'nobody'.
Note: These files are used during CIFS authentication processing when
mapping Windows users to UNIX users even if it is NTFS-only security style.
Enter the password for the root user [ ]:
Retype the password:
[This is the root user created in the /etc/passwd file. With respect
to CIFS, this root user is used in a non-Windows workgroup only and
when authentication is performed with the /etc/passwd file.]
The password is
entered, but it is not
displayed.

CLI cifs setup: ROOT USER

With respect to CIFS, the root user is used in a non-Windows (UNIX) workgroup only and when
authentication is performed with the /etc/passwd file.


CLI cifs setup: Server Name
The default name for this CIFS server is ' system '.
would you like to change this name? [n]:

CLI cifs setup: SERVER NAME


CIFS Authentication Methods
Data ONTAP CIFS services support four styles of
user authentication.
Choose the one from the list below that best
suits your situation.
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
filer's local user accounts
4. etc/passwd and/or NIS/LDAP authentication

CIFS AUTHENTICATION METHODS

If you plan to have the storage system join a Windows domain and make use of that domain's
users and groups, you should choose option 1 or 2. Options 3 and 4 are authentication methods
that do not require the use of domain controllers, but may still require other systems for full
functionality.

Option 1: Use this option if the storage system is joining an Active Directory-based domain (i.e.
a Windows 2000 or later domain)

Option 2: Use this option if the storage system is joining a Windows NT 4-based domain or an
Active Directory-based domain as a Windows NT 4 server.

Option 3: Use this option if you want to join a Windows Workgroup and do not want to depend
on external domain controllers. You will need to define a set of local users on the storage system.

Option 4: Use this option for a non-Windows Workgroup that uses UNIX style authentication.
This style requires the use of clear text passwords from Windows clients.


CLI: cifs setup Workgroup
Selecting Windows Workgroup:
1. Active Directory domain authentication
2. Windows NT 4 domain authentication
(Windows NT or Active Directory domains
3. Windows Workgroup authentication using
the filer's local user accounts
4. /etc/passwd and/or NIS/LDAP
authentication
Selection (1-4)? [1]: 3

CLI: cifs setup WORKGROUP


CLI: cifs setup Workgroup (Cont.)
What is the name of the Workgroup? [WORKGROUP]: workgroup1
Fri Jun 23 19:32:53 GMT [wafl.quota.sec.change:notice]:
security style for /vol/vol0/ changed from unix to ntfs
CIFS - Starting SMB protocol...
It is recommended that you create the local administrator
account(DEVSLU10-F1\administrator)for this filer.
(The local administrator account can be locally authenticated via
CIFS authentication and has privileges to administer CIFS on the
storage system. The local users and passwords are stored in the
storage system registry file.)
Do you want to create the system\administrator account? [y]:
Enter the new password for system\administrator:

CLI: cifs setup WORKGROUP (CONT.)


Workgroup completion continued
Welcome to the WORKGROUP1 Windows(R) workgroup
CIFS local server is running.
system> Fri Jun 23 19:33:18 GMT
[nbt.nbns.registrationComplete:info]: NBT: All CIFS name
registrations have completed for the local server.
CLI: cifs setup Workgroup (Cont.)

CLI: cifs setup WORKGROUP (CONT.)


Results

RESULTS


CIFS Server Files
During setup, several configuration files are created.
/etc/cifsconfig_setup.cfg
Stores CIFS setup configuration
/etc/usermap.cfg
Multiprotocol support for NFS and CIFS
Discussed in the next module
/etc/passwd
Multiprotocol and UNIX workgroup
/etc/cifsconfig_share.cfg
Default share definitions
/etc/lclgroups.cfg
Local groups definitions
NOTE: Additional files are created depending on the environment

CIFS SERVER FILES

During the CLI cifs setup script or FilerView CIFS Setup Wizard, CIFS support and
configuration files are created in the /etc directory. The number and content of the files are
dependent on the environment.

The following are files that are common to all environments:
/etc/cifsconfig_setup.cfg (stores the CIFS setup configuration)
/etc/usermap.cfg (multiprotocol support for mapping users of NFS and CIFS)
/etc/passwd (multiprotocol and UNIX workgroup)
/etc/cifsconfig_shares.cfg (default shares definitions)
/etc/lclgroups.cfg (local groups definitions)

Additional files are created depending on the environment as in a workgroup (Windows/non-
Windows) or a Windows domain.


/etc/cifsconfig_setup.cfg File
/etc/cifsconfig_setup.cfg file
Contents are persistent across reboots
Runs each time the CIFS service is started
system> rdfile /etc/cifsconfig_setup.cfg
#Generated automatically by cifs commands
cifs setup -security unix -cp 0 -NTFSonly
The content of the file varies depending
on the environment that is selected.

/etc/cifsconfig_setup.cfg FILE

The following shows the contents of an /etc/cifsconfig_setup.cfg file:

system> rdfile /etc/cifsconfig_setup.cfg
cifs setup -security unix -cp 0 -NTFSonly

The content of the file varies depending on the environment that is selected. This file is used each
time CIFS service is started and persists across reboots.


/etc/passwd file
system> rdfile /etc/passwd
root:_J9../ongnoStt3Ei79o:0:1::/:
pcuser::65534:65534::/:
nobody::65535:65535::/:
ftp::65533:65533:FTP Anonymous:/home/ftp:
Is checked during CIFS authentication processing when
mapping Windows users to UNIX UID and GID
Can be used for authentication in a non-Windows (UNIX)
workgroup environment
/etc/passwd File
Unless the Windows user is mapped to a specific UNIX user name,
pc user is the default.
An encrypted root user password is shown.
Note: This root user was created during cifs setup for
the /etc/passwd file. This is not for the storage system
user root that is used for system administration.

/ETC/PASSWD FILE


CIFS Default Shares
Setup creates three default shares:
C$ maps to /vol/<root volume>
ETC$ maps to /vol /<root volume>/etc
HOME is /vol /<root volume>/home
Home directory is accessible to everyone
$ shares are hidden.
C$ and ETC$ are available only to
administrators.

CIFS DEFAULT SHARES

These are the three default share definitions:
C$ is /vol/<root volume>. This is a hidden admin share to root of the root volume.
ETC$ is /vol /<root volume>/etc. This is a hidden admin share to /etc directory on root volume.
The /etc directory stores storage system configuration files, executables required to boot the
system, and some log files.
HOME is /vol /<root volume>/home. This share is to the /home directory on root volume that is
accessible to everyone.

A hidden share means that it is not visible when browsing. An admin share is available only to
users who are members of an administrator group.

The storage system default root volume is /vol/vol0 unless the installer selected a unique volume
name during the storage system setup script. You also can change which volume on your storage
system is used as root volume or create a new one and in the process designate a different name
for the root volume. The root volume contains special directories and configuration files for
administering the storage system.


/etc/cifsconfig_share.cfg File
/etc/cifsconfig_share.cfg file
system> rdfile /etc/cifsconfig_share.cfg
cifs shares -add "ETC$" "/etc" "Remote
Administration
cifs access "ETC$" S-1-5-32-544 Full Control
cifs shares -add "HOME" "/vol/vol0/home
"Default Share
cifs access "HOME" S-NONE "nosd
(The HOME share acts special in that it maps to the user
who is trying to log in and the security descriptors on the users
home directory apply.)
cifs shares -add "C$" "/" "Remote Administration
cifs access "C$" S-1-5-32-544 Full Control
This file can be altered via CLI commands or GUIs
nosd = No Security Descriptor

/etc/cifsconfig_share.cfg FILE

The HOME share acts in a special way in that it maps to the user who is trying to login. The
security descriptors on the users home directory apply.


/etc/lclgroups.cfg File
The local administrator is added to lclgroups.cfg:
system> rdfile /etc/lclgroups.cfg
[ "Replicators" 552 ( "not supported" ) ]
[ "Backup Operators" 551 ( "Members can bypass file
security to backup files" ) ]
[ "Power Users" 547 ( "Members that can share
directories" ) ]
[ "Guests" 546 ( "Users granted Guest Access" ) ]
[ "Users" 545 ( "Ordinary Users" ) ]
[ "Administrators" 544 ( "Members can fully
administer the filer" ) ]
S-1-5-21-265246955-68147109-1151652928-500
Local Administrator

/etc/lclgroups.cfg FILE

The lclgroups.cfg file defines the members of the groups on the storage system.


SIDs

SIDS


CLI: cifs lookup
Windows security identifiers (SIDs) can be
converted to user and group IDs or the reverse
CLI: cifs lookup command
FilerView
system> cifs lookup S-1-5-32-544
name = BUILTIN\Administrators
system> cifs lookup S-1-5-21-265246955-68147109-
1151652928-500
name = system\administrator
NOTE: SID might be listed in the/etc/lclgroups.cfg file

CLI: cifs lookup

Security IDs (SIDs) can be converted to user and group IDs using the CLI or FilerView.

The following examples demonstrate using the CLI with the cifs lookup command.

system> cifs lookup S-1-5-32-544
name = BUILTIN\Administrators

The SID S-1-5-32-544 is the name BUILTIN\Administrators.

system> cifs lookup S-1-5-21-265246955-68147109-1151652928-500
name = system\administrator

This is the SID for the local administrator, system\administrator, which is listed in the
/etc/lclgroups.cfg and /etc/cifsconfig_share.cfg file.


FilerView: cifs lookup Command
FilerView -> CIFS -> Look Up Name / SID

FILERVIEW: cifs lookup COMMAND

The Windows SID can be converted to user and group names with FilerView.

On FilerView go to CIFS Look Up Name/SID.
Enter a Windows user or group name, or a SID.
Click the Look Up button.
The response to the lookup appears in the Name/SID Look Up page.

In this example, the SID S-1-5-32-544 shows the name is BUILTIN\Administrators.


SID Cache
To manage the SID Cache,
options cifs.sidcache.enable on
Turns on SID Cache
options cifs.sidcache.lifetime time
Sets the normal life span of cached SIDs
cifs sidcache clear all
Clears all CIFS SID-to-name map cache entries
cifs sidcache clear domain [domain]
Clears CIFS SID-to-name map cache entries for a
particular domain
cifs sidcache clear user [user]
particular user
cifs sidcache clear sid [sid]
particular SID

SID CACHE

CIFS is frequently required to map SIDs to user and group names and vice versa for user
authentication, quota management, console command processing, and various RPC responses.
The SID-to-name map cache contains entries that map SIDs to pre-Windows 2000 user and group
names.

The storage system obtains the SID-to-name mapping information by querying the domain
controller. To minimize multiple lookups of the same names, SID-to-name information received
from the domain controller is saved in the SID-to-name map cache on the storage system.

The SID-to-name map cache is enabled on the storage system by default. You can manually
control the cache by changing the lifetime of the entries, clearing entries, or turning SID-to-name
map caching off or on. A cache persists if CIFS is terminated or restarted, but it does not persist
across a reboot or a takeover and giveback.

When the storage system requires SID-to-name mapping information, it first looks for a matching
entry in the SID-to-name map cache. If a matching entry is not found or if an expired matching
entry is found, the storage system queries the appropriate domain controller for current mapping
information. If the domain controller is not available, an expired mapping entry might be used by
the storage system.


NetBIOS Aliases

NETBIOS ALIASES


NetBIOS
NetBIOS
Means Network Basic Input/Output System
Is an API that allows machines to be discovered by
name
Is typically used by various applications such as
Network Neighborhood and net use
Windows clients set NetBIOS name by the
Computer Name tab of the System Properties,
which can be accessed via the Control
Panel/System or by right-clicking on My Computer
and selecting Properties
On the Storage System, set NetBIOS name(s)
using nbalias and the cifs_nbalias.cfg file

NETBIOS

The Network Basic Input/Output System (NetBIOS) is an Application Program Interface (API)
that provides simple networking services enabling users to share and use one anothers resources
easily.

NetBIOS over TCP/IP (NBT or NetBT) is the standard protocol used for CIFS prior to Windows
2000. NBT is used with Windows 95, Windows98, and Windows NT. The NetBIOS Name
Server (NBNS) protocol is part of the NetBIOS over TCP/IP family of protocols


system> rdfile /etc/cifs_nbalias.cfg
#
# This file contains NetBIOS aliases used by the filer.
# See the System Administrator's Guide for a full
# description of this file.
#
# There is a limit to the number of aliases that may be specified.
# Currently that limit is 200.
#
# Aliases must be entered one per line.
#
# After editing this file, use the console command "cifs nbalias
load"
# to make the filer process the entries in this file.
#
# Note that the "#" character is valid in a CIFS NetBIOS alias.
# Therefore the "#" character is only treated as a comment in this
# file if it is in the first column.
#
myfiler
NA1
Filer
Stumpy
system>
NetBIOS Aliases

NETBIOS ALIASES

The /etc/cifs_nbalias.cfg configuration file contains the NetBIOS aliases for the
storage system. A NetBIOS alias allows the storage system to be accessed by a Windows client
using an alternate name for the storage system.

To list the current NetBIOS aliases, do the following:

system> cifs nbalias
No NetBIOS aliases

system> rdfile /etc/cifs_nbalias.cfg
# After editing this file, use the console command
# "cifs nbalias load"
# to make the filer process the entries in this file.
#
# Note that the "#" character is valid in a CIFS
# NetBIOS alias.
# Therefore the "#" character is only treated as a
# comment in this
# file if it is in the first column.
grumpy
happy [Edit and add the NetBIOS aliases.]
sneezy
system>


NetBIOS Aliases (Cont.)
cifs nbalias command
List aliases
cifs nbalias
Load file after making changes
cifs nbalias load

NETBIOS ALIASES (CONT.)

Once the /etc/cifs_nbalias.cfg file has been edited with the proper NetBIOS Aliases,
use the cifs nbalias load command to register the update with the Windows Internet
Naming Service (WINS) server.


Terminating/Restarting
CIFS

TERMINATING/RESTARTING CIFS


Stopping and Restarting CIFS
To terminate CIFS service (a complete
shutdown) where all CIFS sessions are ended:
cifs terminate [-t minutes]
To restart CIFS service after terminating:
cifs restart

STOPPING AND RESTARTING CIFS


CLI: Stopping and Restarting CIFS
As an example, stop and restart CIFS services
on the storage system called system.
system> cifs terminate
CIFS local server is shutting down...
CIFS local server has shut down...
system> cifs restart
system> Tue Aug 1 19:07:26
GMT[nbt.nbns.registrationComplete:info]: NBT:
All CIFS name registrations have completed for
the local server.

CLI: STOPPING AND RESTARTING CIFS


FilerView: Stopping CIFS Services

FILERVIEW: STOPPING CIFS SERVICES

You can disable CIFS for the entire storage system or for a specific workstation. Disabling CIFS
for the entire storage system ignores the delay time if there are no active sessions. Otherwise, it
tries to notify existing sessions prior to termination.

As an example with FilerView, stop CIFS services on the storage system by performing the
following steps:
Go to FilerView CIFS Enable/Disable.
There are no active sessions for the storage system, so the Delay Time is ignored.
Click the Disable button.

NOTE: You also can enter the name of a specific PC (Windows workstation) to disable CIFS
services.


FilerView: Restarting CIFS Services

FILERVIEW: RESTARTING CIFS SERVICES

As an example with FilerView, restart the CIFS services on the storage system by performing the
following steps:
Go to FilerView CIFS Enable/Disable.
Click the Enable CIFS button.
Enabling CIFS will allow clients to access shares on this storage system.


Module Summary

MODULE SUMMARY


Module Summary
In this module, you should have learned:
The CIFS service on a storage system can be
configured via CLI with the cifs setup command or
from FilerView
A successful configuration automatically starts the
CIFS service
Resulting files reference users using SIDs
SIDs can resolved using the cifs lookup command
NetBIOS allows machines to be discovered by name
A storage system can have multiple aliases or
NetBIOS names
The CIFS service may be stopped and started from the
CLI and FilerView

MODULE SUMMARY


Exercise
Module 2: Workgroups
Estimated Time: 45 minutes

EXERCISE


S
h
a
r
e
s
3-1 CIFS Administration on Data ONTAP 7.3: M03_Shares
MODULE 3: SHARES AND SESSIONS
Shares and
Sessions
Data ONTAP 7.3

SHARES AND SESSIONS

Module Objectives
By the end of this module, you will be able to:
Display all shares available on the storage
system
List the default shares
Configure a client machine to access any
share
Define sparse files and set their attributes
Identify the CIFS sessions established by
accessing a share on the storage system
Add, modify, and delete shares

MODULE OBJECTIVES

Share Administration
Shares may be managed via:
CLI
FilerView
Microsoft Management Console (MMC)
Computer Management
Share administration includes:
Display shares
Add shares
Provide access to shares
Remove shares

SHARE ADMINISTRATION

Displaying Shares

DISPLAYING SHARES

CLI: Displaying CIFS Shares
As a result of setting up the CIFS service,
default shares are created
To display all shares: cifs shares
Example:
system> cifs shares
Name Mount Point Description
---- ----------- -----------
ETC$ /etc Remote Administration
BUILTIN\ Administrators / Full Control
HOME /vol/vol0/home Default Share
everyone / Full Control
C$ / Remote Administration

CLI: DISPLAYING CIFS SHARES

FilerView: Displaying CIFS Shares
Display CIFS shares with FilerView

FILERVIEW: DISPLAYING CIFS SHARES

You can go to FilerViewCIFSSharesReport to display CIFS shares.
In this example, the three default shares: C$, ETC$, and HOME display with their mount points
(paths) and descriptions.

MMC: Displaying Storage System Shares
Connect to the storage system with a right-click and
selecting Connect to another computer
You are now interacting with the storage system
NOTE: You must login with a user account that is defined in the
BUILTIN\Administrations group
Users and Groups is disabled
in workgroup authentication

MMC: DISPLAYING STORAGE SYSTEM SHARES

To display storage system shares, click the Shares folder in the console tree. The three default
shares C$, ETC$, and HOME display, as does the hidden IPC$ share.
The IPC$ share is an interprocess communications mechanism for temporary connections
between clients and servers. It is primarily used to administer network servers remotely. This
share enables the communication between the Windows Computer Management GUI and the
storage system.

Accessing Shares

ACCESSING A SHARE

Accessing a Share
Once the share has been created, it may be
accessed from Windows by
The Microsofts net use command
net use e: \\toaster\jdoe /user:marketing\jdoe
Using the Run Dialog
Mapping a Drive

ACCESSING A SHARE

Run Dialog

RUN DIALOG

On a Windows workstation using the Windows run line, access the C$ share on the storage
system system by performing the following steps:
On the Windows desktop, click the Start menu and choose Run. The Run window appears.

In the Open text box, type \\storage_system_name\C$ (\\system\C$).

NOTE: The storage system name can be the name or IP address. Click the OK button and the Connect
To window appears.

In the Connect To window, type the user name administrator and the password, and click the OK
button. The \\system\C$ window appears with the share access to C$ that displays the etc and home
folders.

Mapping a Drive to a Share
\\10.254.134.35\C$...

MAPPING A DRIVE TO A SHARE

On a Windows workstation, map a network drive letter to a share by performing the following
steps:
Open Windows Explorer and to go Tools Map Network Drive. The Map Network Drive window
appears.

In the Drive list box, select any unused letter. In the example, the letter K is selected.

In the Folder list box, type \\storage_system\C$. NOTE: The storage system name can be the name or
IP address.

Click the Finish button. The Map Network Drive attempts to connect to the storage system and share.

When the Connect to window appears, in the User name text box, type administrator and in the
Password text box, type the administrators password.

Click the Ok button.

Mapping a Drive to a Share (Cont.)

MAPPING A DRIVE TO A SHARE (CONT.)

(The following continues the mapping of a network drive letter to a share.)

The mapped network drive letter (K in this example) displays the mapping to the C$ share. Both the
etc and home folders are in the C$ share.

Encoding
CIFS uses Unicode for its encoding.
If a volume is exclusively being accessed by
CIFS, consider:
vol options <vol> create_ucode on
vol options <vol> convert_ucode on
If the ucode options are not set, Data ONTAP
will transparently convert a non-Unicode
directory when first accessed by CIFS.
Time consuming
If read-only (i.e., snapshot copy), then access is
refused

ENCODING

The CIFS protocol requires a UNICODE encoding method. Unicode is an industry standard
allowing computers to consistently represent text in most of the worlds writing systems.
Unicode provides a unique number for every character regardless of the language. See
http://www.unicode.org for more information.

If a volume is exclusively being accessed by CIFS or Network File System (NFS) version 4.0 or
later, then consider setting the create_ucode and convert_ucode volume options. Create_ucode
option forces newly created directories to be unicode directories for both NFS and CIFS. By
default it is set to off, in which case all directories are created in a non-unicode format and the
first CIFS access will convert it to the Unicode format. Convert_ucode option on forces
all directories to be converted to the Unicode format when accessed from both NFS and CIFS.
By default this option is set to off.

Unicode is not defaulted on a storage system because Unicode directories take up more space and
are slower on some workloads.

Sparse Files

SPARSE FILES

Sparse Files
Now that we have access to a share, users
can create and read files from that location.
When creating files, normally Data ONTAP
allocates space for the complete size of the file
regardless if the file contains data.
Sparse files are files in which much of the data
are zeros.
Data ONTAP 7.3 and later can store sparse
files more efficiently.

SPARSE FILES

In the Windows environment, a sparse file is a file in which many of the data blocks contain
zeros. The blocks in the sparse files that contain zeros are known as sparse data sets.

Files like these are typically very large. Some examples of sparse files are files containing disk
images, a matrix within a high-speed database or log files. The problem with files containing
sparse data sets is that they use disk space inefficiently.

Support for sparse files was introduced in the NTFS filesystem as another way to make the disk
space usage more efficient. The NTFS filesystem used compression as a partial solution to the
problem. File compression compacts ranges of data blocks containing zeros. However, a
drawback of file compression is that access time may increase due to data compression and
decompression.

When the sparse file functionality is enabled, Data ONTAP only allocates hard drive space to a
file for regions that contain nonzero data. When a write operation is attempted where a large
amount of the data in the buffer is zeros; the zeros are not written to the file. Instead, the file
system creates an internal list containing the locations of the zeros in the file. This list is
consulted during all read operations. When a read operation is performed in areas of the file
where zeros were located, the file system returns the appropriate number of zeros in the buffer
allocated for the read operation. In this way, maintenance of the sparse file is transparent to all
processes that access it.

Sparse Files and Data ONTAP Features
To configure, use the fsutil tool from
Microsoft.
Setting sparse attribute:
Deletes space reservations for the file
All of the operations to set the space
reservations on the sparse files fail
The sparse bit is preserved during the qtree
SnapMirror process.
The sparse bit is preserved during the backup
(dump) and restore processes.

SPARSE FILES AND DATA ONTAP FEATURES

To set the sparse attribute, the client administrator uses the fsutil tool from Microsoft.

fsutil: sparse
Syntax
fsutil sparse [queryflag] PathName
fsutil sparse [queryrange] PathName
fsutil sparse [setflag] PathName
fsutil sparse [setrange] PathName BeginningOffset length
Example: To mark a file as sparse, type:
fsutil sparse setflag C:\Temp\sample.txt

When Windows client administrators set the sparse attribute on a file, then the space reservations
for that file are deleted. Any reserved space is returned to the available space. Any attempts to
set space reservations on a sparse file will fail. When administrators turn the sparse attribute off,
space reservations will remain off as well until intentionally set by the administrator.

Quotas with Sparse File Attribute
Data ONTAP 7.2 and lower physical file size
Data ONTAP 7.3 and higher logical file size
Without sparse file attribute set
10 Gigabytes
sparse data sets (zeros)
With sparse file attribute set
10 Megabytes
Allocated

QUOTAS WITH SPARSE FILE ATTRIBUTE

Using Data ONTAP 7.2 and lower, the number of blocks charged to the user's quota for a file is
equal to the number of blocks actually allocated. Data ONTAP 7.3 has modified quota accounting
in the WAFL file system so that the full logical size of a file is accounted for by quotas. This
simplifies quota management and matches the way quotas are implemented by Microsoft for
Windows Server 2008.

Sessions

SESSIONS

CIFS Sessions
A client establishes a session with a storage
system upon the first share access
Access is based on user authentication and
share access rules
Display a CIFS session status by using these
methods:
CLI: cifs sessions command
FilerView: FilerView -> CIFS -> Session Report
Windows Computer Management: GUI->
System Tools -> Shared Folders->Sessions

CIFS SESSIONS

cifs sessions Command
With the cifs sessions command, you can
display the following types of session
information:
A summary of session information, including the
number of open shares and files opened by user
cifs sessions
Share and file information about a specified connected
user or all connected users, including shares and files
opened
cifs sessions username | IPaddress |
host
cifs sessions * [all connected users]
Security information
cifs sessions -s

CIFS SESSIONS COMMAND

With the cifs sessions command, you can display the following types of session information:
A summary of session information, including storage system information and the number of open
shares and files opened by each connected user
cifs sessions

Share and file information about a specified connected user or all connected users, including:
The names of shares opened by a specified connected user or all connected users

The access levels of opened files
cifs sessions user_name | IP_address |workstation_name
cifs sessions * [all connected users]

With the cifs sessions command, you can display the following types of session
information:
Security information about a specified connected user or all connected users, including the UNIX user
ID (UID) and a list of UNIX groups and Windows groups to which the user belongs:
cifs sessions s user_name | IP_address |
workstation_name
cifs sessions s [all connected users]
NOTE: The number of open shares shown in the session information includes the hidden IPC$
share.
The cifs sessions command can be used as a status command even when there is no
session.

Example 1 is a storage system in a Windows workgroup. The storage system uses local user
authentication.
system> cifs sessions
Server Registers as 'system' in workgroup 'WORKGROUP1
Root volume language is not set. Use vol lang.
Using Local Users authentication
Comment: This is a Windows workgroup server
===================================================
PC IP(PC Name) (user) #shares #files

Example 2 is a storage system in a Windows 2000 domain. The storage system uses the domain
controller for authentication.
Server Registers as 'system' in Windows 2000 domain 'DEVELOPMENT
Selected domain controller \\DEVDC01 for authentication
Comment: This is a Windows 2000 member server
====================================================

OPTIONS:

The -t option displays the total count of CIFS sessions, open shares and open files.

If you include the user argument, the command displays information about the specified user, along
with the names and access level of files that user has opened. If you use * as the specified user, the
command lists all users.

Specifying the -c option with a user argument, will display the names of open directories and the
number of active ChangeNotify requests against the directory.

The -s option displays security information for a specified connected user. If you do not specify a user
or workstation name, the command displays security information for all users.

Here are examples using the machine_name and machine_IP_address arguments:
cifs sessions 192.168.228.4
users
shares/files opened
TORTOLA (nt-domain\danw - root)
HOME

cifs sessions tortola
users
shares/files opened
TORTOLA (nt-domain\danw - root)
HOME

Here is an example using the -t option:
cifs sessions -t
Using domain authentication. Domain type is Windows NT.
Number of WINS servers: 2
CIFS sessions: 1
CIFS open shares: 1
CIFS open files: 3
CIFS sessions using security signatures: 0

cifs sessions Example
The following example of the cifs sessions
command shows a session with a storage
system in a Windows domain.
Server Registers as system' in workgroup WORKGROUP'
Using Local Users authentication
====================================================
10.254.134.40() (system\administrator - root)
1 0

CIFS SESSIONS EXAMPLE

The following example of the cifs sessions command shows a session with a storage system in a
Windows workgroup.

The PC IP address 10.254.134.40 is the Windows workstation WIN.
The system\administrator user is the local administrator account on the storage system.
The user mapping for this account is root.
One share is currently being accessed.

CLI: cifs sessions Security Information
system> cifs sessions -s
users
Security Information
10.254.134.40() (system\administrator - root)
***************
UNIX uid = 0
user is a member of group daemon (1)
user is a member of group daemon (1)
NT membership
system\administrator
BUILTIN\Administrators
User is also a member of Everyone, Network Users,
Authenticated Users
***************

CLI: CIFS SESSIONS SECURITY INFORMATION

The following example of cifs sessions -s command shows security information for a
user with a session with a storage system in a Windows workgroup.

FilerView: CIFS Sessions

FILERVIEW: CIFS SESSIONS

Go to FilerViewCIFSSession Report and click the Sessions button to display session
information.

In this example, CIFS is running, and the storage system is in a Windows workgroup.

MMC: CIFS Sessions
List and terminate all the current sessions except
the session that Computer Management uses
GUI connected to the storage system

MMC: CIFS SESSIONS

With the Computer Management GUI, click the System ToolsShared FoldersSessions
folders to display the CIFS sessions.

In this example, the local administrator has a session with the storage system system that is
in a Windows workgroup.
The name of the administrators computer is 10.254.134.40 WIN.
The number of Open Files is 3.
This account is not a Guest account.

Broadcasting a Message
To display a message on Windows users sessions:
cifs broadcast {workstation | -v
volname} message
You can inform users about pending terminations or
other important events.
The Messenger service on the Windows workstation
must be enabled.
1. On your Windows workstation, go to
StartProgramsAdministrative Tools
ServicesMessenger.
2. If the Messenger service is disabled, start the service.

BROADCASTING A MESSAGE

Broadcasting a Message Example
Example of broadcasting a message from a
storage system:
system> cifs broadcast -v flexvol1 "The
shutdown will start in 10 minutes."
The following message displays on the
Windows workstation:

BROADCASTING A MESSAGE EXAMPLE

Terminating Sessions
cifs terminate [-t time] host
cifs terminate Host1
cifs terminate
Host1
Host2
Host3
Host4

TERMINATING SESSIONS

The cifs terminate command stops CIFS service. If a single host is named, all CIFS
sessions opened by that host are terminated. If a host is not specified, all the CIFS sessions are
terminated and the CIFS service is shut down.

If you run cifs terminate without specifying a time before shutdown and users have open
files, you are prompted to enter the number of minutes to delay before terminating. If CIFS
service is terminated immediately for a host that has one or more files open, the user will not be
able to save changes. You can use the -t option to warn of an impending shutdown of service. If
you execute cifs terminate from rsh, you need to supply the -t option.

Creating / Deleting
Shares

CREATING / DELETING SHARES

Default Shares
As you recall, three default share definitions
are created upon completion of cifs setup:
C$
ETC$
HOME
But you can create new shares

DEFAULT SHARES

Creating a Share
When you create a share, you must provide:
Complete path name
Name of the share
Optionally, a description of the share
Data ONTAP CLI also allows:
Group membership for files in the share
Support for wide symbolic links
Disabling/enabling of virus scanning when files
in the share are first opened
MMC also allows permissions for the share

CREATING A SHARE

When you create a share, you must provide these items:
The complete path name of an existing volume or directory to be shared
The name of the share entered by users when they connect to the share
Optionally, a description of the share

When creating a share from the Data ONTAP CLI, you can specify a variety of share properties,
including group membership for files in the share, support for wide symbolic links, and disabling
of virus scanning when files in the share are first opened. Virus scanning occurs when files are
opened, renamed, and closed after being modified.

Microsoft interfaces additionally allow the administrator to set permissions as you create the
share.

Creating a Share (Cont.)
Additional properties can be set/modified after
creating a share:
Maximum number of users who can
simultaneously access the share
If not specified, the limit is defined by the
storage systems memory
Share-level access control list (ACL)

CREATING A SHARE (CONT.)

CLI: Preparing to Create a Share
You can create shares for folders, qtrees, or
volumes
For example:
To prepare for creating a share on a qtree, first
create the following resources:
An aggregate (aggr1)
A flexible volume (flexvol1) on aggr1
A qtree (datatree1) on flexvol1
NOTE: This path example will be used throughout this module

CLI: PREPARING TO CREATE A SHARE

You can create shares for volumes or directories including qtrees.
For example, to prepare for creating a share on a qtree, first create the following resources:
An aggregate (aggr1)
A flexible volume (flexvol1) on aggr1
A qtree (datatree1) on flexvol1

CLI: CREATING AN AGGREGATE
To create on a storage system an aggregate aggr1 with RAID type raid4 and with 3 disks.
system> aggr create aggr1 -t raid4 -r 3
Fri Jun 30 08:59:18 GMT [raid.vol.disk.add.done:notice]:
Addition of Disk /aggr1/plex0/rg0/0b.27 She
lf 1 Bay 11 [NETAPP X272_HJURE073F10 NA14] S/N [41519624] to
aggregate aggr1 has completed successfully
Fri Jun 30 08:59:18 GMT [raid.vol.disk.add.done:notice]: Addition
of Disk /aggr1/plex0/rg0/0b.25 She
lf 1 Bay 9 [NETAPP X272_HJURE073F10 NA14] S/N [414Y7808] to
aggregate aggr1 has completed successfully

Fri Jun 30 08:59:18 GMT [raid.vol.disk.add.done:notice]: Addition of
Disk /aggr1/plex0/rg0/0b.22 Shelf 1 Bay 6 [NETAPP X272_HJURE073F10
NA14] S/N [415R9619] to aggregate aggr1 has completed successfully
Creation of an aggregate with 3 disks has completed.
system> Fri Jun 30 08:59:18 GMT [wafl.vol.add:notice]: Aggregate aggr1
has been added to the system.

CLI: CREATING A FLEXIBLE VOLUME
To create on a storage system a flexible volume flexvol1 on aggr1.
NOTE The qtree status command verifies the existence of the newly created flexvol1.
system> vol create flexvol1 aggr1 10g
Creation of volume 'flexvol1' with size 10g on containing aggregate
'aggr1' has completed.
system> qtree status
Volume Tree Style Oplocks Status
-------- -------- ----- -------- ---------
vol0 ntfs enabled normal
flexvol1 ntfs enabled normal
The New Technology File System (NTFS) security style for flexvol1 is based on the
wafl.default_security_style option.

CLI: CREATING A QTREE
To create on a storage system a qtree datatree1 on flexvol1.
system> qtree create /vol/flexvol1/datatree1
Volume Tree Style Oplocks Status
-------- -------- ----- -------- ---------
vol0 ntfs enabled normal
flexvol1 ntfs enabled normal
flexvol1 datatree1 ntfs enabled normal

CLI: Adding a CIFS Share
As an example, add a share called
datatree1 (for the qtree datatree1).
system> cifs shares -add datatree1
/vol/flexvol1/datatree1
-comment "Qtree for Windows Users"
The share name 'datatree1' will not be accessible by
some MS-DOS workstations
Are you sure you want to use this share name? [n]:y
Qtree for
Windows Users
/vol/flexvol1/datatree1
everyone / Full control
datatree1
Description
-----------
Mount Point
-----------
Name
----
Default access control (discussed later)

CLI: ADDING A CIFS SHARE

FilerView: Adding a CIFS Share

FILERVIEW: ADDING A CIFS SHARE

As an example with FilerView, add a new share called datatree1 (for the qtree datatree1) on
volume flexvol1 by performing the following steps:

Go to FilerView CIFS Shares Add.
For Share Name, type datatree1.
For Mount Point, type /vol/flexvol1/ datatree1.
For Share Description, type Qtree for Windows Users.
Click the Add button.

You receive a caution message that the share name datatree1 will not be accessible by some
MS-DOS workstations (because the length of the name is more than eight characters).

MMC: Adding a CIFS Share
Choose New Share...
Right-click Shares.

MMC: ADDING A CIFS SHARE

As an example with the Windows Computer Management GUI, add a new share called datatree1
(for the qtree datatree1) on volume flexvol1 by performing the following steps:|

In the console tree, right-click the Shares folder and choose New Share. The Welcome to the
Share a Folder Wizard appears.
Click the Next button to start the wizard, and the Folder Path page displays with the Computer
name text box showing your storage system name or IP address.
In the Folder path text box, type the path C:\vol\flexvol1\datatree1 for the datatree1 share, and click
the Next button.

MMC: Adding a CIFS Share (Cont.)
Click the Customize button.

MMC: ADDING A CIFS SHARE (CONT.)

(The following continues the adding of a CIFS share.)

In the Name, Description, and Settings page, in the Share name text box enter datatree1.
In the Description text box, type Qtree for Windows Users and click the Next button.
In the Permissions page, mark the Use custom share and folder permissions radio button, and then
click the Customize button.

MMC: Adding a CIFS Share (Cont.)
Click the OK button.

MMC: ADDING A CIFS SHARE (CONT.)

(The following continues the adding of a CIFS share.)

In the Customize Permissions window, mark the Allow check boxes for Full Control, Change, and
Read, and click the OK button.
In the Permissions page, click the Finish button.
You receive the message that sharing was successful.
Click the Close button to close the wizard.

CLI: Deleting a Share
As an example, delete the share called
datatree1.
system> cifs shares -delete datatree1
system> cifs shares
---- ----------- -----------
ETC$ /etc Remote Administration
HOME /vol/vol0/home Default Share
everyone / Full Control
C$ / Remote Administration
NOTE: The share datatree1 is deleted

CLI: DELETING A SHARE

FilerView: Deleting a Share
Click the operation Delete.

FILERVIEW: DELETING A SHARE

As an example with FilerView, delete the share called datatree1 by performing the following
steps:
Go to FilerView CIFS Shares Manage.
For datatree1 share, click the operation Delete.
When the confirmation dialog box asks if you really want to delete the share datatree1, click OK.
MMC: Deleting a Share
Click the Yes button to confirm stop sharing datatree1.
Right-click datatree1 share.
Choose Stop
Sharing.

MMC: DELETING A SHARE

As an example with the Windows Computer Management GUI, delete the share called datatree1
by performing the following steps:

In the Computer Management window, right-click the datatree1 share and choose Stop Sharing.
In the Shared Folders window, when it asks if you are sure that you wish to stop sharing datatree1,
click the Yes button.

Module Summary

MODULE SUMMARY

Module Summary
The available shares can be displayed via CLI,
FilerView, or Microsoft tools.
Shares are accessed from the client by the
Run menu, mapping a drive, or the Windows
command net use.
A CIFS session can be administered via CLI,
FilerView, or Microsoft tools.
Creating and deleting shares can be done
through CLI, FilerView, or Microsoft tools.

MODULE SUMMARY

Exercise
Module 3: Shares

EXERCISE


A
c
c
e
s
s

C
o
n
t
r
o
l

4-1 CIFS Administration on Data ONTAP 7.3: M04_AccessControl
MODULE 4: ACCESS CONTROL
Access Control
Data ONTAP 7.3

ACCESS CONTROL


Module Objectives
Create and manage local users for a storage system
Identify how to create a local group and make a local
user a member of that group
Use the CLI, FilerView or Microsoft tools to add,
delete, and modify access permissions of shares
Use Microsoft tools to add, delete, and modify access
permissions of files and folders
Determine and verify user mappings for CIFS users
accessing NTFS and UNIX volumes/qtrees

MODULE OBJECTIVES


Local Users


Local Users
Local users are:
Accounts that are authenticated locally
Associated with Groups on the storage system
Created and managed using useradmin
command or a text editor
Saved in the /etc/registry or
/etc/passwd

LOCAL USERS

On the storage system, the domain administrators group and the local administrator account are
part of the BUILTIN\Administrators group. They can do the following:
Provide a text editor to edit configuration files. Data ONTAP does not include an editor.
Provide the ability to administer a storage system and hence have access to the root file system (C$ and
ETC$).
Modify the share access for C$ and ETC$ to grant additional users access.
The local administrator can set up local users on the storage system with the useradmin user
add command.


Purpose of Local Users
Two main reasons for local user authentication:
1. Provides local administrators the ability to
configure the storage system
Discussed in Data ONTAP Fundamentals
Course
2. Provides local client users access to the
resources on the storage system for all
environments
Windows workgroup
Windows domain
NOTE: You can create a maximum of 96 local user accounts.

PURPOSE OF LOCAL USERS

Reasons for local user accounts include the following:
Windows workgroup
You must create local user accounts so that the storage system can authenticate local users.

Non-Windows workgroup (UNIX mode)
Do not create local user accounts because the storage system authenticates users with the
UNIX password (/etc/passwd) database.

Windows domain
The storage system can authenticate users (with the local user accounts) who try to connect to
the storage system from an untrusted domain.
Local users can access the storage system when the domain controller is down or not available
for domain authentication.

NOTE: You can create a maximum of 96 local user accounts.


Purpose of Local Users (Cont.)
When the CIFS server is configured for:
Windows workgroup
You must create local user accounts so that the
storage system can authenticate users
Use the useradmin command
User accounts are stored in /etc/registry
Non-Windows workgroup (UNIX mode)
You must create local UNIX users
Use the passwd command
User accounts are stored in /etc/passwd and
/etc/shadow

PURPOSE OF LOCAL USERS (CONT.)


Purpose of Local Users (Cont.)
When the CIFS server is configured for:
Windows domain
Storage system can authenticate users (with the
local user accounts) who try to connect to the
storage system from an untrusted domain
Local users can access the storage system
when the domain controller is down or not
available for domain authentication
Use the useradmin command
User accounts are stored in /etc/registry

PURPOSE OF LOCAL USERS (CONT.)


Local Administrator
As you recall, during cifs setup, the local
administrator account may be created.
It is highly recommended that you create the local
administrator account: (system\administrator) for
this filer. This account allows access to CIFS
from Windows when domain controllers are not
accessible.
Do you want to create the system\administrator
account? [y]:

LOCAL ADMINISTRATOR


Local User Definitions
List the local users on the storage system.
system> useradmin user list
Name: root
Info: Default system administrator.
Rid: 0
Groups:
Name: administrator
Info: Built-in account for administering the filer
Rid: 500
Groups: Administrators
A local administrator is added to the user list if the response during
cifs setup was to create a local administrator account for the
storage system. Be sure to set an appropriate password for the
administrator account.
This is the storage
system root user
account.

LOCAL USER DEFINITIONS

A local administrator is added to the user list if the response during cifs setup was to create a
local administrator account for the storage system. Be sure to set an appropriate password for the
administrator account.


Administrating Local Users
Local Users
Must provide a unique name
Associate user to a group
Created only via CLIs useradmin command
when the storage system is set to CIFS
workgroup authentication

ADMINISTRATING LOCAL USERS

With FilerView, you cannot create local user accounts.

Microsoft Management Console (MMC) tools have some capabilities that are discussed in the
next module because they only are available when the storage system is using CIFS domain
authentication.


Local User Management
Manage local users fully by using the CLI
useradmin command.
To add a new local user:
useradmin user add user_name g group_name
To modify a local user :
useradmin user modify user_name g group_name
To list user information:
useradmin user list user_name
To delete a local user:
useradmin user delete user_name

LOCAL USER MANAGEMENT


CLI: Adding a New Local User
As an example, add a local user called Jane to
the predefined Guests group.
Note: User names are not case sensitive.
system> useradmin user add jane -g Guests
New password:
Retype new password:
user <jane> added.
system> Mon Jul 31 01:13:18 GMT
[useradmin.added.deleted:info]:
The user 'jane' has been added.
Password is typed but
not displayed.

CLI: ADDING A NEW LOCAL USER

As an example, add a local user called Jane to the predefined Guests group.
NOTE: User names are not case sensitive.

system> useradmin user add jane -g Guests
New password:
Retype new password:
User <jane> added.
system> Mon Jul 31 01:13:18 GMT [useradmin.added.deleted:info]:
The user 'jane' has been added.

NOTE: The password is typed but not displayed.


CLI: Adding a New Local User (Cont.)
In the example, verify that the local user Jane
has been added to the predefined Guests group.
system> useradmin user list jane
Name: jane
Info:
Rid: 131075
Groups: Guests
Full Name:
Allowed Capabilities:
Password min/max age in days: 0/4294967295
Status: enabled

CLI: ADDING A NEW LOCAL USER (CONT.)

In the example, verify that the local user Jane has been added to the predefined Guests group.
system> useradmin user list jane
Name: jane
Info:
Rid: 131075
Groups: Guests
Full Name:
Allowed Capabilities:
Password min/max age in days: 0/4294967295
Status: enabled

NOTE: Jane has no allowed capabilities in the Guests group, but she can log in and be
authenticated.


Local Groups


Local Groups
Local Groups
Contain local and domain users
Created only via CLIs useradmin command
when the storage system is set to CIFS
workgroup authentication

LOCAL GROUPS

With FilerView, you cannot create local group accounts.

MMC tools have some capabilities that are discussed in the next module because they only are
available when the storage system is using CIFS domain authentication.


CLI: Group Management
Manage local groups by using the CLI useradmin.
To add a new group:
useradmin group add group_name r role
To modify an existing group:
useradmin group modify group_name g
new_group_name
To list group information:
useradmin group list group_name
To delete a group:
useradmin group delete group_name
To add an existing Windows domain user to a group:
useradmin domainuser add username g
group_name
To list Windows domain users in a group:
useradmin domainuser list g group_name

CLI: GROUP MANAGEMENT


CLI: Local Groups
As an example, add a local group called Helpers
with the predefined admin role and verify the
Results.
system> useradmin group add Helpers -r admin
Group <Helpers> added.
system > Mon Jul 31 02:02:43 GMT
[useradmin.added.deleted:info]: The group
'Helpers' has been added.
system > useradmin group list Helpers
Name: Helpers
Info:
Rid: 131076
Roles: admin
Allowed Capabilities: login-*,cli-*,api
*,security-*

CLI: LOCAL GROUPS

As an example, add a local group called Helpers with the predefined admin role and verify the
results.
system> useradmin group add Helpers -r admin
Group <Helpers> added.
system> Mon Jul 31 02:02:43 GMT [useradmin.added.deleted:info]:
The group 'Helpers' has been added.
system> useradmin group list Helpers
Name: Helpers
Info:
Rid: 131076
Roles: admin
Allowed Capabilities: login-*,cli-*,api-*,security-*

Note: The admin role has full capabilities.
When groups are created, they are placed in the lclgroups.cfg file. Normally, this file is for
administrative reference only; it is not used to reload groups into the system memory. However,
sometimes you need Data ONTAP to reload this filefor example, when you migrate a storage
system. Do not edit this file without direction from support.


Share Permissions

SHARE PERMISSIONS


Permissions
Permissions can be set at:
Share level
Folder/File level
Both permission levels must be satisfied to
gain access to the resource

PERMISSIONS


Share Permissions
Share permissions can be managed by:
CLI: cifs access command
FilerView
MMC such as Computer Management
Windows share permissions are the following:
Read-only
Full control
Change
If all the permissions are denied, then there is
no access.

SHARE PERMISSIONS


cifs access Command
CLI cifs access command sets or modifies the
share-level ACL to share definitions
To modify a share access:
cifs access <share> [-g] [user_rights]
To delete an ACL entry for a user on a share:
cifs access -delete <share> [-g]
[user]
The g option specifies that the user is the name of a
UNIX group. Use this command when you have:
A UNIX group and a UNIX user or an NT user or
group with the same name

CIFS ACCESS COMMAND


CLI: Setting and Deleting Share Access
As an example, on the datatree1 share, set the share
access for the administrator to Full Control and delete
the Everyone access
system> cifs access datatree1 administrator Full Control
1 share(s) have been successfully modified
system> cifs access -delete datatree1 everyone
1 share(s) have been successfully modified
system> cifs shares datatree1
---- ----------- -----------
datatree1 /vol/flexvol1/datatree1 Windows Qtree
system\administrator / Full Control
NOTE: This is the storage system local administrator

CLI: SETTING AND DELETING SHARE ACCESS


FilerView: Managing Share Access

FILERVIEW: MANAGING SHARE ACCESS

As an example with FilerView, on the datatree1 share, set the share access for the administrator to
Full Control and delete the Everyone access by performing the following steps:

Go to FilerView CIFS Shares Manage.
For datatree1 share, click operation Change Access.


FilerView: Managing Share Access (Cont.)

FILERVIEW: MANAGING SHARE ACCESS (CONT.)

(The following continues the setting and deleting of share access.)

In the Change Access for datatree1 page, click Add Access Control Entry.
In the Add access Control Entry for datatree1 page, perform these steps:
In the User/Group text box, type administrator.
In the Permissions list box, select Full Control (rwx).


FilerView: Managing Share Access (Cont.)
Click the
operation
Delete.

FILERVIEW: MANAGING SHARE ACCESS (CONT.)

In the Change Access for datatree1 page, view the newly added administrator with Full-Control share
access.
In theeveryone row, click the operation Delete to remove the share access.


MMC: Setting and Deleting Share Access
Choose Properties.
Click the Share Permissions tab.
Right-click datatree1 share.

MMC: SETTING AND DELETING SHARE ACCESS

As an example with Windows Computer Management GUI, on the datatree1 share, set the share
access for the administrator to Full Control and delete the Everyone access by performing the
following steps:

Right-click the datatree1 share and choose Properties.
In the datatree1 Properties window, the General tab appears displaying the share name, folder path,
and description for the datatree1 share. Click the Share Permissions tab.


MMC: Managing Share Access (Cont.)
Location of users or groups.
Type administrator.

MMC: MANAGING SHARE ACCESS (CONT.)

In the Share Permissions tab, click the Add button. The Select Users, Computers, or Groups window
appears.
In the Enter the object names to select text box, type administrator and click OK. The datatree1
Properties window appears, displaying the new share access for the administrator.


MMC: Managing Share Access (Cont.)
Select Everyone.
Click the Remove button.

MMC: MANAGING SHARE ACCESS (CONT.)


In the dataree1 Properties window, select Everyone and click the Remove button to delete share
access for Everyone.
The datatree1 Properties window displays that the Everyone share access is deleted.


File Permissions

FILE PERMISSIONS


Folder/File Permissions
A storage system stores the NTFS file-level
permissions for folders and files.
Managed only from a Windows client or GPOs
Standard Windows GUI tools display and set
permissions.
Manage permissions as you would an NTFS
file system on a Windows workstation or
server.

FOLDER/FILE PERMISSIONS


File Permissions of a Mapped Drive
Right-click the file, and choose Properties.
Right-click and choose Properties.

FILE PERMISSIONS OF A MAPPED DRIVE

To display the file permissions, perform the following steps:
From a mapped network drive, right-click the file.
Choose Properties from the shortcut menu.

Security Tab
The Everyone system group
has full control for permissions,
including Modify, Read & Execute,
Read, Write, and Special Permissions
Click the Security tab

SECURITY TAB
To set up security, perform the following steps:
In the file Properties window, click the Security tab.
Note the group and user names and the permissions for the group or user.

In this example, the Everyone system group has full control for permissions including Modify,
Read and Execute, Read, and Write.


ABE

ABE


Access-based Enumeration
Share permissions conventionally allow users to view
shared folders or files regardless of whether the users
have access to them
Causes security risk
Administrators can protect sensitive information using
Access-based Enumeration (ABE) option
cifs shares -change <sharename>
[-accessbasedenum | -
noaccessbasedenum]
May be set with -add switch when creating shares
No ABE is the default

ACCESS-BASED ENUMERATION

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 (ABE) 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)
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.

ABE for a CIFS share on a NetApp storage system can be managed by the CIFS shares option
[accessbasedenum | -noaccessbasedenum].


Access-based Enumeration (Cont.)
Without ABE
With ABE

ACCESS-BASED ENUMERATION (CONT.)

The two figures illustrate how ABE affects Data ONTAP directory listing. In the first figure, all
the folders under the share customer data are visible to the user, who does not have access to
some of the folders containing sensitive information. In the bottom figure, after enabling Access-
based Enumeration on this share, users can see only the folders to which they have access.


Multiprotocol
But CIFS users dont necessarily have to
access only NTFS volumes or qtrees
Volumes and qtrees can have either:
NTFS style ACL permissions
UNIX style permissions
Having UNIX style permissions does not
prevent Windows (CIFS) users from accessing
a volume or qtree if Multiprotocol is correctly
configured

MULTIPROTOCOL


Multiprotocol

MULTIPROTOCOL


Security Style Interaction
For a Windows user to
access:
A NTFS style volume or
qtree
Windows user is
tested against NTFS
style ACLs
A UNIX style volume or
qtree
Windows user must
be mapped to a UNIX
UID and GID
Windows HOST
UNIX NTFS
Windows
User and
Group ID
UNIX
User and
Group ID

SECURITY STYLE INTERACTION

NOTE: There is always a user mapping (UNIX user NTFS user) whether the chosen security
style is NTFS or multiprotocol. Even when a Windows client user is accessing data through an
NTFS qtree on a storage system with NTFS security style, a user mapping occurs for the
Windows client user. Both NTFS and UNIX users are always mapped.


Windows to UNIX User Resolution
Windows
Domain
Controller
Workgroup Authentication
Authenticated by
/etc/registry
Windows
authenticated
Unauthenticated
Storage System
Windows
authenticated
Unauthenticated
Domain
Authenticated

WINDOWS TO UNIX USER RESOLUTION

When a CIFS user attempts to access a storage system, regardless of whether the user attempts to
access a volume or qtree that has UNIX permissions, the user is authenticated with the method by
which the CIFS server has previously been configured. If the storage system has been configured
for domain authentication, the storage system passes the credentials to the domain controller for
proper authentication. The credentials are either authenticated or not. If the storage system has
been configured for workgroup authentication, then the storage will authenticate the user via the
/etc/registry.


Windows to UNIX User Resolution (Cont.)
Check mapping
/etc/usermap.cfg
Domain/user => UNIX
If no mapping,
try Windows user
If mapping exists,
try mapped user
If mapped to
Invalid user
Verify UNIX user by
/etc/passwd,
NIS, or domain
User accepted
If not
verified
Check
wafl.default_unix_user
Windows
authenticated

WINDOWS TO UNIX USER RESOLUTION (CONT.)

A Windows authenticated user then is looked up in the /etc/usermap.cfg file. Three possibilities
are available. The user maybe mapped to a UNIX user, not mapped at all, or mapped to an empty
string. If the user is mapped, then the mapped UNIX user is passed to verification. If the user is
not mapped, then the authenticated CIFS users name is tried for UNIX verification with all
letters lowercased. If the user is mapped to an empty string , then the user is invalid.
VERIFICATION
The storage system will attempt to verify a UNIX user by employing the mechanism as stated in
the /etc/nsswitch.conf file. These mechanisms are using /etc/passwd, NIS, and/or LDAP. If
verification is unsuccessful, then the option wafl.default_unix_user is tried as a generic user
account. A typical default UNIX user is pcuser with UID =65534 and GID=65534, which is
stored in /etc/passwd file by default. If verification is successful, the CIFS user is properly
associated with a UNIX account. If verification is unsuccessful, the CIFS user is invalid.
WINDOWS ADMINISTRATOR
The Windows Administrator user is a special case. The administrator is mapped to the UNIX user
name root with UID=0 and GID=1 if the wafl.nt_admin_priv_map_to_root option is
set on.

Windows to UNIX User Resolution (Cont.)
Unauthenticated
or Invalid user
Unauthenticated
or Invalid user
rejected
No
Yes
Guest user
rejected
Verify
UNIX user by
/etc/passwd,
NIS, or LDAP
Guest account configured
options
cifs.guest_account
Try
guest
user
Guest user
accepted

WINDOWS TO UNIX USER RESOLUTION (CONT.)

Unauthenticated or invalid users still may be allowed access to the resource if options
cifs.guest_account is configured. The guest account then is passed to the storage system
for UNIX verification that is specified by the /etc/nsswitch.conf file.


Verify Mappings
A Windows-to-UNIX user mapping is kept as
part of the CIFS session credential.
A fresh Windows-to-UNIX user mapping is
required only when a new CIFS session is
established for a user.
Use cifs session -s command to verify
mapping.

VERIFY MAPPINGS


Multiprotocol Options
A CIFS user can access the file without
disrupting UNIX permissions.
A CIFS user might then attempt to set security
restrictions on a file or folder.
Prior to Data ONTAP 7.2, the CIFS user must
have an add-on from the NOWsite called
SecureShare.
Data ONTAP 7.2 and later, the CIFS user can
manage security directly with
cifs.preserve_unix_security

MULTIPROTOCOL OPTIONS


Preserving UNIX Permissions
cifs.preserve_unix_security option
preserves UNIX permissions as files are
edited and saved by Windows applications
that perform the following steps:
1. Read the security properties of the file
2. Create a new temporary file
3. Apply those properties to the temporary file
4. Rename temporary file with original file name
Windows clients that perform a security query
receive a constructed ACL that exactly
represents the UNIX permissions

PRESERVING UNIX PERMISSIONS


Preserving UNIX Permissions (Cont.)
cifs.preserve_unix_security option
allows manipulation of UNIX permissions by
using the Security tab on a Windows client
When enabled, UNIX qtrees appear as NTFS
volumes
The default for this option is off
NOTE: You cannot change the owner and group from the Windows
Security tab.

PRESERVING UNIX PERMISSIONS (CONT.)


File Permissions with Mapped UNIX User
UNIX credentials are used
when evaluating access
requests by comparing
Windows credentials against
the file or folders permissions.

FILE PERMISSIONS WITH MAPPED UNIX USER

In this example, a Windows user is accessing a UNIX file. The Security tab in the file Properties
window displays the users mapped UNIX credentials.

The UNIX credentials are used when evaluating the users access requests by comparing the
users credentials against the file or folders UNIX access permissions.

Module Summary

MODULE SUMMARY


Module Summary
Create and manage local users for a storage system
Identify how to create a local group and make a local
user a member of that group
Use the CLI, FilerView or Microsoft tools to add,
delete, and modify access permissions of shares
Use Microsoft tools to add, delete, and modify access
permissions of files and folders
Determine and verify user mappings for CIFS users
accessing NTFS and UNIX volumes/qtrees

MODULE SUMMARY


Exercise
Module 4: Access Control

EXERCISE

D
o
m
a
i
n
s
5-1 CIFS Administration on Data ONTAP 7.3: M05_Domains
MODULE 5: DOMAINS
Domains
Data ONTAP 7.3

DOMAINS

Module Objectives
Terminate the CIFS service to prepare for
CIFS domain configuration
Reconfigure the CIFS service for a Windows
domain
Identify the resulting files
Create domain users and add the domain
users to a local storage system group
Set up Preferred Domain Controllers (DCs)

MODULE OBJECTIVES

Reconfiguring CIFS

RECONFIGURING CIFS

Reconfiguring CIFS
To reconfigure CIFS on a storage system:
1. Disconnect users and stop CIFS service:
cifs terminate
2. Reconfigure CIFS service:
cifs setup
CIFS server restarts with the new
configuration
Next we will investigate reconfiguring a
storage system for an Active Directory
domain

RECONFIGURING CIFS

CLI cifs setup: AD
cifs setup Windows 2000 (Active Directory)
domain completion
(1) Active Directory domain authentication
(2) Windows NT 4 domain authentication
(Windows NT or Active Directory domains)
(3) Windows Workgroup authentication using
the filer's local user accounts
(4) /etc/passwd and/or NIS/LDAP
authentication

CLI CIFS SETUP: AD

This is an example of the administrator configuring the storage system for an Active Directory
(AD) domain.

CLI cifs setup: AD (Cont.)
Windows 2000 completion continued
What is the name of the Active Directory
domain? [development.netappu.com]:
In Active Directory-based domains, it is essential
that the filer's time match the domain's internal
time so that the Kerberos-based authentication
system works correctly.
If the time difference between the filer and the
domain controllers is more than 5 minutes, CIFS
authentication will fail. Time services currently
are not configured on this filer.
Would you like to configure time services? [y]:

CLI CIFS SETUP: AD (CONT.)

Active Directory uses a time-based key mechanism. It is important for the domain controller and
the storage system to be in sync by five (5) minutes or less.

CIFS Setup will configure basic time services. To continue, you
must specify one or more time servers. Specify values as a
comma or space separated list of server names or IPv4
addresses. In Active Directory-based domains, you can also
specify the fully qualified domain name of the domain being
joined (for example:(DEVELOPMENT.NETAPPU.COM") and time
services will use those domain controllers as time servers.
Enter the time server host(s) and/or address(es)
[DEVELOPMENT.NETAPPU.COM]:10.254.134.2
[The IP address is for the domain controller or a time server.
It is best to enter the IP address of the main (root) domain
controller for the domain.]
Would you like to specify additional time servers? [n]:
Wed Jun 21 16:28:22 GMT [rc:ALERT]: timed: time daemon started


The IP address is for the domain controller or a time server. It is best to enter the IP address of
the main (root) domain controller for the domain.

The timed daemon allows the storage system to synchronize its time with external resources.

You need to configure the following:
options timed.max_skew 30m
options timed.proto ntp
options timed.sched hourly
options timed.servers [server_ip_or_name,]
For a list of available time servers, see http://www.eecis.udel.edu/~mills/ntp/servers.htm
options timed.enable on
options timed.log on

In order to create an Active Directory machine account for the
filer, you must supply the name and password of a Windows
account with sufficient privileges to add computers to the
DEVELOPMENT.NETAPPU.COM domain.
Enter the name of the Windows user
[Administrator@DEVELOPMENT.NETAPPU.COM]:
[This Windows user is the domain account administrator
that has privileges to join (add) the storage system to the
domain controller.]
Password for Administrator@DEVELOPMENT.NETAPPU.COM:
CIFS -Logged in as Administrator@DEVELOPMENT.NETAPPU.COM.
The user that you specified has permission to create the
filer's machine account in several (4) containers. Please
choose where you would like this account to be created.


This Windows user is a domain account administrator with privileges to join (add) the storage
system to the domain controller.

[The container list displays OUs (Organizational
Units) in which you have permission to create
computer accounts. The list reflects your Active
Directory domain and may contain customized OUs.]
(1) CN=computers
NOTE: CN means Common Name. The storage system is joining as a
member server.
(2) OU=Domain Controllers
(3) OU=Additional_OU
(4) OU=sub_Additional_OU,OU=Additional_OU
(5) None of the above


The container list displays Organizational Units (OUs) in which you have permission to create
computer accounts. The list reflects your Active Directory domain structure and may contain
customized OUs.

Wed Jun 21 16:29:23 GMT [wafl.quota.sec.change:notice]:
security style for /vol/vol0/ changed from unix to ntfs
CIFS - Starting SMB protocol...
It is highly recommended that you create the local
administrator account (system\administrator) for this
filer. This account allows access to CIFS from Windows
when domain controllers are not accessible.
Do you want to create the system\administrator account?
[y]:


The local administrator account has privileges to administer CIFS on the storage system even if
the domain controller is down. The local administrator can set up local users on the storage
system with the useradmin user add command.

Currently, the user system\administrator" and members
of the group DEVELOPMENT\Domain Admins" have permission
to administer CIFS on this filer. You may specify an
additional user or group to be added to the filer's
"BUILTIN\Administrators" group, thus giving them
administrative privileges as well.
Would you like to specify a user or group that can
administer CIFS? [n]:
Wed Jun 21 16:30:18 GMT
[nbt.nbns.registrationComplete:info]: NBT: All CIFS name
registrations have completed for the local server.
Welcome to the DEVELOPMENT.NETAPPU.COM (DEVELOPMENT)
Active Directory(R) domain.


FilerView Setup

FILERVIEW SETUP

CIFS Setup Wizard
This description is available
from the CLI: cifs comment

CIFS SETUP WIZARD

To start the CIFS Setup Wizard, choose CIFS Configure Setup Wizard.

The CIFS Setup Wizard helps you configure your storage system for CIFS access. You may run
the wizard at any time to change the settings. CIFS is stopped and restarted upon completion of
the wizard.

In the CIFS Setup Wizard Filer Name window, the name of the storage system appears. You
can add a description of the storage system. This description is available from the CLI by typing
cifs comment.

CIFS Setup Wizard (Cont.)
Domain user must have authority to
join the storage system to the domain.
Help (?)

CIFS SETUP WIZARD (CONT.)

In the CIFS Setup Wizard Authentication window, choose an authentication method. You can
click ? for help. The Authentication help window shows the four choices for authentication
methods:

Workgroup
UNIX Clear Text Password (Non-Windows workgroup)
NT Local User (Windows workgroup)

Domain
NT4 (Windows NT4 domain)
Windows 2000 (Windows Active Directory domain)
For workgroup authentication, enter the name of the workgroup.

For NT domain authentication, a domain administrator must have already created a machine
account for the storage system on the domain controller (Primary Domain Controller) before the
storage system joins the domain. Enter the NT4 domain name.

The domain user (administrator) added to the Windows 2000 domain must have the authority
(privileges) to join the storage system to the domain. Enter the Windows 2000 (Active Directory)
domain name, administrator name, and administrator password.

CIFS Setup Wizard (Cont.)

CIFS SETUP WIZARD (CONT.)

In the CIFS Setup Wizard Security Style window, choose the type of security style to be used as
the default on the storage system. The choices are multiprotocol or NTFS-only.

The default security style is NTFS-only if CIFS-only is licensed. If both CIFS and NFS are
licensed, the default is multiprotocol.
Note that changing the default security style does not change existing files and directories, but
only the newly created files and directories.

Results

RESULTS

Results
Additional files created in domain environment:
/etc/filersid.cfg
Contains the storage system SID
/etc/cifssec.cfg
Contains the Windows domain SID
NOTE: These files are not readable; do not edit the files

RESULTS

The /etc/filersid.cfg file is created in a domain environment and contains the storage system
security identifier (SID).

The /etc/cifssec.cfg file contains the Windows domain controller account information.

NOTE: These files are not readable; do not edit the files.

lclgroups.cfg Changes
Domain administrators are added to lclgroups.cfg:
system> rdfile /etc/lclgroups.cfg
[ "Replicators" 552 ( "not supported" ) ]
[ "Backup Operators" 551 ( "Members can bypass
file security to backup files" ) ]
[ "Power Users" 547 ( "Members that can share
directories" ) ]
[ "Guests" 546 ("Users granted Guest Access") ]
[ "Users" 545 ( "Ordinary Users" ) ]
[ "Administrators" 544 ( "Members can fully
administer the filer" ) ]
S-1-5-21-265246955-68147109-1151652928-500
S-1-5-21-3723512375-496415379-1150184651-512
Remember use cifs lookup to resolve SIDs
Local Administrator
Domain Admins Group

LCLGROUPS.CFG CHANGES

Domain Specific Commands
After configuring the storage system for a
domain environment, do the following:
Display your domain information:
cifs domaininfo
Test the storage system connection to the
Windows domain controller:
When CIFS has been successfully started and
is operational:
cifs testdc
When the CIFS subsystem is not running:
cifs testdc
[WINSsvrIPaddress]domainname
[storage_sys_name]

DOMAIN SPECIFIC COMMANDS

CLI: cifs domaininfo Command
The following example is output from the cifs
domaininfo command on a storage system in
a domain
system> cifs domaininfo
NetBios Domain: DEVELOPMENT
Windows 2000 Domain Name:development.netappu.com
Type: Windows 2000
Filer AD Site: none

CLI: CIFS DOMAININFO COMMAND

CLI: cifs domaininfo Command (Cont.)
Example output from the cifs domaininfo
command (cont.):
Current Connected DCs: \\WIN2K3
Total DC addresses found:2
Preferred Addresses: None
Favored Addresses: None
Other Addresses: 10.0.0.5 WIN2K2 PDC
10.0.0.6 PDC
Connected AD LDAP Server:\\win2k3.netapp.com
Preferred Addresses: None
Favored Addresses: None
Other Addresses: 10.0.0.
win2k3.netapp.com 10.0.0.6 win2k3-2.netapp.com

CLI: CIFS DOMAININFO COMMAND (CONT.)

CLI: cifs testdc Command
The following example is output from the cifs testdc
command on a storage system in a domain
system> cifs testdc
Using Established configuration
Current Mode of NBT is B Mode
Netbios scope ""
Registered names...
system < 0> Broadcast
system < 3> Broadcast
system <20> Broadcast
GRUMPY < 0> Broadcast
GRUMPY < 3> Broadcast
GRUMPY <20> Broadcast
HAPPY < 0> Broadcast
HAPPY < 3> Broadcast
HAPPY <20> Broadcast

CLI: CIFS TESTDC COMMAND

CLI: cifs testdc Command (Cont.)
Output from the cifs testdc command
(cont.):
SNEEZY < 0> Broadcast
SNEEZY < 3> Broadcast
SNEEZY <20> Broadcast
DEVELOPMENT < 0> Broadcast
Testing all Primary Domain Controllers
found 1 unique addresses
found PDC DEVDC01 at 10.254.134.2
Testing all Domain Controllers
found 1 unique addresses
found DC DEVDC01 at 10.254.134.2

CLI: CIFS TESTDC COMMAND (CONT.)

FilerView: CIFS Test Domain Controller

FILERVIEW: CIFS TEST DOMAIN CONTROLLER

Preferred DCs

PREFERRED DCS

Preferred DCs
Microsoft domain members use a mechanism
called site awareness to discover their
closest domain controllers within the domain
Storage system administrators can override
this default mechanism by setting preferences
for other domain controllers
options cifs.site_awareness.enable
off
cifs prefdc

PREFERRED DCS

Site awareness, also called site discovery, is the process of automatically discovering the
preferred domain controller. By default, a storage system is configured with
cifs.site_awareness.enable set to on. A storage administrator can override this
default mechanism by setting the cifs.site_awareness.enable option to off and
setting the preferred domain controllers using the cifs prefdc command.

Configuring prefdc List
The cifs prefdc command configures and displays
CIFS preferred domain controller information
To display the preferred domain controller list:
cifs prefdc print [domain]
To add a preferred domain controller list:
cifs prefdc add domain address [address]
To delete a preferred domain controller list:
cifs prefdc delete domain
system> cifs prefdc print No preferred
domain controllers configured.Domain
controllers will be automatically
discovered.

CONFIGURING PREFDC LIST
The cifs prefdc command can be used to configure or display CIFS preferred domain
controller information.

To display the preferred domain controller list:
cifs prefdc print [domain]

To add a preferred domain controller list:
cifs prefdc add domain address [address]

To delete a preferred domain controller list:
cifs prefdc delete domain

In the following example, there are no preferred domain controllers configured and domain
controllers will be automatically discovered.

system> cifs prefdc print
No preferred Domain Controllers configured.
DCs will be automatically discovered.

Favored
Other
Best!
Worst!
Preferred
Specified
by the Admin
Determined
by DC Ping
Ordering
DC Ping Ordering

DC PING ORDERING

Most Windows server environments have multiple domain controllers. A NetApp storage
system contacts domain controller in the following order:

Preferred: Any domain controller(s) configured as preferred with the cifs prefdc command.
Favored: Any domain controller(s), which is determined by site awareness rules to be readily
accessible.
Other: Any other domain controller(s) that is reachable.

NOTE: A DC ping occurs every time the CIFS server starts, every time cifs prefdc is
executed, and every four hours.

Domain Users

DOMAIN USERS

Domain User
Domain user is:
Created in a domain
Authenticated by the domain
Created with the Active Directory Users and
Computers tool

DOMAIN USER

A domain user is a nonlocal user that belongs to a Windows domain and is authenticated by the
domain. This type of user can also be placed into storage system groups that grant it capabilities
on the storage system.

On the Windows workstation, you can create a domain user with the Active Directory Users and
Computers tool. The Windows Active Directory Users and Computers tool allows you to manage
users, groups, organizational units, and all other Active Directory objects. You can administer
and publish information in the directory.

The following example demonstrates how to add a domain user named Jane Doe.

To create a domain user with the Active Directory Users and Computers Tool, perform the
following steps:
1. To open the tool from your Windows workstation, go to
StartProgramsAdministrative ToolsActive Directory Users and Computers.

Creating a Domain User
Right-click the
Users folder.

CREATING A DOMAIN USER

2. To add a new domain user, right-click the Users folder and choose New User.

Creating a Domain User (Cont.)

CREATING A DOMAIN USER (CONT.)

3. In the New Object User window, type the name of the user in the First name, Last
name, and Full name text boxes.
4. In this example, user_jdoe (for Jane Doe) is typed in the First name text box and repeated
in the Full name text box.
5. In the User logon name text box, type the user logon of user_jdoe to add the domain user
Jane Doe. Click the Next button.
6. In the password window, type the password for Jane Doe and confirm the password.
7. Mark the Password never expires check box for this example.
8. Click the Next button.
9. Click the Finish button to complete adding user_jdoe to the domain.
Creating a Domain User (Cont.)

CREATING A DOMAIN USER (CONT.)

Local User Authentication
When the storage system is using CIFS Domain
authentication:
Local user authentication is still possible
Additional MMC functionality is available
Users:
Displays a current list of local users only
Cannot create, delete, or view properties of local users
Cannot administer passwords
Groups:
Can display, create, and delete a group, and add or delete
users in the group
Cannot add or modify roles (and hence, capabilities) for the
group

LOCAL USER AUTHENTICATION

Adding Domain Users to Groups
Assign a Windows domain user to a custom or
predefined local group
CLI: useradmin domainuser subcommand
Computer Management (MMC)
useradmin domainuser add win_user_name -g
{custom_group|Administrators|"Backup
Operators"|Guests|"Power Users"|Users}

ADDING DOMAIN USERS TO GROUPS

MMC: Groups
Right-click
Groups folder.
Choose New Group.
Type the Group Name.
Click the Add button
to add members.

MMC: GROUPS
As an example, from the Windows Computer Management GUI, in the Groups folder, add a new
group Helpers2 and add local user Jane to the group by performing the following steps:

1. Go to System ToolsLocal Users and GroupsGroups.
2. Right-click the Groups folder and choose New Group.
3. In the New Group window, in the Group name text box, type the group name Helpers2.
4. Click the Add button to add members to the new group.

MMC: Groups (Cont.)
Type the local user Jane, and remember to
use the storage_sys_name\user_name format.
Click the Create button, and
then click the Close button.

MMC: GROUPS (CONT.)

5. In the Select Users window, use the format of storage_sys_name\user_name and type the
local user DEVSLU10-F1\jane.
6. Click the OK button. The New Group window is displayed, showing the local user Jane
as a member.
7. In the New Group window, click the Create button and then click the Close button.

MMC: Groups (Cont.)
Note that the new group
Helpers2 has been added.

MMC: GROUPS (CONT.)

(The following continues the adding of a new local group.)

8. Note that in the Computer Management GUI, the new group Helpers2 has been added.

Module Summary

MODULE SUMMARY

Module Summary
Create and manage local users for a storage
system
Identify how to create a local group and make a
local user a member of that group
Use the CLI, FilerView, or Microsoft tools to
add, delete, and modify access permissions of
shares
Use Microsoft tools to add, delete, and modify
access permissions of files and folders
Determine and verify user mappings for CIFS
users accessing NTFS and UNIX volumes/qtrees

MODULE SUMMARY

Exercise
Module 5: Domains

EXERCISE


A
d
v
a
n
c
e
d

A
d
m
i
n
i
s
t
r
a
t
i
o
n
6-1 CIFS Administration on Data ONTAP 7.3: M06_AdvancedAdmin
MODULE 6: ADVANCED ADMINISTRATION
Advanced
Administration
Data ONTAP 7.3

ADVANCED ADMINISTRATION

Module Objectives
Configure event auditing
Set up Auto Home Shares for your user-base
Configure Group Policy Objects (GPOs)
Manage CIFS opportunistic locks (oplocks)
Set up virus scanning
Increase security by configuring caching, SMB
signing, and the minimum security level

MODULE OBJECTIVES

Event Auditing

EVENT AUDITING

Auditing CIFS Events
Enable auditing of:
Logon and logoff events
File access events
NTFS volumes/qtrees
MIXED volumes/qtrees
UNIX volumes/qtrees
cifs.audit.nfs.enable on
Audit records are recorded in an internal
format and then are saved off into an external
format for viewing

AUDITING CIFS EVENTS

You can enable auditing for the following categories of events:
Logon and logoff events
File access events

These are the prerequisites for auditing file access events:
The file or directory can be audited in a mixed or NTFS volume, or qtree.
If the cifs.audit.nfs.enable option is on, you can audit events for files in UNIX security-
style qtrees.
You must activate auditing for individual files and directories according to your Windows
documentation.

For more information about configuring NFS auditing, please see technical report #3595 at
http://www.netapp.com/library/tr/3595.pdf.

Configuring Auditing
To set up CIFS auditing:
1. Determine what you are going to audit
2. Configure any System ACLs (SACLs) needed
3. Set options for CIFS auditing and turn it on
4. Save off audit record into .evt file
5. Use Microsoft Event Viewer to access the audit
record
When you configure Data ONTAP for CIFS
auditing, the event log file and settings for all
options persist across a reboot or if CIFS is
terminated or restarted.

CONFIGURING AUDITING

Determining What to Audit
To enable auditing for file access events:
options
cifs.audit.file_access_events.enable
on
To enable auditing for logon and logoff
events:
options
cifs.audit.logon_events.enable on

DETERMINING WHAT TO AUDIT

To enable auditing specifically for file access events:
options cifs.audit.file_access_events.enable on

The auditing of file access events is turned on by default and requires that the
cifs.audit.enable option is on.
To enable auditing specifically for logon and logoff events:
options cifs.audit.logon_events.enable on

The auditing of logon and logoff events is turned on by default and requires that the
cifs.audit.enable option is on.

NOTE: Auditing settings applies to the entire storage system, not just an individual share or
volume.

Setting an SACL for Event Logging
If you desire file access events auditing, you
must set a SACL on a file and specify the
groups/users/events to monitor.
To set a SACL
For a volume or qtree:
Use Storage-Level Access Guard security
For individual files and directories:
Use the Windows Properties/Security tab to set
the ACL
Security tab >Advanced > Auditing
Use Storage-Level Access Guard security

SETTING AN ACL FOR EVENT LOGGING

System access control lists (SACLs) can be used to enable auditing access on files and
directories.

There are three ways to set SACLs for auditing access:
If you want to audit access events on all files and directories within a volume or qtree, it is recommended
that you set SACLs by applying Storage-Level Access Guard security. For more information about
Storage-Level Access Guard, see the Data ONTAP 7.3 Fundamentals, course.
If you want to audit access events on individual files and directories, you can set SACLs in two ways:
Using your Windows Explorer GUI
Using Storage-Level Access Guard security

NOTE: Make sure that you select only the events you need to audit, as because selecting too
many audit options might impact system performance.

Auditing Configuration
Set the location of the saved log file
options cifs.audit.saveas <path>
Set the log file size
options cifs.audit.logsize <value>
To enable CIFS auditing on the storage
system:
options cifs.audit.enable on
The default is CIFS auditing disabled (off)

AUDITING CONFIGURATION

Saving the Audit Record
The audit record is recorded in an internal format.
/etc/log/auditlog.alf
Can wrap, resulting in event loss, if not written to external
file
The audit record can be saved to an external file
2 ways:
Manually
cifs audit save [-f]
Automatically, on the occurrence of
File size threshold
cifs.audit.autosave.onsize.enable
cifs.audit.autosave.onsize.threshold
Time interval
cifs.audit.autosave.ontime.enable
cifs.audit.autosave.ontime.threshold
File size threshold and time interval

SAVING THE AUDIT RECORD

Options for Autosaving
The saved files are automatically named.
Each time the internal log file is saved, an extension is
added to the base name of the
.evt file.
Counter
options cifs.audit.autosave.file.extension
counter
Example: If the base file name is evtlog, when an
automatic save occurs, the newest evtlog.evt is renamed
to evtlog1.evt, the former evtlog1.evt is then renamed to
evtlog2.evt, and so on.
Timestamp
options cifs.audit.autosave.file.extension
timestamp
basename.YYYYMMDDHHMMSS.evt

OPTIONS FOR AUTOSAVING

Options for Autosaving (Cont.)
This option limits the number of files
automatically saved.
The administrator can specify how many files
can be saved by the autosave feature; when
saved, event files are much larger than the
internal .alf files.
To specify the maximum number of .evt files
that can be automatically stored (1 to 999):
options cifs.audit.autosave.limit value
options cifs.audit.autosave.limit 20

OPTIONS FOR AUTOSAVING (CONT.)

View the External Audit File
From a Windows client, you can view audit
events with Microsoft Event Viewer with the
following displays:
Real-time display using Live View (Windows
2000 or later)
options cifs.audit.liveview.enable
Static display of the event log file

VIEW THE EXTERNAL AUDIT FILE
To view the external audit file:
To enable or disable Live View on your storage system, set options cifs.audit.liveview.enable on | off.

From a Windows client, start the Event Viewer from Administrative Tools or from MMC.

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

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

Auto Home Shares

AUTO HOME SHARES

Auto Home Shares
Auto Home Shares
Match users by name and provide a home
directory share automatically
Save administrators from manually creating home
shares for their users
When user logs in, users name is matched to a
home directory path and share becomes available
Each user can connect to the users home directory
only, not to the home directories of other users.
Exception: BUILTIN\Administrators group can
access others shares by setting options
cifs.homedirs_public_for_admin on

AUTO HOME SHARES

You can create user home directories on the storage system and configure Data ONTAP to
automatically offer each user a home directory share. Each user can connect to the users home
directory only, not to the home directories of other users.

The cifs share command does not display the home directories.

To specify the naming style used for matching home directories to users:
options cifs.home_dir_namestyle {ntname | hidden | domain | mapped | }

To specify whether members of the storage system BUILTIN\Administrators group can connect
to the CIFS home directories of other users:
options cifs.homedirs_public_for_admin on

When you create a users folder for the users home directory, Data ONTAP automatically
searches the paths in the cifs_homedir.cfg file for the user name that matches the logon name, and
dynamically creates the share for that user.

Creating Auto Home Shares
To set up an auto home share:
1. Configure the parent location of the users
home directories
2. Specify the naming style of the home
directories
3. Create individual directories in a home
directory path
4. Access the auto home share
NOTE: The cifs share command does not
display the home directories.

CREATING AUTO HOME SHARES

Creating Home Directories
Create a parent directory or qtree for the users
home directories
Example: /vol/vol1/mktghome
Specify the parent home directory paths by
editing the /etc/cifs_homedir.cfg file
Changes to this file are processed automatically
whenever CIFS starts.
You can also process changes immediately to
this file by using the cifs homedir load
command.
The cifs homedir command displays the
current list of home directory paths.

CREATING HOME DIRECTORIES

The /etc/cifs_homedir.cfg configuration file contains the configured home directory paths for
users that access the storage system using the CIFS network protocol. For changes to take effect
after editing the file, you must run the cifs homedir load command.

DEVSLU10-F1> rdfile /etc/cifs_homedir.cfg

# This file contains the path(s) used by the filer to

# determine if a CIFS user has a home directory. See

# the System Administrator's Guide

# for a full description of this file and a full

# description of the CIFS homedir feature.

# There is a limit to the number of paths that may be

# specified.

# Currently that limit is 1000.

# Paths must be entered one per line.

After editing this file, use the console command "cifs homedir
load" to make the storage system process the entries in this
file.

# Note that the "#" character is valid in a CIFS

# directory name. Therefore the "#" character is only

# treated as a comment in this file if it is in the

# first column.

# Two example path entries are given below.

# /vol/vol0/users1

# /vol/vol1/users2

# Actual path entries follow this line

/vol/userVol/users

Specify Naming Style
Naming Style
Determines how Data ONTAP will attempt to
match the user to the directory
To specify the naming style used for matching
home directories to users:
options cifs.home_dir_namestyle {ntname
| hidden | domain | mapped | }
ntname or = \\toaster\jdoe
hidden = \\toaster\jdoe$
domain = \\toaster\~marketing~jdoe
mapped = \\toaster\~jdoe

SPECIFY NAMING STYLE

The cifs homedir command displays the current list of home directory paths. The
options cifs.home_dir_namestyle command enables you to specify the naming style
used for matching home directories to users.

Use ntname if the home directories have the same names as the Windows user names.

Use hidden if you want to use a Windows user name with a dollar sign ($) appended to it to initiate a
search for a home directory with the same name as the Windows user name.

Use domain if you want to use the domain name in addition to the Windows user name to search for
the home directory.

Use mapped if the home directories have the UNIX user names as specified in the usermap.cfg file.

Use if you do not want to specify a namestyle and want Data ONTAP to match home directories to
users the same way it did before Data ONTAP 6.0.

NOTE: By default, the cifs.home_dir_namestyle option is .

Create Users Directories
If the namestyle is set to ntname, hidden,
mapped or , create users directories under
the home directory path
Example: /vol/vol1/mktghome/jdoe
If the namestyle is set to domain, create a
domain directory under the home directory
path before the user directory
Example: /vol/vol1/mktghome/marketing/jdoe

CREATE USERS DIRECTORIES

Access the Home Directory
Log in as the user
Access the home share by
Run dialog box from the Start menu
Map a drive to the share
NOTE: A user may have logins in two domains
If jdoe is logged in as engineering/jdoe, jdoe sees only
the engineering home directory
To access the marketing domains home share, use
net use * \\toaster\jdoe /user:marketing\jdoe

ACCESS THE HOME DIRECTORY

Group Policy Objects

GROUP POLICY OBJECTS

Group Policy Objects
Group Policy Objects (GPOs) are a set of rules
that apply to computers in an Active Directory
environment.
While not all GPOs are applicable to your
storage system, the storage system recognizes
and processes relevant GPOs.
When CIFS and GPOs are enabled on your
storage system, Data ONTAP sends LDAP
queries to the Active Directory server and
requests GPO information.
If the GPO definitions are applicable to the
storage system, the Active Directory server
returns the GPO information.

GROUP POLICY OBJECTS

Relevant GPOs
The following GPOs are currently supported on
your storage system:
Startup and shutdown scripts
Group Policy refresh interval for computers
File System security policy
Restricted Groups security policy
Event Log
Auditing

RELEVANT GPOS

Example of Using GPOs
GPO File System security settings can be
applied directly to Data ONTAP file system
objects (directories or files).
The settings are propagated down the
directory hierarchy.
The File System security settings can be
applied to mixed or NTFS volumes or qtrees
only.
Cannot be applied UNIX security style
The File System security ACL propagation is
limited to about 280 levels of directory
hierarchy.

EXAMPLE OF USING GPOS

Configuring GPOs
To use GPOs on your storage system:
CIFS is licensed and enabled on the storage system.
CIFS is configured using cifs setup, and the
storage system joins a Windows 2000 (or later)
domain environment.
GPOs are configured on a Windows Active Directory
server by associating a GPO to an Organizational
Unit (OU), and then placing the storage system
within that OU.
GPO support is enabled on the storage system with
options cifs.gpo.enable on.
When support is enabled the first time, the /etc/ad
directory is created as an information repository.

CONFIGURING GPOS

CLI GPO Commands
cifs gpresult
Displays GPOs currently in effect for the storage
system and the results of those GPOs
cifs gpupdate
Updates GPOs on the storage system
immediately with the most current Group Policy
settings available in the Active Directory domain

CLI GPO COMMANDS

GPO: Mapping User Home Folders
A login GPO in Active Directory can be
configured to automatically map the users
auto home share.
The basic steps are:
1. Create an OU
2. Create the GPO within the OU
3. Create a script and associate it with the GPO
4. Test the configuration

GPO: MAPPING USER HOME FOLDERS

The corresponding labs provide detailed instructions on how to create a GPO to automatically
map the users auto home share to a network drive. The next several slides are only intended for
high-level discussion.

GPO: Mapping User Home Folders (Cont.)
Create an OU
This is the new OU.
This user has been
added to the OU.

GPO: MAPPING USER HOME FOLDERS (CONT.)

Create the GPO within the OU
Right-click
Select


Right-click User_Logon_GPO and select the Properties tab, then select the Create and Link a
GPO Here option.
In this example, the Login_Homespace_Mapping GPO has already been created. To edit an
existing GPO, right-click the GPO and select Edit to open the Group Policy Object Editor.

Create a script and associate it with the GPO
Right-click


Create the script:
net use m: \\<storagesystem>\%username%
NOTE: This assumes ntname or namestyle
Place the script in the GPO logon scripts
default location.
C:\Windows\SYSVOL\<domain>\policies\<SID>\
user\scripts\logon
Test the configuration.
Log in as a user and there should be an auto
home share mapped to the m drive.


Oplocks

OPLOCKS

CIFS Oplocks
CIFS opportunistic locks (oplocks) enable the
redirector on a CIFS client in certain file-
sharing scenarios to perform client-side
caching of read-ahead, write-behind, and lock
information.
A client can then work with a file (read or write
it) without regularly reminding the server that it
needs access to the file in question.
This improves performance by reducing network
traffic.
CIFS oplocks on the storage system are on by
default.

CIFS OPLOCKS

CIFS Oplocks (Cont.)
To set the CIFS protocol oplock setting:
options cifs.oplocks.enable
[on|off]
Setting the cifs.oplocks.enable option:
OFF
Disables oplocks on the storage system
regardless of the volumes or qtrees setting
ON
Enables oplocks on the storage system if enabled
on the volume or qtree

CIFS OPLOCKS (CONT.)

CIFS Oplocks (Cont.)
You might turn oplocks off for one of the
following reasons:
You are using a database application with
documentation that recommends oplocks be
turned off.
The CIFS clients are on an unreliable network.
You are handling critical data, and you cannot
afford even the slightest data loss.
Otherwise, leave CIFS oplocks on.
To change CIFS oplocks use:
qtree oplocks [path] {enable|disable}

CIFS OPLOCKS (CONT.)

Virus Scanning

VIRUS SCANNING

CIFS Virus Protection
CIFS virus protection:
Provides on-access virus scanning of files on a
storage system
Requires a virus-scanning Windows server
running compliant antivirus applications
May require a file to be scanned before a CIFS
client can open it

CIFS VIRUS PROTECTION

CIFS virus protection is a Data ONTAP feature that enables a virus-scanning Windows server
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.

CIFS Virus Scanning
The following steps describe how virus scanning
works:
1. The scanner (Windows server) registers with the
storage system, so no storage system configuration
is required.
2. At the storage system prompt, type the vscan on
command to enable scanning.
3. The scanner waits for requests to come from the
storage system.
Several scanners can register with the storage system.
This is recommended for performance and reliability.
A single scanner can scan multiple storage systems.
4. The scanner pings the storage system from time to
time to detect and recover from reboots and
takeovers.

CIFS VIRUS SCANNING

Virus-Scanning Process
1. Client requests a file
2. Storage system requests scanner to scan file
3. Scanner returns a go or no-go reply
If file is go, the storage system allows access.
If file is no-go, storage system denies access.
Ethernet
Client
Scanner Storage System

VIRUS-SCANNING PROCESS

vscan Commands
Manage scanning clients vscan scanners
Reset cache of already-scanned files vscan reset
Set timeout value, mandatory scan, and
Client MsgBox
vscan options
Enable virus scanning vscan on
Disable virus scanning vscan off
Specify files to check or ignore for
viruses
vscan extensions
List of virus-scanning commands vscan help

VSCAN COMMANDS

Client MsgBox
There are three styles of MsgBox:
Attempt to scan modified file failed.
Your machine is probably the source of the
virus.
Attempt to scan file failed.
Your Windows workstation is probably innocent,
but it has attempted to open an infected file.
Could not scan file and storage system is
configured to deny access.
vscan mandatory_scan is set, and no
scanners are available to scan files.

CLIENT MSGBOX

Secondary Scanners
Actual virus scanning is done by an attached antivirus
scanner, running on a Windows server.
All scanners are primary scanners unless explicitly
made a secondary.
The secondary scanners main purpose is to act as a
hot standby in case the primary goes down.
Storage system will not use the secondary scanner
unless there are no primary scanners available.
To turn on secondary scanners:
system> vscan scanners secondary_scanners
IP1[,IP2]
system> vscan scanners secondary_scanners
10.1.2.3,10.2.3.4

SECONDARY SCANNERS

Setting Up Virus Scanning
Turn on vscan
vscan on
Set vscan extension
vscan extensions include
vscan extensions exclude
Set vscan options
vscan options timeout [seconds]
vscan mandatory_scan [on | off]
vscan client_msgbox [on | off]
Set up secondary scanners
vscan scanners secondary_scanners
[IP,]

SETTING UP VIRUS SCANNING

NOTE: Primary scanners attach to the storage system automatically and will appear in the list
of available scanners by using the vscan scanners command. Administrators may designate
primary scanners as secondary or designate a secondary back to a primary scanner.

vscan Options for CIFS Shares
cifs shares -add <sharename>
<path>
[novscan]
[novscanread]
Example: cifs shares add engineering
/vol/vol0 novscan
cifs shares change <sharename>
<path>
[novscanread|vscanread]
[vscan|novscan]
Example: cifs shares change
engineering /vol/vol0 -novscanread

VSCAN OPTIONS FOR CIFS SHARES

File Scanning
File Policies (FPolicy)
Allows administrators to create file policies that
specify file operation permissions according to
file type
Example: Restrict .jpg and .mpg files from being
stored on a storage system
FPolicy is enabled two ways:
Using third-party file screening software
Can be located at www.netapp.com/partners
Using native file blocking

FILE SCANNING

You use file screening 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. A file screening policy determines how
the storage system handles requests from individual client systems for operations such as open,
rename, create, and delete.

Triggering Operations
create
open
write
rename
delete
close
create_dir
getattr
link
lookup
read
rename_dir
setattr
symlink
Operations that can trigger a file policy:

TRIGGERING OPERATIONS

Third-Party File-Screening Process
1. Client requests a file.
2. Storage system consults the screen server.
3. Screen server responds as follows:
If file is OK, storage system allows access.
If a file is denied, storage system denies
access.
Possible operations controlled by file screening
are creation of a new file, opening an existing file,
and renaming a file.
Ethernet
Client
File Screen Server
Storage System

THIRD-PARTY FILE-SCREENING PROCESS

Configuring FPolicy
To enable FPolicy:
Turn the feature on
options fpolicy.enable on
Create a file policy
fpolicy create <PolicyName> screen
Screen is the only supported policy type
Add/remove extensions and options to the file
policy
Set up a file policy monitor
Enable the file policy
fpolicy enable <PolicyName>

CONFIGURING FPOLICY

Blocking MP3s Example
To block MP3s on a storage system:
fpolicy create mp3blocker screen
Creates the FPolicy
fpolicy ext inc set mp3blocker mp3
Adds the extension mp3 to the FPolicy
fpolicy options mp3blocker required on
Requires FPolicy to be implemented
fpolicy monitor set mp3blocker -p cifs,nfs
create,rename
Assigns FPolicy to create and rename operation over CIFS
and NFS traffic
fpolicy enable mp3blocker -f
Turns it on

BLOCKING MP3S EXAMPLE

This is intended as a high-level discussion. The corresponding labs have detailed instructions
on how to implement this example.

Security

SECURITY

Security
Security is always a concern.
NetApp provides several mechanisms to
increase security within the CIFS protocol:
Disable share caching
Enable SMB signing
Set minimum security level

SECURITY

Share Caching
Administrators can configure caching by using a share
property:
Enable manual caching (default)
cifs shares -change sharename
-manual_caching
Enable automatic caching of documents
-auto_document_caching
Enable automatic caching of programs
-auto_program_caching
To increase security:
Disable caching
cifs shares -change sharename -nocaching

SHARE CACHING

Client-side caching enables Windows clients to cache files on a share so that the files are
available for offline use. Client-side caching can be specified from the storage system or from a
Windows 2000, XP, 2003, Vista, or 2008 client. A shared folder caching policy can be set to the
following options:

OPTION DESCRIPTION
no_caching Disallow Windows clients from caching any files on this share.
manual_caching
Allow users on Windows clients to manually select files to be
cached.
auto_document_caching
Allow Windows clients to cache user documents on this share.
The actual caching behavior depends upon the Windows client.
auto_program_caching
Allow Windows clients to cache programs on this share. The
actual caching behavior depends upon the Windows client.

Manual caching is enabled by default for new shares.
SMB Signing
SMB Signing helps to ensure secure network
traffic between clients and storage system.
If enabled, the storage system will sign if client
requires it.
Client SMB policies are set through Security
Settings using MMC.
The two SMB policies are:
Microsoft Network client: Digitally sign
communications (if server agrees)
Microsoft Network client: Digitally sign
communications (always)

SMB SIGNING

Data ONTAP supports Server Message Block (SMB) signing when requested by the client. SMB
signing helps to ensure that network traffic between the storage system and the client has not been
compromised by preventing replay attacks (also known as 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 all 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.

A client SMB signing policy is set through Security Settings using a Microsoft Management
Console (MMC). The two SMB signing policies are:

Microsoft Network client: Digitally sign communications (if server agrees). This setting controls
whether or not the clients SMB signing capability is enabled. It is enabled by default. When this
setting is disabled on the client, the client communicates normally with the storage system without
SMB signing, regardless of the SMB signing setting on the storage system.

If SMB signing is enabled on the storage system, all communications between client and storage
system use SMB signing.

If SMB signing is not enabled on the storage system, communications proceed normally without SMB
signing.

Microsoft Network client: Digitally sign communications (always). This setting controls whether the client
requires SMB signing to communicate with a server. It is disabled by default. When this setting is disabled
on the client, SMB signing behavior is based on the policy setting for Digitally sign communications (if
server agrees) and the setting on the storage system.

If SMB signing is enabled on the storage system, all communications between client and storage
system use SMB signing.
If SMB signing is not enabled on the storage system, the client rejects communication with it.

NOTE: If your environment includes Windows clients configured to require SMB signing, you
must enable SMB signing on the storage system. If you do not, the storage system cannot serve
data to these systems.

SMB Signing Configuration
Configuring SMB Signing
options cifs.signing.enable
[on|off]
Off by default
NOTE: Enabling SMB signing will significantly impact
performance.
Most Windows clients will negotiate SMB
signing by default if enabled on the server.

SMB SIGNING CONFIGURATION

Minimum Security Level
Administrators can require a certain level to be
negotiated between client and a storage system.
options cifs.LMCompatibilityLevel
This option takes values from 1-5:
1. LM, NTLM, NTLMv2 session security, NTLMv2, Kerberos
(Default)
2. NTLM, NTLMv2 session security, NTLMv2, Kerberos
3. NTLMv2 session security, NTLMv2, Kerberos
4. NTLMv2, Kerberos
5. Kerberos only
Clients not willing to communicate at the required
level are denied.

MINIMUM SECURITY LEVEL

Windows servers can set policies to define the minimum level of security that they support when
clients connect. Data ONTAP administrators can configure the storage system to deny requests
from clients that are attempting to use a security level lower than the defined minimum.
Data ONTAP 7.3 provides an option that sets the minimum security level similar to the way
Microsofts registry variable provides this setting:

1 - Accepts LM, NTLM, NTLMv2 session security, NTLMv2, Kerberos.
2 - Accepts NTLM, NTLMv2 session security, NTLMv2, Kerberos.
3 - Accepts NTLMv2 session security, NTLMv2, Kerberos.
4 - Accepts NTLMv2, Kerberos.
5 - Accepts Kerberos only.

When Data ONTAP is processing an NTLM authentication token or a Kerberos ticket from a
client, the value of this option will determine if the client request will be allowed or denied.
When option cifs.LMCompatibilityLevel is enabled, the following EMS message will be
displayed when Data ONTAP rejects an authentication request:
Login rejected This type of LM/NTLM response is not accepted with current value of\
cifs.LMCompatibilityLevel.

Module Summary

MODULE SUMMARY

Module Summary
Logon/Logoff and file access events may be audited
on a storage system
Auto home shares allows administrators to set up user
home directories without creating individual shares
Group Policy Objects allows highly configurable
policies with an Active Directory domain
Oplocks provide a write-behind, read-ahead
mechanism that is usually suitable for most
environments
Virus scanning allows management of undesirable
filesIncrease security by disabling caching, turn on
SMB signing and set a minimum level of security

MODULE SUMMARY

Exercise
Module 6: Advanced Administration
Estimate Time: 90 minutes

EXERCISE


P
e
r
f
o
r
m
a
n
c
e

7-1 CIFS Administration on Data ONTAP 7.3: M07_Performance
MODULE 7: PERFORMANCE
Performance
Data ONTAP 7.3

PERFORMANCE


Module Objectives
Describe the importance of performance
management
Capture performance statistics with Data
ONTAP commands and other tools
Identify factors that affect CIFS performance
Identify steps to analyze performance and to
resolve performance problems

MODULE OBJECTIVES


Factors

FACTORS


Performance Management
What is performance management?
Three broad functional categories: monitoring,
controlling, and capacity planning
Monitoring tracks activities on the network
Controlling enables performance management
to make adjustments to improve network
performance
Capacity planning ensures a healthy network
that can grow to meet future needs

PERFORMANCE MANAGEMENT

As storage networks become more complex, the role of the system administrator becomes more
challenging. Performance management enables the administrator to proactively identify problem
areas before they occur. Performance data can be used to baseline, plan, and determine how
critical resources of the system will be utilized. The system resources include memory, central
processing unit, disk, network bandwidth, and so on.

Performance management includes the monitoring and controlling of system resources so that the
system and network can perform at peak efficiency.

With performance monitoring, you keep track of system and network traffic based on
predetermined settings (baseline). You can monitor events, analyze them, and set thresholds.

Storage capacity planning tools assist administrators in planning ahead for migration of data or
acquisition of new storage hardware.


Steps in Resolving Performance Problems
1. Identify perceived performance problem
2. Gather data to prove or disprove the
existence of the problem
3. If the problem exists, identify and implement
configurations that might resolve the issue
4. Test to validate performance with new
configurations
5. Repeat as necessary

STEPS IN RESOLVING PERFORMANCE PROBLEMS

Before analyzing performance data, collect the data based on predefined metrics. Depending on
the baseline of your data, set thresholds. Thresholds are limits beyond which error or warning
messages are reported to the system administrator.

Performance monitoring involves knowing what is expected based on the requirements. It
includes identifying the desired metric, checking what is actually in place by collecting current
network-device and link-utilization data, analyzing the relevant data, and finally, based on the
differential, conducting the necessary workload analysis in accordance with capacity planning
documentation created earlier.


Factors Affecting CIFS Performance
CPU
Memory
Network
Network interface
System bus
Non-volatile random
access memory
(NVRAM)
I/O devices
Disk controllers
Disks
Network Bandwidth, Latency, and Reliability
Multiple CPUs
System Bus
Memory
NICs Disk
Drives
Disk Controllers NVRAM

FACTORS AFFECTING CIFS PERFORMANCE

The following factors affect the performance of your Network File System (NFS) environment:

SYSTEM CPU
The CPU speed directly affects the rate at which the system can process NFS requests and
responses.

MEMORY
Since memory can be used to cache file attributes and file data, slow performance may often be
attributed to the amount of memory; however, you need to check memory requirements for your
configuration before adding memory to your system.

SYSTEM BUS
Since all traffic among the CPU, interface cards, memory, and disk goes through the system bus,
no amount of memory increase or disk increase will compensate for slow system bus
performance. Systems are usually configured to match the system bus.

NETWORK
Current IP network technology has several speed alternatives. Common choices are 100 Mb
(megabit), 1000 Mbit/1 Gb, and 10 Gb. Before deploying a gigabit network, you will need to
upgrade to a high-speed network interface card (NIC) and a gigabit-capable switching
infrastructure. Gigabit deployment continues to become cheaper and easier as the required
components become commodities. Gigabit Ethernet typically provides the physical transport and
datalink layer. The Gigabit Ethernet driver can play an important role in network performance;

therefore, the latest version of the Ethernet driver is always recommended for highest
performance.

The first step in configuring Gigabit Ethernet for any type of deployment is to isolate the NFS
data network for a specific workload from the general purpose network. This reduces network
congestion and provides better data security. Isolating the network can be accomplished by
various means, including physical network isolation or virtual LAN-based isolation. The
following table compares the theoretical bandwidth limits of various connection technologies.
The table also lists average latency (in milliseconds) to transfer 64 kB (kilobytes) of data.

Connection Technology
Theoretical
Bandwidth
Latency for 64 kB
Transfer
10 Mbit Ethernet 1.25 MB/sec 50 ms
100 Mbit Ethernet 12.5 MB/sec 5 ms
1 Gb Ethernet 125 MB/sec 0.5 ms (500s)
1 Gb Fibre Channel 125 MB/sec 0.5 ms (500s)
SCSI-3 160 MB/sec 0.4 ms (400s)
10 Gb Ethernet 1.25 GB/sec 0.048 ms (48s)

High-speed storage infrastructures can also be deployed with such technologies as 1Gb Fibre
Channel or SCSI-3. An NFS infrastructure that delivers similar performance requires the
bandwidth associated with Gigabit Ethernet. Gigabit Ethernet technology is available for all
UNIX systems. Enterprise applications that require high performance should always be deployed
with gigabit technology. Gigabit components are available from the platform vendor. In addition,
this technology is provided by a number of third-party vendors.

NetApp storage systems currently support 100 Mb, 1 Gb, and 10Gb Ethernet infrastructures.


Data Collection

DATA COLLECTION


Data Collection
Data ONTAP commands
sysstat
netstat
ifstat
stats
statit
netdiag
cifs stat
cifs top
pktt
External tools
perfstat
sio
Covered in Data ONTAP
Fundamentals course

DATA COLLECTION

The following Data ONTAP tools can be used to collect performance data:

The sysstat, netstat, ifstat, stats, statit, netdiag, cifs stat, and
cifs top commands are bundled with Data ONTAP for collecting and/or performance data.
The packet trace (pktt) utility is also used to gather network traffic information for further analysis
by NetApp support personnel.

The external tools are available for download at the NOW (NetApp on the Web) site.


cifs stat Command Overview
cifs stat has two main forms
If interval is specified, command continues displaying a
summary of CIFS activity until interrupted
Information is for the preceding interval (in seconds), with
header line repeated periodically
The interval must be >= 1
If interval is not specified, command displays counts and
percentages of all CIFS operations as well as a number
of internal statistics that may be of use when diagnosing
performance and other problems
Statistics displayed are cumulative for all clients by
default.
If the cifs.per_client_stats.enable option is on,
a subset of clients may be selected using the -u option,
the -h option, or both

CIFS STAT COMMAND OVERVIEW

The cifs stat command has two main forms. If you specify the interval, the command
continues to display a summary of CIFS activity until interrupted. The information is for the
preceding interval seconds. (The header line is periodically repeated.) The interval must be >= 1.
If you do not specify the interval, the command displays counts and percentages of all CIFS
operations as well as a number of internal statistics that may be of use when diagnosing
performance and other problems.
By default, the statistics displayed are cumulative for all clients. However, if the
cifs.per_client_stats.enable option is on, a subset of the clients may be selected
using the -u option, the -h option, or both.


cifs stat Options
-u <user>
If per-client stats are being gathered, selects a user
account to match for stats reporting
-h <host>
If per-client stats are being gathered, specifies a host to
match for stats reporting
-v [v]
If per-client stats are being reported using the -u or -h
options, the -v option shows the count of the number of
matching clients prior to the stats themselves
-c
Displays counts and percentages for non_blocking CIFS
operations as well as block_ing, which is the default
-z
Zeroes all CIFS operation counters, including per-client
counters, if any

CIFS STAT OPTIONS

-u <user> If per-client stats are being gathered, this selects a user account to match for stats
reporting. More than one -u <user> option may be supplied. If more than one client matches
the user, the values reported are the sum of all matching clients.

The user specified may have a domain, which restricts matching to that domain, or the domain
may be "*" or left blank to match any domain. The user account may be specified, or may be "*"
to match any user.

-h <host> If per-client stats are being gathered, this specifies a host to match for stats
reporting. More than one -h <host> option may be supplied. If more than one client matches
the host, the values reported are the sum of all matching clients.
The host may be an IP address in dot notation, or it may be any hostname found using the
Domain Name System (DNS), if a DNS is enabled on the storage system.

-v [v] If per-client stats are being reported using the -u or -h options, it may be desirable to
know which clients contributed to the total stats being reported. If -v is given, the count of the
number of matching clients is printed prior to the stats themselves. If -vv is given, the actual
matching clients are also printed prior to printing the stats themselves.

-c Displays counts and percentages for non_blocking CIFS operations as well as block_ing,
which is the default. This option is not available in combination with the per-client options.



-z Zeroes all CIFS operation counters, including per-client counters, if any.

EXAMPLE
system> cifs stat 10
GetAttr Read Write Lock Open/Cl Direct Other
175 142 3 70 115 642 50
0 0 0 0 18 0 0
0 3 8 0 0 10 0
0 0 0 6 0 0 1
0 0 0 0 0 0 0

NOTES
If vFiler volumes are licensed, the per-user statistics are only available when in a vFiler
context. That means when using the -u <user> or -h <host> options with the cifs stat
command, it must be invoked using vfiler run, even for the hosting storage system. For
example,
system> vfiler run vfiler0 cifs stat -h 10.10.20.23 -u *\tom 1


cifs top Command Overview
Displays CIFS client activity based on different
criteria
Can display clients that are generating large
amounts of load, as well as identify clients that
are behaving suspiciously
Default outputa sorted list of clients, number
of I/Os, "suspicious" events, number and size of
READ and WRITE requests, IP address, and
client user account.
Statistics normalized to values per second
Syntax: cifs top [-s <sort>] [-n
<maxclients>] [-a <avg>] [-v]

CIFS TOP COMMAND OVERVIEW

The cifs top command is used to display CIFS client activity based on a number of different
criteria. It can display which clients are generating large amounts of load, as well as help identify
clients that may be behaving suspiciously.

The default output is a sorted list of clients, one per line, showing the number of I/Os, number of
and sizes of READ and WRITE requests, the number of "suspicious" events, and the IP address
and user account of the client. The statistics are normalized to values per second. A single client
may have more than one entry if it is multiplexing multiple users on a single connection, as is
frequently the case when a Windows Terminal Server connects to the storage system.

This command relies on data collected when the cifs.per_client_stats.enable option
is "on," so it must be used in conjunction with that option. Administrators should be aware that
there is overhead associated with collecting the per-client stats. This overhead may noticeably
affect the storage system performance.

OPTIONS
-s <sort> Specifies how the client stats are to be sorted. Possible values of <sort> are
ops, reads, writes, ios, and suspicious. These values may be abbreviated to the
first character, and the default is ops. They are interpreted as follows:
ops Sort by number of operations per second of any type.
reads Sort by kilobytes per second of data sent in response to read requests.


writes Sort by kilobytes per second of data written to the storage system.
ios Sort by the combined total of reads plus writes for each client.
suspicious Sort by the number of "suspicious" events sent per second by each client.
"Suspicious" events are any of the following, which are typical of the patterns seen when viruses
or other badly behaved software or users are attacking a system:
ACCESS_DENIED returned for FindFirst
ACCESS_DENIED returned for Open/CreateFile
ACCESS_DENIED returned for DeleteFile
SUCCESS returned for DeleteFile
SUCCESS returned for TruncateFile
-n <maxclients> Specifies the maximum number of top clients to display, default is 20.
-a <avg> Specifies how the statistics are to be averaged for display. Possible values of <avg>
are smooth, now, and total. These values may be abbreviated to the first character, and the
default is smooth. They are interpreted as follows:
smooth Use a smoothed average which is weighted towards recent behavior but takes into
account previous history of the client.
now Use a one-second sample taken immediately. No history is taken into account.
total Use the total count of each statistic divided by the total time since sampling started. If
the -v option is also used, the totals are given without dividing by the sample time.
-v Specifies that detailed statistics are to be given, similar to those for the cifs stat
command. These stats include the sample time and the counters used to calculate the usage. As
mentioned above, in the case of total averaging, a dump of the raw stats is produced in a form
suitable for input to scripts.
EXAMPLE

If vFiler volumes are licensed, the per-user statistics are only available when in a vFiler context.
This means the cifs top command must be invoked in a vFiler context (for example, using
vfiler run), even for the hosting storage system. For example,
system> vfiler run vfiler0 cifs top

cifs top -n 3 -s w
ops/s reads(n, KB/s) writes(n, KB/s) suspect/s IP Name
263 | 29 215 | 137 627 | 0 | 10.56.10.120 ENGR\varun
248 | 27 190 | 126 619 | 1 | 10.56.10.120 ENGR\jill
246 | 26 195 | 125 616 | 19 | 10.56.12.118 MKTG\bob

pktt Overview
Overview
Data ONTAP utility for packet capture
Captures data for further analysis by support personnel
Syntax
pktt start <if>|all [-d dir] [-m pklen] [-b bsize]
[-i ipaddr i .]
Starts packet tracing
pktt dump [<if>|all [-d dir]] | [<if> [-f file]]
Writes data from memory to file (disk)
pktt stop <if>|all
Stops packet tracing
Optional commands
pktt pause <if>|all
pktt status [<if>|all] [-v]
pktt delete [filename.trc]+
pktt list

PKTT OVERVIEW

The start subcommand is used to start tracing (or to restart if it has been paused). The packet
trace data is stored in tcpdump format in a circular buffer in memory. The displaying of flags is
optional, and can be done as follows:
-d dir
Allows you to specify the path to an existing directory in which the trace data file will be written.
The file will always have the name *.trc where * is the interface name (e.g., e4, fa3, etc.).
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. Note that when writing trace data to
disk, if the file system cannot keep up with the network traffic, you may not log all packets. This
will show up in the dropped counts when looking at the status. Also remember that logging all
traffic may generate a heavy write load on the storage system, which may 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 a lot of traffic. You should set -b to 128 KB or
larger.
-s size
Allows you to set the maximum size of the trace file. If this is not specified, the file can grow to
32 GB, so you are advised to 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 the disk.
-v
This causes the pktt status -v information to be displayed as tracing starts.

-m pklen
Sets the length at which packets will be truncated. The default is 1,500 bytes, which results in full
packets for Ethernet. Note that in 5.3, the default of 1,500 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 cases where the packet size can be larger than 1,500, you may want to
specify a larger maximum. However, many of the decoders refuse to deal with packets larger than
1,500 bytes so you should only specify a larger value if that seems critical to finding a problem.
-b bsize
Sets the buffer size, which may be specified as a number with an optional trailing k or m
multiplier. The default is 32 KB, which should be large enough to find packet of death bugs
and similar problems. You should use a value of at least 128 KB when using the -d option. The
value may range from 8 KB to 128 MB, but only in the most exceptional cases would it be
necessary to increase the size beyond 12 MB. In cases where the network is very busy and it is
not practical to log all the traffic to disk, you may need to use a larger buffer.
Important Note: Do not specify a value larger than 3 MB.
-i ipaddr [-i ipaddr]
This allows limited filtering capability. Up to four IP addresses 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, Address Resolution Protocol [ARP]/Reverse Address Resolution Protocol
[RARP]) traffic.
EXAMPLES OF PKTT
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 100 MB with a 128 KB 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, and storing the traces in
the file /home/el10.trc. Up to 10 KB of each packet will be stored in a 1 MB 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 are 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 .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. This can be used to display the buffer and
file status of an existing trace.
NOTE 1: Each of the above subcommands must be followed by an interface name or the word
all.
NOTE 2: The recommended naming convention to be used when storing packet trace files is
illustrated by the following example:
e9_20060607_131233.trc
lo_20060607_131233.trc

In the first example above:
Name Fragment Description
e9 port number
2006 year
06 month
07 date
13 hour
12 minute
33 seconds


External Tools

EXTERNAL TOOLS


Capturing CIFS Packets
pktt trace saved in tcpdump format
Reference www.tcpdump.org
Use a tcpdump-compliant program to review the
packet trace
Such as Ethereal - see www.ethereal.com
Alternatively, convert pktt trace to Netmon-
compliant format using
Capconv utility see
http://now.netapp.com/NOW/download/tools/capconv/
Netmon-compliant packet analyzers such as Windows
Netmon

CAPTURING CIFS PACKETS

In addition to the pktt utility, the above tools enable you to capture CIFS packets, format them,
and send them out for analysis and troubleshooting.


perfstat Overview
Data collection tool with several key properties:
Captures all needed performance information with one
command
Captures information from host(s) and storage system(s)
Captures all information simultaneously for cross-
correlation
Operates on all host platforms and storage system
platforms
perfstat comes in exactly two flavors:
Unix/Linux version (perfstat.sh)
Windows version (perfstat.exe)
Supported platforms:
Unix: AIX, HP-UX, Linux, OSF1, Solaris, FreeBSD
Windows: 2000/XP/2003 /2008

PERFSTAT OVERVIEW

The perfstat tool is the following version:
A command line .exe version for Windows platforms

The tool is used for isolating performance bottlenecks. It is the preferred method for collecting
performance statistics on NetApp storage systems. Using a single command, the system
administrator is able to gather all data needed to isolate performance problems on both the storage
system and host data.

Since it is constantly being updated, the latest version of the perfstat script, you should obtain
the latest version from the NOW site, on the Tools and Utilities page at
http://now.netapp.com/NOW/download/tools/perfstat

Before using perfstat, you must have:
root access to the system
rsh access to the system from the host running perfstat
rsh access to any host systems to be monitored


PARTIAL OUTPUT
*------------- Perfstat v6.35 -------------*
APP_NAME, default, "
BEGIN, default, "FALSE
CONF_ONLY, default, "FALSE
DEBUG, default, "FALSE
END, default, "FALSE
FILER_TARGETS, set, "na20
DO_HOST, default, "TRUE
HOST_TARGETS, default, "
ITERATIONS, set, "12
ITER_INTERVAL, default, "0
FILER_LOGIN, default, "root
SSH, default, "FALSE
RAMRUN, default, "FALSE
APP_PARAM, default, "
PERF_ONLY, default, "FALSE
QUIET, default, "FALSE
ROOT_CMD, default, "
TIME, set, "10
PRETEND, default, "FALSE
LOGS, default, "FALSE
PROFILES, default, "FALSE
EXCLUDE, default, "FALSE
STUTTER_STATIT, default, "TRUE


perfstat Options
Options
-f system_name Name of system under test
-c Configuration data recorded only
-h Comma-separated list of hostnames
-t time Time to collect histogram data
-a appname o options Optional application to test
-p Capture performance data only
-l login[:password] User name and password to use
-F Storage system only; dont capture host data
-v Print version info only
-r rootcommand Run a root command on the host
-q Quiet mode; no console output
-x Print commands
-b Begin capture
-e End capture
Syntax: perfstat options > output_file

PERFSTAT OPTIONS

The format of the basic perfstat command is as follows:
perfstat [-b|e|c] [-f filername] [-h hostname]
What follows is a list of some of the perfstat options. For the complete list, refer to the NOW
site on the Tools and Utilities page.

Option Definition
-b Begins sampling and returns prompt immediately
-e Ends samplingused in conjunction with -b
-c Captures configuration info only, no performance data
-f filername Name of storage system (server)
-h hostname Name of host system (client)
-t time Sample time per iteration (in minutes), with a default of 2

NOTE: -t option is only needed with the -b option.

perfstat Example
perfstat -f filer1 -h host1 -t 5 -i 12 > perfstat.$date.out
Where -f is the storage system (server), -h the host (client), -t sample period, -i number of
iterations. Please do not use the perfstat -b and perfstat -e option. Typically NetApp
Support will request the perfstat; and sample time and iteration will be provided.

sio Utility
Overview
Acronym for simulated I/O
General-purpose load generator
Allows for different block size read and write ops
Performs synchronous I/Os to the specified
file(s)
Collects basic statistics
Syntax
sio Read% Rand% Blk_Size File_Size
Seconds Thread Filename [Filename]

SIO UTILITY

Simulated I/O (sio) is a general purpose I/O load generator. It performs synchronous I/Os to the
specified file(s). The main purpose is to generate various I/O loads while collecting some basic
statistics. In general, sio allows the user to control:
Read/write mix
Random or sequential I/O patterns
Access in various block sizes
Access over a variable amount of file space (starting at offset 0)
Adjustable run time (in seconds)
Single or multiple concurrent threads performing I/O
Access to one or more files or devices (for example, raw devices)
After completing the specified workload, sio generates several basic statistics:
I/Os completed per second
kBps transferred
Total I/Os completed over the measured interval

The sio command is meant to enable I/O performance testing without having to create large
application structures (such as databases). For example, sio can approximate a workload
similar to that of TPC-C by specifying (for instance) a 2-to-1 read/write ratio, of 4 kB transfer
sizes, with the appropriate number of threads. While the emulation is not exact, the
approximation provides valuable insight into I/O subsystem performance.


BUILD REQUIREMENTS
AIX, Linuxgcc
HP-UX, Solariscc
WindowsVisual C++

Installation
Download sio_ntap.tar.gz and unpack it using gzip and tar, then use the appropriate
binary for the desired client system. View the README if you wish to build a binary from the
provided source. The parameters used with sio are as follows:
Parameter Definition
Read % Percentage of accesses that are reads (versus writes)
Rand % Percentage of accesses that are random (versus sequential)
Blk_Size Size of I/O requests that are issued
FileSize
Size of area to be accessed in the file(s) (can be <= actual file size; same
for all files)
Seconds
Run time (specified in seconds), minimum of 10 seconds (60 or more
recommended)
Threads Number of concurrent threads issuing I/Os
Filename(s)
Device to access. May be file (foo.out) or device (/dev/dsk/etc).
Multiple devices can be specified. I/O is distributed evenly and randomly
across the devices.
INPUT EXAMPLES
100% random reads of 512-byte transfers to filename1, running for 60 seconds with one
thread, accessing 1 MB of the file:
sio 100 100 512 1m 60 1 filename1

Half-reads, half-writes of random 4 KB I/Os, filename1, 10 seconds, two threads, 20 MB of
file accessed:
sio 50 100 4k 20m 10 2 filename1

Sequential writes of 64 KB I/Os for 60 seconds against filename1 with one thread, 10 MB of
file accessed:
sio 0 0 64k 10m 60 1 filename1

100% random reads of 512-byte transfers to filename1, filename2, filename3,
running for 60 seconds with 32 threads, accessing 1 GB of each of the files:
sio 100 100 512 1g 60 1 filename1 filename2 filename3


Resources

RESOURCES


CIFS References
Education
Fundamentals of Performance Analysis
Data ONTAP Manual page reference under
http://now.netapp.com/NOW/main/tatools.shtml
NetApp library at
http://www.netapp.com/library/
Tech Talk online events at
http://www.netapp.com/news/techtalk/

CIFS REFERENCES


Module Summary

MODULE SUMMARY


Module Summary
Describe the importance of performance
management
Capture performance statistics with Data
ONTAP commands and other tools
Identify factors that affect CIFS performance
Identify steps to analyze performance and to
resolve performance problems

MODULE SUMMARY


Exercise
Module 7: Performance

EXERCISE


T
r
o
u
b
l
e
s
h
o
o
t
i
n
g
8-1 CIFS Administration for Data ONTAP 7.3: M08_Troubleshooting
MODULE 8: TROUBLESHOOTING
Troubleshooting
Data ONTAP 7.3

TROUBLESHOOTING

Module Objectives
Describe NT LAN Manager (NTLM) authentication
process and communication
Describe Kerberos authentication process and
communication
Follow a methodology for resolving communication
errors when a client attempts to access data on a
storage system
Identify troubleshooting tools
Describe typical cifs setup problem and solution
scenarios
Describe cifs setup best practices
Locate documentation for problem resolution

MODULE OBJECTIVES

NTLM

NTLM

NTLM Communication
Windows generally authenticates users using
NT LAN Manager (NTLM), or
Kerberos
NTLM is a challenge-response authentication protocol.
Three-way handshake
Then set to DC for approval
Client Storage System Domain Controller
1. Negotiate
2. Challenge
3. Response
4. Request
5. Accepted/Denied

NTLM COMMUNICATION

In this module, we will discuss the NT LAN Manager (NTLM) and Kerberos authentication
protocols. NTLM provides a basic mechanism for authenticating a client to a server based on a
three-way handshake used primarily to provide compatibility with versions of Windows earlier
than Windows 2000.
1. The attempt to start a NTLM communication begins by negotiating with the storage system.
This is a request to begin the authentication handshake. At this point the receiver of the
negotiate message doesn't know who the request is coming from,only that a response needs to
be generated to complete the handshake.
2. The response is a challenge by the storage system. The challenge is a NONCEessentially a
64-bit number generated by the server and guaranteed only to be used once. The client will
use this to identify itself without sending its clear text credentials.
3. The client now needs to send a response to the challenge. To form this response, the
password is used as a cryptographic key to encrypt the NONCE. This is sent back to the
storage system.
4. The NTLM challenge from step 2 and the response from step 3, along with the username, is
then sent to domain controller for authentication.
5. If the domain controller calculates the same NTLM Challenge Response as sent by the
storage based upon the domain controllers copy of the clients hashed password, then a
successful response will be sent to back to storage system. Otherwise, the challenge response
is denied.
Kerberos

KEBEROS

Kerberos Security Protocol
In Windows 2000 (or later) Active Directory
domains, everyone (if at all possible) should
use Kerberos-based authentication because it
is more secure.
Kerberos V5 is an Internet standard security
protocol for handling authentication of a user or
system identity.
The following slides describe in detail how
Kerberos-based authentication works to create
secure communications.

KERBEROS SECURITY PROTOCOL

In Windows 2000 (or later) Active Directory domains, everyone (if at all possible) should use
Kerberos-based authentication because it is more secure. Kerberos V5 is an Internet standard
security protocol for handling authentication of a user or system identity.

The following slides describe in detail how Kerberos-based authentication works to create secure
communications.

How Kerberos Works
Sharing a Secret: How Kerberos Works
1. Authentication exchange
The client asks the authentication server for a ticket to the ticket-granting server (TGS). The
authentication server looks up the client in its database, then generates a session key
(SK1) for use between the client and the TGS. Kerberos encrypts the SK1 using the clients
secret key. The authentication server also uses the TGSs secret key (known only to the
authentication server and the TGS) to create and send the user a ticket-granting ticket.
(TGT).
Client
Kerberos
authentication
server
Auth Requests ticket to TGS
TGT
SK1 Creates session key1,
ticket-granting ticket
Server
authenticates
client

HOW KERBEROS WORKS

1. Authentication exchange
The client asks the authentication server for a ticket to the ticket-granting server (TGS).
The authentication server looks up the client in its database, authenticates the client, and then
generates a session key (SK1) for use between the client and the TGS.
Kerberos encrypts the SK1 using the clients secret key.
The authentication server also uses the TGSs secret key (known only to the authentication server
and the TGS) to create and send the user a ticket-granting ticket (TGT).
NOTE: In the slide, Auth is the authenticator, SK1 is the session key, and TGT is the ticket.

2. Ticket-granting service exchange
The client decrypts the message and recovers the session key, then uses it to create an
authenticator containing the users name, IP address and a time stamp. The client sends
this authenticator (Auth), along with the TGT, to the TGS, requesting access to the target
server. The TGS decrypts the TGT, then uses the SK1 inside the TGT to decrypt the
authenticator. It verifies information in the authenticator, the ticket, the clients network
address, and the time stamp. If everything matches, it lets the request proceed. Then the
TGS creates a new session key (SK2) for the client and target server to use, encrypts it
using SK1 and send it to the client. The TGS also sends a new ticket containing the clients
name, network address, a time stamp, and an expiration time for the ticketall encrypted
with the target servers secret keyand the name of the server.
TGT
How Kerberos Works (Cont.) How Kerberos Works
Client
Ticket-
granting
server
Auth
Requests ticket to target server:
Target server name, TGT and
authenticator
TK-TS
SK2 Creates session key2,
issues session ticket
for target server Server
authenticates
client

HOW KERBEROS WORKS (CONT.)

2. Ticket-granting service exchange
The client decrypts the message and recovers the session key and then uses it to create an
authenticator containing the users name, IP address, and a time stamp.

The client sends this authenticator (Auth), along with the TGT, to the TGS and requests access to
the target server.

The TGS decrypts the TGT and then uses the SK1 inside the TGT to decrypt the authenticator.
It verifies information in the authenticator, the ticket, the clients network address, and the time
stamp.

If everything matches, it lets the request proceed and the server authenticates the client.
Then the TGS creates a new session key (SK2) for the client and target server to use, encrypts it
using SK1, and sends it to the client.

The TGS also sends a new ticket containing the clients name, network address, a time stamp, and
an expiration time for the ticketall encrypted with the target servers secret keyand the name
of the server.

3. Client and target server exchange
The client decrypts the message and gets the SK2. Finally ready to approach the target
server, the client creates a new authenticator encrypted with SK2. The client sends the
session ticket (already encrypted with the target servers secret key) and the encrypted
authenticator. Because the authenticator contains plaintext encrypted with SK2, it proves
that the client knows the key. The encrypted time stamp prevents an eavesdropper from
recording both the ticket and authenticator and replaying them later. The target server
decrypts and checks the ticket, authenticator, client address, and time stamp. For
applications that require two-way authentication, the target server returns a message
consisting of the time stamp plus 1, encrypted with SK2. This proves to the client that the
server actually knew its own secret key and thus could decrypt the ticket and the
authenticator.
How Kerberos Works (Cont.)
Client
Target
server
Requests access; sends
session ticket from TGS
Returns message with
the time stamp plus 1,
encrypted with SK2,
thereby authenticating
the target server to the
client
Server
authenticates
client
Auth
SK2
TK-TS
Auth


3. Client and target server exchange
The client decrypts the message and gets the SK2.

Finally ready to approach the target server, the client creates a new authenticator encrypted with
SK2.

The client requests access to the target server and sends the session ticket (already encrypted with
the target servers secret key) and the encrypted authenticator.

Because the authenticator contains plain text encrypted with SK2, it proves that the client knows
the key.

The encrypted time stamp (TS) prevents an eavesdropper from recording both the ticket and
authenticator and replaying them later.

The target server decrypts and checks the ticket, authenticator, client address, and time stamp.
The target server authenticates the client.

For applications that require two-way authentication, the target server returns a message
consisting of the time stamp plus 1, encrypted with SK2.

This proves to the client that the server actually knows its own secret key and thus could decrypt
the ticket and the authenticator.
How Kerberos Works (Cont.)
4. Secure communications
The target server knows that the client is who he claims to be, and the two now share an
encryption key for secure communications. Because only the client and target server share
this key, they can assume that a recent message encrypted in that key originated with the
other party.
KEY: Authenticator Session Key Ticket
Client
Target
server
SK2
SK2
TGT Auth SK1


4. Secure communications

The target server knows that the client is who the client claims to be, and the two now share an
encryption key for secure communications.

Because only the client and target server share this key, they can assume that a recent message
encrypted in that key originated with the other party.

Authentication
Scenario

AUTHENTICATION SCENARIO

Authentication Scenario
5. Storage system maps
NT (user) account to a
UNIX user name.
1. In a domain environment, a
Windows client user requests
user session authentication with
a storage system.
2. The storage system goes
to the domain controller to
authenticate the user.
3. The domain controller
(DC) authenticates user or
indicates user not exist.
4. If the DC indicates guest access, the
storage system cannot allow guest access
unless cifs.guest_account is set.
6. The storage system
compares NT account
info with the share ACL.
7. The storage system compares
the NT account info with the file
ACL or the mapped UNIX account
with UNIX file permissions.
8. If the user has access
to both the share and the
file, then the storage
system grants access.

AUTHENTICATION SCENARIO

The following slides show the steps for a multiprotocol security troubleshooting scenario where a
Windows client user requests access to data on a storage system in a domain environment. Each
step is then examined separately to look at the potential points of failure (issues) and the tools or
steps that are useful to resolve the failure.
1. In a domain environment, a Windows client user requests user session authentication with a
storage system.
2. The storage system goes to the domain controller to authenticate the user.
3. The domain controller authenticates user or indicates user does not exist.
4. If the domain controller indicates user does not exist, the storage system cannot allow guest
access unless cifs.guest_account is set.
5. The storage system maps the NT (user) account to a UNIX user name.
6. The storage system compares the NT account information with share access control list
(ACL).
7. The storage system compares the NT account information with file ACL or the mapped
UNIX account with the UNIX file permissions.
8. If the user has access to both the share and the file, then the storage system grants access.

Issue: Client Communication
1. In a domain environment, a Windows client
user requests user session authentication
with the storage system.
Potential Issue: Network failed or is slow.
Check the following:
system> ifstat
system> netdiag
system> ping
C:\> tracert

ISSUE: CLIENT COMMUNICATION

1. In a domain environment, a Windows client user requests user session authentication with the
storage system.

Potential Issue: Network failed or is slow. Check the following:
system> ifstat
The ifstat command displays statistics about packets received and sent on all or a specified network
interface.
system> netdiag
The netdiag command analyzes the statistics continuously gathered by the network protocol code,
performs various tests (if required), displays the results of analysis, and suggests remedial actions if
problems are encountered.
system> ping
The ping command sends ICMP ECHO_REQUEST packets to network hosts to elicit an ICMP
ECHO_RESPONSE from the specified host or gateway.
C:\> tracert
The Windows tracert command visually displays a network packet being sent and received and the
number of hops required for the packet to reach its destination.

Issue: Client Communication (Cont.)
Potential Issue: Domain controller does not
authenticate the user.
Check the access to other servers in the
domain.
Potential Issue: Windows client cannot find
the storage system.
If using DNS, try pinging the storage system by
name.
C:\> ping system_name

ISSUE: CLIENT COMMUNICATION (CONT.)

Issue: Client Communication (Cont.)
If using WINS, run the nbtstat command.
system> nbtstat
The nbtstat command displays information
about the NetBIOS over TCP connection.
NOTE: If you change the domain controller IP address
in DNS, be sure to change the domain controller IP
address in WINS.

ISSUE: CLIENT COMMUNICATION (CONT.)

Issue: DC Authentication
2. Storage system goes to the domain controller
to authenticate the Windows client user
Potential Issue: Firewall prevents
communications between storage system
and DC
If using SMB over TCP/IP
Windows 2000 and later
Requires TCP port 445
If using SMB over NetBIOS over TCP/IP
Pre-Windows 2000
Requires:
UDP port 137 & 138
TCP port 139

ISSUE: DC AUTHENTICATION

2. The storage system goes to the domain controller to authenticate the Windows client user.
Potential Issue: Firewall prevents storage system and DC communications
SMB directly over TCP/IP, which is available in Windows 2000 and later requires only
TCP port 445.
SMB over NetBIOS over TCP/IP, which is required in all pre-Windows 2000 servers and
clients; requires UDP port 137 and 138 along with TCP port 139.

See http://support.microsoft.com/kb/832017 for more information about the
appropriate communication ports.

NOTE: It is not possible to remap these ports on the storage system. If you have a firewall that
only accepts traffic from certain ports, you will need to set up port forwarding to adequately
establish communication.

Issue: DC Authentication (Cont.)
Potential Issue: Communication from
storage system to domain controller fails or
trust across multiple domains fails.
Perform the following steps:
a) system> cifs domaininfo
This provides information about domain and known
domain controllers.
If you receive an error and want more verbose output,
then go to step b.

ISSUE: DC AUTHENTICATION (CONT.)

b) Set the following option on:
system> options cifs.trace_dc_connection
on
When this option is on, the storage system logs all DC
address discovery and connection activities.
c) system> cifs resetdc
This command tells the storage system to disconnect
from the domain controller and then establish a new
CIFS connection with the DC.
(The steps are being logged with the
cifs_trace_dc_connection option.)
d) Check the trace output on the console or logged output in
/etc/messages file to find the problem.


b) Set the following option on:
system> options cifs.trace_dc_connection on
When this option is on, the storage system logs all DC address discovery and connection
activities.
c) system> cifs resetdc
This command tells the storage system to disconnect from the domain controller and then
establish a new CIFS connection with the DC.
(The steps are being logged with the cifs_trace_dc_connection option.)
d) Check the trace output on the console or logged output in /etc/messages file to
find the problem.
The following is sample output when running the cifs resetdc command with the
cifs.trace_dc_connection option set on.
system> options cifs.trace_dc_connection on
system> cifs resetdc

Disconnecting from domain FILER2K3MIX...
Reconnecting to domain FILER2K3MIX...
Tue Jul 11 08:32:19 CEST [cifs.server.infoMsg:info]: CIFS:
Warning for server \\ FILER2K3MIXDC01: Connection
terminated.
Tue Jul 11 08:32:19 CEST
[auth.dc.trace.DCConnection.statusMsg:info]: AUTH: Trac
eDC- Starting DC address discovery for FILER2K3MIX.
eDC- Filer is not a member of a site.
eDC- Found 1 addresses using generic DNS query.
eDC- DC address discovery for FILER2K3MIX complete. 1 unique
addresses found.
eDC- Connection with \\FILER2K3MIXDC01 established.
Reconnection succeeded
[auth.ldap.trace.LDAPConnection.statusMsg:info]: AUTH:
TraceLDAPServer- Starting AD LDAP server address discovery for
FILER2K3MIX.NGSLA BHD.EUROPE.NETAPP.COM.
TraceLDAPServer- Found 1 AD LDAP server addresses using generic
DNS query.
TraceLDAPServer- AD LDAP server address discovery for
FILER2K3MIX.NGSLABHD.EUROPE.NETAPP.COM complete. 1 unique
addresses found.

3. Domain controller authenticates Windows
client user or indicates user does not exist
Potential Issue: Authentication result is not what was
expected. Check the details of the mapping.
system> options cifs.trace_login on
This option gives verbose output in mapping the user to its
ultimate user identity.
system> cifs sessions s winname
The cifs sessions s winname command where
winname can be a Windows user name or SID, displays
the current user mappings for the Windows account.


3. Domain controller authenticates Windows client user or indicates user does not exist.
Potential Issue: Authentication result is not what was expected. Check the details of the
mapping.
system> options cifs.trace_login on
This option gives verbose output in mapping the user to its ultimate user identity.
system> cifs sessions s winname
The cifs sessions s winname command where winname can be a Windows
user name or SID, displays the current user mappings (credentials) for the Windows
account.

The following are cifs.trace_login examples:
A trace login for a login attempt by a user from a non-trusted domain and there is no guest
account:

system> Tue Jul 11 08:35:11 CEST [auth.trace.authenticateUser.loginAccepted:info]: AUTH:
Login by NULL user from 10.10.10.22 accepted.

[auth.trace.authenticateUser.loginTraceIP:info]: AUTH: Login
attempt by user winguy of domain TEASTDOM from client machine
windows-xp (10.10.10.22).
[auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC-
attempting authentication with domain controller
\\FILER2K3MIXDC01.
[auth.trace.authenticateUser.loginRejected:info]: AUTH: Login
attempt by user rejected by the domain controller with error
0xc0000064: DC indicates user is not from a trusted domain.
[auth.trace.authenticateUser.loginTraceMsg:info]: AUTH: login
from 10.10.10.22 rejected because guest account not set.
A trace login after the guest account is enabled (set to pcuser):
system*> options cifs.guest_account pcuser
system*> Tue Jul 11 08:59:17 CEST
[auth.trace.authenticateUser.loginAccepted:info]: AUTH: Login by
NULL user from 10.10.10.22 accepted.
attempt by user winguy of domain TESTDOM from client machine
windows-xp (10.10.10.22).
\\FILER2K3MIXDC01.
winguy from 10.10.10.22 accepted.

There is no obvious message logged showing that this user has been mapped to pcuser. The last
line of output simply shows that the login was accepted by the storage system after the domain
controller indicated that the user was not from a trusted domain. This is a clue to the mapping.

What you can do is check the output of the command cifs sessions, which shows the
mapped user details and the fact that this is the guest account.
system*> cifs sessions

Server Registers as SYSTEM in Windows 2000 domain FILER2K3MIX.


Selected domain controller \\FILER2K3MIXDC01 for authentication.
==========================================
PC (user) #shares #files
winguy (TESTDOM\winguy - pcuser[guest])
A trace login showing an error when an attempt is made to map the
user to pcuser (remember that it is the account to be used for
guests), but the customer has deleted pcuser from /etc/passwd
file:
system*> Tue Jul 11 09:07:50 CEST
NULL user from 10.10.10.22 accepted.
attempt by user winguy of domain TESETDOM from client machine
windows-xp (10.10.10.22).
\\FILER2K3MIXDC01.
Tue Jul 11 09:07:50 CEST [auth.mapNTToUnix.failed:error]: AUTH:
Error mapping NT user winguy to Unix user: 0xc0000001 (Unix user
name not valid). Login is rejected.

Issue: If User Does Not Exist
4. If the domain controller indicates the user
does not exist, the storage system cannot
allow guest access unless the
cifs.guest_account is set.
Potential Issue: Guest access is denied.
Set the guest account to a desired account name
(user_name):
system> options cifs.guest_account
user_name
The configured user name (account) specifies the UNIX user
ID, group ID, and group set. An example of a user name is
pcuser The cifs.guest_ account is for an
unauthenticated Windows user.
Note: The default mapping for a UNIX user that specifies an
NT user account (user_name) can be set with:
system> options wafl_default_nt_user
user_name

ISSUE: IF USER DOES NOT EXIST

4. If the domain controller indicates that the user does not exist, the storage system cannot allow
guest access unless the cifs.guest_account is set.
Potential Issue: Guest access is denied.
Set the guest account to a desired account name (user_name):
system> options cifs.guest_account <user>
The configured user name (account) specifies the UNIX user ID (UID), group ID (GID), and
group set. An example of a user name is pcuser. The cifs.guest account is for an unauthenticated
Windows user (for example, from an untrusted domain). The user name for this account must also
be in the /etc/passwd file.

If an unauthenticated Windows user is given the cifs.guest_account, then it is mapped to a UNIX
user name with a UID and GID. If the unauthenticated Windows user wants to access an NTFS
file, the user does not have any group rights (because the user is unauthenticated), so the users
authorization is limited to accessing files that are available to everyone. If the user wants to
access a UNIX file, then the UID and GID of the cifs.guest_account are used.

The option cifs.guest_account enables a user to get access to a storage system provided
in which the storage system either:

Uses a domain controller for authentication and the user is not in a trusted domain, or
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

NOTE: The default mapping for a UNIX user that specifies an NT user account (user_name) can
be set with:
system> options wafl_default_nt_user user

Issue: Map NT User to UNIX User
5. Storage system maps NT (user) account to a
UNIX user name
Potential Issue: The NT account does not
map or the UNIX user name does not exist.
Check for the existence of the UNIX user name
in the /etc/passwd file
Edit the /etc/passwd file when necessary.
If using an NIS server:
system> nis info
Check the status of NIS
system> options nis.group_update_schedule

ISSUE: MAP NT USER TO UNIX USER

5. The storage system maps NT (user) account to a UNIX user name.
Potential Issue: The NT account does not map or the UNIX user name does not exist. Check for the
existence of the UNIX user name in the /etc/passwd file.
Edit the /etc/passwd file when necessary.
If using an NIS server:
system> nis info
The nis info command displays the status of the NIS client and slave services along
with the domain name and the last time the local group cache was updated.
Check the status of NIS.
system> options nis.group_update_schedule
Make sure NIS updates are available.

The options nis.group_update_schedule command specifies the hours of the day when
the local NIS group cache has to be updated. If you do not cache the NIS group, performance is
impacted.

Issue: Map NT User to UNIX User (Cont.)
Potential Issue: The NT account does not map
or the UNIX user name does not exist. (Cont.)
Check the user mapping for NT account and
UNIX user name
system> rdfile /etc/usermap.cfg
Edit the /etc/usermap.cfg file when
necessary and be sure to use the proper syntax
system> wcc -S <ntname> and wwc -u
<unixname>
Verify mappings with the wcc command

ISSUE: MAP NT USER TO UNIX (CONT.)

Issue: Checking Share Permissions
6. Storage system compares NT account
information with the share ACL
Potential Issue: User does not have access
to the share.
Check the share-level ACL.
system> cifs shares
The CLI is the best way to check the ACLs.
C:\>
Use the Computer Management GUI (Windows
2000 or later) to view the shares.
The Windows client user must have rights to
connect to the storage system.

ISSUE: CHECKING SHARE PERMISSIONS

6. The storage system compares NT account information with the share ACL.
Potential Issue: User does not have access to the share. Check the share-level ACL.
system> cifs shares
C:\>
Use the Computer Management GUI (Windows 2000 or later) to view the shares. The Windows
client user must have rights to connect to the storage system.

The cifs shares command displays one or more shares, edits one or more shares, creates a
share, deletes a share, or displays a total summary of the shares.

Issue: Checking File Permissions
7. Storage system compares NT account info
with file ACL or mapped UNIX account with
UNIX file permissions
Potential Issue: User does not have access to a file.
Check the security style.
If the qtree has the wrong security style, use:
system> qtree security <qtree>
[ntfs|unix|mixed]
Check the NT ACL information.
Right click Properties -> Security tab
Use fsecurity command
Check the UNIX file permissions.
unix_client> ls l
Use only if qtree status is UNIX or mixed

ISSUE: CHECKING FILE PERMISSIONS

Issue: Checking File Permissions (Cont.)
Resolving denial or unexpected accepted file
access can be difficult
Usually only a general Access Denied error
occurs
Error could be a result of many problems
Two tools to help resolve the problem:
Data ONTAP sectrace command
Microsofts cacls.exe command

CHECKING FILE PERMISSIONS (CONT.)

In the past, when administrators suspected permission problems, they relied solely on NetApp
Support to help them trace the source of the problem. The Data ONTAP sectrace command
allows administrators to quickly find the source of access problems.

Administrators use the sectrace command with a filter to trace access and incoming requests. The
filter is based on a path, an IP address of the client, or the UNIX or Windows username. The
access decisions to grant or deny the request are recorded in an EMS message.

sectrace Command
Administrators can set a storage system to
display file access denials or acceptances.
Traces appear on the console.
To configure:
sectrace add -ip 10.0.0.2 -a
-ip filters the report to only traffic coming from this
client.
-a adds acceptance information, default is only
denial information.
Other possible filters:
-ntuser
-unixuser
-path

SECTRACE COMMAND

To configure sectrace, use the add method along with the optional switches:
-ip switch filters the report to only network traffic coming from a particular client machine.
-a switch includes not just denial information but adds file access granted information
-ntuser switch limits the information in the trace report to a particular Window user
-unixuser switch limits the information in the trace report to a particular unix user. You can provide a
UID or user name.
-path switch limits the information in the trace report to a particular path.

sectrace Command (Cont.)
To display configured traces:
sectrace show [filter_index]
Displays all or a single trace report
Example:
system> sectrace show
Sectrace filter: 1
Hits: 338
IP Addr: 10.0.0.2
Trace DENY and ALLOW events
Number of trace
reports since added

SECTRACE COMMAND (CONT.)

Trace Report example:
Access allowed because 'Execute' permission
(0x20)
is granted on requested path
(Access allowed because the user is root)
- Status: 1:8796095119360:0:0 - 10.254.134.39 -
NT user name: DEVELOPMENT\user_jdoe - UNIX
user name: root(0)
- - Path: /vol/vol0/home/
To get more details, use:
system> sectrace print-status
1:8796095119360:0:0
Access allowed because 'Traverse' permission is
granted on requested path.
Access allowed because the user is root.

sectrace COMMAND (CONT.)

To turn off the trace report:
sectrace delete <[filter_index] | all>
Remember that trace reports should only be
used when troubleshooting file permissions.
Turn it off when you are not using it.

sectrace COMMAND (CONT.)

Microsoft Tool
Microsoft provides a command that shows
access control list information.
cacls.exe
Example:
C:\> cacls file1.pdf
C:\file1.pdf NETAPP\user1:R
NT AUTHORITY\SYSTEM:F
BUILTIN\Administrators:F
Rights:
R = Read
W = Write
C = Change (read/write)
F = Full control

MICROSOFT TOOL

Microsoft provides a tool for analyzing access control list information. This command is
cacls.exe.

Authentication Success
8. If user has access to both the share and file,
storage system grants the user access to the
data
Success

AUTHENTICATION SUCCESS

CISF Setup Scenarios

CIFS SETUP SCENARIOS

cifs setup Scenarios
The following scenarios show common cifs
setup problems and their solutions.
1. DNS disabled
2. DNS enabled, but domain short name is not
resolvable
3. Time synchronization differs more than 5
minutes
4. Incorrect domain controller IP address

cifs setup SCENARIOS

cifs setup: DNS Disabled
system> cifs setup
...
Selection (1-4)? [1]: 1
In order to operate correctly within an Active Directory based
Windows domain, CIFS must use the DNS resolver service. That
service is currently not configured on the filer. You must
either configure DNS resolver services or choose a different
authentication style.
Do you want to configure the filer's DNS resolver service? [y]:
What is the filer's DNS domain name? []:
*** CIFS cannot join an Active Directory-based domain when
*** the filer's DNS resolver service is not available. You
*** must choose a different authentication style to
*** continue.
NOTE: The cifs setup script is clever enough to help you through
this mistake.

cifs setup: DNS DISABLED

Note that the storage system was previously a member of a Windows-style workgroup that did
not require the DNS resolver service, so DNS is disabled. To resolve the problem, enter the DNS
domain name and IP addresses for the DNS name servers.

The cifs setup script is clever enough to help you through this mistake, as shown in the
following slide.

cifs setup: DNS Disabled (Cont.)
(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 filer's
local user accounts
(4)/etc/passwd and/or NIS/LDAP authentication
Selection (1-4)? [1]: 1
In order to operate correctly within an Active Directory
based Windows domain, CIFS must use the DNS resolver
service. That service is currently not configured on the
filer. You must either configure DNS resolver services
or choose a different authentication style.
Do you want to configure the filer's DNS resolver
service? [y]:
ngslabhd.europe.netapp.com

cifs setup: DNS DISABLED (CONT.)

cifs setup: DNS Disabled (Cont.)
What are the IPv4 address(es) of your authoritative DNS
name server(s)? [10.64.25.91]:
Would you like to specify additional DNS name servers?
[y]:
What are the IPv4 address(es) of your authoritative DNS
name server(s)? [10.64.25.92]:
Would you like to specify additional DNS name servers?
[n]:
...
system> Tue May 16 05:40:43 GMT
[cifs.startup.local.succeeded:info]: CIFS: CIFS local
server is running.
Success

cifs setup: DNS DISABLED (CONT.)

cifs setup: Domain too Short
system> cifs setup
...
Selection (1-4)? [1]: 1
In order to operate correctly within an Active Directory based
Windows domain, CIFS must use the DNS resolver service. That
service is currently not configured on the filer. You must
either configure DNS resolver services or choose a different
authentication style.
Do you want to configure the filer's DNS resolver service? [y]:
ngslabhd.europe.netapp.com
What are the IPv4 address(es) of your authoritative DNS name
server(s)? [10.64.25.91]:
Would you like to specify additional DNS name servers? [y]:
What are the IPv4 address(es) of your authoritative DNS name
server(s)? [10.64.25.92]:

cifs setup: DOMAIN TOO SHORT

cifs setup: Domain too Short (Cont.)
Would you like to specify additional DNS name
servers? [n]:
What is the name of the Active Directory domain?
[ngslabhd.europe.netapp.com]: filer2k3mix
Note: DNS name too short
*** CIFS Setup cannot find a necessary DNS service
***(SRV)record for the specified domain.
*** The"_ldap._tcp.FILER2K3MIX" service cannot be
*** found using DNS as currently configured.
(1) Enter a different Active Directory domain name
(2) Reconfigure DNS and try again
(3) Exit CIFS Setup

cifs setup: DOMAIN TOO SHORT (CONT.)

cifs setup: Domain too Short (Cont.)
What is the name of the Active Directory domain? []:
filer2k3mix.ngslabhd.europe.netapp.com
NOTE: Provide Fully Qualified Domain Name (FQDN)
In order to create an Active Directory machine account
for the filer, you must supply the name and password of
a Windows account with sufficient privileges to add
computers to the FILER2K3MIX.NGSLABHD.EUROPE.NETAPP.COM
domain.
...
system> Tue May 16 06:32:12 GMT
[cifs.startup.local.succeeded:info]: CIFS: CIFS local
server is running.
Success

cifs setup: DOMAIN TOO SHORT (CONT.)

To resolve the problem, use the Fully Qualified Domain Name (FQDN) when the Active
Directory domain name is entered.

cifs setup: Time Sync
system> cifs setup
...
Selection (1-4)? [1]: 1
What is the name of the Active Directory domain? []:
FILER2K3MIX.NGSLABHD.EUROPE.NETAPP.COM
FILER2K3MIX.NGSLABHD.EUROPE.NETAPP.COM domain.
[Administrator@FILER2K3MIX.NGSLABHD.EUROPE.NETAPP.COM]:
Password for
Administrator@FILER2K3MIX.NGSLABHD.EUROPE.NETAPP.COM:
Could not authenticate with domain controller: Filer and Domain
controller clocks are more than 5 minutes apart.
Filer and Domain Controller times must be synchronized in
Windows 2000 domains.

cifs setup: TIME SYNC

cifs setup: Time Sync (Cont.)
CIFS - unable to log into domain as
Administrator@FILER2K3MIX.NGSLABHD.EUROPE.NETAPP.COM.
Please try again (Ctrl-C to exit).
system>
Use date command or setup NTP services
Verify the timezone with timezone command
Storage system and DC must be in sync within
5 minutes
When in sync, rerun cifs setup

cifs setup: TIME SYNC (CONT.)

A quick fix to resolve this problem is to use the date command on the storage system and change
the storage-system time to match the domain-controller time. If the storage-system time differs
more than 30 minutes from the time server, then you must use the date command to reset the
storage-system time.

cifs setup: Incorrect DC IP
system> cifs setup
...
Selection (1-4)? [1]: 1
What is the name of the Active Directory domain?
[ngslabhd.europe.netapp.com]:filer2k3mix.ngslabhd.europe.netapp
.com
FILER2K3MIX.NGSLABHD.EUROPE.NETAPP.COM domain.
Password for
Could not authenticate with domain controller: KRB5 error code
68.

cifs setup: INCORRECT DC IP

cifs setup: Incorrect DC IP (Cont.)
Password for
Could not authenticate with domain controller: KRB5 error code
68.

cifs setup: INCORRECT DC IP (CONT.)

[Administrator@FILER2K3MIX.NGSLABHD.EUROPE.NETAPP.
COM]:
system>
[Ctrl-C is typed to exit cifs setup.]
system> cifs prefdc print
Preferred DC ordering per domain:
FILER2K3MIX:1. 10.64.21.95
Incorrect DC IP address


Incorrect IP address:
cifs prefdc add <domain_name>
<Incorrect_DC_IP_address_list>
To resolve this problem:
1. cifs prefdc delete <domain_name>
2. cifs prefdc add <domain_name>
<Correct_DC_IP_address_list>


Best Practices

BEST PRACTICES

Best Practices
Configure NTP to same time sources as DCs
Active Directory is dependent on DNS
Configure DNS to find:
Active Directory domain controllers
LDAP servers
Kerberos servers
Kpasswd (Kerberos password) servers

BEST PRACTICES

Best Practices (Cont.)
If possible, eliminate WINS
Avoids conflicting with DNS
Prefer to bind to a local or nearest possible DC
/ LDAP service whenever appropriate
If sites have been implemented, join storage
system with a site that has high-bandwidth
connections
Better performance

BEST PRACTICES (CONT.)

Module Summary

Module Summary
A multiprotocol scenario is complex but with a
proper understanding any difficulties can be
avoided.
Several issues may come up during CIFS
setup; each can be avoided with proper
planning.

MODLUE SUMMARY

Exercise
Module 8: Troubleshooting

EXERCISE


Check Your Understanding
When communication from a storage system to
a domain controller fails or trust across
multiple domains fails, what steps are useful to
resolve the problem?
When the NT account does not map or the
UNIX user name does not exist, what steps are
useful to resolve the problem?
When the user does not have access to the
share, what steps are useful to resolve the
problem?

CHECK YOUR UNDERSTANDING

Check Your Understanding
When the storage system and the Active
Directory domain controller time clocks differ
more than 5 minutes, what steps are useful to
resolve the problem?
During cifs setup, if you enter the short
name for the Active Directory domain, what
error occurs and how do you resolve the
problem?

CHECK YOUR UNDERSTANDING

64 2008 NetApp. All rights reserved. 64
Additional Resources
Education
NFS Administration on Data ONTAP 7.3
SAN Administration on Data ONTAP 7.3
NetApp Protection Software Administration
Performance Analysis on Data ONTAP 7.3
Web sites
NOW(NetApp on the Web)
NetApp (www.netapp.com)

ADDITIONAL RESOURCES

Thank You!
Please fill out an evaluation.

THANK YOU!


CIFS Administration On Data ONT - NetApp University

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CIFS Administration On Data ONT - NetApp University

Uploaded by

Copyright:

Available Formats

NetApp University

Data ONTAP 7.3

You might also like