Showing results for 
Search instead for 
Did you mean: 

Solman_admin user lock in RTS system

0 Kudos

Solman_admin user lock in solman system. We have corrected all RFC connections which are pointing to solman where Solman_admin is being used. Everyday lock is happening at 4AM with different ip address IP_ADDRESS. Requested ****** team to stop the instance(IP_ADDRESS), but they were saying that is  new instance and it is replacing server ******qa01 and they can't stop the instance even for one day.

Kindly request you check what else we can do to get this resolved.



Learn more about the SAP Support user and program here.
View Entire Topic
0 Kudos

Please refer to below extracted solution from KBA 2685122.

"It is very difficult to determine the root cause of a user being locked as landscapes may vary and we may not be able to reproduce this issue on demand. According to Solution Manager documentation, there is a principle of segregation of duty. That means the users are used according to their needs and SOLMAN_ADMIN user is a configuration user used during the system setup and it is recommended to be deactivated after setup so it can be activated when necessary (or that authorizations are restricted). That means the user is not expected to be used by any other configuration scenario that could store the user password for any activity.

This document is to help customers identify where the lock is occurring in the system. As locks can come from anywhere customers are overall responsible for knowing where their users are changed in their configurations.

If SOLMAN_ADMIN user password has been changed and then frequently locks after it is likely that the user has been used in multiple configuration scenarios such as RFC's, SMD's, etc.

  • You can read and review the recommended checks on page below, which is also usually helpful:

Best Practice - How to analyze user lock issue

As also explained on the documentation, the naming is a suggestion and the relevant for the setup user are the roles on the use case of SOLMAN_ADMIN (you can see that on SMUA).

Please read the details on the two links below for more details on the explanation just provided:

To help determine where the users maybe getting locked its necessary to use different traces:

  1. The Audit Log trace (SM19/SM20) transactions can be activated for the locked user and these traces can show from which source address the user is trying to access the system.
  2. The Change Documents (SUIM transaction) can show in some cases the reason why a user is being locked e.g. an incorrect password being used or a kernel function.
  3. The developer traces detailed in SAP Note 495911 - Logon problem trace analysis can show the root cause but not where it comes from.
  4. Please also check all transactions in SOLMAN_SETUP to check where the user is being used.
  5. Check the RFC's of managed systems in Step 3 of the managed system configuration to ensure if the user is being maintained and update any passwords if necessary.
  6. Please check SAP Note 1493272 - A user gets locked automatically for information on how to check on Java stacks.
  7. When changing/resetting the password for SOLMAN_ADMIN it is not sufficient to make the change in SU01.  The change must also take place in transaction USR_MNGT as this change will push the information to the genstore (SOLMAN_SETUP_ADMIN).  Changing in only in SU01 will not update the generic store automatically.

IMPORTANT: Don't use character £ in password

In case the information above does not help you to identify what is executed that is sending incorrect password and locking the user, please create a new user with SOLMAN_ADMIN roles (assign SOLMAN_ADMIN use case) and use that for the configuration."