CIFS Share-level permissions problem

[marklomas]

I'm having a problem setting CIFS share-level permissions (FAS2020A, Ontap 7.3.3) - we've succesfully joined to the Active Directory domain, but when we attempt to add a group to the share permissions, we can only add Distribution Groups - not Security Groups.

Is there an easy way to allow security groups to be added?

--

Mark Lomas

[rkaramchedu1]

hmm... I thought it would be the other way around.. can you elaborate more... is this a Security Group you created? What's the error message? Do any messages show on on the console of the NetApp or in the logs?

[marklomas]

I've tried using CLI, FilerView, and System Manager.

With both CLI and FilerView, if I try to add the group (in the format [domain]\[GroupName] - it tells me it can't find it (unknown user/group) - if I change the group to a distribution group, it can find it just fine.

Using System Manager, when I try to type the name in, it behaves as if it can't find it - if I do a search and get it to show me all groups in AD, it only shows me a list of Distribution Groups.  Again, if I change the group i've been working on to a Distribution Group, it immediately becomes available for use.

I've tried running CIFS setup again in CLI, and this completes with no problems, my DCs all seem to be accesible to the controllers.  I /could/ setup distribution groups for what I want to do - but it would seem odd to me to have to do this, and would result in various redundant groups showing up for Exchange users (which I can supress, but again I shouldn't have to do this really).

I can't see any relevant errors in teh SYSLOG pertaining to CIFS.

The domain is using Windows 2008 R2 Domain Controllers, operating at a Windows 2003 forest and domain functional level (Domain started life on 2003 DCs which have been decommisioned).  Should I raise the functional level?  Might this help?

--

Mark Lomas

[rkaramchedu1]

Does the storage system retrieve AD Security groups at all? Try running commands like "cifs lookup DOMAIN\username" and wcc -s DOMAIN\username. If the user belongs to a SG and the CIFS communications are all working properly, you should see the groups listed.

[julian_topley]

What type of security groups are you attempting to add (there are several types with specific rules e.g. Domain Local, Global and Universal).

Also are the security groups from the same domain the filer is a member of?

[marklomas]

I've tried changing the group scopes to no avail - and yep, it's all in the same domain (there is only one).

If I add the group as a distribution group, and add it to the ACL of the share level permissions, it doesn't actually seem to work (members of the group are NOT allowed access).  If I then change the group to be a security group (after having added it to the ACL of the share) members of the group can then gain access - it all starts working!

This is a very odd workaround scenariio I find myself in!

Any thoughts?  Could there be something lurking in my domain somewhere that might be worth investigating, and is there anyway from the Filer to tell what's going on?

--

Mark Lomas

[julian_topley]

You need to elaborate a little on what you changed the groups to - Universal or Global should work.  Also I'd never consider using shares for setting security access in Windows; I'd use Full Control and then lock down the folders using NTFS ACLs.

I suggest you experiment by creating a share will full control and then permission the folder's NTFS security - its also generally good practice to use inheritence, i.e. propigate the permissions down the tree.

[marklomas]

I tried the groups in every configuration.  THe scope of the group had no impact - only the type of group.

On the NTFS front, you're preaching to the converted!  Never-the-less, it still stands as a rather odd point that this seems to only work in a 'back to front' fashion.  The customer is using share level permissions to control the overall 'read / write' state of a share.  Not to mention a Filers ability to display ONLY the shares you have access to when browsing.

Whilst I take your point about NTFS permissions - share level permissions should still work.

--

Mark Lomas

[cking22001]

Ok, I might be a bit confused but here is what I see. Using NTFS permissions, Universal Distribution groups don't work but Universal Security groups do. I don't much care as we should be using Universal Security groups but I wonder if this is some sort of 'by design' or a strange bug with the NetApp.

Model	FAS3170
System ID
Version	7.3.2P2

[stuartg_orion]

We just got a NetApp, this is the first time we've used one for CIFS, and as far as I can tell I have the same problem.

I can't add any of our main groups to the share using System Manager as they are security groups.

[terryzolinski]

yep, same issue here. I'll post support ticket and find out the actual answer.

[itr · Accepted solution]

Solution:

Run mmc

File - Add/Remove Snap-in

Shared Folders - Another computer: NetApp (or IP)

Under the "Shares" you can add / remove / modify share permissions for users and GROUPS.

Lajos Barf

[terryzolinski]

Good call Lajos. That's exactly what you need to do to manage the perms properly.

In regards to the issue itself, this is a bug in System Manager. Review bug ID 371143 for the whole story. My consultant has the new System Manager beta and this is bug is gone.