Why doesn't a RFC logon update USR02 "last logon"?

[former_member318517]

Hello all,

Just wondering why when RFCing into a system, say into BW to execute reports, USR02 doesn't update the last logon field for that user? Does USR02 only get updated with a dialog logon?

Thanks,

Tom

[mvoros]

Hi,

No, it should get updated. Check what you have in parameter login/update_logon_timestamp. Also search for OSS notes. There are some related to TRDAT and RFC.

Cheers

[Former Member]

This message was moderated.

[Former Member]

Which SAP release are you on? You should generally mention this dependency when asking questions.

Cheers,

Julius

[former_member318517]

Thanks Julius. I did check some OSS notes, certain SRFC calls don't actually update USR02.

[Former Member]

SRFC are classed by default as public functions. Where there is no authority-check, there is also no requirement to authenticate.

As the user does not need to exist even, the logon timestamp is not updated.

An example is the connection test "ping" in SM59. This is just a physical ping for the correctness of the admin data tab settings - but from the application layer using RFC (without valid logon data credentials being evaluated).

Cheers,

Julius

[ted_dinh]

I'm curious if you have an answer for this. We have the exact same problem with users login on to BI portal, and it doesn't stamp last logon date for the user in R/3 back end site. It looks like SAP does check for authentication (reject logon to portal if user is locked), and check for authorization when running reports.

Reading some of the old OSS notes (489768, 416402), I'm under the impression that RFC logon should also stamp logon date/time. We're in SAP BASIS 700 / release 24, and SAP_BW 700/ release 26.

We also created a message with SAP, but do not have an answer back on this just yet.

Thanks.

[Former Member]

With RFC you must remember that authorization checks trigger the authentication (against which user should the authority-check be performed?).

If the user context does not have a session ID (they already are on the inside) then they are prompted for authentication.

This might be transparent as it aleady happened (e.g. logon tickets of various sorts) or an interactive logon screen appears if the client application (and middle-ware components) support it.

Then you can authenticate.

AFAIK the logon time stamp was an old mechanism to signify the status of the password only. This collided with people and programs who observe (and sometimes update...) table USR02. Public functions do not require authentication, so anyone can call them and authentication is not required.

Transaction SM19 and Sm20N will also help you further to record logons,

Cheers,

Julius

[ted_dinh]

Thanks, Julius.