BUILTIN\Administrators not working properly for CIFS share

[Livewire18]

We have quite a few Clusters and 7 Mode boxes in our environment. In an effort to reduce work during future changes, we decided to add our NAS Admin domain group (we'll call it Domain\NASAdmins) and our Off Shore Support group (call it Domain\OffShore) to the BUILTIN\Administrators group of our Clusters. Then, when adding security to the top Level Volumes we just add \\SVMName\Administrators to the volume with Full Control. That way, everyone in Domain\NASAdmins and Domain\OffShore should have full control over the volumes and the qtree's and if we ever add/change a support group, we don't have to re-push the new group to all 100K+ shares. But, it doesn't work. If we add the domain groups directly to the volume or share, they work as expected. I have tested this on multiple clusters and 7 mode pairs all with the same results. I have checked the domain groups and have tried Group Scope types of Universal and Global.

edit: I have also tried adding admin Domain accounts directly to the BUILTIN\Administrators with the same outcome. 

All CIFS access and authentication is working for all shares properly and have been for a long time. This is just a new change we are trying to make.

[JGPSHNTAP]

This is quite a common setup throughout the industry.  Are you saying that when you provisioned the system, you don't provision builtin\administrators to the NTFS file system?

I'm trying to understand how your share vs ntfs file system security is setup

Generally

Share - everyone- full   or authenticated users - full

NTFS permission - builtin\administrators - full

   User Group - modify

[Livewire18]

JGPSHNTAP - Thanks for the reply. 

Share Permissions are set to Authenticated Users = Change and our Domain\NASAdmins & Domain\OffShore set to the FULL. 

NTFS = Share specific group = READ/WRITE and SVM\Administrators set to FULL & in some cases, the Domain\NASAdmins & Domain\OffShore set to the FULL but we are trying to do away with that. 

[JGPSHNTAP]

Ok, so you explicitly remove builtin\adminstrators when you are provisioning and then you want it back to a standard as what you are saying?

I personally believe you are making your life more difficult.

We always let NTFS control permissions.  So we also leave everyone/full_Control at share level, and not worry about acling the share and worry about controlling perms at NTFS level.

When you say things aren't working, what exactly isn't working?

Also, do you map root to builtin group?

for cDOT - this vserver cifs options -  Are Administrators mapped to 'root': true

7-mode - options wafl.nt_admin_priv_map_to_root

[Livewire18]

Removing everyone/full_Control from the Share level is required by our corporate security. We have argued this for a long time, but they will not allow this to be changed because IF by chance a share is created and set to Everyone, than that allows a hole so that even non-authenticated users can access it. 

This share creation is done through WFA, so no real time lost. I would love to do it differently, but right now, we have 70+ clusters and 30+ & mode HA pairs. 

The part that "isn't working" is that the Active Directory Groups being added to the BUILTIN\Administrators group are not getting FULL control to the NTFS shares when SVMNAME\Adminsitrators is added to NTFS perimssions as having FULL control. 

[JGPSHNTAP]

We have a very large environment as well and i cannot for the life of me figure out why something so trivial isn't working.

Ok, try this

in cDOT

go to diag mode (set d)

diag sec  login-cifs -vserver smvname -user domain\userid -node node

When the command returns, at the bottom you should see this

BUILTIN\Administrators (Windows Alias)
BUILTIN\Users (Windows Alias)
User is also a member of Everyone, Authenticated Users, and Network Users

Privileges (0x22b7):
SeBackupPrivilege
SeRestorePrivilege
SeTakeOwnershipPrivilege
SeSecurityPrivilege
SeChangeNotifyPrivilege
Authentication Succeeded.

Make sure you are using an account in builtin\adminsitrators

Let me know if you get a response back

If not, sometimes secd cache is jacked up.  I've seen this happen

[Livewire18]

I have ran through this before, and yes, when running checks the following does show up:

diag sec  login-cifs -vserver smvname -user domain\userid -node node

BUILTIN\Administrators (Windows Alias)
BUILTIN\Users (Windows Alias)

as well as all other Groups. 

Privileges (0x22bf):
SeTcbPrivilege
SeBackupPrivilege
SeRestorePrivilege
SeTakeOwnershipPrivilege
SeSecurityPrivilege
SeChangeNotifyPrivilege
Authentication Succeeded.

I have also tried clearing the secd cache with the same results. 

[JGPSHNTAP]

At this point it's either something very simple that we are missing or something complex, which I don't think.  I'm going with the first one.

I would suggest opening a case b/c it should work.

Have you tried to create a brand new vserver in the lab and start from scratch to see if things work.

[Livewire18]

BUMP - 

Anyone else have any ideas before I open a ticket?

[tduran12165]

Hi.  Just curious if you ended up opening a case, and the findings?  I never experienced the same issue, but we do put Groups in the BUILTIN\Group so was curious if this is best practice.

[chris_hurley]

remember... when you change group membership, the user needs to logoff and back on to the ONTAP share.  This way, ONTAP can give them their group membership changes.

you can use sectrace (vserver security trace) to tell you why its access denied

also...  from diag mode for the username of someone in one of those groups:

diag secd authentication show-creds -node <node> -vserver <svm> -win-name <username>

you DEFINITELY want to see the map to root(if you have local admins mapped to root)

UNIX UID: root <> Windows User: DOMAIN\user (Windows Domain User)

GID: daemon
Supplementary GIDs:
daemon

Primary Group SID: DOMAIN\Domain Users (Windows Domain group)

Windows Membership:
DOMAIN\Domain Users (Windows Domain group)
DOMAIN\ClusterAdmins (Windows Domain group)
DOMAIN\Domain Admins (Windows Domain group)
DOMAIN\ESX Admins (Windows Domain group)
DOMAIN\Denied RODC Password Replication Group (Windows Alias)
NT AUTHORITY\Claims Valid (Windows Well known group)
Service asserted identity (Windows Well known group)
BUILTIN\Users (Windows Alias)
BUILTIN\Administrators (Windows Alias)  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
User is also a member of Everyone, Authenticated Users, and Network Users

Privileges (0x22b7):
SeBackupPrivilege
SeRestorePrivilege
SeTakeOwnershipPrivilege
SeSecurityPrivilege
SeChangeNotifyPrivilege

[tduran12165]

Is there a difference where users are added?  For example the discussion here is about BUILTIN\Administrators.  However, I have typically seen in root folder NTFS permissions, the "vserver"\Administrators is added with FULL Control.  So does the placement of users (either in BUILTIN\Administrators or "vserver"\Administrators) affect the outcome of what can or cannot be done to directories/folders/files? 

Aside from the fact that you should logoff/logon after changes.

[chris_hurley]

No.   BUILTIN\Administrators  and VSERVER\Administrators are the same.  It all depends on the context as to which one is displayed.

[tduran12165]

Got it.  Thanks for the reply back!