emc vnx home directory · 2 days ago · in the typical business environment, user home directories...

White Paper

Abstract

This paper provides an overview of the VNX™ Home Directory feature. VNX gives system administrators the ability to configure powerful rules that automate the process of creating and assigning home directories to users. Whether an organization has hundreds of users or tens of thousands, this feature helps relieve the management burden of providing CIFS home directories for the organization’s users.

March 2015

EMC VNX Home Directory A Detailed Review

2 EMC VNX Home Directory

Copyright © 2015 EMC Corporation. All Rights Reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. The information in this publication is provided “as is.” EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.

Part Number H2283.5

Table of Contents

Executive summary.................................................................................................. 4

Introduction ............................................................................................................ 5

Audience ............................................................................................................................ 5

Terminology ....................................................................................................................... 6

What is VNX Home Directory? ................................................................................... 7

Traditional approaches to CIFS home directory implementation ......................................... 7

Shared drive ................................................................................................................... 7

Unique shares ................................................................................................................ 8

The VNX Home Directory approach ..................................................................................... 9

Stored mappings .......................................................................................................... 11

Process for matching user credentials against database entries ....................................... 12

Home Directory database search: In detail ................................................................... 12

Path syntax ...................................................................................................................... 14

Regular expressions ......................................................................................................... 15

Auto-create....................................................................................................................... 17

How do I manage Home Directory? ......................................................................... 18

Managing home directory entries ..................................................................................... 18

Enabling the Home Directory service ................................................................................ 19

Scope of the Home Directory feature ................................................................................ 19

Exporting/importing the Home Directory database ........................................................... 19

Security considerations .................................................................................................... 20

Setting the Home Directory path in AD User Profile ........................................................... 22

Spreading users across two or more file systems .............................................................. 23

When <domain,user> values are identical between database entries ............................ 24

When only <domain> is identical between database entries .......................................... 27

Spreading users across two or more Data Movers ............................................................. 27

Replicating Home Directory configurations ....................................................................... 29

Migrating Home Directory configurations from VNX to VNX ............................................... 30

Migrating Home Directory configurations from another vendor’s array to VNX ................... 30

File Extension Filtering and Quotas ................................................................................... 32

Conclusion ............................................................................................................ 33


Executive summary Data is vital to the operation of today’s businesses: Even small data files generated every day by individual users can have costly repercussions if they are lost or damaged. Yet, by failing to provide a protected storage location on the network for this data, many companies effectively mandate that users store data on fault-sensitive disks in laptop or desktop computers.

CIFS home directories can be combined with fault-tolerant storage (such as VNX) to provide safe, secure, network-accessible storage for this user-level data. Management of these home directories can be burdensome to the storage administrators, so EMC® VNX provides an integrated Home Directory feature that significantly reduces administrative burden by shifting the directory and share management to VNX.

In the typical business environment, user home directories are not shared; each home directory is intended for only one specific user. Consequently, the system or domain administrator must:

1. Determine where the user’s home directory will exist.

2. Create a directory on the file server to act as the user’s home directory.

3. Create a CIFS share to give the user access to the home directory.

4. Secure the CIFS share.

5. Set the home directory field of the user’s profile on the domain controller to reflect the appropriate home directory location.

VNX’s Home Directory feature eliminates the need for three of these steps. Further, it eases the burden of the last step because the contents of the home directory field in the user profile can be the same for all users.

When using VNX’s Home Directory feature, you initially set up rules that govern home directory behavior. To add a user home directory, you then follow this less burdensome sequence of steps:

1. Determine where the user’s home directory will exist.

2. Set the home directory field of the user’s profile on the domain controller to reflect the appropriate home directory location.

The Home Directory feature also has important benefits for disaster recovery (DR) and migration. VNX’s CIFS configurations can be replicated to remote sites for DR purposes, and the home directory database is a replicated configuration component. Should disaster strike, end users need only to reconnect to the home directory, eliminating the need to change the Universal Naming Convention (UNC) path.

In migration scenarios, the home directory database and user file systems can be migrated to the new VNX Data Mover with minimal downtime. Once the home directory database has been migrated, users can simply be referred to the new VNX Data Mover where each user will see his home directory as it was on the old VNX Data


Mover. This simplicity contrasts with the need to manually migrate a CIFS home directory configuration that includes hundreds or thousands of individual CIFS shares (one per user). As a company’s home directory storage needs grow, migrating to newer or larger VNX cabinets requires less work than it would otherwise.

VNX for File Operating Environment (OE) 8.1.3.72 introduces a parameter that allows users to connect to their Home Directory using a \\server\username[$] path while still being able to use the traditional \\server\HOME path. This new syntax is helpful to users who are migrating their home directories from another vendor’s arrays to a VNX. By supporting the \\server\username[$] path, manual changes from a \\server\username[$] path to a \\server\HOME path is eliminated. See Migrating Home Directory configurations from another vendor’s array to VNX for more information.

In summary, the VNX Home Directory’s benefits are:

Significantly reduced administrative costs around home directory management

Simpler, more reliable disaster recovery

Simpler, more reliable home directory migrations to VNX or between VNX Data Movers (intra- and extra-cabinet)

Introduction This paper’s goal is to communicate the business case for VNX Home Directory, as well as high-level implementation and design considerations of the feature. Specific implementation details are documented in the VNX Home Directory Management Help Files and are not be covered here.

