pam_winbind should reject disabled users

Can you double-check that your pam configuration for pam_winbind is configured to use required or requisite rather than sufficient?

It's possible that the required or requisite defaults aren't sufficient but may still be possible to configure using the more complicated pam syntax. Search for 'valueN' in /usr/share/doc/libpam-doc/txt/Linux-PAM_SAG.txt.gz for some details. I don't know off-hand if the pam_winbind module supports these finer-grained controls but it's possible it does.

Thanks

It is, I believe, the default line added by pam-auth-update:

#
# /etc/pam.d/common-account - authorization settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authorization modules that define
# the central access policy for use on the system. The default is to
# only deny service to users whose accounts are expired in /etc/shadow.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.
#

# here are the per-package modules (the "Primary" block)
account [success=2 new_authtok_reqd=done default=ignore] pam_unix.so
account [success=1 new_authtok_reqd=done default=ignore]
 pam_winbind.so
# here's the fallback if no module succeeds
account requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required pam_permit.so
# and here are more per-package modules (the "Additional" block)
account required pam_krb5.so minimum_uid=1000
# end of pam-auth-update config

Thanks,
John Runyon

On Fri, 29 Jan 2021 at 21:45, Seth Arnold <email address hidden>
wrote:

> Can you double-check that your pam configuration for pam_winbind is
> configured to use required or requisite rather than sufficient?
>
> It's possible that the required or requisite defaults aren't sufficient
> but may still be possible to configure using the more complicated pam
> syntax. Search for 'valueN' in /usr/share/doc/libpam-doc/txt/Linux-
> PAM_SAG.txt.gz for some details. I don't know off-hand if the
> pam_winbind module supports these finer-grained controls but it's
> possible it does.
>
> Thanks
>
> ** Information type changed from Private Security to Public Security
>
> ** Changed in: samba (Ubuntu)
> Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1913851
>
> Title:
> pam_winbind should reject disabled users
>
> Status in samba package in Ubuntu:
> Incomplete
>
> Bug description:
> pam_winbind should reject disabled users. Currently, disabled accounts
> are instead treated as disabled passwords, which means that they can
> still be logged into through other credentials.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 18.04
> Package: libpam-winbind 2:4.7.6+dfsg~ubuntu-0ubuntu2.21
> ProcVersionSignature: Ubuntu 4.15.0-135.139-generic 4.15.18
> Uname: Linux 4.15.0-135-generic x86_64
> ApportVersion: 2.20.9-0ubuntu7.21
> Architecture: amd64
> Date: Fri Jan 29 20:36:50 2021
> InstallationDate: Installed on 2018-05-02 (1003 days ago)
> InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64
> (20180426)
> OtherFailedConnect: Yes
> ProcEnviron:
> ...

[Expired for samba (Ubuntu) because there has been no activity for 60 days.]

Thanks for the bug report and apologies for the delay in getting back to you.

I configured a Bionic VM acting as an AD member, joined the AD, and then disabled one of the users in the AD DC. I noticed that issuing a "login <email address hidden>" correctly displays the following message:

# login <email address hidden>
Password: xxxx
Your account has been locked. Please contact your System administrator

Login incorrect
#

I'm afraid I don't fully understand what you meant by "which means that they can still be logged into through other credentials." What credentials are you referring to here? If you could provide steps to reproduce what you meant, that would be very helpful.

Thank you.

Hi,

My concern specifically centers around SSH key auth, but in more general terms, Ubuntu makes a distinction between an account being locked, and a password being locked. So far as I can tell, Samba/AD do not make that distinction, but in any case the operation 'samba-tool user disable <account>' is described as disabling a "user". However, it does not disable a user in the same sense as other tools do. For example, 'passwd -l <account>' will disable password login, but not other ways to log in to a user account. 'usermod -e 1 <account>' however will disable other methods:

$ ssh test@foo echo yay
yay

# passwd -l test
$ ssh test@foo echo yay
yay

# usermod -e 1 test
$ ssh <email address hidden> echo yay
Your account has expired; please contact your system administrator
Connection closed by ...

(This last case is rejected by pam_unix at the account stage: "pam_unix(sshd:account): account test has expired (account expired)")

IMHO, the account stage of pam_winbind should do the same for disabled users.

(To clarify my first paragraph: 'samba-tool user disable' has a similar effect to 'passwd -l', but the phraseology and description from --help, as well as the phraseology in the Microsoft AD Users & Computers tool, imply that it should have a similar effect to 'usermod -e 1')

Thank you for the further details.

Indeed, I was able to reproduce and confirm this locally. It is a limitation of winbind. In fact, I have found an upstream bug about this problem:

https://bugzilla.samba.org/show_bug.cgi?id=14622

The "good news" is that upstream is aware of such limitation. The bad news is that the person who was trying to implement the PAM account support on winbind has lost interest in doing so.

Anyway, I'm marking this bug as triaged and linking the upstream bug, but unfortunately we won't be able to do much here unless upstream takes the lead on this. Sorry about it.

FWIW, as a workaround what you can do is create a group which contains disabled users on the AD (e.g., "DisabledUsers"), and add the following directive to /etc/ssh/sshd_config:

DenyGroups DisabledUsers

Then, whenever you disable a user on the AD you also include it into the "DisabledUsers" group. You probably knew that already, but I'm leaving it here in case someone else faces the same problem.