Multiprotocol Application Deployment Guide v0 2

Multiprotocol Application Deployment Guide for
CompanyABC
Prepared for: CompanyABC
Prepared by:
Version Number: 0.2
Reference Number: 123456
21/08/2012
© Hitachi Data Systems 2012 All trademarks are hereby acknowledged
This document contains intellectual property rights and copyright which are proprietary to Hitachi Data Systems. It is made a vailable only under
the specific terms of the license granted at the time of purchase. It is strictly forbidden to remove the copyright notice, or copy, distribute or
disclose the contents to third parties, in whole or in part, except under written license terms granted by Hitachi Data Systems.
Multiprotocol Application Deployment Guide: CompanyABC
Arthur Wasiak
Modification History
Document Authorisation by Author
Name/Title Signature Date
Arthur Wasiak <approved> 21/08/2012

e: Arthur.Wasiak@hds.com
Document Authorisation by HDS Reviewer

Document Authorisation by HDS Manager

Document Authorisation by Customer

Document Location
Machine File Name:
HDS Internal SharePoint Site 123456 - CompanyABC MP Guide v0 2.docx
CAVEAT
This document was developed as a result of real customer experiences and information received from interactions with the HDS BA engineers.
This document is provided ‘AS-IS’ without warranty. All solution herein should be fully tested and proven in a test environment before
deployment into mission critical production environments. It is assumed that the following is correct for 8.x releases, however subsequent HNAS
code releases may modify functionality and thus invalidate or enhance some solutions.
Document History
PLEASE NOTE: Before using this document, contact author to ensure accuracy and forward details of any engagement that utilise this
document. A copy of the VISIO diagrams used in this document can also be supplied by the Author. For HDS internal use only.
Version Date Name and Role Details
0.1 08/09/2012 Arthur Wasiak, Technical Consultant Initial Draft
Added FS DACL Mode section and update

0.2 21/08/2012 “-“
A2U section with Mapping.
© Hitachi Data Systems 2012 Hitachi Data Systems and CompanyABC Confidential
2
21/08/2012 0.2
Arthur Wasiak
Table of Contents
1 Introduction ............................................................................................................... 5
1.1 Background ....................................................................................................................................................................... 5
1.2 Topology ............................................................................................................................................................................ 5
1.3 Intended Audience .......................................................................................................................................................... 5
1.4 Related Documents ......................................................................................................................................................... 6
1.5 Customer’s Prime Contact .............................................................................................................................................. 6
1.6 Objectives .......................................................................................................................................................................... 6
1.7 Scope .................................................................................................................................................................................. 6
1.8 Assumptions, Exclusions, Constraints and Dependencies ...................................................................................... 6
2 Permission Principles................................................................................................. 7
2.1 FS-DACL-MODE ................................................................................................................................................................ 7
2.2 POSIX Primary Groups .................................................................................................................................................... 8
2.3 User Masks ........................................................................................................................................................................ 9
2.4 Creator Owner Permissions ......................................................................................................................................... 10
3 Application to Application Multiprotocol ............................................................... 12

3.1 Topology .......................................................................................................................................................................... 12
3.2 Permission Structure ..................................................................................................................................................... 12
3.3 Implementation Plan ..................................................................................................................................................... 13
4 Application to User Multiprotocol ........................................................................... 15

4.1 Topology .......................................................................................................................................................................... 15
5 User to User Multiprotocol ...................................................................................... 18

5.1 Topology .......................................................................................................................................................................... 18
6 Appendix A: List of abbreviations........................................................................... 23
List of Figures
Figure 1: FS DACL Mode default behaviour........................................................................................................................................... 7
Figure 2: FS DACL Mode – Mask on CHMOD or Create ...................................................................................................................... 8
Figure 3: AD POSIX Support for A2A via Primary Groups .................................................................................................................. 9
Figure 4: A2A Topology............................................................................................................................................................................ 12

3
21/08/2012 0.2
Arthur Wasiak
Figure 5: A2A Permission Structures ..................................................................................................................................................... 13
Figure 6: A2U Topology ........................................................................................................................................................................... 15
Figure 7: A2U Permission Structures..................................................................................................................................................... 16
Figure 8: U2U Topology ........................................................................................................................................................................... 18
Figure 9: U2U Permission Architecture ................................................................................................................................................. 19
Figure 10: Common Software Repository Architecture ..................................................................................................................... 20
List of Tables
No table of figures entries found.
4
21/08/2012 0.2
Arthur Wasiak
1 Introduction
The purpose of this document is to provide a solution for hosting the multi protocol application
environments on the HNAS NAS infrastructure.
1.1 Background
CompanyABC has commissioned Hitachi Data Systems to design and deploy a solution that will primarily
serve as a file serving environment.
As the existing infrastructure is on Netapp Filers, some consideration is required during migration of data.
Of particular note is that different mapping structures are employed by HNAS and Netapp Filers. These
include:
» HNAS provides a 1-to-1 mapping between users and groups

» HNAS does not map at a server level, rather at an EVS level
In light of these migration considerations and challenges, this document has been commissioned to
examine and resolve any issues arising from migrating and provisioning application to the HNAS.
1.2 Topology
Although the number of application architectures is potentially infinite, from a multi protocol perspective
they can loosely be categorised into 3 broad categories. These are introduced below.
» Application to Application (A2A): Two or more applications, residing on separate servers,
utilise a common shared storage area to pass requests, responses and statuses. A2A tend to
have specific service accounts.
» Application to User (A2U): One or more applications generate an output that is then
consumed by end users. A notable characteristic is that the end users are typically organised
into read only consumption groups.
» User to User (U2U): Two disparate groups require a common access area, where files are
stored in a common repository.
These three categories/topologies will be enumerated and detail in following sections
1.3 Intended Audience

In order to fully understand this document, the reader should have technical experience of storage and
NAS solutions. The document is intended for the following audiences:
» Technical Design Authorities/Technical Architects

» Storage Administrators
» Operating System support teams
» Application Support
5
21/08/2012 0.2
Arthur Wasiak
1.4 Related Documents

This document should be read in conjunction with the following documents:
» Application MP Request Form
1.5 Customer’s Prime Contact

Name Role Contact Details
John Smith Project Manager +44 (0) 1234 567 890
1.6 Objectives
» Create a standard process for storage configuration and implementation of multi-protocol
application environments (MP)
» Provide guidance on the type of information required to process a migration/provisioning
request for a MP environment
1.7 Scope
The scope, for the purposes of this document is:
» Three broad categorisations of MP application topologies, A2A/A2U/U2U
1.8 Assumptions, Exclusions, Constraints and Dependencies

1.8.1 Assumptions
Key assumptions are:
» Although this is document will provide a framework and generalised steps & commands, a
qualified HNAS administrator will be required to interpret the business requirements and
implement said requirements on HNAS infrastructure.
1.8.2 Exclusions
Excluded from the scope are:
» Specific application requirements (i.e. a specific section for Weblogic)
6
21/08/2012 0.2
Arthur Wasiak
2 Permission Principles
2.1 FS-DACL-MODE
Discretionary Access Control List (DACL) is an access control list that is controlled by the owner of an
object and that specifies the access particular users or groups can have to the object. Put simply, DACLs
are permissions that you can define on a file or folder, granting or denying access (be is read/write/modify
etc).
The default mode of the HNAS is to discard DACLs when a UNIX client creates a file or folder. This is
controlled by the command fs-dacl-mode.
When you enter ‘fs-dacl-mode’ the mode is displayed as:
File system DACL mode: mask-on-chmod-discard-on-create (masking-deny-aces enabled)
This results in the behaviour shown in the following diagram.
FS DACL Mode: mask-on-chmod-discard-on-create
HNAS Directory Object HNAS Directory Object

Owner: Jane May Owner: Jane May
Group: Domain Admins Group: Domain Admins
DACL DACL
Allow Group Domain User Full Control - inheritable Allow Group Domain User Full Control - inheritable
(1) Define DACL Allow Group Domain Admins Full Control - inheritable (1) Define DACL Allow Group Domain Admins Full Control - inheritable
GID: 55555 GID: 55555

