Transaction to list userswith SAP_ALL&SAP_NEW Authorisation

[Former Member]

Hi,

Can some one please tell me if there is a transaction by which we can find out the list of users that has the SAP_ALL and SAP_NEW authorisation profile assigned to it.

Thanks

Priya

[morten_nielsen]

Hi

Take a look at transaction S_BCE_68001395

Regards

Morten Nielsen

[Former Member]

Hi Morten,

Thanks for the quick reply.

This transaction was the what I wanted.

Thanks a lot for the help.

Priya

[Former Member]

Hi,

As Morten states that transaction provides you with the solution. For education purposes this is basically a sub-query of the SUIM transaction. This transaction "User Information System" allows you to query user masters/authorization data etc based on various field(s) you choose.

So in your example any user with SAP_ALL, or it could be any user who hasn't logged in for 90 Days, or any user who has Role Z_ABC_1.

I hope this helps you/and others, with any future user master queries, it is a very useful transaction.

Ashley Day

[koehntopp]

I would like to suggest that you check for users with critical transactions instead, I suppose you would also like to catch users with renamed SAP_ALL profiles.

Also, this is only a very tiny element of authorization based security. A combination with two or three auth objects can make you more powerful than SAP_ALL in no time, if you know how to do it...

Frank.

[Former Member]

Does anyone know how to set this up to run monthly as a batch job and have the report e-mailed to an end-users mail box?

thanks,

Dawn Longo

[former_member912992]

Hi Dawn

Set the program to be executed as a background job. Afterwards, go to t. code SM37, find the job, change it and click on the 'spool recipient' button. There you can define who should receive the report in the mailbox.

Regards

Agoes

[Former Member]

When I enter SAPLSUSD for the program it tells me that program can't be run in the background because it's not type 1 or J. If I put rsusr002 or any of those programs/tables I get all information in the usr02 table.

We have many, many, many different production systems and I need to go in every month and see if anyone has the sap_all, sap_new profiles and I'm trying to automate this with the suim reports but it does not seem to be doable.

I may have to have a developer help but I thought I would ask out ther.

[koehntopp]

Coming back to my suggestion: would you catch those who renamed the profile and/or created their own version of it?

Yes, of course your excercise will catch the obvious ones, but this is completely useless if you can outsmart the report so easily...

Kind regards,

Frank.

[Former Member]

Hi Frank,

There are ways of automating some of it if the assumption that change documents

are created holds true (meaning that the preventative measures of bypassing the

creation of change documents are implemented) and even better if an (ab)user

does not know about the control...

Here are some of them which I have seen: (actually one of them did see me first

One of the better solutions involved both an interrogation of user to profile

assignments (USR04) AND the change documents (USH04) => because the

profile might have been removed before the "current" detective control is

performed. For that (profiles or roles) there is a standard report called RSUSR100

to read the change documents.

Once identified, the available profiles of SAP_ALL and equivalents can be

automatically sent to you if you can get the system to create a job on an

hourly basis which submits report RSUSR100 for a "from -> to" period (like

from '31.12.9999' to 'sy-datum minus n days'). If it finds such a change document

or new existing entry in UST04, it fires an alert with details within the hour.

There are several different ways of doing this with very low effort, and in all

existent clients.... also without making the job visible in SM37, with a bit more

effort.

This would however be unlikely to detect that which you are refering to: What if

SAP_ALL is copied or the authorization is manually imported into a role which

the user already has? For that you would need to go looking in UST10 (the

assignment of authorizations to profiles) or ideally USR10; or USH10 for the

change documents. If you find &_SAP_ALL or equivalent authorizations in the

change documents or they do not match the profile names... then fire the same

alert as before. I cannot remember how this was done done (which report etc)

and do not have access to the system anymore.

That would however not pass all requirements for automated detective controls,

because someone may have changed the authorization values of those auths

which are already assigned via profiles which the user has... For that you would

need to go prying in USH12 to see whether anything changed. For the current

authorization, looking in UST12 is easier to understand than USR12; but they

should be the same. Note that this access would be instant so there is no

necessity (nor sense) in searching for change documents relating to the user,

only change documents for object <-> field <-> values which you know to be

equivalent to SAP_ALL.

Another approach is to use the SAP standard rules in tables USK* (search SAP

notes on it, and the report RSUSR008_009_NEW) to define critical authorizations

which cannot be assigned, or critical authorizations which cannot be combined

together. I have seen one solution which used it to prevent the assignment of the

authorizations from tcode SU01 etc. I also suspect that it is (more...) sustainable

and less maintenance work in the long run, than programming an own report or

buying an external tool (someone else's own report).

Cheers,

Julius

[Former Member]

Hello Julius,

I'm currently work on a list of critical HR authorizations on a 4.7 system. Well, it's not so easy to understand the logic behind the authorization ids, the critical authorizations and the critical combinations. Do you already got a clue? Anyway it works quite well with the already defined authorizations and we were also able to correct many of our roles. What are your experiences with the report?

Regards,

Ben Göbel

[Former Member]

Hi Ben,

My experience in the past was somewhat limited as far as practical experience is concerned, because I was an auditor (see evil, hear evil, do nothing (in the sence taht auditors dont actually implement security)).

But I did hear and see a lot about the report and its predecessor (RSUSR009) and did some tests in a sandbox in 46C. It was tricky to use and nothing for magic "one size fits all" SOD stuff...

I hope to change that this year with an implementation of RSUSR008_009_NEW for some key basic critical authorizations and fundamental conflicts (the ones which would not care about S_TCODE (bar a few discreet ones). I am hoping to be able to come up with a set which covers about 80% of the risk and can be implemented in 1 day (excluding remediation of the system config and role design...).

I will update the thread if I learn anything interesting from the experience (planned for Q3 2007 - I am working on it already in my own time, out of inquisitiveness).

Regarding HR... sorry. No experience there yet with the report. But key things to understand are the search icons work (See SAP Note 978447 which is the latest released one) and how the logical operators AND & OR are to be used (See Note 1003763) within and between the authorization IDs.

Perhaps we will see an IF / THEN / ELSE logical operator some time...

Cheers,

Julius

Message was edited by:

Julius Bussche

[Former Member]

Hi Priya,

The simplest approach here is , use transaction SA38, you run report RSUSR002, before executing u can enter SAP_ALL and SAP_NEW in profile parameters, you will get list of all users who have SAP_ALL and SAP_NEW.

this will solve your purpose.

bye

puneet singh