USER TYPES IN R/3 SECURITY: Characterization of user types Dialog user 'A‘ Individual system access (personalized) Logon with SAPGUI is possible. The user is therefore interaction-capable with the SAPGUI. Expired or initial passwords are checked. Users have the option of changing their own passwords. Multiple logon is possible but we can restrict by parameter Ex : End users, Support users etc. Service user 'S‘ Shared system access (anonymous) Logon with SAPGUI is possible. The user is therefore interaction-capable with the SAPGUI. The passwords are not subject to the password change requirement, that is, they cannot be initial or expired. Only a user administrator can change the password. Multiple logon is permitted. Ex : Fire Fighter Id System user 'B‘ System-dependent and system-internal operations Logon with SAPGUI is not possible. The user is therefore not interaction-capable with the SAPGUI. The passwords are not subject to the password change requirement, that is, they cannot be initial or expired. Only an administrator user can change the password. It is used to communicate within the system. Ex : Internal RFC, background processing, external RFC (for example, ALE, workflow, TMS, CUA) Communication user 'C‘ : Logon with SAPGUI is not possible. The user is therefore not interaction-capable with the SAPGUI. It is also one type of background user and communicates between the systems. Ex : external RFC , CUA Reference user 'L' Authorization enhancement —No dialog logon is possible. —Reference users are used for providing extra privileges of a user who is going on vacation or leave to existing users. Ex : Internet users with identical authorizations For more information visit www.keylabstraining.com HOW TO CREATE USER IN SAP? Before creating the user in sap system we need details of the user(i.e User id, First name, Last name, email Id, User Group, validity period & required authorizations(Roles/Profiles)etc). After that we need to take the approvals from the appropriate managers. Important Note :- For creation of the new user account some of the mandatory fields that we need to fill are User id, Last name, Password. There after we have to follow bellow steps: 1. Execute SU01 2. Enter user name and press CREATE (notepad) 3. Enter necessary details such as Firstname and Lastname 4. Click on Logon Data Tab and enter password a password eg: Keylabs123 5. 6. Then give the required authorizations in Roles, profiles tab. Click Save . Now you can informed the user that his/her account has been created. AUTHORIZATION CHECKS : Authorization Checks Starting SAP Transactions : When a user starts a transaction, the system performs the following checks: The system checks in table TSTC whether the transaction code is valid and whether the system administrator has locked the transaction. The system then checks whether the user has authorization to start the transaction. The SAP system performs the authorization checks every time a user starts a transaction from the menu or by entering a command. Indirectly called transactions are not included in this authorization check. For more complex transactions, which call other transactions, there are additional authorization checks. The authorization object S_TCODE (transaction start) contains the field TCD (transaction code). The user must have an authorization with a value for the selected transaction code. If an additional authorization is entered using transaction SE93 for the transaction to be started, the user also requires the suitable defined authorization object ( TSTA, table TSTCA). If you create a transaction in transaction SE93, you can assign an additional authorization to this transaction. This is useful, if you want to be able to protect a transaction with a separate authorization. If this is not the case, you should consider using other methods to protect the transaction (such as AUTHORITY-CHECK at program level). The system checks whether the transaction code is assigned an authorization object. If so, a check is made that the user has authorization for this authorization object. The check is not performed in the following cases: You have deactivated the check of the authorization objects for the transaction (with transaction SU24) using check indicators, that is, you have removed an authorization object entered using transaction SE93. You cannot deactivate the check for objects from the SAP NetWeaver and HR areas. This can be useful, as a large number of authorization objects are often checked when transactions are executed, since the transaction calls other work areas in the background. In order for these checks to be executed successfully, the user in question must have the appropriate authorizations. This results in some users having more authorization than they strictly need. It also leads to an increased maintenance workload. You can therefore deactivate authorization checks of this type in a targeted manner using transaction SU24. You have globally deactivated authorization objects for all transactions with transaction SU24 or transaction SU25. So that the entries that you have made with transactions SU24 and SU25 become effective, you must set the profile parameter AUTH/NO_CHECK_IN_SOME_CASES to ―Y‖ (using transaction RZ10). All of the above checks must be successful so that the user can start the transaction. Otherwise, the transaction is not called and the system displays an appropriate message. Checking Assignment of Authorization Groups to Tables You can also assign authorization groups to tables to avoid users accessing tables using general access tools (such as transaction SE16). A user requires not only authorization to execute the tool, but must also have authorization to be permitted to access tables with the relevant group assignments. For this case, we deliver tables with predefined assignments to authorization groups. The assignments are defined in table TDDAT; the checked authorization object is S_TABU_DIS . SAP SECURITY,AUTHORIZATIONS : An authorization is a permission to perform a certain action in the SAP System. Authorizations are used to control access at the application level.. SAP Authorization concept is basically used for SAP Security. Security: Security means protecting your data and your business. SAP Authorization Architecture Structure of Authorization is as follows: Field: Smallest unit against which a check should be run. It is a least granular element/data element to secure the data/information. Authorizations: Authorizations are used to control access at the application level. Authorization Object: Groups 1 to 10 authorization fields together. These fields are then checked simultaneously. Authorization Object Class: Logical grouping of authorization objects. Profile: Profiles is to provide Authorization based on provided Authorizations and Authorization Objects. We used to create profiles up to 4.6C version in SU02 Transaction Code, after 4.6C version these profiles will create automatically while modifying/creating roles or generation roles. Role: Its is a combination of Menu ’s, Authorizations, Profiles and personalization. A role is a group of activities performed within business scenarios. Or Activities assigned to the user. Or a role is a set of functions describing a specific work area. Roles consist of Menu, Authorizations, Organizational values. PROFILE PARAMETERS FOR LOGON: Parameters login/min_password_lng Explanation Defines the minimum length of the password. Default value: 3; permissible values: 3 –8 Defines the minimum number of digits (0-9) in passwords. Default value: 0; permissible values: 0 –8 Available as of SAP Web AS 6.10 Defines the minimum number of letters (A-Z) in passwords. Default value: 0; permissible values: 0 –8 login/min_password_digits login/min_password_letters login/min_password_specials login/min_password_diff login/password_expiration_time login/password_change_for_SSO login/disable_password_logon login/password_logon_usergroup Available as of SAP Web AS 6.10 Defines the minimum number of special characters in the password Permissible special characters are ()!\"@ $%&/()=?'`*+~#-_.,;:{[]}\\ Default value: 0; permissible values: 0 –8 Available as of SAP Web AS 6.10 Defines the minimum number of characters that must be different in the new password compared to the old password. Default value: 1; permissible values: 1 –8 Available as of SAP Web AS 6.10 Defines the validity period of passwords in days. Default value: 0; permissible values: any numerical value If the user logs on with Single SignOn, checks whether the user must change his or her password. Available as of SAP Web AS 6.10, as of SAP Basis 4.6 by Support Package Controls the deactivation of password-based logon Available as of SAP Web AS 6.10, as of SAP Basis 4.6 by Support Package Controls the deactivation of password-based logon for user groups Available as of SAP Web AS 6.10, as of SAP Basis 4.6 by Support Package SU25-PROFILE UPGRADATION: Why SU25 is required? In SAP security the two standered tables are USOBT&USOBX which contains SAP security type data. This is a single time activity.when you click on initially fill the customer tables option the data will be copied into customer tables USOBT_C ,USOBX_C from USOBT &USOBX. The table USOBT contains T-CODE Vs Authorization object. The Table USOBX contains checkindicators for USOBT table After upgrading SAP with the new release, you need to make adjustment to the all the roles and transaction codes.SU25 is the transaction code for upgrading profile generator. This has 6 different steps and the execution of these steps depends on whether you were already using profile generator in the last release. This transaction has 6 steps. This transaction is used to fill the customer tables of the Profile Generator the first time the Profile Generator is used, it will update the customer tables after an upgrade. The customers tables of the Profile Generator are used to add a copy of the SAP default values for the check indicators and field values. These check indicators and field values are maintained in transaction SU24. If you have made changes to check indicators, you can compare these with the SAP default values and adjust your check indicators as needed. Step1: If you have not yet used the Profile Generator or you want to add all SAP default values again, use the initial fill procedure for the customer tables. If you have used the Profile Generator in an earlier Release and want to compare the data with the new SAP defaults after an upgrade, use steps 2a to 2d. Execute the steps in the order specified here. Step 2a: Is used to prepare the comparison and must be executed first. Step 2b: If you have made changes to check indicators or field values in transaction SU24, you can compare these with the new SAP default values. The values delivered by SAP are displayed next to the values you have chosen so that you can adjust them if necessary. If you double-click on the line, you can assign check indicators and field values. You maintain these as described in the documentation for transaction SU24. Note on the list of transactions to be checked To the right of the list you can see the status which shows whether or not a transaction has already been checked. At first the status is set to to be checked. If you choose the transaction in the change mode and then choose save, the status is automatically set to checked. By choosing the relevant menu option in the list of transactions you can manually set the status to checked without changing check indicators or field values, or even reset this status to to be checked. If you want to use the SAP default values for all the transactions that you have not yet checked manually, you can choose the menu option to copy the remaining SAP default values. Step 2c: You can determine which roles are affected by changes to authorization data. The corresponding authorization profiles need to be edited and regenerated. The affected roles are assigned the status ―profile comparison required‖. Alternatively you can dispense with editing the roles and manually assign the users the profile SAP_NEW (make sure the profile SAP_NEW only contains the sub profiles corresponding to your release upgrade. This profile contains authorizations for all new checks in existing transactions). The roles are assigned the status ―profile comparison required‖ and can be modified at the next required change (for example, when the role menu is changed). This procedure is useful if a large number of roles are used as it allows you to modify each role as you have time. Step 2d: Transactions in the R/3 System are occasionally replaced by one or more other transactions. This step is used to create a list of all roles that contain transactions replaced by one or more other transactions. The list includes the old and new transaction codes. You can replace the transactions in the roles as needed. Double-click the list to go to the role. Step 3: This step transports the changes made in steps 1, 2a, and 2b. Tailoring the Authorization Checks This area is used to make changes to the authorization checks. Step 4: Changes to the check indicators are made in step 4. You can also go to step 4 by calling transaction SU24. -You can then change an authorization check within a transaction. -When a profile to grant the user authorization to execute a transaction is generated, the authorizations are only added to the Profile Generator when the check indicator is set to Check/Maintain. -If the check indicator is set to do not check, the system does not check the authorization object of the relevant transaction. -You can also edit authorization templates that can be added to the authorizations for a role in the Profile Generator. These are used to combine general authorizations that many users need. SAP delivers a number of templates that you can add directly to the role, or copy and then create your own templates, which you can also add to roles. In step 5 you can deactivate authorization objects system wide. In step 6 you can create roles from authorization profiles that you generated manually. You then need to tailor and check these roles. USER MASTER RECORD : The concept of user master records User master records defines the user accounts for enabling access to the SAP system. The user master record is mainly used for user administrative and Authorization management (Role Administration). Normally, the user master record contains the user id as well as a wealth of other information which can be used by SAP system administrators in managing users effectively. For example, the user master record contains information which validates a user log on session. User master record stores important information like users access rights to SAP, user's passwords, the authorization profiles and so on. User master records can be accessed using the Transaction T Code SU01. In t-code SU01, users can be displayed by user id or in case one does not know the user id, users can be displayed using all possible entries. You need authorizations to create or maintain user master records: Authorization to create and/or maintain user master records and to assign a user group (Auth.object S_USER_GRP). Authorization for the authorization profiles you want to assign to users (Auth.object S_USER_PRO). Authorization to create and maintain authorizations (object S_USER_AUTH). Authorization to protect roles. You can use this authorization object to determine which roles may be processed and which activities (Create, Display, Change and so on) are available for the role(s) (object S_USER_AGR). Authorization for transactions that you may assign to the role and for which you can assign authorization at the start of the transaction in the Profile Generator (object S_USER_TCD ). Authorization to restrict the values which a system administrator can insert or change in a role in the Profile generator ( S_USER_VAL ) CENTRAL USER ADMINISTRATION: SYSTEM SETUP Setting up ALE user for all clients. creating Logical Systems. assigning Logical Systems to Clients. define Target systems for RFC calls. creating Distribution model in the central system. generating Partner profiles in central system. distributing Model views. generating Partner profiles in client system. assigning the Central User Administration distribution Model. user distribution field selection testing Central User Administration. migrating Existing Users to Central System (SCUG) testing Migrated Data in Central System. log display for Central User Administration. Advantage of Central User Administration o Maintain user mater records centrally in one system o Make administrative job easy. o Less possibility of user data inconsistency o Time Saving. MASS USER ADMINISTRATION(SU10): SU10 transaction is used to perform mass user administration activities like creation, modification, Lock/Unlock and assigning roles. Disadvantage of SU10 is we can not maintain individual address data for each user and also cannot assign different to values to different users. Mass user locking: CREATION OF CUSTOMIZED AUTH.OBJECTS(SU21): When entered Su21 T-Code u will get Click on create button and select authorization object Then provide your customized auth.object class name and text and click on save button.when you click on save then it will ask package name ---->provide name of the package name and save it Under this Auth.object we can maintain our own auth.fields also MAINTAING AUTH.OBJECTS AS CHECK INDICATOR(SU24): SAP SECURITY PROFILE GENERATOR: The objective today is to provide a brief overview of SAP Security and to discuss the best practice of PFCG. In SAP, a User ID is assigned with one or more Security Role based on his/her Job Role. SAP’s documentation calls it Role, but I prefer to use the term Security Role to differentiate it from Job Role. For those who are using pre-profile generator sap system, an ID is assigned with one or more profiles. Is there anyone here who is still on 3.0? I feel your pain in creating a profile. However, I find that those who have experience with the manual method tends to have a better understanding of how SAP Security works. With the advent of Profile Generator, a Security Role may have one or more Profile and each profile may contain up to 150 authorizations. If you create a role that has 450 authorizations, then Profile Generator will create 3 profiles. You might wonder what’s the difference between Authorization Object and Authorization? Auth.Object has one or more fields and is the foundation of all SAP Security program checks. When you add value or combination of values to the field, it becomes an authorization. One Auth.Object can be used to create one or more Auth. For example, S_TCODE has only one field and therefore you can only create one Standard authorization per Security Role. However, with S_USR_GRP it has two fields. Therefore you may create multiple authorizations using different combination to satisfy your business requirement. Let’s say that you are creating a security helpdesk role that has the ability to create, change, & delete only users from the Houston region and display access to all users. The first authorization would contain object S_USR_GRP and the Activity would have 01, 02, 06 and User Group value would be Houston. The second authorization using the same object would have 03 for Activity and * for Class. As a result you now have 2 authorizations Now that we have an understanding of how an ID is linked to a Role and the Role to Profile & Authorization, let’s discuss the mechanic of SAP’s Authority -Check. When a user logs in to SAP, his authorizations are loaded into the User Buffer. When he execute SU01 to maintain user, the program perform an A-C against the authorization in the buffer to see if it contain the object S_TCODE. If yes, it then performs the next check against the field TCD for value ―SU01‖. Then it checks the next authorization for objects S_USR_GRP. Once the program verifies all the necessary auth, it will allow you to perform the task. SAP SECURITY TABLES: Table Description Role Notes AGR_1016 AGR_1016B and Profile Role and Profile Role and AGR_1250 Authorization data Role Object, AGR_1251 Authorization, Field and Value Organizational AGR_1252 elements for authorizations Roles in Composite AGR_AGRS Roles To See All Roles AGR_DEFINE (Role definition) Menu structure AGR_HIER2 AGR_HIERT information – Customer vers Role menu texts Assignment of Menu AGR_OBJ Nodes to Role Profile name for AGR_PROF role Assignment of roles AGR_TCDTXT to Tcodes Assignment of roles AGR_TCODES to Tcodes File Structure for AGR_TEXTS Hierarchical Menu – Cus Time Stamp for AGR_TIME Role: Including profile Assignment of roles AGR_USERS DD02L DD02T DD03L DD04T TDDAT TSTC SAP Transaction Codes Transaction Code, TSTCA TSTCT Object, Field and Value Transaction Code Texts Address Data for USER_ADDR USGRP users User groups Text table for USGRPT USGRP Change history for USH02 logon data Relation USOBT transaction to authorization object (SAP) Relation USOBT_C Transaction to Auth. Object (Customer) Check table for USOBX table USOBT Check Table for USOBX_C Table USOBT_C Temporary table for USOBXFLAGS storing USOBX/T* chang User Master USR01 (runtime data) to users SAP Tables R/3 DD- SAP table texts Table Fields Data element texts Users Data (logon USR02 USR03 data) User address data User master USR04 USR05 USR06 authorization (one row per user) User Master Parameter ID Additional Data per User Authorisation USR10 profiles (i.e. &_SAP_ALL) Text for USR11 authorisation profiles Authorisation USR12 values Short text for USR13 authorisation Table for illegal USR40 passwords User profiles UST04 (multiple rows per user) Composit profiles UST10C (i.e. profile has sub profile) SAP SECURITY AUTHORIZATIONS: The Authorization Concept Introduction on Authorizations Authorization objects enable complex checks of an authorization, which allows a user to carry out an action. An authorization object can group up to 10 authorization fields that are checked in an AND relationship. For an authorization check to be successful, all field values of the authorization object must be maintained accordingly. The fields in an object should not be seen as input fields on a screen. Instead, fields should be regarded as system elements, such as infotypes, which are to be protected. You can define as many system access authorizations as you wish for an object by creating a number of allowed values for the fields in an object. These value sets are called authorizations . The system checks these authorizations in OR relationships. Authorization: Authorization means permission to perform a particular function in the sap system. It is achieved by assigning authorization profiles to users. Authorization Field: 1.It is an element which requires protection. 2.The is the least granular field against which SAP system is protected. 3.These fields are associated with the data elements of the ABAP/4 dictionary 4.This is defined in the transaction SU20. 5.Data Element: It is least granular element which has a valuable name defined by length and type. Activity: 1.It is defined the type of action which can be performed an authorization field. Example: Create, Modify, Delete, Display, Approve, Save, Reverse, Print, etc. 2.Activities are defined in the table. Authorization Object: 1. R/3 uses authorization objects to assign authorizations to users. 2. An authorization object is a template for an authorization. For example, authorization object F_SKA1_BUK - G/L Account: Authorization for company codes requires the specification of two field values: Company Code and Activity. To allow a General Ledger supervisor to create a general ledger master record, he/she must be assigned an authorization to create (Activity 1) accounts for a specific company code (eg. Company Code 2000). Such an authorization is created using the object F_SKA1_BUK by assigning these field values and naming the authorization following an appropriate convention (eg. Z_SCC20001). 3. The Authorization object defines an activity that needs to be protected in the SAP System. 4. An authorization object groups together upto 10 authorization fields that are checked together in an authorization check. 5. Authorization objects are defined in transaction SU21 (Most are in-built) Object Class: 1. 2. Depending on Application Area, Group of relevant authorization objects are grouped into an object class. These are defined in transaction SU22. Authorizations: 1. 2. Authorization is used to define permitted values for the fields of an authorization object. Authorizations are defined in SU20. Authorization Profiles: 1. As a rule authorizations are not directly assigned to a user. Instead these authorizations are clubbed in an authorization profile and are then assigned to the user master records. 2. A group of not more than 150 authorizations is called an authorization profile. 3. Before 4.6c version, profiles created manually in SU02. From 4.6c onwards, profiles are generated using Profile Generator. Composite Profile: 1. A group of authorization profiles (sap_all, sap_new) 2. These are used for administrative purpose, however when it exceeds more than 150 authorizations , another profile will be created and generated. Role: 1. Role is the group of Profiles, menus, transactions, reports and user assignments and personalization. 2. Roles are defined in Transaction code PFCG 3. Roles are called as Activity Groups until 4.6c Types of Roles: 1.Single Role i. Parent Role or Role ii. Derived Role or Child Role 2. Composite Role Figure: Role Types SAP SECURITY CHECK INDICATORS-SU24: •Transaction SU24 maintains the USOBT_C and USOBX_C tables. These tables hold the relationships between the particular transaction and its authorization objects. It is possible to add or subtract the checks performed in the transaction by changing the appropriate flag. •The benefit of transaction SU24 occurs when transactions are added to or deleted from Role Groups using the Profile Generator. •When new transactions are added, the Profile Generator will add all authorization values maintained in SU24 for the transaction(s). •When deleting transaction the Profile Generator will remove all authorization values that are maint ained in SU24 for the transaction. •Activities performed: •Check/Maintain Authorization Values •Addition of Authorization Object to tcode •Deletion of Authorization Object from tcode Check Ind. Proposal Meaning Explanation Check YS Check /Maintained The object will be inserted along with the values in the role. The object will be checked along with the values during runtime of the transaction. Check NO Check This object will not be inserted into the roles. A check on the object along with the values will be done during the runtime of the transaction Do not Check NO Do Not Check The object will not be inserted into the roles and there will not be any check performed during runtime of the transaction Status Texts for authorizations •Standard: All field values in the subordinate levels of the hierarchy are unchanged from the SAP defaults •Maintained: At least one field in the subordinate levels of the hierarchy was empty by default and has sinc e been filled with a value •Changed: The proposed value for at least one field in the subordinate levels of the hierarchy has been changed from the SAP default value. •Manual: You maintained at least one authorization in the subordinate hierarchy levels manually (it was not proposed by the Profile Generator). Effect of SU24 changes in Role Groups •Authorization objects are maintained in SU24 for a particular transaction code. When a transaction code is added to role, only the authorization objects having check as check indicator value and yes as proposal value, maintained for that tcode will be added into the role group. 1) Adding Tcodes to a role When a new Tcode is added to a role •When a new tcode is added to a role, going in either change authorizatio n data or expert mode provides the same result. All the authorizations maintained for the tcode at SU24 level is added to the role. •The program adds new standard authorizations for objects in the roles If the authorization default values contain objects that were previously not existing Or only had authorizations in the status Changed or Manual •A new standard authorization is not included if the authorization fields contain identical authorizations in the status Standard in both authorizations, and the fields maintained in the old authorizations are empty in the new standard authorization. If there were already authorizations in the status Maintained (active or inactive) or Inactive Standard before the merge, the program compares the values and the maintenance status of all authorization fields to determine whether new standard authorizations must be extended. Changing SU24 values for a tcode If the authorization data is changed for any tcode in SU24 and tcode is already present in the role, then going in the expert mode with option ―read old data and compare with new data‖ will only reflect the additional changes. Change authorization data will not pull the new data for the tcode maintained at SU24 level 2) Removing Tcodes from the role When you remove transactions from the role menu, this has the following effect on the authorizations. •A standard authorization for which the associated transa ction was removed from the role menu is removed during the merge, unless at least one other transaction that remains in the menu uses the same authorization default value. This applies both for active and inactive standard authorizations. •Authorizations i n the statuses Changed and Manual are not affected by the merge. They are therefore always retained. COMPOSITE ROLES IN SAP SECURITY: Composite roles: 1. A composite role is a container with several different roles. For reasons of clarity, it does not make sense and is therefore not allowed to add composite roles to composite roles. Composite roles are also called roles. 2. It is used to simplify the administration. 3. Composite roles do not contain authorization data. If you want to change the authorizations (that are represented by a composite role), you must maintain the data for each role of the composite role. 4. It only groups the roles, but menus can be compressed. 5. Creating composite roles makes sense if some of your employees need authorizations from several roles. Instead of adding each user separately to each role required, you can set up a composite role and assign the users to that group. 6. The users assigned to a composite role are automatically assigned to the corresponding (elementary) roles during comparison. 7. Composite roles are identified by customer naming conventions only. 1. These are created in PFCG. 2. These are earlier called as CAGS(Composite Activity Groups). 3. Example for Composite Role. Here the role name, ― BASIS Role” is defined as Composite Role · · · The menu tree of a composite role is, in the simplest case, a combination of the menus of the roles contained. When you create a new composite role, the initial menu tree is empty at first. You can set up the menu tree by choosing Read menu to add the menus of all roles included. This merging may lead to certain menu items being listed more than once. For example, a transaction or path contained in role 1 and role 2 would appear twice. If the set of roles contained in a composite role changes, the menu tree is also affected. In such a case, you can completely rebuild the menu tree or process only the changes. If you choose the latter option, the Profile Generator removes all items from the menu which are not contained in any of the roles referenced. It is possible (and often necessary) to change the menu of a composite role at any time. You adjust these menus in the same way as the menus for roles (see above). CREATING COMPOSITE ROLES IN SAP SECURITY: Composite role: A group of one or more roles for administrative purpose is refereed as composite role. Create a composite role as for the naming conventions Specify the description In composite role it doesn't contain authorizations tab.it is nothing but group of one or more roles.if they need to change in composite role i.e only in menu tab. Specify the roles Assigne this composite role to the existing user. Click on Read menu tab.when you click on this read menu tab then it will fetch authorizations from the single roles. Now log on with that specified user. TYPES OF ROLES IN SAP SECURITY: Role:1.Role is the group of Profiles, menus, transactions, reports and user assignments and personalization. 2.Roles are defined in Transaction code PFCG 3.Roles are called as Activity Groups until 4.6cTypes of Roles: 1. Single Role i. Parent Role or Role ii.Derived Role or Child Role 2. Composite Role 3.CopyRole CREATING DERIVED ROLES IN SAP SECURITY: Derived roles : 1. Derived roles refer to roles that already exist. The derived roles inherit the menu structure and the functions included (transactions, reports, Web links, and so on) from the role referenced or simply you can call as Parent Role. A role can only inherit menus and functions if no transaction codes have been assigned to it before. 2. These are used to define to handle the security at organization levels. 3 These are created for administrative purpose to minimize the maintenance. 4. Derived roles specify the division or unit for which the security can be provided. 5. Derived roles are inherited from parent role/ single role/ generic role differed by there organization levels. 6. Derived roles are also called as child roles. 7. The higher-level role passes on its authorizations to the derived role as default values which can be changed afterwards. Organizational level definitions are not passed on. They must be created a new in the inheriting role. User assignments are not passed on either. 8. Derived roles are an elegant way of maintaining roles that do not differ in their functionality (identical menus and identical transactions) but have different characteristics with regard to the organizational level. 9. The menus passed on cannot be changed in the derived roles. Menu maintenance takes place exclusively in the role that passes on its values. Any changes immediately affect all inheriting roles. 10. You can remove the inheritance relationship, but afterwards the inheriting role is treated like any other normal role. Once a relationship is removed, it cannot be established again. 11. In derived roles, menus are fixed. 12. These are created in PFCG 13. In versions earlier than 4.6 c, derived roles are also called as Derived Activity Groups DAGS. EVALUTION OF AUTHORIZATIONS (SU53) IN SAP SECURITY: TROUBLE SHOOTING USING SU53: Troubleshooting security issues is one of the daily tasks of any security administrator. The first method of investigating authorization failures is the ubiquitous SU53 transaction. It involves us asking the affected user to run the step(s) to replicate the issue and immediately on getting the error, execute /nsu53 through the command window. The screen-shots below show the sequence of actions. The user tries to create another user through SU01 and gets an authorization error The user gets a pop up window with the message that he doesn’t have authorization to create user. Many times clicking the help button can provide important information about the background of the error. To get the SU53 screen, we execute /nsu53 from the command window immediately after getting the error. The SU53 window shows the last check for an authorization which has returned a non zero value (authorization failure) for the user. The biggest limitation of SU53 is the fact that it only shows the last authorization failure of an user. In a typical transaction, there can be an entire sequence of authorization checks, any of which might fail. To view the entire sequence of authorization checks, we use the authorization trace tool (transaction ST01). SOME IMPORTANT TRANSACTION CODES IN SAP: User Administration: SU01- User Maintenance SU01D- User Display SU02- Maintain Authorization Profiles SU03- Maintain Authorizations SU05 -Maintain Internet users SU10 -User Mass Maintenance SMLG- Maintain Logon Group SUPC -Profiles for activity groups SUIM -Info system Authorizations PFCG -Profile Generator PFUD- User Master Data Reconciliation Client Administration: SCC3 -Checking Client Copy Log SCC4 -Client Administration SCC5 -Client Delete SCC7 -Client Import Post-Processing SCC8 -Client Export SCCL -Local Client Copy SCC9 -Remote client copy Database Administration: DB01- Analyze exclusive lock waits DB02 -Analyze tables and indexes DB12 -DB Backup Monitor DB13 -DBA Planning Calendar DB15 -Data Archiving: Database Tables Transport Management System: STMS -Transport Management System SE01 -Transport and Correction System SE06 -Set Up Workbench Organizer SE07 -CTS Status Display SE09 -Workbench Organizer SE10 -Customizing Organizer SE11 -ABAP/4 Dictionary Maintenance SE16 -Data Browser SE80 -Repository Browser SM30 -Call View Maintenance SM31 -Table Maintenance Background Jobs Administration: SM36 -Define Background Job SM37 -Background Job Overview SM39 -Job Analysis SM49 --Execute External OS commands SM62 Maintain Events SM64 -Release of an Event SM65 -Background Processing Analysis Tool SM69 -Maintain External OS Commands Spool Administration: SP01 -Output Controller SP11 -TemSe directory SP12 -TemSe Administration SPAD -Spool Administration Other Administration Tcodes: AL11 -Display SAP Directories BD54 -Maintain Logical Systems OSS1 -Logon to Online Service System SALE IMG -Application Link Enabling SARA -Archive Management SICK -Installation Check SM14 -Update Program Administration SM35 -Batch Input Monitoring SM56 -Number Range Buffer SM58- Asynchronous RFC Error Log SM59 -RFC Destinations (Display/Maintain) SAINT -SAP Add-on Installation Tool SPAM -SAP Patch Manager (SPAM) SPAU -Display modified DE objects SPDD -Display modified DDIC objects ST11 -Display Developer Traces Daily monitoring TCodes: AL08 -Current Active Users SM12 -Display and Delete Locks SM13 -Display Update Records SM21 -System Log SM50 -Work Process Overview SM51 -List of SAP Servers SM66 -System Wide Work Process Overview ST22 -ABAP/4 Runtime Error Analysis ST01 -System Trace ST02 -Setups/Tune Buffers ST03 -Performance, SAP Statistics, Workload ST04 -Select DB activities ST05 -Performance trace ST06 -Operating System Monitor ST10 -Table call statistics SU56 -Analyze User Buffer Other Monitoring Tcodes: OS01 -LAN check with ping RZ01 -Job Scheduling Monitor RZ03 -Presentation, Control SAP Instances ST07 -Application monitor STAT- Local transaction statistics Other Useful Transactions Codes AL22 -Dependent objects display BAOV -Add-On Version Information SA38 -ABAP reporting SE38 -ABAP Editor HIER -Internal Application Component Hierarchy Maintenance ICON -Display Icons WEDI -IDoc and EDI Basis WE02 -IDoc display WE07- IDoc statistics WE20 -Partner profiles WE21 -Port definition WE46 -lDoc administration WE47 -Status Maintenance $TAB -Refreshes the table buffers $SYNC- Refreshes all buffers, except the program buffer