WF-BATCH locked automatically

[Former Member]

I'm facing the problem that although I unlock user WF-BATCH with tx

SU01, after a little while the user WF-BATCH gets locked again automatically.

Kindly advice. Jobs run using WF-BATCH user.

[manohar_kappala2]

Hi

Verify the vailidty dates and also if there are some jobs scheduled to lock the ID after validity period is over or if not used for more than a certain period.

That could be causes why its being locked..

Let me know if it helps

Thanks

Manohar

[WolfgangJanzen]

I assume that it's the "password lock" not the "account lock" that has been set.

In that case, some RFC client is attempting a password-based authentication which fails (due to using the wrong password).

If your system is an NetWeaver Application Server ABAP with release 7.0 kindly have a look on <a href="https://service.sap.com/sap/support/notes/1023437">SAP Note 1023437</a> explaining potential error reasons.

<a href="https://service.sap.com/sap/support/notes/171805">SAP Note 171805</a> might also be helpful.

[Former Member]

Maybe it helps to have a look at your RFC destinations (SM59 / table RFCDES) to ensure that every destination using the WF-BATCH user is configured with the correct password.

Wrong password in an RFC destination could lead to locking of the user if the destination is actually used.

The best way to find the destinations is via SE16 on RFCDES, select for WF-BATCH in field RFCOPTIONS. Usually you will at least find a destination like "WORKFLOW_LOCAL".

The password has to be configured via SM59 of course.

If that's not the cause of the problem, please provide the USR02-record (you can null out the BCODE-field ) and the USH02 records of user WF-BATCH. That should give a little more clues about what's going on ...

Regards,

Ralf

[Former Member]

Hi,

check in SU01 <b>why</b> the user is locked. Clicking the lock symbol should tell you if the locking is caused by mulitple incorrect logon attempts or if an administrator locked the user.

If it is the first case, check if come RFC client is using an outdated password for connecting to this system.

Regards,

Dominik

[Former Member]

Hi Sri,

I would open a customer note with SAP and ask for support. Or is the problem already solved?

@ the rest of the thread contributors...

Another possibility is that the user type is incorrect.

If the user type is Communication, then it is possible that config changed and the password is initial. So the user account is locked / blocked by the prompt to change the password (although both USR02 and RFCDES or other are the same).

If the type is System, then it is more tricky (because the checks are, debatably, more agressive...). It might be that WF-BATCH is in a user group which can be administrated by itself, and the local system is preventing the user from changing it's password.

In both cases the "account lock" mentioned by Wolfgang would be the result as far as I know, without any "incorrect password lock".

Also checking BD87, WE02 or several other reports whether there is an IDOC stuck somewhere might help (the idoc as well)... and securing the user group (S_USER_GRP) and the dataset of the workflow items (S_DATASET), and the application authorizations of the workflow user (i.e. it should idealy not be able to administrate or even display itself...). It is a relatively easy and a well invested security measure (compared to the rest, like restricting posting to the G/L for example...)...

Cheers,

Julius

[WolfgangJanzen]

<i>> Another possibility is that the user type is incorrect.</i>

Sorry to disagree. The usertype has no impact on the validation of passwords.

However, the usertype has an impact on the ability to use SAPGUI and on the requirement / ability to change the (own) password. See <a href="https://service.sap.com/sap/support/notes/622464">SAP Note 622464</a>.

<i>> If the type is System, then it is more tricky (because the checks are, debatably, more agressive...).</i>

No. The major difference between "SYSTEM" and "COMMUNICATION" is the password change requirement / ability (as stated above). Whenever you store logon data in a destination record, I'd strongly recommend to use a "SYSTEM" user rather than a "COMMUNICATION" user.

A "COMMUNICATION" user is actually a "DIALOG" user which is blocked from using SAPGUI. That's all.

<i>> In both cases the "account lock" mentioned by Wolfgang would be the result as far as I know, without any "incorrect password lock".</i>

An "account lock" effects all logon attempts. Same as "account validity". Changes to account attributes are always performed by an user administrator (resulting in change documents which can be evaluated using ABAP transaction SUIM).

In contrast to that, a "password lock" only effects password authentication. See <a href="https://service.sap.com/sap/support/notes/498889">SAP Note 498889</a> and <a href="https://service.sap.com/sap/support/notes/939017">SAP Note 939017</a>.

Cheers, Wolfgang

PS: you will not find any more SDN postings of mine in the next 4 weeks (due to vacation, starting from next week)

[Former Member]

Thanx for all. The problem has been resolved.

I’ve implemented a solution using the tcode SWU3.

I selected "Maintain Runtime Environment" / "Configure RFC Destination". Before it would be a red X mark. Now press F9, “Perform Automatic Workflow Customizing”.

This solves the problem.

[WolfgangJanzen]

That means: by generating a new password and updating the RFC destination with this new value the settings are consistent, again. So, it was a "password lock" which has been set by the system in reaction to providing the wrong password (stored in the RFC destination).

Cheers, Wolfgang

[Former Member]

SWU3

[WolfgangJanzen]

In that very specific case SWU3 is helpful. In general you should analyse the situation by tracing (as described above).

[cwcheong]

Experienced similiar issue when few site's user change WF-BATCH pwd. /nswu3 resolve the issue and you may notice tRFC error too in /nsm58.