Authorization object class: Logical grouping of authorization objects (for example, all authorization objects for object class

FI beginning with .F_.) Authorization object: Groups 1 to 10 authorization fields together. These fields are then checked simultaneously (example: F_LFA1_APP, vendor: application authorization) Authorization field: Smallest unit against which a check is to be run (ACTVT, APPKZ) Authorization: An instance of an authorization object, that is, a combination of allowed values for each authorization field of an authorization object Authorization profile: Contains instances (authorizations) for different authorization objects Role: A role describes the activities of an SAP user. Its is generated using the Profile Generator (transaction .PFCG.), and allows the automatic generation of an authorization profile User/user master record: Used for logging on to SAP systems and grants restricted access to functions and objects of the SAP system based on authorization profiles. Created when a user is created ** Every customer can create their own authorization object classes, authorization objects, and authorization fields.

****************** What is the Profile Generator? The Profile Generator is the central tool for generating authorizations and authorization profiles and assigning them to users

Before the Profile Generator can be used, you must activate it in the system. Activating the Profile Generator after a new installation requires that: - The SAP system profile parameter auth/no_check_in_some_cases has the value Y - The default tables are filled which control the behavior of the Profile Generator when a transaction is selected in a role.

With new settings (since SAP R/3 4.6), the parameter is already set to Y in the default settings. *************** Steps to create a Role: Define Role Name Determine Activities Maintain Authorization Data Generate Authorization Profiles Assign Users User Master Record comparison

Significance of different traffic lights RED-- atleast one org value field is blank YELLOW--atleast one non org value field is blank GREEN--all field values are maintained STATUS OF AUTH OBJECTS Standard Maintained Changed Manually ****************** Types of Roles

Single Roles

Composite Roles It is a combination of multiple Single roles/Derived roles Master Roles and Derived Roles: - A master role is defined to contain all transactions required by a position in order to perform a Companys business role. It is basically a collection of transactions needed to carry out daily business activities in SAP. All authorization values are determined when creating a master role, but asterisks (i.e., an asterisks indicates access to all values) are given to all organizational level fields. The master role shall never be assigned to end users, but exists only as template for derive roles according to the organization level segregation decisions. - A derived role is a role that inherits the characteristics of its master role. It inherits the transactions as well as the authorization object values except for organizational level values. Two derived roles from a master role will differ from each other thru the organizational level field values. SU24 provides a template of the supporting authorization objects that are necessary to execute a particular Transaction code.

Process-based Each Role can performs one function (usually one or only a few Transactions) Vendor master creation Create sales order

Job-based Each Role contains most functions that a user will need for their job in the organization A/P Clerk Buyer Warehouse Manager

Profiles

 Authorization Objects are stored in Profiles Profiles are the original SAP Authorization infrastructure Ultimately a users Authorization comes from the Profile/s that they have assigned Profiles are different from Roles.

Users: Creation, Maintenance and Types To access the SAP system and work in the system, a user master record with authorizations is required A user can only logon to an SAP system if a user master record with a corresponding password exists. The scope of activity of individual users in the SAP system is defined in the master record by one or more roles, and is restricted by the assignment of the appropriate authorizations ** User master records are client-specific User Types: The user type is an important property of a user. Different user types are available for different purposes: Dialog (A) A normal dialog user is used for all logon types by exactly one person. During a dialog logon, the system checks for expired/initial passwords, and the user has the opportunity to change his or her own password. Multiple dialog logons are checked and, if appropriate, logged

System (B) User type for background processing and communication within a system (internal RFC calls): - A dialog logon is not possible.

- The system does not check whether the password has expired or is initial. - Only the user administrator can change the password. Communication (C) User type for dialog-free communication between systems (such as RFC users for ALE, Workflow, TMS, and CUA): A dialog logon is not possible. Whether the system checks for expired or initial passwords depends on the logon method (interactive or not interactive). Due to a lack of interaction, no request for a change of password occurs.

