R/3 Security

Derived Role
Composite Role
User Type
Profile parameter
NewPassword rules
Authorization Analysis
Authorization Checks Starting SAP Transactions
 
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
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
0Authorization check passed
1No Authorization
2Too many parameters for authorization check
3Object not contained in  user buffer
4No profile contained in user buffer
6Authorization check incorrect
7,8,9Invalid user buffer
 

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
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.
AIS is currently focused on two key areas that are covered in more detail below:
 Systems Audit; and
 Business Audit.
AIS allows the auditor to set up a report view specific to the audit, perform tasks such as
the attaching of comments, as well as allowing for tracking the audit’s progress.
AIS also has the capability to extract data into pre-defined formats appropriate for data.
Starting Audit

Transaction code SECR is used to access the AIS. The user can elect to enter:
 Complete audit -When executed, this provides all tests and documentation
available in the AIS system.
 User defined audit - When executed, this provides tests and documentation
applicable to the User-defined audit selected by the user.
Once started the user is provided with a report tree structure that sets out all applicable
documentation and tests that are executable. The reporting tree contains steps that include
variants for each type of function. These can be centrally maintained to apply across
multiple audit tasks.
Installation Check
The Installation Check is an AIS tool which, when executed, checks whether all of the
programs and variants listed in AIS are currently available in the current system
environment. The Installation check can be initiated through selecting Extras —
Installation — Installation check from
transaction SECR.

Preparatory Tasks
In preparation for the completion of an audit, the user may complete preparatory tasks.
These tasks allow the user to customize the audit to improve efficiency in completion of
tasks.
The preparatory tasks within AIS are broken into three areas:
Area                                         Description
Allows for audit customization through the definition of variables
AIS Customization and constants to be utilized in the audit process. This may include
variables such as company codes which are then used in reporting.
Customize Financial Provides the user with functions relevant to the configuration and
Information System extraction of financial information.
 
ABAP/4 Query Provides access to logical database structure and information
including download pertinent to
extracting data for analysis purposes.
           
Systems Audit
The "Systems Audit" is primarily used for administration and review of system activities,
such as, security and change control. The users are provided with easy access to many of
the standard SAP security and control reports and audit trails.
Checklists are available to assist in the execution of an AIS systems audit. These
checklists provide samples of security items to be considered which can be amended as
required.
The System Audit functionality in AIS is broken down into the following key areas
which include:
 
Area Description
Systems Configuration Allows the user to gain details of the environment and general
set up of the SAP system.
Transport Group Information relevant to change control processes, and system
set-up.
Tables / Repository Includes information regarding table configuration, change
logging as well as table security.
Development / Information relevant to background processing, including the
Customizing graphical job schedule and access to the job overview.
Background Processing Provides access to logs (system, access, database etc) as well
as configuration settings pertinent to these logs.
System Logs Provides access to information relevant to administration and
security of the SAP system. This includes various reports on:
- User Security and Authorisations
- Profile Generator
- User administration such as users who have not logged into
the system for a predefined period of time.
User Administration  
Using the System Audit functionality, the user can access key parts of the Basis module,
including the Transport Management System, repository and table browser. It also
provides comprehensive tools to review the security around user access.
 

Audit information system

Business Audit
The “Business Audit” functionality in AIS allows the auditor to produce financial
statements and balance sheets, as well as perform general ledger, accounts payable and
accounts receivable activities and queries.
For example, through the business audit functionality, auditors can perform and
document their review of general ledger posting keys, automatic postings, billing and
document types, number ranges and reconciliation accounts, as well as duplicate invoice
reviews.
The Business Audit is broken into the following areas:
Area Description
Organizational This area allows the user to familiarize with the enterprise
Overview structure that has been implemented into SAP.
Further, the user is provided with information about the financial
structure of the organization including details on Account
Determination and Special General Ledger.
Financial Statement The Financial Statement Oriented Audit provides the user with
Oriented Audit details of
Account reconciliation, Balance Sheet, Profit & Loss and other
General Ledger related reports which can be used for financial
analysis.
Process Oriented Audit The Process Oriented Audit steps are broken down into the
 various areas of SAP including retail, procurement, production
and sales and distribution. Areas of this section are at various
levels of development.
 
When the audit begins, the present parameters and selection criteria are edited by using
the “Preparatory Tasks” in the Business Audit menu. The auditor customizes the
reporting tree to reflect the correct time period and organizational structure required for
the audit. The use of these “variants” helps reduce the potential for adversely affecting
system performance, by limiting the parameters for which the reports are run. Business
Audit functionality is not generally considered to be  comprehensive and many items
included in the menu structure are not yet functional. This should be considered when
utilizing AIS.
 
Customizing Audits
To make effective use of the AIS tool it is important to customize the audits and ensure
that only relevant information is provided. All information provided in the complete audit
can be partitioned into audit programs specific to the particular needs and scope of audit
work to be completed.
This can be performed by selecting Audit Information System — Create/change view.
A new view can then be created where you can manually select from the tree structure the
components that are to be displayed in this user defined view.

Following the customization and generation of an audit this can be accessed by selecting
the user -defined audit that has been created.
 
Security
In order for a user to access configuration, data or other reports, relevant access must be
provided to the user. The AIS provides links through to various reports and other
information, and therefore, access provided to complete AIS tasks may vary between
users in line with tasks the individual is to perform. The transaction to start the AIS is
SECR and a user must therefore be granted transaction start authorisation. In order for a
user to be able to edit notes in AIS the user must have been provided with the following
authorisation objects:

S_IMG_ACTV
 Value
Field
PROJAUTH 900 Project for Audit: 900
ACTVT 02 Change activity
IMG_ACTIV NOTE Edit notes
In order for a user to be able to edit the status of the audit and tasks in the AIS the
following authorizations must be provided: Authorisation for editing status information:
S_IMG_ACTV
Value
Field
PROJAUTH 900 Project for Audit: 900
ACTVT 02 Change activity
IMG_ACTIV STAT  Edit notes
Other security, which may be granted to the user in order to complete tasks, may include:
 Authorization to view data in the IMG.
 Authorization to display user and security information.
 System administration and other system and performance monitoring functions.
• Change control authorizations.
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.
creating a CATT script :
Recording a test case
1.1
To 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.1
To 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.1
To 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.2
Open the file, with excel and edit and add another couple of user, and save the text file
3.3
To 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).
 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 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.
Default value: 0; permissible values: 0 – 8
Available as of SAP Web AS 6.10
login/min_password_letters Defines the minimum number of letters (A-
Z) in passwords.
Default value: 0; permissible values: 0 – 8
Available as of SAP Web AS 6.10
login/min_password_specials Defines the minimum number of special
characters  in the password Permissible
special characters are ()!\"@
$%&/()=?'`*+~#-_.,;:{[]}\\<>
Default value: 0; permissible values: 0 – 8
Available as of SAP Web AS 6.10
login/min_password_diff Defines the minimum number of characters
that must be different in the new password
compared to the old password.
Default value: 1; permissible values: 1 – 8
Available as of SAP Web AS 6.10
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
Available as of SAP Web AS 6.10, as of
SAP Basis 4.6 by Support Package
login/password_logon_usergroup Controls the deactivation of password-based
 logon for user groups
Available as of SAP Web AS 6.10, as of
SAP Basis 4.6 by Support Package
Multiple Logon
Parameters Explanation
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)
Available as of SAP Basis 4.6
Incorrect Logon
Parameters Explanation
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
Parameters Explanation
login/password_max_new_valid Defines the validity period of passwords for
newly created users.
Available as of SAP Web AS 6.10, as of
SAP Basis 4.6 by Support Package
login/password_max_reset_valid Defines the validity period of reset
passwords.
Available as of SAP Web AS 6.10, as of
SAP Basis 4.6 by Support Package
SSO Logon Ticket
Parameters Explanation
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.
Available as of SAP Basis 4.6D
login/ticket_only_by_https The logon ticket is only transferred using
HTTP(S).
Available as of SAP Basis 4.6D
login/ticket_only_to_host When logging on over HTTP(S), sends the
ticket only to the server that created the
ticket.
Available as of SAP Basis 4.6D
Other Login Parameters:
Parameters Explanation
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.
Available as of SAP Basis 4.6
Other User Parameters
Parameters Explanation
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
0Authorization check passed
1No Authorization
2Too many parameters for authorization check
3Object not contained in  user buffer
4No profile contained in user buffer
6Authorization check incorrect
7,8,9Invalid user buffer
 

 
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.

