How to trace what is locking a user

[tomas_lindberg]

For our central SLD, we have a user called jcouser which has been defined in SLDAPICUST and SLD Supplier Bridge on many remote systems.

Unfortunately, this password was recently changed on the SLD host, and it's now locked constantly from a remote system apparently.

I've checked most systems and changed to to the new password, but the user is still locked, not as frequently but still.

Does anyone know what possibilities there are to trace from where the connection comes that locks the user?

an IP adress or similar to help the troubleshooting.

We will look over the procedure to have unique users or something for the SLD update in the future, but to solve this current issue I would like to know if anyone know about any possibilites to find a trace or similar.

Thanks and Best Regards

Tomas

[tomas_lindberg · Accepted solution]

A colleague of mine actually find a good source to use which is the security logs at:

/usr/sap/<SID>/J<XX>/j2ee/cluster/server<X>/log/system

In here i was able to find several re-occuring entries with a LOGIN FAILED statement and an Ip adress.

After going through the file, i had about 8 different IP's which I then could analyze back to which system and find the faulty password definitions.

Best regards

Tomas

[Former Member · Accepted solution]

HI Tomas,

We are also facing the same issue now. Can you please elaborate how to trace user locking..

[Former Member · Accepted solution]

I also found out that checking for error 401 in /usr/sap/<SID>/DVEBMGS<sysnr>/j2ee/cluster/server<X>/log/system/httpaccess is helpful.

[paul_power]

Hi Tomas,

In transaction SLDAPICUST, have you maintained an SLD destination with
host, port, user and password ?

Please take this user for interactive logon to the SLD via browser
with URL http://host:port/sld
and try to display data.
This way you can check if the user is valid for SLD logon and has
sufficient authorizations.

If the user is suitable for SLD logon, then please clear and re-type
its password in SLDAPICUST, as this is a common source of errors.

Check  the note Note 1665838 - How to check why a technical PI
user gets locked

"If the user that logs the above error is SAPJSF, in most of the cases
the affected user (XIAPPLUSER in our example) is locked by a java
application. SAPJSF is an internal UME user for Java - ABAP
communication."

In order to solve this issue please ensure you have maintained the
correct password, which MUST be the same, for all the service users
on XI. You may check all the places it should be maintained, such as
Exchange Profile, SU01, SLDAPICUST, etc..

Please kindly check the note below:
#936093 - XI 7.0: Changing the passwords of XI service users

Also please ensure that the user has the correct role as per link below:
http://help.sap.com/saphelp_nw70/helpdata/en/9f/d12940cbf2195de10000000a1550b0/frameset.htm

The problem with the SLDAPICUST user is likely getting locked,
when it is been called with the wrong password in one of the following
locations:

- SLD data supplier Java (in 70 in Visual Admin -> SLD Data Supplier
Service first tab)
- SLD HTTP client ((in 70 in Visual Admin -> SLD Data Supplier Service
second tab)
- SLD ABAP data supplier (transaction RZ70)
- SLD ABAP client (transaction sldapicust)

I assume there are many different systems updating the
SLD with this same user. Please identify which system has the incorrect
password, this could be any system within his landscape that is sending
information to the sld.

Hope this helps track down the cuase of the issue.

Regards,

Paul

[tomas_lindberg]

Hi Paul

Thanks for clarifying my question a bit further.

The only issue that I have right now is that in some of my systems, the jcouser is still defined with the wrong password. Since we have 80+ systems, i'm intressted in finding out if it's possible to trace from where the connection that locks the user originates instead of going through RZ70, SLDAPICUST, SLD Data Supplier and Cim Generation setting in each of these systems.

I have already gone through most of the systems, and I have seen a decrease in the timeintervall from when the user get's locked, but it seems that it is still defined somewhere with the wrong password.

For future reference we would not have changed this password, or we will switch to use unique users but for this current issue we would like to know if there is a trace possibility to decrease the amount of work with manually check all systems.

Best Regards

Tomas