To achieve that goal, this paper answers these questions:

• What is Home Directory?

• How does Home Directory work?

• How do I manage Home Directory?

• How can I take Home Directory beyond its basic functionality and use it in advanced ways?

Audience

EMC customers, those considering the purchase of EMC VNX storage, and EMC field personnel are the intended recipients of this paper.

This audience expected to have a basic understanding of VNX concepts and the administration of users within a Microsoft Windows Active Directory domain. A basic understanding of VNX CIFS technology is assumed, although this paper should also be accessible to those who understand Microsoft CIFS concepts but lack deep understanding of VNX’s CIFS implementation.


Terminology

Common Internet File System (CIFS)— A file sharing technology for IP networks that is the primary file sharing technology for Microsoft Windows operating systems and that has gained traction with other operating systems. CIFS is based on the Server Message Block (SMB) protocol.

Disaster recovery (DR) — The recovery of business IT operations after the primary data site is lost to a disaster. Such disasters may include power outages, natural disasters such as wind damage or flooding, terrorist attacks, and so forth.

Home Directory— A dedicated, network-attached (CIFS) file storage resource; typically one per user and mapped as a network drive at login.

Microsoft Management Console (MMC)— An extensible Microsoft application (mmc.exe) that provides the ability to create a custom system management “dashboard” (or view). Many Microsoft Windows features are managed via the MMC; for example, Computer Management (compmgmt.msc) is an MMC application.

MMC Snap-in— A plug-in to the Microsoft Management Console. These plug-ins can be arbitrarily grouped into a single, customized MMC view by using the mmc.exe /console command. Microsoft provides many such plug-ins, but third-party vendors such as EMC may also provide plug-ins to manage their own products. EMC VNX File CIFS Management is an example of an MMC Snap-in that is provided by EMC.

Virtual Data Mover (VDM)— A virtual container of VNX file systems and CIFS servers. A VDM is treated as a unit, and it can be moved between Data Movers within a VNX cabinet and replicated to other Data Movers for disaster recovery.

VNX File CIFS Management—An EMC MMC snap-in that provides management functions for Home Directory, as well as for some other VNX features. (Previously called Celerra CIFS Management.)


What is VNX Home Directory?

Traditional approaches to CIFS home directory implementation

To understand exactly what VNX Home Directory is and what it does, first consider two traditional approaches for providing CIFS home directories: shared drive and unique shares.

Note that this paper’s examples use a simple subset of a hypothetical user base, and they show the perspective of three users:

Table 1. Example users and logon names

Full name Windows logon name

Joanna Smith MARKETING\jsmith

Mark Fodor MARKETING\mfodor

Rue Prada FINANCE\rprada

This example uses a CIFS server called ATLANTA3, assumed to be joined to the MARKETING domain. Also assume that the MARKETING domain has a bidirectional trust relationship with the FINANCE domain so that members of both domains can authenticate with ATLANTA3.

Shared drive

One common implementation for CIFS home directories is the “shared drive” implementation, shown in Figure 1. This implementation is simple both conceptually and in practice: One large shared drive (CIFS share) is created and shared by many users. Each user has a folder/directory on the shared drive that is used as the user’s home directory. The advantage of this approach is that it can be extremely easy to implement if security is not a concern. Some challenges with this approach are:

The creation of each user’s home directory can be labor-intensive.

Setting permissions on each new home directory can be labor-intensive and error-prone.

Unless proper security measures are implemented with file permissions/Access Control Lists (ACLs), one user may be able to see – and perhaps modify – another user’s files. Correctly applying ACLs to home directories can be a laborious and error-prone process.

The user must navigate into a subdirectory of the share to find his own home directory.

This problem can be prevented by specifying the full path to a user’s home directory in his Windows profile. For example, in Figure 1 mfodor’s profile would contain the path \\atlanta3\shared\mfodor in his home directory settings.


Figure 1. All users map the same CIFS share in the shared drive approach

Unique shares

The “unique shares” approach is another common implementation for CIFS home directories (shown in Figure 2). In this approach, a unique CIFS share is created for each user’s home directory. Only the user who owns the home directory is permitted to map the share. This approach is more secure than the shared drive implementation, but it suffers from being much more difficult to implement. Its drawbacks include:

Creation of all the shares can be labor-intensive.

Creation of the directory that roots each share can be labor-intensive.

Setting permissions on each new share can be labor-intensive and error-prone.


Figure 2. A CIFS share is created for each user in the unique shares approach

The VNX Home Directory approach

VNX Home Directory achieves the benefits of both the shared drive and unique shares approaches (ease of implementation and high security) while alleviating administrative burden. It accomplishes this in two ways:

It provides a unique, secure home directory view to each user without requiring a unique share for each user.

It automates most of the traditional home directory management duties by moving responsibility for those duties from the administrator to the VNX server.

VNX Home Directory uses CIFS login information and a database to provide a unique, secure home directory view to each user. The home directory view users see is defined by rules stored in the Home Directory database. A VNX administrator configures the database to meet the specific needs of the organization.

VNX Home Directory eases home directory administration in two key ways:

It enables users to see their unique home directory views while logging into the same CIFS share.

It has a flexible language for specifying home directory mapping rules, allowing the administrator to specify mapping behavior for hundreds or even thousands of users with a single rule.

For a given CIFS server, each user of the CIFS server connects to \\[cifs-server]\HOME to access his/her home directory. In other words, all users connect to the same CIFS share, as depicted in Figure 3.

