Debian Buster and Samba AD integration (member server)

[DaIceMan]

Hi all,
I have setup the latest debian Buster 10.3 and Samba 4.9.5 and PAM - kerberos - sssd authentication. After setting up the realm and joining AD ssh using AS account logins work as expected and home directories are created. However AD users are unable to authenticate correctly to Samba shares on the debian server - or more specifically - they do authenticate but there is a failure in MAPPING the UID of the user from the AD SID (failed to add local groups):

[2020/04/27 21:57:39.078817, 3] ../source3/param/loadparm.c:1621(lp_add_ipc)
adding IPC service
[2020/04/27 21:57:39.078872, 5] ../source3/lib/username.c:181(Get_Pwnam_alloc)
Finding user GIEMMENET\daiceman
[2020/04/27 21:57:39.078905, 5] ../source3/lib/username.c:120(Get_Pwnam_internals)
Trying _Get_Pwnam(), username as lowercase is DOMAIN\daiceman
[2020/04/27 21:57:39.078928, 5] ../source3/lib/username.c:159(Get_Pwnam_internals)
Get_Pwnam_internals did find user [DOMAIN\daiceman]!
[2020/04/27 21:57:39.079723, 1] ../source3/auth/token_util.c:561(add_local_groups)
SID S-1-5-21-682003330-2146849767-839522115-8621 -> getpwuid(100002) failed
[2020/04/27 21:57:39.079773, 3] ../source3/auth/token_util.c:400(create_local_nt_token_from_info3)
Failed to add local groups
[2020/04/27 21:57:39.079796, 1] ../source3/auth/auth_generic.c:174(auth3_generate_session_info_pac)
Failed to map kerberos pac to server info (NT_STATUS_UNSUCCESSFUL)
[2020/04/27 21:57:39.079886, 3] ../source3/smbd/smb2_server.c:3195(smbd_smb2_request_error_ex)
smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_ACCESS_DENIED] || at ../source3/smbd/smb2_sesssetup.c:137
[2020/04/27 21:57:39.079989, 5] ../lib/dbwrap/dbwrap.c:130(dbwrap_lock_order_lock)
dbwrap_lock_order_lock: check lock order 1 for /var/run/samba/smbXsrv_session_global.tdb
[2020/04/27 21:57:39.080040, 5] ../lib/dbwrap/dbwrap.c:159(dbwrap_lock_order_unlock)
dbwrap_lock_order_unlock: release lock order 1 for /var/run/samba/smbXsrv_session_global.tdb
[2020/04/27 21:57:39.086900, 4] ../source3/smbd/sec_ctx.c:320(set_sec_ctx_internal)
setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0
[2020/04/27 21:57:39.086944, 5] ../libcli/security/security_token.c:53(security_token_debug)
Security token: (NULL)
[2020/04/27 21:57:39.086964, 5] ../source3/auth/token_util.c:866(debug_unix_user_token)
UNIX token of user 0
Primary group is 0 and contains 0 supplementary groups
[2020/04/27 21:57:39.087007, 5] ../source3/smbd/uid.c:509(smbd_change_to_root_user)
change_to_root_user: now uid=(0,0) gid=(0,0)
[2020/04/27 21:57:39.087031, 4] ../source3/smbd/sec_ctx.c:320(set_sec_ctx_internal)
setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0
[2020/04/27 21:57:39.087049, 5] ../libcli/security/security_token.c:53(security_token_debug)
Security token: (NULL)

wbinfo -u and -g returns all users and group correctly. Id <username@domain> returns the user info with relevant gid group(s):

#id daiceman@domain
uid=854208621(daiceman@domain.com) gid=854200513(domain users@domain.com) groups=854200513(domain domain.com)

id mapping in the smb.conf is:

idmap config * : backend = tdb
idmap config * : range = 7000-7999
idmap config DOMAIN : backend = sss
idmap config DOMAIN : range = 100000-999999999
template shell = /bin/bash

I have tried re-joining the domain (using net ads join) several times and it always succeeds - I also deleted the sssd cache files. As per recent modifications to the smbd demon the winbind daemon is running to complement for the moved calls. Any suggestions on what could be the culprit? There must be something I missed in the idmap but the range seems to include the mapped SID.

Thanks!

[DaIceMan]

I apparently maaged to fix it: I deleted the samba cache files under /var/lib/samba/ specifically the gencache.tdb file and restarted sssd and smbd services - now it maps the user correctly. Probably this is due to starting the smbd and sssd daemons after install with an incorrect config which is retained even after editing the smb.conf file as the mapped SIDs are cached and not updated - so remember to delete the tdb cache files every time you modify the idmap config mapping settings in smb.conf!

[DaIceMan]

Well - I was too fast on this: I can login with one user but can't with others - same error even after deleting the cache. Restarting the service and re-joining the domain doesn't help...