Manage Passwords and Account Expiration

What you will be able to do

• Explain the five core decisions involved in manage passwords and account expiration.
• Choose the narrow Linux command or method that matches a stated operational need.
• Interpret command output as evidence before deciding whether to change system state.
• Apply an observe, act, verify, and recover workflow to a realistic Linux task.

01

Build the Operating Model

Manage password state and aging without exposing secrets, and distinguish credential expiration from locking or removing an account.

Reliable Linux work separates observation, decision, action, and verification. That order keeps a command from becoming a guess and makes each result useful for the next decision.

Begin in a disposable lab or a recoverable environment. Record the active user, working directory, target, and baseline output before any command that can change system state.

02

Password changes

The `passwd` command changes authentication password data through a protected interaction that does not echo the secret. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Use the intended account context, enter the secret only at the password prompt, and confirm completion status. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: do not place a password in shell history. You should be able to verify this result: password data changes without screen echo.

03

Password status

Password status reports whether an account has a usable, locked, or absent password entry. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Inspect status before resetting credentials so the existing authentication condition is recorded. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: password status is not the entire login policy. You should be able to verify this result: current password state is classified.

04

Password locking

Locking a password disables authentication with that password but may not disable every other login method. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Identify SSH keys and active sessions, lock the password, and test the complete access requirement. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: other authentication methods may remain usable. You should be able to verify this result: password authentication is disabled.

05

Password aging

Password aging fields can define minimum, maximum, warning, and inactivity intervals for an account. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Review current aging values, align them with policy, and record the effective dates after any change. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: aggressive values can lock out valid users. You should be able to verify this result: credential lifetime rules are visible.

06

Account expiration

An account expiration date controls account availability separately from the password's own aging schedule. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Set a date for temporary access, verify it in the account record, and plan extension or deprovisioning. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: time-zone and date interpretation should be checked. You should be able to verify this result: account access has a defined end date.

07

Apply One Controlled Change

Start from the read-only commands that reveal identity, scope, and current state. Write the expected result before entering a modifying command, including which files, processes, accounts, or connections may be affected.

Make one narrow change and stop. If the output reports an error or an unexpected target, preserve that evidence and return to inspection instead of adding unrelated commands.

Repeat the original observation after the action. A successful command status is useful, but the real completion signal is the intended state plus the absence of an unintended side effect.

08

Complete the Evidence Loop

A good terminal record answers four questions: what was observed, why one action was selected, exactly what changed, and how the result was verified. A screenshot without command context answers fewer questions than saved text output.

Test both the expected success and one safe failure condition. This confirms that the procedure recognizes a wrong path, missing permission, invalid input, stopped service, or unavailable endpoint instead of silently continuing.

Finish by restoring the lab baseline when the task was experimental. For an operational change, record the final state and the reversal step so later work begins from a known boundary.

09

Recap Before Practice and Prove

The first decision concerns password changes. Use the intended account context, enter the secret only at the password prompt, and confirm completion status.

The second decision concerns password status. Inspect status before resetting credentials so the existing authentication condition is recorded.

The third decision concerns password locking. Identify SSH keys and active sessions, lock the password, and test the complete access requirement.

The fourth decision concerns password aging. Review current aging values, align them with policy, and record the effective dates after any change.

The final decision concerns account expiration. Set a date for temporary access, verify it in the account record, and plan extension or deprovisioning. Keep the final output as the baseline for the next task.