Orion Poplawski
2020-May-14 17:46 UTC
[Samba] Users loose supplementary groups after a time
All - I seem to be suffering from the common complaint that users loose supplementary group access after a while - in our case it seems to be connections left overnight. Restarting smb fixes it. I haven't been able to determine the cause. From the logs I've been able to determine a bad access looks something like this: AuthZ reports a S-1-5-21- SID: [2020/05/14 09:49:40.474490, 4] ../../auth/auth_log.c:751(log_successful_authz_event_human_readable) Successful AuthZ: [lsarpc,ncacn_np] user [DOMAIN]\[user] [S-1-5-21-DOMAIN_SID] at [Thu, 14 May 2020 09:49:40.474481 PDT] Remote host [ipv4:Y.Y.Y.Y:54184] local host [ipv4:X.X.X.X:445] {"timestamp": "2020-05-14T09:49:40.474546-0700", "type": "Authorization", "Authorization": {"version": {"major": 1, "minor": 1}, "localAddress": "ipv4:X.X.X.X:445", "remoteAddress": "ipv4:Y.Y.Y.Y:54184", "serviceDescription": "lsarpc", "authType": "ncacn_np", "domain": "DOMAIN", "account": "user", "sid": "S-1-5-21-DOMAIN_SID", "sessionId": "50d682c6-196e-44fa-9999-abe8e33bfd1c", "logonServer": "ADSERVER", "transportProtection": "SMB", "accountFlags": "0x00000214"}} then: [2020/05/14 09:46:37.381633, 5] ../../libcli/security/security_token.c:63(security_token_debug) Security token SIDs (39): and the SIDs listed will be domain SIDs prefixed by S1-5-21-. And we will get 0 supplementary groups: [2020/05/14 09:46:37.381898, 5] ../../source3/auth/token_util.c:866(debug_unix_user_token) UNIX token of user 21678 Primary group is 21678 and contains 0 supplementary groups Also relevant errors seem to be: [2020/05/12 13:13:29.395726, 5] ../../source3/lib/username.c:120(Get_Pwnam_internals) Trying _Get_Pwnam(), username as lowercase is domain\user [2020/05/12 13:13:29.395740, 5] ../../source3/lib/username.c:159(Get_Pwnam_internals) Get_Pwnam_internals did find user [DOMAIN\user]! [2020/05/12 13:13:29.399159, 5] ../../source3/passdb/lookup_sid.c:1400(sid_to_uid) winbind failed to find a uid for sid S-1-5-21-DOMIAN_SID though I think that is to be expected at this point as we are not using winbind idmapping to map AD users, but rather we have an IPA - AD trust and so have local unix users already. On a successful connection/session we will see: [2020/05/14 10:08:29.078174, 5] ../../source3/auth/auth_generic.c:180(auth3_generate_session_info_pac) ../../source3/auth/auth_generic.c:180OK: user: user domain: DOMAIN client: [2020/05/14 10:08:29.078463, 4] ../../auth/auth_log.c:751(log_successful_authz_event_human_readable) Successful AuthZ: [SMB2,krb5] user [DOMAIN]\[user] [S-1-22-1-21678] at [Thu, 14 May 2020 10:08:29.078442 PDT] Remote host [ipv4:X.X.X.X:61595] local host [ipv4:X.X.X.X:445] {"timestamp": "2020-05-14T10:08:29.078943-0700", "type": "Authorization", "Authorization": {"version": {"major": 1, "minor": 1}, "localAddress": "ipv4:x.x.x.x:445", "remoteAddress": "ipv4:x.x.x.x:61595", "serviceDescription": "SMB2", "authType": "krb5", "domain": "DOMAIN", "account": "user", "sid": "S-1-22-1-21678", "sessionId": "7aaba59b-02c3-4c2f-b8c2-79f85a012d3c", "logonServer": "ADSERVER", "transportProtection": "SMB", "accountFlags": "0x00000214"}} [2020/05/14 10:08:29.181352, 5] ../../libcli/security/security_token.c:63(security_token_debug) Security token SIDs (37): will list S-1-22- type SIDs and we will get our supplementary groups: Primary group is 1001 and contains 33 supplementary groups I have seen unsuccessful AuthZ messages with type [SMB2,krb5] as well. Server is Scientific Linux release 7.8 samba-4.10.4-10.el7.x86_64 workgroup = DOMAIN security = ads realm = AD.DOMAIN # Workaround unix group issue (https://bugzilla.samba.org/show_bug.cgi?id=10618) username map script = /bin/echo Is the above now causing more issues? Recent changes that I can think of are then 7.8 update and configuring AD sites. Though I think this problem has likely been occurring for a long time - but for some reason we are seeing more connections left overnight. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 https://www.nwra.com/
Orion Poplawski
2020-May-14 18:24 UTC
[Samba] Users loose supplementary groups after a time
On 5/14/20 11:46 AM, Orion Poplawski wrote:> All - > > I seem to be suffering from the common complaint that users loose > supplementary group access after a while - in our case it seems to be > connections left overnight. Restarting smb fixes it. I haven't been able to > determine the cause. > > From the logs I've been able to determine a bad access looks something like > this: > > AuthZ reports a S-1-5-21- SID: > > [2020/05/14 09:49:40.474490, 4] > ../../auth/auth_log.c:751(log_successful_authz_event_human_readable) > Successful AuthZ: [lsarpc,ncacn_np] user [DOMAIN]\[user] > [S-1-5-21-DOMAIN_SID] at [Thu, 14 May 2020 09:49:40.474481 PDT] Remote host > [ipv4:Y.Y.Y.Y:54184] local host [ipv4:X.X.X.X:445] > {"timestamp": "2020-05-14T09:49:40.474546-0700", "type": "Authorization", > "Authorization": {"version": {"major": 1, "minor": 1}, "localAddress": > "ipv4:X.X.X.X:445", "remoteAddress": "ipv4:Y.Y.Y.Y:54184", > "serviceDescription": "lsarpc", "authType": "ncacn_np", "domain": "DOMAIN", > "account": "user", "sid": "S-1-5-21-DOMAIN_SID", "sessionId": > "50d682c6-196e-44fa-9999-abe8e33bfd1c", "logonServer": "ADSERVER", > "transportProtection": "SMB", "accountFlags": "0x00000214"}} > > then: > > [2020/05/14 09:46:37.381633, 5] > ../../libcli/security/security_token.c:63(security_token_debug) > Security token SIDs (39): > > and the SIDs listed will be domain SIDs prefixed by S1-5-21-. And we will get > 0 supplementary groups: > > > [2020/05/14 09:46:37.381898, 5] > ../../source3/auth/token_util.c:866(debug_unix_user_token) > UNIX token of user 21678 > Primary group is 21678 and contains 0 supplementary groups > > > Also relevant errors seem to be: > > [2020/05/12 13:13:29.395726, 5] > ../../source3/lib/username.c:120(Get_Pwnam_internals) > Trying _Get_Pwnam(), username as lowercase is domain\user > [2020/05/12 13:13:29.395740, 5] > ../../source3/lib/username.c:159(Get_Pwnam_internals) > Get_Pwnam_internals did find user [DOMAIN\user]! > [2020/05/12 13:13:29.399159, 5] > ../../source3/passdb/lookup_sid.c:1400(sid_to_uid) > winbind failed to find a uid for sid S-1-5-21-DOMIAN_SID > > though I think that is to be expected at this point as we are not using > winbind idmapping to map AD users, but rather we have an IPA - AD trust and so > have local unix users already. > > > On a successful connection/session we will see: > > [2020/05/14 10:08:29.078174, 5] > ../../source3/auth/auth_generic.c:180(auth3_generate_session_info_pac) > ../../source3/auth/auth_generic.c:180OK: user: user domain: DOMAIN client: > [2020/05/14 10:08:29.078463, 4] > ../../auth/auth_log.c:751(log_successful_authz_event_human_readable) > Successful AuthZ: [SMB2,krb5] user [DOMAIN]\[user] [S-1-22-1-21678] at [Thu, > 14 May 2020 10:08:29.078442 PDT] Remote host [ipv4:X.X.X.X:61595] local host > [ipv4:X.X.X.X:445] > {"timestamp": "2020-05-14T10:08:29.078943-0700", "type": "Authorization", > "Authorization": {"version": {"major": 1, "minor": 1}, "localAddress": > "ipv4:x.x.x.x:445", "remoteAddress": "ipv4:x.x.x.x:61595", > "serviceDescription": "SMB2", "authType": "krb5", "domain": "DOMAIN", > "account": "user", "sid": "S-1-22-1-21678", "sessionId": > "7aaba59b-02c3-4c2f-b8c2-79f85a012d3c", "logonServer": "ADSERVER", > "transportProtection": "SMB", "accountFlags": "0x00000214"}} > > [2020/05/14 10:08:29.181352, 5] > ../../libcli/security/security_token.c:63(security_token_debug) > Security token SIDs (37): > > will list S-1-22- type SIDs > > and we will get our supplementary groups: > > Primary group is 1001 and contains 33 supplementary groups > > I have seen unsuccessful AuthZ messages with type [SMB2,krb5] as well. > > > Server is Scientific Linux release 7.8 > samba-4.10.4-10.el7.x86_64 > > workgroup = DOMAIN > security = ads > realm = AD.DOMAIN > # Workaround unix group issue (https://bugzilla.samba.org/show_bug.cgi?id=10618) > username map script = /bin/echo > > Is the above now causing more issues? > > > Recent changes that I can think of are then 7.8 update and configuring AD > sites. Though I think this problem has likely been occurring for a long time > - but for some reason we are seeing more connections left overnight.So, the transition between the successful AuthZ and the unsuccessful ones appear to involve this (though I can find one example that doesn't): [2020/05/14 01:22:03.321905, 3] ../../source3/smbd/smb2_server.c:3201(smbd_smb2_request_error_ex) smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_NETWORK_SESSION_EXPIRED] || at ../../source3/smbd/smb2_server.c:2513 [2020/05/14 01:22:03.337393, 4] ../../source3/smbd/sec_ctx.c:320(set_sec_ctx_internal) setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0 [2020/05/14 01:22:03.337453, 5] ../../libcli/security/security_token.c:53(security_token_debug) Security token: (NULL) But perhaps that's just a side effect of long sessions as well. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 https://www.nwra.com/
On 14/05/2020 18:46, Orion Poplawski via samba wrote:> All - > > I seem to be suffering from the common complaint that users loose > supplementary group access after a while - in our case it seems to be > connections left overnight. Restarting smb fixes it. I haven't been able to > determine the cause. > > > though I think that is to be expected at this point as we are not using > winbind idmapping to map AD users, but rather we have an IPA - AD trust and so > have local unix users already.Yes, but is winbind running ?> Server is Scientific Linux release 7.8 > samba-4.10.4-10.el7.x86_64 > > workgroup = DOMAIN > security = ads > realm = AD.DOMAIN > # Workaround unix group issue (https://bugzilla.samba.org/show_bug.cgi?id=10618) > username map script = /bin/echo > > Is the above now causing more issues?I think it is what isn't there that is the problem> Recent changes that I can think of are then 7.8 update and configuring AD > sites. Though I think this problem has likely been occurring for a long time > - but for some reason we are seeing more connections left overnight.You do not say what you upgraded from, but 7.8 will now mean you have a Samba version >= 4.8.0 and from Samba 4.8.0 you need to run winbind if you have 'security = ADS' in smb.conf. This also means you need the 'idmap config' lines as well, which means you cannot have the same users in /etc/passwd. Rowland
Orion Poplawski
2020-May-14 20:59 UTC
[Samba] Users loose supplementary groups after a time
Sorry, I thought I had re-enabled delivery, but I had not. So trying to reply to Rowland Penny here:> On 14/05/2020 18:46, Orion Poplawski via samba wrote: >> All - >> >> I seem to be suffering from the common complaint that users loose >> supplementary group access after a while - in our case it seems to be >> connections left overnight. Restarting smb fixes it. I haven't been able to >> determine the cause. >> >> >> though I think that is to be expected at this point as we are not using >> winbind idmapping to map AD users, but rather we have an IPA - AD trust and so >> have local unix users already. > Yes, but is winbind running ?>> Server is Scientific Linux release 7.8 >> samba-4.10.4-10.el7.x86_64 >> >> workgroup = DOMAIN >> security = ads >> realm = AD.DOMAIN >> # Workaround unix group issue (https://bugzilla.samba.org/show_bug.cgi?id=10618) >> username map script = /bin/echo >> >> Is the above now causing more issues? > I think it is what isn't there that is the problem >> Recent changes that I can think of are then 7.8 update and configuring AD >> sites. Though I think this problem has likely been occurring for a long time >> - but for some reason we are seeing more connections left overnight. > > You do not say what you upgraded from, but 7.8 will now mean you have a > Samba version >= 4.8.0 and from Samba 4.8.0 you need to run winbind if > you have 'security = ADS' in smb.conf. This also means you need the > 'idmap config' lines as well, which means you cannot have the same users > in /etc/passwd.I upgraded from 7.7. And yes since we've had samba >= 4.8.0 for a while now we've been running winbind. This configuration (dropping the username map script hack) seems to be working for us, does this seem correct? idmap config * : backend = tdb idmap config * : range = 1000000-1999999 idmap config DOMAIN : backend = nss idmap config DOMAIN : range = 1000-999999 winbind scan trusted domains = no -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 https://www.nwra.com/
On 14/05/2020 21:59, Orion Poplawski via samba wrote:> Sorry, I thought I had re-enabled delivery, but I had not. So trying to reply > to Rowland Penny here: > >> On 14/05/2020 18:46, Orion Poplawski via samba wrote: >>> All - >>> >>> I seem to be suffering from the common complaint that users loose >>> supplementary group access after a while - in our case it seems to be >>> connections left overnight. Restarting smb fixes it. I haven't been able to >>> determine the cause. >>> >>> >>> though I think that is to be expected at this point as we are not using >>> winbind idmapping to map AD users, but rather we have an IPA - AD trust and so >>> have local unix users already. >> Yes, but is winbind running ?>> Server is Scientific Linux release 7.8 >>> samba-4.10.4-10.el7.x86_64 >>> >>> workgroup = DOMAIN >>> security = ads >>> realm = AD.DOMAIN >>> # Workaround unix group issue (https://bugzilla.samba.org/show_bug.cgi?id=10618) >>> username map script = /bin/echo >>> >>> Is the above now causing more issues? >> I think it is what isn't there that is the problem >>> Recent changes that I can think of are then 7.8 update and configuring AD >>> sites. Though I think this problem has likely been occurring for a long time >>> - but for some reason we are seeing more connections left overnight. >> You do not say what you upgraded from, but 7.8 will now mean you have a >> Samba version >= 4.8.0 and from Samba 4.8.0 you need to run winbind if >> you have 'security = ADS' in smb.conf. This also means you need the >> 'idmap config' lines as well, which means you cannot have the same users >> in /etc/passwd. > I upgraded from 7.7. And yes since we've had samba >= 4.8.0 for a while now > we've been running winbind. > > This configuration (dropping the username map script hack) seems to be working > for us, does this seem correct? > > idmap config * : backend = tdb > idmap config * : range = 1000000-1999999 > idmap config DOMAIN : backend = nss > idmap config DOMAIN : range = 1000-999999 > winbind scan trusted domains = noYes, that should work for your setup. It will map your local users to IPA users. It isn't the way that I would do it though ;-) From what you have posted, you are mapping local users to IPA users and the IPA is in a trust with AD, I would just ignore IPA and join the computer to AD and get your users and groups directly. If you have AD, why not leverage it and have all users & groups stored in AD ? Rowland