User profile updated with incorrect date stamp

[Former Member]

Good Day Gurus,

Our SAP ERP 6.07 accesses are managed through GRC 10.1. We recently upgraded from ERP 6.04. Post upgrade, we noticed an inconsistency in the last changed date on certain user profiles in SU01. The error is that for some user accounts, the last changed date is a random date (2017-02-21) in the future. Note that no matter where the account was updated from, i.e. GRC or manually through SU01, the same incorrect date stamp was encountered. There doesn't seem to be any similarities with the specific users, in addition, the date remains constant for updates made on different days. For two weeks now the same date stamp (2017-02-21) is being used over and over on certain accounts.

We have asked SAP to come in and determine the issue. So far they have not been successful. They gave us a custom program that may be causing the error, however, this seems to have been a program written to download some data for an audit report some years ago.

I have tried searching the forums but has not found anything similar. Has anyone seen such an occurrence? Thanks in advance.

Regards,

Nick

[Former Member]

A possible explanation for this is that someone decided that they don't want to be subject to the password change rules.

So... they thought that if they set the last change date of the password into the future, then they will not have to change it until they reach that date.

Only problem is that they overestimated their abilities and were led to the USRSTAMP table for "all changes" displayed in SU01 and not the kernel side table with the datestamp of the actual password change. But never-the-less they went ahead and updated the database for themselves and some friends and congratulated each other for what they think they have achieved...

Except it does not work that way! Try a where-used-list search from SE11 on USRSTAMP? Any Z-programs or the likes? Could however also have been done directly on the database.

Cheers,

Julius

[Former Member]

Good Day,

Thanks Julius for your response. I've checked for Z programs or the likes, however, I have found none. Further, I am seeing abnormalities with the changed date. E.g. for a couple users, when in SU01 it shows a last changed date of 2017-02-21. So you have an entry on  USRSTAMP with the 2017 date however, no corresponding entry exists in CDHDR. I am trying to build a log of the last valid change date for the affected users to begin with.

Not sure if you have any other ideas that I can also look at? Thanks again for your response!

Regards,

Nick

[Former Member]

If USRSTAMP is inconsistent with CHDHR OR USH02 then this would indicate that something directly hit USRSTAMP. Check table SE16N_CD_KEYS as well.. but at DB level or with debugging it is considerably more difficult to find the origin.

What do the users in question all have in common? Eg. they are all developers, or basis admins or they are all from Texas, etc? 🙂

Cheers,

Julius

[Former Member]

Good Day Julius,

I've asked the Basis person to check the table at DB level. Awaiting a response. These users do not seem to have anything in common per say. I am still trying to compare the users to determine that. What I am seeing is that it may just be for a specific number of users where this random date stamp was placed.

Since yesterday I have been monitoring the number of users in USRSTAMP with the incorrect date and the number of users is fixed @ 302. So I can infer that it is the same 302 users are constantly being updated with an incorrect date. Making a change to these users manually, e.g. changing a date format, does not override the incorrect date. It remains. However, in our QAS client, the same error exists and making a manual change corrects the date stamp.

Note too that I have seen the incorrect date in table AGR_TIMEC. So assignment modifications are also being affected. The latter would have come through our GRC system. However we have noted at least one instance where a user updated their own data in SU3 and it placed an incorrect date as well....

The search continues...

Regards,

Nick

[Bernhard_SAP]

Nicholas Hassanali wrote:

However we have noted at least one instance where a user updated their own data in SU3 and it placed an incorrect date as well....
The search continues...

Regards,
Nick

you msut keep in mind, that for the ush02 an ush04 CD-records a new entry cannot be older than an existing entry.

So once you are trapped in the future date, all further changes will have also a future date!

comment in SUSR_USER_PROFS_BUFFER_TO_DB:

... * Writing USH04 must be done at first, because in some cases we need to

* adapt the time stamps for an entry. In such case we maybe need to

* adapt the USR04 entry [before writing] regarding last USH04 entry as

* well. *>>>> END OF INSERTION <<<<<<

...

*      Not to lost change documents        AND

*      Not to run into performance problems

*      the decision was to save "wrong" change documents with an

*      increased time stamp. ....

.....

Therefore you must get rid of that entries wiht future date. Best approach: archive them. Log that activity,so that you can explain auditors later, if there are gaps in the history.

b.rgds, bernhard