Multiprotocol Application Deployment Guide v0 2

Multiprotocol Application Application Deployment Guide for f or

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 copyr ight 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 Modification History Document Authorisation by Author Name/Title

Signature

Date

Arthur Wasiak

21/08/2012

Signature

Date

Signature

Date

Signature

Date

e: [email protected]

Document Authorisation by HDS Reviewer Name/Title

Document Authorisation by HDS Manager Name/Title

Document Authorisation by Customer Name/Title

Document Location Machine

File Name:

HDS Internal SharePoint Site

123456 - CompanyABC 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 t he Author. For HDS int ernal use only.

Version

Date

Name and Role

Details

0.1

08/09/2012

Arthur Wasiak, Technical Consultant

Initial Draft

0.2

21/08/2012

© Hitachi Data Systems 2012 21/08/2012

Added FS DACL Mode section and update A2U section with Mapping.

“-“

Hitachi Data Systems and CompanyABC Confidential 0.2

2


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

1.6

Objectives .......................................................................................................................................................................... 6

1.7

Scope .................................................................................................................................................................................. 6

Prime Contact .............................................................................................................................................. 6

1.8 Assumptions, Exclusions, Exclusions, Constraints and Dependencies ...................................................................................... 6

2

3

4

5

6

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

Application to Application Application Multipro Multiprotocol tocol .......................... ........................................ ........................... ....................... ..........12 3.1

Topology .......................................................................................................................................................................... 12

3.2

Permission Structure ..................................................................................................................................................... 12

3.3

Implementation Implementation Plan ..................................................................................................................................................... 13

Application to User Multiprotocol Multiprotocol .......................... ........................................ ............................ ............................ ..................... ....... 15 4.1

Topology .......................................................................................................................................................................... 15

4.2


4.3


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

5.1

Topology .......................................................................................................................................................................... 18

5.2


5.3


........................................ ............................ ............................ ..................... ....... 23 Appendix A: List of abbreviati abbreviations ons ..........................

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 © Hitachi Data Systems 2012 21/08/2012


3


Figure 5: A2A Permission Permission Structures ..................................................................................................................................................... 13 Figure 6: A2U Topology ........................................................................................................................................................................... 15 Figure 7: A2U Permission Structures Structures..................................................................................................................................................... 16 Figure 8: U2U Topology ........................................................................................................................................................................... 18 Figure 9: U2U Permission Architecture Architecture ................................................................................................................................................. 19 Figure 10: Common Software So ftware Repository Architecture Architecture ..................................................................................................................... 20

List of Tables No table of figures entries found.



4


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


1.4

Related Documents

This document should be read in conjunction with the following documents: »

1.5

Application MP Request Form

Customer’s Prime Contact

Name

Role

Contact Details

John Smith

Project Manager

+44 (0) 1234 567 890

1.6

Objectives »

»

1.7

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

Scope

The scope, for the purposes of this document is: »

Three broad categorisations of MP application topologies, A2A/A2U/U2U

1.8

Assumptions, Assump tions, Exclusions, Constraints and Dependencies

1.8.1

Assumptions

Key assumptions are: »

1.8.2

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.

Exclusions

Excluded from the scope are: »

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



6


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‘fs -dacl-mode’ 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 mask-on-chmod-discard-on-create

HNAS Directory Object Owner: Jane May Group: Domain Admins DACL Allow Group Domain User Full Control rol - inheritable Allow Group Domain Admins Full Control rol - inheritable

(1) Define DACL

Jane May AD Domain Admin

HNAS Directory Object Owner: Jane May Group: Domain Admins

Folder A

GID: 55555 UID: 44444 drwxrws---

DACL Allow Group Domain User Full Control - inheritable Allow Group Domain Admins Full Control - inheritable

(1) Define DACL


INHERIT INHERIT

Folder A DISCARD

HNAS Directory Object Owner: John Smith Group: Domain User

HNAS Directory Object Owner: Unix User/44444 Group: Unix Group/55555

(2) Create File A

DACL Allow Group Domain User Full Control Control - inheritable Allow Group Domain Admins Full Control rol - inheritable

John Smith Domain User File A


GID: 55555 UID: 44444 -rwxrws---

DACL Allow Current Group 55555 Full Control Allow Current User 44444 Full Control rol

(2) Create File A

