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 profiles (i.e. &_SAP_ALL)
UST10C Composit profiles (i.e. profile has sub profile)
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_ADDR Address Data for users
AGR_1016 Name of the activity group profile
AGR_1016B Name of the activity group profile
AGR_1250 Authorization data for the activity group
AGR_1251 Authorization data for the activity group
AGR_1252 Organizational elements for authorizations
AGR_AGRS Roles in Composite Roles
AGR_DEFINE Role definition
AGR_HIER2 Menu structure information - Customer vers
AGR_HIERT Role menu texts
AGR_OBJ Assignment of Menu Nodes to Role
AGR_PROF Profile name for role
AGR_TCDTXT Assignment of roles to Tcodes
AGR_TEXTS File Structure for Hierarchical Menu - Cus
AGR_TIME Time Stamp for Role: Including profile
AGR_USERS Assignment of roles to users
USOBT Relation transaction to authorization object (SAP)
USOBT_C Relation Transaction to Auth. Object (Customer)
 USOBX Check table for table USOBT
USOBXFLAGS Temporary table for storing USOBX/T* chang
USOBX_C Check Table for Table 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 distinguish 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.
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. For
more information, see Creating a Single 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 page.
7. Either enter the names of the users individually in the Users tab (manually or from the
possible entries help) or choose Selection. You can define selection criteria (such as all users in
a user group)
If you select a username and choose Display, detailed user information is displayed.
Choose Compare 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 in composite roles with the 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. Upload the single roles with the services they contain.

2. Upload the composite roles 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 the single roles from the Workplace component systems with the services they
include, as described above.
4. Upload the composite roles without the services they 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.
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 portal role 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 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 to 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.

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: This parameter defines the number of days after which a password
must be changed.

Login/min_password_lng: This parameter defines the minimum password length.

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.

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 is important to
have it documented. By so doing, it can be picked up by any trained personnel when you are
unavailable and the task can be done with little or no hassle.

2. 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 addressed 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 infrastructures such as servers and network
equipments. These facilities needs to be maintained based on defined schedule. Performing the
preventive maintenance of these equipment as at when due is key 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 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 environment, 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 password. 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 in 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 to 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.

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.
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).
Any unauthorized starting of external programs can be prevented by maintaining the file
secinfo in the data directory of the gateway instance.
Default value <Data-Directory>/secinfo

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).
Unauthorized registration of programs can be prevented 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.
Default value <Data directory>/reg info

Dynamic Yes

SNC Parameters
There are a number of additional parameters that control the behavior of the SAP Gateway in
conjunction with SNC (Secure Network Communication).
Parameter Meaning Default Dynamic
value
snc/enable This parameter specifies whether 0 No
the gateway accepts connections
that protect the data via SNC.
snc/permit_insecure_comm This parameter specifies whether 0 No
the gateway accepts connections
without SNC.
snc/permit_insecure_start This parameter specifies whether 0 No
the gateway may establish
connections with programs that
 communicate without SNC.
snc/permit_common_name This parameter specifies whether 0 No
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.
snc/gssapi_lib Path for the shared library of the "" No
security system in use.
snc/identity/as Identity of the gateway application "" No
server

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 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 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 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 processes 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, code either:

- Contains an Authority-Check statement referring to an appropriate authorization object and

valid set of values;

or

- Contains a program Include statement, where the referred program contains an Authority-
Check 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 authorization the user currently has and determine if the user
has more authorizations (roles) than he has been approved for by the approval 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 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 collects the 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 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. 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 personalization tab of the role. (I supposed that it is a way for
SAP to address his ambiguity of its concept of user group 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 can 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 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.