Recently we came across an issue where a user was not able to manage ACLs of the share using MMC from his Windows Client.
At first we wanted to see the ACLs set on the share.
From the ACL output snippet as you can see below, owner has ALL the ACLs set. He did have ACLs to WRITE the ACLs. However, operation was failing.
(X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED
(X)DELETE (X)DELETE_CHILD (X)CHOWN (X)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED
We then asked to collect the Samba Debug 10 logs along with Winbind Debug 10 logs during the recreate to see what the exact issue was.
Going through the logs,it was clearly see that some privileges were missing which are required to perform some actions like Change ACLs.
Here is the snippet -[2017/10/30 23:20:22.790998, 2, pid=10330, effective(12793314, 13000513), real(12793314, 0), class=rpc_srv] ../source3/rpc_server/srvsvc/srv_srvsvc_nt.c:1801(_srvsvc_NetShareSetInfo)
_srvsvc_NetShareSetInfo: uid 12793314 doesn't have the SeDiskOperatorPrivilege privilege needed to modify share audit
[2017/10/30 23:20:22.791006, 1, pid=10330, effective(12793314, 13000513), real(12793314, 0)] ../librpc/ndr/ndr.c:450(ndr_print_function_debug)
srvsvc_NetShareSetInfo: struct srvsvc_NetShareSetInfo
out: struct srvsvc_NetShareSetInfo
parm_error : *
parm_error : 0x00000000 (0)
result : WERR_ACCESS_DENIED
[2017/10/30 23:20:22.791024, 5, pid=10330, effective(12793314, 13000513), real(12793314, 0), class=rpc_srv] ../source3/rpc_server/srv_pipe.c:1496(api_rpcTNP)
Clearly the SeDiskOperatorPrivilege privilege
for that user who wanted to preform operations like update ACLs is missing.
From Samba documentation:SeDiskOperatorPrivilege - Accounts that possess this right will be able to execute scripts defined by the add/delete/change share command in smb.conf file as root. Such users will also be able to modify the ACL associated with file shares on the Samba server.
So, we recommended to add the user into a group which in turn has the privilege set. So, all such users who want to manage ACLs for share can be added to this group.Solution:
Set the Privilege for the group using the command:# net rpc rights grant 'domain_name\group_name' SeDiskOperatorPrivilege -U'domain_name\user_name'
Here "user_name" should be part of "Domain Admins" group.
Now, even after this, user was not able to edit ACLs using MMC.
For using MMC to perform any operation, the user must be member of the Local Administrators group. However, the user in question was not part of the group.Solution:
We asked the user to get himself added in the "Local Administrators" group and then things should work as normal.
Another hint, only a user in the "Domain Admins" group can add a user into the "Local Administrators" group. So, once the user was successfully added to "Local Administrators" group, things worked fine.CONCLUSION: 4 Essentials things to know for managing ACLs of Share or Files/Folders in a share are:
1. You need to have ACLs for being able to edit ACLs. WRITE_ACL(X) should be set.
2. The privilege "SeDiskOperatorPrivilege" must be set for the user or group in question.
3. For using MMC, the user in question MUST exist in the LOCAL ADMINISTRATOR group.
4. Only a user from DOMAIN ADMINS can add a user into LOCAL ADMINISTRATOR group.#IBMSoftwareDefinedStorage#IBMSpectrumScale#spectrumscale#ibmstorage#SpectrumScaleAuthentication#softwaredefinedstorage#Softwaredefinedstorage