10-31-2006 9:32 AM
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
10-31-2006 9:42 AM
10-31-2006 9:42 AM
10-31-2006 9:50 AM
Hi Morten,
Thanks for the quick reply.
This transaction was the what I wanted.
Thanks a lot for the help.
Priya
10-31-2006 5:03 PM
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
11-02-2006 12:13 PM
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.
01-17-2007 6:06 PM
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
01-18-2007 1:39 PM
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
01-19-2007 2:04 PM
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.
01-22-2007 2:27 PM
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.
02-10-2007 10:50 AM
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
02-22-2007 10:35 AM
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
03-01-2007 9:19 PM
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
03-02-2007 6:52 AM
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