Luke Barone
2022-Dec-02 20:41 UTC
[Samba] User cannot access member server share by name, only by IP
So here's the sad part (for me): some users are showing up still in the 70_000-range, which they should not be. Is there a way to get all the user ID numbers from the member server's point of view, then re-assign them to be in the 100_000 range? On Fri, Dec 2, 2022 at 12:39 PM Luke Barone <lukebarone at gmail.com> wrote:> 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 >> >
Rowland Penny
2022-Dec-02 21:00 UTC
[Samba] User cannot access member server share by name, only by IP
On 02/12/2022 20:41, Luke Barone via samba wrote:> So here's the sad part (for me): some users are showing up still in the > 70_000-range, which they should not be. Is there a way to get all the user > ID numbers from the member server's point of view, then re-assign them to > be in the 100_000 range? >There is something strange going on here. If you use the idmap 'rid' backend, the DOMAIN ID's are supposed to be calculated from the RID with this calculation: ID = RID + LOW_RANGE_ID From what you posted earlier, this becomes: ID = RID + 100000 As '70,000' is less than 100,000 , there should be no way that your users and groups are getting such low numbers. All you DOMAIN users and groups should have Unix ID's starting from 101000 , normal user & group RIDs start from '1000' Also from what you posted earlier, I am willing to bet that the group 'staff' has the RID '1109'. Have you run 'net cache flush' ? How are you creating users ? How are you creating groups ? How are you adding users to a group ? Rowland