Jane May UID: 44444 Jane May UID: 44444
drwxrws--- drwxrws---
AD Domain Admin Folder A AD Domain Admin Folder A
INHERIT DISCARD
Owner: John Smith Owner: Unix User/44444
Group: Domain User Group: Unix Group/55555
(2) Create File A
DACL DACL
(2) Create File A
Allow Group Domain User Full Control - inheritable Allow Current Group 55555 Full Control
Allow Group Domain Admins Full Control - inheritable Allow Current User 44444 Full Control
John Smith Paul Kent
Domain User GID: 55555 GID: 55555
UID: 44444 Unix GID:55555 UID: 44444
File A -rwxrws--- UID:44444 File A -rw-rw----
Figure 1: FS DACL Mode default behaviour
This default behaviour poses issues in multiprotocol environments where rich Windows ACLs need to be
inherited by child object, regardless if the object is created by a UNIX user or Windows user.
When a UNIX user creates a file/folder, despite the inheritance flag being set, to allow Domain Admins
access to child object, the HNAS will discard these permissions and replace them with ‘Current Owner’
‘Current Group’ UNIX style permissions. This is for legacy reasons, even though such issues can now be
avoided by utilising the correct FS-DACL-Mode.
To ensure correct inheritance of rich ACLs, the following should be set:
File system DACL mode: mask-on-chmod-or-create (masking-deny-aces disabled).
The result of enabling this mode is demonstrated in the following diagram.
7
21/08/2012 0.2
Arthur Wasiak
FS DACL Mode: mask-on-chmod-or-create

Owner: Jane May Owner: Jane May
Group: Domain Admins Group: Domain Admins
DACL DACL
Allow Group Domain User Full Control - inheritable Allow Group Domain User Full Control - inheritable
(1) Define DACL Allow Group Domain Admins Full Control - inheritable (1) Define DACL Allow Group Domain Admins Full Control - inheritable
GID: 55555 GID: 55555

Jane May UID: 44444 Jane May UID: 44444
drwxrws--- drwxrws---
AD Domain Admin Folder A AD Domain Admin Folder A
INHERIT INHERIT HNAS Directory Object
HNAS Directory Object Owner: Unix User/44444
Owner: John Smith Group: Mapped Group
Group: Domain User
(2) Create File A DACL
DACL Allow Current Group 55555 Full Control
(2) Create File A
Allow Group Domain User Full Control - inheritable Allow Current User 44444 Full Control
Allow Group Domain Admins Full Control - inheritable Allow Group Domain User Full Control - inheritable
John Smith Paul Kent Allow Group Domain Admins Full Control - inheritable
Domain User GID: 55555
UID: 44444 Unix GID:55555 GID: 55555
File A -rwxrws--- UID:44444 File A UID: 44444
-rw-rw----
Figure 2: FS DACL Mode – Mask on CHMOD or Create
Whilst the permissions will now carry across, note that the HNAS still performs an interpretation of the
permissions. This interpretation can cause some issues, as seen in the section Creator Owner Permissions,
but the basic effect is now that the ACLs are inherited and the ‘current owner/group’ UNIX notation is
added to the DACL, rather than substituted.
The last part of the FS-DACL-mode command refers to ‘masking-deny-aces’. This parameter was
introduced to fix the issue when UNIX client modifications lead to mid-ACL deny statements. Windows
Explorer expects that any deny entries are placed at the end of an ACL. Setting masking-deny-aces
disabled ensure the result ACLs are windows explorer friendly.
There are additional modes, and there may be use cases for them but they are outside the scope of this
document. The above recommendation should be sufficient to get multiprotocol inheritance to work as
expected.
2.2 POSIX Primary Groups

