samba - Mar 2022 - Remove all Windows ACL's from files/folders

Sorry for the long post;
The gist is:

1) I set permissions in the Windows UI, and it appears to be successful.
2) I then attempt to access a share, from a domain joined Windows PC, using
the user (and group) I've assigned "full control" to.
3) It Fails.
4) So, I check the Samba logs - sure enough it shows that user attempting
to access that share.
5) I check to be sure the UID matches the UID of the user. It does.
6) I check the GID and it also matches.
7) I check the NTACL perms that Samba thinks are set, and look (as best I
can understand) the SDDL output.
8) And the SDDL output doesn't even remotely match the permissions I set in
Windows.

And I have no idea where to look next to figure out why.

Following is the "show my work" section. :)
---

So, I'm only able to set permissions (as Administrator) with
"acl_xattr:ignore system acls = yes" set.
(Which is "wrong" but lets just go with it. You'll see where
I'm going in a
minute.)

So, I set the permissions on a share to the following. (From the Windows
file explorer)
Allow root: full control
Allow SYSTEM: full control
Allow Domain Admins: full control
Allow: Domain Users: full control
Allow ad\gs: full control

I'm testing with a test user, AD\GS.
GS is a member of domain users, which should grant access, but doesn't.
So, I add the user explicitly, which also fails to grant access.

So, check the Samba logs.
---
2022/03/29 10:23:54.736440,  0]
../../source3/smbd/service.c:168(chdir_current_service)
  chdir_current_service:
vfs_ChDir(/abc-zfs-01/ad-shared-folders/shared-files) failed: Permission
denied. Current token: uid=11608, gid=10513, 7 groups: 11608 10513 11129
3003 3004 3006 3001
---
# wbinfo -i "ad\gs"
AD\gs:*:11608:10513:gs:/home/AD/gs:/bin/false
---

So the UID in the Samba log matches the user I expect.
That's good.
At least the user attempting access matches the user I've set permissions
for,

---
Incidentally, the group matches too;
wbinfo -i "ad\domain users"
AD\domain users:*:10513:10513::/home/AD/domain users:/bin/false
---

So, now lets see what Samba thinks the permissions are on that
share/directory.

---
getfattr -n security.NTACL /abc-zfs-01/ad-shared-folders/shared-files/
samba-tool ntacl get /abc-zfs-01/ad-shared-folders/shared-files/ --as-sddl

And I get:
O:S-1-22-1-0G:DAD:(A;;0x001f01ff;;;S-1-22-1-0)(A;;0x001f01ff;;;DA)(A;;0x001200a9;;;WD)(A;OICIIO;0x001f01ff;;;CO)(A;OICIIO;0x001200a9;;;CG)(A;OICIIO;0x001200a9;;;WD)

However, I'm a bit lost decoding that - but it really doesn't look like
I'd
expect.
It looks to have a couple of "everyone" permissions - which isn't
in the
Windows UI.
Also, there's a "Creator Owner" and "Creator Group"
which aren't in the ACL
I've set in Windows. And I don't see the "Domain Users" or the
explicit
User assignment in there.

(Rowland, I'd be happy for a better decode, if you can - but that's what
I
think I see.)

So that would explain a lot - the permissions that Samba thinks is set on
the share/folder don't match, at all, the permissions I set from the
Windows file explorer UI.

Can someone tell me where to look next to figure out why?

On 29 March 2022 18:41 Greg Sloop wrote:
> So, I set the permissions on a share to the following. (From the Windows
file
> explorer) Allow root: full control Allow SYSTEM: full control Allow Domain
Admins: full
> control
I share your frustration having followed this thread.  I wish I could solve it
for you but is this the problem?   You need to use Computer Management to set
permissions from Windows.   See
https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs

Roy