Service (S) User type that is a dialog user available to a larger, anonymous group of users. Assign only very restricted authorizations for this user type: - During a logon, the system does not check whether the password has expired or is initial. Only the user administrator can change the password - Multiple logons are permissible. Reference(L) User type for general, non-person related users that allow assignment of additonal identical authorizations, such as for internet users created with transaction SU01. You cannot log on to the sytem with a reference user.

User Group for Authorization Check: To assign the user to a user group, enter the user group. This is required if you want to divide user maintenance among several user administrators. Only the administrator that has authorization for this group can maintain users of this group. If you leave the field empty, the user is not assigned to any group. This means that any user administrator can maintain the user.

Transporting Authorizations Authorization components such as roles should be created and tested in development systems, and not in production systems. At the end of the test phase they are transported from the development systems to the production system. Which Authorization Components Can Be Transported? - Roles - Authorization profiles - Check indicators Transporting Roles with User Assignment: If you transport user assignments, the entire user assignment for the role in the target system is replaced. Types of transport requests CUSTOMIZING -Client dependent, e.g.Role WORKBENCH REQUESTS -Client independent, e.g.SU24 check indicators

Uploading and Downloading Roles - When you download the data, it is all stored in a local file, with the exception of the generated authorization profiles and the user assignments. - After an upload, the role might have to be edited and generated.

SAP_ALL: To assign all authorizations that exist in the SAP system to users,assign the profile SAP_ALL. SAP_NEW: Composite profile to bridge the differences in releases in the case of new or changed authorization checks for existing functions, so that your users can continue to work as normal.

Authorization Checks 1) Does the Transaction exist? All Transactions have an entry in table TSTC

2) Is the Transaction locked? Transactions are locked using Transaction SM01 Once locked, they cannot be used in any client

3) Can the User start the Transaction? Every Transaction requires that the user have the Object S_TCODE=Transaction Name Some Transactions also require another Authorization Object to start (varies depending on the Transaction)

4) What can the User do in the Transaction? The system will check to see if the user has additional Authorization Objects as necessary Error Analysis for Authorization Problems If you cannot find documentation about authorization for a transaction, or if a failed authorization check is always reported when you execute a transaction,there are two ways in which you can determine the required authorizations: 1. With the authorization error analysis and Tcode SU53 2. With the authorization trace ST01 Values of RC in System trace RC=0 User has access to the authorization object via the assigned profiles RC=4 User has access to the authorization object but not to the exact field values RC=12 user does not have access to the authorization object in any of the assigned roles or profiles Profile Parameters and Password rules for user logon

login/min_password_lng: This parameter defines the minimum length of the logon password. The password must have at least .3. characters, but the administrator can force a longer length. login/fails_to_session_end: Number of incorrect logon attempts allowed with a user master record before the logon procedure is terminated. login/fails_to_user_lock: Number of incorrect logon attempts allowed with a user master record before the user master record is locked. An entry is written in the system log at the same time. The lock is removed at midnight. login/failed_user_auto_unlock: Controls unlocking of the users locked due to an incorrect logon. If the parameter is set to 1 (default), user locks caused by incorrect logons during previous days are not taken into consideration. If the value is set to 0, the lock is not removed. login/password_expiration_time: The value .0. means that the user is not forced to change the password. A value .> 0. specifies the number of days after which the user must change the logon password. Sensitive authorization objects S_TCODE S_PROGRAM S_TABU_DIS S_TABU_CLI S_DEVELOP S_TRANSPRT S_USER_AGR S_USER_AUT S_USER_GRP S_USER_PRO

Important Tcodes and Tables

Tcodes SU01 SU10 SU24 PFCG SUIM ST01 SU53 SU56 SU21 SU20 SE01/09/10

Tables USR02 AGR_1251 AGR_1252 AGR_USERS AGR_TCODES AGR_AGRS AGR_DEFINE