[Samba] User cannot access member server share by name, only by IP

[Rowland Penny]

On 02/12/2022 18:11, Luke Barone via samba wrote:
> I think I found the issue, just not the resolution.
> 
> While researching, I tried to flush the winbind cache. This looked to work
> until this morning. The Staff group for the domain has an ID of 70012 (for
> those paying attention - not part of the domain range, but part of the *
> range) on the ACL of the folder, but 101109 when I run `id` while logged in
> as a user of that group (and their user ID appears to be 70010!). When I
> login as another user in the group, it shows as 70012 in the `id` command
> though! The user's ID in this case is 101471.
> 
> Obviously there is an issue with how the usernames are mapped. What I need
> to know is how do I move past this? Can I manually change the uid being
> reported on the member server for these users to be in the 100_000 range?
> Or am I at the whim of winbind?
> 
> On Tue, Nov 29, 2022 at 2:32 PM Luke Barone <lukebarone at gmail.com> wrote:
> 
>> To add to this: On the file server, I see this line repeated constantly
>> for the computer the user is working on:
>>
>> [2022/11/29 14:23:36.559926,  0]
>> ../../source3/smbd/service.c:166(chdir_current_service)
>>    chdir_current_service: vfs_ChDir(/usr/local/share/Staff) failed:
>> Permission denied. Current token: uid=70010, gid=100513, 8 groups: 100513
>> 101109 70011 101202 70002 70003 70010 70001
>>
>> I'm feeling that's wrong, given the range in the config file. Is this
>> something that can be repaired, or do I have to wipe and redo the
>> account(s)?
>>
>> On Tue, Nov 29, 2022 at 2:18 PM Luke Barone <lukebarone at gmail.com> wrote:
>>
>>> I have 2 DCs and a member server, all running on Debian Bullseye, version
>>> 4.13.13-Debian. Recently, some users cannot access folders that are being
>>> shared on the member server.
>>>
>>> I can run `su -s/bin/bash USERNAME`, then cd into the directory just
>>> fine. From the Windows workstation, it's not always working. Most recently,
>>> I was able to fix one share by flushing the winbind cache (net cache
>>> flush). The other main share they're using is fixed temporarily by mapping
>>> to the IP address vs the FQDN (or hostname). This is leading me to think
>>> this is a Kerberos issue.
>>>
>>> The Windows 10 computers are on the 21H2 patch level, which is working
>>> for other sites in our organization. Checking on both DCs, replication
>>> appears to be working (0 consecutive failures).
>>>
>>> I saw a previous message about users being part of a group for
>>> permissions, but it didn't seem to be my *exact* issue. Is it related? We
>>> only add users to the groups, then the groups have permissions on various
>>> shares.
>>>
>>> DC1 smb.conf (DC2 is the same):
>>>
>>> # Global parameters
>>> [global]
>>>          bind interfaces only = Yes
>>>          disable netbios = Yes
>>>          interfaces = lo enp1s0
>>>          ntlm auth = ntlmv1-permitted # needed for wireless
>>>          passdb backend = samba_dsdb
>>>          realm = DOMAIN.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 = DOMAIN
>>>          rpc_server:tcpip = no
>>>          rpc_daemon:spoolssd = embedded
>>>          rpc_server:spoolss = embedded
>>>          rpc_server:winreg = embedded
>>>          rpc_server:ntsvcs = embedded
>>>          rpc_server:eventlog = embedded
>>>          rpc_server:srvsvc = embedded
>>>          rpc_server:svcctl = embedded
>>>          rpc_server:default = external
>>>          winbindd:use external pipes = true
>>>          idmap_ldb:use rfc2307 = yes
>>>          idmap config * : backend = tdb
>>>          map archive = No
>>>          vfs objects = dfs_samba4 acl_xattr
>>>
>>>
>>> [netlogon]
>>>          path = /var/lib/samba/sysvol/DOMAIN.ca/scripts
>>>          read only = No
>>>
>>>
>>> [sysvol]
>>>          path = /var/lib/samba/sysvol
>>>          read only = No
>>>
>>> Relevant section on file server:
>>> [global]
>>>          bind interfaces only = Yes
>>>          client signing = required
>>>          dedicated keytab file = /etc/krb5.keytab
>>>          disable netbios = Yes
>>>          interfaces = lo enp1s0
>>>          kerberos method = secrets and keytab
>>>          log file = /var/log/samba/%m.log
>>>          realm = DOMAIN.CA
>>>          security = ADS
>>>          server role = member server
>>>          server signing = required
>>>          template homedir = /home/DOMAIN/%U
>>>          username map = /etc/samba/user.map
>>>          winbind enum groups = Yes
>>>          winbind enum users = Yes
>>>          winbind refresh tickets = Yes
>>>          winbind separator = /
>>>          winbind use default domain = Yes
>>>          workgroup = DOMAIN
>>>          idmap config edge : range = 100000-199999
>>>          idmap config edge : backend = rid
>>>          idmap config * : range = 70000-99999
>>>          idmap config * : backend = tdb
>>>          map acl inherit = Yes
>>>          vfs objects = acl_xattr
>>>
>>>
>>> [Users]
>>>          path = /home/DOMAIN
>>>          read only = No
>>>
>>>
>>> [Staff]
>>>          path = /usr/local/share/Staff
>>>          read only = No
>>>
>>>
>>> [Office]
>>>          path = /usr/local/share/Office
>>>          read only = No
>>>
>>>
>>>

Why is 'staff' getting the GID '70012' ?
As you say, that range is meant for the default domain and 'staff' 
should be a DOMAIN group.

Is DOMAIN actually 'edge' as you have set in the 'idmap config' lines ? 
If it isn't, then change 'edge' to 'DOMAIN' and reload Samba or restart 
it, but beware, this will give all your users and groups ID's in the 
100000-199999 range (which is what they should have).

Rowland