S_ADMI_FCD

Definition
This authorization object S_ADMI_FCD checks access to several Basis functions, for example,
spool administration and monitoring.
Defined fields

S_ADMI_FCD System administration function

The object defines one authorization field, System administration functions. The possible
values for this field are:

System administration
NADM: Network administration (SM54, SM55, SM58, SM59, SMT1, SMT2, SMQ1,
SMQ2, SMQ3, SMQA, SMQR). Note also authorization object S_RF transaction SICF.
PADM: Process administration (SM50, SM51, SM04, SMICM); intercept background
job (debugging function in background job administration: T checked against the value
PADM when displaying and deleting the trace files)
SM02: Authorization to create, change, and delete system messages
UMON: Monitoring and administration of update records (SM13)
UADM: Update administration (SM14 or SM13 -> administration): As UMON, but also
possible to activate/deactivate update.
UDSP: Display update, as with UADM, but without authorization to repeat or delete
update requests. This authorization is intended for developers who need to analyze update
terminations of "normal" users in production systems, and need to test or debug these
when doing so. For debugging, you also need to assign the debug authorization. In
particular, a user with this authorization can display the update data that is associated
with an update request.
T000: Create new client
TLCK: Lock/unlock transactions
MEMO: Set SAP memory management quota using report RSMEMORY
COLA: Administration of OLE automation servers and controls
F4MX: Activate/deactivate ActiveX search help support throughout the system
TOUC: Execute report TOUCHALL
ICFA: Administration of the Internet Communication Framework activities (transaction
SICF)
ICFR: Administration of the Internet Communication Framework (ICF) recorder
activities (transaction SICFRECORDER)
ICFS: Authorization to create and delete PUBLIC services in the Internet Communication
Framework (ICF and transaction SICF)
RFCA: Administration of Remote Function Calls (RFC and transaction SM59)
QDEL: Execution of the reports RSTRFCQDS or RSTRFCIDS for deleting a queue in
SMQ1 or in SMQ2 in accordance with selection criteria
Spool Administration
Authorization for spool administration is controlled in two groups of authorization values. You
need authorizations from both groups to perform spool administration. These groups are:

Client authorizations
The functions of these values are the same, as the spool administration objects are clientindependent. We recommend you only enter the value SPAD. Without a functional
authorization, the SPAD user cannot execute any spool administration functions.

o
o

SPAD: Authorization for spool administration in all clients

SPAR: Authorization for client-dependent spool administration

