Service account lockout occurring several days after automated password rotation (Event ID 40970)

Products

• DX Unified Infrastructure Management (Nimsoft / UIM)

Issue/Introduction

An environment utilizes an automated script/workflow to rotate the passwords for the service accounts running UIM components (e.g., Primary Hub, Operator Console). Following a successful automated password rotation, the service account begins to lock out periodically (e.g., every 30–60 minutes).

Key symptoms and observations include:

• The lockout does not happen immediately after the password is changed. Instead, it typically starts exactly 7 days after the last server reboot.

• The Windows Event Viewer on the hosting servers logs repeated Event ID 40970 (Source: LSA/LsaSrv) or similar bad password/lockout events.

• Reviewing the core UIM logs (hub.log, controller.log, wasp.log) shows no corresponding application activity or failures at the exact timestamps of the lockouts.

• While UIM services may remain operational, integrations relying on the service account (such as LDAP authentication) may fail during the lockout window until the account is manually unlocked.

Environment

 

• Product: DX UIM 23.4.6 / 23.4.CU6

• OS: Windows Server

• Authentication: Active Directory / Kerberos

• Configuration: Automated service account password rotation tools/scripts in use.

 

Cause

This issue originates at the Windows Server and Active Directory/Kerberos layer, outside of the UIM application itself.

The 7-day recurrence interval aligns with the default Windows/Active Directory Kerberos ticket renewal limit, known as MaxRenewAge (Maximum lifetime for user ticket renewal).

When the custom script rotates the password and restarts the UIM services, it may not force the OS to generate a completely new Kerberos ticket for the service's logon session. The existing ticket keeps counting down from the last server reboot. Once the 7-day renewal limit is reached, Windows forces a fresh authentication. Because the cached session or ticket state conflicts with the newly rotated password, the authentication attempt fails, resulting in an account lockout that loops independently of the rotation schedule.

Resolution

Because this behavior is controlled by the Windows operating system and Active Directory policies, it must be addressed outside of DX UIM.

What might help: 

 

• Server Restart: Modify the automated password rotation workflow to include a full server reboot as the final step. This ensures that all localized cached credentials and Kerberos tickets are completely flushed, forcing the server to request a fresh ticket upon startup with the new credentials.

• Script Modification: Alternatively, work with your Windows Server/AD administration team to modify the password rotation script. Ensure it includes commands to explicitly purge old Kerberos tickets (e.g., using klist purge) and forcefully terminate any lingering logon sessions using the old credentials before restarting the UIM services.

 

 

Additional Information

For more details regarding Kerberos policies and ticket lifespans, consult your Active Directory administration team and refer to Microsoft's official documentation:

• Maximum lifetime for user ticket renewal (Windows Security)