How to Reset a Maximo User Password

What should you check before resetting the password?

Before touching the user record, identify the authentication model. Maximo environments may use local authentication, LDAP, SSO, OIDC, or an enterprise identity provider managed outside Maximo. If the user signs in through corporate SSO, changing a local Maximo value may do nothing or may create confusion during support. Ask how the user normally reaches Maximo, whether other users are affected, and whether the problem is password, account lockout, expired access, disabled identity, or missing security group.

Summary: The safest reset starts by finding the source of identity. Do not assume the password lives in Maximo.

How do you reset a local Maximo password?

Use an administrator account with permission to manage users. Open the Users application, find the person by login ID, and confirm you have the correct account. Review status, password expiration settings, failed-login indicators, and security groups. If your organization permits local resets, enter the temporary password, require the user to change it at next login where policy allows, and record the support ticket or approval reference.

A practical sequence is:

1. Confirm the user identity and support request.
2. Open Users and search by login ID, not display name alone.
3. Check account status and authentication source.
4. Reset the temporary password according to policy.
5. Ask the user to sign in and change the password immediately.

What if the account uses LDAP, SSO, or OIDC?

For enterprise identity users, send the user through the corporate password-reset process or identity team. Maximo administrators may still need to confirm that the person record, user record, status, and security groups are correct. In MAS environments, identity configuration can also involve suite access, application access, and entitlement expectations.

What if the user is locked out?

A lockout is not always a password problem. Check whether failed attempts, inactive status, password policy, identity-provider lockout, or missing application entitlement caused the issue. If many users are affected, stop and investigate identity-provider, SSO, certificate, or network issues instead of resetting accounts one by one.

What should be documented?

Document who requested the reset, who approved it, what identity source was used, whether security groups changed, and whether the user confirmed access. Password values should never be stored in tickets or email. Use the ticket to record process evidence, not secrets.