[Samba] Users loose supplementary groups after a time

Thu May 14 18:24:23 UTC 2020

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/