The windows permissions are achieved by loading the initial root folder with the required full inheritable
AD permissions. This will ensure the subsequent Windows files inherit these permissions.
There is one issue, if a new file is created, due to POSIX constraints of one user/one group, the Windows
Application service account must have its primary group defined as the of the Mapping AD Group. The
following figure explains that without a primary group set on the AD service account, it is not possible for
the POSIX style permissions (such as NFSv3 UNIX) by default to know which group should be defined in
the single GID allocation.
8
21/08/2012 0.2
Arthur Wasiak
Application A Application B
Service Account Service Account
Windows Unix
Read UID\GID
Create File
SID: <creator owner>
< group A> full control
< group B> full control
< group C> full control
…
UID: No mapping for user – set root
GID: WHICH GROUP?? – set root
(can be only one)
WITHOUT SET PRIMARY
(POSIX) Shared Folder
Application B
Application A
Service Account
Service Account
Windows Unix
Create File Read UID\GID
SID: <creator owner>

< group A> full control
< group B> full control #PRIMARY#
< group C> full control
…
UID: No mapping for user – set root
GID: Group B mapped to GID PRIMARY
WITH SET PRIMARY
(POSIX) Shared Folder
Figure 3: AD POSIX Support for A2A via Primary Groups
2.3 User Masks

User masks (umask) can have a significant impact on the creation of new folders and files if not correctly
managed.
umask is a command and a function in POSIX environments that sets the file mode creation mask of the
1
current process which limits the permission modes for files and directories created by the process .
If a user mask is set to 0007, that will ensure that new files will be set with a mode of: -rw-rw----
1
http://en.wikipedia.org/wiki/Umask
9
21/08/2012 0.2
Arthur Wasiak
If, however, the mask were set to 0022 the resultant mode would be -rw-r--r--, thereby granting the group
with only read access.
Similarly, the umask for directory and file creation can be defined on the HNAS via:
» umask-directory-set
» umask-directory-show
» umask-file-set
» umask-file-show
In the context of the MP setting being utilised, this will have little impact, but in case future FS-DACL-
MODEs change, set the umask to 0000 on the HNAS EVS:
 umask-directory-set 0000
 umask-file-set 0000
2.4 Creator Owner Permissions

A new owner directive is introduced in this document, that being the “creator owner”.
To reduce administrative overhead, and allow for reuse of accounts across multiple environments,
mapping of AD to UNIX accounts is performed at the group level.
With a group mapping in place, when a file is created from a CIFS connection, the resultant UNIX security
mode on the HNAS file system object is seen as the following:
Unix security:
UID : root (0) (failed to map from security descriptor owner CORP\ADAppUser
(S-1-5-21-34888-2291))
GID : unixappgrp (55555)
Mode: ---rwx---
As the GID has mapped across, the correct “rwx” is observed. There is no equivalent usermapping, so the
default of “---“ is applied.
Problems arise when a UNIX user then modifies the file. Because the ACL needs to be reassessed, and the
user permissions are defined as “---“ or ‘no access’, an implicit DenyACE is inserted, forbidding the user
from accessing their own file. Clearly, this is not ideal.
ACE:
Type : AccessDeniedACEType
Flags : 0x0
Size : 24
Mask : 0x3f = FileReadData/FileListDirectory | FileWriteData/FileAddFile | …
SID : BUILTIN\Current Owner (S-1-5-32-21061)
To avoid such misinterpretation in a simplified user administration model, we introduce explicit owner
access permission such as:
» cacls-add dacl ace 1 type allow fullcontrol who "Creator Owner" flags fd <folder>
10
21/08/2012 0.2
Arthur Wasiak
The resultant UNIX mode will therefore be:

Unix security:
UID : root (0) (failed to map from security descriptor owner CORP\ADAppUser
(S-1-5-21-34888-2291))
GID : unixappgrp (55555)
Mode: rwxrwx---
11
21/08/2012 0.2
Arthur Wasiak
3 Application to Application Multiprotocol

3.1 Topology
A2A MP applications utilise a shared folder for communication. This is demonstrated in the following
figure, A2A Topology.
Application B
Application A
Service Account
Service Account
Windows UNIX
rwx rwx
Shared Folder
Figure 4: A2A Topology

