Skip to main content

Linux User Authorization Policy

Updated this week

Overview

The Linux User Authorization Policy lets you manage and control how user passwords are enforced on Linux devices. This policy is designed for both:

  • Company-owned devices

  • BYOD (Bring Your Own Device)

When configured, Swif keeps local Linux user passwords aligned with the last known password stored in Swif (the “cloud password”). If a user changes their password locally on the device, Swif can detect the change and reset it back to the Swif-managed password.

Supported platform

  • Linux (supported Swif Linux agent distributions and desktop environments)

Note: Behavior and timing are designed to be consistent with the existing enforcement on macOS and Windows, as much as technically possible on Linux.

How enforcement works on Linux

Unlike some other platforms, Linux does not always expose a simple “local password change” event. Instead, Swif uses the following approach:

  1. Password state in Swif

    • Swif stores the last known password for the managed user account (the “cloud password”).

  2. Local password check

    • Swif retrieves the local password salt and hash from the Linux system for the managed account.

    • Swif computes a new hash using cloudPassword + localSalt and compares it with the stored localHash.

  3. Detecting a change

    • If the recomputed hash is different from the stored local hash, Swif concludes that the local password has been changed.

  4. Enforcement behavior

    • When enforcement is enabled (see allowPasswordModification below), and a mismatch is detected, Swif:

      • Resets the local Linux account password back to the last known Swif password (the cloud password).

    • This effectively undoes any unauthorized local password change and keeps the device aligned with Swif.

Because the detection relies on comparing hashes rather than a real-time “password changed” event, there is no functional difference between:

  • Assigning the policy before a local password change, or

  • Assigning the policy after a local password change

In both cases, once the policy is active and the agent performs its checks, any mismatch between the local password and the Swif-managed password will be corrected by resetting the local password to the Swif value.

Policy fields

1. Allow Password Modification

  • Field name: allowPasswordModification

  • Display name: Allow Password Modification

  • Type: Boolean

  • Default: false

  • Required: Optional (if not provided, the default is used)

  • Supported platform: Linux

Description

Controls whether users are allowed to effectively change their local Linux password in a way that diverges from the password stored in Swif.

  • When disabled (false – default):

    • Swif enforces the cloud password.

    • If a user changes their local password on the Linux device, Swif:

      1. Detects that the local password no longer matches the Swif-managed password.

      2. Automatically resets the local password back to the last known Swif password.

    • From the user’s perspective, any local change “doesn’t stick” — the password reverts to what is stored in Swif.

  • When enabled (true):

    • Swif does not reset the local password back to the Swif-managed password.

    • Users can change their local Linux password, and that change remains in effect.

    • Swif will continue to manage the account, but will not enforce password alignment with the cloud password.

Important: On Linux, this policy resets passwords instead of blocking the password change action itself. This is different from some other platforms where local password changes can be directly prevented.

Typical use cases

1. Enforce a single source of truth for passwords

For company-owned devices where you want the Swif portal to be the source of truth:

  • Keep allowPasswordModification set to false.

  • Any local password changes on Linux will be reverted to the Swif-managed password, ensuring consistency for:

    • Helpdesk workflows

    • SSO and identity integration assumptions

    • Security policies requiring centralized control

2. Allow local flexibility for BYOD

For BYOD scenarios or less tightly managed environments:

  • Set allowPasswordModification to true.

  • Users can change their local Linux password without Swif resetting it, while you still benefit from device enrollment and other policies.

Example QA / verification steps

This flow reflects how the feature is validated on Linux:

  1. Enroll a Linux device with the Swif agent.

  2. Update the user’s password in the Swif portal, for example: password@PORTAL.

  3. Confirm that the password is updated successfully on the device (the user can log in with password@PORTAL).

  4. On the Linux device, change the local password to something else, for example: password@LOCAL.

  5. Assign the Linux User Authorization Policy with enforcement enabled.

  6. After the policy takes effect, verify that the user’s password is reset back to password@PORTAL (the Swif-managed password), not password@LOCAL.

Logs and troubleshooting

When this policy is in effect, Swif logs:

  • Detected local password changes (via hash mismatch).

  • Enforcement actions (password reset back to the Swif-managed value).

  • Cases where no action was taken and the reason (for example, account is not managed, policy disabled, or allowPasswordModification is true).

If you observe that Linux device passwords are not staying in sync with the Swif-managed password:

  • Confirm that the Linux User Authorization Policy is assigned.

  • Verify the value of allowPasswordModification.

  • Check agent logs and telemetry for:

    • Password change detection events

    • Enforcement attempts and any associated errors

  • Confirm that the user account is a Swif-managed account and that the device is online and checking in.

Related Articles
Apple User Authorization Policy
Swif Admin User Behavior on Managed Devices
Linux Password Policy
User Authorization Policy for Windows
Linux Azure Login Policy
Did this answer your question?