Paul Kent Unix GID:55555 UID:44444

File A

GID: 55555 UID: 44444 -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 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


FS DACL Mode: mask-on-chmod-or-create HNAS Directory Object Owner: Jane May Group: Domain Admins DACL Allow Group Domain User Full Control - inheritable Allow Group Domain Admins Full Control - inheritable

(1) Define DACL


HNAS Directory Object Owner: Jane May Group: Domain Admins

Folder A


DACL Allow Group Domain User Full Control rol - inheritable Allow Group Domain Admins Full Control rol - inheritable

(1) Define DACL


INHERIT INHERIT

Folder A INHERIT

HNAS Directory Object Owner: John Smith Group: Domain User (2) Create File A

DACL Allow Group Domain User Full Control - inheritable Allow Group Domain Admins Full Control - inheritable

John Smith Domain User File A

GID: 55555 UID: 44444 -rwxrws---

HNAS Directory Object Owner: Unix User/44444 Group: Mapped Group DACL Allow Current Group 55555 Full Control Allow Current User 44444 Full Control rol Allow Group Domain User Full Control Control - inheritable Allow Group Domain Admins Full Control rol - inheritable

(2) Create File A

Paul Kent Unix GID:55555 UID:44444


File A

GID: 55555 UID: 44444 -rw-rw----

Figure 2: FS DACL Mode – Mode – Mask 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 ba sic 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 FS-DACL-mode command refers to ‘ masking-deny-aces’. 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 GI D allocation.



8


Application B Service Account

Application A Service Account Application A Windows

Application B Unix Read UID\GID

Create File

WITHOUT SET PRIMARY (POSIX)

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

Shared Folder


Application A Service Account

Application B Unix

Application A Windows Create File

Read UID\GID SID: < 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.o http://en.wikipedia.org/wiki/Umask rg/wiki/Umask



9


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-DACLMODEs change, set the umask to 0000 on the HNAS EVS:

2.4



umask-directory-set 0000



umask-file-set 0000

Creator Owner Permission Permissionss

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

: 0x3f = FileReadData/FileListDirectory | FileWriteData/FileAddFile | …

: 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



10


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:

rwx


rwx---


11


3 3.1

Application to Application Application Multiprotocol Topology

A2A MP applications utilise a shared folder for communication. This is demonstrated in the following figure, A2A Topology.


Application A Service Account Application A Windows

Application B 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


Other AD GRPs

Secondary GROUP

AD Administrative Users

Mapping AD GRP

PRIMARY GROUP

Application Service Account

Mapping AD GRP = Mapping UNIX GRP

Secondary GROUP

Mapping UNIX GRP

Application Service Account Secondary GROUP Secondary GROUP

Application UNIX GRP

Unix Administrative Users

Figure 5: A2A A2 A Permission Structures Structures

3.3

Implementation Implem entation 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\ “CORP\Domain Users” 8. Create NFS export to same location, with correct parameters a. E.g. EVS-AW:/vivolRoo EVS-AW:/vivolRoott 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


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


4 4.1

Application to User User Multiprotocol 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, users, if data is to be modified, then a local copy is taken.

Application A Service Account Application A Unix

Data Consumers Windows ro

rwx

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.

4.2


The A2U permission structure is illustrated in the following figure, A2U Permission Structures.



15


Read Only Access GRP

Secondary GROUP

Mapping AD GRP

User Group(s)

Mapping AD GRP = Mapping UNIX GRP

Secondary GROUP

UNIX GRP

Application Service Account Secondary GROUP Secondary GROUP

Application UNIX GRP

Unix Administrative Users

Figure 7: A2U Permission Structures

4.3

Implementation Implem entation Plan 1. Create or ensure AD Read Only Access Group exists a. E.g. CORP\ADApplicationROGroup 2. Create Application mapping group on UNIX server(s) a. E.g. unixappgrp [GID:55555] 3. Provision Storage, EVS, File System and virtual volume a. E.g EVS-AW, FS-AW, vivolRoot 4. Create CIFS Share to virtual volume a. vivolRoot share -> /FS-AW/vivolRoot 5. Define permissions on CIFS Share a. E.g. remove “everyone” and replace with RO with RO “CORP\ “CORP\Domain Users” 6. Create NFS export to same location, with correct parameters a. E.g. EVS-AW:/vivolRoo EVS-AW:/vivolRoott 7. If you need to reset the folder permissions to begin from the start, enter the EVS & FS then try: a. >cacls-del dacl vivolRoot 8. Before proceeding, enter the group level mapping. a. CORP\ADApplicationGroup = unixappgrp [GID:55555]