To ensure both sides can access the common space, both UNIX UserID\GroupID [UID\GID] and Active
Directory [AD] security identifiers [SID] need to be defined.
As the application access is a known quantity, these permission can either explicitly define groups or
individuals to have access.
3.2 Permission Structure

The A2A permission structure is illustrated in the following figure, A2A Permission Structures.
12
21/08/2012 0.2
Arthur Wasiak
Secondary Other
GROUP
AD GRPs
AD Administrative
Users
PRIMARY Mapping
GROUP AD GRP
Application Service
Account
Mapping AD GRP =
Mapping UNIX GRP
Secondary Mapping
GROUP UNIX GRP
Application Service
Account
Secondary
GROUP
Secondary Application
GROUP UNIX GRP
Unix Administrative Users
Figure 5: A2A Permission Structures
3.3 Implementation Plan

1. Create or ensure AD Mapping Group exists
a. E.g. CORP\ADApplicationGroup
2. Create or ensure Application service account exists
a. E.g CORP\ADAppUser
3. Confirm primary group for service account is set to mapping group
a. E.g. CORP\ADAppUser -> PRIMARY -> CORP\ADApplicationGroup
4. Create Application mapping group on UNIX server(s)
a. E.g. unixappgrp [GID:55555]
5. Provision Storage, EVS, File System and virtual volume
a. E.g EVS-AW, FS-AW, vivolRoot
6. Create CIFS Share to virtual volume
a. vivolRoot share -> /FS-AW/vivolRoot
7. Define permissions on CIFS Share
a. E.g. remove “everyone” and replace with full RW “CORP\Domain Users”
8. Create NFS export to same location, with correct parameters
a. E.g. EVS-AW:/vivolRoot
9. If you need to reset the folder permissions to begin from the start, enter the EVS & FS then try:
a. >cacls-del dacl vivolRoot
13
21/08/2012 0.2
Arthur Wasiak
10. Before proceeding, enter the group level mapping.

a. CORP\ADApplicationGroup = unixappgrp [GID:55555]
11. Apply the owner and group unix permissions
a. chmod 770 vivolRoot
b. chgrp unixappgrp vivolRoot
c. chmod g+rws vivolRoot
12. Load the required CREATOR OWNER dacl
a. cacls-add dacl ace 1 type allow fullcontrol who "Creator Owner" flags fd vivolRoot
13. Now load additional permissions, such as full control for domain admins and the AD mapping
group
a. cacls-add dacl ace 1 type allow fullcontrol group "CORP\Domain Admins" flags fd
vivolRoot
cacls-add dacl ace 1 type allow fullcontrol group "CORP\ADApplicationGroup" flags fd
vivolRoot
14. Check the permissions
a. security-decode-file vivolRoot
15. Migrate the existing data across via standard CIFS or NFS migration methodologies
a. Note: If rich AD permissions are in use, use the CIFS migration tools
b. To ensure of sub-directories have the correct group set post migration, you can use the
following commands from the UNIX client:
i. chgrp -Rv unixappgrp /mnt/nfs/vivolRootMount/
ii. chmod -R 770 * <- note that this will also define the owner as current user
14
21/08/2012 0.2
Arthur Wasiak
4 Application to User Multiprotocol

4.1 Topology
A2U MP applications use a common storage as an output to provide a common storage for a broad group
of users. Whereas A2A has clearly defined access entities, A2U topologies only have a specific account
generating the consumable data, whilst the users can belong to one or more groups.
Additionally, as seen in the following figure, the consumers only require read access. Although no group
mapping for access is required, for the correct behaviour of inheritance an AD group must still be mapped
(even if empty) for the UNIX side permissions to carry down. For read-only users, if data is to be modified,
then a local copy is taken.
Application A
Service Account
Application A
Unix Data Consumers
Windows
rwx ro
Shared Folder
Figure 6: A2U Topology

A2U topology will generally have the content generated via a UNIX server, as most user desktops are
Windows Workstations. If the server and users were both utilising Windows, then the use case would not
be considered multi-protocol and easily managed by conventional permission structures.

