2010-05-14 01:37 PM
Does anyone have some suggestions on how best to configure multi-protocol file access for a new NetApp environment that is replacing an EMC Celerra? My client is moving about 24 TB from a Celerra to a NetApp V-series. There is some dedicated NFS data and CIFS data but the majority of data is accessed by both CIFS and NFS clients.
With the Celerra, we used the "NATIVE" access-checking policy for multi-protocol access. "NATIVE" mode means that the Celerra handles two separate sets of permissions for the same files and directories--one set for NTFS and one for Unix. NFS permissions have no affect on CIFS clients and vice versa.
We're now trying to determine the best way to configure the NetApp for this multiprotocol environment. Since ONTAP can't mimic the Celerra NATIVE behavior, our only options seem to be to 1) use NTFS security style and map users or 2) go with "mixed" security style. We'd like to avoid mixed security on vols/qtrees since NetApp has recommended against it in recent years and it's an administrative headache.
However, mapping users is a tremendous undertaking as well. As I see it, we're talking about looking at every unix client and application, understanding what user needs to access what NFS data, configuring Unix-to-AD mapping of some sort, and setting appropriate NTFS ACLs to accommodate that access.
We do have LDAP setup for authenticating Unix clients against AD using Vintela Authentication Services, as described in Netapp KB9264. With LDAP, we should be able to simply create the Unix users (e.g. "oracle") in AD and use that rather than relying on a complex usermap.cfg file. However, we'll still need to set file-level ACLs on all the necessary files for every user.
The only thing I see that may simplify this is if we can somehow harness the Celerra's user and group mapping files for a scripted deployment. We can download those from the Celerra management interface. Each file has entries similar to this:
S-1-5-15-28123bcf-3f2354db-6e564c54-1041:*:73215:32768:user abc7578 from domain _history_sid_range_:/usr/S-1-5-15-28123bcf-3f2354db-6e564c54-1041:/bin/sh
These files are very large (over 40,000 lines for the user file and 8300 lines for the group file) and I'm not really sure how to begin using them. Any suggestions are appreciated.
2010-05-14 11:11 PM
If the user names are the same, mapping will work without a usermap.cfg entry. Are they the same? Mixed mode is quite a headache and if both windows and unix update permissions it really is not fun to manage.
2010-05-15 12:08 PM
As I see it, we're talking about looking at every unix client and application, understanding what user needs to access what NFS data,
I am not sure I quite understand it. Every file on NFS share has well defined permissions which do not depend on who is accessing this file. These permissions can be fetched and converted alongside with copying file itself. It is relatively straightforward to generate Windows ACLs from Unix mode bits once user mapping issue is resolved.
The files you downloaded are from internal usermapper service. Every user on Celerra must have Unix UID and GID. For CIFS users mapping can either be configured manually, or as a last resort usermapper generates them automatically. So this database likely contains random UID for every Windows user ever accessing your Celerra; but it does not contain anything directly related to file permissions. It could be useful to find out which Windows user owns file in case file owner comes from CIFS side.
2010-05-17 07:22 AM
Thank you everyone for the responses.
The core problem we're trying to address is how to map Unix permission mode bits to NTFS ACLs. The Celerra's NATIVE access-checking policy keeps separate Unix and NTFS permissions, so even if there is a Unix->Windows account mapping in place and NTFS ACLs on a file structure, Unix users accessing NFS exports use Unix security instead.
On a NetApp qtree with NTFS security, on the other hand, there are no Unix permissions--only NTFS ACLs. Therefore, we need to replicate the old Unix permissions as equivalent NTFS ACLs.
For example, we have a user oracle@unix with data on Celerra accessed via NFS. The same data is also accessed by AD users via CIFS. The Celerra's NATIVE access-checking policy maintains 1) Unix mode bits for oracle's UID/GID and 2) NTFS ACLs for AD users. As I understand it, even if there is an "oracle" user in AD, the AD account is not used for file access-checking via NFS when oracle@unix accesses the data.
Here are a few additional points of clarification on our environment:
This is the migration process we've settled on:
Following step 2 above, Unix hosts see normal Unix permissions on the destination (NetApp) NFS export. These permissions mirror the original copy
on the source as you would expect (e.g "rwxr-x---".
Following step 3 above, there is no change in the Unix permissions
Following step 4 above, Unix hosts see either NO permissions ("---------") or ALL permissions ("rwxrwxrwx") depending on whether the Unix user is not mapped or is mapped to an AD account. Neither of these are desirable, as we'd like the Unix user to see something more closely approximating the original Unix permissions.
So, if it's relatively straightforward to generate Windows ACLs from Unix mode bits, then that's what we need.
2010-06-02 08:50 AM
To wrap up this discussion, here's what we ended up doing.
A few additional notes:
Thanks again to those who provided input.