This site is specially for Beginner of SAP Security and
Authorizations. Though a search in google returns any number of
references on security, the number of sites dealing exclusively with SAP
security are few and far between. This is a personal site maintained
solely by me. I intend to update it regularly with more information,
links and other online resources.
Feel free to look around and make use of any of the resources. I would
be glad if any of information presented in the following pages helps you
in learning SAP security.
SNC Tab is only displayed when Secure Network Communications is configured
Alternate Tcodes for the SU01:- OMDL OMEH OMWF OPF0 OTZ1 OY27 OY28 OY29 OY30
SU01 – In the logon tab there are 5 different types of users
Dialog (A):
User type for exactly one interactive user (all logon types including Internet users):
During a dialog log on, the system checks whether the password has expired or is initial. The user can change his or her password himself or herself.
Multiple dialog logons are checked and, where 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.
Due to a lack of interaction, no request for a change of password occurs. (Only the user administrator can change the password.)
Multiple logons are permissible.
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 log on, the system does not check whether the password has expired or is initial. Only the user administrator can change the password (transaction SU01, Goto ® Change Password).
Multiple logons are permissible.
Service users are used, for example, for anonymous system accesses through an ITS service. After an individual authentication, an anonymous session begun with a service user can be continued as a person-related session with a dialog user.
Reference (L):
User type for general, non-person related users that allow the assignment of additional identical authorizations, such as for Internet users created with transactions SU01. You cannot log on to the system with a reference user.
To assign a reference user to a dialog user, specify it when maintaining the dialog user on the Roles tab page. In general, the application controls the assignment of reference users. This assignment is valid for all systems in a Central User Administration (CUA) landscape. If the assigned reference user does not exist in a CUA child system, the assignment is ignored.
You should be very cautious when creating reference users.
If you do not implement the reference user concept, you can deactivate this field in accordance with SAP Note 330067.
We also recommend that you set the value for the Customizing switch REF_USER_CHECK in table PRGN_CUST to “E”. This means that only users of type REFERENCE can then be assigned. Changing the Customizing switch affects only new assignments of reference users. Existing assignments are retained.
We further recommend that you place all reference users in one particularly secure user group to protect them from changes to assigned authorizations and deletion.
Difference between Role and Profile
There are 2 type of profile 1. Generated profile (PFCG) 2. Manually created profile (Which is created from transaction SU02. But problem of Manually Created profile is that need to know the exact authorization object needed and their field level values. This type of profile can be assign to user directly.
Generated profile (PFCG): Its a part of role. Role has two parts 1. Menu 2. Profile. So Generated profile is a part role. This PFCG tool or creation of role is easy way for creating and maintaining the profile. Just need to add the Tcode in the menu part and it automatically pick up authorization abject and their default value forms the table USOBX_C and USOBT_C, so here no need to know the exact Authorization needed for a particular transaction.
But the profile created from PFCG is a part of role and you need assign the role to user not the profile and profile will be automatically assigned to the user.
So the profile associated with particular role and menu will be automatically assign to the user.
But user will get the authorizations from the profile not from the Role. So actual, authorization will be in the profile and role will contain profile+ Menu.
Roles and profiles are literally same. The only difference is using profile we can’t restrict a user up to activity level whereas we can do so using roles.
Powerful profiles
SAP_ALL:- All R/3 privileges
SAP_NEW:- Delivers all changes for authorization objects
S_A.SYSTEM:- Unlimited access to all users, profiles and authorizations (as offered by S_USER_ALL)
S_A.ADMIN:- Authorization for SAP system administration: This includes all authorizations except for: Maintenance of users in user group SUPER Maintenance of profiles and authorizations with names beginning “S_S.”
S_A.CUSTOMIZ:- Authorizations for use in the SAP customizing system
S_A.DEVELOP:- Authorizations for use in the SAP Development environment (excludes any user or profile authorizations
S_A.USER:- Basis system authorizations for end-users (e.g. S_PROGRAM)
S_USER_PRO:– Authorization object, which is checked during authorization maintenance. The check is made in the following profile maintenance transactions SU02 SU01 SU10 FIELDS are:- PROFILE (Authorization profile)and ACTVT (activity)
S_USER_AUT:- Authorization object, which is checked during authorization maintenance. The check is made in the following profile maintenance transactions SU02 SU03. FIELDS are:- OBJECT(authorization object) AUTH(auth. name) and ACTVT
S_USER_AGR:- Authorization object is used to protect the activity groups. Activity groups are used to combine users in groups and to assign them different attributes, in particular transactions and authorization profiles. FIELDS ARE:- ACT_GOUP and ACTVT
S_USER_TCD:- 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
S_USER_VAL:- Authorization to restrict the values which a system administrator can insert or change in a role in the Profile generator
S_USER_SYS:- authorization object for system assignment in the Central User Administration (CUA).You can distribute users from a central system to various child systems of a system group
S_TABU_ANZ:- Display tables in all classes
S_TABU_ALL:- Standard table maintenance all authorizations
S_TABU_CLI:- Maintain client-independent tables
Create/Change access to tables – client independent tables
S_TABU_DIS:- Create/Change access to object – Table Maintenance all tables
S_USER_ALL:- Permits complete authorizations to maintain users
S_TOOL_EX_A:- Access to the performance monitor
S_BTCH_ADM:- Permits administration for managing background jobs
S_BDC_ALL:- All batch input activities
S_BTCH_ALL:- All batch processing authorizations
S_DDIC_ALL:- DDIC: All authorizations
S_SYST_ALL:- All system authorizations
S_ADMI_ALL:- All System administrative functions
S_ABAP_ALL:- All authorizations for ABAPs
S_PROGRAM
S_TRANSPRT
Transaction Codes
PFCG:-Profile Generator Tool for maintenance of roles and profiles.
PFUD: – PFUD tool is used to do mass role user comparison. i.e., if you have just assigned a role to a user, he will not be able to use the new authorizations until the user comparison is done. When the user logins to system all the Authorizations are loaded into user’s buffer. PFUD is used to do user master comparison for a large no of roles.
SUPC: – Mass generation of profiles
SU01:- Maintain User Used for the creation and maintenance of User Master Records including password resetting by System administrators.
SU10:- Mass User Maintenance.
SU02:-Profile Maintenance Tool for the direct maintenance of profiles (not recommended in version 4.0A or above, Should be performed in the profile generator).
SU20:- List of Authorization Fields.
SU21 & SU03:- List of Object Class and authorization objects
SU53:- To display last authority check that failed. To deactivate this function, set the system profile parameter auth/check_value_write_on to 0.
SU56:- Display User Buffer.
SUGR: – Maintain User Groups.
SM04:- Shows the list of the users who are logged on to the instance in which you are currently logged in.
AL08:- shows the list of all the users who are logged on to the system globally or for all the instances in the systems which are active. It shows all the active instances and number of active users in the system
RZ11:- It is used to set profile parameters. Alternatively, you can select and check the parameter setting using report RSPFPAR.
RZ10:– Profile Configuration
ST01:– System Trace
ST11:– Display developers trace and error log files
ST22:– ABAP/4 runtime error analysis
SA38:– Users can run executable programs either in the foreground or as a background job.
SM02:– System Message
SM49:– Execute external OS Commands.
SM69:– Maintain external OS commands.
SE16:– Table display
SM31:– Table view and modifications
SM59:– Display and maintain RFC destinations
SM19:- Security audit – Configuration
SM20:- Security Audit – Report
SM01:– To lock the transaction codes. We can lock one or many at a time.
SM35 and SM35P:– Tcode SM35P use to display/monitor sessions. Using Tcode SM35 to run/process the Sessions in background or foreground.SM50:- List of work process overviewSM51:- List of SAP ServersSM12:- Display and delete locksSM13:- Display update recordsSM21:- System LogSE63:- to change the Title of the SAP Transaction code to a more meaningful one SE93:- Create and Maintain Transaction Codes SECR:- Audit Information SystemSQVI:– To build a custom Report based on multiple tables
EWZ5:– To lock all the users except SAP* and DDIC of a particular client
OBR1:-Business data will be deleted for that particular day, will reset transaction data
SE01:- is the main screen of the Change and transport Organizer. From here the administrator can achieve all tasks related to transport requests – such as create, change, view logs, display client/delivery transports, etc. SE09 and SE10 can also be accessed from here. However, not all developers might be granted access to this transaction.
SE11:– creation of table
SE80:– development tool
SE38:– Creating program
SCC1:- is to Client to client copy and is used to pull the requests with in the same server in different clients SCC3:– Used to access Client copy logSCC4:– To create client.SCC5:– to delete client.SCCL:– Local Client copySTMS: – for transport management system, controls the movement of objects between various SAP systems.SU99:– list of combination of critical transactionsSE84:– List of in-house development tables.SPAD:– Spool administrationSP01:– monitoring spool requestSP02:– monitoring output requestsSP12:- temse administrationRZ04:– creating of operation modes
RZ03:- Monitoring Operation modes
SU56:- User buffer info.
SAP AUTHORIZATION OBJECT TABLES
TOBJ : – TOBJ gives you the details of all the authorization objects in the system. Details include field names, object class, name of the user who created the authorization object etc.
TOBC :- An overview of all object classes is provided in the table TOBC
TOBJT :– TEXT for authorization object is stored.
TACT : – It gives you the details of all the activities that are present in the sap system
TACTZ : – gives you valid activities for each authorization objects
TDDAT : – gives you the details of table name and corresponding authorization group
TSTC : – gives you the list of all SAP Transaction codes
TBRG — Contains all authorization groups and gives information about relation between authorization object and authorization group. The description of the authorization groups is defined in table TBRGT.
USOBX AND UXOBT
Tables USOBT & USOBX are standard tables delivered by SAP.
USOBT defines for each transaction and authorization object, which default values should be used in the profile generator for the transaction(s) entered in a Role Menu.
USOBX defines (a) which authorization checks should occur within a transaction and (b) which authorization checks should be maintained in the profile generator.
In each case the set up and values are SAP’s standard ones which may not be appropriate for how a business wants to run its operations on SAP.
At implementation a copy is made of these tables (via SU25) and these copies are called USOBT_C and USOBX_C.
It is on these copies that subsequent changes are made (via SU24) to bring the operation of transactions/authorizations in line with what the business wants.
TABLES:
T000:- has the SAP clients
T001:- has the companies
USR01:- Contains the runtime data of the user master records
USR02:- Is the table containing logon information such as the password, user type, group, validity etc….
UFLAG status
192 – Locked by admin and locked due to incorrect logon
USR03:- User Address data
USR04:- User master authorizations (Profiles and roles)
USR05:- User master parameter ID.
USR06:- Additional Data per User
USR06SYS:- System-Specific User Classification (License-Related)
USR07:- Object/values of last authorization check that failed
USR08:- Table for user menu entries
USR09:- Entries for user menus (work areas)
USR10:- User master authorization profile.
USR12:- User master authorization values
USR13:- Short Texts for Authorizations
USR14:- Surcharge able Language Versions per User
USR15:- External User Name (Replaced By Table USRACL)
USR16:- Values for Variables for User Authorizations
USR20:- Date of last user master reorganization
USR21:- Assign user name address key
USR21S:- Shadow table: Assignment of user name to address key
USR22:- Logon data without kernel access
USR30:- Additional Information for User Menu
USR41:-User master: Additional data
USR40:- Table for illegal passwords
USGRP: – User groups
USER_ADDR:- Address data for users
UST10S:- It displays all single roles with their authorizations
USORG: – Organizational values are listed in this table
USGRP_USERS:- to get the user list to which group they belong to
DEVACCESS: – Table for development users.. Who has got developers access key?
SUKRI:- List of combination of critical transactions
AGR_DEFINE:- Contains all Roles and also the reference to the parent and child role.
AGR_AGRS:- it tells you how many Single Roles are available in a Composite role
AGR_USERS:- Roles assigned to users.
AGR_1016:- Tells you the combination of Roles and profiles
AGR_1016B:- Tells you the combination of Roles and profiles
AGR_1250:- all the authorizations objects and authorizations are stored.
AGR_1251:- all the authorization object, authorizations, fields and values are stored
AGR_1252:- all the org levels and their values are stored
AGR_TCODES:- relationship between roles and tcodes
AGR_PROF:- it tells you the profile name for role
AGR_TIME:- time stamp for roles
AGR_FLAGS:- Role attributes
AGR_BUFFI:- Internet links for a role
USRSYSACT:- CUA: Roles in Distributed Systems
USRSYSACTT:- CUA: Roles in Distributed Systems
USRSYSLNG:- User’s Language in a System
USRSYSPRF:- CUA: Profiles in Distributed Systems
USRSYSPRFT:- CUA: Profile Text in Distributed Systems
USRSYSUPPL:- CUA: Assignment of User Types to Price Lists
USRSYSUTPA:- CUA: System Measurement: User Types with Attributes
USH02:- Change History for LOGON data.
USH04:- Change history for authorization
USH10:- Change history for authorization profile.
USH12:- Change history for authorization values
IMPORTANT ACTIVITIES IN SAP
01 – Create
02 – Change
03 – Display
05 – Lock/unlock
06 – Delete
22 – Enter, Include and Assign
AUTHORIZATION STATUS
Standard : – The authorization values in the role are the same as those configured in SU24 for the relevant
Transactions
Maintained: – Where an object has been maintained for a transaction in SU24, but the values are not fully
defined, the object appears in the role with one or more empty fields. When these fields are updated
then the object status is “Maintained”
Change : – When the authorization object values are changed from the proposal values configured in SU24,
the object status is “Changed”
Manually : – Authorization objects can be manually added to roles to provide additional authorization over and
above that configured in SU24
REPORTS:
RSCLCCOP: – To transport user master records, profiles and authorizations between clients in an R/3 system.
Start RSCLCCOP from the target client which the users and authorizations should be copied.
Do not use this report if the target client contains some users and authorizations you want to preserve.
RSAUDITC:– To know the locked tcodes
RSUSR008:– List of combination of critical transactions(tcode – SU99 and table SUKRI)
RSUVM005:– All the users with their user names and user types are listed in this report
To lock or unlock a client:- Go to se37 Tcode type in functional module SCCR_LOCK_CLIENT then enter the client name and execute. And to unlock SCCR_UNLOCK_ CLIENT
ST01 TRACE
Go to transaction ST01 and select “Authorization Check” under Trace Components and click on “Trace On.”
Ask the user to execute the transaction.
Once the user either completes the transaction or encounters the error message, go back to St01 and click on “Trace Off”
Then, click on “Analysis”
Replace the User name with the userid of the user who executed the transaction and select the appropriate range of dates and then click on the execute button.
This will show you all the authorization checks that were encountered by the user.
MINIMUM NUMBER OF SESSIONS PER USER IN SAP
By default the value is 6. So a user can open 6 sessions in 4.7x.You set this values in rdisp/max_alt_modes parameter.
You can change this parameter using RZ10 in instance profile and use extended maintenance for changing this.
User gets authorization error for the following below reasons
Conclusion
In our security scenario we deal with su53 dumps on regular basis. Here we have discussed the various issues related to dumps that are faced in projects and how to deal with these issues. It is a common practice for SAP security practitioners to deal with su53 only without proper judging the problem. Many times the su53 dump gives a wrong output. The detailed reasons for improper su53 are discussed above. This document will help security Practitioners to identify correct su53 dump and work on the same.
Authorization Objects/Transaction SU24
Profile Generator uses the information in transaction SU24 to determine what authorization objects are needed for a transaction code. SU24 is made up of multiple tables that are brought together by the program SAPMS921. Sometimes this information is incorrect and will result in authorization objects incorrectly added or omitted from an activity group. This is why positive and negative testing is a must before the system is implemented. SAP allows alteration of the information in SU24, thereby changing the authorization objects that Profile Generator uses for specific transaction codes. This is useful because you can prevent Profile Generator from bringing in certain authorizations that are more powerful and should be used more sparingly than how they are delivered in SU24. The following are a list of these authorizations that should be deactivated from the SU24 and only added after testing has occurred and the reasons for its use is documented.
S_TABU_DIS – This authorization allows table maintenance that typically should only be allowed in the development systems and transported forward into production. This prevents the systems from becoming out of sync. This authorization should only be
assigned in production in very rare instances. It is acceptable to assign the display version of this authorization in production. SAP assigns tables to authorization groups and these authorization groups are used by S_TABU_DIS to assign tables for security access. The problem is that SAP may assign as many as 1500 tables to an authorization group. There are rare instances where table changes are appropriate in production. When this occurs a custom authorization should be created with only the tables appropriate for
the production change.
S_TABU_CLI – This allows cross client table maintenance. Most tables in SAP need to be transported to other clients and systems in order for the change to take affect. However there are a few tables that will automatically update other clients. These tables are called client dependent In these instances this authorization is needed and should be handed out sparingly.
S_DEVELOP – This authorization allows users with developer keys to make changes to and develop new program code, transaction codes, and authorizations. This authorization should only be given in development. These types of changes should be transported into production in order to keep the systems in sync.
S_PROGRAM – This is used to restrict use of programs. SAP delivers many programs that can be accessed through transaction SA38. These programs often have the authorization S_PROGRAM attached to them or the developers often use the authorization in custom-built programs. They will assign authorization groups that are used by this authorization object. If a user does not have the appropriate authorization group they will not have access to this program. As of version 4.6 programs can be assigned transaction codes that alleviate the need to assign the transaction SA38 to users. This transaction is dangerous because if a sensitive program does not have security assigned to it the user will be able to run it with the SA38 access. If a user does not have SA38 then they will need to have the transaction code assigned to the program. It is important for security to ensure that the developers have implemented a procedure for assigning security to newly developed programs.
S_ADMI_FCD – This authorization object in combination with the S_TCODE authorization can allow sensitive system altering access. There are several system functions that can be performed through this authorization object. For example, you can
give a user transaction code SM04 through authorization object S_TCODE that allows a user to view all users currently active on SAP. However if you give the user the additional authorization S_ADMI_FCD along with the system function PADM they will
be able to terminate another user’s session.
S_BTCH_ADM – If this authorization is given independent of S_BTCH_JOB and S_BTCH_NAM the user will be able to create, change, copy, delete, and start all background jobs. This authorization should only be given to a basis role.
S_BTCH_NAM – Allows restrictions for creating and viewing batch jobs. You can restrict to a user’s own jobs and/or other users’ jobs. Users should not have access to all batch jobs because sensitive data could reside in these jobs or significant changes could be made to the system if a user runs a job they are unfamiliar with.
S_BDC_MONI – This allows restrictions based on the job name. For example you may only want a user to create, change, or delete jobs beginning with certain letters. This is used very affectively if a good naming convention is in place for job names.
S_USER * – All authorizations beginning with S_USER should only be given to security professionals. All these authorizations control the Profile Generator and user master functions. Sometimes you will still want to change an authorization brought in by Profile Generator, but you do not want to change the SU24. For example, a transaction code can be changed from allowing change to display only by changing the authorization object from change to display activity. You may only want display in certain roles but change in others. The SU24 is based on a transaction and does not change based on the intent. This change must be made at the activity group level. In order to prevent the change authorization from reappearing if you make changes to the display activity group, the change authorization brought in by Profile Generator must be inactivated and then manually add the display authorization. This will ensure the integrity of your display roles.
TABS in SU01
Address, Logon Data, Defaults, Parameters, Roles, Profiles, Groups, personalization, Licence dataSNC Tab is only displayed when Secure Network Communications is configured
Alternate Tcodes for the SU01:- OMDL OMEH OMWF OPF0 OTZ1 OY27 OY28 OY29 OY30
SU01 – In the logon tab there are 5 different types of users
- Dialog
2. System
3. Communication
4. Service
5. Reference
Dialog (A):
User type for exactly one interactive user (all logon types including Internet users):
During a dialog log on, the system checks whether the password has expired or is initial. The user can change his or her password himself or herself.
Multiple dialog logons are checked and, where 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.
Due to a lack of interaction, no request for a change of password occurs. (Only the user administrator can change the password.)
Multiple logons are permissible.
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 log on, the system does not check whether the password has expired or is initial. Only the user administrator can change the password (transaction SU01, Goto ® Change Password).
Multiple logons are permissible.
Service users are used, for example, for anonymous system accesses through an ITS service. After an individual authentication, an anonymous session begun with a service user can be continued as a person-related session with a dialog user.
Reference (L):
User type for general, non-person related users that allow the assignment of additional identical authorizations, such as for Internet users created with transactions SU01. You cannot log on to the system with a reference user.
To assign a reference user to a dialog user, specify it when maintaining the dialog user on the Roles tab page. In general, the application controls the assignment of reference users. This assignment is valid for all systems in a Central User Administration (CUA) landscape. If the assigned reference user does not exist in a CUA child system, the assignment is ignored.
You should be very cautious when creating reference users.
If you do not implement the reference user concept, you can deactivate this field in accordance with SAP Note 330067.
We also recommend that you set the value for the Customizing switch REF_USER_CHECK in table PRGN_CUST to “E”. This means that only users of type REFERENCE can then be assigned. Changing the Customizing switch affects only new assignments of reference users. Existing assignments are retained.
We further recommend that you place all reference users in one particularly secure user group to protect them from changes to assigned authorizations and deletion.
Difference between Role and Profile
There are 2 type of profile 1. Generated profile (PFCG) 2. Manually created profile (Which is created from transaction SU02. But problem of Manually Created profile is that need to know the exact authorization object needed and their field level values. This type of profile can be assign to user directly.
Generated profile (PFCG): Its a part of role. Role has two parts 1. Menu 2. Profile. So Generated profile is a part role. This PFCG tool or creation of role is easy way for creating and maintaining the profile. Just need to add the Tcode in the menu part and it automatically pick up authorization abject and their default value forms the table USOBX_C and USOBT_C, so here no need to know the exact Authorization needed for a particular transaction.
But the profile created from PFCG is a part of role and you need assign the role to user not the profile and profile will be automatically assigned to the user.
So the profile associated with particular role and menu will be automatically assign to the user.
But user will get the authorizations from the profile not from the Role. So actual, authorization will be in the profile and role will contain profile+ Menu.
Roles and profiles are literally same. The only difference is using profile we can’t restrict a user up to activity level whereas we can do so using roles.
Powerful profiles
SAP_ALL:- All R/3 privileges
SAP_NEW:- Delivers all changes for authorization objects
S_A.SYSTEM:- Unlimited access to all users, profiles and authorizations (as offered by S_USER_ALL)
S_A.ADMIN:- Authorization for SAP system administration: This includes all authorizations except for: Maintenance of users in user group SUPER Maintenance of profiles and authorizations with names beginning “S_S.”
S_A.CUSTOMIZ:- Authorizations for use in the SAP customizing system
S_A.DEVELOP:- Authorizations for use in the SAP Development environment (excludes any user or profile authorizations
S_A.USER:- Basis system authorizations for end-users (e.g. S_PROGRAM)
Authorization objects
S_USER_GRP:- Authorization object which is checked during user maintenance. The check is made in the following user maintenance transactions SU01, SU10. The object is defined with the following two fields: CLASS ( User Group) and ACTVT(activity)S_USER_PRO:– Authorization object, which is checked during authorization maintenance. The check is made in the following profile maintenance transactions SU02 SU01 SU10 FIELDS are:- PROFILE (Authorization profile)and ACTVT (activity)
S_USER_AUT:- Authorization object, which is checked during authorization maintenance. The check is made in the following profile maintenance transactions SU02 SU03. FIELDS are:- OBJECT(authorization object) AUTH(auth. name) and ACTVT
S_USER_AGR:- Authorization object is used to protect the activity groups. Activity groups are used to combine users in groups and to assign them different attributes, in particular transactions and authorization profiles. FIELDS ARE:- ACT_GOUP and ACTVT
S_USER_TCD:- 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
S_USER_VAL:- Authorization to restrict the values which a system administrator can insert or change in a role in the Profile generator
S_USER_SYS:- authorization object for system assignment in the Central User Administration (CUA).You can distribute users from a central system to various child systems of a system group
S_TABU_ANZ:- Display tables in all classes
S_TABU_ALL:- Standard table maintenance all authorizations
S_TABU_CLI:- Maintain client-independent tables
Create/Change access to tables – client independent tables
S_TABU_DIS:- Create/Change access to object – Table Maintenance all tables
S_USER_ALL:- Permits complete authorizations to maintain users
S_TOOL_EX_A:- Access to the performance monitor
S_BTCH_ADM:- Permits administration for managing background jobs
S_BDC_ALL:- All batch input activities
S_BTCH_ALL:- All batch processing authorizations
S_DDIC_ALL:- DDIC: All authorizations
S_SYST_ALL:- All system authorizations
S_ADMI_ALL:- All System administrative functions
S_ABAP_ALL:- All authorizations for ABAPs
S_PROGRAM
- ABAP/4: Program Run Checks
- Values for field P_GROUP
- Values for field P_ACTION
- SUBMIT – start programs
- EDIT – maintain program attributes, copy programs, delete programs
- VARIANT – Maintain program attributes and texts
- BTCSUBMIT – Submit program for background execution
S_TRANSPRT
- Part of the object class ‘Basis: Development Environment’
- Correction and Transport System and Request Management
- Permits access to ABAP/4 development workbench, customizing system, and Correction and Transport System
- Part of the object class ‘Basis: Development Environment’
- Permits access to ABAP/4 development tools and dictionary/data modeler, screen and menu painters, and object browser.
Transaction Codes
PFCG:-Profile Generator Tool for maintenance of roles and profiles.
PFUD: – PFUD tool is used to do mass role user comparison. i.e., if you have just assigned a role to a user, he will not be able to use the new authorizations until the user comparison is done. When the user logins to system all the Authorizations are loaded into user’s buffer. PFUD is used to do user master comparison for a large no of roles.
SUPC: – Mass generation of profiles
SU01:- Maintain User Used for the creation and maintenance of User Master Records including password resetting by System administrators.
SU10:- Mass User Maintenance.
SU02:-Profile Maintenance Tool for the direct maintenance of profiles (not recommended in version 4.0A or above, Should be performed in the profile generator).
SU20:- List of Authorization Fields.
SU21 & SU03:- List of Object Class and authorization objects
SU53:- To display last authority check that failed. To deactivate this function, set the system profile parameter auth/check_value_write_on to 0.
SU56:- Display User Buffer.
SUGR: – Maintain User Groups.
SM04:- Shows the list of the users who are logged on to the instance in which you are currently logged in.
AL08:- shows the list of all the users who are logged on to the system globally or for all the instances in the systems which are active. It shows all the active instances and number of active users in the system
RZ11:- It is used to set profile parameters. Alternatively, you can select and check the parameter setting using report RSPFPAR.
RZ10:– Profile Configuration
ST01:– System Trace
ST11:– Display developers trace and error log files
ST22:– ABAP/4 runtime error analysis
SA38:– Users can run executable programs either in the foreground or as a background job.
SM02:– System Message
SM49:– Execute external OS Commands.
SM69:– Maintain external OS commands.
SE16:– Table display
SM31:– Table view and modifications
SM59:– Display and maintain RFC destinations
SM19:- Security audit – Configuration
SM20:- Security Audit – Report
SM01:– To lock the transaction codes. We can lock one or many at a time.
SM35 and SM35P:– Tcode SM35P use to display/monitor sessions. Using Tcode SM35 to run/process the Sessions in background or foreground.SM50:- List of work process overviewSM51:- List of SAP ServersSM12:- Display and delete locksSM13:- Display update recordsSM21:- System LogSE63:- to change the Title of the SAP Transaction code to a more meaningful one SE93:- Create and Maintain Transaction Codes SECR:- Audit Information SystemSQVI:– To build a custom Report based on multiple tables
EWZ5:– To lock all the users except SAP* and DDIC of a particular client
OBR1:-Business data will be deleted for that particular day, will reset transaction data
SE01:- is the main screen of the Change and transport Organizer. From here the administrator can achieve all tasks related to transport requests – such as create, change, view logs, display client/delivery transports, etc. SE09 and SE10 can also be accessed from here. However, not all developers might be granted access to this transaction.
SE11:– creation of table
SE80:– development tool
SE38:– Creating program
SCC1:- is to Client to client copy and is used to pull the requests with in the same server in different clients SCC3:– Used to access Client copy logSCC4:– To create client.SCC5:– to delete client.SCCL:– Local Client copySTMS: – for transport management system, controls the movement of objects between various SAP systems.SU99:– list of combination of critical transactionsSE84:– List of in-house development tables.SPAD:– Spool administrationSP01:– monitoring spool requestSP02:– monitoring output requestsSP12:- temse administrationRZ04:– creating of operation modes
RZ03:- Monitoring Operation modes
SU56:- User buffer info.
SAP AUTHORIZATION OBJECT TABLES
TOBJ : – TOBJ gives you the details of all the authorization objects in the system. Details include field names, object class, name of the user who created the authorization object etc.
TOBC :- An overview of all object classes is provided in the table TOBC
TOBJT :– TEXT for authorization object is stored.
TACT : – It gives you the details of all the activities that are present in the sap system
TACTZ : – gives you valid activities for each authorization objects
TDDAT : – gives you the details of table name and corresponding authorization group
TSTC : – gives you the list of all SAP Transaction codes
TBRG — Contains all authorization groups and gives information about relation between authorization object and authorization group. The description of the authorization groups is defined in table TBRGT.
USOBX AND UXOBT
Tables USOBT & USOBX are standard tables delivered by SAP.
USOBT defines for each transaction and authorization object, which default values should be used in the profile generator for the transaction(s) entered in a Role Menu.
USOBX defines (a) which authorization checks should occur within a transaction and (b) which authorization checks should be maintained in the profile generator.
In each case the set up and values are SAP’s standard ones which may not be appropriate for how a business wants to run its operations on SAP.
At implementation a copy is made of these tables (via SU25) and these copies are called USOBT_C and USOBX_C.
It is on these copies that subsequent changes are made (via SU24) to bring the operation of transactions/authorizations in line with what the business wants.
TABLES:
T000:- has the SAP clients
T001:- has the companies
USR01:- Contains the runtime data of the user master records
USR02:- Is the table containing logon information such as the password, user type, group, validity etc….
UFLAG status
- – Not locked
- – Locked by admin
192 – Locked by admin and locked due to incorrect logon
USR03:- User Address data
USR04:- User master authorizations (Profiles and roles)
USR05:- User master parameter ID.
USR06:- Additional Data per User
USR06SYS:- System-Specific User Classification (License-Related)
USR07:- Object/values of last authorization check that failed
USR08:- Table for user menu entries
USR09:- Entries for user menus (work areas)
USR10:- User master authorization profile.
USR12:- User master authorization values
USR13:- Short Texts for Authorizations
USR14:- Surcharge able Language Versions per User
USR15:- External User Name (Replaced By Table USRACL)
USR16:- Values for Variables for User Authorizations
USR20:- Date of last user master reorganization
USR21:- Assign user name address key
USR21S:- Shadow table: Assignment of user name to address key
USR22:- Logon data without kernel access
USR30:- Additional Information for User Menu
USR41:-User master: Additional data
USR40:- Table for illegal passwords
USGRP: – User groups
USER_ADDR:- Address data for users
UST10S:- It displays all single roles with their authorizations
USORG: – Organizational values are listed in this table
USGRP_USERS:- to get the user list to which group they belong to
DEVACCESS: – Table for development users.. Who has got developers access key?
SUKRI:- List of combination of critical transactions
AGR_DEFINE:- Contains all Roles and also the reference to the parent and child role.
AGR_AGRS:- it tells you how many Single Roles are available in a Composite role
AGR_USERS:- Roles assigned to users.
AGR_1016:- Tells you the combination of Roles and profiles
AGR_1016B:- Tells you the combination of Roles and profiles
AGR_1250:- all the authorizations objects and authorizations are stored.
AGR_1251:- all the authorization object, authorizations, fields and values are stored
AGR_1252:- all the org levels and their values are stored
AGR_TCODES:- relationship between roles and tcodes
AGR_PROF:- it tells you the profile name for role
AGR_TIME:- time stamp for roles
AGR_FLAGS:- Role attributes
AGR_BUFFI:- Internet links for a role
USRSYSACT:- CUA: Roles in Distributed Systems
USRSYSACTT:- CUA: Roles in Distributed Systems
USRSYSLNG:- User’s Language in a System
USRSYSPRF:- CUA: Profiles in Distributed Systems
USRSYSPRFT:- CUA: Profile Text in Distributed Systems
USRSYSUPPL:- CUA: Assignment of User Types to Price Lists
USRSYSUTPA:- CUA: System Measurement: User Types with Attributes
USH02:- Change History for LOGON data.
USH04:- Change history for authorization
USH10:- Change history for authorization profile.
USH12:- Change history for authorization values
IMPORTANT ACTIVITIES IN SAP
01 – Create
02 – Change
03 – Display
05 – Lock/unlock
06 – Delete
22 – Enter, Include and Assign
AUTHORIZATION STATUS
Standard : – The authorization values in the role are the same as those configured in SU24 for the relevant
Transactions
Maintained: – Where an object has been maintained for a transaction in SU24, but the values are not fully
defined, the object appears in the role with one or more empty fields. When these fields are updated
then the object status is “Maintained”
Change : – When the authorization object values are changed from the proposal values configured in SU24,
the object status is “Changed”
Manually : – Authorization objects can be manually added to roles to provide additional authorization over and
above that configured in SU24
REPORTS:
RSCLCCOP: – To transport user master records, profiles and authorizations between clients in an R/3 system.
Start RSCLCCOP from the target client which the users and authorizations should be copied.
Do not use this report if the target client contains some users and authorizations you want to preserve.
RSAUDITC:– To know the locked tcodes
RSUSR008:– List of combination of critical transactions(tcode – SU99 and table SUKRI)
RSUVM005:– All the users with their user names and user types are listed in this report
To lock or unlock a client:- Go to se37 Tcode type in functional module SCCR_LOCK_CLIENT then enter the client name and execute. And to unlock SCCR_UNLOCK_ CLIENT
ST01 TRACE
Go to transaction ST01 and select “Authorization Check” under Trace Components and click on “Trace On.”
Ask the user to execute the transaction.
Once the user either completes the transaction or encounters the error message, go back to St01 and click on “Trace Off”
Then, click on “Analysis”
Replace the User name with the userid of the user who executed the transaction and select the appropriate range of dates and then click on the execute button.
This will show you all the authorization checks that were encountered by the user.
MINIMUM NUMBER OF SESSIONS PER USER IN SAP
By default the value is 6. So a user can open 6 sessions in 4.7x.You set this values in rdisp/max_alt_modes parameter.
You can change this parameter using RZ10 in instance profile and use extended maintenance for changing this.
User gets authorization error for the following below reasons
- User is not authorized to run the transaction. If user is not authorized to run a certain transaction then we get some error message. SU53 will show the transaction which user requires for authorization.
- User is authorized to run a transaction but is getting error when trying to proceed further. It is a problem related to the values of authorization object. The su53 in such cases will be different from the one we discussed above. Here one need to judge whether the authorization object is related to the transaction that is being run and also the input values are correct or not. Even Parameter values in certain cases are misleading.
Conclusion
In our security scenario we deal with su53 dumps on regular basis. Here we have discussed the various issues related to dumps that are faced in projects and how to deal with these issues. It is a common practice for SAP security practitioners to deal with su53 only without proper judging the problem. Many times the su53 dump gives a wrong output. The detailed reasons for improper su53 are discussed above. This document will help security Practitioners to identify correct su53 dump and work on the same.
Authorization Objects/Transaction SU24
Profile Generator uses the information in transaction SU24 to determine what authorization objects are needed for a transaction code. SU24 is made up of multiple tables that are brought together by the program SAPMS921. Sometimes this information is incorrect and will result in authorization objects incorrectly added or omitted from an activity group. This is why positive and negative testing is a must before the system is implemented. SAP allows alteration of the information in SU24, thereby changing the authorization objects that Profile Generator uses for specific transaction codes. This is useful because you can prevent Profile Generator from bringing in certain authorizations that are more powerful and should be used more sparingly than how they are delivered in SU24. The following are a list of these authorizations that should be deactivated from the SU24 and only added after testing has occurred and the reasons for its use is documented.
S_TABU_DIS – This authorization allows table maintenance that typically should only be allowed in the development systems and transported forward into production. This prevents the systems from becoming out of sync. This authorization should only be
assigned in production in very rare instances. It is acceptable to assign the display version of this authorization in production. SAP assigns tables to authorization groups and these authorization groups are used by S_TABU_DIS to assign tables for security access. The problem is that SAP may assign as many as 1500 tables to an authorization group. There are rare instances where table changes are appropriate in production. When this occurs a custom authorization should be created with only the tables appropriate for
the production change.
S_TABU_CLI – This allows cross client table maintenance. Most tables in SAP need to be transported to other clients and systems in order for the change to take affect. However there are a few tables that will automatically update other clients. These tables are called client dependent In these instances this authorization is needed and should be handed out sparingly.
S_DEVELOP – This authorization allows users with developer keys to make changes to and develop new program code, transaction codes, and authorizations. This authorization should only be given in development. These types of changes should be transported into production in order to keep the systems in sync.
S_PROGRAM – This is used to restrict use of programs. SAP delivers many programs that can be accessed through transaction SA38. These programs often have the authorization S_PROGRAM attached to them or the developers often use the authorization in custom-built programs. They will assign authorization groups that are used by this authorization object. If a user does not have the appropriate authorization group they will not have access to this program. As of version 4.6 programs can be assigned transaction codes that alleviate the need to assign the transaction SA38 to users. This transaction is dangerous because if a sensitive program does not have security assigned to it the user will be able to run it with the SA38 access. If a user does not have SA38 then they will need to have the transaction code assigned to the program. It is important for security to ensure that the developers have implemented a procedure for assigning security to newly developed programs.
S_ADMI_FCD – This authorization object in combination with the S_TCODE authorization can allow sensitive system altering access. There are several system functions that can be performed through this authorization object. For example, you can
give a user transaction code SM04 through authorization object S_TCODE that allows a user to view all users currently active on SAP. However if you give the user the additional authorization S_ADMI_FCD along with the system function PADM they will
be able to terminate another user’s session.
S_BTCH_ADM – If this authorization is given independent of S_BTCH_JOB and S_BTCH_NAM the user will be able to create, change, copy, delete, and start all background jobs. This authorization should only be given to a basis role.
S_BTCH_NAM – Allows restrictions for creating and viewing batch jobs. You can restrict to a user’s own jobs and/or other users’ jobs. Users should not have access to all batch jobs because sensitive data could reside in these jobs or significant changes could be made to the system if a user runs a job they are unfamiliar with.
S_BDC_MONI – This allows restrictions based on the job name. For example you may only want a user to create, change, or delete jobs beginning with certain letters. This is used very affectively if a good naming convention is in place for job names.
S_USER * – All authorizations beginning with S_USER should only be given to security professionals. All these authorizations control the Profile Generator and user master functions. Sometimes you will still want to change an authorization brought in by Profile Generator, but you do not want to change the SU24. For example, a transaction code can be changed from allowing change to display only by changing the authorization object from change to display activity. You may only want display in certain roles but change in others. The SU24 is based on a transaction and does not change based on the intent. This change must be made at the activity group level. In order to prevent the change authorization from reappearing if you make changes to the display activity group, the change authorization brought in by Profile Generator must be inactivated and then manually add the display authorization. This will ensure the integrity of your display roles.