The A2U permission structure is illustrated in the following figure, A2U Permission Structures.
15
21/08/2012 0.2
Arthur Wasiak
Secondary Read Only

GROUP
Access GRP
User Group(s)
Mapping
AD GRP
Mapping AD GRP =
Mapping UNIX GRP
Secondary
GROUP UNIX GRP
Application Service
Account
Secondary
GROUP
Secondary Application
GROUP UNIX GRP
Unix Administrative Users
Figure 7: A2U Permission Structures

1. Create or ensure AD Read Only Access Group exists
a. E.g. CORP\ADApplicationROGroup
a. E.g. remove “everyone” and replace with RO “CORP\Domain Users”
16
21/08/2012 0.2
Arthur Wasiak
9. Apply the owner and group UNIX permissions

10. Now load additional permissions, such as full control for domain admins and Read Only for the AD
Access group
vivolRoot
cacls-add dacl ace 1 type allow read group "CORP\ADApplicationROGroup" flags fd
vivolRoot
17
21/08/2012 0.2
Arthur Wasiak
5 User to User Multiprotocol

5.1 Topology
U2U MP applications provide potentially the greatest challenges, as two non-specific groups require
common rwx access to shared folders.
Windows Users Unix Users
rwx rwx
Shared Folder
Figure 8: U2U Topology

Whilst the figure demonstrates two groups accessing a common area, the reality is that numerous groups may be
required to have common access to each other’s files across heterogeneous protocols.

The U2U permission structure is illustrated in the following figure, U2U Permission Structures.
Some practical concessions may need to be adopted, primary on the topic of Primary Groups in AD.
If all users can be have their primary group defined to a specific primary group, then all windows user
‘creates’ will have a single group associated to a mapped group. This mapped group directly translates to
a UNIX mapped group, thus allowing Windows <=> UNIX file modification.
A major problem with this approach is that for a specific account, only one primary group can be defined.
So if the user needs access to two separate U2U applications, the same group needs to be reused, thus
granting disparate groups the same access, which is likely to result in security violations.
Two methods to increase granularity are:
1. Perform primary group overrides
2. Use different accounts for each application
Understandably, using a separate account for each application instance leads to increase user
administration and confusion.
Using the primary group override allows the administrator to define, on an EVS basis, what primary group
should be defined when a file or folder is created. If the user had a primary group defined as
18
21/08/2012 0.2
Arthur Wasiak
“CORP\Domain User” in AD, “CORP\ApplicationGroupA” in filpr1 and “CORP\ApplicationGroupB” in filpr3,

then three separate context-aware groups could be used. Membership to more U2U groups would
warrant additional HNAS EVS’s.
Secondary Other
GROUP
AD GRPs
User Group(s)
Mapping
AD GRP
Mapping AD GRP =
Mapping UNIX GRP
Mapping
UNIX GRP
Secondary
GROUP
Secondary Other
GROUP UNIX GRPs
User Group(s)
Figure 9: U2U Permission Architecture
Alternatively, we can examine what the scenario is attempting to achieve. The classic scenario is a
common software repository, where application and build data is stored for reuse across numerous
servers, operating systems and applications.
Given a common software repository, one approach would be to utilise a content management solution,
which allows groups to upload via an application interface such as a web form uploader. The application
can run under the service account, mirroring the A2U topology. Once uploaded, the data is then available
to be mounted or connected to by external servers and can be presented in a read-only mode. This is
demonstrated in the following figure, Common Software Repository.
19
21/08/2012 0.2
Arthur Wasiak
Windows Users Unix Users

UPLOAD – FTP / SFTP / HTTP / HTTPS
rw rx rx
CIFS NFS
Uploader rwx
Service Account
Shared Folder
File Store Facility
“Uploader App”
Figure 10: Common Software Repository Architecture

