Using Google Chrome?

Download my
free Chrome Extension, Power Notes Searcher, to make searching for and evaluating SAP notes, much easier.

Recent Posts

Tuesday, January 29, 2013

HowTo: Secure ABAP Reports with an Authorization Group

Securing reports in SAP is different to securing transaction codes.
Reports don't necessarily have to have any authorisation checks inside them.
Instead, you have to assign the reports a authorisation groups to control access.

This is a one-to-one assignment only.  So does't give that much flexibility.
From transaction SE38 in your DEV SAP system, enter the report you wish to secure, then select “Attributes” from the radio options, and click “Change”:



You can maintain in the original language if you wish.

Simply insert the authorisation group you wish to secure the report against, into the “Authorization Group” field and click “Save”:



If you have not created this auth group before, then you will be prompted to create a “New Entry”.
You will be prompted for a transport request.

You should now activate your report:



You can now secure the report by removing this specific auth group from the auth object S_DEVELOP in your roles:



Wednesday, January 23, 2013

HowTo: Query to show SAP roles and transaction codes by user

Scenario: You have been requested to provide a list of all roles currently assigned to your SAP user accounts, plus the transaction codes that are assigned to each role and user account.

HINT: To be able to do this within SAP, you can use the SAP QuickViewer (SQVI) to create a query and join the required tables. You could then generate a program and then copy it to create your own Z-report.

Using the following Oracle SQL*Plus query at the database level, will allow you to produce a report containing the USERNAME, ROLENAME, TCODE_RANGE_START and TCODE_RANGE_END.

set linesize 500 pagesize 9999 newpage none recsep none
SELECT u.uname USERNAME,
               r.agr_name ROLENAME,
               r.low TCODE_RANGE_START,
               r.high TCODE_RANGE_END
  FROM agr_1251 r,
       (select mandt,
               uname,
               agr_name
          from agr_users) u
 WHERE r.agr_name = u.agr_name
   AND r.mandt = u.mandt
   AND r.mandt = <YOUR CLIENT>
   AND r.object='S_TCODE'
ORDER BY u.uname,r.agr_name,r.low,r.high;


NOTE: You should adjust "<YOUR CLIENT>" to be the client number you wish to check.

You should note that TCODE_RANGE_START and TCODE_RANGE_END could contain wild cards as per the usual methods of providing a range of values to an authorisation object in PFCG.

Sunday, January 13, 2013

HowTo: Use AWR snapshot data to provide a history of sequential read values

Scenario: You have changed your back-end storage hardware (SAN array or SATA disk storage) and you want to see a historical overview of sequential read times of your database.

It's possible to query the Oracle AWR data (provided you have paid for the license), to provide a historical list of sequential read times acccording to the snapshots taken by AWR.
You are obviously limited to the amount of data retained by AWR and the frequency of the AWR snapshots.

set linesize 400 pagesize 400
SELECT event_start.snap_id,
       to_char(snap.begin_interval_time,'DD-MM-YY HH24:MI') as begin_time,
       to_char(snap.end_interval_time,'HH24:MI') as end_time,
       round(decode(
                 (event_end.total_waits - nvl(event_start.total_waits, 0)),0, to_number(NULL),
       ((event_end.time_waited_micro -    nvl(event_start.time_waited_micro,0))/1000) / (event_end.total_waits - nvl(event_start.total_waits,0))
),0) avgwait,
       event_end.event_name event_name,
      (event_end.time_waited_micro - nvl(event_start.time_waited_micro,0)/1000000) total_ms,
      event_end.total_waits
FROM dba_hist_system_event event_start,
     dba_hist_system_event event_end,
     dba_hist_snapshot snap
WHERE event_end.snap_id = event_start.snap_id + 1
  AND event_end.event_name = 'db file sequential read'
  AND event_start.event_name = event_end.event_name
  AND event_start.snap_id = snap.snap_id
  AND event_start.dbid = snap.dbid
  AND event_start.instance_number = snap.instance_number
  AND snap.begin_interval_time > SYSDATE - 14            -- max 14 days history.
-- AND to_char(snap.begin_interval_time,'HH24') IN ('09','10','11','12','13','14','15','16','17')
-- AND to_char(snap.begin_interval_time,'MI') = '50'
ORDER BY event_start.snap_id;


NOTE: You can restrict the snapshot intervals used to provide "hourly" values by uncommenting the additional two lines.

Friday, January 04, 2013

HowTo: Hide SAP tables including USR02

Within an SAP system, the user account passwords are hashed and stored in the SAP schema table USR02.
If the SAP system users have access to transaction SE16, then it's possible for them to view the USR02 table by default.

This would present the user with the opportunity of seeing the password hash values.



It would be possible to spot a commonly used password hash and provided the user knows the actual password text that generated the hash, could use it to log in as a different SAP user, maybe with higher privileges.

More importantly, if the user manages to modify the table through transaction SM30, they could set their own hashes.

It is better to create a new authorisation group for the USR02 table, then exclude this specific auth group from the user roles via auth object S_TABU_DIS and setting the "Authorization Group" field.

An example would be to create a new authorisation group "ZZND" (zz no display) in transaction SE54.
Then, still in SE54, assign all the tables you do not wish anyone to see, to the new auth group.






Use transaction PFCG to edit your roles and change authorisation S_TABU_DIS, so that the field "Authorization Group" is set to a range "$*" to "ZY*" (it excludes ZZ*):






The next time the users try to access the table, they will receive a no authorization prompt in SE16.

UPDATE 30/05/2014: The post above was based on R/3 4.7.  Later releases may have an SC auth group already defined with the USR* tables, plus others, already defined.  You may still wish to create your own ZZND auth group to ensure continuity across upgrades and for your own standardisation practices if you must customise the list of tables in the auth group.  Thanks Matt.