samba - Dec 2021 - Authentication issue after updating samba on CentOS 7 (from yum)

On Wed, 2021-12-22 at 17:12 +0300, Alex via samba wrote:
> Hello,
> 
> After updating from samba-4.10.16-15.el7_9.x86_64 to samba-4.10.16-
> 17.el7_9.x86_64 our users are no longer able to get to samba shares.
> Besides that, winbindd and samba logs are getting flooded (even when
> nobody tries to get to a share):
> winbindd.log:
> ...
> [2021/12/22 16:21:32.350675,  3]
> ../../auth/kerberos/kerberos_pac.c:413(kerberos_decode_pac)
>   Found account name from PAC: username [Firstname Lastname]
> [2021/12/22 16:21:33.426925,  3]
> ../../source3/winbindd/winbindd_misc.c:432(winbindd_interface_version
> )
>   winbindd_interface_version: [smbd (5383)]: request interface
> version (version = 31)
> [2021/12/22 16:21:33.427150,  3]
> ../../source3/winbindd/winbindd_misc.c:470(winbindd_priv_pipe_dir)
>   winbindd_priv_pipe_dir: [smbd (5383)]: request location of
> privileged pipe
> [2021/12/22 16:21:33.429703,  3]
> ../../auth/kerberos/kerberos_pac.c:413(kerberos_decode_pac)
>   Found account name from PAC: username [Firstname Lastname]
> [2021/12/22 16:21:33.512604,  3]
> ../../source3/winbindd/winbindd_misc.c:432(winbindd_interface_version
> )
>   winbindd_interface_version: [smbd (5385)]: request interface
> version (version = 31)
> [2021/12/22 16:21:33.512853,  3]
> ../../source3/winbindd/winbindd_misc.c:470(winbindd_priv_pipe_dir)
>   winbindd_priv_pipe_dir: [smbd (5385)]: request location of
> privileged pipe
> [2021/12/22 16:21:33.515820,  3]
> ../../auth/kerberos/kerberos_pac.c:413(kerberos_decode_pac)
>   Found account name from PAC: username [Firstname Lastname]
> ...
> 
> 172.26.10.1.log:
> ...
> [2021/12/22 16:21:33.454953,  3]
> ../../source3/smbd/oplock.c:1422(init_oplocks)
>   init_oplocks: initializing messages.
> [2021/12/22 16:21:33.455252,  3]
> ../../source3/smbd/process.c:1948(process_smb)
>   Transaction 0 of length 108 (0 toread)
> [2021/12/22 16:21:33.455648,  3]
> ../../source3/smbd/smb2_negprot.c:293(smbd_smb2_request_process_negpr
> ot)
>   Selected protocol SMB2_10
> [2021/12/22 16:21:33.522077,  3]
> ../../source3/auth/auth_util.c:1877(check_account)
>   Failed to find authenticated user DOMAIN\username via getpwnam(),
> denying access.
> [2021/12/22 16:21:33.522316,  3]
> ../../source3/smbd/smb2_server.c:3213(smbd_smb2_request_error_ex)
>   smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1]
> status[NT_STATUS_LOGON_FAILURE] || at
> ../../source3/smbd/smb2_sesssetup.c:146
> [2021/12/22 16:21:33.524042,  3]
> ../../source3/smbd/server_exit.c:236(exit_server_common)
>   Server exit (NT_STATUS_CONNECTION_RESET)
> ...
> 
> I've rolled back to 4.10.16-15 and things got back to work.
> 
> Here is the changelog: 
> https://access.redhat.com/errata/RHSA-2021:5192
> 
> I understand you don't care much about packaged versions, but
> probably you could help me figure out what should be changed in the
> config to get latest version working.
It is not that we don't care about packaged versions, it is that a
problem may have been fixed in a later version of Samba.
> 
> smb.conf:
> [global]
>    workgroup = DOMAIN
>    server string = vm-corp
>    netbios name = VM-CORP
>    realm = DOMAIN.BIZ
>    security = ads
>    template shell = /sbin/nologin
So, your users never log into the server directly, just via Samba.
>    kerberos method = secrets and keytab
> 
>     log file = /var/log/samba/%m.log
>     log level = 3
>     max log size = 1000
> 
>     idmap config * : backend = tdb
>     idmap config * : range = 16777216-33554431
Is there some reason for that range ? It will allow you 16777215 users
& groups for something that requires only about 200.
> 
>     idmap config DOMAIN:backend = ad
>     idmap config DOMAIN:schema_mode = rfc2307
>     idmap config DOMAIN:range = 400-999999
Again why the strange range, do you have users & groups with uidNumber
& gidNumber attributes that low ?
>     idmap config DOMAIN:unix_primary_group = yes
Do your users have gidNumber attributes.
>     idmap config DOMAIN:unix_nss_info = yes
This is interesting, you only need that if your users have a
unixHomeDirectory attribute (at least), yet you are not using '[homes]'
below.
> 
>    winbind use default domain = true
>    winbind offline logon = false
>    winbind enum users = Yes
>    winbind enum groups = Yes
You do not need the 'enum' lines, it works without them.
>    winbind cache time = 15
>    winbind refresh tickets = Yes
>    winbind expand groups = 5
> 
>     vfs objects = acl_xattr
>     map acl inherit = yes
>     store dos attributes = yes
> 
>     load printers = No
>     domain master = no
>     local master = no
>     preferred master = no
>     server min protocol = SMB2
>     use sendfile = yes
>     dos charset = CP866
> 
>     veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/
>     veto files = /*:Zone.Identifier:*/
> 
> [username]
>         comment = username's home
>         path = /home/username
>         read only = No
>         create mode = 0660
>         valid users = username
As noted above, why are you not using '[homes]' ?
> 
> I tried to create the username_map_script.sh and add the following
> lines (as mentioned in 
> https://bugzilla.samba.org/show_bug.cgi?id=14901):
>     min domain uid = 500
Try changing the '500' to '0'
>     username map script = /etc/samba/username_map_script.sh
Change that to:
username map script = /etc/samba/user.map

Create /etc/samba/user.map containing:

!root = DOMAIN\Administrator

Rowland

Hello Rowland,

Thank you for your prompt reply!

[skip]
>> 
>> smb.conf:
>> [global]
>>    workgroup = DOMAIN
>>    server string = vm-corp
>>    netbios name = VM-CORP
>>    realm = DOMAIN.BIZ
>>    security = ads
>>    template shell = /sbin/nologin
> So, your users never log into the server directly, just via Samba.
Most users don't. Some of them that are allowed have a shell defined in the
AD (loginShell attribute).
>>     idmap config * : backend = tdb
>>     idmap config * : range = 16777216-33554431
> Is there some reason for that range ? It will allow you 16777215 users
> & groups for something that requires only about 200.
I think it's a legacy. Don't remember why it's here. I'll try to
remove it.
>>     idmap config DOMAIN:backend = ad
>>     idmap config DOMAIN:schema_mode = rfc2307
>>     idmap config DOMAIN:range = 400-999999
> Again why the strange range, do you have users & groups with uidNumber
> & gidNumber attributes that low ?
This is also a legacy thing. There're users in the AD with uidNumber
starting from 400.
>>     idmap config DOMAIN:unix_primary_group = yes
> Do your users have gidNumber attributes.
Yes, they do. This came from MS Services for Unix.
>>     idmap config DOMAIN:unix_nss_info = yes
> This is interesting, you only need that if your users have a
> unixHomeDirectory attribute (at least), yet you are not using
'[homes]'
> below.
Yes, they do have unixHomeDirectory attribute.
>>    winbind use default domain = true
>>    winbind offline logon = false
>>    winbind enum users = Yes
>>    winbind enum groups = Yes
> You do not need the 'enum' lines, it works without them.
There was an issue w/o the enum lines. Unfortunately, I don't remember
exactly what it was, probably couldn't retrieve groups from the AD with
"getent group" command.
>> [username]
>>         comment = username's home
>>         path = /home/username
>>         read only = No
>>         create mode = 0660
>>         valid users = username
> As noted above, why are you not using '[homes]' ?
It's b/c most users are prohibited from using this server. So, I allowed
homes on this server for just a few of them directly.
>> 
>> I tried to create the username_map_script.sh and add the following
>> lines (as mentioned in 
>> https://bugzilla.samba.org/show_bug.cgi?id=14901):
>>     min domain uid = 500
> Try changing the '500' to '0'
>>     username map script = /etc/samba/username_map_script.sh
> Change that to:
> username map script = /etc/samba/user.map
> Create /etc/samba/user.map containing:
> !root = DOMAIN\Administrator
Assuming you meant "username map = /etc/samba/user.map" here. I did
that both (changed min uid to 0 and set a user.map file) - still can't log
in :(

-- 
Best regards,
Alexander Kolesnik