Figure 3. User mechanism of connecting to VNX with Home Directory feature


All users connect to \\atlanta3\HOME, the location of their home directory. Note that any shared-drive CIFS solution can provide this functionality, but only if all three users are allowed to see the same files and directories when connected to \\atlanta3\HOME. For example, in Figure 3 all three users would see the same directory listing of \\atlanta3\HOME if a shared drive implementation were used:

$ dir \\atlanta3\HOME

aapple

…

jsmith

mfodor

rprada

…

For example, Joanna Smith could access the contents of Mark Fodor’s home directory if the ACLs allow. Yet this behavior is not typically desirable. The alternative unique shares approach – giving each user a dedicated share to map (\\atlanta3\jsmith, \\atlanta3\mfodor, \\atlanta3\rprada) – is also undesirable because it greatly increases the administrative burden of providing the user home directories.

Changing the requirements extends the example case. A column could be added to the user table to specify not only the user’s logon information, but also the file path that should be exported to the user when connected to the home directory CIFS share. In other words, the table that specifies that each user should have a unique view when connected to \\atlanta3\HOME\ is augmented.

Table 2. Users, logon names, and home directory paths

Full name Windows logon name Home directory path

Joanna Smith MARKETING\jsmith /marketing/jsmith

Mark Fodor MARKETING\mfodor /marketing/mfodor

Rue Prada FINANCE\rprada /finance/rprada

This latest requirement changes the example significantly. All users are connecting to the same share – \\atlanta3\HOME – yet each user sees a different set of files and folders when connected. VNX Home Directory enables exactly this capability, shown in Figure 4.


Figure 4. Logical view built when a user connects to Data Mover with VNX Home Directory

VNX Home Directory’s secure single share model – in which all users connect to the same share yet see unique, private file system views – provides noteworthy value when configuring user profiles in the Active Directory. The Setting the Home Directory path in AD User Profile section on page 22 offers more information.

Stored mappings

VNX Home Directory uses a database to store mappings between users and file system paths. Each Data Mover or Virtual Data Mover has a database table where a row in the table takes this general form:

Table 3. Database table form

Match criterion Path Options

A match criterion consists of two patterns: One pattern specifies a domain name and the other pattern specifies a username.

Table 4. Match criterion table form

Match criterion Path Options

domain name username

When a user like Joanna Smith logs into the CIFS server called atlanta3, the Data Mover extracts Joanna’s domain (MARKETING) and username (jsmith) from her login credentials. The Data Mover uses this information to search the home directory database; it compares Joanna’s domain and usernames with the various match criteria stored in database table. If the Data Mover finds a match, then the specified


path will be associated with Joanna’s CIFS session. If no match is found, then Joanna’s CIFS session fails and she is denied login.

In the following sections look more closely at how this process works.

Process for matching user credentials against database entries

Login information (domain name, username) is compared against the match criterion of database entries to find the user’s home directory path. Visually, this database simply looks like:

Table 5. Database matching criteria

domain name username path options


… … … …


At the most basic level, the Data Mover consults the database and looks for a match based on domain name and username. If it finds such a match, then it looks for the path specified by the matching entry. If it fails to that path, then the Data Mover will look for the next matching database entry. Since the search algorithm is slightly more complex than this description allows, it is worth taking a deeper look at the database search.

Home Directory database search: In detail

Finding a match in the database is not as simple as the “first match” algorithm. Rather, the Data Mover searches the entire database top to bottom when looking for a match, and no single match is used until all matches have been identified.

When the Data Mover finds multiple matches in the database, it will attempt to use (“try”) the most recently found match first. Note that the most recently found matching entry is the one found farthest down the database table. Should the Data Mover be unable to locate the path specified by that matching entry, it will take the next most recently found match and try it, and so on.


This section uses Joanna as an example to look at the match process. For this example, Joanna maps \\atlanta3\HOME, and the Home Directory database looks like the following:

Figure 5. Database matching

After reading the database table from top to bottom, the Data Mover processes the rows that match in “most recently found” order. This means that the matches will be processed in this order:

Table 6. Database matching order

Order processed

Matching entry

1 MARKETING *smith /home/special/msmith options

2 * * /guests options

3 MARKETING jsmith /marketing/jsmith options

The Data Mover will look at Matching Entry #1 first, so it will search for the path /home/special/msmith. Assuming that the path /home/special does not exist on the Data Mover, Matching Entry #1 will be discarded because the home directory /home/special/msmith does not exist. Matching Entry #2 (/guests) will be processed next, and the path /guests does exist. Joanna will be allowed to map \\atlanta3\HOME and her working directory for that session will be /guests.

Recall that this result is not desired; Joanna’s working directory was to be /marketing/jsmith. That goal can be achieved by simply changing the order of the Home Directory database table entries so that the desired entry to apply is found last and processed first:

Table 7. Database matching order flexibility

Domain User Path Options

FINANCE * /finance options

MARKETING h* /marketing-h options

* * /guests options

… … … …

MARKETING *smith /home/special/msmith options

MARKETING jsmith /marketing/jsmith options

In practice, it is best to ensure that only one database table entry/row will match each user, unless the goal is to spread users across multiple file systems. This white paper discusses how to spread users across multiple file systems in a subsequent section.

