samba - Sep 2023 - Some users cannot access shares with FQDN, but can with IP or hostname

Hi List,

I have a Samba setup on Debian Bookworm, 2 DCs (dc1/dc2) and a file server
(fs1). We host our shares on FS1, and apply security level permissions
through the Windows File Explorer.

I have a user who is part of the group allowed to access the share, but
keeps getting Access Denied errors if using the FQDN in the path (i.e. \\
fs1.example.com\Sharename), but it works when I use just the hostname or IP
address (i.e. \\fs1\Sharename). I also confirmed by logging in as root,
then `su -s/bin/bash username -` on the file server, and can access the
folder.

Because it's using the FQDN, I assume it's a Kerberos issue. Yes, I made
sure that both the file server and computer have the DCs as the
primary/secondary DNS servers.

FS1 smb.conf file (privatized):

[global]
        server role = member server
        security = ADS
        workgroup = EXAMPLE
        realm = EXAMPLE.AD.CA

        interfaces = lo enp1s0
        bind interfaces only = yes

        log file = /var/log/samba/%m.log
        log level = 1

        idmap config * : backend = tdb
        idmap config * : range = 70000-99999

        # Use idmap_rid for domain accounts
        idmap config EXAMPLE: backend = rid
        idmap config EXAMPLE: range = 100000-199999

        # Configure winbind
        winbind nss info = template
        template shell = /bin/false
        template homedir = /home/example/%U
        winbind separator = /
        winbind use default domain = yes
        winbind enum users = Yes
        winbind enum groups = yes

        # Enable extended ACLs globally
        vfs objects = acl_xattr
        map acl inherit = yes
        store dos attributes = yes

        client signing = mandatory
        server signing = mandatory

        # Turn off NetBIOS, since our clients don't need it
        disable netbios = yes

[Users]
path = /home/example
writeable = yes

[Staff]
path = /usr/local/share/Staff
writeable = yes

On the DCs (same except hostname):

[global]
        bind interfaces only = Yes
        disable netbios = Yes
        interfaces = lo enp1s0
        netbios name = DC1
        ntlm auth = ntlmv1-permitted
        realm = AD.EXAMPLE.CA
        server role = active directory domain controller
        server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl,
winbindd, ntp_signd, kcc, dnsupdate
        winbind separator = /
        workgroup = EXAMPLE
        idmap_ldb:use rfc2307 = yes
        dns forwarder = 1.2.3.4
        ntlm auth = mschapv2-and-ntlmv2-only
        log level = 1 auth_json_audit:5
        dns zone transfer clients allow = 127.0.0.0/8 ::1/128

[netlogon]
        path = /var/lib/samba/sysvol/ad.example.ca/scripts
        read only = No

[sysvol]
        path = /var/lib/samba/sysvol
        read only = No

DCs and File server Samba version: 4.17.10-Debian

I have also restarted the servers to attempt to fix this, but no change.

When I look at /var/log/samba/winbindd.log (the file updated when I try to
access the share), I see lots of these lines:

Could not convert sid S-0-0: NT_STATUS_NONE_MAPPED

On 2023-09-21 3:57 p.m., Luke Barone via samba wrote:

Not saying this is the cause of your issue, but you have 'ntlm auth' set
twice in the [global] section of your DC conf, to conflicting values: 
'ntlmv1-permitted' and 'mschapv2-and-ntlmv2-only'.

-S.M.

On Thu, 21 Sep 2023 15:57:38 -0700
Luke Barone via samba <samba at lists.samba.org> wrote:
> Hi List,
> 
> I have a Samba setup on Debian Bookworm, 2 DCs (dc1/dc2) and a file
> server (fs1). We host our shares on FS1, and apply security level
> permissions through the Windows File Explorer.
> 
> I have a user who is part of the group allowed to access the share,
> but keeps getting Access Denied errors if using the FQDN in the path
> (i.e. \\ fs1.example.com\Sharename),
Now that just might be a typo, but if it isn't, then it shouldn't work.
Lower down your realm is 'EXAMPLE.AD.CA' on the fileserver, and
'AD.EXAMPLE.CA' on the DCs, hopefully one should be correct, in which
case, to access the share it should be something like
\\fs1.example.ad.ca\Sharename

Do you want to try again, but this time, please use the same
sanitisation everywhere.

Rowland