User Cannot Log In After Security Policy Change
An OpenVMS Integrity system enforces a site security policy. The security administrator recently changed the system password policy: minimum password length raised from 8 to 12, password lifetime reduced to 60 days, and a new intrusion-detection policy. After the change, a service account APP_SVC used by a batch application fails to authenticate, and several interactive users report being locked out after a single mistyped password. SHOW INTRUSION shows entries for the interactive users but none for APP_SVC. The application team says the account worked yesterday and nothing changed on their side. The security admin insists the policy change is unrelated because "APP_SVC never logs in interactively."
1. Explain why the policy change can break a non-interactive service account even though it never logs in interactively.
Read the worked answer
Password policy is enforced at authentication time, regardless of whether the login is interactive. A batch application authenticates with a username/password (or via a proxy/credential) just like an interactive user, so the same policy applies.
The likely causes for APP_SVC:
- Password lifetime: reducing lifetime to 60 days can mark the account's password expired. An expired password forces a change at next login; a non-interactive process cannot satisfy that prompt, so authentication fails.
- Minimum length: if the account's stored password predates the length change, policy may force a reset on next authentication.
- Intrusion detection: a new policy can lock an account after failed attempts.
SHOW INTRUSIONshows nothing forAPP_SVC, which actually argues against lockout and points to expiry/policy, not intrusion.
So the security admin's reasoning is wrong: "never logs in interactively" does not exempt the account from password policy. Check SHOW ACCOUNT/ALL APP_SVC for PWD_EXPIRED, PWD_LIFETIME, and flags, and check the application's authentication method.
2. The interactive users are locked out after one mistyped password. Diagnose the likely policy setting and how to correct it without weakening security excessively.
Read the worked answer
One mistype causing lockout indicates the intrusion detection policy is too aggressive - likely /FAILURE_DELAY or a failure count threshold set very low, or a SECURITY_POLICY that locks on first failure.
Diagnosis:
SHOW INTRUSIONlists the locked sources/users and the failure counts.SHOW SECURITY_POLICY(or the relevant system parameter / security profile) shows the failure threshold and lockout behavior.SHOW ACCOUNT/ALL <user>shows the account's intrusion settings.
Correction without over-weakening:
- Set a sane failure threshold (commonly 3–5 consecutive failures) rather than 1, balancing brute-force resistance against human error.
- Keep a lockout duration or require an operator to clear, rather than permanent lockout on first failure.
- Clear current lockouts with
DELETE/INTRUSIONfor the affected entries after verifying the users are legitimate. - Keep the stricter password length/lifetime - those are good - and address the service account separately (see previous task) rather than loosening the whole policy.
Document the threshold change so it is a deliberate, reviewed decision.
3. Outline a verification procedure to confirm both the service account and interactive users can authenticate after remediation.
Read the worked answer
Service account
SHOW ACCOUNT/ALL APP_SVC- confirmPWD_EXPIREDis cleared and lifetime is acceptable; confirm no lockout flag.- Have the application team perform a test authentication with the account (e.g., a controlled
SET HOST/batch test or the app's own connectivity check) and confirm success. - Check the application's audit/log for successful authentication.
Interactive users
SHOW INTRUSION- confirm no remaining lockout entries for the affected users.- Have one affected user log in successfully; confirm the password-change prompt (if any) behaves as intended.
- Verify a deliberate single mistype no longer locks the account, but that repeated failures still do (test with a throwaway account, not a real user).
Policy sanity
SHOW SECURITY_POLICY/ relevant parameters to confirm the new thresholds are in effect.- Review
OPERATOR.LOG/ security audit log for authentication events during the test window. - Confirm no other service accounts are affected by the same length/lifetime change (scan accounts with
SHOW ACCOUNTand check expiry dates).
Only close the incident when both the service path and the interactive path are verified end-to-end.