If multiple matches are necessary to implement the home directory rules required for the organization, then the best practice is to put the more general criteria toward the top of the database table and more specific criteria toward the bottom of it. This arrangement allows more specific database entries to be found last and processed first.

Path syntax

This white paper has established that Home Directory database entries are matched to a user’s login credentials based on the value of the domain name and username. However, the actual database key is not <domain,user> but <domain,user,path>. Including the path in the key provides the flexibility to specify multiple matching entries in the database so that users can be spread across multiple file systems. Spreading users across multiple file systems is discussed below; it is only mentioned here to emphasize the reason the path field is part of the key in the Home Directory database.

A path has the following general syntax:

It must begin with a forward ‘/’ or backward slash ‘\’ character.

It may contain two special strings that are substituted by the Data Mover upon processing the database entry:

o : Substituted with the username of the user who is connecting to the HOME share

o <d>: Substituted with the domain name of the user who is connecting to the HOME share

It must be specified relative to the root of the Data Mover or Virtual Data Mover.

The substitution strings provide enormous flexibility when defining database entries. Consider the following example:

Table 8. Example database entries with substitution strings


* a* /home/<d>/a-c/ options

* b* /home/<d>/a-c/ options

* c* /home/<d>/a-c/ options

* d* /home/<d>/d-f/ options

* e* /home/<d>/d-f/ options

…20 more…

* z* /home/<d>/y-z/ options

FINANCE * /finance/ options

MARKETING * /marketing/ options

The first 26 entries in this table (only six are shown here) are “catch all” entries; users of all domains other than FINANCE and MARKETING match to one of these entries, and their home directories are arranged into alphabetical buckets (a-c, d-f, etc.) according to their domain and usernames. For example, if ENGINEERING\ecartman logs in, the Data Mover will process the database and determine that the home directory is /home/engineering/d-f/ecartman.

The last two entries in the table catch all users in the MARKETING and FINANCE domains, associating those users with directories under /marketing and /finance, respectively.

Substitution strings provide the ability to avoid having to specify one Home Directory database entry per user. Instead, you can specify a generic path that contains substitution strings; the path will then become customized for each user based on login credentials.

Regular expressions

When defining Home Directory database entries using only alphanumeric characters and the two supported wild cards (‘*’ and ‘.’), it can be difficult to encode the necessary patterns. This challenge might result in an excessive number of database entries to achieve a goal that should have been relatively simple. VNX Home Directory solves this problem by leveraging the enormous flexibility of regular expressions to specify the domain name and username of a database entry.

Consider a scenario where the goal is to divide users alphabetically among different file systems such that groups of four adjacent letters are on the same file system (a-d, e-h, and so on). Without regular expressions, this goal can be accomplished only by creating 26 separate database table entries, one for each letter of the alphabet.

Table 9. Example entries without Regular Expression use


* a* /homeA-D/<d>/ options

* b* /homeA-D/<d>/ options

* c* /homeA-D/<d>/ options

* d* /homeA-D/<d>/ options

* e* /homeE-H/<d>/ options

…18 more… … … …

* x* /homeU-X/<d>/ options

* y* /homeY-Z/<d>/ options

* z* /homeY-Z/<d>/ options

Using regular expressions, this set of 26 entries can be consolidated into a set of only seven and shows how powerful it is to use regular expressions:

Table 10. Example entries using regular expressions


.* [a-d].* /homeA-D/<d>/ regexp=Yes

.* [e-h].* /homeE-H/<d>/ regexp=Yes

.* [i-l].* /homeI-L/<d>/ regexp=Yes

.* [m-p].* /homeM-P/<d>/ regexp=Yes

.* [q-t].* /homeQ-T/<d>/ regexp=Yes

.* [u-x].* /homeU-X/<d>/ regexp=Yes

.* [y-z].* /homeY-Z/<d>/ regexp=Yes

Table 11 shows other examples of how regular expressions can be used in the Home Directory database to simplify Home Directory management:


Table 11. Examples of regular expression use in the Home Directory database

Domain name Username Matches Does not match

[ENGINEERING|FINANCE] .* All users in the domains ENGINEERING and FINANCE

Users in any other domain

.* [wdc|moc].* All users in all domains whose names are prefixed with the contractor designations ‘wdc’ (Widget Development Corp) or ‘moc’ (Manufacturing Operations Consultants)

Users whose names are not prefixed with one of the two designations

.* .* [2] [0-9] {3}.*

All users in all domains that have four sequential numeric characters in the username where the first digit is 2; for example, joe2006

Users whose names do not have the required sequence of digits

While regular expressions can simplify Home Directory management, they should be used with care. Be sure that the regular expression you use does not unintentionally match users other than those it is designed to match.

Auto-create

While the combination of regular expressions with Home Directory’s single share model is powerful, its usefulness is diminished if each user’s home directory must be manually created. VNX Home Directory’s auto-create feature can ensure that home directories are created automatically as needed by the VNX1.

Auto-create is an option set on the Home Directory database table entry. It tells the Data Mover to create the user’s home directory if such a directory does not already exist. There are several choices for the security applied to these auto-created directories; see the Security considerations section on page 19 for details. Only the lowest level token in the home directory path will be created. If the parent container of the lowest-level token not exist, then the home directory entry will be treated as if it does not match the login credentials.

1 File system permissions on the automatically created directory are:

drwxr--r-- 2 root bin

Figure 6. Auto-create and the Home Directory path

