sapjsf locks ABAP service user psswd: M ***LOG US1=> Login, Wrong Password

[Former Member]

I have a PI system and a number of ABAP systems connecting to this.

I have defined a service user in PI for each ABAP system - SY_SID_999 (where SID is the SAP System ID and 999 is the client). Various connections (e.g., RFC, ABAP proxy) use these userid and I rely on the user name to identify the source of the activity within PI.

I was forced to change the password of one of these userids and, subsequently, to update connection details in RFCs etc within the source system. All went well for these connections.

Now, however, at 25 minutes past the hour, I get the following error in the PI system's developer trace

M  ***LOG US1=> Login, Wrong Password (SY_SID_999 ) [sign.c       4545]

and the SM21 log says

10:25:47 DIA  000 100 SAPJSF                  US  1 User SY_SID_999 locked due to incorrect logon

SU01 change records show no changes to SY_SID_999 from the time I unlock it until 25 minutes past the hour when this error occurs.

The SM19 security audit log in the PI system has errors:

12.08.2009	10:08:18	SAPJSF	localhost		SAPMSSY1	Logon Failed (Reason = 53, Type = U)

Type=U means "user switch (internal call)" according to the documentation.

Reason 53 means "Too many failed password logon attempts"

These errors occur in bunches but without a consistent repetition interval. For example, there were 8 at 10:04:56/57 then 2 at 10:08:18 then a string of success messages as follows:

12.08.2009	10:08:18	SAPJSF	localhost		SAPMSSY1	Logon Successful (Type=U)

Then, at 10:25...

12.08.2009	10:25:47	SAPJSF	localhost		SAPMSSY1	User SY_SID_999 Locked in Client 100 After Erroneous Password Checks
12.08.2009	10:25:47	SAPJSF	localhost		SAPMSSY1	Logon Failed (Reason = 1, Type = U)

If I do not unlock the SY_SID_999 userid in the PI ABAP system, there will be no further errors in SM21 but if I do, at 25 minutes past the hour after the error pattern will repeat.

I have set the rfc/logon_error_log parameter to 3 in PI ABAP to trigger a short dump.

Internal notes from the short dump do not identify the who, what or where of the sign-on attempt...

Internal notes
    The termination was triggered in function "ab_xsignon"
    of the SAP kernel, in line 2725 of the module
     "//bas/710_REL/src/krn/rfc/absignon.c#4".
    The internal operation just processed is "CALY".
    Internal mode was started at 20090812112528.
    Caller system......: " "
    Caller.............: " "
    Caller client......: " "
    RFC user ID........: " "
    RFC client.........: 100
    Login return code..: 20
    Transaction code...: " "
    (Note: In releases < 4.0, no information on the caller is available)

The source system represented by the SY_SID_999 userid is an ABAP ONLY stack so has no sapjsf userid. (For the record, SY_SID_999 doesn't exist in client 999 of SID either - it's defined in the PI system to do work on behalf of SID client 999.)

So the question, after all that, is:

How do I identify the source of this password error?

[Former Member]

Please create a test rfc and then then check the user id and password that wahich system password id not with sink if you dont find any error in trace.

thanks

Rishi Abrol

[Former Member]

- check the SM21 on SY_SID for errors.

- check SM59 on SY_SID, you might have a HTTP connection to the PI, verfify (or reenter) the password

- depending on the release of the systems, you might have problems with upper/lowercase characters and with passwords and longer than 8 chars, you can try to setup a test r/3 connection in SM59 and test it

Regards, Michael

[Former Member]

Thanks Michael

I did get a short dump during the testing process and it indicates that the failed RFC logon attempt originates from within the PI system. My implementation partner was rather careless in the assignment of userids to connections so, while this userid should only be used for connections originating from the SID, I cannot guarantee that.

I've been into both my PI system and the ABAP system (which doesn't have a sapjsf userid so should not be the offending party) and run an SQL select script to find all RFC destinations which contain the string "SID" or "sid" in any of the RFCOPTIONx fields. I've carefully checked out each of these RFC destinations and, in SID they contain the SY_SID_999 userid and, when that's unlocked in PI, the connection and authorisation tests succeed. That rules out upper/lower case issues and pretty much eliminates these legitimate RFC destinations from the suspect list. The RFC destinations identified in the PI system by the SQL search contain "SID" because they name that as their target system; these definitions don't reference the SY_SID_999 userid at all.

All the evidence I can find points very strongly to some process running as SAPJSF in the Java stack of the PI (dual stack) system calling something on the ABAP side and trying to connect as SY_SID_999. Trouble is I can't find it. In fact, I'm don't even know where to start looking to find a job running in the Java stack - on the ABAP side I'd head for SM37 but what to use on the Java side?

[Former Member]

Solved!

The evidence in the short dump was definitely pointing to the error coming from within the PI system. I was convinced that this was the Java stack trying to log on to the ABAP stack of PI using a userid from the attached ABAP business system. I could find NO RFC destination in the attached ABAP business system which connected to the PI system where the connection and authorisation tests failed while the userid was unlocked in PI.

Turned out that transaction SLDAPICUST in the business system was configured to use SY_SID_999 as well as the two visible RFC destinations. This was not updated with the new password when it changed so, at 25 minutes past the hour, something (I've still not worked that out) from SID checked with PI and tried to logon until the password locked.