Nightly Lockouts After Onboarding 2,300 Accounts

The 02:15 pattern is a rotation-versus-consumer problem, not an authentication problem. CPM changes the password inside its change window; the batch job keeps presenting the cached old value, retries several times, and trips the domain lockout threshold. A threshold of 5 bad attempts in 30 minutes is exhausted quickly if the job retries every five minutes. The same root cause would exist even if the job ran at 09:00.

Key judgement: an account should only be under automatic rotation when something can fetch the new value. Rotating a credential with no retrieval path is a guaranteed outage, just delayed.

Sequence:

1. Stop the bleeding - set those 41 accounts to manual/no-change so the nightly failure stops, and confirm with the app owners which process actually consumes each credential (trace the logon events on the domain controllers).
2. Classify - split accounts into interactive/human (rotate freely), application-embedded (need an integration), and appliance/vendor (often cannot rotate at all; document as an accepted exception with compensating controls).
3. Fix the consumer - for the batch job, either move the credential retrieval into the application via a secrets store, or keep the account out of rotation and compensate with session monitoring and network restriction.
4. Only then re-enable rotation, and verify with a check-out and logon test before the next scheduled cycle.
5. Align the change window and the account lockout policy with the rotation schedule so a failure cannot cascade into a lockout.

Both controls belong in the Master Policy with Safe-level overrides and, where justified, account-level exceptions - but the design decision is which accounts get which control and how approval is staffed.

Dual control means a second authorized user must approve the retrieval before the requester receives the password. It directly closes the audit finding: two admins can no longer each pull the domain admin credential independently, because every retrieval produces an approval event tied to a named approver. Exclusive access is a different control - it prevents concurrent check-out of the same credential - and is only appropriate where simultaneous use causes a real conflict (single-session consoles, one-admin-per-host RDP limits, accounts where two operators would fight over the same session). Applying exclusive access broadly creates queueing during incidents without adding security.

For the on-call problem, do not disable dual control. Instead:

• Define an approver group drawn from the on-call rotation, excluding the requester, so approval is always available.
• Add a separate break-glass account in a distinct Safe with dual control, a very short check-out duration, and an alert to the security team on every use.
• Turn on one-time password for the tier-0 accounts so the approver authorizes access but nobody learns the underlying value.
• Route human use through PSM so the session is recorded and the password is never displayed.

This satisfies the finding, keeps 03:00 response viable, and produces the approval trail the auditor is asking for.

CPM rotates a local Windows account by authenticating as that account (or via a reconcile account) and setting the new password through the platform's Windows mechanism. If the account's configured username no longer exists on the target because the built-in Administrator was renamed by hardening baseline, the logon fails before any password change is attempted, and the failure repeats every cycle. The failure reason in the account activity will point at logon rather than at password policy.

Fix path:

1. Confirm on one host what the account is actually named now, and whether it is enabled.
2. Correct the account's username property in PAM to the renamed value, or, better, stop managing the renamed built-in account directly and manage a separate local admin account that the baseline creates.
3. Confirm the platform can reach the host: WinRM or RPC reachable, firewall rules, and any UAC remote restrictions that block local-account token use over the network.
4. Verify with a verify/check operation on a single host before letting the schedule run across all twelve, then watch the first full cycle.

What I would not do: manually reset passwords on the hosts and mark the accounts reconciled, or delete and re-onboard them. Both destroy the audit trail and hide a configuration defect that will reappear on the next baseline refresh. Also avoid setting the accounts to no-change permanently - that converts a fixable defect into an unmanaged standing credential.