Below the list of SAP R/3 Security Table that could be used for your referrences USR02
Logon data
USR04
User master authorization (one row per user)
UST04
User profiles (multiple rows per user)
USR10
Authorisation pr profiles (i.e. &_ &_SAP_ALL)
UST10C
Comp omposi osit profi ofiles (i.e. pro profile has has sub profi ofile)
USR11
Text for authorisation profiles
USR12
Authorisation values
USR13
Short text for authorisation
USR40
Tabl for illegal passwords
USGRP
User groups
USGRPT
Text table for USGRP
USH02
Change history for logon data
USR01
User Master (runtime data)
USER USER_A _ADD DDR R
Addre Address ss Data Data for for user userss
AGR_1016
Nam Name of of th the ac activit vity gr group pr profile
AGR_ AGR_10 1016 16B B
Name Name of the the act activ ivit ity y gro group up prof profil ilee
AGR_ AGR_12 1250 50
Aut Author horizat zation data data for the act activit vity gro group up
AGR_ AGR_12 1251 51
Aut Author horizat zation data data for the act activit vity gro group up
AGR_ AGR_12 1252 52
Orga Organi niza zattiona ionall elem elemen entts for for auth author oriizat zations ions
AGR_ AGR_A AGRS GRS
Rol Roles in Comp Compos osiite Rol Roles
AGR_ AGR_DE DEFI FINE NE Role Role defi defini niti tion on AGR_ AGR_HI HIER ER2 2
Menu Menu str struct uctur uree info inform rmat atio ion n - Cus Custo tome merr vers vers
AGR_HIERT
Role ole men menu u texts xts
AGR_OBJ
Assignment of of Menu Nodes to Role
AGR_PROF
Profile nam name for role
AGR_TCDTXT AGR_TCDTXT Assignment Assignment of roles to Tcodes Tcodes AGR_TE AGR_TEXTS XTS
File File Str Struct ucture ure for Hierar Hierarchi chical cal Menu Menu - Cus
AGR_ AGR_TI TIME ME
Time Time Stam Stamp p for for Role Role:: Inc Inclu ludi ding ng prof profil ilee
AGR_ AGR_US USER ERS S
Assi Assignm gnment ent of role roless to to use users rs
USOBT
Relation tr transaction to to au authorization ob object (S (SAP)
USOB USOBT_ T_C C
Rel Relatio ation n Tran Transa sact ctio ion n to to Aut Auth. Obj Objec ectt (Cu (Cust stom omer er))
USOBX
Check table for table USOBT
USOBXFLAGS USOBXFLAGS Temporary Temporary table table for storing USOBX/T* USOBX/T* chang chang USOBX_C
Check Ta Table fo for Table US USOBT_C
View and Delete All Single and Composite Role We have done some changes in production role for single as well as composite role. How to delete all the single as well as composite role at one time?
Run transaction SU10 and select multiple role single and composite and delete on single click of button:
Is there any way to view the composite roles that were assigned to a user that was deleted? I am able to go to SUIM and view the single roles but I would like to get the composite roles that were deleted. This is needed so that we can recreate the user and assign the old roles to the user.
If you select the "role change docs" in SUIM and use the selection criteria "overview of change docs" or "all change docs", then deleted composite roles will show up in this report. It would be handy if your composite roles had a different naming convention than the single roles.
Creating Composite Roles Use Composite roles can simplify the user administration. They consist of single roles. Users who are assigned a composite role are automatically assigned the associated single roles during the compare. Composite roles do not themselves contain authorization data. Setting up composite roles are useful for example if some of your staff need authorization for several roles. You can create a composite role and assign it to the users instead of putting each user in each required single role.
Procedure ...
1.
Enter a name in the Role field in the role maintenance (transaction PFCG).
The SAP System does not d istinguish between the names of simple and composite roles. You should adopt your own naming convention to distinguish between simple and composite roles. 2.
Choose Create collective role role..
3.
You can define the composite role in the following screen.
4.
Save your entries.
5. Enter the roles in the composite role in the Roles tab page. You can display all the simple roles in the system with the possible entries help.
You cannot include composite roles in a composite role. 6. You can restructure the role menus which you read in with Read menu , in the Menu tab. Menu tab. For more information, see Creating a Single Role. Role. This does not affect the menus of the roles. Note also the information about menus of composite roles provided if you choose Information ( ) on the Menu tab Menu tab page. 7. Either enter the names of the users individually in the Users tab (manually or from the possible entries help) or choose Selection. (such as all users in Selection. You can define selection criteria (such a user group) If you select a username and choose Display , detailed user information is displayed. Choose Compare users. users. The user data is updated after the comparison. Note that users which are assigned to a composite role are displayed on a gray background in its roles (not changeable). The user assignment should only be changed in the composite role.
You can display an overview of Roles of Roles in composite roles with the View pushbutton View pushbutton in the role maintenance initial screen.
Composite Roles, Single Roles and Workplace Scenarios Composite and Single Roles You should take the following into consideration when you upload (single and composite) roles from an ABAP-based system to the SAP NetWeaver Portal: If a target system is entered in a single role, this means that the role contains transactions and other objects that do not run in the system in which you are currently working. Single roles may only contain objects from a single target system. If no target system is entered in a single role, it exists locally in the system in which you are currently working. When you create composite roles, the single roles are read in the menu of the composite roles. Composite roles may contain single roles whose contents run in different systems.
Note the following issues when uploading roles: You always load single and composite roles from the system containing the menu information for these objects. This can be the system in which they were defined or another system to which they were transported. If a target system that differs from the local system (= the system you are logged onto) is entered for a single role, note that you may not upload this role from the local system. In this case the role contains menu entries that run in another system and the upload from the local system will not work correctly. Instead, the role must be uploaded from the target system. If no target system is entered in a single role, you can assume that it exists locally and does not get its contents from another system. In this case you can upload the role from the local system. You can upload single roles as worksets (and not as roles). You can then regroup and restructure the single roles in the portal by assigning them to a portal role and redefining the navigation structure within this role. If you upload composite roles, you should consider whether or not the single roles they contain should be stored in the portal as separate objects. If you want the single roles to be separate objects, proceed as follows: ...
1. Uplo Upload ad the the sin singl glee rol roles es with the services they contain. 2. Uplo Upload ad the the comp compos osit itee role roless without the services they contain. If you do not want the single roles included in the composite roles to be separate objects in the portal, you should define that you want to upload the single roles with the included services when you upload the composite roles. For more information, see the Workplace scenarios below.
Workplace Scenarios Composite roles are created, maintained, and changed on the Workplace Server. The Workplace Server is a special ABAP-based SAP system that is linked with other back -end systems via RFC definitions. On the Workplace Server, single roles are grouped together as a composite role and arranged so that they represent the LaunchPad (the user’s menu structure). Single roles exist on both the Workplace Server and the backend systems. The contents of a single role only run in the backend system unless they were also created locally on the Workplace Server. This results in the following system landscape:
When you upload roles from Workplace systems, you have the following scenarios: 1.
You upload the single roles with the services they include.
You can upload the single roles from a Workplace system landscape and dispense with the composite roles. The single roles are in the component systems. In some cases there may be local single roles on the Workplace Server.
Always upload single roles from the component systems or from the systems containing the role contents locally. For example, if you upload a single role from the Workplace Server and the Workplace Server is not defined as its target system, the upload does not work correctly. You can also upload single roles as worksets (and not as roles). You can then regroup and restructure the single roles in the portal by assigning them to a portal role and redefining the navigation structure within this role. 1.
You upload the single roles and then the corresponding composite roles.
Single roles are created in the portal as separate objects. You want the menu structure of composite roles in the portal. Do the following:
1. . . . 3. Upload Upload the single single roles from from the Workpl Workplace ace component component systems systems with with the services services they include, as described above. 4. Upload Upload the composi composite te roles roles without without the service servicess they contain. contain. If you do not want to create the single roles as separate objects, proceed as described below. 1.
You upload composite roles with all the services they include.
When you upload composite roles with all included services from the Workplace Server, the corresponding single roles are also uploaded to the portal with all the included services. This means that both the menu structure and the included services are uploaded to the portal and stored in the PCD.
A target system must be entered in each single role on the Workplace Server. The target systems are the component systems containing the contents of the roles. For each target system, a system with a connection to this target system must be set up in the portal. For more information, see Requirements Requirements.. When you upload composite roles with included services, the contained single roles are not created as separate objects (roles or worksets) in the portal. The composite role is only converted to a single portal object: either one either one portal role or one or one workset. If you want your single roles to be separate objects in the portal, you must upload them separately as described above.
SAP SYSTEM SECURITY PARAMETERS A good number of parameters in the RSPARAM table define how security is enforced in the SAP system. These parameters have default values defined for them. If many of these default values are not changed, the integrity of the system can be compromised. Find following a concise description of some important security-oriented parameters. Login/no_automatic_user_sapstar
By default, the SAP system is installed with a super user master record called SAP*. If this master record is deleted, SAP allows a user to logon l ogon with a password of “PASS” for the SAP* user. To disallow this “illegal” entry, set the value to 1. Recommended value is 1. Login/failed_to_user_lock
This parameter defines the maximum number of unsuccessful logon attempts before the user is locked by the system. An entry will therefore be recorded in the system log. Recommended value is 6 Login/failed_user_auto_unlock
This parameter activates or deactivates the automatic unlocking of locked users at midnight. It is advisable that the system/user administrator performs the unlocking of locked users. Recommended value is 0 Login/fails_to_session_end
This parameter defines the number of times a user may enter a wrong password before the login session is terminated. Recommended value is 3 Login/gui_auto_logout
This parameter defines the number of inactive seconds after which a user is automatically logged out of the system. Recommended value is 1800 sec Login/password_expiration_time
This parameter defines the number of days after which a password must be changed. Recommended value is 35 days Login/min_password_lng
This parameter defines the minimum password length. Recommended value is 8 *Login/min_password digit
This parameter defines the minimum number of digits (0-9) in a password.
*Login/min_password_letters
This parameter defines the minimum number of letters or alphabets (A-Z) in a password. *Login/min_password_special
This parameter defines the number of special characters in a password. These special characters include (), !, \, $, %,:,’, “, ;, =, &, #, },],{,[, >, < *Login/min_password_diff
This parameter defines the number of differing characters from previous password. Rec/client
This parameter activates or deactivates automatic table logging. It is recommended to switch it on, however, resource utilization, table(s) to be logged and log volume should be critically analyzed. Auth/rfc_authority_check
This parameter defined how S_RFC object is checked during RFC calls. When set t o a recommended value of 2, check is active and it performed against SRFC-FUGR. A user account must have a password in order to be able to connect to the SAP system. When a user is created in SAP, an initial password is assigned to the user account. The initial password can be explicitly specified or system generated. The user is prompted to change the password on first logon attempt. attempt.
It is important to ensure that both the initial and new passwords must not be trivial. A number of parameters can be used to manage password in SAP. These include: Login/password_expiration_time: Login/password_expiration_ time: This parameter defines the number of days after which a password must be changed. Login/min_password_lng: Login/min_password_lng: This parameter defines the minimum password length. Login/min_password Login/min_password digit: This parameter defines the minimum number of digits (0-9) in a password. Login/min_password_letters: Login/min_password_letters: This parameter defines def ines the minimum number of letters or alphabets (AZ) in a password. Login/min_password_special: Login/min_password_special: This parameter defines the number of special characters in a password. These special characters include (), !, \, $, %,:,’, “, ;, =, &, #, },],{,[, >, <. Login/min_password_diff: Login/min_password_diff: This parameter defines the number of differing characters from previous password. In order to enforce password complexity and ensure that passwords that can be easily guessed are not specified in the system, SAP provides table USR40, which is used to define prohibited passwords. This table houses words that cannot be used as password in the SAP system. ? and * are two wild characters that can be used in conjunction with words defined in the USR40 table. While ? addresses single character, * addresses sequence of any combination of characters of any length. For example, 123* forbids password that begins with 123; *123* forbids any password that contains the sequence 123 and XY? Forbid password that begin with XY and have additional characters such as
XYX, XYY and XYZ. To define prohibited password, use transaction SE16
Different work processes exist in an SAP system. These include dialog, background, spool, enqueue and update work processes. These work processes are of various types, use and differs in the minimum number that can be defined per dispatcher or in an SAP system. As regards operation mode, the dialog and background work processes are of high importance. The dialog work process allows front end interaction with the SAP system while the background work process is used to handle background jobs. Every dispatcher requires at least two dialog work processes. At least one background work process must exist in an SAP system. You can configure more than one background work process per dispatcher. Depending on the workload and the time, the number of both dialog and background work processes can be increased to meet the immediate system need. Usually, at peak periods (may be during the day - DayTime), more users are connected to the SAP system and less background jobs are active, thus, enough dialog work process must be available for optimal transaction processing. In same vein, during off peak period (may be during the night NightTime), less users are connected but more background jobs are active, hence, enough background work process must be available. SAP offers functionality to automatically switch work process distribution especially between dialog work process and background work process. The essence is to optimize system performance. By defining operation mode, work process and system resources are better utilized.
During peak period (as stated above), more dialog work process will be available for dialog users and during off peak periods (as stated above), more background work process is available for background job processing. Using this functionality, work process or system resources are not wasted and performance is optimized. At operation mode change, work process is automatically redistributed without shutting down the instance. Typically, the total number of work process remains the same, only a switch occurs, for example a work process used for dialog processing is switched for background processing. The switching of work process may not be instantaneous as new process type is not activated until a process is free. When work processes are redistributed, the event is recorded in the system log. The following activities need to be performed when configuring operation modes: 1. Create the operation mode using transaction RZ04 2. Assign instance attributes to an operation mode using transaction RZ04 3. Specify the distribution of dialog and background processes for the operation mode using transaction RZ04 4. Assign the operation mode through transaction SM63
The SAP system is a complex system and by implication its administration can be challenging especially in large deployments. In this post, I present a number of best practices and tidbits that are invaluable to SAP system administrators and which goes a long way to simplify SAP system administrative tasks irrespective of the complexity or size of the implementation. 1. Documentation : Proper documentation simplifies administrative tasks. How to achieve a task should be well documented. This should include the various steps to be taken and the correct sequence. There is always a tendency to forget a very important step when performing routine administrative task. Think about overwriting a file without making a backup and you now need to restore back to a point before the overwriting. No matter how minute a task is, it i s important to have it documented. By so doing, it can be picked p icked up by any trained personnel when you are unavailable and the task can be done with little or no hassle. 2. Professional/Peer Professional/Peer Networking: As an SAP administrator, you need to belong to fora where technical SAP issues are discussed. It broadens your technical horizon and expands your skill sets. Through such fora, you can make friends with whom you can discuss challenges on the job with and probably get solutions without necessarily re-inventing the wheels. This is because such individuals might have experienced such issues before. Attending SAP technical summits and conferences such as SAPTECHED is also helpful. SAP Users Group (*SUG) exist in some localization; it is beneficial to belong to such groups. 3. Safeguard the SAP System : The SAP system, been an enterprise system houses the company wide data in most cases, hence the need to properly safeguard the system. Direct access to the database should be highly prohibited and necessary controls must be in place to guide against this. Network security must be very effective. Remote connection to the SAP system must also be well controlled and access granted only when the need arises. Administration of the SAP system must be centralized. Suffice to say that the SAP administration team must be abreast of any work on the SAP system at any point in time. 4. Checklists: Because the administrative tasks that need to be performed on the SAP system are enormous, it is best to have a checklist of these activities. The checklist guides you at ensuring that all defined activities are performed and any observation can be noted and addre ssed in due course. By this, you are unlikely to forget any activity by omission. You can develop checklists for daily,
weekly, monthly, quarterly and annual administrative tasks. 5. Maintenance : The SAP environment is characterized by different application which includes operating system, database system and enterprise system and third party application. These applications are continuously improved and enhanced via upgrades, patches, service packs and hot fixes. It is best for SAP administrator to apply these enhancements when they are released. Furthermore, the SAP system runs on high end e nd infrastructures such as servers and network equipments. These facilities needs to be maintained based on def ined schedule. Performing the preventive maintenance of these equipment as at when due is ke y to ensuring that service is not disrupted as result of equipments break down. 6. Disaster Recovery Plan: The disaster recovery plan is a set of activities that will be carried out to restore service in the event of a disaster of any kind which can mean physical inaccessibility to the server room which is the primary site. A disaster recovery plan must be well documented and all users must be abreast of what to do in case of a disaster. The plan must be tested t ested at defined intervals to ensure that the plan is still relevant to the business case that justifies its existence. 7. Incident Management: When user encounters problems with the system, experience has shown that the system administrators are the first point of call. In an SAP e nvironment, an incident management system should exist to monitor user complaints and problem resolution or status at any point in time. This complaint might be as mild as resetting users pa ssword. With an incident management system in place, service calls can be well managed and progress monitored. 8. SAP System Isolation: Despite the fact that SAP system is an enterprise application that is supposed to integrate all business units of an organization, companies still have one reason or the other to run non SAP systems. In some cases, these non SAP systems are integrated with the SAP system. However, it is best to isolate the SAP system from non SAP system. The SAP application should be installed on a separate server different from other applications. This simplifies administration and makes troubleshooting less difficult. Even the network infrastructure should be isolated if possible. The SAP system can exist i n a separate VLAN different from other systems. 9. Controlled Modification: The SAP administrator should not just make changes to the SAP system without fully understanding the implication of such action. This also applies to making changes to system parameter settings. There should be proper justification for making changes to the system state. 10. Knowledge Database: It is good practice to keep a database of known issues and solutions. Because the challenges of administering the SAP system are multi facet, it is very possible to forget how a problem was resolved when it occurred. A knowledge database exists t o serve as a reference data center when a familiar problem re-occurs. Furthermore, the knowledge database should be centrally managed. It enhances collaboration especially as it relates to issues and corresponding solution documentation.
Important SAP Security Parameters 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). If the value is set to0, 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. p assword. login/disable_multi_gui_login
If this parameter is set to value .1., the system blocks multiple SAP dialog logons (in the same client and with the same user name). When the system detects a multiple logon, a warning message appears, permitting the user either to. End the existing sessions. or .End this logon.. This parameter applies to SAP GUI logons.
Security Parameters Use The parameters described below are used to configure the gateway to ensure secure connections.
Integration Refer also to Security Settings in the SAP Gateway. Gateway.
Prerequisites Your system must be configured for using the SNC interface.
Features gw/sec_info File with the security details (see Assigning Start Authorizations for External Programs). Programs).
Any unauthorized starting of external programs can be prevented by maintaining the file secinfo in the data directory of the gateway instance. /secinfo Default value Dynamic
Yes
gw/tcp_security These parameters can be used to protect external programs against being started. If this parameter has the value ‘1', the information in file gw/sec_info is read. The gateway establishes from the entries in this file whether the user has the authority to start external programs. Default value
1
Dynamic
Yes
(*) but only if changing the parameter affords increased security, thus 0 -> 1 is allowed, 1 -> 0 is not allowed.
gw/reg_info File with the security information for registered programs (see Access Controls for Registered Programs). Programs ). Unauthorized registration of programs can be p revented by maintaining the file reginfo in the data directory of the gateway instance. If the file exists, the system searches for valid registration entries in this list. If there are none, the system searches, as up to now too, in the gw/sec_info file. /reg info Default value Dynamic
Yes
SNC Parameters There are a number of o f additional parameters that control the behavior of the SAP Gateway in conjunction with SNC (Secure Network Communication). Parameter
Meaning
Default value
Dynamic
snc/enable
This parameter specifies whether the gateway accepts connections that protect the data via SNC.
0
No
snc/permit_insecure_comm
This parameter specifies whether the gateway accepts connections without SNC.
0
No
snc/permit_insecure_start
This parameter specifies whether the gateway may establish connections with programs that
0
No
communicate without SNC. snc/permit_common_name
This parameter specifies whether the gateway can use a default SNC name specified by the parameter snc/identity/as, if an SNC name for the connection cannot be read from secinfo.
0
No
snc/gssapi_lib
Path for the shared library of the security system in use.
""
No
snc/identity/as
Identity of the gateway application server
""
No
SAP Security and Authorization Concepts R/3 audit review questions.
Here is a list of items most commonly reviewed by internal/external auditors when reviewing your R/3 system. It is always a good idea to review this list a couple times a year and to take the appropriate steps to tighten your security. Review the following :* System security file parameters (TU02) (e.g. password length/format, forced password sessions, user failures failures to end session etc.) have been set to ensure confidentiality and integrity of password. Security-Parameter-Settings-Documentation
* Setup and modification of user master records follows a specific procedure and is properly approved by management. * Setup and modification of authorizations and an d profiles follows a specific procedure and is performed by someone independent of the person responsible for user master record maintenance. * An appropriate naming convention for profiles, authorizations and authorization objects has been developed to help security maintenance and to comply with required SAP R/3 naming conventions.
* A user master record is created for each user defining a user ID and password. Each user is assigned to a user group, in the user master record, commensurate with their job responsibilities. * Check objects (SU24) have been assigned to key transactions) to restrict access to those transaction. * Authorization objects and authorizations have been assigned to users based on their job responsibilities. * Authorization objects and authorizations have been assigned to users ensuring segregation of duties. * Users can maintain only system tables commensurate with their job responsibilities. * Validity periods are set for user master records assigned to temporary staff. * All in-house developed programs p rograms contain authority check statements to ensure that access to the programs are properly secure. Select a sample of :* Changes to user master records, profiles and authorizations and ensure the changes were properly approved. (The changes can be viewed with transaction (SECR ). ). * Ensure that security administration is properly segregated. At a minimum there should be separate administrators responsible for: - User master maintenance. (This process can be further segregated by user group.) - User profile development and profile activation. (These p rocesses can be further segregated.) * Verify that a naming convention has been developed for profiles, authorizations and in-house developed authorization objects to ensure: - They can be easily managed. - They will not be overwritten by a subsequent release upgrade (for Release 2.2 should begin with Y_ or Z_ and for Release 3.0 by Z_ only.)
* Assess through audit information system (SECR ) or through a review of table USR02, whether user master records have been properly established and in particular: - The SAP_ALL profile is not assigned to any user master records. - The SAP_NEW profile is not signed to any user master records. Verify that procedures exist for assigning new authorization objects from this profile to users following installation of new SAP releases. * Assess and review of the use of the authorization object S_TABU_DIS and review of table authorization classes (TDDAT) whether :- All system tables are assigned an appropriate authorization class. - Users are assigned system table maintenance access (Through S_TABU_DIS) based on authorization classes commensurate with their job responsibilities. * Assess and review of the use of the authorization objects S_Program and S_Editor and the review of program classes (TRDIR) whether: - All programs are assigned the appropriate program class. - Users are assigned program classes commensurate with their job responsibilities. * Ensure through a review of a sample of :- In-house developed programs that the program, p rogram, code either: - Contains an Authority-Check statement referring to an appropriate authorization o bject and valid set of values; or - Contains a program Include statement, where the referred program contains an AuthorityCheck statement referring to an appropriate authorization object and valid set of values. I think an auditor would want to know what methods you are using to approve who gets what profile and what method you are using to document it so that if you review your documentation you could compare it with what wha t authorization the user currently has and determine if the user has more authorizations (roles) than he has been approved for by the approval a pproval system in place.
Frequently Asked Questions on Authorization Role & Profile
What is the difference between role and a profile? Role and profile go hand in hand. Profile is bought in by a role. Role is used as a template, where you can add T-codes, reports..... Profile Profile is one which gives the user authorization. When you create a role, a profile is automatically created. What is the use of role templates? User role templates are predefined avtivity groups in SAP consisting of tyransactions, reports and web addresses. What is the different between single role & composite role? A role is a container that that collects the transaction transaction and generates the associated profile. A composite reole is a container which can collect several different roles What profile versions? Profile versions are nothing but when u modify a profile paarameter through a RZ10 and generate a new profile is created created with a different version and it is stored in the database. Is it possible to change role template? How? Yes, we can change a user role template. template. There are exactly three ways in which we can work with user role templates - we can use it as they are delivered in sap - we can modify them as per our needs through pfcg - we can create them from scratch. For all the above specified we have to use pfcg transaction to maintain them. Personalization Tab Within PFCG
Please expalin the personalization tab within a role. Personalization is a way to save information that could be common to users, I meant to a user role... E.g. you can create SAP queries and manage authorizations by user groups. Now this information can be stored in the the personalization tab of the role. (I supposed that it is a way for SAP to address his ambiguity of its concept of user g roup and roles: is "usergroup" a grouping of people sharing the same access or is it the role who is the grouping of people sharing the same access?)
How to insert missing authorization? Ways? su53 is the best transaction with which we can find the missing authorizations.and we can insert those missing authorization through pfcg. Table of authorisation field settings
Is there a table for authorisations where I ca n quickly see the values entered in a group of fields? In particular I am looking to find the field values for P_ORGIN across a number of authorisation profiles, without having to drill down on each profile and authorisation. AGR_1251 will give you some reasonable info. Table with deleted users
Someone has deleted users in our system, and I am eager to find out who. Is there a table where this is logged? Debug or use RSUSR100 to find the infos. Run transaction SUIM and down its Change documents. How can I make T_Code SPRO Read Only
I have a requirement to make SPRO read only. As you know it has a tree like structure and to make it read only seems like impossible. You cannot make SPRO 100% display only by ANY setting. The SCC4 option only turns configuration tables to not-modifyable but still allows the non-config delivery class tables (or those configured to be changeable) to be modifed. It does nothing for the tcodes that are NOT table maintenance and not n ot controlled by S_TABU_DIS. These will still allow configuration. All the tcodes in the SPRO are in several tables CUST_ACTOBJ (spelling?) is one. You only real option is to create a role with all the tcodes in them that are in the SPRO , remove the create and change to display ( generally by changing the last nunmer on the 4 digit tcodes to 3) and removing all the Create and change access in all the activities and allow only the display. PFCG allows you to create a role from a SPRO project so the usermenu will come close to the SPRO menu, which your changes it will be display. Mass Delete of Old Roles
How can i do a mass delete of the roles without deleing the new roles.
There is a SAP delivered report that you can copy, remove the system type check and run. To do a landscape with delete, enter the roles to be deleted in a transport, run the delete program or manually delete and then relase the transport and import them into all clients and systems. It is called: AGR_DELETE_ALL_ACTIVITY_GROUPS. To used it, you need to tweak/debug & replace the code as it has a check that ensure it is deleting SAP delivered roles only. Once you get past that little bit, it works well.
