samba - May 2022 - "Check Names" only supported on single subnet

Hi,

I'm having a problem with ACLs on my server (Samba 4.13.17 on FreeBSD
13.1-RELEASE). Back in January, I had everything working properly, so that
users with "Full Control" on a directory could edit the ACLs on that
directory to their needs. There have been changes to smb4.conf since it was
initially setup, but no changes since a point I know it was working. There
have been package/system updates since then, of course (including Samba -
as far as I can tell, I was using 4.13.14 back in January). The problem
seems to be related actually to networking, rather than the ACL system -
let me do my best to explain.

There are 3 VLANs that Samba should be listening on (2, 10, 99 on mce0.2,
mce0.l and mce0 respectively, since 99 is PVID/Untagged on that port).
We'll focus on 2 and 99 for now (10 acts identical to 2 in testing). 99 is
a more "privileged" VLAN in my head, but by all means they should be
equivalent in terms of FW rules for everything I describe (FW being between
the VLANs - pf is disabled on this server), leaving the only thing
"special" about 99 being that it's untagged on the server's
interface, and
it's the network for the default route. There are several users with access
to the share, but it doesn't seem to matter which one is used (in
particular, one user in "admin users" and the unix wheel group acts
the same way as the rest). The share itself, and *almost* everything in it
are Everyone - Full Control with inheritance enabled. When we want to
"hide" a folder, we'll disable inheritance on that, and add the
permissions
we actually want, always using Windows.

When any user connects from a 99 address to the server's 99 address,
everything works fine. When any user connects from a 2 address to either 2
or 99, things fail (see below).
When any user connects from a 99 address to the server's 2 address, things
fail (see below).

The "fail" state is a little wacky: basically, it's possible to
modify
ACLs, but not "Check Names", which makes almost every
"useful" ACL
modification impossible in Windows. When in the failed state, any time the
Windows "Select User or Group" dialog comes up, entering anything and
then
hitting "Check Names" immediately asks for authentication (and nothing
helps) - alternatively, hitting "Advanced" and "Find Now"
lists several
"builtin" groups, but not the users (like it does in the success
state).
I'm able to, in that failed state, disable inheritance, remove individual
entries, etc., but nothing that requires entering a principal name.

smb4.conf looks like this (clipped out the print$ and printers sections -
we're largely not using samba for printers anymore, and hoping to disable
that anyway soon):
-----
[global]
workgroup=WORKGROUP
netbios name = Castor
security = user
rpc_server:spoolss = external
rpc_daemon:spoolssd = fork
printing = CUPS
spoolss:architecture = Windows x64
admin users = root, mkern
acl allow execute always = yes
interfaces = 172.20.0.7 192.168.10.7 192.168.99.7 127.0.0.1 #tried with
this and next line commented out too - that first is the vlan 2 address,
then 10, then 99.
bind interfaces only = yes
disable netbios = yes #also tried with this and the next line commented out
smb ports = 445

[fdrive]
path = /storage/fdrive
read only = no
mangled names = no
vfs objects = zfsacl shadow_copy2
shadow:snapdir = .zfs/snapshot
shadow:sort = desc
shadow:format = %Y-%m-%d
zfsacl:map_dacl_protected = yes
-----

Where do I even start debugging this one? How does that "Check Names"
function work, and is there another way I can test that? Any other ideas?

Many thanks in advance!
-Matthew Kern

...of course, I work on this all day and figure it out just *after* I post
on the mailing list. Issue was actually new rules I just rolled out on the
endpoints (Windows built-in firewall) related to File and Printer Sharing -
reverting those changes leaves everything in a working state again. I just
wasn't thinking of those changes as potentially breaking.

Issue is not related to Samba - please ignore!

Thanks,
-Matthew Kern


On Thu, May 26, 2022 at 1:03 PM Matthew Kern <mkern at
alconconstruction.com>
wrote:
> Hi,
>
> I'm having a problem with ACLs on my server (Samba 4.13.17 on FreeBSD
> 13.1-RELEASE). Back in January, I had everything working properly, so that
> users with "Full Control" on a directory could edit the ACLs on
that
> directory to their needs. There have been changes to smb4.conf since it was
> initially setup, but no changes since a point I know it was working. There
> have been package/system updates since then, of course (including Samba -
> as far as I can tell, I was using 4.13.14 back in January). The problem
> seems to be related actually to networking, rather than the ACL system -
> let me do my best to explain.
>
> There are 3 VLANs that Samba should be listening on (2, 10, 99 on mce0.2,
> mce0.l and mce0 respectively, since 99 is PVID/Untagged on that port).
> We'll focus on 2 and 99 for now (10 acts identical to 2 in testing). 99
is
> a more "privileged" VLAN in my head, but by all means they should
be
> equivalent in terms of FW rules for everything I describe (FW being between
> the VLANs - pf is disabled on this server), leaving the only thing
> "special" about 99 being that it's untagged on the
server's interface, and
> it's the network for the default route. There are several users with
access
> to the share, but it doesn't seem to matter which one is used (in
> particular, one user in "admin users" and the unix wheel group
acts
> the same way as the rest). The share itself, and *almost* everything in it
> are Everyone - Full Control with inheritance enabled. When we want to
> "hide" a folder, we'll disable inheritance on that, and add
the permissions
> we actually want, always using Windows.
>
> When any user connects from a 99 address to the server's 99 address,
> everything works fine. When any user connects from a 2 address to either 2
> or 99, things fail (see below).
> When any user connects from a 99 address to the server's 2 address,
things
> fail (see below).
>
> The "fail" state is a little wacky: basically, it's possible
to modify
> ACLs, but not "Check Names", which makes almost every
"useful" ACL
> modification impossible in Windows. When in the failed state, any time the
> Windows "Select User or Group" dialog comes up, entering anything
and then
> hitting "Check Names" immediately asks for authentication (and
nothing
> helps) - alternatively, hitting "Advanced" and "Find
Now" lists several
> "builtin" groups, but not the users (like it does in the success
state).
> I'm able to, in that failed state, disable inheritance, remove
individual
> entries, etc., but nothing that requires entering a principal name.
>
> smb4.conf looks like this (clipped out the print$ and printers sections -
> we're largely not using samba for printers anymore, and hoping to
disable
> that anyway soon):
> -----
> [global]
> workgroup=WORKGROUP
> netbios name = Castor
> security = user
> rpc_server:spoolss = external
> rpc_daemon:spoolssd = fork
> printing = CUPS
> spoolss:architecture = Windows x64
> admin users = root, mkern
> acl allow execute always = yes
> interfaces = 172.20.0.7 192.168.10.7 192.168.99.7 127.0.0.1 #tried with
> this and next line commented out too - that first is the vlan 2 address,
> then 10, then 99.
> bind interfaces only = yes
> disable netbios = yes #also tried with this and the next line commented out
> smb ports = 445
>
> [fdrive]
> path = /storage/fdrive
> read only = no
> mangled names = no
> vfs objects = zfsacl shadow_copy2
> shadow:snapdir = .zfs/snapshot
> shadow:sort = desc
> shadow:format = %Y-%m-%d
> zfsacl:map_dacl_protected = yes
> -----
>
> Where do I even start debugging this one? How does that "Check
Names"
> function work, and is there another way I can test that? Any other ideas?
>
> Many thanks in advance!
> -Matthew Kern
>