Documente Academic
Documente Profesional
Documente Cultură
End User
Transaction Code
Menu Path Purpose
SU53 System --> Utilities --> Display Display last authority check that failed
Authorization Check
Role Administration
Transaction Code
Menu Path Purpose
PFCG Tools --> Administration --> User Maintain roles using the Profile Generator
Maintenance --> Roles
User Administration
Transaction Code
Menu Path Purpose
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)
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
System configuration
Transaction Code
Menu Path Purpose
RZ10 Tools --> CCMS --> Configuration Maintain system profile parameters.
--> Profile Maintenance (auth/no_check_in_some_cases = Y). .
SM01 Tools --> Administration --> Lock transaction codes from execution
Administration --> Transaction Code
Administration
Authorization Object
Transaction Code
Menu Path Purpose
Audit
Transaction Code
Menu Path Purpose
SE84 Tools --> Administration --> User Information System for SAP R/3
Maintenance --> Information System Authorizations
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)
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
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
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.
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
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
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.
Now you can login to the client using sap* and password pass
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.
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)
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
Multiple Logon
Parameters Explanation
Incorrect Logon
Parameters Explanation
Parameters Explanation
Parameters Explanation
Parameters Explanation
Parameters Explanation
Overview of the improvements and changes in password rules or logon procedures that
are delivered with Web AS ABAP 7.00 or NetWeaver 2004s
o login/min_password_lowercase
o login/min_password_uppercase
o login/password_downwards_compatibility
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).
o login/password_max_idle_initial
o login/password_max_idle_productive
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/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.
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
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.
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
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.
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
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.
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 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.
0-not locked
32-globally locked
64-locally locked
Defined fields
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 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.
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.
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
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.
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…
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
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
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.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.
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.
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 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
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 .