For the purposes of the implementation plan we will look at the steps to grant two groups common
access, using the primary group override.
1. Create or ensure AD Mapping Group exists
a. E.g. CORP\ADApplicationGroup
2. Create or ensure AD user account exists
a. E.g CORP\ADAppUser
3. Confirm primary group for AD user account is not set to the mapping group
a. E.g. remove “everyone” and replace with full RW “CORP\Domain Users” and
“CORP\ADApplicationGroup”
20
21/08/2012 0.2
Arthur Wasiak
11. Create primary group override
a. E.g. primary-group-set "CORP\ADAppUser" "CORP\ADApplicationGroup"
12. Apply the owner and group unix permissions
13. Load the required CREATOR OWNER dacl
a. cacls-add dacl ace 1 type allow fullcontrol who "Creator Owner" flags fd vivolRoot
14. Now load additional permissions, such as full control for domain admins and the AD mapping
group
vivolRoot
cacls-add dacl ace 1 type allow fullcontrol group "CORP\ADApplicationGroup" flags fd
vivolRoot
Please note: As this scenario utilises the primary group override [Step 11 above], such a setting would
need to be defined for each user in this environment, e.g.
» primary-group-set "CORP\john.smith" "CORP\ADApplicationGroup"
» primary-group-set "CORP\peter.griffin" "CORP\ADApplicationGroup"
» primary-group-set "CORP\jane.jones" "CORP\ADApplicationGroup"
» primary-group-set "CORP\lisa.simpson" "CORP\ADApplicationGroup"
21
21/08/2012 0.2
Arthur Wasiak
5.3.1 Indicative Command Set Procedure

The following command set was used to effectively deploy U2U vivol in the testbed environment:
 evs-select 5
 virtual-volume add --ensure FS-AW2 vivolRoot /vivolRoot arthur.wasiak@hds.com
 virtual-volume list FS-AW2 vivolRoot
 security-mode get -f FS-AW2 -i vivolRoot
 security-mode set -f FS-AW2 -i vivolRoot mixed
 security-mode get -f FS-AW2 -i vivolRoot
 quota add --usage-limit 5G --usage-warn 75 --usage-critical 85 --generate-events yes FS-AW2 vivolRoot
 quota list --verbose FS-AW2 vivolRoot
 nfs-export add -S disable -c "*(sec=sys,rw,anongid=0,anonuid=0)" -r disable vivolRoot FS-AW2 /vivolRoot
 nfs-export list vivolRoot
 cifs-share add --ensure --snapshot-dirs disable --noscanforviruses --comment "WO99999 - Arthur Wasiak" --
cache-options 12 vivolRoot FS-AW2 \vivolRoot
 cifs-share list -v vivolRoot
 cifs-saa list vivolRoot
 cifs-saa delete vivolRoot everyone
 cifs-saa add vivolRoot "EMEASC\Domain Users" af
 group-mappings-add --unix-name unixappgrp --unix-id 55555 --nt-name ""EMEASC\ADApplicationGroup""
 chmod 770 vivolRoot
 chgrp unixappgrp vivolRoot
 chmod g+rws vivolRoot
 cacls-add dacl ace 1 type allow fullcontrol group "CORP\Domain Admins" flags fd vivolRoot
 cacls-add dacl ace 1 type allow fullcontrol who "Creator Owner" flags fd vivolRoot
 cacls-add dacl ace 1 type allow fullcontrol group "EMEASC\ADApplicationGroup" flags fd vivolRoot
 selectfs FS-AW2
 cd /
22
21/08/2012 0.2
Arthur Wasiak
6 Appendix A: List of abbreviations

Abbreviation Definition
AD Active Directory
ACE Access Control Entry
ACL Access Control List
CHAP Challenge-Handshake Authentication Protocol
CIFS Common Internet File system
CNS Clustered Namespace
DFS Distributed File system
DNS Domain Naming System
EVS Enterprise Virtual Server
FC Fibre Channel
Ge Gigabit Ethernet
Gbps Gigabit per second
HBA Host Bus Adapter
HDS Hitachi Data Systems
HNAS High-Performance NAS
HDvM Hitachi Device Manager
HTnM Hitachi Tuning Manager
HSCS Hitachi Storage Command Suite
LDAP Lightweight Directory Access Protocol
LUN Logical Unit Number
MIB Management Information Base
NDMP Network Data Management Protocol
NFS Network File system
NIC Network Interface Card
NTP Network Time Protocol
RAID Redundant Array of Independent Disks
RPM Rotations per Minute
SAN Storage Area Network
SAA Share Access Authentication
SAS Serial Attached SCSI
SATA Serial ATA
SID Security Identifier
SMB Service Message Blocks
SMTP Simple Mail Transfer Protocol
SMU System Management Unit
SNMP Simple Network Management Protocol
23
21/08/2012 0.2