For example, assume that MARKETING\jsmith’s home directory is /homeI-L/marketing/jsmith. Also assume that the only matching database table entry for MARKETING\jsmith specifies a home directory path of /homeI-L/<d>/ and that the auto-create option is set on that entry. When jsmith attempts to map the HOME share, the Data Mover will create the jsmith directory if it does not already exist in /homeI-L/marketing. If /homeI-L/marketing does not already exist, then jsmith will be unable to map the HOME share because the Data Mover will not create both the parent directory (/homeI-L/marketing) and the home directory itself (/homeI-L/marketing/jsmith). Only the lowest level token in the path (the home directory itself) will be created.

How do I manage Home Directory? VNX Home Directory is managed through the EMC VNX File CIFS Management MMC Snap-in, a tool that runs on Microsoft Windows operating systems and plugs into the Microsoft Management Console (Figure 7). Refer to the MMC Snap-in help files for more information.

The Scope of the Home Directory section provides important information about the granularity at which the home directory service can be controlled.

Managing home directory entries

Home directory entries are managed through the EMC VNX File CIFS Management MMC Snap-in2. You can add, delete, and modify entries. You can also reorder the database by dragging entries and dropping them at the bottom of the database.

2 The EMC VNX File CIFS Management MMC Snap-in is available on EMC Online Support.

/homeI-L/

marketing/

jsmith/

In path /homeI-L/<d>/ with auto-create enabled, the lowest level directory (represented by – jsmith in this case) will be created automatically if needed.


Figure 7. EMC VNX File CIFS Management MMC Snap-in

Note that the Data Mover Management Snap-in operates by connecting to a VNX CIFS server. You must therefore create a CIFS server and connect the Data Mover Management Snap-in to that CIFS server before you can modify Home Directory service status or manage the Home Directory database.

Enabling the Home Directory service

The Home Directory service can be started and stopped through the EMC VNX File CIFS Management MMC Snap-in (Figure 7). The special HOME CIFS share is exported automatically when the Home Directory service is running.

Scope of the Home Directory feature

It is important to know the scope of the Home Directory feature. Does it apply to the whole Data Mover? Does it apply to all Data Movers in a VNX cabinet? Or does it have some other scope?

You configure the Home Directory at the Data Mover or Virtual Data Mover level. Thus, the home directory service can be enabled or disabled independently on each Data Mover and Virtual Data Mover.

Each VNX Data Mover or Virtual Data Mover has its own Home Directory database. All users logging in to the HOME share on the primary Data Mover will share a database. However, users logging into a Virtual Data Mover share a different home directory database. Users connecting to two different CIFS servers on the same Data Mover or Virtual Data Mover share the same Home Directory database.

Exporting/importing the Home Directory database

There is no graphical user interface for exporting and importing the Home Directory database. However, to give one Data Mover or Virtual Data Mover an identical copy of


another Data Mover’s Home Directory database you can copy the file3 /.etc/homedir from one Data Mover to another.

Security considerations

In the most common and secure configuration, the VNX Home Directory allows each user to access only his/her own home directory, as defined by the rules configured in each home directory database on each Data Mover. You should take special care to ensure that the rules defined by system administrators do not allow unintended access violations. The default behavior is the most secure and does not need to be changed if the “owner-only access” model is desired.

The VNX Home Directory gives you greater control over who can access automatically-created home directories. This higher degree of control is accomplished using Access Control Lists (ACLs) that are applied to these directories. Specifically, a registry flag offers two security options for automatically-created home directories:

1. Restrict ACL to the owner. (This is the default value.)

2. Set ACL based upon inherited values.

With both settings, if the parent ACL is set up correctly, the inheritance model ensures that the owner of the new home directory is the Windows user rather than UNIX root. When using inheritance, you must be careful when building the inherited ACL to ensure that you achieve the desired result.

A third setting is also available. This setting places the UNIX root user as the owner of each Home Directory folder and the EVERYONE group is given full control. This third setting applies only to new auto-created home directories. It does not apply to manually created or existing home directories.

This security feature is controlled through a registry entry belonging to the CIFS Server:

HKEY_LOCAL_MACHINE\Software\EMC\Homedir\Flags

3 The server_file Control Station command can be used to retrieve and upload this file.


Figure 8. Setting the registry entry for auto-created home directories

The registry entry is global to each Data Mover and Virtual Data Mover, meaning that every CIFS Server on the Data Mover shares the same setting, and every CIFS server on a Virtual Data Mover (VDM) shares the same setting. (A VDM has its own registry, which is distinct from the Data Mover’s registry.) If different groups of CIFS users require different auto-create security policies, those groups can be segregated onto different VDMs. This registry entry can be set from any Windows host in the CIFS Server’s domain by using the regedit / regedt32 commands to connect to the CIFS Server’s registry.

This setting only applies to new, automatically-created home directory paths. Paths that were previously created automatically or manually are unaffected by this registry setting.

The following is a detailed description of the three options for Home Directory security:

0x0 (default)— This setting disallows ACL inheritance from the parent folder and creates the new home directory with the user as the owner (as opposed to ‘root’). Only the user/owner has full privileges. No other privileges are set, which effectively locks out every other user from the directory. To access the user’s home directory, an administrator or user with “take ownership” privileges must take ownership of the home directory and modify the ACL as required.