Functional authorization
o SPAA: Authorization to define output devices in spool administration
o SPAB: Authorization to define physical or logical Output Management Systems
(OMS) in spool administration
o SPAC: Authorization to maintain device types and associated objects (formatting,
character sets, and so on)
o SPAM: Authorization to administer spool requests in external clients (request
client is not the administrator's client). Authorization values SPAD and SP01 are
also required (see below, Administration of Spool Requests in the Spool Output
Controller).

SAPscript Font Maintenance

FONT: Authorization to maintain SAPscript font data
TemSe Administration
The TemSe database stores spool request data, background processing job logs and other data that
only needs to be kept in the system for a short period of time. These authorizations grant access to
the TemSe administration functions, such as consistency checks and reorganization.

SPTD: Authorization for TemSe administration in all clients

SPTR: Authorization for client-specific TemSe administration

Administration of Spool Requests in the Spool Output Controller

Authorization to administer spool requests is controlled using two groups of authorization objects
or authorization values. The authorizations required depend on whether the administrator needs to
access spool requests from external clients (request client is not the administrator's client).
These authorizations are:

SP01: Authorization for administration of spool requests in the spool output controller
(all users and clients)
SP0R: Authorization for administration of spool requests (all users) in the spool output
controller. Access is limited to spool requests in the current client of the user.

For SP01:

To access spool requests in your own client (apart from your own unprotected requests),
you need an additional authorization for object S_SPO_ACT (Spool: Activity).
To access spool requests in external clients, users with the authorization for SP01 are
automatically authorized to list spool requests and to display their attributes.
Administrators with values SPAD and SPAM (see above), have unlimited authorization
for external client spool requests.

For SP0R:

To access spool requests (apart from your own unprotected requests), you need an
additional authorization for object S_SPO_ACT (Spool: Actions).

Monitoring
ST0M: Authorization to change trace switches
ST0R: Authorization to analyze traces
SM21: Authorization to analyze system logs
liveCache Administration
LC01: liveCache Administration authorization (display functions)
LC02: liveCache Administration authorization (start, stop)
LC03: liveCache Administration authorization (integration, configuration)
LC04: liveCache Administration authorization (initialization)
Other

AUDA: Basis audit administration

AUDD: Basis audit display authorization
BTCH: Test environment, background
DBA: Authorization for database administration
UNIX: Execute UNIX commands from the SAP System using program SAPMSOS0
RSET: Reset/delete data without archiving
SYNC: Reset buffers (buffer synch. with $sync, $tab...)
UBUF: Execution of report RSUSR405 - Reset all user buffers
X25 : Open X.25 connection to SAP System(using report SAPSERVER)
TRNL: Translation administration (Transaction SLW2)
TCTR: Table control settings throughout the system
CONV: Conversion according to release
SCP1: Set character sets, languages, character conversions
SCP2: Database character conversion
SMSS: Microsoft SQL Server Command Window

Example
The following values grant a user full authorization (all operations) for administration of the
spool output controller.

Object S_ADMI_FCD
Field S_ADMI_FCD: SPAD, SPAM, SP01

Additional authorization for [S_SPO_ACT] (Spool: Actions):

Field SPOACTION: *
Field SPOAUTH: *

Additional authorization for object [S_SPO_DEV] (Spool: Device authorization)

Field SPODEVICE: *

S_APPL_LOG
Definition
Authorization object which is checked when application log entries are displayed, changed or
deleted.
Defined fields
The object is defined with the three fields object, sub-object and activity.
Object Name of the application log object

Sub-object Name of the sub-objects of the above application object

Activity: Actions on the object and sub-object
o 03 Display log entries
o 06 Delete log entries
Example
Field
Value
Object

BC*

Sub-object *
Activity
03
With this authorization, the user can display all log entries in the BC (Basis) area.
S_ARCHIVE Archiving authorization
Definition
This authorization object is used in SAP archiving programs to protect the access to archive files
as well as the change mode for the archive management list (transaction SARA, choose
Administration).
For user development of archiving programs:
This authorization object is checked in the following function modules:
ARCHIVE_OPEN_FOR_WRITE (create an archive file)
ARCHIVE_OPEN_FOR_DELETE (start delete program)
ARCHIVE_OPEN_FOR_MOVE (reload in database)
ARCHIVE_OPEN_FOR_READ (read and analyze archive files)
Defined fields
APPLIC Name of application area, e.g. FI, BC, CO, ...
ARCH_OBJ Name of archive object, e.g. FI_DOCUMNT, ...
ACTVT Activities for archive object and application area
o 01 Everything is allowed:
Create archives (ARCHIVE_OPEN_FOR_WRITE)
Start delete program (ARCHIVE_OPEN_FOR_DELETE)
Reload (ARCHIVE_OPEN_FOR_MOVE)
Read and analyze archives (ARCHIVE_OPEN_FOR_READ)
Change mode in archive management
o 02 Change mode in archive management
o 03 Read and analyze archives (ARCHIVE_OPEN_FOR_READ) as well as
display mode in archive management
Example
Field
Value
APPLIC

FI

ARCH_OBJ FI_DOCUMNT
ACTVT
03
This authorization allows the user to read all archives in the FI area for the archive object
FI_DOCUMNT and display the archive management list.
S_BDC_MONI
Definition
Authorization object for batch input management and monitoring (System -> Services -> Batch
Input ).

All actions that you can perform in batch input management are checked using this authorization
object, for example, starting a batch input session or displaying a log.
Defined fields
The object consists of the following fields:
Session name: Names of the sessions that a user is allowed to access.
Normal session name: HUGO
Generic entry: HU*
Batch input, monitoring activities: Operations that a user is allowed to perform.
The field has the following values:
o ABTC: Pass on sessions to background processing.
o ANAL: Analyze sessions and logs.
o AONL: Process sessions in dialog mode.
o DELE: Delete sessions
o FREE: Release sessions
o LOCK: Lock and release sessions
o REOG: Reorganize sessions and logs
Example
With the following authorization, a user can delete sessions whose names begin with
"FITRANS":
Field
Value
Batch Input,

DELE

Monitoring activities
Session name
FITRANS*
S_BTCH_ADM
Definition
S_BTCH_ADM authorizes a super user to manage background processing (menu path Tools ->
Administration -> Jobs -> Job overview).
An administrator with this authorization can:
access background jobs in all clients of an SAP system. In the overview, the system
displays all background jobs throughout the system.
Without this authorization, users can only work on background jobs in the clients in
which they are logged on.
perform all functions on background jobs.
execute external programs in job steps.
Defined fields
Id for background administrator: Enter Y to grant the above authorizations to an administrator.
Value N or missing authorization: The user is not authorized as a background processing
administrator.
S_BTCH_JOB
Definition
With the exception of the release of jobs, users can perform all operations of the background
processing system on their own background jobs without any authorizations. This means that the
user may schedule jobs, display jobs in the job overview and also delete them here. However, the

user may not perform operations on the jobs of other users. Nor may he release his own jobs for
execution.
The object Background processing: Operations on background jobs (S_BTCH_JOB) is used for
granting the following authorizations:
Authorization for the user to release his own jobs.
If a user has this authorization, his background jobs are automatically released for
execution during scheduling.
To release the jobs of other users, you must have authorization for Background
processing: Background administrator (S_BTCH_ADM). (This is the "super user"
authorization for background processing.)
Authorization to perform operations other than release (RELE) on the jobs of other users.
An authorization for this object is restricted to the current client of a user. For administration
authorization in all clients, you require authorization for Background processing: Background
administrator.
The object Background processing: Operations on background jobs is intended for
administrators and system users who are to be allowed limited intervention into background
processing. The RELE authorization is also intended for users who want their jobs to be
automatically released for execution.
The background processing "super user" does not require authorization for Background
processing: Operations on background jobs. A user with authorization for the object
Background processing: Background administrator (S_BTCH_ADM) may perform all
operations on all jobs in all clients.
Defined fields
Background processing: Operations on background jobs consists of the following fields:
Functions: Operations the user is allowed to perform.
Possible values are:
o DELE: Delete background jobs of other users.
o LIST: Display spool requests created by jobs of other users.
Note: To guarantee the security of confidential data in spool requests via spool
output control, you must protect confidential spool requests via the spool
authorization field. A user with the System functions SP01 authorization may
display all spool requests.
o PROT: Display processing logs created by the jobs of other users.
o RELE: Release own jobs automatically during scheduling.
o SHOW: Display definition (start/output specifications, steps) and details of a job
scheduled by another user.
Job group: Names of permitted job groups. Reserved: Set to *.
Example
End-user release authorization: With this authorization, the jobs of a user are automatically
released for execution. The user can see the jobs of other users listed in the job overview, but may
not perform any operations on them.
Field
Value
Operations on a job RELE
Job group
*
Administration authorization for supervision of background processing : With this
authorization, a system administrator may perform background monitoring tasks, such as display
jobs, job logs and job definitions. However, the user may not look at spool requests created by
jobs. (To guarantee security of confidential data in spool requests via spool output control, you

must protect confidential spool requests via the spool authorization field. A user with the System
functions SP01 authorization may display all spool requests.)
Field
Value
Operations on a job DELE, SHOW, PROT
Job group

S_BTCH_NAM
Definition
Determines the authorized users, which users can choose from when scheduling a background
job.
An authorized user provides the authorizations for performing a background job.
A user can always enter himself as an authorized user when scheduling a job. Thus, an
authorization for this object is only required if your users require users other than authorized
users. This might occur, for example, if your users need special authorizations for their
background jobs that only certain users possess.
Defined fields
Authorized user: User name that a user can specify as an authorized user. You can also enter
names generically: <character string>*.
Example
The following authorization allows the user to enter himself or the user name FIBATCH as the
authorized user:
Field
Value
Background user name FIBATCH
for authorization check
S_CALENDAR
Definition
Authorizes users to display or maintain public holiday definitions, and public holiday and factory
calendars.
Defined fields
ACTVT Activity
o 02 Create, Change and Delete
o 03 Display
S_CTS_ADMI
Definition
Authorization object S_CTS_ADMI provides you Administration functions in the Change and
Transport System.
Defined fields
The authorization object only has the field:
CTS_ADMFCT Administration Tasks for Change and Transport System
The values of this field describe the various administration activities that can be checked using
the authorization object.
The following administration functions are currently defined:
TABL: This authorization allows you to

maintain the control tables of the Change and Transport System (for example, set the transport
routes)
schedule the transport utility RDDIMPDP
call certain tools (transaction SE03)
You can access the tools from the initial screens of the Transport Organizer (SE09 and SE01) with
Goto -> Transport Organizer tools.
INIT: This special authorization is required to initialize the Transport Organizer after a system
copy (Transaction SE06).
SYSC: To set the system change option, the authorization with value "SYSC" is required.
PROJ: To create or change projects in the Change and Transport System, you require the
authorization with value "PROJ". This is contained in the individual authorization S_CTS_PRPS.
IMPT: The Transport Management System (Transaction STMS) allows imports to be initiated
from the SAP System into your own system or another SAP System. When importing into nonSAP systems, an RFC connection is set up in these SAP Systems and the import initiated with a
user there. In both cases, the user initiating the import must have the authorization "IMPT" for the
authorization object S_CTS_ADMI.
Comment: Do not use the authorization "IMPT" anymore. Instead, use one of the specific
authorizations IMPA, IMPS, TADD, TDEL, TQAS or TADM.
IMPA: Import all transport requests in the import queue
IMPS: Import individual transport requests into the target system
TADD: Forward transport requests to an import queue (addtobuffer)
TDEL: Delete transport requests from the import queue (delfrombuffer)
TQAS: Activate or delete requests in an import queue
TADM: Execute tp commands
QTEA: Authorization for approving transports into the production system
EPS1: Generate EPS objects
EPS2: Change EPS objects
S_DATASET
Definition
Authorizations for accessing files from ABAP/4 programs.
You use this object to assign authorizations for accessing operating system files (with the
ABAP/4 key word OPEN DATASET, READ DATASET, TRANSFER and
DELETE ). This key word can also be used to assign the authorization for using operating
system commands as a file filter.
In ABAP/4 programs, you perform the authorization check with the function module
AUTHORITY_CHECK_DATASET.
Defined fields
The object consists of the following fields:
ABAP/4 program name: Name of the ABAP/4 program that contains the access. You can
restrict the file access to a few known access programs.
Activity: Possible values:
o 33: Normal file read
o 34: Normal file write or deletion
o A6: Read file with filter (operating system command)
o A7: Write to a file with filter (operating system command)
File name: Name of the operating system file. Here, you can restrict the accessible files.
S_DEVELOP

Definition
S_DEVELOP is a general authorization object for objects in the ABAP Workbench.
Using this object, you can assign access authorizations for all the workbench components.

ABAP Development Tools

ABAP Debugger
ABAP Dictionary and Data Modeler
Screen Painter and Menu Painter
Function Library
Object Navigator and Info System
SAP Smart Forms
Form Builder
Enhancements
Switch Framework

Associated Objects:

Transport Organizer (S_TRANSPRT)

To be able to work with the workbench, a user must have the appropriate authorization.
ABAP: Program Flow Checks ([S_PROGRAM])
To execute programs, a user must also have the appropriate authorization.

Defined fields
The object consists of five fields. The first four are used to identify an object or a function in the
SAP system. The fifth field lists the operations that a user is allowed to execute on objects.
These are the following fields:

DEVCLASS Package for Transport System

Package for which a user has authorization.
Using the input help (F4), you can display and choose packages or find them in table
TDEVC.

OBJTYPE ID of a Development Object

Object types for which a user has authorization.
You can display and choose possible values using the input help (F4).
The object types for the ABAP Workbench can be (with a few exceptions) displayed,
changed, created, and deleted:
o APPLTREE: Application hierarchy (customer application menu hierarchy)
o CLAS: Class (ABAP objects) (only display and change)
o DEBUG: ABAP Debugging
Special activities are checked here.
Activity 03: Display
Activity 02: Changing values of fields and (as of Release 6.10) the function
Debugging->Goto statement
Activity 01: Displaying in System Programs and Kernel Debugging
The other fields of the authoriyation objects are not checked during the check for
debugging authorization and can be set to ' ' (quotation mark, blank, quotation
mark).
Activity 90: Debuggin of sessions of other users (only HTTP and RFC session,

but not dialog or background sessions). The users for whom the authorization is
available are specified in the field "Object Name".

o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o

DEVC: Package (organizational unit for grouping development projects)

DIAL: Dialog modules
FUGR: Management of function modules groups
INTF: Interface (ABAP Objects) (only display and change)
LDBA: Logical databases
MENU: Area menus
MSAG: Message ID (message group)
PARA: Set/Get parameters ("Memory" parameters)
PINF: Package interface (see DEVC)
PROG: Programs and corresponding objects (screens, CUA definitions, program
text elements, attributes, and variants)
SSFO: SAP Smart Forms
SSST: SAP Smart Styles
SUSK: Customer: Assignment transaction --> Authorization objects
SUSO: Authorization objects
SUST: Assignment transaction --> Authorization objects
SYST: Runtime analysis, SQL trace
In the Activity field, no value is required.
TRAN: Transaction
WEBI: Service definitions for Enterprise Services

The object types for Web programming can be created, changed, and displayed.
Internet Transaction Server (ITS)

o
o
o
o
o
o
o
o
o
o
o
o

IAJU: JavaScript file

IAMA: MiniApp (only display and change)
IAML: Language-dependent MIME objects (ITS)
IAMU: MIME objects (ITS)
IARP: Internet service resource file
IASP: Internet service and parameters
IATL: Language-dependent HTML template
IATU: HTML template
Business Server pages (BSP)
SMIM: Object from MIME Repository
WAPA: BSP application
WTAG: BSP extension
WTHM: Theme

The object types for XML programming can be created, changed, and displayed.

XSLT: XSLT program

The object types for the Form Builder<?> can be created, changed, and displayed.

SFPI: Form Object: Interface

10

SFPF: Form Object: Form

The object types for the ABAP Dictionary can be displayed, changed, created, deleted, and
activated. Object types marked with * are database object types that can be created, deleted, or
converted on the database.

o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o

DOMA: Domains
DTEL: Data elements
ENQU: Lock objects
INDX: Secondary indices*
MCID: Matchcode ID*
MCOB: Matchcode objects*
SHLP: Search helps
SQLT: Pool/Cluster tables*
SQTT: Technical settings table pool
STRU: Structures
TABI: Table index*
TABL: Transparent tables*
TABT: Technical setting for tables
TTYP: Table types
TYPE: Type groups
VIEW: Views*

The object types for the Data Modeler can be displayed, changed, created, and deleted.

o
o

UDMO: Data Modeler: Data model

UENO: Data Modeler: Entity type

The object type for the Business Object Repository can be displayed, changed, created, and
deleted.

SOBJ: Business object type

The object types for customer enhancements can be displayed, changed, created, and deleted.

o
o
o
o
o

CMOD: Enhancement project (only change and display)

FUGS: SAP part of the customer exit (transaction CMOD)
FUGX: Customer part of the customer exit (transaction CMOD)
SXCI: Implementation Business Add-In (BAdI)
SXSD: Definition Business Add-In (BAdI)

The object type for CATT test cases can be displayed, changed, created, and deleted.
SCAT: Test case
The object types for enhancements can be displayed, changed, created, and deleted.

o
o

ENHO: Enhancement
ENHS: Enhancement Spot

11

o
o

ENHC: Enhancement Composite

ENSC: Enhancement Spot Composite

The object types for eCATT can be displayed, changed, created, and deleted. Test configurations
can also be executed.

o
o
o
o

ECAT: Testscript
ECSD: System data container
ECTC: Test configuration
ECTD: Test data container

The object types for Switch Framework can be displayed, changed, created, and deleted.

o
o
o

SFBS: Business Set

SFBF: Business Function
SFSW: Switch

OBJNAME Object Name

Names of the programs or objects of another type for which a user has authorization, also
generic.

P_GROUP Authorization group for ABAP programs

Allowed authorization groups for ABAP programs and corresponding objects. If you are
not using your own authorization groups, you should set this field to the value *.

ACTVT Activity
Operations that a user is allowed to execute.
Possible Values:
o 01: Create (valid for all object types)
o 02: Change (valid for all object types)
o 03: Display (valid for all object types)
o 06: Delete (for all object types)
o 07: Activate (only effective for ABAP Dictionary object types)
o 16: Execute (only valid for eCATT test configurations and if you execute reports
out of the development workbench accoring to note 1750997, 1686842,
or 1596907)
o 40: Create object in database (object types TABL, SQLT, VIEW, MCOB, MCID,
and INDX)
o 41: Delete object in database (object types TABL, SQLT, VIEW, MCOB, MCID,
and INDX)
o 42: Convert object in database (object types TABL, SQLT, VIEW, MCOB,
MCID, and INDX)
o 70: Monitor test runs (only im CATT, not im eCATT)
o MA: Switch off the Modification Assistant for each transport object
o L0: SAP internal. Change main package (object type DEVC)
o 94: SAP Internal: Overwrite package check for activating DDIC objects (object
type DEVC)

Examples

12

Developers: Generally, developers should have all S_DEVELOP authorizations, except the one
for the database utility (ID of a development object, value TABT).
The corresponding authorization would be as follows:
Field
Package for transport system
ID of a development object
Node name
Authorization group ABAP program
Activity

Value
*
A bis TABS, TABU bis Z*
*
*
*

With this authorization, the user can access workbench objects without limitation, but is not
allowed to perform any functions on the database utility. In the productive system, only Activity
03 Display is entered.
Authorization for the Database Utility: A user with the following authorization can use the
database utility of the ABAP Dictionary:
Field
Package for transport system
ID of a development object
Node name
Authorization group ABAP program
Activity

Value
*
TABT TABL INDX MACO MCID VIEW SQLT
*
*
*

The user can use the database utility without limitation regarding objects of the executed types.
Only these object types are relevant for the database utility.
Detailed Grouping: You can assign a user different authorizations for object types or object
names by assigning several authorizations to the user.
Example: A user is to be allowed to have unlimited access to programs and ABAP Dictionary
objects, but may only display data models.
You can define these different authorizations in the following manner:
Authorization 1: Programming without limitation
Field
Package for transport system
ID of a development object
Node name
Authorization group ABAP program
Activity

Value
*
A bis U, V bis Z
*
*
*

Authorization 2: Display data models

Field
Package for Transport System
ID of a development object

Value
*
U*

13

Node name
*
Authorization group ABAP program *
Activity
03
Further Notes
In productive systems, only the system manager and the Early Watch users should have
authorization to this object. The Early Watch user should only have authorization with the values
SYST for the field ID of a development object, 03 for the field Activity.
The authorization checks during execution of function modules and methods in test environments
(SE24, SE37, SW01, and so on) and the execution of programs are different. In the test
environments, activity 16 (Execute) is checked. On the other hand, activity 03 "Display"
implicitly contains the authorization for exectuin of programs. For each executable program
whose execution is to be protected explicitly, there must be an appropriate authorization group
assigned. In particular, through this assignment, security-relevant programs can be protected
against display or execution. To assign programs to authorization groups, you can use the report
RSCSAUTH. For more information, refer to the program documentation.
S_LOG_COM
Definition
Authorization object S_LOG_COM allows you to execute external operating system commands.
This authorization is used by users who want to create job steps with External commands in
background processing.
With this authorization, the system checks whether or not the user can execute the external
command in a background job.
Defined fields
The authorization object checks the following fields:

COMMAND Logical command name

Name of the external command in R/3. You can display the external commands defined using
Transaction SM59.

OPSYSTEM Operating System of Application Server

Type of operating system on the target host (see system field SY-OPSYS: values ANYOS, AIX,
UNIX, WINDOWS NT)

HOST Name of Current Application Server

Host name of the target host (see SY-HOST)
S_PROGRAM
Definition
Authorization to execute ABAP programs by program group.
You can assign authorizations by program group for the following activities:
Starting a program
Scheduling a program to run as a background job
Maintaining variants
Defined fields
The object consists of two fields:
Authorization group ABAP program: Name of the program group that the user is
authorized to work with.
Programs that are not assigned to a program group can be started and maintained by any
user. The function does not support generic names.

14

User action ABAP program: Permitted activities.

Possible values:
o SUBMIT: Start the program
o BTCSUBMIT: Schedule the program to run as a background job
o VARIANT: Maintain variants.
(The activity EDIT has been obsolete since Release 3.0. Authorizations for attributes, text
elements and ABAP utility functions are checked using the S_DEVELOP object).
Example
This authorization allows a user to execute programs in the MMDLMAT authorization group.
Field
Value
Authorization group ABAP program MMDLMAT
User action ABAP program
SUBMIT
S_PROJECT
Object Description
Definition
Object S_PROJECT is used to restrict access to projects and activities in project.
This object will be checked in all native project transactions like
SOLAR_PROJECT_ADMIN
SOLAR01
SOLAR02
STWB_2
RMMAIN
also in the Workcenter and all project value helps
Defined fields
PROJECT_ID Project name
This field contains the project IDs which the user should have authorization for.
APPL_COMP Application component to which the project is assigned
This field is not relevant for Customizing projects.
This field is not used in SAP Solution Manager
ACTVT Project activity
Possible values:
02: Change a project. This refers in particular to administrative activities and changes to the
project structure
03: Display a project, status information and appended documents
06: Delete an entire project
23: Maintain - In contrast to activity 02 these changes refer to the objects in a project structure.
The project structure itself cannot be changed. This activity is not checked in customizing and
development projects
71: Analyze a project
76: Create - Edit project documents. You may require additional authorizations depending on the
document repository
78: Assign team members to the nodes in the project structure. This activity is not checked in
customizing projects
A3: Change status, planned data, actual data and resources, and assignment of keywords and
memos. In customizing projects, this activity includes the assignment of team members to nodes

15

PROJ_CONF Confidential activity flag

If this field is 'X', confidential project activities are also displayed.
This field is not relevant for customizing projects.
This field is not used in SAP Solution Manager
Applications
The most important authorization objects for project management are:
S_PROJ_GEN (general project functions, such as cross-system maintenance (SYST))
S_PROJECT (project work)
S_PROJECTS (project administration)
For detailed documentation for individual authorization objects, call the documentation in the
authorization maintenance.
These authorizations are in the following individual roles:
SAP_SOL_PROJ_ADMIN_ALL (full authorization)
SAP_SOL_PROJ_ADMIN_DIS (display authorization)
Note: You must adjust the roles according to your requirements.
Example
The system administrator creates the system landscape for your project. The project manager
maintains all other data for the project in project management. Your system administrator should
not have access to other project data than the system landscape. They should use the value SYST
for S_PROJECT 03 and S_PROJ_GEN.
Further notes
For a complete overview of all the roles available in Solution Manager, see SAP Service
Marketplace -> SAP Components -> SAP Solution Manager -> Solution Manager Security Guide.
S_RFCACL
Definition
Authorization check for RFC users, particularly for trusted systems.
Defined fields
This authorization object contains the following fields:
RFC_SYSID : ID of the calling system
RFC_CLIENT: Client of the calling system or domain of the
satellite system
RFC_USER : ID of the calling user
RFC_EQUSER: Flag, whether the user may be called by a user with the
same ID (Y = yes, N = no).
RFC_TCODE : Calling transaction code
RFC_INFO : Additional information from calling system (curently
inactive)
ACTVT : Activity
This field may currently take the value 16 (execute).
Examples:
If a user User1 in source system S1, client M1 wants to call a function module in the target
system under the same ID User1, the user User1 will need the following authorization in the
target system:
RFC_SYSID : S1
RFC_CLIENT: M1
RFC_USER :

16

RFC_EQUSER: Yes
RFC_TCODE : *
RFC_INFO : *
ACTVT : 16
If a user User1 in source system S1, client M1 wants to call a function module in the target
system as user User2, the user User2 in the target system will need the following authorization:
RFC_SYSID : S1
RFC_CLIENT: M1
RFC_USER : User1
RFC_EQUSER: No
RFC_TCODE : *
RFC_INFO : *
ACTVT : 16
Note: The field RFC_INFO is not currently used.
S_RFC
Definition
Authorization check for RFC access to program modules (for example, function group).
Defined Fields
This authorization object contains the following three fields:
RFC_TYPE: Type of the RFC object you want to protect
This field can take the value 'FUGR' (for function group).
RFC_NAME: Name of the RFC object you want to protect
This field currently contains the name of the function group.
The field may be up to 18 characters long, and the check
only applies to the first 18 characters.
ACTVT: Activity
This field may take the value 16 (execute).
Example:
If you want a user to be able to call function modules in group 'ABCD'
remotely, they will need a user in the target system with the following authorization:
Activity
16
Name of RFC object to be protected ABCD
Type of protected RFC object
FUGR
CALL FUNCTION 'AUTHORITY_CHECK_RFC'
EXPORTING
USERID
= 'USER'
FUNCTIONGROUP = 'ABCD'
EXCEPTIONS
RFC_NO_AUTHORITY = 1.
Authorization Object S_ICF
Definition
This object includes authorization checks for using services in the Internet Communication
Framework (SICF), for calling remote function modules through an RFC destination (SM59), and
for configuring proxy settings (SICF).
In transactions SICF or SM59, specify any authorization value (literal) that is also stored in the
authorization object. Only when both of the values are identical does the user have authorization
to call a destination or an ICF service.
Defined Fields

17

This authorization object contains the following fields and values:

Authorization Object S_ICF: Structure
Field
Meaning
Value
ICF_FIELD
Type of the object that SERVICE
is being protected

DEST

PROXY

ICF_VALUE

Check value for target

object (service,
destination,)

<Any literal>
(For example:
CHECK1)

Meaning
This value protects
server-side calls of
services in the Internet
Communication
Framework.
This value protects
remote calls of
function modules on
the client side.
This values protects
the editing of clientside proxy settings.
The chosen value
must match the value
entered in the
corresponding ICF
services (transaction
SICF), in the proxy
configuration
(transaction SICF), or
in the required
destinations
(transaction SM59).

You use ICF_FIELD to determine the function or functions that you want to protect
with the authorization object. ICF_VALUE contains your chosen check values,
which must match the values entered in the corresponding target object (service,
destination,...).
S_RZL_ADM
Definition
Authorization object for R/3 System administration using the Computing Center Management
System ( Tools -> Administration -> Computing Center -> Management System).
Defined fields
The object consists of the field Activity. This field specifies which operations may be executed.
Possible values:
01: All Management System functions including starting and stopping instances, setting
up and changing operation modes, checking system status, etc.
03: Display authorization. None of the maintenance functions can be executed.
S_SPO_ACT
Definition
Authorization to perform actions on spool requests protected with authorization character strings.
Application in the system: Only checked if the explicit or implicit value in the authorization
attribute field of a spool request is not the same as the user identification of the user accessing it.
The authorization is not checked if a user accesses his or her own unprotected spool requests.

18

Examples: Authorization is checked when a user attempts to access the spool request of another
user. Authorization is not checked if a user attempts to delete his or her own spool request, and
the authorization field in the spool request is either initial or contains the user's identification.
The authorization is, therefore, mainly of interest for users who administrate spool requests in the
output controller. These users must access the spool requests of other users. This requires a
S_SPO_ACT (spooler: actions) authorization, in addition to the spool administration
authorization (S_ADMI_FCD, system functions).
Defined fields
This object consists of the following fields:
Authorization field for spool actions: Operations permitted on protected spool requests.
Possible values:
o BASE: See protected spool request in the output controller (determine whether
the spool request exists); Display request attributes.
o DISP: Display contents of a protected spool request.
o ATTR: Change attributes of protected spool request.
o AUTH: Change authorization value of a protected spool request.
o PRNT: Output protected request for the first time.
o REPR: Output protected spool request more than once.
o REDI: Redirect to another printer (of the same type). The printer should be the
same device type.
If used with ATTR, redirection to a different type of printer is permitted.
o DELE: Delete request manually.
Value for the authorization check: Authorization value, for which the user is authorized.
The authorization value is noted in the attributes of the spool request.
A user is permitted to perform a spool action if the value stored for this action in the user master
matches the value in the authorization field in the spool request. If no value was specified in the
authorization field of the spool request, all actions are permitted.
An authorization key can be entered at the time a spool request is created, for example when a
user selects Print . However the spool system automatically adds the identification of the user
creating the request as an implicit authorization value, if no value is entered explicitly.
The user is permitted to perform the respective action if the value in the user master record for the
action matches the value in the authorization field of the spool request. A user is always
authorized for his or her own user identification and no authorization check takes place in this
case. This means that a user can access his or her own spool requests without restriction if no
authorization key is entered that does not match the user identification.
Examples
With this authorization, a user can reprint all requests with an authorization value beginning with
FI.
Field
Value
Authorization field for REPR
spool actions
Value for

FI*

authorization check
Dependencies
An additional authorization for S_SPO_DEV (spooler: device authorizations) for at least one
printer is required for the physical ouput of a spool request in all cases.

19

S_SPO_DEV
Definition
Defined fields
The object consists of the field Spool: Output device.
In this field, enter the SAP names of the output devices for which a user is to be authorized.
Example
The value "LT*" authorizes a user to use all printers with beginning with "LT" in spool
administration.
S_TABU_DIS
Definition
Authorizations for displaying or maintaining tables. The object only controls access using the
standard table maintenance tool (transaction SM31), enhanced table maintenance (SM30) or the
Data Browser, including access in Customizing.
Defined fields
The object contains the following fields:
Authorization group for DD objects: Authorization for tables by authorization class
according to table TDDAT.
Enter the name of the allowed classes. Table classes are defined in table TDDAT.
Activity: Allowed operations.
Possible values:
o 02: Create, change or delete table entries
o 03: Display table entries only
S_TABU_CLI
Definition
Authorization for maintaining client-independent tables with the standard table maintenance
(SE31), enhanced table maintenance (SM30) and Data Browser, also in the customizing system.
This object is used in client-independent tables as additional security and thus complements the
general table maintenance authorization, S_TABU_DIS.
Background
In the Customizing area, each client normally has their own table environment for maintaining
Customizing parameters. The table layout of Customizing tables allows two different clients to
have and maintain their own data without disturbing the other client. However, this is not the case
for client-independent tables since their content is available to all clients.
For this reason, we recommend giving these tables a special authorization, which is given only to
well trained people responsible for maintenance, as protection from unintended side effects in a
multi-client system. There are very few client-independent tables in the Customizing area.
Nonetheless, providing additional security in productive systems is definitely recommended.
Defined fields
The authorization object consists of the field ID Client-independent maintenance. Possible
value: X. User is authorized to maintain client-independent tables.
S_TCODE
Definition
Whenever a transaction is started, a check is made against this authorization object by the screen
with the transaction code as the value. This check always takes place (from Rel. 3.0E) and cannot
be deactivated by the developer. The exceptions are transactions SU01, SU02, SU03 (so that the
missing authorizations for object S_TCODE can be post-maintained if there are problems),
transactions SU50, SU51, SU52 (setting user defaults, user address and parameters) and
transactions SU53 and SU56 (for analyzing possible errors).

20

Defined fields
TCD: Transaction code
S_TRANPRT
Definition
Authorization object for Workbench, Customizing, and Transport Organizer
An authorization for this object is required to use the following R/3 System components:
ABAP Workbench
Customizing system
Workbench, Customizing, and Transport Organizer
Developers and Customizing developers should generally have an authorization for this object.
The display authorization is usually sufficient for administrators. Administration functions in the
Change and Transport System area are checked using the separate authorization object
S_CTS_ADMI.
Defined fields
The authorization object has two fields:
Request type (Change and Transport System) (TTYPE)
Activity (ACTVT)
Appropriate authorization checks are assigned to the various actions in the Workbench,
Customizing, and Transport Organizer using these fields.
The fields can have the following values:
Request type (Change and Transport System)
CLCP: Client transports
CUST: Customizing requests
DLOC: Local change requests
DTRA: Transportable change requests
MOVE: Relocation transports (all three types)
PATC: Advance corrections and deliveries
PIEC: Object lists
TASK: Tasks (repair or correction)
TRAN: Transports of copies
Activity
01: Add or create
02: Change
03: Display
05: Lock
06: Delete
23: Change in object list editor
43: Release
50: Change source client of a request
60: Import
65: Reorganize (merge request)
75: Release other requests
90: Change owner
Examples
Example 1:

21

Field

Value

Request type DTRA

Activity
01
The system checks whether you have the authorization required to create a change request
(TTYPE = 'DTRA') (ACTVT = '01').
Example 2:
Field
Value
Request type TRAN
Activity
43
The system checks whether you have the authorization required to release a transport of copies
(TTYPE = 'TRAN') (ACTVT = '43').
Standard authorizations
SAP delivers the following authorizations for authorization object S_TRANSPRT. They
correspond to typical tasks in the development area.
S_CTS_SHOW
Display authorization in the Change and Transport Organizer
S_CTS_DEVELO
Developers with this authorization cannot create or release change requests independently. They
can only work at task level and have the authorizations required for this, for example, to release
tasks.
S_CTS_PROJEC
You can create and release change requests with this authorization. This authorization should be
assigned to project managers coordinating the development projects.
It also allows transports of copies and relocation transports to be processed.
S_CTS_TR_ALL
All operations available can be applied to all request types. In contrast to the standard
authorization S_CTS_PROJEC, this authorization contains
- processing delivery transports and client transports
- the activities "change source client", "import"
- the authorization for releasing other requests
Developers and project managers do not normally require this authorization.
Note
S_CTS_TR_ALL does not contain the authorization for administrative tasks in the Change and
Transport Organizer area. These are covered by the authorization object S_CTS_ADMI.
S_TRANSLAT
Definition
The authorization object S_TRANSLAT is required for using the R/3 translation environment.
Defined fields
ACTVT Activity
Specify whether translation is allowed.
Possible input:
o 02: Call an object directly in SE63
o A8: Automatich distribution of translations
TLANGUAGE Target language
Specify in which languages translation can take place.
Possible values: see table T002T

22

TRANOBJ Translation: Text type ID

Specify which text types can be translated.
Possible values:
o SHRT: short texts
o LONG: long texts

23