Lockout feature is broken for enterprise environments

[abbra]

FreeIPA core developer here.

I looked at fleetDM's code around locking out the workstations, as introduced by https://github.com/fleetdm/fleet/pull/15501 and it is a mess. On Windows "disable workstation" powershell script simply disables one user, local Administrator. This does not disable access to the machine from any of the enterprise accounts at all. This is very much not a 'lockout' feature.

Linux lockout code iterates /etc/passwd for any account that has uid between 1000 and 60000 and disables them individually. This does not work at all for enterprise accounts, either in Active Directory environment or in IPA case. For each of those environments typically users aren't present in /etc/passwd at all, they get supplied by a corresponding NSS module via /etc/nsswitch.conf configuration. Two most commonly used solutions for integrating with Active Directory and FreeIPA are SSSD and Samba's winbindd. In both cases (nss_sss.so and nss_winbind.so) NSS modules expose users and groups without putting them into /etc/passwd and /etc/group. They should be disabled globally by the administrative tools (in Active Directory or in FreeIPA). For both AD and IPA environments the lockout script thus will see zero users and will do nothing.

On top of that, for any of those users passwd -l <username> will not work as well because this tool has no administrative permissions to disable accounts in Active Directory/FreeIPA. Typically, a domain member system machine account has only read-only permissions to query centralized databases but not modify them. In addition to that, passwd tool has no access to the machine account credentials. For the non-local accounts passwd -l will always fail.

This is not all, though. In Active Directory case, by default SSSD would use SID-based UID/GID generation that results in POSIX IDs above 100K. In IPA case default ID range is always above 200K. See https://freeipa.readthedocs.io/en/latest/designs/id-mapping.html for description of how identity mapping happens in FreeIPA environment.

If you want to disable all but root access to Linux workstations, a recommended way is to use pam_nologin. This is already integrated in most distributions. For example, Fedora and RHEL have this:

# fgrep -r nologin /etc/pam.d
/etc/pam.d/gdm-autologin:account    required    pam_nologin.so
/etc/pam.d/gdm-fingerprint:account     required      pam_nologin.so
/etc/pam.d/gdm-password:account     required      pam_nologin.so
/etc/pam.d/gdm-smartcard:account     required      pam_nologin.so
/etc/pam.d/login:account    required     pam_nologin.so
/etc/pam.d/ppp:account    required  pam_nologin.so
/etc/pam.d/remote:account    required     pam_nologin.so
/etc/pam.d/samba:auth       required    pam_nologin.so
/etc/pam.d/sshd:account    required     pam_nologin.so
/etc/pam.d/vmtoolsd:account    required     pam_nologin.so

So all you need to do is to touch /etc/nologin empty file. Or add some content to it and it will be show to a user attempting to login. See man page for pam_nologin(8).

[lukeheath]

@abbra Thanks for filing this bug and letting us know! It sounds like @georgekarrv has reproduced and brought into the release board for a fix.

[PezHub]

QA Notes: Setup a FreeIPA server and enrolled a Fedora host to test. The script works as expected locking out the user however upon restart the same user is able to login due to the /etc/nologin file getting deleted.

[dantecatalfamo]

After some research it appears that systemd modifies /etc/nologin according to systemd-user-sessions, which didn't used to be the case. The fix for this should be to disable systemd-user-sessions to stop it from deleting /etc/nologin on boot.

• https://github.com/systemd/systemd/issues/26965
• https://www.freedesktop.org/software/systemd/man/latest/systemd-user-sessions.service.html

[dantecatalfamo]

It appears that there's no official way to disable the systemd-user-sessions service. The solution to this will likely be modifying the systemd service file

[dantecatalfamo]

Apparently despite not being able to disable the service, you can mask it, which is a better alternative to modifying the service file

[PezHub]

QA Notes: Looking good after the fix. I can no longer bypass the lockout with a restart and the unlock script works as expected too.

lock succeeded -

unlock succeeded -

[fleet-release]

Lockout fix ahead, In enterprise clouds it threads, Ensuring peace spreads.