This post refers to entries in the SystemOut.log /

Today’s error a special scenario for a common error.

“BMXAA7901E - You cannot log in at this time. Contact the system administrator.” is normally seen at the front-end when someone blocks a Maximo user account by providing too many invalid accounts.

In this case I have blocked the maxadmin account on a demo system…

A number of my readers will experience this at some point in their Maximo career so lets take a minute to understand what the implications are.

The default maxadmin account is the most important Maximo user account in the Maximo system.

If it is blocked then Maximo can fail to start when you try and start it.

The maxadmin account is used for internal tasks such as crontasks so it has the necessary privileges to perform key operations e.g. create security groups and perform critical actions.

Blocked Maxadmin Account Due to Failed Login Attempts

If the maxadmin account is blocked then parts of Maximo will carry on working but it won’t be able to restart.

The reason that some parts of Maximo continue to run is because Maximo will have created a number of database sessions and they will be logged in as maxadmin, these sessions are then kept open and used as required. New crontask instances may not start if a DB connection is not available. See further down for an example message when a crontask instance couldn’t be started.

When the JVM is shutdown the DB connections are closed.

When Maximo is started it opens a DB connection and then tries to create a number of sessions logged in as maxadmin. If Maximo can’t login then there will be errors in the logs to indicate that ánd core Maximo functionality, like crontasks, will be disabled.

This is different from a scenario I see on new ORACLE installations where the password on the maximo DB account expires and the initial database connection can’t be made.

Tip -> Change the password for the maxadmin account if it is still at the default value. Don’t forget to update the maximo.propeties file(s)

Tip -> Enable login tracking. This feature was discussed in this article

Tip -> Create system accounts for the system administrators and avoid using the maxadmin account as much as possible. Never disable or delete the maxadmin account

Tip -> Don’t forget to grant account reassignment rights for the existing security groups so the system administrators can add people into the groups. If the new accounts aren’t granted the group reassignment privileges then the administrator account will encounter BMXAA0028E errors and administrators will be forced to use the maxadmin account.

This is the error seen in the logs when a crontask can’t be started because maxadmin is blocked on a 7.6 system.

[1/17/17 21:15:25:411 GMT] 000000e3 SystemOut    O 17 Jan 2017 21:15:25:411 [ERROR] [MAXIMO] [CID-CRON-64571] BMXAA7901E - You cannot log in at this time. Contact the system administrator.

psdi.util.MXAccessException: BMXAA7901E - You cannot log in at this time. Contact the system administrator.

               at psdi.security.SecurityService.getUserMbo(SecurityService.java:2078)

               at psdi.security.SecurityService.authenticateUserM(SecurityService.java:1765)

               at psdi.security.SecurityService.authenticateUser(SecurityService.java:1734)

               at psdi.server.SimpleCronTask.getRunasUserInfo(SimpleCronTask.java:525)

               at psdi.common.asyncjob.AsyncJobCron.pickupOneJob(AsyncJobCron.java:219)

               at psdi.common.asyncjob.AsyncJobCron.cronAction(AsyncJobCron.java:75)

               at psdi.server.CronTaskManager.callCronMethod(CronTaskManager.java:2379)

               at psdi.server.CronTaskManager.access$1100(CronTaskManager.java:104)

               at psdi.server.CronTaskManager$CronThread.run(CronTaskManager.java:3255)

When the JVM is restarted then there will be similar BMXAA7901E errors.

Unblocking the Maxadmin Account – Keep this SQL Handy!

If Maximo isn’t running then it is necessary to use SQL to reset the status. The status of any Maximo user account, like maxadmin, can be seen from the MAXUSER table.

select userid,status from maxuser where userid='MAXADMIN'

The account can also be unblocked by using SQL statements that update the status on the maxuser table like these taken from technote 1595872.

update maxuser set status = 'ACTIVE' where userid='MAXADMIN' or personid='MAXADMIN'

update person set status = 'ACTIVE' where personid = 'MAXADMIN'

commit

I would go further and insert rows into the associated status tables. Inserting the status records means that the status history is clear if you need to understand the status history in the future.

Security teams can be a little nervous if they come across status histories where the status “magically” changes from BLOCKED to ACTIVE.

Tip -> Take 10 minutes and write a script to do the necessary updates/inserts so that if the account is blocked then you have a tested solution that can be applied. Add a comment at the end to remind yourself to restart the JVM(s)

Tip -> Change the password for the maxadmin/maxreg/mxintadm account if it is still at the default value. Don’t forget to change any locations where they are stored e.g. system properties/properties files

Tip-> Check the security groups for maxreg and ensure that it has minimal privileges. My next article will explain more about this important account that is often overlooked.

Procedure to Unblock the Maxadmin Account

1. Stop JVMs
2. Execute SQL to modify the MAXUSER status for the MAXADMIN account
3. Restart JVMs – checking the logs to confirm that all the JVMs restarted properly
4. Query logintracking table to identify the source of the failed login attempts