R 3 Security Tcodes End User

R/3 Security Tcodes
End User
Transaction Code
Menu Path Purpose
SU3 System --> User Profile--> Own Set address/defaults/parameters

Data
SU53 System --> Utilities --> Display Display last authority check that failed
Authorization Check
SU56 Tools --> Administration --> Display user buffer

Monitor --> User Buffer
Role Administration
Transaction Code
Menu Path Purpose
PFCG Tools --> Administration --> User Maintain roles using the Profile Generator
Maintenance --> Roles
PFUD <none> Compare user master in dialog.

This function can also be called in the Profile
Generator: Environment --> Mass compare
The Job for user master comparison is:
PFCG_TIME_DEPENDENCY (to Release 4.0
RHAUTUP1)
SUPC Tools --> Administration --> User Mass Generation of Profiles

Maintenance --> Roles -->
Environment --> Mass Generation
User Administration
Transaction Code
Menu Path Purpose
SU01 Tools --> Administration --> User Maintain Users

Maintenance --> Users
SU01D Tools --> Administration --> User Display Users

Maintenance --> Display Users
SU10 Tools --> Administration --> User User mass maintenance

Maintenance --> User Mass
Maintenance
SU02 Tools --> Administration --> User Manually create profiles
Maintenance --> Manual
Maintenance --> Edit Profiles
Manually
SU03 Tools --> Administration --> User Manually create authorizations

Maintenance --> Manual
Maintenance --> Edit Authorizations
Manually
Profile Generator Configuration
Transaction Code
Menu Path Purpose
RZ10(to view,edit
parameters for Tools --> CCMS --> Configuration Maintain system profile parameters.
instance/start/default --> Profile Maintenance (auth/no_check_in_some_cases = Y).
profile)
SU25 IMG Activity: Installation

Enterprise IMG --> Basis 1. Initial Customer Tables Fill
Components --> System Upgrade
Administration --> Users and 2a. Preparation: Compare with SAP values
Authorizations --> Maintain 2b. Reconcile affected transactions
authorizations and profiles using 2c. Roles to be checked
Profile Generator --> Work on SAP 2d. Display changed transaction codes
check indicators and field values
Select: Copy SAP check ID’s and
field values
 Maintain Check Indicators
SU24 Same as for SU25:
Select: Change Check Indicators  Maintain Templates
Transport
Transaction Code
Menu Path Purpose
SCCL Tools --> Administration --> Local client copy (within one system, between
Administration --> Client different clients)
Administration --> Client Copy -->
Local Copy
SCC9 Tools --> Administration --> Remote Client Copy (between clients in
Administration --> Client different systems) Data exchange over a
Administration --> Client Copy --> network (not files).
Remote Copy
SCC8 Tools --> Administration --> Client transport (between clients in different
Administration --> Client systems) Data exchange using a data export
Administration --> Client Transport at operating system level.
--> Client Export
<none> Tools --> Administration --> User Mass transport of roles

Maintenance --> Roles -->
Environment --> Mass Transport
<none> Tools --> Administration --> User Upload/Download of Roles

Maintenance --> Roles --> Role -->
Upload/Download
SU25 Point 3. Transport of Check indicators
STMS Tools -->Administration --> Transport Management System

Transports --> Transport
Management System
System configuration
Transaction Code
Menu Path Purpose
RZ10 Tools --> CCMS --> Configuration Maintain system profile parameters.
--> Profile Maintenance (auth/no_check_in_some_cases = Y). .
RZ11 Description of system profile parameters
SM01 Tools --> Administration --> Lock transaction codes from execution
Administration --> Transaction Code
Administration
Authorization Object
Transaction Code
Menu Path Purpose
SU20 Tools --> ABAP Workbench --> List of authorization fields

Development --> Other Tools -->
Authorization Objects --> Fields
SU21 Tools --> ABAP Workbench --> List of authorization objects (Initial screen
Development --> Other Tools --> lists by object class)
Authorization Objects --> Objects
Audit
Transaction Code
Menu Path Purpose
SE84 Tools --> Administration --> User Information System for SAP R/3
Maintenance --> Information System Authorizations
SECR* <none> Audit Information System
Table maintenance
Transaction Code
Menu Path Purpose
SM30 System --> Services --> Table Create table authorization groups (V_BRG)
(Tables Maintenance --> Extended Table Maintain assignments to tables (V_DDAT)
V_BRG, Maintenance
V_DDAT)
AL08-TO CHECK IN WHICH APPLICATION SERVER YOU ARE LOGGED IN
SM51- TO CHAGE APPLICATION SERVER
SM04- KICK OFF USER
SE03- >SEARCH FOR OBJECTS/FIELDS->ACGR-> TO CHECK IN WHICH TR NUMBER A ROLE IS MOVED

Table Group
Transaction Code
Menu Path Purpose
SE43 ABAP Workbench --> Development --> Other Tools Maintain (Display) Area Menus
--> Area Menus
R/3 Security Tables
Security Tables
Table Description
USR02 Logon data
USR04 User master authorization (one row per user)
UST04 User profiles (multiple rows per user)
USR10 Authorisation profiles (i.e. &_SAP_ALL)
UST10C Composit profiles (i.e. profile has sub profile)
USR11 Text for authorisation profiles
USR12 Authorisation values
USR13 Short text for authorisation
USR40 Tabl for illegal passwords
USGRP User groups
USGRPT Text table for USGRP
USH02 Change history for logon data
USR01 User Master (runtime data)
USER_ADDR Address Data for users
AGR_1016 Name of the activity group profile
AGR_1016B Name of the activity group profile
AGR_1250 Authorization data for the activity group
AGR_1251 Authorization data for the activity group
AGR_1252 Organizational elements for authorizations
AGR_AGRS Roles in Composite Roles
Role definition/Table to find the Parent and derived Role Relationship in

AGR_DEFINE
field parent_agr
AGR_HIER2 Menu structure information - Customer vers

