Is there an exception table for Dialog users ?

[Former Member]

Hello Experts,

We have a situation wherin we need to make a RFC user as a Dialog user ( for SCM , GATP connection). SAP recomeends this user to be a dialog user. But the problem is the password reset rules ( e.g reset password after 60 days) also apply for this user.

Do we have an exception table or some other provision using which we can bypass these checks for a particular dialog user ?

Regards,

Shailesh

[Former Member]

Where did SAP recommend using a dialog user?

Yes, by default, when you are also using the ID to logon to the system from the logon pad oran invoced logon screen (which you should not do - you should use your own account for that...) then you will be prompted to change the password (or can do so voluntarily) and the RFC connection with the old logon data will fail.

If you have tweaked the rfc/reject_expired_password parameter, then this will fail for RFC calls as well. That is usefull (but the hard way) to ensure correct user types.

My recommendation. Use a SYSTEM type user, or else create an ICF service which can be called externally and user a SERVICE type user.

Note that anyone who can start the service (object S_SERVICE) can use it if you save the logon data, or even debug it if authorized.

Cheers,

Julius

[Former Member]

Thanks for inputs Julius.

SAP recomandation can be found on SCM 2007 Component secuirty Guide - Page 29 . A part of i reads as follows;

Maintaining Authorizations for Available to Promise (ATP)

Available to Promise plays an important role in the integration of SAP APO and SAP ERP: The ATP

check needs an RFC connection with a dialog user to perform the check.

The guide gives further steps to mizimize this flaw but those are like creating Trusted RFC connection . That's something we do not want to go for as of now.

That's why I was looking for other options , like disabling the forced password reset feature for some set of users using an exceptoin table / any ther method.

Regards,

Shailesh

[Former Member]

That is not "secure" documentation / advice and will cause confusion...

You could theortically use a SERVICE user or go for the trusted RFC option.

If none of those fit your requirement, then dont maintain the login data and the user should be prompted to login. Not all application support this, and the account should not be shared on the calling side anyway.

For this there is a parameter for "sharing" ID's at the same time as exceptions. Rather avoid it, as it will force you to share accounts on the calling application.

Cheers,

Julius