Mdthbs

this would be for whatever Samba versions are in RHEL/CentOS >= 7.6.

I think Samba >= 4.8.

for each user account to be able to have samba access I do smbpasswd -a <user>. As such the user's system login password is independent of the samba password.

Is there a way such that

• a user NEVER has to do smbpasswd
  


• samba works off the password from /etc/shadow
  

The problem: incompatible password hashing methods

Back in Windows NT4 / Windows 2000 era, it was possible - and in fact fairly common - to set up Samba authentication in the way that would satisfy your requirements. But even back then, Samba documentation strongly recommended against doing that, because it had one big glaring security flaw: it required the passwords to be sent unencrypted over the network. Even back then, it was a bad idea; with modern ubiquity of wireless networks and bring-your-own-device solutions, sending passwords unencrypted over the network is completely unacceptable.

Neither Windows nor Linux stores system passwords in plaintext. Instead, the password and a salt value are one-way hashed, and the salt value and the resulting hash are stored. As a result, nothing and nobody (not even the system administrator) can easily recover the plaintext version for your password from the stored hashes for any purpose. It would always require bruteforcing or massive rainbow tables.

When a password needs to be checked, the stored password is not decrypted, because that is essentially impossible. Instead, the algorithm looks up the salt value of the user in question, and uses that to hash the password entered by the user, and then compares the resulting hash with the stored hash: if they match exactly, the password was correct.

Doing this over the network requires still more protection. If the server would just give the salt value to the client and wait for the client to supply a hashed password, the data passed over the network would be password-equivalent and an attacker listening in could simply reuse the hashes as-is with a modified evil client. This was known as the "replay attack", or "pass-the-hash attack".

As a result, when a Windows or Samba client produces an encrypted authentication packet to be passwd over the network, it needs to use a hashing scheme that is compatible with the replay attack protection. But this also makes it impossible for the server to return the Windows-style password hash to a plaintext form it would need to begin checking it against the hashes in /etc/shadow.

The solution

The only place this could be fixed is the password changing process: at that point, the plaintext version of the password must necessarily be known to the server so that it can be hashed and stored. It is in fact possible to modify this process to update both the system login password and the Samba password at the same time.

If your Samba servers are not domain controllers, you can enable the unix password sync parameter in smb.conf file, and specify the passwd program to allow Samba to automatically update the corresponding system login password whenever a Samba password is updated. If you do this, you would need to instruct your users to always use smbpasswd, never passwd.

Alternatively, you could add the PAM module pam_smbpass.so to the PAM configuration of the system. It is available as a RPM package for both RHEL/CentOS 6.x and 7.x.

There are two ways to use pam_smbpass.so: either use the Samba password storage as the primary system password storage for all services using PAM (and essentially everything uses PAM, unless you have a need to use some horrible built-from-ancient-source legacy Unix program), or just plug it in the PAM-based password-changing process so that the regular passwd command (or any other PAM-based method to update the system login password) will update both /etc/shadow and the Samba password at the same time. Then your users could always use passwd and never smbpasswd.

Unless you're planning on a large-scale user roll-out with Samba, I would strongly suggest doing it the way you are. Samba basically has (2) choices for usernames/passwords database backends: tdbsam (the default) or ldapsam. If you want to install/configure ldap, then you can setup Samba to use it. Check out man smb.conf for more details.

EDIT: you can also get Samba to authenticate through a Windows domain controller.