On Tue, Mar 29, 2022 at 10:40:43AM -0700, Greg Sloop <gregs--- via samba
wrote:
>
>So, check the Samba logs.
The Samba logs are the source of truth, always.
>2022/03/29 10:23:54.736440,  0]
>../../source3/smbd/service.c:168(chdir_current_service)
>  chdir_current_service:
>vfs_ChDir(/abc-zfs-01/ad-shared-folders/shared-files) failed: Permission
>denied. Current token: uid=11608, gid=10513, 7 groups: 11608 10513 11129
>3003 3004 3006 3001
>---
># wbinfo -i "ad\gs"
>AD\gs:*:11608:10513:gs:/home/AD/gs:/bin/false
>---
>
>So the UID in the Samba log matches the user I expect.
>That's good.
>At least the user attempting access matches the user I've set
permissions
>for,
>
>---
>Incidentally, the group matches too;
>wbinfo -i "ad\domain users"
>AD\domain users:*:10513:10513::/home/AD/domain users:/bin/false
>---
>
>So, now lets see what Samba thinks the permissions are on that
>share/directory.
>
>---
>getfattr -n security.NTACL /abc-zfs-01/ad-shared-folders/shared-files/
>samba-tool ntacl get /abc-zfs-01/ad-shared-folders/shared-files/ --as-sddl
Neither of these gets the *actual* permissions on the
folder. Remember, Samba is an ordinary program and
when operating under a given uid/gid-list in order
to vfs_ChDir() into a folder, the system permissions
on that folder must allow the uid/gid-list access.

You're only looking and reporting the Samba stored
permissions here.

What does

getfacl /abc-zfs-01/ad-shared-folders/shared-files

show ?

If you decouple the Samba stored permissions from
the system permissions, then you need to ensure
that the system permissions allow access from the
given uid/gid-list. Easiest way to do that is to
force all folders to be 0777, all files to be 0666.

This is safe if you're only accessing via smbd.

On Tue, 2022-03-29 at 10:40 -0700, Greg Sloop <gregs--- via samba
wrote:
> Sorry for the long post;
> The gist is:
> 
> 1) I set permissions in the Windows UI, and it appears to be
> successful.
> 2) I then attempt to access a share, from a domain joined Windows PC,
> using
> the user (and group) I've assigned "full control" to.
> 3) It Fails.
> 4) So, I check the Samba logs - sure enough it shows that user
> attempting
> to access that share.
> 5) I check to be sure the UID matches the UID of the user. It does.
> 6) I check the GID and it also matches.
> 7) I check the NTACL perms that Samba thinks are set, and look (as
> best I
> can understand) the SDDL output.
> 8) And the SDDL output doesn't even remotely match the permissions I
> set in
> Windows.
> 
> And I have no idea where to look next to figure out why.
> 
> Following is the "show my work" section. :)
> ---
> 
> So, I'm only able to set permissions (as Administrator) with
> "acl_xattr:ignore system acls = yes" set.
> (Which is "wrong" but lets just go with it. You'll see where
I'm
> going in a
> minute.)
> 
> So, I set the permissions on a share to the following. (From the
> Windows
> file explorer)
> Allow root: full control
> Allow SYSTEM: full control
> Allow Domain Admins: full control
> Allow: Domain Users: full control
> Allow ad\gs: full control
> 
> I'm testing with a test user, AD\GS.
> GS is a member of domain users, which should grant access, but
> doesn't.
> So, I add the user explicitly, which also fails to grant access.
> 
> So, check the Samba logs.
> ---
> 2022/03/29 10:23:54.736440,  0]
> ../../source3/smbd/service.c:168(chdir_current_service)
>   chdir_current_service:
> vfs_ChDir(/abc-zfs-01/ad-shared-folders/shared-files) failed:
> Permission
> denied. Current token: uid=11608, gid=10513, 7 groups: 11608 10513
> 11129
> 3003 3004 3006 3001
> ---
> # wbinfo -i "ad\gs"
> AD\gs:*:11608:10513:gs:/home/AD/gs:/bin/false
> ---
> 
> So the UID in the Samba log matches the user I expect.
> That's good.
> At least the user attempting access matches the user I've set
> permissions
> for,
> 
> ---
> Incidentally, the group matches too;
> wbinfo -i "ad\domain users"
> AD\domain users:*:10513:10513::/home/AD/domain users:/bin/false
I have been a bit busy with other things, but I had a quick look at
this and the above stands out. If you can run 'wbinfo -i' against a
group and get that output, then you have problems somewhere. '-i' is
short for '--user-info' and 'Domain Users' isn't a user, you
need to
run: wbinfo --group-info="AD\domain users"

Rowland