R/3 Security Tips

QucikViewer (SQVI)
QuickViewer (SQVI) is a tool for generating reports. SAP Query offers the user a whole
range of options for defining reports. SAP Query also supports different kinds of reports
such as basic lists, statistics, and ranked lists. QuickViewer (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. SQVI Tutorial
QucikViewer (SQVI)
QuickViewer (SQVI) is a tool for generating reports. SAP Query offers the user a whole
range of options for defining reports. SAP Query also supports different kinds of reports
such as basic lists, statistics, and ranked lists. QuickViewer (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. SQVI Tutorial
SQVI Tutorial
There might come a time that you want the information and it is spread in multiple tables.
You can write a SQVI and get this info. In this tutorial we will write an SQVI to find out
role assigned to users with full name of the users.
You can get role assigned to users from AGR_USER table and users full name from
USER_ADDR. We will join both these table to get the result.
1. Execute transaction SQVI
2. Create a SQVI  (z_user_role)

 and
3. Put a title and comments. Make sure that you select Table join from  Data
source
 4. Click  to insert tables. Insert AGR_USERS and USER_ADDR tables.

 
5. Select the correct join. Here we will join BNAME

Hit the back button

6. Here I will select Role name and user name from AGR_USERS table and Full
name from USER_ADDR, and also make user name as the selection field. So
when I run the query it will ask me to list the users.
 7. Save the query and execute it. In the selection screen put the user you want to get
the info. You are ready with your SQVI query

User assignment
Never insert generated profiles directly 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
role maintenance (PFCG) and enter the user to whom 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 master record.
Do not assign any authorizations for modules you have not yet installed
If you intend to gradually add modules to your system, it is important you do not assign
any authorizations for those modules you have not yet installed. This ensures that you
cannot accidentally change data in your production system you may need at a later stage.
Leave the corresponding authorizations or organizational levels open.
Creating SPRO Display only.
You might be asked to give SPRO display while implementing your SAP. Igenerally give
these authoriztion to make it display only. Please test it.
Object Field Value
S_PROJECT PROJECT_ID *
S_PROJECT PROJ_CONF *
S_RFC ACTVT 03
S_RFC RFC_NAME *
S_RFC RFC_TYPE *
S_TABU_CLI CLIIDMAINT '
S_TABU_DIS ACTVT 03
S_TABU_DIS DICBERCLS *
Deactivate or
S_TRANSPRTTTYPE remove PIEC and
TASK
 S_CODE REMOVE SPRO
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:
1. Choose Create authorization field.
2. On the next screen, enter the name of the field. Field names must be unique and
must begin with the letter Y or Z.
3. Assign a data element from the ABAP Dictionary to the field.
You can often use the fields defined 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, you can use the SAP field ACTVT in your own 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.
Enter a unique object 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 customer-
specific objects.
You can enter up to ten authorization fields in an object definition. You must also enter a
description of the object and documentation for it. Ensure that the object definition
matches the ABAP AUTHORITY-CHECK calls that refer to the object.
Locking Security Holes through IMG transactions
Even though you have restricted your 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 core team or user community has access to:
OY20 - Authorizations
OY21 - User profiles
OY22 - Create subadministrator
OY24 - Client maintenance
OY25 - CS BC: Set up Client
OY27 - Create Super User
OY28 - Deactivate SAP*
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
AGR_DEFINE Role definition
AGR_HIER2 Menu structure information - Customer vers
AGR_HIERT Role menu texts
AGR_OBJ Assignment of Menu Nodes to Role
AGR_PROF Profile name for role
AGR_TCDTXT Assignment of roles to Tcodes
AGR_TEXTS File Structure for Hierarchical Menu - Cus
AGR_TIME Time Stamp for Role: Including profile
AGR_USERS Assignment of roles to users
USOBT Relation transaction to authorization object (SAP)
USOBT_C Relation Transaction to Auth. Object (Customer)
USOBX Check table for table USOBT
USOBXFLAGS Temporary table for storing USOBX/T* chang
USOBX_C Check Table for Table USOBT_C
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 --> Maintain roles using the Profile Generator
User Maintenance --> Roles
PFUD <none> Compare user master in dialog.
This function can also be called in the
Profile Generator:   Environment
compare
The Job for user master comparison is:
PFCG_TIME_DEPENDENCY (to Release
4.0 RHAUTUP1)
SUPC Tools --> Administration --> Mass Generation of Profiles
User Maintenance --> Roles --
> Environment --> Mass
Generation
User Administration
Transaction Code Menu Path Purpose
SU01 Tools --> Administration --> Maintain Users
User Maintenance --> Users
SU01D Tools --> Administration --> Display Users
User Maintenance --> Display
Users
SU10 Tools --> Administration --> User mass maintenance
User Maintenance --> User
Mass Maintenance
SU02 Tools --> Administration --> Manually create profiles
User Maintenance --> Manual
Maintenance --> Edit Profiles
Manually
SU03 Tools --> Administration --> Manually create authorizations
User Maintenance --> Manual
Maintenance --> Edit
Authorizations Manually
Profile Generator Configuration
Transaction Code Menu Path Purpose
RZ10 Tools --> CCMS --> Maintain system profile parameters.
Configuration --> Profile (auth/no_check_in_some_cases = Y).
Maintenance
SU25 IMG Activity: Installation
Enterprise IMG --> Basis 1. Initial Customer Tables Fill
Components --> System Upgrade
 Administration --> Users and 2a. Preparation: Compare with SAP
Authorizations --> Maintain values
authorizations and profiles 2b. Reconcile affected transactions
using  Profile Generator --> 2c. Roles to be checked
Work on SAP check indicators 2d. Display changed transaction codes
and field values
Select: Copy SAP check ID’s
and field values
SU24 Same as for SU25:  Maintain Check Indicators
Select: Change Check  Maintain Templates
Indicators
Transport
Transaction Code Menu Path Purpose
SCCL Tools --> Administration --> Local client copy (within one system,
Administration --> Client between 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
Administration --> Client different systems) Data exchange using a
Administration --> Client data export at operating system level.
Transport --> Client Export
<none> Tools --> Administration --> Mass transport of roles
User Maintenance --> Roles -->
Environment --> Mass
Transport
<none> Tools --> Administration --> Upload/Download of Roles
User 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 --> Maintain system profile parameters.
Configuration --> Profile (auth/no_check_in_some_cases = Y). .
Maintenance
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
Development --> Other Tools --> screen 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 Authorizations
System
SECR*  <none> Audit Information System

Table maintenance
Transaction Code Menu Path Purpose
SM30 System --> Services --> Table Create table authorization groups
(Tables Maintenance --> Extended Table (V_BRG)
V_BRG, Maintenance Maintain assignments to tables
V_DDAT) (V_DDAT)
Table Group
Transaction Code Menu Path Purpose
SE43 ABAP Workbench --> Development --> Other Maintain (Display) Area
Tools --> Area Menus Menus

R/3 Security- Audit Check

There comes a time when you have to deal with auditors. I have put together a check list
to go through. If this is a new implementation you should go through this and may be you
can impress your boss.
If you have any doubts as to whether or not revisiting your SAP infrastructure security is
worth your while, take this short test and see how well your SAP systems security now
fares.... follow the link
R/3 Security- Audit Check
If you have any doubts as to whether or not revisiting your SAP infrastructure security is
worth your while, take this short test and see how well your SAP systems security now
fares:
1. Launch your SAP GUI, enter “066” as client, “EARLYWATCH” as username, and
SUPPORT” as password. Were you able to log in? If you could not log in, give yourself a
passing grade for this first test question. Your inability to log in means that either you
have successfully changed one of the known passwords (SUPPORT) of a standard SAP
username (EARLYWATCH), or you have locked this username. If you were able to log
in, give yourself a
failing grade for this question. Logging in under these conditions means that one of the
basic security measures at the presentation and application level was not performed, and
therefore any person with access to this SAP system can log in using this known
username, which, while not a full-privileged one, has enough authorizations to perform
certain functions that could be considered risky.
2. Walk over to a colleague’s workspace and try to run the SAP GUI from that person’s
PC. Could you do it? If you could not run the SAP GUI, you pass this test question. Your
inability to run the SAP GUI means that your colleague had basic security measures —
something as simple as having a password protected PC or screen saver — implemented
at the presentation level. If, on the other hand, you or anyone can freely access the
applications installed on any PC, it means that someone could use this gateway for
unwanted actions, or even fake the origin of a security attack.
3. Do you use SAP shortcuts to quickly access the most frequently used transactions or
reports? When you create a shortcut, does it allow you to store the password? If it does
not, run the REGEDIT (Registry Editor) program, search for the key
“HKEY_CLASSES_ROOT\ Sapgui.Shortcut.File\Security”, and set EnablePassword to
a value of “1”. Exit the Registry Editor and try again to create a shortcut. Now can you
create a shortcut with the password stored in the definition? If you initially were not able
to create a shortcut with a stored password,
or you were unable to edit the registry at your Windows workstation, give yourself a
passing grade. However, if you were able to store the password in the shortcut or edit the
registry, then your workstation may not be correctly protected, and you may have a
security problem at the presentation level.
4. If you are an R/3 user that has either SAP_ALL or S_A.SYSTEM privileges, run
report RSUSR009 using standard transaction SE38 or SA38. This report can help
security or system managers discover users with so-called “critical authorizations”. You
may be surprised to learn just how many people have access rights to critical
authorizations. If you find too many individuals who have been granted these privileges,
or discover some surprising or suspect listings as the result of this report, it means
security measures at the application level have not been completely implemented.
5. Log in at the operating system level as user “<sid>adm”. If your database is Oracle,
run svrmgrl (on UNIX systems) or svrmgr30 (on Windows NT). At the prompt enter
“connect internal”. Alternatively, try to connect as user “SAPR3” with password “SAP”
(“connect SAPR3/SAP”). Were you able to connect? Who else can do this? In other
words: Do many
people know the privileged username and password at the operating system or database
level? If this is the case, you may have a serious security problem because standard
usernames and passwords of Oracle and other database engines are well known, and
accessing the database at this level leaves your system highly exposed to the threat of
deleting objects, extracting confidential information, or leaving a database in an
inconsistent state.
6.From an SAP session, run program RSUSR006 (the ABAP report that shows
unsuccessful logon attempts). Do you notice any login attempts that were denied? Many
entries on this report are the result of users making typing mistakes, which is normal and
expected. However, if you discover unexpected users with incorrect logon attempts, your
systems might have been intentionally attacked. This report is included within the basic
set of monitoring and security auditing tools. If you don’t use this and/or similar reports
regularly, give yourself a failing grade here.
7. Copy one of your regular R/3 users (like a financial clerk or a warehouse operator) to a
test user. Log in as this test user. Can you run transactions STMS, SA38, PFCG, and
SU01? If you can run these or similar transactions as a regular user, you have a security
breach at the application level, since regular users should not normally be allowed to
perform operations that are meant to be performed by Basis administrators and/or User
administrators. If your regular users cannot execute these types of transactions, give
yourself a passing grade — otherwise you have a serious security problem at the
application level.
8. Can regular users add or edit system entries when using SAPLOGON? If edit
functionality is disabled, can users edit the SAPLOGON.INI file and change the key
“NoEditFunctionality” to “0”? If this is possible and you work in a company with many
SAP systems, give yourself a failing grade, because it means that users can freely add
new groups or servers to their SAPLOGON, which might enable them to connect to
unauthorized systems. If, on the other
hand, you use SAPLOGONPad or have protected Edit Functionality, give yourself a
passing grade.
9. Log in to an R/3 system with a user ID that has a very simple “display only” profile
(e.g., the profile S_A.SHOW). Then run transaction SE16 and enter “USR02” as the table
name. Can you display this table? Can you download it (System → List → Save →
Local file)? If a user with a “display only”  profile can display and download the table
contents, give yourself a failing grade. USR02 is the table that contains master user logon
data, and although not easy, it is possible for a technical expert with access to an SAP
system to use this table for discovering (cracking) passwords. This means there is a
security problem at the application and the presentation level.
10. Did you ever look at transactions SM19, SM20 (Security Audit Log), or SECR (Audit
Info System)? Maybe you don’t even have them enabled. If you don’t know about these
and other  similar transactions (like SUIM), give yourself a failing grade. These are core
control and auditing transactions that can help you verify the status of your security.
Security logging
and auditing operates at every layer of a security infrastructure, and therefore is a basic
mechanism to measure your infrastructure elements’ compliance with a security policy.
Did you get any failing marks, or did you pass all the tasks with flying colors? Even if
you got a perfect score, don’t walk away just yet! I made this test very, very simple.
Things like remote administration and debugging of ITS servers, password crackers, and
network sniffers have not been factored into this list, not to mention network services and
firewall configurations. Given their client/server architecture, SAP systems include many
components that exchange information with both SAP and non-SAP components alike.
Each of the elements needed for the  communication and exchange of information
constitutes a layer of the SAP security infrastructure. Only with a  comprehensive
security plan that encompasses all tiers of the SAP infrastructure can you ensure that you
set in place a security policy that protects the most valuable assets of your company from
intentional or unintentional, and external or internal attacks.

If you feel I should add more email me admin@sapecc.com

SAP R/3 user ID SAP* and other system user id  has been adequately secured.
SAP R/3 user ID SAP* and other system user id  has been adequately secured.
Performed the following steps to confirm that user ID SAP* has been adequately secured:
 Verified whether default password of SAP* was changed in all production 
clients:
Execute transaction code SA38,  and run report RSUSR003.
 Reviewed RSUSR003 report to verify that the parameter
login/no_automatic_user_sapstar is set (value =0). 

Who has sap_all andsap_new
Execute transaction code SUIM
Click on “User”
Click on “List of users according to complex selection criteria”.
Click on “By user profiles”.
Enter SAP_ALL in the Profile field and click Execution button
Execute transaction code SUIM
Click on “User”
Click on “List of users according to complex selection criteria”.
Click on “By user profiles”.
Enter SAP_NEW in the Profile field and click on the Execution  button

Risk: The SAP_ALL profile grants a user full/complete access to all functions in the
SAP system and has the  potential to be misused.  The SAP_ALL profile should only be
assigned to a minimal number of users on the system.

The default SAP R/3 passwords for DDIC, SAPCPIC and EarlyWatch (in client 066)
have been changed and access restricted to the super user.
Performed the following procedures to verify that the default SAP R/3 passwords for
DDIC, SAPCPIC and EarlyWatch have been changed and access restricted to the super
user ID:
 Execute transaction: SA38
 Program: RSUSR003
 Default passwords that should be changed:
 SAP*                        - PASS
 DDIC                       - 19920706
 SAPCPIC                - ADMIN
 EarlyWatch              - SUPPORT
Risk: SAP comes supplied with a number of default user IDs, all of which have default
passwords.  The passwords to these IDs are well known, and therefore if they are not
changed, the IDs could potentially be misused

To review any passwords which are not allowed for users to use:
Execute transaction code: SE16
Table name: USR40
Risk: Table USR40 is used to prevent users from using a list of commonly guessed
passwords.  If it is not used it increases the possibility that users could select trivial
passwords or you can use profile parameter to do this
 
The SAP R/3 system profile parameters have been set to appropriate values.
Performed the following procedures to determine whether the SAP R/3 system profile
parameters have been set to appropriate values: click here for more deail on profile
parameter
There are two ways in which you can define your choice of user passwords:
 You can use the system profile parameters to assign a minimum length for the
passwords and define how often the user has to set new passwords.
 Invalid passwords can be entered in the table of reserved passwords, USR40. This
table is maintained with transaction SM30. The entries can also be made
generically:
- ? denotes one character
- * denotes a character string
The SAP System also has pre-defined password rules. You can control passwords with
profile parameters login*
login/min_password_lng  - Defines the minimum allowed length of a new password.
login/password_expiration_time - Defines the expiration period of the password
login/fails_to_user_lock - Locks the user after the specified amount of wrong logon
attempts; user is unlocked at midnight if the login/failed_user_auto_unlock parameter is
set
login/fails_to_session_end  - Ends the user.s session after the specified amount of wrong
logon attempts
login/disable_multiple_gui_login - Refuses multiple logon of users; only users listed in
login/multi_login_users are allowed for multiple logon
login/min_password_diff - Defines the minimum number of different characters
between old and new password including rotation
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 passwords reset
login/min_password_digits/_letters/_specials - Defines the minimum number of
digits/letters/special characters in the password
login/disable_password_logon and login/password_logon_usergroup
Controls the deactivation of password-based logon
login/disable_cpic -Refuses incoming connections of type, CPIC
rdisp/gui_auto_logout - Defines the time for automatic SAPGUI logout
login/no_automatic_user_sapstar Controls the SAP* user
Default password, and protecting SAP*
Starting with installations of SAP Web Application Server release 6.10 and higher, the
passwords of SAP* and DDIC are selected during the installation process.
Use the User Information System or report RSUSR003 to monitor the passwords of all
predefined users.
If possible, make use of the profile parameter, login/no_automatic_user_sapstar.
If you create a new client the default password for SAP* is pass. If you delete SAP*
userid, logon is possible with SAP* /pass.
The DDIC user maintains the ABAP dictionary and software logistics. The system
automatically creates a user master record for user SAP* and DDIC in client 000 when
the SAP System is installed. This is the only user who can log on to the SAP System
during a release upgrade.

Do not delete or lock user DDIC because it is required for certain installation and set-up
tasks. User DDIC needs extensive authorization. As a result, the profile SAP_ALL is
allocated to it. The users, SAP* and DDIC, should be assigned to user group SUPER to
prevent unauthorized users from changing or deleting their user master record.
Default clients in an SAP System:
• Client 000 is used for customizing default settings. SAP imports the customized
settings into this client in future SAP System releases during the upgrade process
or even with support packages. Client 000 should not be used to customize data
input or development.
• Client 066 is used by the SAP EarlyWatch service and should not be used or
deleted by the customers.
Please refer to new password rules
 

The production system has been set to productive.

The production system has been set to productive.

To verify that the company codes utilized in the SAP R/3 systems are set to productive.
There are various company codes that come as default within SAP. This is to ensure that
only the company codes that are being used should be checked and set-up as productive.
SOX team/ Security team should perform the following steps:
 Execute transaction code: OBR3 
Review “Productive” column and ensure applicable global settings have not been
checked off.
 The production client settings have been flagged to not allow changes to programs
and configuration.
Performed the following steps to verify that production client settings have been flagged
to not allow changes to programs and configuration:
 Execute transaction code SCC4 (all clients) and SE06
 Double click on the applicable production client.
 Verify that changes to client dependent and client independent objects are not
allowed and that the client is set to productive.

Access Restriction:  SCC4 and SE06

Access Restriction:  SCC4 and SE06

Transaction codes SCC4 and SE06 are critical transactions which can be used to prevent
direct changes being made to the production system.   If these transactions are not
appropriately set there is a risk that unauthorized changes may be made directly in the
production system, without going through the appropriate change management process.
Performed the following steps to verify that the ability to make changes to client and
system settings is restricted and access privileges are appropriately assigned based on job
responsibilities. Perform the following steps
Query 1
 Execute transaction code: SUIM
 Select User by complex criteria
 Authorization object: S_TCODE
 Transaction code value: SCC4
 Authorization object:  S_TABU_DIS
 Activity: 02 and 03
 Authorization Group: SS
 Authorization object:  S_TABU_CLI
 Indicator for cross client maintenance: X
Query 2
 Execute transaction code: SUIM
 Authorization object: S_TCODE
 Transaction code value: SCC4
 Authorization object:  S_ADMI_FCD
 System Administration Function: T000
 Authorization object:  S_CTS_ADMI
 Administration task: INIT
Query 3
 Execute transaction code: SUIM
 Authorization object: S_TCODE
 Transaction code value: SE06
 Authorization Objects: s_transprt
 Activity Value: *
 Request Type: *
 Authorization Objects: s_cts_admi
Administration Task:  RELE
S_DEVELOP is secured
S_DEVELOP is secured
Only the SAP R/3 super user has S_DEVELOP authorization object with critical activity
values in the production system.
Performed the following procedures to verify that only super user has S_DEVELOP
authorization object with critical activity values in the production system:
Query
o Execute  transaction code: SUIM
S_TCODE: SE38
Authorization Object: S_DEVELOP
All fields: “*”

Risk: The risk here is that users who have this access, have the ability to perform
development related functions in the production system.  Such access should be
restricted to developers in the development system only.
 

Change management is secured and controlled

Change management is secured and controlled

Performed the following procedures to ensure that SAP R/3 change management
environment provides a secure and controlled structure for software changes. 

Start the transaction SE16, enter the table name and choose option Display.
 TCESYST               Environments
Inspect the table TCESYST which details the various environments.
 TCETRAL               Cross Transports
Inspecte the table TCETRAL, note various transport layers. Reviewed transport
layers .
 TCEDELI                   Recipient systems
Inspect the table TCEDELI which details with SAP systems receive released
transports.

Transport access to production is restricted

Transport access to production is restricted

Performed the following procedures to verify that the ability to make transports to
production is restricted and access privileges are appropriately assigned based on job
responsibilities:

Risk: The risk here is that users who have this access, have the ability to move code from
the development environment to the production environment.  

Executed transaction:  SUIM

Authorization object: S_TCODE
Transaction code value: SE11
Authorization Object: S_TRANSPRT
Activity value: 01 OR 43
Request Type: DTRA OR CUST

Developer access in production

Developer access in production

The ability to make changes to the SAP R/3 Data Dictionary is restricted and access
privileges are appropriately assigned based on job responsibilities.
Performed the following procedures to verify that the ability to make changes to the SAP
R/3 Data Dictionary is restricted and access privileges are appropriately assigned based
on job responsibilities:
Executed transaction:  SUIM
o Authorization object: S_TCODE
o Transaction code value: SE11
o Authorization object: S_DEVELOP
o Activity value: 01 or 02
o Other fields:  “*”
Risk: The risk here is that users who have this access, have the ability to maintain the
SAP database (data dictionary). 
 
Identify users who can do development in Production
Execute  transaction code: SUIM
S_TCODE: SE38
Authorization Object: S_DEVELOP
Activity:  02 and 03
All fields:  LEAVE BLANK 
All fields:  “*”  
Risk: The risk here is that users who have this access, have the ability to perform
development related functions in the production system.  Such access should be restricted
to developers in the development system only. 
Execute  transaction code: SUIM
S_TCODE: SE38
Authorization Object: S_DEVELOP
Development Object ID: PROG
Activity: 02
All fields: “*” AND LEAVE BLANK 

Risk: The risk here is that users who have this access, have the ability to perform
development related functions in the production system.  Such access should be restricted
to developers in the development system only. 

Execute  transaction code: SE16

Table Name: DEVACCESS

Risk: Developer key is required along with the open system to make changes within
production.
Change critical number range is restricted
Change critical number range is restricted. (company code, charts of accounts etc.)
Performed the following procedures to verify that the SAP system appropriately restricts
the ability to change critical number ranges (i.e., company codes, chart of accounts,
accounting period data, etc.).
Execute transaction code SUIM
Authorization object: S_TCODE
Transaction code value: SNRO
Authorization object: S_NUMBER
Activity: 02
Number of number range:  “*”
Risk: The risk here is that users who have this access, have the ability to maintain critical
number ranges. 
 Custom tables has authorization group
Custom tables has auth group

Performed the following procedures to verify that all customized SAP R/3 tables have
been assigned to the appropriate authorization group:

Executed transaction code: SE16

Table name: TDDAT
Table name: Z*, Y*
Risk: If tables are not assigned to authorization groups it is not possible to appropriately
control direct access to tables.
 Locking of sensitive systems transaction codes
Locking of sensitive systems transaction codes in Production environment.
Query
The authorization to lock and unlock transaction codes should only granted to selected
few users. This also applies to costumer developed tcodes provided they are entered in
table TSTCA through transaction code SE93
Do check using the following report in production who has this access.
Execute transaction: SM01
OR
Execute transaction: SE16
Table Name: TSTC
C info field: 20 to 20

Risk: SAP recommends that certain sensitive transactions be locked in the production
system to prevent accidental or malicious use.  The risk therefore is that these
transactions be accidentally run, or run with malicious intent.
Query
Generated a list of users who have access to lock/unlock transaction codes.
o Execute transaction code: SUIM
o S_TCODE: SM01
o Authorization object:  S_ADMI_FCD
Field value: TLCK (lock/unlock transactions)

Risk: These users have the ability to lock or unlock sensitive transactions which should
not be run in the production system.

BDC user types should has only required access

BDC user types should has only required access. Don't need sap_all

To verify that BDC users are assigned only authorizations to perform the required task,
performed the following steps:

Execute transaction code SUIM

Click on “User”
Click on “List of users according to complex selection criteria”.
Click on “By user ID”.
Then execute by clicking on the small green check mark.
Click on “Other view” twice to display the user type for all listed user IDs.
Risk: The risk here is that these IDs have been provided “super user” access rights,
which is excessive based on the typical needs for these IDs.   Such IDs could potentially
be misused.
 
An overview of jobs scheduled in the SAP R/3 system is performed regularly.
Performed the following steps to produce a listing of batch input sessions:
Execute transaction code SM35
Enter a * in the “Session name” field and “Created By” field.
Click on “Incorrect” Tab.

Risk: If batch sessions are not monitored on a regular basis, there is a risk that important
batch sessions will contain errors or not be completely processed and therefore
processing of critical financial information will not be complete and the issue will not be
identified on a timely basis

Run Program in the back ground

Run Program in the back ground
By default user is allowed to schedule reports for background processing, but cannot
release. Authorization for to release jobs is controlled by S_BTCH_JOB. Activity RELE
is needed to release jobs. Activity PROT is required to display log.
The other authorization like delete change andmove should only be assigned to the batch
adminstrator.
S_BTCH_ADM should be granted to batch administrator and not to all the users. This is
a critical authorization can release other users jobs. Controls access to jobs in all clients
of a system.
S_BTCH_NAM can be used to schedule jobs under a different user id. Never give * as
this would allow the user to start batch jobs under any user id.
To check who all have acces to this production follow the instruction below
Execute transaction code SUIM
S_tcode: SM36/SM37
Authorization Objects: S_BTCH_JOB, S_BTCH_NAM
Job Operations:  RELE:
Summary of jobs for a group: “*”
Background user ID.: “*”

Risk: The risk here is that users who have this access, have the ability to run programs
directly in the background, bypassing transaction level security in SAP, and could
potentially run programs /transactions they are not explicitly authorized to run.
Batch input - SM35
Batch input transaction code SM35 needs authorizationforobject S_BDC_MONI. You
can restrict the privileages tocertain sesssion byentering the respective session name or
name range. If you use name range then naming convetion should be used properly.
Execute transaction code SUIM
S_tcode: SM35
Authorization Objects: S_BDC_MONI
Batch Input monitoring activity: “*”
Session Name:  “*”

Risk: The risk here is that users who have this access, have the ability to process batch
transactions without being explicitly authorized to do so.

Changes to critical SAP R/3 tables are logged

Changes to critical SAP R/3 tables are logged and management regularly reviews
the logs.

Run transaction SE16, table DD09L and noted that tables have been selected for logging. 

Query

Execute transaction code:  SUIM

S_TCODE:  SE01
Authorization object:  S_TRANSPRT
Activity:  02
Field Object in Workbench Organizer: UPGR

Risk: The risk here is that users who have this access, have the ability to transport
matchcodes into the production system.  Such access should be restricted to basis
administrators only.
 
Scheduling and Monitoring Batch jobs
Scheduling Batch jobs
By default user is allowed to schedule reports for background processing, but cannot
release. Authorization for to release jobs is controlled by S_BTCH_JOB. Activity RELE
is needed to release jobs. Activity PROT is required to display log.
The other authorization like delete change andmove should only be assigned to the batch
adminstrator.
S_BTCH_ADM should be granted to batch administrator and not to all the users. This is
a critical authorization can release other users jobs. Controls access to jobs in all clients
of a system.
S_BTCH_NAM can be used to schedule jobs under a different user id. Never give * as
this would allow the user to start batch jobs under any user id.
To check who all have acces to this production follow the instruction below.
Performed the following steps to verify which users have the ability to change the SAP
R/3 job schedule:
Execute transaction code SA38, RSUSR002
S_tcode: SM36 (Schedule)
Authorization Object: S_BTCH_JOB
Job Operations:  RELE
Summary of jobs for a group: “*”, *
Risk: The potential risk here is that users who have this access, have the ability to run
programs directly in the background, bypassing transaction level security in SAP, and
could potentially run programs or transactions they are not explicitly authorized to run.

Monitoring Batch jobs

Run transaction SM37 to check if any of the jobs that had been during the last year are
still active.
Risk: If jobs are not monitored on a regular basis, there is a risk that jobs will not run to
completion and therefore processing of critical financial information will not be complete
and the issue will not be identified on a timely basis

Access to run reports should be restricted.

Access to run reports should be restricted.

Execute transaction code SUIM

S_tcode: SA38
Authorization Objects: S_PROGRAM
User action ABAP  program:  SUBMIT ( foreground and background)
Authorization Group: *, “*”
Risk: The risk here is that users who have this access, have the ability to run programs
directly, bypassing transaction level security in SAP, and could potentially run
programs /transactions they are not explicitly authorized to run.

Execute transaction code SUIM

S_tcode: SA38
Authorization Objects: S_PROGRAM
User action ABAP  program:  EDIT (maintain attributes, text elements, ABAP/4 utilities
to copy and delete programs)
Authorization Group: *
Risk: The risk here is that users who have this access, have the ability to maintain
program attributes.

Critical and custom SAP R/3 tables are restricted.

Critical and custom SAP R/3 tables are restricted.
 Execute transaction SUIM
 Authorization Object: S_TCODE
 Transaction Code:  SM31 (enhanced tables maintenance)
 Authorization object:  S_TABU_DIS
 Activity:  02 AND 03
Risk: The risk here is that users who have this access, have the ability to maintain table
data directly in the production system.  This includes transactional, masterfile, security
and configuration data.
Execute transaction SUIM
Authorization Object: S_TCODE
Transaction Code:  SM31
 Authorization object: S_TABU_DIS
Activity: 02 AND 03
Authorization Object:  S_TABU_CLI 
 
Identify if custom transactions have references to authorization objects.
 Execute transaction code: SE16
 Table name: TSTCA / TSTC
 TCODE:  Z*
Check table TSTCA and verified that no Z transactions existed. Verified in table TSTC
that the majority were secured by Authorization objects.  Since all transactions are
secured by S_Tcode this control is still effective.

SOX/SOD:::

Sarbanes-Oxley
Sarbanes-Oxley has become the ad hoc standard for financial transparency, trust, and
corporate accountability.  While mandatory for all publicly-owned companies, Sarbanes-
Oxley is also becoming a best practice for all types of companies who wish to identify
with good governance practices. 
A significant amount of attention is currently focused on Section 302 (Disclosure) and
Section 404 (Internal Controls).  Sarbanes-Oxley Sections 302 and 404 are designed to
ensure information required to be disclosed is initiated, processed, recorded, and
reported, and that management has assessed the effectiveness of internal controls
regarding the reliability of financial reporting. 
CEOs and CFOs of public companies must:
 Certify that they have reviewed financial statements and each annual or quarterly
report.  
 Certify that each such report fairly represents the company's financial condition.  
  Certify that they have established and are maintaining internal controls  
 Ensure the effectiveness of such internal controls every quarter.  
 Address significant changes in internal controls or other factors that could
significantly affect such controls.  
 Identify corrective actions taken regarding deficiencies/weaknesses in controls.  
 Disclose any significant deficiencies in internal controls and/or any fraud
involving persons with a significant role in upholding such controls
Tool Comparison:

Feature / Attribute Approva Bearing CSI Virsa

Point Systems
Production Installations 5 4 4
Product Stability / Maturity 4 3 2
Support 3 5 3
Support Separation of Duties 5 3 3
roles/responsibilities identification and
resolution
Support ease of implementation 5 3 3
requirements and integration to SAP 4.7
Support monitoring (after the fact) and 5 3 3
audit of compliance to Sarbanes-Oxley
Section 404
List of critical transactions such as 5 4 4
change security systems, change user
accesses, limitation to system and
transaction access
Rules and roles can be enforced and 5 5 5
customized at high level
Rule sets and high level rule definition 5 5 5
Workflow and approvals functionality 5 0 0
Cross platform conflicts identification 5 0 0
Extend rule sets to include non-system 5 0 0
controls for SoD
Drill down to role definition and change 4 4 4
configuration to eliminate SoD conflict
Security software does not impact 5 4 4
performance and integrity of ERP
system
Technical Support Rating 5 3 3
Established User Group 0 0 0
Initial Software Investment Cost Expensive Cheap Cheap Expensive
Annual Maintenance/Support Fees Expensive Cheap Cheap Expensive
 Additional Hardware Required Yes No No
Implementation Costs 5 2 2
End-User Training Required Required Required Required Required
To Setup Product Demonstration 4 3 3
Existing Customer References 4 3 2
Rating 5 is good and 0 is poor. This is my personal opinion.

Synaxion provides you with integrated software solutions for SAP for both Governance,
Risk & Compliance (GRC) as well as Business Performance Management (BPM), giving
you the opportunity to optimize your business processes and SAP controls in an efficient
manner. Synaxion has developed content packs to monitor the following areas:
 Purchase to Pay
 Order to Cash
 Finance to Report
 User Activity
 Segregation of Duties
Organizations using the Synaxion software solutions have achieved key business
improvements such as a reduction of Segregation of Duties (SoD) conflicts, open items
on suspense accounts and SAP license costs. By exception-based monitoring of your SAP
controls and reporting of deviations to the desired outcome, the Synaxion software
solutions enable you to optimize your key business processes.

SOD Matrix::
FI /GL SoD Matrix - This link gives you Finance / General ledger conflicts.
MM SoD Matrix - This link gives you Material Master conflicts.
SD SoD Matrix - This link gives you Sales related conflicts.
HR SoD Matrix - Link to HR related conflicts
PP conflicts - Link for PP conflicts
QM conflicts - Link for QM conflicts
CO sensitive transactions - contributed by Florence Auala
High level view of Conflicts - This link provides all conflicting t-codes. This is a excel
spread sheet
 Conflicts by business process
AP Invoice Verification and AP Payment Runs/ Clearing
Customer Master and Sales Order
Delivery Goods Issue and Cash Receipts/ AR Credit Memos
Delivery Goods Issue and Customer Master
Delivery Goods Issue and Sales Order
Purchase Order and  Vendor
Purchase Order and AP Invoice Verification
Purchase Order and AP Payment Runs/ Clearing
Purchase Order and Receiving
Receiving and Inventory Adjustments
Sales Order and Cash Receipts/ AR Credit Memos
Vendor and AP Invoice Verification
Vendor and AP Payment Runs/ Clearing

Compliance Calibrator Install ::

TCode Risk Description

   
CA87 Mass Replace Work Center
CAT6 Human Resources
CL04 Delete Class
F.34 Credit Limit Mass Changes
F.80 Mass Reversal of Documents
F044 Vendor Archiving
FI12 Change House Banks/Bank Accounts
IP30 Run Date Monitoring
LN08 Number range maint.: LVS_LENUM
MMPV Close Periods
MMRV Allow Posting to previous Period
PA20 Display HR Master Data
PA30 Maintain HR Master Data
PA70 Fast Entry
PA97 Compensation Administration - Matrix
PFCG Role Maintenance - System integrity, stability at risk
RZ04 Maintain SAP Instances
SA38 ABAP Reporting -Can run programs not protected appropriately
SARA Archiving Management - Should be restricted to Archive Admin
SCC1 Client Copy - Special Selections
SCC4 Client Admin.  - System stability & integrity at risk
SCC5 Delete Client - System stability at risk
SCC6 Client Import - System stability & integrity at risk
SCC9 Remote Client Copy - System stability & integrity at risk
SCCL Local Client Copy - System stability & integrity at risk
SE01 Transport Organizer - System stability & integrity at risk
SE11 Data Dictionary Maint. - System stabiltiy & integrity at ris
SE13 Maintain tech tables settings - System stabilitiy at risk.
SE16 Data Browser - Exposure to confidential information
SE37 Function Builder
SE38 ABAP Editor - System stabiltiy & integrity at risk
SM01 Lock Transactions - System stabiltiy at risk
SM02 System Messages - Should be restricted to System Admins only
 SM30 Table Maintenance - System integrity  & stability at risk
SM49 Execute OS commands - System stability at risk
SM50 Work Process overview - System stability at risk
SU01 User Maintenance - Should be restricted to User Admins only
SU02 Profile Maintenance - System stability and integrity at risk
SU03 Maintain Authorizations
SU05 Maintain Internet user
SU10 User Mass Maint - System stabilty at a very high risk
SU20 Authorization Object fields
SU21 Authorization Objects
SU24 Maintain Assignment of Authorization Objects
SU25 Profile Generator Upgrade and First Installation

Enterprise Portal

SAP Enterprise Portal offers users a single point of access to all applications,
information, and services needed to accomplish their daily tasks. Links to back-end and
legacy applications, self-service applications, company intranet services, and Internet
services are all readily available in the user’s portal.
 
Portal Infrastructure Architecture overview -
Follow the link to learn more about how to set up external facing portal and how to
configure reverse proxy on apache server :
SAP Enterprise Portal offers users a single point of access to all applications,
information, and services needed to accomplish their daily tasks. Links to back-end and
legacy applications, self-service applications, company intranet services, and Internet
services are all readily available in the user’s portal.
 
Portal Architecture overview
The security features of SAP Enterprise Portal include:
•Authentication – Confirms or denies user identity through user ID and password,  This
can be done by using the existing LDAP Server
•Authorization – Enforces role-based authorization for all content under the
administrative control of the portal and prevents unauthorized access.
If you plan to have external users (internet users ) access your portal or backend system.
Have a proxy server installed and place it in DMZ. Follow the link below at the bottom of
this page for installing proxy server. The advantage is you don’t have your portal server
facing the world, and disadvantage is that you have additional hardware.
I prefer proxy server for internal users also.  I can hide the port number from users.
 
Single Sign-On (SSO)  Single Sign-On (SSO) provides secure access to multiple systems
without requiring users to reenter ID and password information for each application. In a
portal environment, an SSO mechanism maps portal authentication information to each
application for which a user holds predefined access permissions. This reduces user
frustration, providing enhanced interaction with enterprise resources via the portal. You
can have SSO enable for Portal using third party tool like Siteminder from Netegrity.
This will use Windows authentication. This means once you sign on to your windows
operating system,you don’t have to sign on to portal again.
Then you have to enable SSO between Portal and R3 system so that you don’t have to
sign on to R3 or any other SAP system if you are accessing data from any of these
systems. This can be done using SAP logon. Logon ticket, verifies the digital signature,
and extracts the appropriate user ID.
If you plan to have external users access your portal / backend system. You can have
additional layer of security by giving them secureID or digital certificate.
Apache Configuration for J2EE Web Applications
This document explains and describes how to set up the Apache Web server for use with
the SAP J2EE Engine. This example is based on a Red Hat Linux installation and is
transferable to all other operating systems. It will give you instructions how to configure
the Apache with Proxy Mode The backend used in the tests was a SAP J2EE Server
running Enterprise Portal 6.0. .
Apache Configuration for
J2EE Web Applications
About this document
This document explains and describes how to set up the Apache Web server for use with
the SAP J2EE Engine. This example is based on a Red Hat Linux installation and is
transferable to all other operating systems.
It will give you instructions how to configure the Apache with Proxy Mode
The backend used in the tests was a SAP J2EE Server running Enterprise Portal 6.0.
Recommended Landscape
In general the Apache Webserver should be located in the DMZ. The SAP J2EE Server
itself is located in the Intranet (2.1) or in the DMZ-2 (2.2), which can be protected by an
additional firewall. Further scaling-option like introducing a separate persistence-server
can be done independently from the Apache Web server.

 
Requirements
Software
First of all you need the software, which implements the Reverse Proxy functionality. In
the scenario described in this documentation we have chosen the Apache Web-Server,
which is first of all a Web-Server, but also offers the REVERSE-PROXY functionality.
In the scenario we want to set up, the Apache Web-Server has no other duty than
forwarding the request from the client to the SAP J2EE Server and of course forwarding
the response from the SAP J2EE Server to the client. The main advantage is, that the
client doesn’t know anything about the translations and forwarding–mechanisms at all
and the actual SAP J2EE Server is not exposed to the client directly.
The Apache-Web-Server is available on several platforms:
 Windows 2000
 Unix / Linux
 Free BSD
 and more (see http://httpd.apache.org for more information)
We assume, that if the Reverse Proxy is installed under Unix/Linux a higher security -
level can be reached, because an attack would first be blocked by an Unix/Linux-
environment and only those, who passed this hurdle can then try to attack the Windows
2000/IIS-based Internet Sales-Installation. At least the Knowledge of two operating
Systems are necessary then.
Hardware
The Reverse Proxy should be installed on a separate physical machine. The one and only
issue of the box is to run the Apache-Web-Server including the Reverse Proxy
functionality. The Apache Web-server can also be used as a Web-server for your Catalog
images.
Normally the requirements for this are not too high, but especially when SSL has to be
enabled, the server needs more processor-power. Every single request has to be encrypted
from the Reverse Proxy, then the encrypted request has to be processed by the Reverse
Proxy. After that, the new request has to be decrypted again and forwarded to the SAP
J2EE Server.  We can’t specify that more explicitly, for example by presenting concrete
figures in this paper.
Recommended Apache Versions
In order to ensure proper stability using the described configurations we recommend the
following Apache versions.
Apache 1.3 Use at least version 1.3.19. We recommend using version 1.3.27
Apache 2.0 Use at least version 2.0.40. We recommend using version 2.0.48
 
Apache Configuration using Reverse Proxy
What is a reverse proxy?
A reverse proxy (also called Proxy Gateway) is used to separate your local web from the
outside world (Internet).
Placing a reverse proxy in the DMZ protects the SAP J2EE Server from malicious attacks
as it provides an additional barrier in front of the SAP J2EE Server. As the proxy
gateway does not contain any sensitive information, it has less exposure risk than the
actual Web server.
Another advantage of this landscape is that no ports have to be opened beyond the inner
firewall. All Java-based Application components are in the secured network and a proxy
gateway can add a another security layer to the SAP J2EE Server.
Picture 1: Reverse Proxy Scenario
Reverse-Proxy settings  
Perform these steps to configure the Reverse Proxy:
Stop the Apache Web-server
            Open the configuration file “httpd.conf” from the Apache directory with an editor
and apply the following changes:
Search for #LoadModule proxy_module modules/mod_proxy.so and remove the
comment sign (#) at the beginning of the line.
Search for #AddModule mod_proxy.c and remove the comment sign (#) at the beginning
of the line.
Note: if you don’t see these modules then you have to load these modules
Enabling Apache Proxy Modules
Those directly concerned with proxying include:
 mod_proxy: The core module deals with proxy infrastructure and configuration
and managing a proxy request.
 mod_proxy_http: This handles fetching documents with HTTP and HTTPS.
 mod_proxy_ftp: This handles fetching documents with FTP.
 mod_proxy_connect: This handles the CONNECT method for secure (SSL)
tunneling.
 mod_headers: This modifies HTTP request and response headers.
Building Apache for Proxying
The above are all included in the core Apache distribution. They can easily be enabled in
the Apache build process. For example:
$ ./configure --enable-so --enable-mods-shared="proxy \
proxy_http proxy_ftp proxy_connect headers"
$ make
# make install
Of course, you may want other build options too, and you could just as well build the
modules as static. If you are adding proxying to an existing installation, you should use
apxs instead:
# apxs -c -i [module-name].c
noting that mod_proxy itself is in two source files
(mod_proxy.c and proxy_util.c).
Edit the httpd.conf. The VirtualHost section should be configured as follows:
For a non-SSL connection add the following lines to the end of the configuration file:
<VirtualHost 10.10.10.10:80>
ProxyPreserveHost On
ProxyPass /irj/ http://<your hostname>:50000/irj/
ProxyPassReverse /irj/ http://<your hostname>:50000/irj/
ErrorLog logs/<your hostname>.80.error.log
CustomLog logs/<your hostname>.80.custom.log common
</VirtualHost>
Restart Apache server Using apachectl start

The security features of SAP Enterprise Portal include:

Authentication – Confirms or denies user identity through user ID and password. This
can be done by using the existing LDAP Server. Follow the link to learn how to
configure a LDAP. A local database can also be used for authentication. Users are created
and stored locally in SAP Portal database.
User creation in SAP Portal (locally)
Assigning role in SAP Portal

Authentication
Good thing about portal is that user can be authenticated against LDAP. I have tried this
with MS Active Directory, and it works like a champ. It supports both Flat Hierarchy,
and Deep Hierarchy. Please check with your LDAP admin what kind of Hierarchy your
company is using. Do ask him/her to create a read only user which can be used to
configure you LDAP connector. Here are few advantages using LDAP:
1. Don’t have to create user id for portal. Just imagine if you have1000’s of users.
2. One less password to remember, as it will be same as LDAP
3. It is easy to setup.
Then if you don’t have LDAP you can still create local user, which work fine as well. For
our test servers we will be using local users as I don’t have the infrastructure to setup a
LDAP server.
You can use both database as well as LDAP repository for authentication. Generally
company's use database for external users and LDAP for company employee
Connecting Portal to LDAP Data Source.  Make sure you test the connection and if
you have a LDAP account. Try to sign on using that account. You should be able to sign
on and should only get an empty page
To connect to LDAP follow the following steps.
1. Logon to portal
2. System Administration >> System configuration >>UM configuration
3. Go to Data Source tab - By default it is Data source is Database. You can change
this to your corporate LDAP
4. Go to LDAP server and put the LDAP server and user and do check the user path
from your administrator.
5. Test the connection and then save.
6. You are done.
7. You can use a test id to logon and you will see blank page like below

 
Create a Portal user in Database
To create a local user in SAP Portal. Login with a user, who has user administrator role.
You should see user administration tab. Go to users and click on create user.
Fill all the fields shown below and hit create. Don't forget the password

Now I logon using portal1 the initial screen will look like

 
Assigning the user super admin role
Let me make one of the test user portal2 as super admin. All you have to do is assign the
user super admin role. Just like you do in SAP R/3 assign the user sap_all profile.
In portal it works like this. You open the role and add the user(s).
Go to User Administration >Roles .
Select role from drop down and search for super*
Click on edit.

Search for portal* and check portal2 and click Add. Click save to save

 
Now since we have created a super account. Lets go and disable sap*
Go to System Administration> System configuration > UM configuration
Uncheck Enable SAP* user (If you disable the SAP* user, enter a super user ID and
password below)

Save. For the changes to take effect you have to restart portal.
Let's sign on with portal2 and you can see that this user has all the authorization.

Now I will create another user support1, and give just User administration role. Look
how the tabs changed. Each tab is associated with a role. If the user don't have any role
will have no tabs.

Authorization – Enforces role-based authorization for all content under the

administrative control of the portal and prevents unauthorized access.

Web AS Security

User Concept for WEB AS / JAVA

SAP Web Application Server provides following user store:
 User Management Engine (UME)
 Universal Description Discovery and Integration (UDDI)
 Database
By default, the UME user store is set during installation.
The User Management Engine (UME) provides central user administration for all
Java applications. The UME is completely integrated into SAP Web Application
Server Java and is used as the default user store as of SAP Web Application Server
6.40. The UME is integrated into SAP Web Application Server Java as a service.
The UME itself administers users and uses databases, directory services, or the SAP
ABAP user administration to store the data. In the UME, the words data sources are
used to refer to repositories for user data.
To display the active user store, select a Server in the Visual Administrator. In the
Security Provider service, select Runtime → User Management, and choose Manage
Security Stores. In case if it is grayed out, you have to go to change mode. If Activate
User Store is inactive for a user store, this means that the user store that you have just
chosen is already active. If you want to use UDDI instead of the default user store UME,
you can use the described method to change this by choosing Activate User Store for the
UDDI user store.
UME Installation Options
During the installation of an SAP Web Application Server (SAP Web AS), you can
select the following options for setting up the User Management Engine (UME):
SAP Web AS Java (without ABAP)
The UME can be configured so that the ABAP user management of another SAP Web
Application Server ABAP is used.
The UME can be configured so that the database of this SAP Web Application Server
Java is used to store user data.
SAP Web AS ABAP +Java
The UME is configured in such a way that the ABAP user management of this SAP Web
Application Server is used. By default, you have read-only access to the user data in
ABAP user management from the UME.
The communication between the UME and the ABAP user management is performed
with the SAPJSF user. After an installation, this user has the ABAP role
SAP_BC_JSF_COMMUNICATION_RO, which provides read access from the UME to
the ABAP user management. You can obtain write access by adding the role
SAP_BC_JSF_COMMUNICATION. SAP recommends the role
SAP_BC_JSF_COMMUNICATION_RO for this user. You can only configure the use of
a directory service as the data source later. In this case, it is recommended that you use
the database as the data source for user data during the installation
Administration of Users (UME with ABAP User Management as data source)
ABAP Users: transaction SU01
ABAP authorizations and roles: transaction PFCG
Java authorizations and roles (UME roles, security roles): Visual Administrator
and UME administration console. If you are using an SAP Enterprise Portal in this
environment, the user administration is controlled using the portal.

User Administration in Java ::

Config Tool
In the context of user administration, the Config Tool is used to adjust data sources
and to maintain specific properties of the UME. It is only possible to maintain this
data in the Configuration Editor mode. You can change the UME configuration and
property files in this mode
See video for demo
 
UME
The UME provides a browser-based administration interface. You can access this from
the home page of the SAP Web Application Server Java (http://<server
name>:<port>/useradmin.You can perform the following actions there:
• Administration of users
• Administration of groups
• Administration of roles
• Manual replication
• Import/export of users, groups, roles
You can always use the UME console for user administration and assigning
authorizations if the UME uses a directory service or a database as the data source. If you
have selected ABAP user management as the data source for the UME, users can only be
administered using the relevant transactions in the SAP ABAP system. In this case (data
source: ABAP management), you can only assign Java authorizations using the UME
console or the Visual Administrator
Visual Administrator
Sever > Services > Security Provider> Runtime > User Management
ABAP user management is done using SU01 / PFCG
Single Signon to R/3 system from portal ::
Implementing SSO (R/3 / Enterprise portal):
Implementing Single signon for Enterprise Portal and R/3 Backend
Procedure
Download public-key certificate of Portal Server
Use the Keystore Administration tool to download the verify.der file from the
portal.
Set profile parameters
On all of the component system's application servers:

1. Set the profile parameters login/accept_sso2_ticket = 1 and login/create_sso2_ticket =

0 in every instance profile.
Import public-key certificate of Portal Server to component system's certificate list
and
add Portal Server to ACL of component system
Both of these steps can be performed with transaction STRUSTSSO2, which is an
extended
version of transaction STRUST. For detailed documentation on transaction STRUST, see
the
Web Application Server documentation under Security > Trust Manager.
In the SAP System, start transaction STRUSTSSO2.
A screen with the following layout appears

The PSE status frame on the left displays the PSEs that are defined for the system.
The PSE maintenance section on the top right displays the PSE information for the
PSE selected in the PSE status frame.
Below that, the certificate section displays certificate information for a certificate that
you have selected or imported.
The Single Sign-On ACL section on the bottom right displays the entries in the ACL of
the system.
Note that the layout of the transaction will vary slightly, depending on the
release of the SAP System.
2. In the PSE status frame on the left, choose the system PSE.
3. In the certificate section, choose Import Certificate.
The Import Certificate screen appears.
4. Choose the File tab.
5. In the File path field, enter the path of the portal’s verify.der  file.
6. Set the file format to DER coded and confirm.
7. In the Trust Manager, choose Add to PSE.
8. Choose Add to ACL, to add the Portal Server to the ACL list.
9. In the dialog box that appears, enter the portal’s system ID and client. By default,
the portal’s system ID is the common name (CN) of the Distinguished Name
entered during installation of the portal. The default client is 000.
If necessary, you can change these default values by changing the properties
login.ticket_issuer and login.ticket_client respectively in user
management properties.
The other values are taken from the certificate.
10. Save your entry.
11. Do not forget to set profile parameters and ITS service parameters as described in
Configuring SAP Systems to Accept and Verify SAP Logon Tickets .
Result
The SAP component systems are able to accept SAP logon tickets and verify the Portal
Server's digital signature when they receive a logon ticket from a user.
Importing Portal Certificate into SAP System
Prerequisites
You have downloaded the public-key certificate of the portal server (verify.pse file). Use
the Keystore Administration  tool for this.
Procedure
1. In the component system, start transaction STRUST.
The following screen appears.

This screen displays a list of the certificates contained in the PSE of the component
system.
2. In the certificate group box, choose Import Certificate.
The Import Certificate screen appears.

3. Choose the File tab.

4. In the File path field, enter the path of the portal’s verify.der file.
5. Set the file format to DER coded and confirm.
6. In the Trust Manager, choose Add to PSE.
7. Save the new certificate list.
The new certificate list is automatically replicated to all application servers in the
system. You do not have to import the portal certificate onto each application
server separately.

Enterprise portal Tips and Tricks ::

SAP Enterprise Portal offers users a single point of access to all applications,
information, and services needed to accomplish their daily tasks. Links to back-end and
legacy applications, self-service applications, company intranet services, and Internet
services are all readily available in the user’s portal.
Tips and tricks
Enable SAP* in portal : If you have disabled SAP* before assigning any user super user
role. You can always enable SAP* or vice versa doing the following:
Go to sapum.properties.bak in /usr/sap/<por SID>/j2ee/j2ee00/ume/ and change the line
ume.superadmin.activated = false to true
Restart the portal. This line is used to activate and deactivate sap* user.