Route PAM Policy by Account Type with pam_usertype

You will add a reviewed PAM rule that can recognise system and regular accounts, while keeping the existing authentication stack intact. The examples use pam_usertype from Linux-PAM package version 1.5.3-5ubuntu5.7 on this machine. Allow about fifteen minutes for inspection and review. A live PAM edit can lock users out, so the configuration example is deliberately shown before any change is made.

1. Inspect the installed module and account boundary

Start with ordinary, read-only checks. The package owns the module at the path below, and the manual page describes the configuration interface:

$ dpkg-query -W -f='${Package} ${Version}\n' libpam-modules:amd64
libpam-modules 1.5.3-5ubuntu5.7
$ test -r /usr/lib/x86_64-linux-gnu/security/pam_usertype.so && echo 'module present'
module present
$ grep -E '^[[:space:]]*(UID_MIN|SYS_UID_MAX)[[:space:]]' /etc/login.defs
UID_MIN                 1000

Your package version, module path and output may differ. The relevant point is that pam_usertype reads the account classification from /etc/login.defs. It is not simply checking whether a user has a home directory, a login shell or a name that looks like a service name.

On this host, UID_MIN is 1000 and there is no SYS_UID_MAX setting. Do not copy that boundary to another host. Distribution defaults and local policy can differ, and changing /etc/login.defs changes how this test classifies accounts. Inspect the file before relying on a result.

2. Choose the condition

The module accepts one condition. Use issystem when the rule should succeed for a system account, or isregular when it should succeed for a regular account. The condition is required: a line with only flags, or with neither condition, is a service configuration error.

Use only one of those conditions in a module line. If you need both paths, write separate rules in the surrounding PAM design rather than putting both conditions on one line and assuming that means "either". The module's documented contract is one condition per invocation.

3. Understand the PAM control flag

The module's result is useful only in the context of the control flag in the PAM stack. This is the common routing pattern from the module manual:

account sufficient pam_usertype.so issystem

With sufficient, a successful system-account test can return success immediately when no earlier required module has failed, so later account modules are skipped. A failed sufficient test is ignored and evaluation continues. That makes this line suitable for a deliberate "system accounts take this fast path" design, but it is not an unconditional allow rule.

Do not change an existing auth, account, password or session stack casually. PAM evaluates each module type separately, and this module provides all four types. A line copied into the wrong type can affect a different phase from the one you intended. The simplest first design is usually an account rule in a dedicated service whose whole stack you understand.

4. Review a dedicated service snippet

Before editing a live file, prepare the smallest possible service configuration in a reviewable location. This example selects system users during the account phase:

# /etc/pam.d/account-type-check
account sufficient pam_usertype.so issystem

The example is a configuration shape, not a complete service. It does not authenticate anyone by itself, and it does not tell PAM what to do for a regular user after the test fails. A real service needs a complete, intentional stack and a safe test harness supplied by the application or your distribution.

Before installing even this small file, check its syntax against the local manual and compare it with the application documentation. If you do make a change as root, preserve the original first:

$ sudo cp --preserve=mode,ownership,timestamps /etc/pam.d/account-type-check /etc/pam.d/account-type-check.bak

That backup command assumes the file already exists. For a new file, save the proposed contents elsewhere, review them, then install the file with permissions appropriate to your host. Do not overwrite a distribution-managed PAM file merely to make this example fit.

5. Account for the selected identity

By default, the module evaluates the account named by PAM, normally the user being authenticated. Add use_uid only when the PAM application requires the test to use the UID of the process running the application instead:

account sufficient pam_usertype.so use_uid issystem

This is a security-sensitive distinction. For a login service, the process UID is often a service or privileged UID, not the person requesting access. Adding use_uid to make a confusing test "pass" can classify the wrong identity and route the wrong policy. Confirm the PAM application's identity model before using it.

The optional audit flag asks the module to log unknown users to the system log:

account sufficient pam_usertype.so audit issystem

It does not turn an unknown user into a system or regular account. Unknown users remain a failure result, and an unparseable argument or missing condition is a service error. If diagnostics are needed, collect the relevant journal or syslog entry without treating a missing log line as proof that the condition was true.

6. Verify without weakening the real stack

First check the edited file and the module path as root, without starting a login service or restarting anything:

$ sudo sed -n '1,80p' /etc/pam.d/account-type-check
account sufficient pam_usertype.so issystem
$ dpkg-query -S /usr/lib/x86_64-linux-gnu/security/pam_usertype.so
libpam-modules:amd64: /usr/lib/x86_64-linux-gnu/security/pam_usertype.so

Then exercise the dedicated service only through a PAM-aware test application that your system already approves. Use a non-critical test account and a console or second administrative session. Do not invent a shell command that loads the module directly: the module needs a PAM handle, a module type and an application conversation method.

For a non-production test, check the account identities you intend to use before running the test:

$ getent passwd root
root:x:0:0:root:/root:/bin/bash
$ getent passwd YOUR_REGULAR_USER
YOUR_REGULAR_USER:x:1000:1000:...

Replace YOUR_REGULAR_USER with a real test account. The UID shown here is evidence about the account database, not a substitute for checking /etc/login.defs and the exact PAM result. Capture the test application's exit status and its PAM diagnostic. A system account should satisfy issystem on a host with the matching boundary; a regular account should not. Test both sides before using the rule to route a service.

7. Recover if the rule causes trouble

If a dedicated test service fails, stop using that service and restore its previous file. For an existing file with the backup made above:

$ sudo install --preserve-context -m 0644 -o root -g root /etc/pam.d/account-type-check.bak /etc/pam.d/account-type-check
$ sudo sed -n '1,80p' /etc/pam.d/account-type-check

Do not restore a backup over an unknown target without first confirming the path. If you changed a distribution PAM stack, use the open root session or console to restore the exact original, then review system logs and the distribution's PAM recovery procedure. Removing a test file does not undo a rule that was copied into another stack.