ONTAP Discussions

BUILTIN\Administrators not working properly for CIFS share

Livewire18
16,892 Views

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.

 

builtin_admins.jpg

13 REPLIES 13

JGPSHNTAP
16,728 Views

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
16,721 Views

JGPSHNTAP
16,713 Views

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
16,684 Views

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
16,677 Views

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
16,667 Views

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
16,656 Views

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
16,462 Views

BUMP - 

Anyone else have any ideas before I open a ticket?

tduran12165
12,700 Views

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
12,213 Views

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
12,190 Views

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
12,181 Views

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

tduran12165
12,129 Views

Got it.  Thanks for the reply back!

Public