0x1— This setting creates the new home directory with the current user as the owner (as opposed to ‘root’) and gives that user full privileges. Inheritance from the parent folder is allowed and dictates any further permissions applied on the home directory folder. This setting may revert to the 0x0 behavior if the ACL inheritance from the parent folder has not been configured. Using inheritance requires care in building the inherited ACL so that the desired result is achieved.


0x2— Any new home directory folder is created with ‘root’ as the owner and allows full privileges to the “EVERYONE” access control entry (ACE).

NOTE: When using the setting 0x1, you should exercise special care. Understand fully the implications of permissions and ACL inheritance. In particular, the inheritance of the “CREATOR OWNER” ACL limits permissions to newly created files and folders inside a user’s home directory folder to the user who created the file or folder. For example, a file created by the Domain Administrator (assuming the permission to do so exists in the ACL) in another user’s home directory will be owned by the Domain Administrator. It will not be accessible to the user who owns the home directory. This is because there is no ACL in the home directories ACL that specifically grants permission to that user (instead, it is the “CREATOR OWNER” ACL).

Setting the Home Directory path in AD User Profile

Active Directory Users and Computers allows you to assign a network path as a user’s home directory4 (Figure 9). In a traditional unique shares home directory scenario, each user has a unique home directory network path. For example, the path shown in Figure 9 might be \\atlanta3\rprada if using the unique shares approach. With each user who added to the Active Directory, you must specify the unique path of user’s home directory in that user’s profile.

VNX Home Directory removes this burden because all users of a CIFS server connect to the same path. This is precisely why in Figure 9 Rue Prada is connecting to \\atlanta3\HOME rather than \\atlanta3\rprada. Other users – such as Mark Fodor – would also connect to \\atlanta3\HOME. Thus, it is possible for the Active Directory administrator to create a template user account with the home directory predefined in the profile, and then copy that user account to add a new user. The home directory path will be copied from the template account and the administrator will not need to set it manually.

4 If the home directory field is set in the AD User Profile, then Windows will take the following actions when the user logs in to a domain member computer:

Map the home directory and assign it to the specified network drive Set the HOMEDRIVE, HOMEPATH, and HOMESHARE user environment variables


Figure 9. Setting the home directory in an Active Directory

Figure 9 shows how to set the user home directory using the Active Directory Users and Computers MMC snap-in. The home directory can also be set using the net user command on the cmd.exe command line. The net user command can be particularly useful in scripting changes to the home directory configuration of existing user accounts. The following example shows how the home directory would be set to \\atlanta3\HOME for the user rprada:

net user rprada /homedir:"\\atlanta3\HOME”

Spreading users across two or more file systems

In certain scenarios, you might want to spread the home directory users of a single domain across more than one file system. Some of these scenarios include:

Performance— In large domains or under heavy I/O conditions, splitting the home directory users between two or more file systems may yield better performance.

Capacity— In large domains or in environments where user home directories are very large, it may be necessary to spread users among two or more file systems to avoid encountering file system capacity limitations.

Billing/chargeback— Spreading users across two or more file systems can help track the capacity used by each set of users. Tracking use can be helpful when parts of an organization are billed internally for their users’ file system usage, or for ISVs that are providing storage hosting services for external customers.

VNX Home Directory makes it relatively easy to spread users across two or more file systems. Recall the discussions in Process for matching user credentials against database entries on page 12 and Path syntax on page 14 that say regarding the database key. The database key for the Home Directory database is <domain, user, path> and — in the case of multiple entries that match on <domain, user> — the matches are searched backward until an entry with a viable/matching path is found. This behavior enables users to be spread among multiple file systems.

Two options are available for spreading users among multiple file systems:

1. Create two or more entries where <domain, user> are identical between database entries, but <path> is different. This option requires caution when using the auto-create functionality.

2. Create two or more entries where only <domain> is identical between database entries, but <user> and <path> both differ between database entries. This option enables unrestricted use of the auto-create functionality.

To understand spreading users further, consider examples using the two MARKETING domain users from this paper’s examples. In this case, Joanna Smith and Mark Fodor will be on different file systems.

Table 12. Spreading users on different file systems

Full name Windows logon name Home Directory path

Joanna Smith MARKETING\jsmith /marketing1/jsmith

Mark Fodor MARKETING\mfodor /marketing2/mfodor

When <domain,user> values are identical between database entries

If the username and user domain must be identical across home directory entries, then (in most cases) it is necessary to create the home directories manually in the file systems. The auto-create feature will not produce the desired result.

The home directory database may look like the following:

Table 13. Example home directory entries


… … … …

MARKETING * /marketing2/ auto-create=no


A user would manually create the following directories in the marketing1 and marketing2 VNX file systems:

/marketing1/jsmith

/marketing2/mfodor

When Joanna Smith maps \\atlanta3\HOME, both entries will match her user domain and username. Recall that the Data Mover database search takes the last match and attempts to find the specified path. In this case, the last match has the path=/marketing1/. Since /marketing1/jsmith exists, no further search is needed. Joanna’s home directory will be /marketing1/jsmith.

When Mark Fodor maps \\atlanta3\HOME, both entries will match his user domain and username. The Data Mover will take the last match and try to find the specified path. In this case, the last match is the one with path=/marketing1/. Since /marketing1/mfodor does not exist, the Data Mover will look at the next-to-last match: path=/marketing2/. Since /marketing2/mfodor exists, no further search is needed. Mark’s home directory will be /marketing2/mfodor.

