To many hits in SUIM, report RSUSR002

[ChrLid_Swe]

Hi,

We get all to many hits while running the report RSUSR002 (Users by complex selection criteria) in SUIM. And we can't find any reasonable explanation for it. A couple of examples:

1. Object S_TCODE, transaction SM30.

The result will be a list of users where some definitely not have this transaction in any role/profile attached to them.

2. Object S_TABU_DIS, activity=02, Auth grp=* (or empty).

Result. Also users who only has activity=03 will be in the hit list.

3. Object S_USER_GRP give us the same result as in No.2.

We have tried the function module called SUSR_SYNC_USER_TABLES without any change to the result/hit list.

System: R/3 Enterprise (4.7 / 6.20)

Any help appreciated!

[Former Member]

Did you run the SUSR_SYNC_USER_TABLES with table type = X ?

[Former Member]

I have been involved in the issue above that Christer described and yes it was table type X.

I also want to add that the problem is client dependent the problem occur in one client but in the next SUIM works as it should.

The problem with SM30 is that all users with any value in S_TCODE will appear in the report.

Message was edited by:

Mattias Lind

[Former Member]

It "sounds" as if it is a bug in the report (there have been many changes and bug-fixes to these reports - so check your SP level).

However, if it is behaving differently in different clients, then it "sounds" more like an inconsistency in the authorization data to me (user and authorization data is client dependent).

One question: Are you entering SM30 into the "Transaction code" field, or are you entering object 1 = S_TCODE and field TCD = SM30?

Kind regards,

Julius

[Former Member]

It does not matter. We got the same result when we entered SM30 in the Transaction code field and when we entered the object S_TCODE with value SM30.

The strange thing is that it is just that transaction (that we have noticed so far at least) that we have problem with.

When checking all roles and profiles that are containing this transaction and entering them in the "User by complex selection criteria" report then we get a correct list.

So it is only when we are searching for users with this acces we get the problems described in the first post.

Kind Regards

Mattias

[Former Member]

Hmm...

That it is only happening to a specific transaction in a specific client (but not when you select the role or profile) would seem to indicate that the bug is in the data at authorization field value level.

An idea: Take a look in table UST12 field BIS to see whether 'SM30' appears there as a value in an authorization, when field FIELD = 'TCD'?

If you also get the same RSUSR002 results for transaction 'SM30A' or 'SM31' or 'SM29' etc then relax the selection on UST12 field BIS as well.

While there, also check field VON = 'SM30' or 'SM3*' and verify that any authorizations found belong to roles which are legitimate for having this transaction.

Cheers,

Julius

[Former Member]

The closest thing I could find in a quick-check for program corrections is SAP note 1072665. That <i>might</i> explain SM30, but not on it's own.

Have a nice weekend anyway

Cheers,

Julius

[Former Member]

The second case you describe, where you get users with value 03 when searching for users with star (), is well known. SUIM doesn't search for the sepcific value '', but interprets it as if you want to list users with 'any' value. In other words, the star is interpreted as a wildcard in the search criteria, not an exact value. You'll probably have to write a custom report checking the AGR_12* tables for specific values...

Regards,

Trond

[ChrLid_Swe]

Hi Trond,

Thanks for your answer!

I agree with you it is always somewhat confusing to use the star (*) as a search criteria in SUIM reports.

But do you really mean that a star (*) value in the field for Authorization group would 'ruin' also the search for a specific value in the field Activity (value 02 in our case)???

Because in our example it was the activity we were interested in the first place, not the Auth group.

[Former Member]

Hello Trond,

I would also be curious. I have been using that report for many years and have seen some bugs... but I am not aware of that one on a <i>reasonably</i> up-to-date SP level.

The object S_USER_GRP has 2 fields - one for the action to be permitted (activity) and the other for the maintained group on the user record => fullfilling the who can do what to which user argument.

What is sometimes not understood, is that the selection values themselves in SUIM are not the same as the field values in the authorizations.

My understanding of the SUIM selection logic is as follows:

If you select a "*", you will get "anything" if the field is available.

If you select "ABC*" you will get 'ABC' and anything starting with "ABC...".

If you select a "#**" you will get "all possible values" known for the field.

If you select "#" you will get those who have a "" as the value in the authorization.

If you select " '<space>' " you will get empty fields.

What is also often not understood in "writing your own report" or "downloading the data" is that you should first select the data records, to determine what the group value is on them (if present), before checking the activity.

"Download tools" in my experience often select the wrong tables, are not "real time" (they are immediately redundant at the time of download) and the logic /data can often easily be changed by the user in the end user application.

In extreme cases the data which is realy checked by AUTHORITY-CHECK statements or system validations of the user's authority (checks which are performed "beyond the boundary of the ABAP statements") are not given the necessary priority.

Of one thing I am certain: SUIM or no-SUIM, such checks are blind to most of customizing, rules for the checks, Z-objects etc. For that you need good quality code / change reviews to ensure that the concept is implemented consistenty, and therefore sustainably.

@ Christer and Mattias: That the report is doing this seems odd to me...

A rather extreme explanation could be that there is a naming / numbering collision => try to run the same report in your QA system (where the roles would be expected to be the same). Does the report deliver the same list of all users?

Regarding the tcode SM30 question, I had another idea: Run the report for object 1 = Q_TCODE TCD = 'SM30'. Do you get the same result?

Kind regards,

Julius

Message was edited by:

Julius Bussche

[Former Member]

Hi,

Finally we found the problem to this issue. After debugging the program RSUSR002 we found out that an error occurred if a search result on an authorization object was contained in more than 500 authorizations. Then the program picked the full list of profiles that contained the object instead of limiting the result on the search criteria.

It also explains why this problem did not occur in all clients since in some client we had not reached the number of 500 authorizations that contained the values in the search.

OSS note 977898 was applied to correct the program.

Best Regards and thank you all for all good inputs in this matter

Mattias Lind

[Former Member]

Hi Mattias,

Thanks for following up with the solution.

I assumed the thread answered now.

Cheers,

Julius

[ChrLid_Swe]

Problem finally solved. See details posted by Mattias.

Thanks everyone for the input on this one!

Regards,

Christer