- Whenever possible use an SAP-delivered authorization to control access to a transaction.

- Every ABAP should have an Authorization Check line attached and be placed into an authorization group.

- All new objects created by EWMS should be named with the first letter being Y or Z to protect them from future SAP upgrades. In practice, Z is typically the only letter used.

- Be sure to document EVERY object, authorization, profile that you change, create, delete, activate even if only for a few moments. Otherwise it will quickly become impossible to remember which authorizations and profiles are in use and which are garbage. Any authorizations or profiles that are developed should be documented.

- All authorizations relating to the ability to sign-on, print, view an in-box, run a job in background, etc. belong in the base profile ZS_A.USER. This is the minimum R/3 sign-on with NO application access. This profile will be granted to every user.

- Profiles should be designed in such a way that the Business Unit and the Security Administrator don’t have to consider segregation of duties issues in the day to day creation and deletion of user accounts. This can be achieved by standardizing on profiles (e.g. keeping the number of end-user profiles under 40) and keeping a matrix of incompatible roles.

- Where possible, authorization group names, printer names etc. should be designed in a way to support wild card characters in authorizations. e.g. HQ* means all printers in the HQ building.

- All custom profiles and authorizations must begin with the letter Z.

- End-user profiles that can be distributed to decentralized staff (e.g. in the plants) must be like one of:

ZI_PM*, ZC_PS*, etc.

See the authorization below for the exact format.

- End-user profiles that are to be held centrally for special job functions such as accounting, accounts payable etc. must be like one of:

ZH_AP*, ZH_FI*, etc.

See the authorization below for the exact format.

- Custom profiles that are not end-user profiles but building blocks only, must begin with ZB_*.

- All newly created authorizations must begin with Z. Follow the convention ZSHOW, ZSHOW2, ... for display only authorizations. Use Zxxx_ALL for update type authorizations. Where convenient, use an SAP delivered authorization before creating a new one. When searching for SAP delivered authorizations note that in German, ANZ means read-only and ALL means update. Always double-check SAP authorizations as a few “ANZ” type authorizations grant update rights, and some are so old that they are not quite correct for the current version.

- All new authorization objects must be placed in the class ZCUS and must begin with Z_ . e.g. Z_TCODE

- A batch user-id will be created to handle regular interface jobs, nightly backup, monitoring reports etc. The user-id should NOT be an on-line user-id. The range of abaps accessible to the batch user-id should be restricted through authorizations??? (may be too inconvenient).

Detailed requirements including Control Objectives, Risks and Techniques are located on the LAN in l:\oper\sap\security\reqmnts\cont-XX.doc where XX represents a functional area such as HR, MM, AP, FI, etc.

The design specification for each role is in a Microsoft Access table in the database AUTH.MDB. The table name is RIGHTS and it maps roles to transactions. Also, the Word document profdes.doc describes profile naming conventions and hierarchy.

A copy of R/3’s authorization object documentation has been downloaded to a Word document and printed. The document name is l:\oper\sap\security\authdocu.doc . The same information is available on-line via the transaction SU03 and the menu selection Overview->Object List/Doc .

The following tables contain information relevant to authorizations. They can be viewed on-line via the SE16 transaction. For convenience, some have been downloaded into Microsoft Access.

TSTCT:

Lists every R/3 transaction and provides a description

TSTCA:

Lists authorizations required to enter into a transaction. Approximately 1,750 transactions are controlled this way.

TSTCP:

Lists “fast path” transactions. Fast paths are not transactions but are short cuts to real transactions. For example F-43 is a fast path to the transaction FB01 using some field values useful for invoice entry.

TRDIR:

Lists ABAP programs and the Authorization attribute of each program (in the field SECU).

TDDAT:

Lists R/3 tables and the authorization group required to view or edit each via table viewing and editing transactions such as SM31.

TACTT:

Lists the activity codes commonly used in authorizations

TOBJ,TOBJT:

Lists the authorization objects and their associated fields.

TPARAT:

Lists the parameters (default values) available for end users. Examples of default values or WRK for Plant, BUK for Company Code

Some name

Craig has over 25 years of Technology Consulting experience including 10 years in Project Leadership roles. He has extensive background working with large scale, high-profile systems integration and development projects that span a customer’s organization, and experience designing robust solutions that bring together multiple platforms from Intel to Unix to Mainframe technologies with the Internet.