user(add).chshell not available on Debian Buster

(I was sent here by The Docs.)

Description of Issue

I'm on Debian Buster/10. Trying to change a user's default shell (in this case to zsh) with user.chsell or useradd.chshell fails:

     ...
     Comment: State 'user.chshell' was not found in SLS 'zsh'
              Reason: 'user.chshell' is not available.
     ...

Setup

I'm using salt to manage my dotfiles config, so I'm running masterless. The minion file looks like this:

file_roots:
  base:
    - ./
file_client: local

...

There is a state 'zsh' which is applied to all targets.

The user is stored in the pillar and is successfully accessed in other states with pillar['user']. I want to set the user's default shell to zsh, which is installed by another state. which zsh gives me /usr/bin/zsh.

I have my pillar data in pillar/pillar.sls, so my deployment command is:

sudo salt-call --config-dir=./ --pillar-root=./pillar state.apply

Steps to Reproduce Issue

zsh/init.sls includes the following state:

zsh-default-shell:
  user.chshell:
    - name: {{ pillar['user'] }}
    - shell: /usr/bin/zsh

On running the above deployment command I get all states succeed except zsh-default-shell:

...
----------
          ID: zsh-default-shell
    Function: user.chshell
        Name: <user redacted>
      Result: False
     Comment: State 'user.chshell' was not found in SLS 'zsh'
              Reason: 'user.chshell' is not available.
     Changes:   
----------
...

I've tried removing as many variables as I can (e.g. removing the templating and hard-coding the user, or using useradd.chshell explicitly) and got the same error. This and the error report itself make it fairly clear that the problem is the useradd executable.

What's strange though is that sudo which useradd gives me /usr/sbin/usermod, and of course I can run usermod (even without specififying the path) as root or with sudo, and change things from the cli. So salt is failing to find something which is there (though it might be in the wrong place?).

Clearly, the desired behaviour is that salt finds usermod and sets the shell.

Versions Report

Salt Version:
Salt: 3002.2

Dependency Versions:
cffi: 1.14.3
cherrypy: Not Installed
dateutil: 2.7.3
docker-py: Not Installed
gitdb: 2.0.5
gitpython: 2.1.11
Jinja2: 2.11.2
libgit2: Not Installed
M2Crypto: Not Installed
Mako: 1.0.7
msgpack: 0.5.6
msgpack-pure: Not Installed
mysql-python: Not Installed
pycparser: 2.20
pycrypto: 2.6.1
pycryptodome: 3.6.1
pygit2: Not Installed
Python: 3.7.3 (default, Jul 25 2020, 13:03:44)
python-gnupg: Not Installed
PyYAML: 3.13
PyZMQ: 17.1.2
smmap: 2.0.5
timelib: Not Installed
Tornado: 4.5.3
ZMQ: 4.3.1

System Versions:
dist: debian 10 buster
locale: UTF-8
machine: x86_64
release: 4.19.0-13-amd64
system: Linux
version: Debian GNU/Linux 10 buster

Start by reproducing the failure with the documented salt-call command and the user.chshell or useradd.chshell state on Debian Buster. Trace the provider lookup for usermod and verify that the state can locate it and set the shell to /usr/bin/zsh.