16


9. Apply the owner and group UNIX permissions a. chmod 770 vivolRoot b. chgrp unixappgrp vivolRoot c.


10. Now load additional permissions, such as full control for domain admins and Read Only for the AD Access group a. cacls-add dacl ace 1 type allow fullcontrol group "CORP\Domain Admins" flags fd vivolRoot cacls-add dacl ace 1 type allow read group "CORP\ADApplicationROGroup" flags fd vivolRoot 11. Check the permissions a. security-decode-file vivolRoot 12. 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



17


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.

Unix Users

Windows 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 f iles across iles across heterogeneous protocols.

5.2


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’ 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 © Hitachi Data Systems 2012 21/08/2012


18


“CORP\ “CORP\Domain User” in AD, “CORP\ “CORP \ApplicationGroupA” in filpr1 and “CORP\ “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 GROUP

User Group(s)

Other AD GRPs

Mapping AD GRP Mapping AD GRP = Mapping UNIX GRP

Mapping UNIX GRP

Secondary GROUP Secondary GROUP

Other 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


Windows Users

Unix Users

UPLOAD – FTP / SFTP / HTTP / HTTPS

rw

rx CIFS

Uploader Service Account

rx NFS

rwx Shared Folder

File Store Facility “Uploader App”

Figure 10: Common Software Repository Architecture

5.3

Implementation Implem entation Plan

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 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\ “CORP\Domain Users” Users” and “CORP\ “CORP\ADApplicationGroup” 8. Create NFS export to same location, with correct parameters a. E.g. EVS-AW:/vivolRoo EVS-AW:/vivolRoott © Hitachi Data Systems 2012 21/08/2012


20


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 10. Before proceeding, enter the group level mapping. a. CORP\ADApplicationGroup = unixappgrp [GID:55555] 11. Create primary group override a. E.g. primary-group-set "CORP\ADAppUser" "CORP\ADApplicationGroup" 12. Apply the owner and group unix permissions a. chmod 770 vivolRoot b. chgrp unixappgrp vivolRoot c.


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 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 15. Check the permissions a. security-decode-file vivolRoot 16. 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 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


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 virtual-volume add --ensure FS-AW2 vivolRoot /vivolRoot [email protected] virtual-volume virtual-volume list FS-AW2 F S-AW2 vivolRoot security-mode get -f FS-AW2 -i vivolRoot security-mode set -f FS-AW2 -i vivolRoot v ivolRoot 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 FS- AW2 vivolRoot vivolRoot nfs-export add -S disable -c "*(sec=sys,rw,anongid=0,anonuid=0)" "*(sec=sys,rw,anongid=0,anonuid=0)" -r - r disable vivolRoot FS-AW2 /vivolRoot nfs-export list vivolRoot cifs-share add add --ensure --snapshot-dirs --snapshot-dirs disable disable --noscanforviruses --comment "WO99999 - Arthur Arthur Wasiak" -cache-options 12 vivolRoot FS-AW2 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 fu llcontrol group "CORP\Domain Admins" flags fd vivolRoot cacls-add dacl ace 1 type allow fullcontrol who "Creator Owner" flags flags fd vivolRoot cacls-add dacl ace 1 type allow fu llcontrol group "EMEASC\ADApplicationGroup" "EMEASC\ADApplicationGroup" flags fd vivolRoot selectfs FS-AW2 cd /



22


6

Appendix A: List List of abbreviations abbreviations

Abbreviation

Definition

AD

Active Directory

ACE

Access Control Entry

ACL

Access Control List

CHAP

Challenge-Handshake 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 Adapter

HDS

Hitachi Hitac hi Data Systems

HNAS

High-Performance NAS

HDvM

Hitachi Device Manager

HTnM

Hitachi Tuning Manager

HSCS

Hitachi Storage Command Suite

LDAP

Lightweight Directory Access Protocol Protocol

LUN

Logical Unit Number

MIB

Management 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

Multiprotocol Application Deployment Guide v0 2

Recommend Documents