S_ADMI_FCD

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 functionThe 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 authorizationsThe functions of these values are the same, as the spool administration objects are client-independent. We recommend you only enter the value SPAD. Without a functional authorization, the SPAD user cannot execute any spool administration functions.

SPAD: Authorization for spool administration in all clients

SPAR: Authorization for client-dependent spool administration

Functional authorization

SPAA: Authorization to define output devices in spool administration

SPAB: Authorization to define physical or logical Output Management Systems (OMS) in spool administration

SPAC: Authorization to maintain device types and associated objects (formatting, character sets, and so on)

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_FCDField 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

03 Display log entries

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

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

02 Change mode in archive management

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:

ABTC: Pass on sessions to background processing.

ANAL: Analyze sessions and logs.

AONL: Process sessions in dialog mode.

DELE: Delete sessions

FREE: Release sessions

LOCK: Lock and release sessions

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:

DELE: Delete background jobs of other users.

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.

PROT: Display processing logs created by the jobs of other users.

RELE: Release own jobs automatically during scheduling.

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: *.

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

02 Create, Change and Delete

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 SystemThe 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 non-SAP 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:

33: Normal file read

34: Normal file write or deletion

A6: Read file with filter (operating system command)

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 SystemPackage 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 ObjectObject 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:

APPLTREE: Application hierarchy (customer application menu hierarchy)

CLAS: Class (ABAP objects) (only display and change)

DEBUG: ABAP DebuggingSpecial activities are checked here.Activity 03: DisplayActivity 02: Changing values of fields and (as of Release 6.10) the function Debugging->Goto statementActivity 01: Displaying in System Programs and Kernel DebuggingThe 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".

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 traceIn 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)

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 templateBusiness 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

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.

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.

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.

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 caseThe object types for enhancements can be displayed, changed, created, and deleted.

ENHO: Enhancement

ENHS: Enhancement Spot

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.

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.

SFBS: Business Set

SFBF: Business Function

SFSW: Switch

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

P_GROUP Authorization group for ABAP programsAllowed 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 ActivityOperations that a user is allowed to execute.Possible Values:

01: Create (valid for all object types)

02: Change (valid for all object types)

03: Display (valid for all object types)

06: Delete (for all object types)

07: Activate (only effective for ABAP Dictionary object types)

16: Execute (only valid for eCATT test configurations and if you execute reports out of the development workbench accoring to note 1750997,1686842, or1596907)

40: Create object in database (object types TABL, SQLT, VIEW, MCOB, MCID, and INDX)

41: Delete object in database (object types TABL, SQLT, VIEW, MCOB, MCID, and INDX)

42: Convert object in database (object types TABL, SQLT, VIEW, MCOB, MCID, and INDX)

70: Monitor test runs (only im CATT, not im eCATT)

MA: Switch off the Modification Assistant for each transport object

L0: SAP internal. Change main package (object type DEVC)

94: SAP Internal: Overwrite package check for activating DDIC objects (object type DEVC)

Examples

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

Value

Package for transport system

*

ID of a development object

A bis TABS, TABU bis Z*

Node name

*

Authorization group ABAP program

*

Activity

*

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

Value

Package for transport system

*

ID of a development object

TABT TABL INDX MACO MCID VIEW SQLT

Node name

*

Authorization group ABAP program

*

Activity

*

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

Value

Package for transport system

*

ID of a development object

A bis U, V bis Z

Node name

*

Authorization group ABAP program

*

Activity

*

Authorization 2: Display data models

Field

Value

Package for Transport System

*

ID of a development object

U*

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 nameName of the external command in R/3. You can display the external commands defined using Transaction SM59.

OPSYSTEM Operating System of Application ServerType of operating system on the target host (see system field SY-OPSYS: values ANYOS, AIX, UNIX, WINDOWS NT)

HOST Name of Current Application ServerHost 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.

User action ABAP program: Permitted activities.

Possible values:

SUBMIT: Start the program

BTCSUBMIT: Schedule the program to run as a background job

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

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 thesatellite system

RFC_USER : ID of the calling user

RFC_EQUSER: Flag, whether the user may be called by a user with thesame ID (Y = yes, N = no).

RFC_TCODE : Calling transaction code

RFC_INFO : Additional information from calling system (curentlyinactive)

ACTVT : ActivityThis 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 : S1RFC_CLIENT: M1RFC_USER :RFC_EQUSER: YesRFC_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 : S1RFC_CLIENT: M1RFC_USER : User1RFC_EQUSER: NoRFC_TCODE : *RFC_INFO : *ACTVT : 16

Note: The field RFC_INFO is not currently used.

S_RFCDefinition

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

This authorization object contains the following fields and values:

Authorization Object S_ICF: Structure

Field

Meaning

Value

Meaning

ICF_FIELD

Type of the object that is being protected

SERVICE

This value protects server-side calls of services in the Internet Communication Framework.

DEST

This value protects remote calls of function modules on the client side.

PROXY

This values protects the editing of client-side proxy settings.

ICF_VALUE

Check value for target object (service, destination,)

(For example: CHECK1)

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.

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:

BASE: See protected spool request in the output controller (determine whether the spool request exists); Display request attributes.

DISP: Display contents of a protected spool request.

ATTR: Change attributes of protected spool request.

AUTH: Change authorization value of a protected spool request.

PRNT: Output protected request for the first time.

REPR: Output protected spool request more than once.

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.

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.

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:

02: Create, change or delete table entries

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_TCODEDefinition

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).

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:

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 ActivitySpecify whether translation is allowed.Possible input:

02: Call an object directly in SE63

A8: Automatich distribution of translations

TLANGUAGE Target languageSpecify in which languages translation can take place.Possible values: see table T002T

TRANOBJ Translation: Text type IDSpecify which text types can be translated.Possible values:

SHRT: short texts

LONG: long texts

PAGE

3