Given this description, it is not difficult to predict what would happen if auto-create were enabled on these database entries. The last match (the one with path=/marketing1/) is the first examined and with auto-create enabled the Data Mover would simply create a /marketing1/mfodor directory for Mark rather than processing the second-to-last match. This behavior would effectively put all users on the same file system (/marketing1), which is undesirable.

With that caution in mind, the creation of a third directory can be beneficial.

Table 14. Example directory structure to account for users without Home Directories


… … … …

MARKETING * /marketing3/ auto-create=yes



In this case, all users who do not have home directories pre-created on /marketing1 or /marketing2 will fall through to the third-to-last match. Home directories will automatically be created for them on /marketing3 if they do not already exist.

This approach is often the least convenient from an administrative perspective, but it is necessary when usernames lack specific string attributes that would allow them to be grouped into well-defined sets. Because this approach is perhaps the most difficult to understand, the experience of a real-world VNX customer is helpful:

Situation

A school has two sets of users: teachers and students. Both teachers and students log into the same Windows domain. Teachers receive much larger quota allocations than students, so their home directories are stored in a different path from the path for student home directories. There is no mechanism by which a teacher can be distinguished from a student when examining the username. What would the recommended home directory configuration look like?

Analysis

Perhaps the most important piece of information in the description of this customer’s situation is that there is no mechanism by which the username or domain can distinguish a student from a teacher. In other words, the <domain,username> portion of the Home Directory entry will be identical if multiple entries are required.

It is also clear that the user base must be distributed as groups across multiple file systems or across multiple paths within the same file system. As a result, multiple Home Directory entries are required, one for each distinct path.

Like most schools, the student-teacher ratio is fairly large at this school, 20 students for every one teacher (20:1). The following Home Directory configuration would perhaps be the most efficient configuration possible.

Table 15. Home Directory configuration for school example


… … … …

SCHOOL * /homedirs/students/ auto-create=yes

SCHOOL * /homedirs/teachers/ auto-create=no

Note that this configuration requires the administrator to manually create teacher home directories in the path /homedirs/teachers/. When a teacher logs in, her directory will be found by the first matching entry under the path /homedirs/teachers/.

When a student logs in, his directory will be not be found by the first matching entry (/homedirs/teachers/) because it does not exist there. Home Directory then will look at the second matching entry and will find the student’s home directory in the path /homedirs/students. If the student does not already have a home directory under /homedirs/students, then one will be created automatically because auto-create is enabled on the second matching entry. Thus, the administrator does not have to manually create home directories for students.

Since the student-teacher ratio is 20:1, the administrator needs only to manually create home directories for approximately 1/21 of the user base (the teachers). Should he forget to create a teacher’s home directory then the teacher will automatically be given a home directory in /homedirs/students. The administrator can later rectify the situation by simply moving that home directory to /homedirs/teachers.

When only <domain> is identical between database entries

Looking at an alternative approach reveals that, using the auto-create feature, it is possible to avoid manually creating home directories.

Assume that half of the users in the MARKETING domain have usernames beginning with one of the letters from the alphabetical set of letters “a” through “k.” The rest of the usernames begin with “l” through “z.” This fact would allow an administrator to put half of the users on /marketing1 and the other half on /marketing2 while also taking advantage of the auto-create functionality.

Such a home directory database might look like:

Table 16. Example auto-create for home directory database


… … … …

MARKETING [l-z].* /marketing2/ auto-create=yes, regexp=yes

MARKETING [a-k].* /marketing1/ auto-create=yes, regexp=yes

When Joanna Smith maps \\atlanta3\HOME, only the last of these entries will match her user domain and username. If this is her first time mapping the share, then the Data Mover will see that /marketing1/jsmith does not exist and will create it to use as Joanna’s home directory.

When Mark Fodor maps \\atlanta3\HOME, only the second to last of these entries will match his user domain and username. If this is his first time mapping the share, then the Data Mover will see that /marketing2/mfodor does not exist and will create it to use as Mark’s home directory.

This approach is often the most convenient, and it works best when the login names that comprise the user base have specific string attributes that allow them to be grouped into distinct sets. In this example, that attribute is the value of the first character of the username. Regular expressions can then be used to specify match criteria based upon these attributes.

Spreading users across two or more Data Movers

In certain scenarios, you may want to spread the home directory users of a single domain across more than one Data Mover or CIFS server as shown in Figure 10. Some of these scenarios include:


Performance— In domains with a large number of users or with heavy I/O loads, putting all home directory users on the same Data Mover may not be feasible from a performance standpoint. In this case, the I/O load can be spread across Data Movers by spreading the user base across those Data Movers.

Capacity— In environments where the individual user home directories are very large, it may be necessary to spread users across multiple backend storage systems that are connected to different VNX cabinets.

Location— In geographically distributed domains, it may be necessary to spread users across two or more Data Movers. Spreading users across Data Movers (and VNX cabinets) may allow for storing each user’s home directory data closer to the user’s physical location, thus providing the user with a higher level of network performance.

Billing/chargeback— Spreading users across two or more Data Movers may help to manage billing/chargeback. For example, if each department in the organization is charged internally for one Data Mover, it can be helpful to put the users of each department on the Data Mover it pays for.

Figure 10. Users can be spread across Data Movers by connecting them to different CIFS servers

