Password for user set as communication type expires!?!

[Former Member]

Dear experts,

I have communication user who is connecting our RAR 5.2 with our SAP backends. This user is set as communication type which supposes that its password should not expire once set. This is how it is for all backend systems that we connected to RAR, except the CUA client. The background job that I`m scheduling for user sync. with the systems fails for our CUA client exactly for this reason: "Error while executing the Job:com.sap.mw.jco.JCO$Exception: (103) RFC_ERROR_LOGON_FAILURE: The initial password has expired; request a new one"

Could you please advise how to deal with this?!

Thanx in advance!

Iliya

[Bernhard_SAP]

Hi Iliya,

passwords of users of type comunication expire too!

Please refer to the SAP notes #327917 and #622464 and use for instance the type 'System' instead.

b.rgds,

Bernhard

[Former Member]

Hello Ilya,

The error you are getting is because the password for the System user you are using has expired. To get going you can get the password changed and validity updated by your administrator.

To avoid such occurences in future, in addition to a System user you can use the User type "SERVICE" too, if you need the user to be able to log in as a dialog user and at the same time you need the password not to expire anytime.

Regards,

Hersh.

[Former Member]

Thank you Bernhard,

I`m not sure how changing the user type from communication to system will affect the connection between RAR and the backend systems. In the manual is explicitly written that the rfc user should be communication type.

What is odd about this is that even the communication type of user is a subject of password expiration I don`t experience such problem in 25 other SAP systems (R/3, ERP, APO, SCM, SRM, CRM, HCM), but only in the CUA system. When I reset the password in the CUA system for the user, then accordingly set the same password in the Net Weaver RAR it works for two days, on the third day it comes with this message I already mentioned. Obviously the problem here is not that the type of user is communication when it`s working properly for all other systems. I`m also convinced that it is not a parameter of the CUA client setting, because we have other communication users who are working properly with the CUA.

Do you have any other suggestions?

Thank you!

Iliya