Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

User having wired (&_SAP_ALL) permissions in User Buffer but not in Master Data

florianbrandtmayr
Discoverer
0 Kudos

Hello community !

I´m currently investigating in a wired assignment of some kind of &_SAP_ALL permission which is obviously working.

The user does not have the profile assigned via SU01/CUA, but it´s showing up as shown in the screenshot.

Anyone who can tell me how this is possible, and even more important, how to prevent this to be done in the future.


Any help would be appreciated.


Thanks!



9 REPLIES 9

Former Member
0 Kudos

I wouldn't hit the panic button yet..

Which SAP release are you on and kernel level?

Please post the complete screenshot so that we can see the buffering method and the location of this instance? Also check in table USRBF3 for this user whether a reload flag is set.

Cheers,

Julius

0 Kudos

thanks for the quick reply, Julius !

Currently we´re on v731 sp17

0 Kudos

Hmm.. then lets check some things before removing it:

1) Please compare tables USR04 to UST04. Do either of those contain profile SAP_ALL* profile names (in USR04 you will need to extend the field as far as it goes but SAP_ALL is typically right at the beginning of the field).

2) Go to SE11 and do a where-used-list lookup for table USRBF2. Are there any suspect programs or code such as Z* or $* which use this table? While about it you might as well check table SE16N_CD_KEY for any entries to US* tables as well.

3) Go to report RSUSR100N and display the history of authorization changes to the user, particularly when SAP_ALL was legitimately assigned and removed from the user (from the view of change documents). If that is OK, then it would appear that the "user after change" function in SAP did not clear the buffer of the user, but also does not appear to be waiting to reload the buffer.

4) When did the user last logon to the system? Is it older than the date at which SAP_ALL was removed from the user (in point 3).

If there is nothing suspect going on it either of the points above, then I would suggest resetting the buffer via SU53 or report RSUSR405 and it is probably a corrupted buffer or an update to it after a change dumped for some reason. If it comes back again, but point 1 to 4 above are OK, then it might be a DB trigger on the field (but no one voluntarily does that and expects it to work...).

Cheers,

Julius

0 Kudos

1) USR04 and UST04 both don´t contain SAP_ALL / &_SAP_ALL Profiles when checking the concerned user

2) USRBF2 is only used in SAP Programs/FM´s, no Z* or $* entries, also in SE16N_CD_KEY no US* tables listed

3 & 4) SAP_ALL has never been assigned to this user on this (or any other) system (as it´s the prod-enviroment); user logged on every working day

0 Kudos

Then I only see three options left:

1) An update error to the buffer or when clearing the buffer after change (but you say that SAP_ALL was never assigned in the first place, so this is unlikely).

2) An error in SU56 which is showing the wrong buffer. Please check directly in table USRBF2 whether these &_SAP_ALL entries are there and also in table USREFUS whether there is an entry there for the user. While about it, also check any other users with this authorization name in USRBF2 to see whether others are affected.

3) This happened at the DB level and the application does not know about it. So reset the buffer as described above and monitor it in the next days to see whether it comes back -> a DB trigger on the field is something I have seen before did not expect to encounter it a 2nd time in one lifetime... 🙂

In the case of # 3 you can start concluding that something is "wired".

Cheers,

Julius

0 Kudos

1) As you say, quite unlikly as the profile was never assigned to this particular user on this system

2) Entries are also there for this User in USRBF2 (and also found the profile assigned to some other users)

and also in USREFUS the user exists

3) is there any chance of triggering this without having direct access to the DB ?
could this be some kind of (zero-day-)exploit ?

Thanks a lot for your help getting a clue whats happening here

0 Kudos

If there are more than one user with this phenomenon, then it would indicate something systematic. Generally being misused or generally a program error somewhere.

Is there anything in common between the users? Eg. they are all developers, or all from a certain location, or all men with moustaches? 🙂

Accessing the DB depends on the DB. There are known DB connectivity and SQL connectors, there are known ports which have historically been problematic such as the listener in Oracle, and there are also 0-day exploits which one cannot exclude, but the probability starts becoming more and more theoretical.

With a script or a DB trigger, you should however be able to find some common pattern between these users. And if you reset the buffer and it comes back again then you know that it is reproducible or being reproduced.

It certainly is not normal and something is wrong there.

Cheers,

Julius

0 Kudos

Hello Florian,

pelase keep in mind, that (at least in the past) it was possible to insert generated authroiaztions into profiles. So if that SAP_ALL authroizations have been contained somewhen in a profile, which was/is assigned to the user, the user would get that (*sap_all*-)authorizations through that profile, even if he doe snot have the SAP_ALL profile.

To clean up the assigned user buffer, I can suggest the FM susr_user_buffer_after_change.(see SAP note 452904 )

Input: affected client, the user-ID and in the field 'PROFILE' enter 4 (four).

If the *SAP_ALL*-authorizations will still stay in the buffer afterwards...->oss-ticket.

good luck, Bernhard

0 Kudos

Well, that is why I recommended SU53 'RESET' or report RSUSR405. It is easier to use, achieves exactly the same and is more acceptable to administrate a system from the application or if need be from SA38, than what it is to try the same from the SE37 test environment in production.

The buffer must have synched itself by now if the users logon daily. Would also be interested now to know whether the inconsistency corrected itself or returns again...

Cheers,

Julius