Because each Data Mover and Virtual Data Mover has its own Home Directory database, the task of spreading users across two or more Data Movers is easy. Simply direct users to the correct Data Mover (via a CIFS server) when they attempt to map their home directory. This direction requires preparation to decide which Data Mover


each user should use and to ensure the user’s profile reflects the UNC path to that Data Mover.

Replicating Home Directory configurations

CIFS Replication (using Virtual Data Movers) can be used to replicate Home Directory environments between VNX cabinets. This replication can specify the amount of data change required between delta-set transfers. When the primary/source site is lost in a disaster or taken down for maintenance, the secondary site can be brought up with all Home Directory services functioning as before. In such an event, CIFS users will lose their CIFS sessions, but they will be able to reconnect to the same UNC path (for example, \\atlanta3\HOME) without realizing they are connecting to a different location. Figure 11 illustrates this replication technique.5

When using CIFS Replication with Home Directory, keep these best practices in mind:

Replicate between cabinets located in different geographic locations if the goal is to protect against site outages.

Ensure that the mount path of all replicated Home Directory user file systems is the same on both the source and destination Virtual Data Movers. If the mount path is different on the destination Virtual Data Mover, then the paths in the Home Directory database may be incorrect after failover.

Ensure that the CIFS server names used on the destination Virtual Data Mover are identical to those used on the source Virtual Data Mover.

Ensure that the network interface names used on the destination Virtual Data Mover are identical to those used on the source Virtual Data Mover. IP addresses can be different on the destination Data Mover.

5 EMC advises the testing of Home Directory replication plan prior to implementing it on production data.


Figure 11. CIFS Replication of Home Directory configuration

For more information on VDM Replication, please see the white paper titled Virtual Data Movers on EMC VNX located on EMC Online Support.

Migrating Home Directory configurations from VNX to VNX

VNX Home Directory configurations can be migrated easily to other VNX cabinets. Simply migrate the user file systems that contain the home directories and manually copy the homedir database to the new cabinet. This capability is particularly useful when upgrading a VNX cabinet or redistributing workload among VNX cabinets. Further, the use of VNX File System Migration (also known as CDMS) or other supported migration technologies when migrating Home Directory file systems will minimize end-user downtime.6

Migrating Home Directory configurations from another vendor’s array to VNX

Home Directory configurations on another vendor’s array can be migrated easily to a VNX array. With VNX for File OE version 8.1.3.72 or later, users can connect to a \\server\username[$] path which will direct them to their home directory. This capability allows home directories on other vendor’s arrays, which use this path mapping, to be migrated to VNX without extra configuration.

6 EMC advises you to test your Home Directory migration plan prior to implementing it on production data.


This capability is especially helpful in the case where the users have local applications, such as built in synchronization and embedded links. Those applications will not have to be manually updated on each individual user’s account after the migration. This capability is the same for shared network devices, such as scanners, printers, and fax devices.

Without this path mapping, manual remediation would be needed to modify each user’s configuration to a \\server\HOME path. Users will still be able to map to the traditional \\server\HOME path, though. As seen in Figure 12, users can connect to either \\server\HOME or \\server\username[$] to get to their home directory since both paths point to the same place.

Figure 12. User mechanism of connecting to VNX

The new \\server\username[$] home directory connections are enabled by default on VNX. The username support can be disabled using a registry called “UsernameSupported” on each VDM (Figure 13). Note that this registry can be set differently on each VDM. The registry is found through the following path: HKEY_LOCAL_MACHINE/Software/EMC/Homedir/UsernameSupported


Figure 13. Setting registry setting for username support on home directories

The following is a description of the two options that are available for the UsernameSupported registry:

0x0 — Disables the ability of Home Directories to be connected using the //server/username[$] path. Home Directories can still be connected using //server/HOME.

0x1(default) — Enables Home Directories to be connected by both //server/HOME and //server/username[$] paths.

File Extension Filtering and Quotas

File Extension Filtering blocks the creation of files on CIFS shares when the files have a prohibited extension. The Quotas feature allows you to control the total amount of storage that can be consumed by users and/or groups in a file system. Both the File Extension Filtering and the Quotas features can work seamlessly with Home Directory.

Consider a situation where the goal is to prevent creation of files with the .mp3 extension on \\atlanta3\HOME. To achieve this goal, the following file could be created:

\\atlanta3\HOME\c$\.filefilter\mp3@home@atlanta3

To prevent creation of .mp3 files on all HOME shares (for all CIFS Servers) on a Data Mover, the following file could be created:

\\atlanta3\HOME\c$\.filefilter\mp3@home


Conclusion VNX Home Directory feature can significantly ease the administrative pain of providing home directories for CIFS users. It eliminates the need to manually create and manage CIFS home directory shares, and it can also eliminate the need to manually create each user home directory.

Home Directory provides sufficient flexibility for you to implement highly customized rules based on regular expressions, and it may require only a few rules to spread all of your domain users over a single file system or several file systems. This flexibility makes it simple to scale your Home Directory implementation from hundreds to thousands or even tens of thousands of CIFS users.

Further, when Home Directory is combined with VDM Replication, a Home Directory environment can be seamlessly replicated to a remote site for disaster recovery. When combined with VNX File System Migration or other migration technologies, Home Directory environments can easily be migrated to other VNX cabinets.

With an understanding of the Home Directory concepts that were outlined in this white paper, you can create an efficient and effective home directory solution for your organization.

emc vnx home directory · 2 days ago · in the typical business environment, user home directories...

Documents