Query regarding mixed mode security and CIFS folder permissions

[#1]

Hi,

We have two filers in our current setup:

1. FAS 270c cluster pair

Currently, we are using the FAS 270c filers for two main purposes: 1. Home directories for users 2. Department shares for various departments

The iscsi LUNs from these filers are mounted on a windows server and both "Home directories" and "department shares" are accessed by various

users by browsing the appropriate share on the windows server. File and folder permissions are completely set on the windows server.

Both the filers and windows server are in a AD domain.

2. FAS 3040 cluster pair (Joined to AD domain)

We are planning to migrate the "Home directories" and "Department shares" to 3040 filers in the following fashion:

     a. Home directories

          1. Create a Mixed mode qtree on the filer

          2. Migrate the home directories from the 270c filers to 3040 filers

          3. Advertise the new filers shares, so that various clients (windows and unix) can access their respective home directories

          Windows and Mac clients to use CIFS for accessing these shares

          Linux clients to use NFS for accessing these shares

          I have few quick questions in this regard:

          1. What are the best practises to set folder permissions, so that both windows and unix clients can access the home directories with out any issues.

          2. When various clients (windows and unix) access the respective home directories and tries to change the folder permissions (via CIFS and Unix),

              how does Netapp filers, compute the file and folder permissions? I have read several documents available in Netapp website, but couldn't find an

               appropriate one that explains the file and folder permissions in detail for a Mixed mode qtree.

          Though, I experimented a bit with folder permissions, the results were mixed - so I am looking for suggestions from experts.

     b. Department shares

          Can we set complex folder permissions (like controlling access based on AD groups) for different folders shared by the filers via CIFS? For example:

          We will share a qtree (with NT permissions)

          Set different permissions for differnet AD groups and/or users for different folders present under this share - Is this possible?

Sorry for the lengthy query. Thanks in advance.

Thanks,

Satish

[#2]

Any updates??

[#3]

Hi Satish,

Have you checked this TR http://media.netapp.com/documents/tr-3771.pdf ? Hope this should give you the answers to your queries.

Thanks

Daniel

[#4]

Hi Daniel,

Thanks for the link. I checked this doc. But, I am not clear about few things I am looking for.

If I understand correctly, managing the storage systems in Active Directory environment can be controlled in the similar fashion as we control other network resources.

But, I am looking at managing only few things within the Netapp filer based on Active Directory group permissions. For example:

1. I create a new CIFS share in Netapp Filer. How do I restrict access to share based on Active Directory group memberships (RW access to "abc" group, RO access to "xyz" group etc.).

2. Let's say we are supporting CIFS home directory shares. Once the basic configuration is completed, users can access their own home directories. Now, How do I grant permissions

    to individual CIFS home directories based on Active Directory Group memberships (RW access to "abc" group etc.) - AD group to get access other than the owner.

Also, if you could point me the best practises for the following it would be great.

In a Mixed mode qtree:

1. What are the best practises to set folder permissions, so that both windows and unix clients can access the home directories with out any issues.

2. When various clients (windows and unix) access the respective home directories and tries to change the folder permissions (via CIFS and Unix),

    how does Netapp filers, compute the file and folder permissions? I have read several documents available in Netapp website, but couldn't find an

    appropriate one that explains the file and folder permissions in detail for a Mixed mode qtree.

I am sorry if these stuff have already been covered in some document, but I didn't find the answers for the questions I am looking for.

Thanks,

Satish

[#5]

Hi Satish,

Sorry about the delay in responding to this query. First thing first, I'd like to clarify for the MIXED qtrees, you don't need to set the "MIXED" style just because the users are trying to access their files from UNIX and Windows both sides. You need MIXED only in the case you'd need to manage and change the permissions from both sides.

I'd still recommend not to set it to MIXED, unless you really have a pressing need and/or you fully understand how to manage the MIXED security style environments.

1. If possible, within the MIXED style filesystem, isolate the folders which are mostly going to be accessed and managed from the Windows users and set the NTFS ACLs for them. Similarly any other folders which are going to be heavily accessed and managed by the UNIX users, then set the permissions to be the UNIX permissions.

2. If the users are changing the permissions from Windows side at one time and changing it from UNIX side at another time... NetApp filers are going to keep only one set of the permissions active at any given time. e.g., if some UNIX user is trying to access the filesystem and there are NTFS ACLs active at that point, filers compute the UNIX mode bits based on the currently active NTFS permissions and offer that to the UNIX user and vice-versa.

For the details on understanding, how the multiprotocol really works with NetApp systems, I'd recommend the TR-3490.

For your first two question on the permissions for the CIFS shares, you don't need to use the UNIX style RW or RO permissions, those are generally used for the UNIX groups. You can very well use the full control, change, read type of the CIFS share level permissions for the Windows AD groups. After that you can restrict further with more granular permissions at the folder level using the NTFS ACLs.

For home dirs, I'd suggest to check the admin guides on the NOW site for the complete configuration, as you don't need to create one share per user's homedir. You just need to share out the higher level homedir container (volume or qtree) and then create the users' dir underneath and set the individual NTFS ACLs and ownership for each user on their respective folders using Windows Explorer.

I hope I answered all your questions, let me know if still any.

Thanks,
Reena

[#6]

Hi Reena,

Thank you very much for the descriptive explanation. It cleared few of my doubts. I am still left with few more questions.

For your first two question on the permissions for the CIFS shares, you don't need to use the UNIX style RW or RO permissions, those are generally used for the UNIX groups. You can very well use the full control, change, read type of the

CIFS share level permissions for the Windows AD groups. After that you can restrict further with more granular permissions at the folder level using the NTFS ACLs.

1. Well, sorry for the confusion; When I mentioned RW/RO, I actually meant setting some permissions (not exactly Unix style perms). Back to my questions on CIFS share level permissions:

How can we set "CIFS share level permissions based on windows AD groups" on the Netapp filer? I tried a test command, but looks like it was expecting local unix group. Please fill me in

if I am missing something.

     filer> cifs access testvol2$ -g AD-group "full control"
     Unknown Unix group AD-group

2. I created a test volume and test qtree (Mixed mode security style). Created couple of test home directories. Exported this volume using NFS and mounted using NFSv3 on an adminstrative

host and set the ownership and permissions for the test home directories.

     a. From a NFS client (Linux machine), permissions and ownership looks good.

     b. But from a CIFS client (Mac machine), permissions and ownership look strange. They look as mentioned below. This is bit confusing.

     From NFS client (Linux machine)

     ls -ld /mnt/filer/testuser (Home directory root folder)

     drwx--x--x 8 testuser staff 4096 2009-11-06 18:43 /mnt/filer/testuser

     ls -l /mnt/filer/testuser/file1 (A file present under the root folder)
     ---------- 1 testuser staff 600 2009-08-31 10:54 /mnt/filer/testuser/file1 (Edits to this file from NFS client are denied as expected from perms)

     From CIFS client (Mac machine)

     ls -ld /mnt/filer/testuser
     drwxrwxrwx+ 1 testuser  DOMAIN\domain users  16384 Nov  6 18:43 /mnt/filer/testuser

     ls -l /mnt/filer/testuser/file1
     -rwxrwxrwx+ 1 testuser  DOMAIN\domain users  600 Aug 31 10:54 /mnt/bang/file1 (Edits to this file from CIFS client are also denied but the perms look very confusing)

3. In the example scenario mentioned in the above point, if we were to set NTFS ACLs (owner - full control) on a Home directory by logging in as a "Domain Admin" in a Windows server (which is in the domain), I would assume in this case that filer computes the Unix permissions as well (based on the NTFS ACLs). But, I tested for few directories. The Unix permissions were just shown as "root:daemon" (for owner:group) and 700, though the individual owners have "Full control" on their respective home directories.

Am I doing something wrong? If yes, what is the proper way to set the ownership and perms on a Home directory?

Based on my testing: a. If we set the Unix permissions, they weren't looking consistent when accessed via CIFS.

                                   b. If we set the NTFS ACLs, they weren't looking consistent when accessed via NFS.

Thanks,

Satish

[#7]

Hi Satish,

For # 1, you are using the "-g" switch which is used mostly for the unix groups. For giving access to the Windows groups, you can just specify the domain\groupname and the type of access with it.

For #2 & #3, what you are seeing is just the display of the permissions like that, actually I have generally seen it showing correctly. Some possible issues I can think of, if you don't have that user account existing on the other side... also check if there's any /etc/passwd file on the filer as well, generally you should keep one.

How about actually testing the access with these homedirs ? Does it work fine as expected ? Also any specific reason why you wanted to choose MIXED for your homedir containers ?

-Reena

[#8]

Hi Reena,

Thanks for the updates.

#1: Thanks, I was able to modify share permissions based on AD group(s).

#2 & #3:

> if you don't have that user account existing on the other side

All the machines (including the filer) are part of the domain. And users login with only their respective domain accounts. So, this must not have been the case.

>  /etc/passwd file on the filer

Yes, this exists on the filer. Any other thoughts on what might be going on??

Mixed mode qtree: Lot of our users access and modify files/folders from various operating systems (windows, linux and mac).

Testing the home directories: We have actually migrated home directories for few users and asked them to test the same. Our observations are mentioned below. So we are stuck at this place.

     1. When we set the NTFS permissions on a home directory (from a windows server present in the domain): The user is able to access the home directory (and containing folders) properly from windows clients. But, from Linux clients using NFS, users get "permission denied" errors - this could be because the "Unix perms" are always "root:daemon".

     2. When we set the Unix permissions on a home directory (from a windows server present in the domain using secure share s/w): The user is able to access the home directory (and containing folders) properly from Linux clients using NFS. But, users get "access denied" errors when accessed from windows clients.

One more quick question: Is there any way to see the effective latest (NTFS/Unix) permissions of a file / folder that is residing on a mixed mode qtree from the filer? I thought it would be really helpful while troubleshooting issues if this was possible.

Thanks,

Satish

[#9]

Satish,

My other thoughts are if somehow that UNIX username is not existing on the UNIX side or Windows AD account not existing on the AD side or somehow these accounts are not mapping to each other.

BTW the TR3490, not sure if you have gone thru it, gives you a good understanding of the multiprotocol access. You can check couple of things, else I'd recommend to open a support case with NetApp, as if needs to be troubleshooted completely with the data from your systems.

1. Check if you are using NIS for unix user authentication, if not, put the unix user in the local /etc/passwd file of the filer. Make sure to update the order for passwd in the /etc/nsswitch.conf file accordingly.
2. Make sure the UNIX and Windows user names are mapping to each other correctly by looking at the "wcc -s <windowsusername>" and "wcc -u <unixusername>".
3. If these are the same names, then the filer would do an automatic mapping, if not, you may need to set an explicit mapping in the /etc/usermap.cfg file.
4. Ensure that the users are in the appropriate groups on UNIX or Windows side which show up on the permissions list.

You can use the "fsecurity" CLI tool on the console to see the complete security descriptor of any file/folder object. That should help you a lot.

Also there's another CLI tool for troubleshooting the access problems, called "sectrace". You can create a filter for any specific user or the path for which you want to trace the access and see why you get permission denied or approved access.

I hope you could fix your issue within these steps.

Cheers,

Reena