AGR_HIERT Role menu texts
AGR_OBJ Assignment of Menu Nodes to Role
AGR_PROF Profile name for role
AGR_TCDTXT Assignment of roles to Tcodes
AGR_TEXTS File Structure for Hierarchical Menu - Cus
AGR_TIME Time Stamp for Role: Including profile
AGR_USERS Assignment of roles to users
USOBT Relation transaction to authorization object (SAP)
USOBT_C Relation Transaction to Auth. Object (Customer)
USOBX Check table for table USOBT
USOBXFLAGS Temporary table for storing USOBX/T* chang
USOBX_C Check Table for Table USOBT_C
Findout what atbles linked to a particular auth group(used in s_tabu_dis for
TDDAT
restricting table access
TBRG CONTAINS THE TABLE AUTH GROUPS IN A SYSTEM
SAP Security Interview Questions
Q. SAP Security T-codes

A. Frequently used security T-codes
SU01 Create/ Change User SU01 Create/ Change User

PFCG Maintain Roles
SU10 Mass Changes
SU01D Display User
SUIM Reports
ST01 Trace
SU53 Authorization analysis
Click here for all Security T-codes
Q List few security Tables

Click here for security tables
Q How to create users?

Execute transaction SU01 and fill in all the field. When creating a new user, you must enter an
initial password for that user on the Logon data tab. All other data is optional. Click here for
turotial on creating sap user id
Q What is the difference between USOBX_C and USOBT_C?

The table USOBX_C defines which authorization checks are to be performed within a
transaction and which not (despite authority-check command programmed ). This table also
determines which authorization checks are maintained in the Profile Generator.
The table USOBT_C defines for each transaction and for each authorization object which
default values an authorization created from the authorization object should have in the Profile
Generator.
Q What authorization are required to create and maintain user master records?
The following authorization objects are required to create and maintain user master records:
 S_USER_GRP: User Master Maintenance: Assign user groups
 S_USER_PRO: User Master Maintenance: Assign authorization profile
 S_USER_AUT: User Master Maintenance: Create and maintain authorizations
Q List R/3 User Types
1. Dialog users are used for individual user. Check for expired/initial passwords Possible
to change your own password. Check for multiple dialog logon
2. A Service user - Only user administrators can change the password. No check for
expired/initial passwords. Multiple logon permitted
3. System users are not capable of interaction and are used to perform certain system
activities, such as background processing, ALE, Workflow, and so on.
4. A Reference user is, like a System user, a general, non-personally related, user.
Additional authorizations can be assigned within the system using a reference user. A
reference user for additional rights can be assigned for every user in the Roles tab.
Q What is a derived role?
 Derived roles refer to roles that already exist. The derived roles inherit the menu
structure and the functions included (transactions, reports, Web links, and so on) from
the role referenced. A role can only inherit menus and functions if no transaction codes
have been assigned to it before.
 The higher-level role passes on its authorizations to the derived role as default values
which can be changed afterwards. Organizational level definitions are not passed on.
They must be created anew in the inheriting role. User assignments are not passed on
either.
 Derived roles are an elegant way of maintaining roles that do not differ in their
functionality (identical menus and identical transactions) but have different
characteristics with regard to the organizational level. Follow this link for more info
Q What is a composite role?
 A composite role is a container which can collect several different roles. For reasons of
clarity, it does not make sense and is therefore not allowed to add composite roles to
composite roles. Composite roles are also called roles.
 Composite roles do not contain authorization data. If you want to change the
authorizations (that are represented by a composite role), you must maintain the data
for each role of the composite role.
 Creating composite roles makes sense if some of your employees need authorizations
from several roles. Instead of adding each user separately to each role required, you
can set up a composite role and assign the users to that group.
 The users assigned to a composite role are automatically assigned to the
corresponding (elementary) roles during comparison. Follow the link to learn more
Q. What does the different color light mean in profile generator?

A.
Q. What are the different tabs in PFCG?

A.
Q What does user compare do?

If you are also using the role to generate authorization profiles, then you should note that the
generated profile is not entered in the user master record until the user master records have
been compared. You can automate this by scheduling report FCG_TIME_DEPENDENCY on a
daily.
Q. Can we convert Authorization field to Org, field

A. Authorization field can be changed to Organization field using PFCG_ORGFIELD_CREATE or
ZPFCG_ORGFIELD_CREATE
Use SE38 or SA38 to run the above report.
 Organizational level fields should only be created before you start setting up your system. If
you create organizational level fields later, you might have to do an impact analysis. The
authentication data may have to be postprocessed in roles.
 The fields "Activity", "ACTVT" and "Transaction code", "TCD" cannot be converted into an
organizational level field.
In addition, all affected roles are analyzed and the authorization data is adjusted. The values of the
authorization field which is now to become the organizational level field are removed and entered
into the organizational level data of the role.
Note: Table for Org Element- USORG
Refer to Note 323817 for more detail.
Q. How many profiles can be assigned to any user master record.

A. Maximum Profiles that can be assigned to any user is ~ 312. Table USR04 (Profile assignments
for users). This table contains both information on the change status of a user and also the list of
the profile names that were assigned to the user.
The field PROFS is used for saving the change flag (C = user was created, M = user was changed),
and the name of the profiles assigned to the user. The field is defined with a length of 3750
characters. Since the first two characters are intended for the change flag, 3748 characters remain
for the list of the profile names per user. Because of the maximum length of 12 characters per
profile name, this results in a maximum number of 312 profiles per user.
Q. Can you add a composite role to another composite role?

A. No
Q. How to reset SAP* password from oracle database.

A. Logon to your database with orasid as user id and run this sql
delete from sapSID.usr02 where bname='SAP*' and mandt='XXX';
commit;
Where mandt is the client.
Now you can login to the client using sap* and password pass
Q. What is difference between role and profile.

A. A role act as container that collect transaction and generates the associated profile. The profile
generator (PFCG) in SAP System automatically generates the corresponding authorization profile.
Developer used to perform this step manually before PFCG was introduced bySAP. Any maintenance
of the generated profile should be done using PFCG.
Q. What is user buffer?

A. When a user logs on to the SAP R/3 System, a user buffer is built containing all authorizations for
that user. Each user has their own individual user buffer. For example, if user Smith logs on to the
system, his user buffer contains all authorizations of role USER_SMITH_ROLE. The user buffer can
be displayed in transaction SU56.
A user would fail an authorization check if:
 The authorization object does not exist in the user buffer

 The values checked by the application are not assigned to the authorization object in the
user buffer
 The user buffer contains too many entries and has overflowed. The number of entries in the
user buffer can be controlled using the system profile parameter
auth/number_in_userbuffer.
Derived Role
Derived roles
1. Derived roles refer to roles that already exist. The derived roles inherit the menu structure
and the functions included (transactions, reports, Web links, and so on) from the role
referenced. A role can only inherit menus and functions if no transaction codes have been
assigned to it before.
2. The higher-level role passes on its authorizations to the derived role as default values which
can be changed afterwards. Organizational level definitions are not passed on. They must
be created anew in the inheriting role. User assignments are not passed on either.
3. Derived roles are an elegant way of maintaining roles that do not differ in their functionality
(identical menus and identical transactions) but have different characteristics with regard to
the organizational level.
4. The menus passed on cannot be changed in the derived roles. Menu maintenance takes
place exclusively in the role that passes on its values. Any changes immediately affect all
inheriting roles.
5. You can remove the inheritance relationship, but afterwards the inheriting role is treated like
any other normal role. Once a relationship is removed, it cannot be established again.
Composite Role
Composite roles
1. A composite role is a container with several different roles. For reasons of clarity, it
does not make sense and is therefore not allowed to add composite roles to composite
roles. Composite roles are also called roles.
2. Composite roles do not contain authorization data. If you want to change the
authorizations (that are represented by a composite role), you must maintain the data
for each role of the composite role.
3. Creating composite roles makes sense if some of your employees need authorizations
from several roles. Instead of adding each user separately to each role required, you
can set up a composite role and assign the users to that group.
4. The users assigned to a composite role are automatically assigned to the corresponding
(elementary) roles during comparison.
o The menu tree of a composite role is, in the simplest case, a combination of the
menus of the roles contained. When you create a new composite role, the initial
menu tree is empty at first. You can set up the menu tree by choosing Read
menu to add the menus of all roles included. This merging may lead to certain
menu items being listed more than once. For example, a transaction or path
contained in role 1 and role 2 would appear twice.
o If the set of roles contained in a composite role changes, the menu tree is also
affected. In such a case, you can completely rebuild the menu tree or process
only the changes. If you choose the latter option, the Profile Generator removes
all items from the menu which are not contained in any of the roles referenced.
o It is possible (and often necessary) to change the menu of a composite role at

any time. You adjust these menus in the same way as the menus for roles (see
above).
Characterization of user types
Dialog user 'A'

Individual system access (personalized)
 Logon with SAPGUI is possible. The user is therefore interaction-capable with the
SAPGUI.
 Expired or initial passwords are checked.
 Users have the option of changing their own passwords.
 Multiple logon is checked.
Usage: For individual human users (also Internet users)
System user 'B'

System-dependent and system-internal operations
 Logon with SAPGUI is not possible. The user is therefore not interaction-capable
with the SAPGUI.
 The passwords are not subject to to the password change requirement, that is,
they cannot be initial or expired.
 Only an administrator user can change the password.
 Multiple logon is permitted.
Usage: Internal RFC, background processing, external RFC (for example, ALE,
workflow, TMS, CUA)
Communication user 'C'

Individual system access (personalized)
 Logon with SAPGUI is not possible. The user is therefore not interaction-capable
with the SAPGUI.
 Expired or initial passwords are checked but the conversion of the password
change requirement that applies in principle to all users depends on the caller
(interactive/not interactive). (*)
 Users have the option of changing their own passwords.
Usage: external RFC (individual human users)
Service user 'S'

Shared system access (anonymous)
 Logon with SAPGUI is possible. The user is therefore interaction-capable with the
SAPGUI.
 The passwords are not subject to the password change requirement, that is, they
cannot be initial or expired.
 Only a user administrator can change the password.
 Multiple logon is permitted.
Usage: Anonymous system access (for example, public Web services)
Reference user 'L'

Authorization enhancement
 No logon possible.
 Reference users are used for authorization assignment to other users.
Usage: Internet users with identical authorizations
Remarks:
(*) With all non-interactive system accesses (that is, not using the SAPGUI), the password
change rule (which exists for all users except for system and service users when
passwords are initial or have expired) is not enforced by the system if there is no
interaction option. However, provided that you can execute a password update dialog with
the user (=> middleware, such as SAP ITS, for example,), RFC client programs should
recognize the need to change a password and initiate the subsequent password change by
calling special function modules (=> see note 145715) or RFC-API functions (as of 4.6C).
The user interaction (including handling error and exceptional situations) is provided here
with the middleware (= RFC client).
Profile Parameters for Logon
To make the parameters globally effective in an SAP System (system profile parameters),
set them in the default system profile DEFAULT.PFL. However, to make them instance-
specific, you must set them in the profiles of each application server in your SAP System.
To display the documentation for one of the parameters, choose Tools >> CCMS>>
Configuration >> Profile Maintenance (transaction RZ10), specify the parameter name and
choose Display.
Password Checks
Parameters Explanation
login/min_password_lng Defines the minimum length of the

password.
Default value: 3; permissible values: 3 – 8
login/min_password_digits Defines the minimum number of digits (0-

9) in passwords.
Available as of SAP Web AS 6.10
Defines the minimum number of letters (A-
login/min_password_letters Z) in passwords.
login/min_password_specials Defines the minimum number of special

characters in the password Permissible
special characters are ()!\"@ $%&/
()=?'`*+~#-_.,;:{[]}\\<>
login/min_password_diff Defines the minimum number of characters

that must be different in the new password
compared to the old password.
login/password_expiration_time Defines the validity period of passwords in

days.
Default value: 0; permissible values: any
numerical value
login/password_change_for_SSO If the user logs on with Single Sign-On,

checks whether the user must change his
or her password.
Available as of SAP Web AS 6.10, as of
SAP Basis 4.6 by Support Package
login/disable_password_logon Controls the deactivation of password-
based logon
login/password_logon_usergroup Controls the deactivation of password-

based logon for user groups
Multiple Logon
login/disable_multi_gui_login Controls the deactivation of multiple dialog

logons
Available as of SAP Basis 4.6
login/multi_login_users List of excepted users (multiple logon)

Incorrect Logon
login/fails_to_session_end Defines the number of unsuccessful logon

attempts before the system does not allow
any more logon attempts. The parameter is
to be set to a value lower than the value of
parameter login/fails_to_user_lock.
Default value: 3; permissible values: 1 -99
login/fails_to_user_lock Defines the number of unsuccessful logon

attempts before the system locks the user.
By default, the lock applies until midnight.
Default value: 12; permissible values: 1 -99
login/failed_user_auto_unlock Defines whether user locks due to

unsuccessful logon attempts should be
automatically removed at midnight.
Default value: 1 (Lock applies only on same
day); permissible values: 0, 1
Initial Password: Limited Validity
login/password_max_new_valid Defines the validity period of passwords

for newly created users.
login/password_max_reset_valid Defines the validity period of reset

passwords.
SSO Logon Ticket
login/accept_sso2_ticket Allows or locks the logon using SSO ticket.

Available as of SAP Basis 4.6D, as of SAP
Basis 4.0 by Support Package
login/create_sso2_ticket Allows the creation of SSO tickets.

Available as of SAP Basis 4.6D
login/ticket_expiration_time Defines the validity period of an SSO

ticket.
login/ticket_only_by_https The logon ticket is only transferred using

HTTP(S).
login/ticket_only_to_host When logging on over HTTP(S), sends the

ticket only to the server that created the
ticket.
Other Login Parameters:
login/disable_cpic Refuse incoming connections of type CPIC
login/no_automatic_user_sapstar Controls the emergency user SAP* (SAP

Notes 2383 and 68048)
login/system_client Specifies the default client. This client is

automatically filled in on the system logon
screen. Users can type in a different client.
login/update_logon_timestamp Specifies the exactness of the logon

timestamp.
Other User Parameters
rdisp/gui_auto_logout Defines the maximum idle time for a user in

seconds (applies only for SAP GUI
connections).
Default value: 0 (no restriction);
permissible values: any numerical value
Learn more about this effects different user type

New Password rules
Overview of the improvements and changes in password rules or logon procedures that
are delivered with Web AS ABAP 7.00 or NetWeaver 2004s
 Passwords: Differentiation between upper and lower case; maximum

length increased from eight to forty characters
For new passwords, the system distinguishes between upper and lower case ; in
addition, passwords can now consist of up to forty characters (up until now, the
maximum has been eight characters). In newly-installed systems, this applies
immediately to all users; in systems that have been upgraded to Web AS ABAP
7.00 or NetWeaver 2004s from an earlier release, we have ensured that all users
can continue to log on using their old password. Information that tells the system
whether a user has a new password or a password of the old type is stored in the
user master record; this information is analyzed when the system checks the
password: if the user has a password of the old type, the system converts the first
eight characters of the password into upper case; the remaining thirty-two
characters must be spaces. Otherwise, the password is analyzed in its entirety
and without being converted into upper case. In Unicode systems, you can use
Unicode characters in passwords.
Relevant (new) profile parameters:
o login/min_password_lowercase
o login/min_password_uppercase
o login/password_downwards_compatibility
 Password history: size can now be defined as required (it used to be

limited to five entries)
The passwords that the user has assigned in the course of a password change are
stored in the password history (passwords set by the user administrator are not
stored in the password history). The system prevents the user from reusing
previously-used passwords. The password history used to be limited to five
entries; you can now define the size of the password history (maximum value:
100 entries) using a profile parameter (login/password_history_size).
 Lock period for password change can be selected (it used to be limited to
one day)
To prevent the password history from being bypassed, a user may only change his
or her password again after the lock period has passed (exception: the user is
asked to change the password by the system). You can now select this lock period
using the profile parameter login/password_change_waittime (maximum value:
1000 days).
 (Advance) password change with stricter password rules

You can now set the system so that it asks only users whose current password no
longer satisfies the current (stricter) password rules to change their password (in
advance). To do this, set the profile parameter
login/password_compliance_to_current_policy = 1.
 Validity period of unused passwords can be restricted

Passwords that are not used by the authorized user are a security risk. For this
reason, you are now able to restrict the validity period of these passwords; here,
the system distinguishes between initial passwords (that is, passwords that are
assigned by the user administrator and that are to be changed by the user at the
next opportunity) and non-initial passwords (that is, passwords that have been
set by the user). (Technical) users of the type SERVICE and SYSTEM are exempt
from this regulation.
Relevant (new) profile parameters:
o login/password_max_idle_initial
o login/password_max_idle_productive
 Logon: Compromising error messages are avoided

If you attempt to log on using incorrect logon data, the system now only issues
the generic error message "Name or password is incorrect" as a rule; further
reasons for failed logons (for example, locked user accounts, user account is
outside validity period, and so on) are only given in detail when valid logon data
has been passed. Error scenarios in which the system could not check the logon
data, or where no further check is allowed are the exceptions to this rule:
o "User has no password - logon using password is not possible"
o "Password logon no longer possible - too many failed attempts"
 The default values of certain profile parameters that are relevant to security
have been changed:
o login/failed_user_auto_unlock : 0 (instead of 1)
Locks for failed logon attempts remain valid for an unlimited
period.
o login/fails_to_user_lock : 5 (instead of 12)

The lock for failed logon attempts is set after five failed
passwordlogon attempts.
o login/no_automatic_user_sapstar : 1 (instead of 0)
The emergency user must be activated explicitly.
o login/min_password_lng : 6 (instead of 3)
Passwords must consist of at least six characters.
o login/ticket_expiration_time : 8 (instead of 60)

Logon tickets are only valid for eight hours.
 The profile parameters login/password_max_new_valid and

login/password_max_reset_valid have been replaced by the profile parameter
login/password_max_idle_initial, which means that the system no longer
distinguishes between the first and the subsequent setting of a password by the
user administrator regarding the restriction of the validity of the resulting initial
passwords.
Authorization Analysis
Analyze Authorization check SU53
1. Choose the menu path System -> Utilities -> Display Authorization Check or transaction
code SU53. You now can analyze an error in your system that just occurred because of a
missing authorization.
2. You can call Transaction SU53 in all sessions, not just in the session in which the error
occurred. Authorization errors in other users' sessions, however, cannot be analyzed from
your own session.
3. In the below example, user Bob calls Transaction VA03 (display sales order). The message
"You do not have authorization for Transaction VA03" appears. User Bob now chooses
transaction code /nSU53 and the system displays the authorization object that was just
checked and, for comparison purposes, the values of the object that user Bob has in its user
master record. In this case the user Bob don’t have VA03 assigned to any of his role.
4. Transaction SU56 allows the user to see what current authorizations are in his buffer
Authorization Trace ST01
You can analyze authorizations as follows: Choose Tools -> Administration -> Monitor -> Traces ->
SAP System Trace or Transaction ST01.
Choose trace component Authorization check and pushbutton Trace on. The trace is automatically
written to the hard disk.
To limit the trace function to your own sessions, choose Edit -> Filter -> Shared. Enter your user ID
in field Trace for user only in the displayed dialog box.
Once the analysis is completed, choose Trace off.
To display the results of the analysis, choose Goto -> Files/Analysis or the pushbutton File listSelect
the required file and choose Analyze.
 The results of the authorization check are displayed in the following format: <Authorization
object>:<Field>=<Tested value>
 The return code shows whether or not the authorization code was successful.
 ST01 Return Code
0 Authorization check passed
1 No Authorization
2 Too many parameters for authorization check
3 Object not contained in user buffer
4 No profile contained in user buffer
6 Authorization check incorrect
7,8,9 Invalid user buffer
After 4.6 upgrade version we get only these RCs.
RC= 0 Check for authorization successful.
RC= 4 Check for authorization unsuccessful. User has authorization object in his user
buffer but with different values than what are checked.
RC= 12 Check for authorization unsuccessful. User doesn’t have authorization object in
user buffer.
Q. How to restrict a Table ?
For client dependent Tables:
By using S_Tabu_Dis object 2 fields. 1.auth group & 2 activity (02 change & 03 display)
Each table is linked with a auth group which can be created & linked using tcode SE54.So by
maintaining proper auth group we can restrict access to a table.
TDDAT-Table used for getting the auth group of a table linked with
TBRG-Table for getting details about the auth groups in a system
For cross client/client independent:
S_Tabu_DIS check happens first then S_TABU_CLI check happens.
S_TABU_CLI has only one field named “CLIDMAINT”.(indicator for cross client maintainace) It has
to take a “X” value to grant a user auth to maintain cross client table.
Q.What happens when a table is not linked to any auth group ?
Bydefault the system assigns the tables to auth group “&NC&”(not classified) auth group.
Q.What is the demerit in proving the table access by S_TABU_DIS & how to overcome it?
By using S_TABU_DIS object,we are providing access to tables linked to a particular authorization
group.Each group can be linked with many tables but the vice versa is not true.Hence there is a
possibility that the user may get access to more tables then what actually it is needed.So the
solution is to go for another auth check i.e “S_TABU_NAM”.It has two fields as below.
Activity(ACTVT) & Table name (TABLE)
Activity restricts the access to change(02) & display(03).The field TABLE(Table name) is for name of
the table which needs to be accessed.
After the S_Tabu_DIS check the check for S_TABU_NAM happens.So if the user has the access for
S_TABU_NAM in his user buffer then he will have the access to tables.
When accessing any table via SE16, SE16N, SM30 etc the authorization check for
S_TABU_DIS is checked first.
If auth check is successful, access is granted as specified in activity(02 for change and 03
for DIsplay)
If auth check is failed, auth check for S_TABU_NAM is done.
If S_TABU_NAM auth check is success, access is granted as given in activity specified in

S_TABU_NAM.
If S_TABU_NAM auth check is failed, access is not granted.
Q.Different types of locks?
0-not locked
32-globally locked
64-locally locked
128-locked due to incorrect log on

S_USER_GRP
Authorization object S_USER_GRP is checked during user maintenance.
Defined fields
The object is defined with the following two fields:
 CLASS User group

This field can be used to set a user administrator for maintenance of one or more
user groups. This makes sense if there is to be more than one user administrator.
Every user must be assigned to a user group. Users that are not assigned to a
group can be maintained by all user administrators.
As of Release 4.6, users can be assigned to more than one group. Note that one
group is marked as relevant for the authorization check. This is the group listed
under the "Logon data" tab in the user maintenance transaction SU01.
 ACTVT Activity
This field can be used to limit what the administrator is allowed to do with the
authorization.
Possible values:
o 01: Create
o 02: Change
o 03: Display
o 05: Lock, unlock
o 06: Delete
o 08: Display change documents
o 22: Add users to activity groups
o 24: Archive
o 78: Assign
o 68: Model users and assign to systems or activity groups in user
management. The models are used later as templates for the actual
assignments.
Authorization Description
Object
User master maintenance: Authorizations
S_USER_AUT
This authorization object defines which authorizations the administrator
can process. You can use the activities to specify the types of processing
(such as creating, deleting, displaying change documents).
User master maintenance: User groups
S_USER_GRP
The authorization object is used in role administration when assigning
users to roles and during the user master comparison.
You can divide user administration between several administrators with

this authorization object, by assigning only a certain user group to an
administrator. You can use the activities to specify the administrator’s
processing types for the group (such as creating, deleting, and
archiving).
User master maintenance: Authorization profiles
S_USER_PRO
Profiles are protected with this authorization object. You can use the
activities to specify the administrator's processing types for the profile
(such as creating, deleting, and archiving).
Authorization system: Check for roles
S_USER_AGR
This authorization object protects roles. The roles combine users into
groups to assign various properties to them; in particular, transactions
and authorization profiles.
You can use this authorization object together with the authorization
objects S_USER_GRP, S_USER_AUT, S_USER_PRO,
S_USER_TCD, and S_USER_VAL to set up a distributed user
administration.
Authorization system: Transactions in roles
S_USER_TCD
This authorization object determines the transactions that an
administrator can assign to a role, and the transactions for which he or
she can assign transaction authorization (object S_TCODE).
Note that a user can only maintain ranges of transactions for the
S_TCODE authorization object in the Profile Generator if he or she has
full authorization for the S_USER_TCD authorization object.
Otherwise, he or she can only maintain individual values for the
S_TCODE object.
Authorization system: Field values in roles
S_USER_VAL
This authorization object allows the restriction of values that a system
administrator can insert or change in a role in the Profile Generator.
This authorization object relates to all field values with the exception of
the values for the object S_TCODE.
The authorization to include transactions in a role or to change the

transaction start authorization in a role is linked to the authorization
object S_USER_TCD.
Authorization object for system assignment in the Central User
S_USER_SYS Administration (CUA).
You can distribute users from a central system to various child systems
of a system group. The object S_USER_SYS is used to check the
systems to which the user administrator can assign the users. This
authorization object is also checked when setting up the CUA.
User master maintenance: System-specific assignments
S_USER_SAS
The authorization object S_USER_SAS is checked in transactions
SU01, SU10, PFCG, and PFUD when you assign roles, profiles, and
systems to users. It represents a development of the authorization
objects S_USER_GRP, S_USER_AGR, S_USER_PRO, and
S_USER_SYS, which the system previously checked when users made
assignments. If you do not activate the authorization object
S_USER_SAS using the Customizing switch, the previously-used
authorization objects are checked.
To activate authorization object S_USER_SAS, use transaction SM30

to create the Customizing switch CHECK_S_USER_SAS with the
value YES in the table PRGN_CUST. All authorization checks for the
objects S_USER_AGR, S_USER_PRO, S_USER_GRP, and
S_USER_SYS with the activity assign are replaced by authorization
checks for the object S_USER_SAS.
Administration functions for user and authorization administration.
S_USER_ADM
The authorization object S_USER_ADM protects general Customizing
and administration tasks for user and authorization administration. It
consists solely of the authorization field S_ADM_AREA.
Until now, there was only the fixed value CHKSTDPWD, with which
special users (such as SAP*) could be displayed, including their default
passwords. SAP extends additional fixed values as required for other
general administration functions in the area of user and authorization
administration
Authorization Checks
Authorization Checks Starting SAP Transactions

When a user starts a transaction, the system performs the following checks:
 The system checks in table TSTC whether the transaction code is valid and
whether the system administrator has locked the transaction.
 The system then checks whether the user has authorization to start the
transaction. The SAP system performs the authorization checks every time a user
starts a transaction from the menu or by entering a command. Indirectly called
transactions are not included in this authorization check. For more complex
transactions, which call other transactions, there are additional authorization
checks.
o The authorization object S_TCODE (transaction start) contains the field
TCD (transaction code). The user must have an authorization with a value
for the selected transaction code.
o If an additional authorization is entered using transaction SE93 for the
transaction to be started, the user also requires the suitable defined
authorization object (TSTA, table TSTCA).
If you create a transaction in transaction SE93, you can assign an
additional authorization to this transaction. This is useful, if you want to
be able to protect a transaction with a separate authorization. If this is
not the case, you should consider using other methods to protect the
transaction (such as AUTHORITY-CHECK at program level).
 The system checks whether the transaction code is assigned an authorization
object. If so, a check is made that the user has authorization for this authorization
object.
The check is not performed in the following cases:
o You have deactivated the check of the authorization objects for the
transaction (with transaction SU24) using check indicators, that is, you
have removed an authorization object entered using transaction SE93.
You cannot deactivate the check for objects from the SAP NetWeaver and
HR areas.
o This can be useful, as a large number of authorization objects are often
checked when transactions are executed, since the transaction calls other
work areas in the background. In order for these checks to be executed
successfully, the user in question must have the appropriate
authorizations. This results in some users having more authorization than
they strictly need. It also leads to an increased maintenance workload.
You can therefore deactivate authorization checks of this type in a
targeted manner using transaction SU24.
o You have globally deactivated authorization objects for all
transactions with transaction SU24 or transaction SU25.
o So that the entries that you have made with transactions SU24 and SU25
become effective, you must set the profile parameter
AUTH/NO_CHECK_IN_SOME_CASES to “Y” (using transaction RZ10).
All of the above checks must be successful so that the user can start the transaction.
Otherwise, the transaction is not called and the system displays an appropriate message.
Checking Assignment of Authorization Groups to Tables

You can also assign authorization groups to tables to avoid users accessing tables using
general access tools (such as transaction SE16). A user requires not only authorization to
execute the tool, but must also have authorization to be permitted to access tables with
the relevant group assignments. For this case, we deliver tables with predefined
assignments to authorization groups. The assignments are defined in table TDDAT; the
checked authorization object is S_TABU_DIS.
Introduction on Authorizations
 Authorization objects enable complex checks of an authorization, which allows a user to

carry out an action. An authorization object can group up to 10 authorization fields that
are checked in an AND relationship.
 For an authorization check to be successful, all field values of the authorization object must
be maintained accordingly. The fields in an object should not be seen as input fields on a
screen. Instead, fields should be regarded as system elements, such as infotypes, which
are to be protected.
 You can define as many system access authorizations as you wish for an object by creating
a number of allowed values for the fields in an object. These value sets are called
authorizations. The system checks these authorizations in OR relationships.
Troubleshooting authorization in SAP R/3.

When you encounter errors during testing of roles, you can use SU53 and ST01 to analyze the
error.
1. Ask the user to run SU53 to display the result of the last failed authorization. It is important
the user run SU53 immediately after failed authorization check, as only the last object the
failed the authorization check is saved.
2. You can run trace using ST01 to further analyze the error. For more detail follow the link…
Audit Information System

The Audit Information System (AIS) has been developed to provide internal and external
auditors, Security Administrators and those with data protection and controlling responsibilities with
a tool to assist in understanding and completing required tasks in the complex SAP environment.
The SAP Audit Information System (AIS) provides a centralized repository for reports, queries,
and views of data that have a control implication. AIS was first available for SAP R/3 Version 3.0D,
and is delivered as standard in SAP R/3 Versions 4.6 and above. AIS is provided at no additional
cost from SAP, and allows an auditor or manager to work online in the production system on a real
time basis......More
Emergency Role (Firefighting)

How good you do your security there may come a time when user might need emergency
authorizations. Such authorization can be necessary in exceptional situations. It could be a month
end close, which got closed before the month end.
Virsa provides tool called firefighter, which can help you.
First you have to define what is an emergency for your company. You might have to create roles for
these emergencies, and also define the time frame this role will be assigned to users. You might
have to define an approval procedure for this. Hoe is this going to be audited. Work with your audit
team to make sure they are ok with the process
Shortcut to create role with many reports /tcode

Once I had couple of roles which where made just t hold reports. The number of reports where
huge. Here is how I did it.
First create a CATT script with a dummy role and add one tcode. Make the role and T-code as
variant. Once you have this you can add any number of tcode to any existing role. Icould resuse
this tocreate another roles where I had to insert lot of T-codes.
Project Phases .. Please follow the link for detail on project phases
Recommended Books
•Authorization made Easy
•SAP Authorization System
Writing a CAT script to create user
1 Recording a test case
1.1To record a test case, call Transaction SCAT and enter test case Zuser_creat.
Do not choose Enter.
Choose Test Case → Record Transaction. Enter Transaction SU01, and choose
Record/Enter.
The system runs Transaction SU01.
Enter the user name TESTZ and choose Create.
Enter the user’s title first name ZEBRA and the last name TEST.
Select the Logon data tab, enter init as the initial password, and repeat the password,
profile select sap_all then choose Save.
Go back a screen and
In the dialog box displayed, select End recording.
A message is displayed stating that the recording has ended.
Enter the test case title User maintenance.
In the field Component, enter BC-SEC-USR.
Save the test case.
In the field package class, enter $TMP.
Choose Save to save the attributes.
To save the test case functions, go back.
2 Entering parameters for a test case
2.1To define parameters for a test case, call Transaction SCAT.

Enter the test case name Zuser_creat.
Select Functions and choose Change.
Double-click on TCD.
Then double-click on program SAPLSUU5 screen 0050. (first appearance of this
program)
The first screen of Transaction SU01 is displayed. (If you backed out, enter the
procedure name again and double-click on TCD.)
Double-click on the user name field. In the field Param. name, enter an "&", and
choose Copy/Enter.
Choose Next screen and double-click the last name. In the field Param. name, enter an
"&" and choose Copy/Enter.
Go back until the Save folder appears, and choose Save.
3 Creating and using an external variant for the test case
3.1To export the default parameters into a frontend file, in the test case, select Goto →
Variants → Export Default.
Note: The default file name is <the name of your test case>.txt. Do not change the
default values.
3.2Open the file, with excel and edit and add another couple of user, and save the text
file
3.3To execute the test case using the external variant from file, from the initial CATT
screen, enter the test case name and choose Execute.
In the field Variants, select External from file and choose Choose. Select the file
created above, and choose Open. Under Processing mode, select Errors, and choose
Execute.
Note: When you use this method, the file must be imported each time the test case is
executed (file remains only on PC).
R/3 Security Tips
 QucikViewer (SQVI)
nerating reports. SAP Query offers the user a whole range of options for defining reports. SAP Query also supports different kinds of reports suc
ewer (SQVI), on the other hand, is a tool that allows even relatively inexperienced users to create basic lists. I have created a tutorial for SQVI.
 User assignment
tly into the user master record (Transaction SU01). Assign the role to the user in the Roles tab in transaction SU01 or choose the User tab in ro
om you want to assign the role or profile. If you then compare the user master records, the system inserts the generated profile in the user ma
 Do not assign any authorizations for modules you have not yet installed
s to your system, it is important you do not assign any authorizations for those modules you have not yet installed. This ensures that you cann
system you may need at a later stage. Leave the corresponding authorizations or organizational levels open.
 Creating SPRO Display only.

might be asked to give SPRO display while implementing your SAP. Igenerally give these authoriztion to make it display only. P
 Object  Field  Value

 S_PROJ  PROJEC
 *
ECT T_ID
 S_PROJ  PROJ_C
 *
ECT ONF
 S_RFC  ACTVT  03
 RFC_NA
 S_RFC  *
ME
 RFC_TY
 S_RFC  *
PE
 S_TAB  CLIIDM
 '
U_CLI AINT
 S_TAB
 ACTVT  03
U_DIS
 S_TAB  DICBER
 *
U_DIS CLS
 Deactivate or
 S_TRA
 TTYPE remove PIEC
NSPRT
and TASK
 S_COD  REMOV
 SPRO
E E
 Creating Authorization Fields
In authorization objects, authorization fields represent the values to be tested during authorization checks.
To create authorization fields, choose Tools --> ABAP Workbench --> Development --> Other Tools --> Authorization Objects --> Fields
To create an authorization field, proceed as follows:
 Choose Create authorization field.

 On the next screen, enter the name of the field. Field names must be unique and must begin with the letter Y or Z.
 Assign a data element from the ABAP Dictionary to the field.
d by SAP in your own authorization objects. If you create a new authorization object, you do not need to define your own fields. For example, yo
authorization objects to represent a wide variety of actions in the system.
 Creating Authorization Objects

An authorization object groups together up to ten authorization fields that are checked together in an authorization check.
To create authorization fields, choose Tools --> ABAP Workbench, Development --> Other tools --> Authorization objects --> Objects.
ect name and the fields that belong to the object. Object names must begin with the letter Y or Z in accordance with the naming convention for
elds in an object definition. You must also enter a description of the object and documentation for it. Ensure that the object definition matches
the object.
 Locking Security Holes through IMG transactions

users from SU01 or PFCG (to modifiy themselves or other people) they can get into these areas by the different IMG transaction codes. If your
 OY20 - Authorizations
OY21 - User profiles
OY22 - Create subadministrator
OY24 - Client maintenance
OY25 - CS BC: Set up Client
OY27 - Create Super User
OY28 - Deactivate SAP*
 Q. What’s the basic difference in between SU22 & SU24?
 SU22:it wil update the values in table USOBT,USOBX

SU24:it will update the values in tables USOBT_C,USOBX_C
 Q.What exactly is SU25? What's the significance of it's 2a,2b,2c & 2d sections?
U25 insulation of profile Generator. It is a one time activity .when u run this it will copy the values from table USOBT,USOBX to
USOBT=T.code VS autho Objects
USOBX=T.code VS Autho Object and check indicator
 Q. Through which tcode I can do a mass user comparision? What's the daily background job for the same?
Ans:sm36 by scheduling repot periodically or SA38 by running report
Report name : pfcg_time_dependency
 Q.What does PRGN_STAT & TCODE_MOD table consist of?
 Q.What does we check through SM50 & SM51?
 SM50 local work process over view

SM51global Work Process over view
the prerequisites we should take before assigning sap_all to a user even we have approval from authorizati
 prerequisites are follows before assigning sap_all to any
user .
1.enabling the audit log ---- using sm19 tcode.

eving the audit log-----using sm20 tcode. Incase you don’t have GRC implemented.Incase of GRC systems,provide required acc
 S_RS_RREPU: BI role template for Reporting User (rrmx for executing query)
 The reporting user executes queries in the BEx Analyzer or via the Web
 SRM Auth objects:
o BBP_PD_SC - SRM: Process Shopping Carts

o BBP_PD_BID - SRM Bid Invitation
o B_bupa_rlt- maintain business partner
o BBP_PD_VL- SRM: Edit Vendor List
o BBP_BID_EV - SRM Bid Evaluation
o BBP_BUDGET - Authorization for Budget Display
o PLM Auth objects:
o Authorization for Checklist Template CPRO_CPT

o Create Project Definition CPRO_DPO
o Authorization for Project Template CPRO_DPT
o Authorization for Evaluation CPRO_EVAL
o Authorization for Project Type CPRO_PTYPE
o Authorization for Control Plan Template CPRO_UPT
o Authorization for Version CPRO_VSHDR

R 3 Security Tcodes End User

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

R 3 Security Tcodes End User

Enviado por

Direitos autorais:

Formatos disponíveis

R/3 Security Tcodes

SU3 System --> User Profile--> Own Set address/defaults/parameters

SU56 Tools --> Administration --> Display user buffer

PFUD <none> Compare user master in dialog.

SUPC Tools --> Administration --> User Mass Generation of Profiles

SU01 Tools --> Administration --> User Maintain Users

SU01D Tools --> Administration --> User Display Users

SU10 Tools --> Administration --> User User mass maintenance

SU03 Tools --> Administration --> User Manually create authorizations

Profile Generator Configuration

SU25 IMG Activity: Installation

<none> Tools --> Administration --> User Mass transport of roles

<none> Tools --> Administration --> User Upload/Download of Roles

SU25 Point 3. Transport of Check indicators

STMS Tools -->Administration --> Transport Management System

RZ11 Description of system profile parameters

SU20 Tools --> ABAP Workbench --> List of authorization fields

SECR* <none> Audit Information System

AL08-TO CHECK IN WHICH APPLICATION SERVER YOU ARE LOGGED IN

SM51- TO CHAGE APPLICATION SERVER

SM04- KICK OFF USER

SE03- >SEARCH FOR OBJECTS/FIELDS->ACGR-> TO CHECK IN WHICH TR NUMBER A ROLE IS MOVED

Role definition/Table to find the Parent and derived Role Relationship in

AGR_HIER2 Menu structure information - Customer vers

Q. SAP Security T-codes

SU01 Create/ Change User SU01 Create/ Change User

Q List few security Tables

Q How to create users?

Q What is the difference between USOBX_C and USOBT_C?

Q List R/3 User Types

Q What is a derived role?

Q What is a composite role?

Q. What does the different color light mean in profile generator?

Q. What are the different tabs in PFCG?

Q What does user compare do?

Q. Can we convert Authorization field to Org, field

Q. How many profiles can be assigned to any user master record.

Q. Can you add a composite role to another composite role?

Q. How to reset SAP* password from oracle database.

Where mandt is the client.

Q. What is difference between role and profile.

Q. What is user buffer?

A user would fail an authorization check if:

 The authorization object does not exist in the user buffer

o It is possible (and often necessary) to change the menu of a composite role at

Dialog user 'A'

System user 'B'

Communication user 'C'

Service user 'S'

Reference user 'L'

login/min_password_lng Defines the minimum length of the

login/min_password_digits Defines the minimum number of digits (0-

login/min_password_specials Defines the minimum number of special

login/min_password_diff Defines the minimum number of characters

login/password_expiration_time Defines the validity period of passwords in

login/password_change_for_SSO If the user logs on with Single Sign-On,

login/password_logon_usergroup Controls the deactivation of password-

login/disable_multi_gui_login Controls the deactivation of multiple dialog

login/multi_login_users List of excepted users (multiple logon)

login/fails_to_session_end Defines the number of unsuccessful logon

login/fails_to_user_lock Defines the number of unsuccessful logon

login/failed_user_auto_unlock Defines whether user locks due to

Initial Password: Limited Validity