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
Luke Barone
2022-Dec-02 20:39 UTC
[Samba] User cannot access member server share by name, only by IP
I agree, the ID number is weird. I've started creating new groups (Staff2, Office2, etc), and they are getting the right ID numbers. I'm in the process of adding the users to their new groups, and it seems to be helping. I'll rename the groups after I get rid of the originals. Yes, "DOMAIN" is "edge", I thought I sanitized but apparently not. My goal is to have all the users/groups for the domain in the 100_000 to 199_999 range. On Fri, Dec 2, 2022 at 10:46 AM Rowland Penny via samba < samba at lists.samba.org> wrote:> > > 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 > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >