Luke Barone
2022-Dec-02 18:11 UTC
[Samba] User cannot access member server share by name, only by IP
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 >> >> >>
Rowland Penny
2022-Dec-02 18:45 UTC
[Samba] User cannot access member server share by name, only by IP
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