Multiprotocol Application Deployment Guide v0 2

Uploaded by

Document Information

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

Multiprotocol Application Deployment Guide v0 2

Uploaded by

Copyright:

Available Formats

Multiprotocol Application Deployment Guide for

Prepared for: CompanyABC

Version Number: 0.2

Reference Number: 123456

© Hitachi Data Systems 2012 All trademarks are hereby acknowledged

Arthur Wasiak <approved> 21/08/2012

Document Authorisation by HDS Reviewer

Document Authorisation by HDS Manager

Document Authorisation by Customer

HDS Internal SharePoint Site 123456 - CompanyABC MP Guide v0 2.docx

Version Date Name and Role Details

0.1 08/09/2012 Arthur Wasiak, Technical Consultant Initial Draft

Added FS DACL Mode section and update

3 Application to Application Multiprotocol ............................................................... 12

4 Application to User Multiprotocol ........................................................................... 15

5 User to User Multiprotocol ...................................................................................... 18

6 Appendix A: List of abbreviations........................................................................... 23

Figure 2: FS DACL Mode – Mask on CHMOD or Create ...................................................................................................................... 8

Figure 3: AD POSIX Support for A2A via Primary Groups .................................................................................................................. 9

Figure 4: A2A Topology............................................................................................................................................................................ 12

Figure 5: A2A Permission Structures ..................................................................................................................................................... 13

Figure 6: A2U Topology ........................................................................................................................................................................... 15

Figure 7: A2U Permission Structures..................................................................................................................................................... 16

Figure 8: U2U Topology ........................................................................................................................................................................... 18

Figure 9: U2U Permission Architecture ................................................................................................................................................. 19

Figure 10: Common Software Repository Architecture ..................................................................................................................... 20

» HNAS provides a 1-to-1 mapping between users and groups

1.3 Intended Audience

» Technical Design Authorities/Technical Architects

1.4 Related Documents

» Application MP Request Form

1.5 Customer’s Prime Contact

John Smith Project Manager +44 (0) 1234 567 890

1.8 Assumptions, Exclusions, Constraints and Dependencies

» Specific application requirements (i.e. a specific section for Weblogic)

When you enter ‘fs-dacl-mode’ the mode is displayed as:

File system DACL mode: mask-on-chmod-discard-on-create (masking-deny-aces enabled)

This results in the behaviour shown in the following diagram.

FS DACL Mode: mask-on-chmod-discard-on-create

HNAS Directory Object HNAS Directory Object

GID: 55555 GID: 55555

Figure 1: FS DACL Mode default behaviour

To ensure correct inheritance of rich ACLs, the following should be set:

File system DACL mode: mask-on-chmod-or-create (masking-deny-aces disabled).

The result of enabling this mode is demonstrated in the following diagram.

FS DACL Mode: mask-on-chmod-or-create

HNAS Directory Object HNAS Directory Object

GID: 55555 GID: 55555

Figure 2: FS DACL Mode – Mask on CHMOD or Create

2.2 POSIX Primary Groups

Create File Read UID\GID

SID: <creator owner>

Figure 3: AD POSIX Support for A2A via Primary Groups

2.3 User Masks

2.4 Creator Owner Permissions

The resultant UNIX mode will therefore be:

3 Application to Application Multiprotocol

Figure 4: A2A Topology

3.2 Permission Structure

Figure 5: A2A Permission Structures

3.3 Implementation Plan

10. Before proceeding, enter the group level mapping.

4 Application to User Multiprotocol

Figure 6: A2U Topology