User Master Records

Creating and Editing User Master Records
Use
With these functions, we can assign user data and access authorizations to the users of our
ABAP system.
Note:
The changes that we make to user master records only take effect when the user next logs on
to the system. If a user is logged on at the time when the system administrator implements the
changes, these will only take effect when the user logs on to their next session.
We can also change a users authorizations by changing and then reactivating profiles and
authorizations within the user master record. Changes to reactivated authorizations have
immediate effect. Changes to profiles, on the other hand, only take effect at the users next
logon.
Prerequisites
We have the following authorizations as the user administrator:
Authorization to create or edit a user master record and to assign it to a user group
(object S_USER_GRP)
Authorization for the authorization profiles we assign to users (object S_USER_PRO)
Authorization to create and edit authorizations (object S_USER_AUTH)
Authorization to protect roles, we can use this authorization object to determine which
roles may be processed and which activities (Create, Display, Change, and so on) are
available for the role(s) (object S_USER_AGR).
Authorization for transactions that we may assign to the role and for which we can
assign authorizations at the start of the transaction in the Profile Generator (object
S_USER_TCD)
Authorization to restrict the values which a system administrator can insert or change in
a role in the Profile generator (S_USER_VAL)
Organizing Authorization Administration
The authorization system allows us great flexibility in organizing and authorizing the
administration of user master records and roles:
If our company is small and centralized, we can have all administration of user master
records and authorization components executed by a single super user.
Protecting Special Users
Clients 000, 001 and 066 are created when our SAP System is installed. Two special users are
defined in clients 000 and 001. Since these users have standard names and standard
passwords, we must secure them against unauthorized use by outsiders who know of their
existence.
Note that no special user is created in client 066.
The two special users in the SAP System are as follows:
The SAP System super user, SAP*

SAP* is the only user in the SAP System that does not require a user master record, but that
is instead defined in the system code itself. SAP* has by default the password PASS, as well
as unlimited system access authorizations.
When we install our SAP System, a user master record is defined for SAP* with the initial
password 06071992(Its R/3 Release date) in Clients 000 and 001. The presence of a SAP*
user master record deactivates the special properties of SAP*. It has only the password and
the authorizations that are specified for it in the user master record.
To secure SAP* against misuse, we should at least change its password from the standard
PASS. For security reasons, SAP recommends that we deactivate SAP* and define our own
super user.
The maintenance user for the ABAP Dictionary and software logistics, user DDIC.
The user master record for user DDIC is automatically created in clients 000 and 001 when
we install our SAP System. The default password for this user is 19920706. The system code
allows user DDIC special privileges for certain operations. For example, DDIC is the only
user that is allowed to log on to the SAP System during an upgrade.
To secure DDIC against unauthorized use, we must change the initial password for the user in
clients 000 and 001 in our R/3 System.
The user EarlyWatch is delivered in client 066 and is protected using the password
SUPPORT. The SAP EarlyWatch experts use this user which should not be deleted. Change
the password. This user should only be used for EarlyWatch functions (monitoring and
performance).
Securing User SAP* Against Misuse
The SAP system has a default super user, SAP*, in the clients 000 and 001. A user master
record is defined for SAP* when the system is installed. However, SAP* is programmed in
the system and does not require a user master record.
If we delete the SAP* user master record and log on again as SAP* with initial password
PASS, then SAP* has the following attributes:
The user is not subject to authorization checks and therefore has all authorizations.
The user has the password "PASS", which cannot be changed.

If we want to deactivate the special properties of SAP*, set the system profile parameter
login/no_automatic_user_sapstar to a value greater than zero. If the parameter is set,
then SAP* has no special default properties. If there is no SAP* user master record, then
SAP* cannot be used to log on.
We should set the parameter in the global system profile, DEFAULT.PFL, so that it is
effective in all instances of an SAP system. We should ensure that there is a user master
record for SAP* even if we set the parameter. Otherwise, resetting the parameter to the value
0 would once again allow we to log on with SAP*, the password PASS and unrestricted
system authorizations.
See Profile maintenance for system profile parameter details.
If a user master record exists for SAP*, it behaves like a normal user. It is subject to
authorization checks and its password can be changed.
Deactivating User SAP*
As SAP* is a known super user, SAP recommends that we deactivate it and replace it with
our own super user. In the SAP* user master record, we should proceed as follows:
Create a user master record for SAP* in all new clients and in client 066.
Assign a new password to SAP* in clients 000 and 001.
Delete all profiles from the SAP* profile list so that it has no authorizations.
Ensure that SAP* is assigned to the user group SUPER to prevent accidental deletion
or modification of the user master record.
The SUPER user group has a special status in the predefined user profiles. The users that are
assigned to group SUPER can be maintained or deleted only by the new super user that we
define, provided that:
we use the predefined profiles, and
we follow SAP's other user and authorization maintenance recommendations.

Defining a New Super user
To define a super user to replace SAP*, we need only give a user the SAP_ALL profile.
SAP_ALL contains all authorizations, including new authorizations released in the
SAP_NEW profile.
SAP_NEW assures upward compatibility of authorizations. The profile ensures that users are
not inconvenienced when a release or update includes new authorization checks for functions
that were previously unprotected.
Protecting User DDIC Against Unauthorized Access
User DDIC is a user with special privileges in installation, software logistics, and the ABAP
Dictionary. The user master record is created in clients 000 and 001 when we install our R/3
System.
We should secure the DDIC user against misuse by changing DDICs initial password
19920706 in clients 000 and 001.
User DDIC is required for certain installation and setup tasks in the system, so we should not
delete it.
Depending on the size and organization of our company, we should, however, distribute
the administration of user master records and authorizations among multiple administrators,
each with limited areas of responsibility. This applies in particular in a decentralized
environment, in which different time zones might apply. This also helps to achieve maximum
system security.
Each administrator should only be able to perform certain tasks. By separating these tasks, we
make sure that no single super user has total control over our user authorizations. We also
make sure that more than one person approves all authorizations and profiles. In addition,
define standard procedures for creating and assigning our authorizations.
Since we can precisely restrict authorizations for user and authorization administration, the
administrators do not have to be privileged users in our data processing organization. We can
assign user and authorization administration to ordinary users.
Note:
We use the role administration tools and functions (transaction PFCG) to maintain our roles,
authorizations and profiles. These functions make our job easier by automating certain
processes and providing more flexibility in our authorization plan. We can also use the
Central User Administration functions to centrally edit the roles delivered by SAP or our
own, new roles, and to assign the roles to any number of users.
In Organization if We Are Using the Role Administration Tool
If we are using the role administration tool (the profile generator), we can distribute the
administration tasks within an area (such as a department, cost center, or other organizational
unit) to the following administrator types:
Authorization data administrator, who creates roles (transaction selection and

authorization data), selects transactions, and edits authorization data. However the
authorization data administrator can only save data in the role administration tool,
since he or she is not authorized to generate the profile, He or she accepts the default
profile name T_.... when doing this.
Authorization profile administrator, who checks and approves the data, and generates
the authorization profile, to do this, he or she choose All Roles in transaction
SUPC or PFCG, and then specifies the abbreviation of the role to be edited. On the
following screen, he or she checks the data by choosing Display Profile.
User administrator, who edits the user data with the user administration transaction
(SU01) and assigns roles to the users, this enters the approved profiles in the master
records of the users.
These administrators of one or more areas are administered by super users who set up
their user master records, profiles, and authorizations. We recommend that we assign
the super user, the user administrator, and the authorization administrator the SUPER
group. If we use the pre-defined user administration authorizations, this group
assignment makes sure that user administrators cannot modify their own user master
records or those of other administrators. Only administrators with the pre-defined
profile S_A.SYSTEM can edit users in the group SUPER.
The table in the section Setting Up User and Authorization Administrators shows the tasks
that we should assign to individual administrators, tasks that we should not assign, and the
templates that we have predefined for these tasks.
Setting Up User and Authorization Administrators
Use
If we have organized our user administration in a decentralized manner, in which we have
distributed the user administration tasks among multiple administrators, we must create these
administrators as normal SAP users or assign these tasks to existing users.
The table below shows the tasks that we should assign to individual administrators, tasks that
we should not assign, and the templates and roles that we have predefined for these tasks. A
role is only available for the user administrator. This has the advantage over a template that
the administrator receives a menu that contains all of the important functions for his or her
work.
Organization of the User Administrators when using the Role Administration Tool
Administrator
User Administrator
Authorization Data
Administrator
Authorization
Profile
Administrator
Permitted Tasks
Creating and
changing user
master records
Impermissible Tasks
Changing role data
Assigning roles to
users
Assigning profiles
beginning with
"T_......." to users
Displaying
authorizations and
profiles
Using the User
Information System
Creating and
changing roles
Changing
authorization data
and transaction
selection in roles
Using the User
Information System
Displaying roles and
the associated data
Changing or
generating profiles
Using transaction
PFCG or SUPC to
generate the
authorizations and
profiles that begin
Changing role data
Changing users
Templates and Roles

Template
SAP_ADM_US
Role
SAP_BC_USER_ADMI
SAP_ADM_AU
Generating profiles
Changing users
SAP_ADM_PR
with T_..... for

roles that have
authorization data
Checking roles for
the existence of
authorization data
(transaction SUPC)
Generating
authorization
profiles with
authorization
objects that begin
with S_USER
Performing a user
master comparison
(transaction PFUD,
Performing a profile
comparison of the
user master
comparison)
Using the User

Information System
Prerequisites
We are an administrator with the predefined profile S_A.SYSTEM, with which we can edit
users of the group SUPER.
Procedure
1. Create a role for each administrator.
a. Enter a name in the Role field in role administration (transaction PFCG) and
choose Create Role.
b. Do not assign any transactions; instead, choose Change authorization data on the
Authorizations tab page.
A dialog box appears asking us to choose a template.
c. Choose one of the following templates:
Template
SAP_ADM_PR
SAP_ADM_AU
SAP_ADM_US
Administrator
Authorization profile
administrator
Authorization data
administrator
User administrator
d. Generate an authorization profile in each case.

Use a profile name that does not begin with T_...., so that the authorization data
administrator cannot change his or her own authorizations.
2. On the User tab page, assign the role to the relevant user, that is, to the administrator.
3. Save our entries.
4. So that the user administrators cannot change their own user master records, or those of
other administrators, assign them to the group SUPER. This applies if we are using the
predefined user administration authorizations.
a. To do this, choose the Logon Data tab page in user administration (transaction
SU01).
b. In the User Group for Authorization Check field, enter the value SUPER.
c. Save our entries.
5.
If appropriate, restrict the authorizations of the administrators further:

We can use authorization objects S_USER_AGR, S_USER_TCD and
S_USER_VAL to further differentiate the roles of the administrators.
For the user administrator, we can restrict the authorization to particular user
groups.
For the profile administrator, we can exclude additional authorization objects, for
example, for HR data. If we want our generated authorization profiles to begin
with a letter other than T_....., we should inform our profile administrator.
Note:
No authorization profile beginning with T_..... may contain critical (S_USER* objects)
authorization objects.
Procedure
1. Choose Tools Administration User Maintenance User (transaction SU01).
The User maintenance: Initial screen appears.
2. Enter a new user name and choose Create ( ) or enter an existing user name or alias
(such as an Internet user) and choose Change ( ).
We can also create a user by copying existing users.
3. Enter the personal data for the user on the Address tab page. The Last name field must be
filled. This data belongs to the Business Address Services (BC-SRV-ADR).
There are the following tab pages in user administration: Address, Logon Data, (possibly
SNC), Defaults, Parameters, (possibly Systems), Roles, Profiles, Groups, Personalization,
and License Data. The tab pages SNC and Systems are only displayed if the SNC interface
and Central User Administration are used.
The tab pages can be divided into those we must maintain and those we can optionally
maintain:
We do not need to edit the Defaults and Parameters tab pages. Users can change this data
themselves later by choosing System
User profile
Own data (see Editing User Defaults and Options).
We can use transaction variants to restrict the fields that users can edit themselves.
The Address, Logon data, Roles, and Profiles tab pages contain fields that we must fill in.
Copying Users
Use
We can create a user by copying an existing one. We can copy the standard values, addresses,
and parameter settings, or copy the entire user and create it under a new name.
Prerequisites
We are authorized to assign the authorizations, systems, roles, profiles, and reference users
that are assigned to the user to be copied. Otherwise, the role for which we do not have
authorization is not copied to the new user master record. When copying or assigning a
reference user, the system checks whether we are authorized to assign its profiles and roles.
If we cannot copy the template user completely, because, for example, the reference user does
not exist in the current system, the system displays a log with the exact causes of the error.
Procedure
1.
Choose Tools Administration User Maintenance User (transaction SU01).
2.
Specify the user to be copied.
3.
Choose Copy .
The system displays the Copy User dialog box.
4.
Enter the names of the reference and new users.
5.
Select the desired values and leave the dialog box by choosing Copy ( ).
The system displays the Maintain User screen. We can edit the user more here.
6. To actually create the user, save our entries.
Note:
When we are copying a user, the reference user of the copy source is always copied too, as
long as we have sufficient authorizations to assign the roles or profiles of the reference user.
If we do not want the reference user to be assigned to the new user, we must manually delete
it from the user master record after the copy process.
Errors that occur during the authorization checks are collected and displayed in a log.
If an error occurred during the authorization check, this is displayed in a log.
For information about authorization checks for the assignment of reference users, see
SAP Note 513694.
Business Address Services (BC-SRV-ADR) Purpose
Business Address Services (BAS) offer functions for managing addresses in applications.
We can store and further process addresses, using different address types. An address is
subordinate to an associated application object (such as a customer, a purchase order, or a
plant).
Implementation Considerations
The BAS provide flexible dialog integration for standard functions such as creating,
changing, displaying and finding addresses. In this way, the BAS guide users through
different applications when they maintain addresses.
BAS function modules enable the application to store addresses for the associated application
object in BAS tables. These tables contain the addresses of all applications that use the BAS
in a system. Functions and data storage in address management are central with regard to a
client in a system.
Integration
The BAS are already used by a broad range of applications, including, for example:
Customer and vendor master
Site master (Retail)
Bank addresses
Sales and Distribution documents: Document addresses and one-time customer

addresses
User addresses
SAP office addresses (external communication)
Customizing addresses (SM30)
MM Purchasing: Permanent delivery addresses, manual delivery addresses in

purchase orders, purchase requisitions, one-time vendors
PM/SM (functional locations, equipment, notification, order)
IS-U (connection objects, contracts)
IS-Oil (service stations)
SAP Business Partners
New Dimension products such as SFA, BW, APO, CRM

In addition, the BAS provide functions to support other tools and interfaces:
Integration into SAP connect
Provision of archiving classes for the Archive Development Kit (ADK)
Support of addresses as objects in the BOR
Provision of interfaces for application-specific enhancements
Automatic writing of change documents for address data changes

Features
General Characteristics
Together with the address, we can enter data for all common communication methods
(for example, telephone number, fax number, e-mail address, and so on).
International address requirements (print output according to international mail

standards, multiple address formats, for example for Asian countries) are considered.
By means of a where-used list, we can determine which application objects reference

an address as an attribute.
Checks against city and street directories are performed using interfaces (for example,
for partner solutions) or as a function in the standard system (city and street files are
delivered without content and can be filled by means of transfer programs).
A duplicate check and an error-tolerant search are performed using interfaces, which
can be validated, for third-party vendors.
Functions are provided for using addresses in combination with other tools (see
Integration).
Integration into the Application
Three address types are available to map addresses from the application onto BAS
data structures: Company addresses, personal addresses, and workplace addresses
It is also possible to maintain address-independent communication data. For more
information, see Address-Independent Communication Data.
Dialogs for maintaining addresses can be integrated flexibly into the application (as a
dialog box, sub screen, or full screen). We can parameterize the screens to hide fields
or to define required fields, for example.
Address data is updated together with the application data.
Addresses are grouped by their assignment to an application, which can be used as a

filter for searches and authorization checks.
Address Distribution and Transport
Address used
for
Example
Transport or distribution methods or tools

used by BAS
Master data
Customer,
vendor
Distribution using ALE (Application Link

Enabling)
Customizing
objects
Plant, sales
organization
Methods for transporting addresses within the

normal Customizing object transport process
System user
System user
Methods for client copy and BAPIs for central

user management (cross-system in this case)
Constraints
The functions of Business Address Services are system-dependent. However, we can use the
tools and methods mentioned above to transport and distribute addresses.
Time-dependent addresses (which are valid for a limited period only, such as the vacation
address of a newspaper subscriber) are currently not supported.
BOR
Definition
The Business Object Repository (BOR) is the object-oriented repository in the R/3 System. It
contains the SAP business object types and SAP interface types as well as their components,
such as methods, attributes and events.
BAPIs are defined as methods of SAP business object types (or SAP interface types) in the
BOR. Thus defined, the BAPIs become standard with full stability guarantees as regards their
content and interface.
For general information on creating business objects see the documentation on

Business Workflow.
SAP
Use
The BOR has the following functions for SAP business object types and their BAPIs:
Provides an object oriented view of R/3 System data and processes.

R/3 application functions are accessed using methods (BAPIs) of SAP Business
Objects. Implementation information is encapsulated; only the interface functionality
of the method is visible to the user.
Arranges the various interfaces in accordance with the component hierarchy, enabling
functions to be searched and retrieved quickly and simply.
This finds the functionality searched for quickly and simply.
Manages BAPIs in release updates.

BAPI interface enhancements made by adding parameters are recorded in the BOR. Previous
interface versions can thus be reconstructed at any time. When a BAPI is created the release
version of the new BAPI is recorded in the BOR. The same applies when any interface
parameter is created.
The version control of the function module that a BAPI is based on is managed in the
Function Builder.
Ensures interface stability.

Any interface changes that are carried out in the BOR, are automatically checked for syntax
compatibility against the associated development objects in the ABAP Dictionary.
Integration
A BAPI is implemented as a function module that is stored and described in the Function
Builder. We should only define a BAPI as a method of an SAP business object type in the
BOR, if the function module that the BAPI is based on has been fully implemented.
Access to the BOR is restricted at SAP.
BOR/BAPI Wizard
The BOR/BAPI Wizard helps us to create new BAPIs in the BOR. It takes us through the
process step by step.
BAPIs
Definition
A Business Application Programming Interface (BAPI) is a precisely defined interface
providing access to processes and data in business application systems such as R/3.
BAPIs of SAP Business Object Types
BAPIs are defined as API methods of SAP business object types. These business object types
and their BAPIs are described and stored in the Business Object Repository (BOR). A BAPI
is implemented as a function module, which is stored and described in the Function Builder.
BAPIs of SAP Interface Types
As of Release 4.5A BAPIs can also describe interfaces, implemented outside the R/3 System
that can be called in external systems by R/3 Systems. These BAPIs are known as BAPIs
used for outbound processing. The target system is determined for the BAPI call in the
distribution model of Application Link Enabling (ALE).
BAPIs used for outbound processing are defined in the Business Object Repository (BOR) as
API methods of SAP Interface Types. Functions implemented outside the R/3 System can be
standardized and made available as BAPIs. For further information see BAPIs Used For
Outbound Processing.
Integration
BAPIs can be called within the R/3 System from external application systems and other
programs. BAPIs are the communication standard for business applications. BAPI interface
technology forms the basis for the following developments:
Connecting:
New R/3 components, for example, Advanced Planner and Optimizer (APO) and
Business Information Warehouse (BW).
Non-SAP software
Legacy systems
Isolating components within the R/3 System in the context of Business Framework
Distributed R/3 scenarios with asynchronous connections using Application Link

Enabling (ALE)
Connecting R/3 Systems to the Internet using Internet Application Components

(IACs)
PC programs as frontends to the R/3 System, for example, Visual Basic (Microsoft) or
Visual Age for Java (IBM).
Workflow applications that extend beyond system boundaries
Customers' and partners' own developments

The graphic below shows how BAPI interfaces enable different types of applications to be
linked together.
BAPIs - Interfaces to the R/3 System
For further background information on BAPIs refer to the document BAPI User Guide.
API Documentation
If we are working in the Developer Studio, the corresponding Java doc is directly available
under the Reference API Documentation node from within the Java Development
Manual structure.
Otherwise, if we access this documentation using the Help Portal without having installed the
Developer Studio, we can use selected versions of Java doc made available in the SAP
Developer Network (SDN).
For more information, see http://www.sdn.sap.com/irj/sdn/javadocs

Note:
If we do not have an SDN user, we must register before we can log on.
Editing User Defaults and Options
Both system administrators and individual users can edit user data. The system administrator
can edit all data (see Creating and Editing User Master Records). Users can edit the following
user data: Password, Constants, Addresses and Parameters.
The following sections describe the user options that every user can set himself or herself.
Editing Our Own User Data
Users can edit their own data by choosing System
User profile
Own data. Choose F1 to display Help on the fields. We can display selectable input values
with the possible entry help (F4).
Password
Users can change their current password using the Password button. The password can only
be changed once every day.
Fixed Values
Users can set the following default values and can call up information about this with F1:
Start menu
The user can specify the name of an area menu from the possible entries help in this field.
The SAP Menu then only contains the components of this area menu.
A user needs the credit management transactions for his or her daily work. If the start menu in
his or her user data is FRMN, the SAP Menu only displays the credit management
transactions.
The system-wide initial menu can be specified in the transaction SSM2.
Logon language
The default system language at logon. Users can however choose another language on the
logon screen
Output device
Spool control
Personal time zone (different from the company time zone on the Address tab page,
crucial with RFC)
Date format
The format for decimals
CATT test status

Address
The user address data fields are self-explanatory. Only the system administrator can edit
company addresses.
A time zone is assigned to each company address. User-specific time zones can overlap
company time zones (see Defaults above).
Parameters
User parameters supply defaults to SAP fields. If a field is indicated, the system
automatically fills in the default value. Depending on the field definition, the entry can also
be replaced with a value entered by the user.
The two input fields on the parameter editing screen are described briefly below. For more
information, choose F1.
Parameter: Enter the parameter ID for which we want to define a default value. We can
display all of the parameter IDs defined in the system by choosing F4.

Value: Enter the default value for the parameter.
Transaction Variants and Screen Variants
Whenever we use a transaction in the SAP system to process specific business transactions, it
often makes sense to adjust processing flow to mirror these business activities. This can be
done by hiding all information not pertinent to the business. More important information
should be placed in a better position.
Creating a transaction variant alters the layout of the screen. Business processes delivered by
SAP retain their integrity in any case.
Transaction variants are actually made up of a series of screen variants. The field values and
settings for each screen in the transaction variant are stored in a screen variant.
We can create as many variants of a specific transaction as we like. These variants are started
by entering a transaction code that we have selected. We system administrator can assign our
transaction codes to user menus. This allows the users in the departments that use our
transaction to call the transaction directly. For more information, refer to the section entitled
Creating Roles.
The functions of the transactions variants are supplemented by the integration of the tool
GuiXT. Transactions can be enhanced using graphics, texts, and HTML pages. Screen fields
can also be moved around on the screen, and important new menu functions can be added to
the user interface or application toolbar in the form of pushbuttons.
More information:
Transaction Variants
Variant Transactions, Setting Transaction Variants
Creating and Maintaining Variant Groups
Screen Variants
Table Control Layout in Variants
Transaction Variants and Screen Variants: Limitations
Transaction Variants and Screen Variants: Special Features
GuiXT
More information about the tab pages for user administration:
Logon Data Tab Page
When we create a user, it is only mandatory to fill out the Initial Password field on the Logon
Data tab page. All other entries on this screen are optional. The fields are described in detail
below.
Alias
We can assign an alias of up to 40 characters to a user to specify more memorable names.
Depending on the programming of the application, the user can then log on using either the
(12 character) user name or the alias.
If an external user sets up a user account for himself or herself in the Internet, he or she
automatically uses an alias instead of a user name to do this. The SAP system then creates a
new user master record with this alias and an automatically generated 12 character user name.
The user then reports, for example, password problems using his or her alias instead of the
technical user name, which is unknown to the user. The system administration determines the
correct user master record in the SAP system using the alias.
Initial Password
We have the following options when assigning initial passwords:
Enter the password manually and repeat it in the Repeat Password field to avoid
typographical errors.
To generate the password, choose Generate ( ).
To deactivate the password, choose Deactivate ( ).
This means that the user can no longer log on using a password, but only with Single Sign-On
variants (X.509 certificate, logon ticket). This is useful if we do not require password-based
logon because logon is performed exclusively in other ways (such as using logon tickets, see
SAP Note 177895). In this case, deactivating the password increases security, as passwords
that are not used are usually still initial.
Although the deactivation of passwords cannot be made retrospectively (looking backward),
the administrator can define a new initial password at any time.
The deactivation of the password on the Logon Data tab page refers to the local system. If
Central User Administration is in use, we can change or deactivate passwords systemspecifically in user maintenance.
More Information:
Password Rules
Login Parameters for password rules
User Maintenance Functions, Change Password section.

Although the Password Status is always displayed when creating a user, it only shows the
status for users that have been created (see also Password Status).
Password Rules
The following table describes the specifications that are to be followed for passwords. It also
shows whether these guidelines are predefined in the system or whether we can change them
using profile parameters.
Rule
The password must be at least 3
characters long
The password cannot be more
than 40 characters long Until
SAP NetWeaver 6.40 (inclusive);
passwords could not be more
than 8 characters long.
Until SAP NetWeaver 6.40
(inclusive), all characters of the
syntactic character set can be
used, that is, all letters and digits,
and some special characters. The
system does not differentiate
between upper- and lower-case.
After SAP NetWeaver 6.40, any
Unicode characters can be used,
and the system does differentiate
between upper- and lower-case.
As of SAP Web AS 6.10, the
administrator can define how
many digits, letters, and special
characters must be contained in
new passwords (see profile
parameter).
The first character may not be an
exclamation point (!) or a
question mark (?).
Notes
We can change this with profile parameter
login/min_password_lng.
Predefined in SAP system
We can change this with profile parameters

login/min_password_letters,
login/min_password_digits, and
login/min_password_specials.
See also: login/password_charset.
The first three characters may not

appear in the same order in the
user ID
This rule applies only in systems
up to SAP R/3 4.6D.
The first three characters cannot
all be the same.
None of the first three characters
can be a space
This rule applies only in systems
up to SAP R/3 4.6D.
The password may not be in a list
of impermissible passwords
(table USR40) The list contains
character combinations or terms,
where the asterisk (*) and
question mark (?) can be used as
placeholders. Asterisk (*) stands
for a character sequence, and the
question mark (?) for a single
character.
The administrator receives only a
warning, if he or she breaks this
password rule when assigning
passwords in user maintenance.
The password cannot be PASS or
SAP*.
The password may not be
changed to any of a users last x
passwords, if the user changes
the password himself or herself.
(inclusive), the password history
was fixed to the value 5.
After SAP NetWeaver 6.40, the
administrator can set the size of
the password history (up to 100
passwords selected by the user).
The administrator can reset a
users password to any initial
password, therefore also to one of
the last x passwords for this user.
This is necessary, since the
administrator should not know
the passwords of the users. The
user is prompted to change the
initial password at the first
interactive logon.

Can be changed. The default value is that all

passwords, except PASS and SAP* are allowed.

We can change this with the profile parameter
login/password_history_size.
The password can only be

changed after the old password
has been entered correctly.
Up to SAP Web AS 6.10, the user
can only change the password
during the logon procedure. As of
SAP Web AS 6.20, the user can
also change the password by
choosing System User Profile
Own Data (transaction SU3)
Users can only change their

passwords again after a wait
period.
(inclusive), the wait period was
one day. A password changed by
a user could only be changed
again by that user on the next
day.
The system can now reject all
password changes during the wait
period (unit: days). If the
administrator changes the users
password, the user must change
this initial password the next time
he or she logs on, regardless of
when he or she last changed his
or her password.
System administrators can still
change passwords as often as
necessary.
The password must contain at
least x lower-case letters.
(inclusive), the system did not
differentiate between upper- and
lower-case.
The password must contain at
least x upper-case letters.
(inclusive), the system did not
differentiate between upper- and
lower-case.

login/password_change_waittime.

login/min_password_lowercase.

login/min_password_uppercase.
At least one character in the new We can change this with profile parameter
password must be different from login/min_password_diff.
the old password.
As of SAP Web AS 6.10, the
administrator can specify the
minimum number of characters
that must be different in the old
and new passwords in a profile
parameter.
The password must comply with We can activate this with the profile parameter
the current password rules and
login/password_compliance_to_current_policy.
must be changed if it does not.
(inclusive), changed password
rules did not apply to old
password, but were only
evaluated when passwords were
changed.
A productive password (chosen
by the user) is valid for a
login/password_max_idle_productive.
maximum of x days, if it is not
used.
Available after SAP NetWeaver
6.40.
An initial password (set by the
user administrator) is valid for a
login/password_max_idle_initial.
maximum of x days, if it is not
used. After this period has
expired, the password can no
longer be used for authentication.
The user administrator can
reactivate password-based logon
by assigning a new initial
password.
Available after SAP NetWeaver
6.40.
As of SAP Web AS 6.10, the function module PASSWORD_FORMAL_CHECK can
determine whether a string meets the current password rules. The following rules are not
evaluated here:
Password may not be changed to any of a users last five passwords
The password can only be changed after the old password has been entered correctly.
A user can change his or her password only once a day.
At least x characters in the new password must be different from the old password.
For an exact description of the sequence and the scope of the check, see the documentation
for the function module. We can display this documentation with transaction SE37.
Profile Parameters for Logon and Password (Login Parameters)
The following table presents the profile parameters with which we can set password and
logon rules. These profile parameters define the minimum requirements for passwords, for
example, that the password must contain at least three special characters. We cannot set upper
limits for password rules. For example, in accordance with the usual password rules, the users
can enter any number of special characters. For information about the procedure for changing
profile parameters, see Changing and Switching Profile Parameters.
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,
we must set them in the profiles of each application server in our 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. On the following screen, choose the Documentation pushbutton.
Password Rules
Parameter
login/min_password_lng
login/min_password_digits
login/min_password_letters
login/min_password_lowercase
login/min_password_uppercase
login/min_password_specials
Explanation
Defines the minimum length of the
password.
Default value: 6; permissible values: 3
40
Until SAP NetWeaver 6.40 (inclusive),
up to 8 characters.
Defines the minimum number of digits
(0-9) in passwords.
40
Available as of SAP Web AS 6.10 (Until
SAP NetWeaver 6.40 (inclusive), up to 8
characters.)
Defines the minimum number of letters
(A-Z) in passwords.
40
characters.)
Specifies how many characters in lowercase letters a password must contain.
Permissible values: 0 40; default value
0
Available after SAP NetWeaver 6.40
Specifies how many characters in uppercase letters a password must contain.
Permissible values: 0 40; default value
0
Defines the minimum number of special
characters in the password Permissible
special characters are, in particular, !"@
$%&/()=?'`*+~#-_.,;:{[]}\<>| and space
and the grave accent.
After SAP NetWeaver 6.40, all
characters that are not letters or digits
are regarded as special characters.
login/password_charset

40
characters.)
This parameter defines the characters of
which a password can consist.
Permissible values:
0 (restrictive): The password can
only consist of digits, letters, and the
following (ASCII) special
characters: !"@ $%&/()=?*+~#-_.,;:
{[]}\<> and space and the grave
accent.
1 (backward compatible, default
value): The password can consist of any
characters including national special
characters (such as , , from ISO
Latin-1, 8859-1). However, all
characters that are not contained in the
set above (for value = 0) are mapped to
the same special character, and the
system therefore does not differentiate
between them.
2 (not backward compatible): The
password can consist of any characters.
It is converted internally into the
Unicode format UTF-8. If our system
does not support Unicode, we may not
be able to enter all characters on the
logon screen. This restriction is limited
by the code page specified by the system
language.
Warning:
With login/password_charset = 2,
passwords are stored in a format that
systems with older kernels cannot
interpret. We must therefore only set the
profile parameter to the value 2 after we
have ensured that all systems involved
support the new password coding.
Available in the standard system as of
SAP Web AS 6.40.
Password Logon
login/password_compliance_to_current_policy Permissible values: 0 no check; 1 the
system checks during password logon
whether the current password complies
with the current password rules and
forces a password change if this is not
login/disable_password_logon
login/password_logon_usergroup
login/password_max_idle_productive
login/password_max_idle_initial
login/password_max_new_valid
login/password_max_reset_valid
the case.
Default value: 0
Controls the deactivation of passwordbased logon
This means that the user can no longer
log on using a password, but only with
Single Sign-On variants (X.509
certificate, logon ticket). More
information: Logon Data Tab Page
Available as of SAP Web AS 6.10, as of
SAP Basis 4.6 by Support Package
Controls the deactivation of passwordbased logon for user groups
Specifies the maximum period for which
a productive password (a password
chosen by the user) remains valid if it is
not used. After this period has expired,
the password can no longer be used for
authentication. The user administrator
can reactivate password-based logon by
assigning a new initial password.
Permissible values: 0 24,000 (unit:
days); Default value 0, that is, the check
is deactivated
Specifies the maximum period for which
an initial password (a password chosen
by the administrator) remains valid if it
is not used. After this period has expired,
the password can no longer be used for
authentication. The user administrator
can reactivate password-based logon by
assigning a new initial password.
This parameter replaces the profile
parameters
login/password_max_new_valid and
login/password_max_reset_valid.
days); Default value 0, that is, the check
is deactivated
Defines the validity period of passwords
for newly created users.
Only available in SAP Web Application
Server 6.20 and 6.40.
Defines the validity period of reset
passwords.
Only available in SAP Web Application

Server 6.20 and 6.40.
Password Changes
login/min_password_diff
login/password_expiration_time
login/password_change_for_SSO
login/password_history_size
login/password_change_waittime
Other Password Profile Parameters

login/password_downwards_compatibility
Defines the minimum number of

characters that must be different in the
new password compared to the old
password.
40
characters.)
Defines the validity period of passwords
in days.
1000
If the user logs on with Single Sign-On,
checks whether the user must change his
or her password.
Specifies the number of passwords
(chosen by the user, not the
administrator) that the system stores and
that the user cannot use again.
Permissible values: 1 100 (unit:
number of entries); default value 5
Specifies the number of days that a user
must wait before changing the password
again.
days); default value 1
Specifies the degree of backward compatibility
to be achieved. The default value is 1, where
the values have the following meaning:
0
Warning:
With
login/password_downwards_compatibility = 0,
passwords are stored in a format that systems
with older kernels cannot interpret. The system
only generates new (backward incompatible)
password hash values.
1
The system also generates backward
compatible password hash values internally,

but does not evaluate these for password-based
logons (to its own system). This setting is
required if this system is used as the central
system of a Central User Administration that
systems that only support backward compatible
password hash values are also connected to the
system group.
2
The system also generates backward
compatible password hash values internally,
which it evaluates if a logon with the new, nonbackward compatible password failed. In this
way, the system checks whether the logon
would have been accepted with the backward
compatible password (truncated after eight
characters, and converted to upper-case). This
is recorded in the system log. The logon fails.
This setting is to allow the identification of
backward incompatibility problems.
3
As with 2, but the logon is regarded as
successful. This setting is to allow the
avoidance of backward incompatibility
problems.
4
As with 3, but no entry is created in the system
log.
5
Full backward compatibility: the system only
creates backward compatible password hash
values.
Multiple Logon
Parameter
login/disable_multi_gui_login
login/multi_login_users
Incorrect Logon
Parameter
login/fails_to_session_end
Explanation
Controls the deactivation of multiple dialog
logons
Available as of SAP Basis 4.6
List of excepted users, that is, the users that
are permitted to log on to the system more
than once.
Explanation
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
login/failed_user_auto_unlock
SSO Logon Ticket

Parameter
login/accept_sso2_ticket
login/create_sso2_ticket
login/ticket_expiration_time
login/ticket_only_by_https
login/ticket_only_to_host
Other Login Parameters

Parameter
login/disable_cpic
login/no_automatic_user_sapstar
login/system_client
login/update_logon_timestamp
Other User Parameters
Parameter
rdisp/gui_auto_logout
Defines the number of unsuccessful logon

attempts before the system locks the user.
Default value: 5; permissible values: 1 -99
Defines whether user locks due to
unsuccessful logon attempts should be
automatically removed at midnight.
Default value: 0 (locks due to incorrect
logon attempts remain in force for an
unlimited period); permissible values: 0, 1
Explanation
Allows or locks the logon using SSO ticket.
Available as of SAP Basis 4.6D, as of SAP
Basis 4.0 by Support Package
Allows the creation of SSO tickets.
Available as of SAP Basis 4.6D
Defines the validity period of an SSO
ticket.
Default value: 8; Unit: hours
The logon ticket is only transferred using
HTTP(S).
When logging on over HTTP(S), sends the
ticket only to the server that created the
ticket.
Explanation
Refuse inbound connections of type CPIC
Controls the emergency user SAP* (SAP
Notes 2383 and 68048)
Default value: 1, that is, the emergency
user must be explicitly activated
Permissible values: 0, 1
Specifies the default client. This client is
automatically filled in on the system logon
screen. Users can type in a different client.
Specifies the exactness of the logon
timestamp.
Explanation
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
User Administration Functions

As an administrator, we can use the following functions in the user administration tool (Tools
Administration User Maintenance Users):
Function
Description
- Create
Enter a user name and choose Create. For more
information, see Creating and maintaining user master
records.
- Change
Enter an existing user name or an alias and choose Change.
For more information, see Creating and maintaining user
master records.
- Display
Enter a user name or an alias and choose Change. For more
information, see Creating and maintaining user master
records.
Delete
Enter a user name or an alias and choose Delete.
Copy
1.
Enter the name of the user to be copied and choose
Copy.
The system displays the Copy User dialog box.
2.
In the From field, enter the user to be copied, and in
the To field, enter the new user. In the Choose parts group
box, we can specify the user data to be copied using the
checkboxes. Logon data (password, SNC) is, of course, not
copied.
The user administration function appears, and we can edit
the new user as described under Creating and Maintaining
User Master Records.
Note:
We can also rename user master records (User Rename)
if we simply want to replace one record with an identical
one of a different name.
Lock/Unlock
Enter an existing user name and choose Lock/Unlock to
grant or deny a user access to a system. Locking or
unlocking a user master record takes effect the next time a
user attempts to log on. Users who are logged on at the
time that changes are made are not affected.
The system automatically locks users if twelve successive
unsuccessful attempts are made to log on. The lock is
recorded in the system log, along with the terminal ID of
the machine where the logon attempt took place.
We can set the number of permissible unsuccessful logon
attempts in a system profile parameter (see Profile
Parameters for Logon and Password (Login Parameters)).
This automatic lock is released by the system at midnight.
We can also remove the lock manually before this time.
Locks that we specifically set our self apply indefinitely
until we release them.
- Change password
Enter the user name and choose Change password.
This new password must fulfill the standard conditions
regarding permissible passwords (see Password rules). For
Edit Address
Info Info System
Environment Mass
changes
Environment Archive
and read
more information, see Logon Data Tab Page or the F1 help.

The new password take effect immediately, meaning that
the user can use the new password immediately after the
change.
Users can change their own passwords no more than once a
day. System administrators, on the other hand, may change
user passwords as often as necessary.
Special Features for Central User Administration
(CUA).
If we change passwords in the central system, a dialog
window with a list of target system appears. We can
activate or deactivate the password in this window (see
Logon Data Tab Page).
The selections in the dialog window are set so that if we are
changing the password the child system is selected, and if
we are deactivating the password, the central system is
selected. We can change this setting.
Select a component (telephone number, fax number, and so
on) and make changes as needed.
With this function, the system displays the User
Information System (transaction SUIM).
We can also perform most changes which can be made for
one user in the user management for a selected set of users.
For more information, see Mass changes.
Displaying Change Documents
To call a list of changes to user master records,
authorization profiles and authorizations, choose
Information Information system and then Change
documents. The system logs the following changes:
Direct authorization changes for a user (that is,
changes to the profile list in the user master record).
Indirect changes are changes to profiles and authorizations
contained in the user master record. These changes cannot
be seen in the display. We can, however, see them in the
change documents for profiles and authorizations.
Changes to user passwords, user type, user group,
validity period and account number
For each change made, the log shows the deleted value in
the Deleted entries line. The changed or new value is
displayed in the Added entries line.
Archiving change documents
User master records and authorizations are stored in the
USR* tables. We can reduce the amount of space that these
take up in the database by using the archiving function.
Change documents are stored in the USH* tables. The
archiving function deletes change documents that are no
longer required from the USR* tables.
We can archive the following change documents relating to
user master records and authorizations from the USH*
tables:
Environment Maintain
Profiles
Authorization
Environment User
groups
Environment
Organizational Assignment
Company Address
Environment
Distribution Log
Changes to authorizations (archiving object

US_AUTH)
Changes to authorization profiles (archiving object
US_PROF)
Changes to the authorizations assigned to a user
(archiving object US_USER)
Changes to a users password or to defaults stored in
the user master record (archiving object US_PASS)
The functions for administering users and authorizations
provide access to the archiving system. In the user
administration function, choose Environment Archive
and read. In profile and authorization administration,
choose Utilities Archive and read. We then have two
options, either Archive auth. docs or Read auth. docs.
These options refer to whether we want to archive or read
change documents pertaining to users, profiles or
authorizations.
For more detailed information about the archiving system,
see the Archiving User and Authorization Changes section
in Data Archiving in the SAP Web AS.
With this function, we go to the obsolete, manual profile
administration (transaction SU02). Instead of this, use the
new role administration tool (transaction PFCG).
With this function, we go to the obsolete authorization
administration (transaction SU03). Instead of this, use the
new role administration tool (transaction PFCG).
Users can be assigned to one or more user groups. For
more information, see User groups.
We can assign a position to the user in accordance with his
or her place in the organizational management here.
With this function, we go to the company address
administration (transaction SUCOMP). We can assign the
company address in user administration using the relevant
pushbuttons.
The log display for central user administration appears, in
which we can display distribution logs (transaction SCUL).
Mass Changes
With the Mass Changes function (transaction SU10), we can perform most of the changes
that we can make for individual users in user maintenance for user groups; that are certain
sets of users. This applies for Logon data, Defaults, Parameters, Roles, and Profiles.
The mass change functions apply to all of the users displayed in the initial screen unless we
make a selection.
Warning:
We must choose Change in the Address, Logon data and Constants tab pages for each change.
In this way, we can ensure that our changes, such as the deletion of a fields contents are
accepted for the corresponding fields.
Mass Maintenance Functions

Function
Comment
Select users
Used to select a set of users that have a particular characteristic
with the User Information System. We can then process this set of
users with the other mass maintenance functions.
1.
Choose Address or Authorization data.
2.
Specify a selection criterion.
3.
Select some or all users in the result list and choose Copy.
We have transferred a subset of the users that exist in the system to
mass maintenance and can now process these with the other mass
maintenance functions.
Create users
1.
Enter the names of the users to be created in the User
column.
2.
Choose Create .
Maintain the user data as in the user maintenance (SU01). For
more information, see Creating and Maintaining Users.
Note:
We cannot assign individual passwords because we create several
users at the same time. They are generated automatically and
displayed in the mass changes log.
Changing users
Delete users
Lock/unlock users
1.
Choose Change .
2.
Change the user data. We can decide whether parameters,
roles, profiles and groups are added to or removed from the user
master records.
Choose Delete .
Choose Lock ( ) or Unlock ( ).
Note:
The users are only locked or unlocked if it is allowed in the current
system. If the system is in the Central User Administration, only
the central system may be able to lock and unlock. See Setup field
distribution parameters.
The functions of the Info and Environment menus correspond to those of user maintenance
(see User Maintenance Functions).
Mass changes log
After every mass change, the system shows who made which changes in which system at
what time.
The log contains several message levels which we can expand with a pushbutton. If a
message has a long text, we can display it with a pushbutton next to the message.
We can make certain settings for the log display under Settings and the Color legend explains
the colors used in the display.
We can print the log or save it in a PC file.
Special Features for Central User Administration (CUA).
If we use the Central User Administration, i.e. we make the mass changes from the central
system, profiles and roles are displayed system-dependently. For more information, see
Distributing users.
User Administration with Active Central User Administration
With active Central User Administration, we still use transaction SU01 to edit users; however
user administration is somewhat different:
Whether fields are ready for input or not depends on the distribution attributes that we
assigned to the field in transaction SCUM. For more information about this, see Setting
Distribution Parameters for Fields.
Only the fields that may be maintained in the system are ready for input.
We can only change a field that is to be maintained globally in the central system. This field
does not accept input in the child systems.
In the central system, the user administration transaction also displays the tab page
Systems. Here we enter the systems to which users are to be distributed. To display the
systems for the corresponding distribution model, use the possible entries help. Each time we
save, the system distributes the user data to these listed systems.
The Roles and Profiles tab pages each contain an additional column for each entry,
specifying the system for which the user is assigned the role and/or profile.
With the Text comparison from child sys. Pushbutton on the Roles and Profiles tab pages, we
can update the texts for roles/profiles that we have changed, for example, in the child
systems. The texts in the child systems are stored temporarily so that they are available in the
central system. As the comparison requires some time, it is performed asynchronously and
the current texts may not be available immediately.
We can only assign profiles to users for the systems in which they are distributed. If we enter
a new system when we assign profiles to users, the system displays a warning that the user
was assigned a new system. The entry is automatically transferred into the tab page Systems.
After this, the user master record is also distributed in the new system.
During text comparisons from child systems, the names of the generated profiles for the role
are not copied to the central system, that is, only assigned profiles are displayed on the
Profiles tab page (such as SAP_ALL or SAP_NEW), but no generated profiles of the roles.
All user master records are created in the user master records. Users can then only log onto
the central system if the central system itself is entered in Systems tab page of the
corresponding user master record.
Note:
We can display the global user data from a child system in the User Information System.
Further Information
As well as the authorizations already mentioned, we also need another authorization in the
central system for object S_USER_SYS. We can only assign new systems to a new user with
this authorization.
When a user is deleted in the central system, the system entry for the user is retained until the
deletion is confirmed. If an error occurs, we can repeat the deletion by canceling the system
(in the child system).
In the child systems, the RFC user is output as the last person to make changes. Choose an
appropriate name when we set up the RFC user.
Password Status
The Logon Data tab page and the dialog box for changing the password on the initial screen
of user administration transaction SU01 always display the status of the password.
The meaning of these displays depends on whether the system is a CUA central system with
global initial password assignment or a standalone system (or a CUA central system with an
equivalent setting in the CUA distribution parameters, such as initial password = proposal).
Standalone System
The password status corresponds to the status in the database.
CUA Central System
The password status corresponds to the initial password to be newly assigned before saving,
since it is not possible to determine and display the individual password statuses from the
child systems.
Depending on the type of password change, the password status is changed to Password
deactivated or Initial password (set by administrator).
Possible Password Statuses
Initial password (set by administrator)

The user administrator (and not the user himself or herself) assigned this password. The user
is prompted to change the password at his or her next logon, to ensure that only he or she
knows the password.
Productive password
The password was set by the user.
Password deactivated
The password has been deactivated, that is, the user can no longer log on to the system with a
password.
Special Features of Password Status for Special User Types
The password for the user types service and system can only have the status productive
password or password deactivated. When creating a reference user, it is no longer necessary
to specify a password. Since it is not possible to log on at all with a reference user, the
password is automatically deactivated for a reference user. This also applies when copying
and renaming a user of type Reference.
In addition to the user type Reference user, the system displays the message Logon not
possible. If we change any user type to a reference user, the previous password and password
status (relating to the previous user type) and always retained.
Additional Information on the Logon Data Tab Page
If a users password has not been deactivated, the Logon Data tab page displays the following
information in the first line under password, in the specified order:
If profile parameter login/disable_password_logon is activated: Password logon not

possible (deactivated system-wide)
If the user has been locked due to incorrect logon attempts: Password logon not possible
(too many incorrect logon attempts)
If profile parameter login/password_max_idle_initial is activated: Password logon not

possible (initial password has expired)
If profile parameter login/password_max_idle_productive is activated: Password logon

not possible (productive password has expired)
User Group
To assign the user to a user group, enter the group. This is necessary if we want to distribute
user maintenance among several user administrators. Only the administrator that has
authorization for a group can edit users of the group. If we leave the field empty, the user is
not assigned to any group (see Assigning User Groups). This means that the user can be
maintained by any user administrator.
User Type
We can specify the following user types:
Dialog (A)
Individual system access (personalized)
It is possible to log on using SAP GUI. The user is therefore capable of interaction
through SAP GUI.
The system checks whether the password has expired or is initial.
The user can change his or her password himself or herself.
Multiple dialog logons are checked and, where appropriate, logged.

Purpose: for individual human users (including Internet users)
System (B)
System-related and internal system processes.
It is not possible to log on using SAP GUI. The user is therefore incapable of
interaction through SAP GUI.
The password change requirement does not apply to the passwords, that is, they cannot
be initial or expired.
Only a user administrator can change the password.
Multiple logons are permissible.
Purpose: background processing and communication within a system (internal RFC

calls) and between multiple systems (external RFC calls). Purpose: for example, RFC users
for ALE, workflow, TMS, CUA.
Communications (C)
Individual system access (personalized)
It is not possible to log on using SAP GUI. The user is therefore incapable of
interaction through SAP GUI.
Although the system checks whether the password has expired or is initial, the
implementation of the requirement to change the password, which exists in principle, depends
on the logon method (interactive or non-interactive).
The user can change his or her password himself or herself.
Purpose: external RFC calls of individual human users.
Service (S)
Shared system access for a larger, anonymous group of users. Assign only very
restricted authorizations for this user type.
It is possible to log on using SAP GUI. The user is therefore capable of interaction
through SAP GUI.
During a log on, the system does not check whether the password has expired or is
initial.
Only a user administrator can change the password.
Multiple logons are permissible.
Purpose: Anonymous system access (such as for public Web services). After an
individual authentication, an anonymous session begun with a service user can be continued
as a person-related session with a dialog user.
Reference (L)
It is not possible to log on to the system.
User type for general, non-person related users that allow the assignment of additional
identical authorizations, such as for Internet users created with transactions SU01.
To assign a reference user to a dialog user, specify it when maintaining the dialog user on the
Roles tab page. In general, the application controls the assignment of reference users. This
assignment is valid for all systems in a Central User Administration (CUA) landscape. If the
assigned reference user does not exist in a CUA child system, the assignment is ignored.
We should be very cautious when creating reference users.
If we do not implement the reference user concept, we can deactivate this field in
accordance with SAP Note 330067.
We also recommend that we set the value for the Customizing switch
REF_USER_CHECK in table PRGN_CUST to "E". This means that only users of type
REFERENCE can then be assigned. Changing the Customizing switch affects only new
assignments of reference users. Existing assignments are retained.
We further recommend that we place all reference users in one particularly secure user
group to protect them from changes to assigned authorizations and deletion.
Note:
Prior to Release 4.6C, the SAP System categorized users into two basic types: dialog users
and non-dialog users (also referred to as CPIC users or background users). We recommend
using non-dialog users for communications between systems where the user ID and password
are defined in the system (for example, in RFC destinations between systems). This ensures
that no one logs on for a dialog session with this user.
We recommend assigning the appropriate user type when creating users. For example, if the
user does not need dialog access to the SAP system, define it as a system user. If the user is
an anonymous, public user that many different individuals can use, define it as a service user
and keep its authorizations to a minimum.
Valid from... and Valid to...
We define the validity period of the user master record with these fields. If we do not want to
restrict the validity, leave the fields empty.
Account Number
For each user or user group, assign an account name or number of our choice. The user
appears in the computing center accounting system (ACCOUNTING EXIT) under this
number.
A suitable account number would be the users cost center or company code, for example.
We recommend that we always enter an account name or number in the computing center
accounting system. The user will otherwise be assigned to a general category without account
number.
SNC Tab Page
This tab page is only displayed if we are using Secure Network Communications (SNC). It
contains the following fields:
SNC Name
The SNC name is the user name from SAP NetWeaver Single Sign-On or the external
security product that we copy from there and either enter in this field or in table USRACL. A
unique that is a canonical SNC Name is also generated for storage in the database.
Allow password logon for SAP GUI (user-specific)
This indicator only has an effect when secure network communication (SNC) has been
enabled and password logon over SAP GUI is allowed for specific users. For this condition to
apply, we must set the following profile parameters:
snc/enable = 1
snc/accept_insecure_gui = U
The SNC Status indicates the status of these profile parameters.
If the profile parameters are set as described above, use this indicator to determine whether
the user is forced to log on with their SNC name or not.
By default, Allow password logon for SAP GUI is not selected, meaning the user can only
log on with their SNC name, provided a mapping exists between the SNC name and the user
account.
When Allow password logon for SAP GUI is selected, the system allows the user to log on
without their SNC name, using user ID and password. If the system receives an SNC name
and a mapping exists for that user, the user can still log on securely, even if logon with
password is allowed.
See also:
The SNC user manual in the SAPService Marketplace

(http://service.sap.com/security) Security in Detail Secure System Management
SAP Note 66687: Use of Network Security Products

Secure Network Communications (SNC)
Purpose
Secure Network Communications (SNC) integrates SAPNetWeaver Single Sign-On or an

external security product with SAP systems. With SNC, we strengthen security by using
additional security functions provided by a security product that are not directly available
with SAPsystems.
Note:
If we are using standard protocols such as HTTP, then we can use the Secure Sockets Layer
(SSL) protocol to provide such protection.
Implementation Considerations
There are regulations in various countries that restrict the use of encryption in software
applications. Pay close attention to the regulations that apply to our area of application.
Features
SNC secures the data communication paths between the various SAP system client
and server components of the SAP system that use the SAP protocols RFC or DIAG. There
are well-known cryptographic algorithms that have been implemented by security products
supported and with SNC; we can apply these algorithms to our data for increased protection.
With SNC, we receive application-level, end-to-end security. All communication that

takes place between two SNC-protected components is secured (for example, between the
SAP GUI for Windows and the application server).
We can use additional security features that SAP does not directly provide (for example,
the use of smart cards).
We can change the security product at any time without affecting the SAP business
applications.
Levels of Protection
There are three levels of security protection we can apply. They are:
Authentication only
Integrity protection
Roles Tab Page
We assign authorizations for accessing the SAP System to a user on the Roles tab page.
Note:
After an upgrade or release change, we must regenerate and revise the role profiles
(generated profiles). To do this, choose Environment Installation/Upgrade (transaction
SU25).
Table
We can enter any number of roles, the validity of which we can restrict with the Valid from
and Valid to columns. If we choose input help for these columns, the system displays a
calendar in which we can select the date.
Reference User for Additional Rights
To assign additional authorizations to a user, we can also assign a reference user to it (see
Logon Data Tab Page).
Special Features if You Are Using Central User Administration (CUA).
If we are using Central User Administration with the field distribution setting Global for the
Role field (transaction SCUM), the Roles tab page in the central system has the following
special features:
The additional column System that specifies the system in which the role is valid
The additional pushbutton Text Comparison, with which we can make the profile and
role names of the child systems known to the central system
Assigning Roles
Use
Assign roles to the users in the SAP System so that they receive authorizations to execute
functions. We have the following options:

Assign the Role to Users in Role Maintenance (Transaction PFCG)
Assign the Role to Users Using the SAP Easy Access Menu.
We are assigning roles to users in user maintenance (transaction SU01) (explained in

the procedure below).
Note:
Collective roles are automatically broken down. The individual roles contained within them
are entered.
Prerequisite
We have created the roles that we want to assign to the users.
Assigning Roles to Users in User Maintenance
1.
Choose Tools Administration User Maintenance Users (transaction SU01).
2.
Specify the user to which we want to assign one or more roles.
3.
Specify any number of roles on the Roles tab page.
4.
To assign a role to a user for a limited time, specify a date in the Valid from or the
Valid to column. We can use the input help calendar to do this.
Note:
To assign additional authorizations to a user, we can also assign a reference user for
additional rights to it (see Logon Data Tab Page).
Special Features for an Active Central User Administration (CUA)
Column System
The system also displays the column System on the Roles and Profiles tab page. It specifies
the system for which we have assigned the role or profile for each entry.
Reference user
This assignment of a reference user is valid for all systems in a CUA landscape. If the
reference user does not exist in a CUA child system, the assignment is ignored.
Text comparison from child sys.

On the Roles and Profiles tab pages in the central system of the CUA, we can choose Text
comparison from child system, to inform the central system about the names of the roles and
profiles that exists in the child systems. Only then can we display and select roles from the
child systems in the central system using the input help. We cannot assign roles from child
systems manually without a text comparison.
We can choose the roles obtained through the Text comparison for external systems. If these
are composite roles, the composite roles in the target system must consist of local single
roles. For our own system, we can enter the roles that can be maintained with role
maintenance. This can also be single roles that are tied to the system (single roles with a
target system attribute) and composite roles containing single roles that are tied to the system
and local single roles.
Profiles Tab Page
On the Profiles tab page, we assign manually created authorization profiles and therefore
authorizations to a user. The generated profiles of the roles assigned to the user are also
displayed here.
Authorization Profile (BC-SEC-USR)
User Administration (BC-SEC-USR)
An element of the authorization concept.
Authorization profiles give users access to the SAP System. They contain authorizations,
which are identified using the name of an authorization object and the name of an
authorization. If a profile is specified in a user master record, the user is assigned all of the
authorizations defined in this profile.
Note:
Never enter the generated profiles directly on the Profiles tab page, as transaction PFUD
deletes these assignments if there is no entry for them on the Roles tab page. When we assign
a role to a user on the Roles tab page, the profile generated for this role is automatically
entered on the Profiles tab page (see Assigning a Role and Comparing Profiles in the User
Master Record with Roles).
We can assign 300 authorization profiles to a user (see SAP Note 410993).
We can manually maintain profiles by choosing Tools
Administration
User Maintenance
Manual Maintenance
Edit Profiles Manually (see Creating and Maintaining Authorizations and Profiles
Manually); however, we recommend that we use the Profile Generator instead, and generate
the profiles automatically. We can enter composite profiles (a combination of several profiles)
in the user master records when manually maintaining profiles.
The SAP system contains predefined profiles, the most important of which are explained
below:
SAP_ALL: To assign all authorizations that exist in the SAP system to users, assign
the profile SAP_ALL.
Authorization Profile SAP_ALL
This composite profile contains all SAP authorizations, meaning that a user with this profile
can perform all tasks in the SAP system. We should therefore not assign this authorization
profile to any of our users. We recommend that we create only one user with this profile. We
should keep the password of this user secret (store it in a safe) and only use it in emergencies
(see also Protective Measures for SAP*).
Instead of using the SAP_ALL profile, we should distribute the authorizations it contains to
the appropriate positions. For example, instead of assigning our system administrator (or
super user) the authorization SAP_ALL, assign him or her only those that apply to system
administration, namely the S_* authorizations. These authorizations give him or her enough
rights to administer the entire SAP system, without allowing him or her to perform tasks in
other areas such as Personnel.
SAP_NEW: Composite profile to bridge the differences in releases in the case of new
or changed authorization checks for existing functions, so that our users can continue to work
as normal. This composite profile contains very extensive authorizations, as, for example,
organizational levels are assigned with the full authorization asterisk (*).
Temporarily assign either the composite profile SAP_NEW, suitably adjusted beforehand, or
the relevant single profile SAP_NEW_<Release> contained in the composite profile. We
require all single profiles between the old release and the new release. For example, if we are
upgrading from SAP R/3 4.5B to SAP R/3 4.6C, we require the following SAP_New profiles:
SAP_NEW_4.6A, SAP_NEW_4.6B and SAP_NEW_4.6C. The simplest way to make these
assignments is to delete all other single profiles from SAP_NEW and to assign SAP_NEW.
Once we have incorporated the new authorization checks in our authorization concept, delete
the SAP_NEW profile to avoid assigning authorizations that are too extensive.
Authorization Profile SAP_NEW
This composite profile contains a single profile for each release that contains the
authorizations that the users require to be able to continue using the functions that they have
used until now, but which are protected with new authorization checks. However, we should
not leave this profile active for a long period of time.
We recommend that we perform the following steps:
1. After the upgrade, delete the SAP_NEW_* profiles from the composite profile
SAP_NEW for releases before the last revision of our authorization concept.
2. Assign the composite profile SAP_NEW to all users. This means that they can
continue to use the functions that they have used until now.
3.
Distribute the authorizations contained in the SAP_NEW single profiles to the roles
or profiles that we use productively and maintain the authorization values.
4.
Delete the profile assignment for SAP_NEW and the SAP_NEW profile.
A long list of SAP_NEW profiles (for example, after multiple upgrades) indicates that it is
time to revise and redefine our authorization concept.
Note:
We must add the new authorizations to manually generated profiles
SAP_APP: This profile contains all application authorizations. It is not included in

the standard SAP system; however we can generate it with the report
REGENERATE_SAP_APP. We can decide when executing this report whether authorizations
for the SAP NetWeaver and HR areas should be included.
Special Features if You Are Using Central User Administration (CUA).
If we are using Central User Administration with the field distribution setting Global for the
Profiles field (transaction SCUM), the Profiles tab page in the central system has the
following special features:
The additional column System that specifies the system in which the manually
generated profile is valid
The additional pushbutton Text Comparison, with which we can make the profile and
role names of the child systems known to the central system
The profiles generated by the assignment of roles are no longer displayed (these
profiles are only displayed in the child systems in which they are valid)
Comparing User Master Records
Use
The user master record comparison consists of three types of comparison:
The profile comparison

With this, the profiles of time-dependent role assignments are updated.
Note:
We cannot set time limits for authorization profiles and their entry in user master records.
The composite roll area

This updates the role assignments defined in composite roles, that is, added or deleted.
The organizational management comparison

This generates the direct role assignments from the indirect role assignments of the
organizational management model.
We can also choose the Clean-Ups option to delete invalid, generated profiles, and invalid
role assignments.
Procedure
1.
Start transaction PFUD.
2.
Specify the roles that we want to use for the comparison.
3.
Choose one of the following actions:
Schedule or check job for the full comparison

Here we can start report PFCG_TIME_DEPENDENCY by specifying the time when the job
is to start. The overview displays the status of background jobs that have already been
scheduled.
If we schedule the report PFCG_TIME_DEPENDENCY daily before the start of business as
a total comparison and it runs error-free, the authorization profiles in the user master are upto-date every morning.
If we choose this action, all four processes types are always included, regardless of our
selection under Processing Type. To execute only certain processing types of the comparison
as a background program (for example, with the aim of improving runtime behavior); choose
Perform User Master Comparison and the desired processing types. Then choose Save, to
schedule a variant of the program RHAUTUPD_NEW.
Performing the User Master Comparison

With this action, we start the user master comparison in dialog for individual roles. We can
select the required processing types (see 4.).
4.
If we have selected Perform User Master Comparison, choose one or more of the
following processing types:
Profile Comparison: Start the profile comparison immediately after generating or

importing profiles. If we are using time-dependent role assignments, we recommend that we
schedule this daily as a background job. This compares the authorization profiles with the
user master records; that is, profiles that are no longer current are deleted from the user
master records and the current profiles are entered in the user master records.
Composite role comparison: Start the composite role comparison if we make changes
to a composite role definition (that is, if we add or delete single roles to a composite role) or
import a change. Single-role assignments are compared with the composite role assignments
for the user. If we add single roles to the composite role, the single roles are assigned to those
users that are assigned the composite role. Conversely, if single role assignments are deleted
for the users, the single role is removed from the composite role.
HR comparison: Start the HR comparison, if we make changes to our local

organizational management model that influence the indirect role assignment or transport
these to the system. We can only select this processing type if organizational management is
active; that is, if the switch HR_ORG_ACTIVE is set in the table PRGN_CUST to YES.
Clean-Ups: Perform clean-ups when we generate or import profiles. Generated profiles

that no longer exist are deleted. Regular clean-ups are particularly important if we transport
our roles and profiles frequently, as this helps to solve possible inconsistencies quickly.
We can also select the following options:
Display error messages: All error messages are displayed on the screen in dialog
mode.
Replicate local HR assignments in the central system: We can only select this option
if we are in a child system of a CUA group and if organizational management is active. This
option replicates the role assignments that exist in the child system that originate through
relationships in the local organizational management model, for information in the CUA
central system. We can display these relationships in the user maintenance (transaction
SU01).
Result
Following the comparison the system displays a log that includes any errors that occurred
(background processing log for a background job).
Groups Tab Page
We assign the user to a user group on this tab page. This is purely a grouping that is suitable,
for example, for mass maintenance of user data (transaction SU10).
Assignments that we make on the Groups tab page are not used for authorization checks that
are specified on the Logon Data tab page using the User Group field.
Personalization Tab Page
On the Personalization tab page, we can make person-related settings using personalization
objects. We can call this tab page both in role maintenance and in user maintenance. The
procedure for personalization is the same.
Personalizing User or Role
1. As the Personalization tab page is available both in user and role maintenance, we have
the following options:
To perform a personalization for a user, choose Tools Administration User

Maintenance Users (transaction SU01).
To perform a personalization for a role, choose Tools Administration User

Maintenance Roles (transaction PFG).
2.
Enter the role in the Role field and choose Change.
3. To display the application components on the left side of the screen on the
Personalization tab page, choose By Application Components on the Personalization tab
page. ( ).
4.
Select the components for which we want to maintain personalization data by double
clicking them.
The personalization objects for the component are output on the right-hand side.
Example of the Personalization Tab Page
To change the values of a personalization object, choose Change ( ) or select the object by
double clicking it.
A dialog box for entering default values appears.
The opportunity to create personalization objects provides a framework for application
development with which user-dependent data can be easily saved for an application.
To use the framework, we must simply create a key, under which the user-dependent data is
to be saved. The data can then be stored in the application simply by calling an interface
direct to a generic data repository. We can specify if changing the data for this key should
also be performed with the user administration. To do this, the application must provide a
dialog window that can be called in the user maintenance for the personalization key.
In addition to using the generic storage of personalization data, it is possible to connect our
own tables with user-dependent data to user administration using the framework. For more
information, see Central Store for Personalization Data.
Central Repository for Personalization Data

The purpose of a central repository for personalization data is to provide storage for userspecific and role-specific data without having to create any additional database tables. This
data should be taken into consideration whenever users or roles are changed.
Another aim was to integrate existing user-specific tables in the concept using a given
interface.
Features
The functionality includes a generic repository for user-specific and role-specific data and for
central access to this data by user and role maintenance. It also permits existing tables
containing user-specific data to be linked to the central access using a fixed interface.
A key must be assigned for personalization data to be stored in the central repository. This
can be done with registration transaction PERSREG.
Generic Repository for Personalization Data
The generic repository is used to store the personalization data. It can be accessed with the
class methods of class CL_PERS_ADMIN.
Generic Repository
The data can be stored either as simple values, structures or internal tables. As fields,
structures can only contain elementary data. Internal tables can contain structures or
elementary data as rows.
Note:
The internal tables must be defined as table types. Tables with a header line (for example: like
TSTC occurs 0 with header line) cannot be used.
The data types used need not be stored in the Dictionary.
Selective Access
If an internal table was selected as the data type for the personalization data, we can read only
parts of the table when we access the data. Selection conditions can also be defined for any
fields of the internal table. The conditions are passed in the form of field name-field value
combinations when we read the data.
Similarly, we can update only parts of the stored internal table. In this case the fields to be
used as keys for the modification must be defined when the data is written.
Type Check
The type check when reading or writing is not very strict. If the type with which the data was
written in the repository is not the same as the type with which the data is read, there is only
an error if the individual fields do not have the same length. If other changes are made to the
type, e.g. if the name of the field changes, the fields might not be completely defined.
Buffering
A buffer can be used when the data is written. In this case the data is only written to the
database when the corresponding method is called.
Different Levels of Personalization
The data can be stored either for the user, for roles or for the system. In this case all the data
assigned to a user (with the role or with ones own setting) can be read at one time.
Central Access to Personalization Data
We can access the personalization data from user administration or from role administration.
Transactions SU01 and PFCG were enhanced to cope with this situation.
We can also access the data from a maintenance transaction for personalization.
The use of the generic repository for personalization data is explained in the following
documentation:
Use of the Generic Repository
Implementing a Dialog
Integrating External Tables

Registering Personalization Objects
Licence Data Tab Page
Use
We specify the contractual user type of the user on this tab page.
For more information about user types, see the SAP Service Marketplace under the path
http://service.sap.com/licenseauditing System Measurement Named User User
Classification.
If we are using Central User Administration, we can edit the user types in the central system
using User Maintenance (transaction SU01) or Mass User Maintenance (transaction SU10).
The following requirements must be fulfilled:
Central and child systems have a release status of at least SAP Web AS 6.20 and SAP
Note 704412 is installed
In transaction SCUM, the maintenance of the license data is set to Global (see Setting
Distribution Parameters for Fields). This is the default setting for a new installation of the
CUA.
Setting Up Field Distribution Parameters
Use
If we are using Central User Administration, we can use the distribution parameters in
transaction SCUM to determine where individual parts of a user master record are
maintained.
In the central system
Locally in the child system
In the child system with automatic redistribution to the central system and the other
CUA child systems
Every input field of the user maintenance transaction SU01 has a field attribute that we set
once in the central system with transaction SCUM during Customizing. As far as possible, we
should then not change the field maintenance indicator at all.
Warning:
If we later change the distribution from Local or Proposal to Global or Redistribution, data
inconsistencies can occur.
User Master Record
Record that contains important master data for a user in the SAP system. The user master
record contains the assignment of one or more roles to the user. In this way, a user menu and
the corresponding authorizations for the activities contained in the user menu are assigned to
the user. Only users who have a user master record can log on to the system.
We must be particularly careful when removing inconsistencies, since data is lost when we
switch system-dependent parameters from local to global maintenance and then distribute the
users again. The distribution creates the central system status in all child systems. If we have
previously maintained system-dependent data, such as the user assignment of roles, this data
is unknown to the central system. This means that when we distribute the central system
entries, we overwrite the role assignments of the child system. This system-specific data is
therefore permanently lost.
To recreate data consistency after changing the field distribution parameters, proceed as
follows:
To maintain cross-system parameter (such as printers) globally rather than locally,

set the parameter appropriately and then redistribute the users from the central system to the
child systems. This means that the central system status is adopted in all child systems.
Caution:
To maintain system-dependent parameters (such as role or profile assignments) globally
rather than locally, we must not redistribute the users. Instead, we must remove the CUA and
set it up again, so that we can copy the users and their system-specific data from the child
systems into the central system again. After completely removing the CUA and setting it up
again, the field distribution parameters are set to "global" by default. Check these settings
before we transfer the users again with transaction SCUG.
The only exception to this is the Locks tab page. We can change the indicators on this tab
page at any time without any risk.
Procedure
1.
Log on to the central system (in this example, ADM, client 070).
2.
In the Implementation Guide (IMG, transaction SALE), choose Modeling and
Implementing Business Processes Predefined ALE Business Processes CrossApplication Business Processes Central User Administration Set Distribution
Parameters for Fields (transaction SCUM).
The system displays the User Distribution Field Selection screen, with tab pages of the fields
whose distribution parameters we can set. To display additional fields, choose page down.
We can select the following options on the tab pages:
Global
We can only maintain the data in the central system. The data is
then automatically distributed to the child systems. These fields
do not accept input in the child systems, but can only be
displayed.
Note:
All other fields that are not set to global accept input both in
the central and in the child systems and are differentiated only
by a different distribution after we have saved.
Proposal
We maintain a default value in the central system that is
automatically distributed to the child systems when a user is
created. After the distribution, the data is only maintained
locally, and is not distributed again, if we change it in the
central or child system.
RetVal
We can maintain data both centrally and locally. After every
local change to the data, the change is redistributed to the
central system and distributed from there to the other child
systems.
Local
We can only maintain the data in the child system. Changes are
not distributed to other systems.
Everywhere We can maintain data both centrally and locally. However, only
changes made in the central system are distributed to other
systems, local changes in the child systems are not distributed.
3.
To maintain the other parameters, too, switch to the other tab pages. The tab pages
correspond to those of user maintenance.
4.
Save our entries.
The distribution parameters are automatically transferred to the child systems.
Locks Tab Page
We can control the distribution of lock data on this tab page, and therefore determine which
locks can be set and/or reset in which systems. When we reset locks, we must pay close
attention to the lock indicators in the user master record that can be combined in any way we
choose, and the functions available in this system, so that we can set the indicators on the
Locks tab page appropriately.
A user cannot log on to a child system of a CUA. The local administration removes the lock.
However, this removal refers only to a local lock that may exist in the user master record.
Global locks, or, if the indicator for Locked due to incorrect logons is set to global, locks due
to incorrect logon attempts, are not removed by this. Therefore, if the local administration
should be able to remove locks due to incorrect logon attempts, we must not set the indicator
for Locked due to incorrect logons to global in transaction SCUM.
To be able to unlock a user from the central system after an incorrect logon attempt or for
local locks in a child system, set the indicator everywhere for the lines Unlock incorrect.
Logon and Unlock locally.
The following functions are available in the respective systems:
Lock globally: This function is only available in the central system. The request to lock
or unlock is sent to all child systems and performed there.
Unlock globally: This function is only available in the central system. The request to
lock or unlock is sent to all child systems and performed there.
Unlock incorrect logon globally: This function is only available in the central system.
The request to lock or unlock is sent to all child systems and performed there.
Lock locally
Unlock locally: This function attempts to remove all three possible lock indicators:
Locked due to incorrect logons, global lock, and local lock.
Unlock incorrect logon locally

Selection on the Locks Tab Page
Field
Unlock
Incorrect.
Logon
Explanation
Controls the
removal of the
indicator Locked
due to incorrect
logons
Lock
Locally
Controls the
setting of the
locked locally
indicator
Unlock
Locally
Controls the
removal of the
locked locally
indicator
Global
Removal of the
indicator Locked
due to incorrect
logon using the
unlock globally
function is
allowed
Local
Removal of the
indicator Locked
due to incorrect
logon using the
unlock locally
function is
allowed
Setting the
indicator locked
locally using the
lock locally
function is
allowed
Removing the
indicator locked
locally using the
unlock locally
function is
Everywhere
Removal of the
indicator Locked
due to incorrect
logon using the
unlock locally
function is
allowed
Removal of the
indicator Locked
due to incorrect
logon using the
unlock globally
function is also
allowed
Removing the
indicator locked
locally using the
unlock locally
function is
allowed
Lock
Globally
Controls the
setting of the
locked globally
indicator
Unlock
globally
Controls the
removal of the
locked globally
indicator
Setting the
indicator locked
globally using the
lock globally
function is
allowed
Removal of the
locked globally
indicator using
the unlock
globally function
is allowed
allowed
Removal of the
indicator locked
locally using the
unlock globally
function is also
allowed
Removal of the
locked globally
indicator using
the unlock
globally function
is allowed
Removal of the
indicator locked
globally using the
unlock globally
function is also
allowed
Recommendations for Other Fields

Field
Setting
Printer
Proposal
Parameters
Proposal
Group (Gen.)
Proposal
Fields for data that the
Redistribution
users maintain themselves
See also:
SAP Note 313945: CUA: Incorrect logon locks not globally reversible
We have transferred the users with all of their data (address data, license data, and so
on) from the child systems to the central system (see Transferring Users from New Systems)
Transferring Users from New Systems
Use
If we include a new system in the distribution model selected, we must make sure that the
user master records in the new system are transferred to the central system.
Prerequisites
We have synchronized the company addresses.
Procedure
1.
Log on to the central system (in this example, ADMCLNT070).
2.
In the Implementation Guide (IMG, transaction SALE), choose Modeling and
Implementing Business Processes Predefined ALE Business Processes Central
User Administration Transfer Users from New Systems (transaction SCUG).
The system displays the Central User Administration Structure Display screen with a
Tree structure of the systems of the distribution model. The systems with New
indicators
contain user master records that are not contained in the Central User Administration.
3.
If we are setting up a completely new Central User Administration, place the cursor on
the central system and choose Transfer Users.
The system displays the following tab pages:
New users
Identical users
Different users
Already central users
4.
5.
These users are not yet contained in Central User

Administration. By choosing Transfer Users, we
can transfer the selected users into the central
system. This transfers all user parameters such as
address and logon data, as well as profiles and
roles. In the future, the user will be maintained
centrally.
These are users with identical user IDs (that is,
their name and user name is the same). The roles
and profile data for this user can be transferred to
the central system. The user is then distributed and
therefore appears as it is stored in the central
system. Local data is overwritten.
These user IDs are contained in both the central
and the child systems, but with different data.
Note:
If in a single case, the users are actually the same
user, we can transfer the roles and profile data for
the user to the central system. The user is then
distributed as it exists in the central system.
If these are two different users, create a new user
ID for one user in the central system, and delete
this user in the child system.
These users are already in the Central User
Administration under the same name and are
maintained centrally.
Select all new and changed users and choose Transfer Users.
Perform steps 3 and 4 successively for all child systems from which we want to transfer
users.
6.
After we have completed the user transfer, remove the roles
Z_SAP_BC_CUA_SETUP_CENTRAL and
Z_SAP_BC_USR_CUA_SETUP_CLIENT from the system users.
These roles are only required to set up the CUA, but not for its operation. By restricting
the authorizations of the system users to the minimum level, we increase the security of
our system landscape.
7.
Use transaction SCUL to check the distribution of the users after the transfer.
Note:
Users that we have not copied to the central system can still be maintained in the child
system. This means that the functions Create and Delete are still displayed in the user
maintenance. These functions are no longer available only after the complete transfer of all
users.
8.
Save our entries.
The application toolbar contains the following pushbuttons:

License data
References
The License Data tab page appears, so that we can enter

measurement-relevant data. For more information, see the
System Measurement Guide on the SAP Service Marketplace
(http://service.sap.com/licenseauditing) System
Measurement Named User Documentation.
This function allows the application developers to assign a
business object to a user, to, for example, display this users own
data. In transaction SU01, it is used only for display.
A table appears in which we can assign business object types to a
user. An object type is a description of data (objects) used in the
system, created at definition time in the Business Object
Builder. An object is any type of connected information that is
addressed with a unique key; such as master data (customer,
material, vendor, and so on).
The possible entries help for the Object type field lists all
available object types.
Note:
This function is not the same as assigning reference users on the
Roles tab page.
Business Object Builder

Use
We can use the Business Object Builder to create, display or change object types in the
Business Object Repository.
Integration
If we want to display or change a defined object type in the Business Object Builder, we must
know its ID, name or description.
If we do not know the object type precisely or if we are not sure whether there is an
appropriate object type, we can find an object type using its position in the component
hierarchy or using its relationships to other object types. In this case, use the Business Object
Repository Browser.
Runtime objects are based on object types.
Features
Various functions such as check, test, generate, or where-used list are available. We can also
create subtypes of an existing object type or determine a delegation type .
More information:
User Administration Functions
User Information System
Use
We can use the User Information System (transaction SUIM) to obtain an overview of the
authorizations and users in our SAP system at any time using search criteria that we define. In
particular, we can display lists of users to whom authorizations classified as critical are
assigned.
Note:
To explicitly search for authorizations that contain the full authorization asterisk (*), we need
to enter a number sign (#) before the asterisk, that is, search for #*. Otherwise, the system
searches for any values.
We can also use the User Information System to:
Compare roles and users
Display change documents for the authorization profile of a user
Display the transactions contained in a role
Create where-used lists

Recommend that we regularly check the various lists that are important for us. Define a
monitoring procedure and corresponding checklists to make sure that we continually review
our authorization plan.
Especially recommend we determine which authorizations we consider critical and regularly
review which users have these authorizations in their profiles.
The possible evaluations are described in the following sections:
Determining Users with the Users Node
Determining Roles, Profiles, Authorizations, and Authorization Objects
Determining Transactions
Comparing Cross-System Users, Authorizations, Roles, and Profiles
Creating Where-Used Lists for Profiles
Creating Where-Used Lists for Authorization Objects
Creating Where-Used Lists for Authorizations
Creating Where-Used Lists for Authorization Values
Determining Change Documents

Determining Users with the Users Node
There are a number of evaluation options available to us using the Users node. These are
explained below.
Cross-System Information
Users by Address Data (RSUSR002_ADDRESS)

We perform the procedure for evaluating with generic input options (placeholder asterisk and
multiple selection). To obtain a result, the corresponding criteria, such as room, must be
maintained in the user data.
Users by Complex Selection Criteria (RSUSR002)
By Critical Combinations of Authorizations at Transaction Start (RSUSR008)
With incorrect logon attempts (RSUSR006)

This evaluation is started immediately without additional selection criteria when we choose
Execute in the User Information System. The result list displays all users with incorrect logon
attempts:
Number of incorrect logon attempts (users that are not locked)
Users locked due to incorrect logon attempts
Users locked by administration
Users locked globally in the central system (if we are using CUA)
Users locked locally and globally by the administration (if we are using CUA)
This evaluation also displays the date and time of the last logon.
By logon date and password change (RSUSR200)
With critical authorizations (RSUSR009)
With Critical Authorizations (New Version) (RSUSR008_009_NEW)

Determining Cross-System Information
Prerequisites
We can only perform these evaluations in the central system of a Central User Administration
(CUA). This also means that we can only use these reports if we are using a CUA.
Procedure
The procedure is explained using an example of Users by System
(RSUSR_SYSINFO_ZBV). To, for example, display the list of users on a child system,
follow the procedure below:
1.
Start the user information system (transaction SUIM) in the central system of the central
user administration.
2.
Expand the nodes Users and Cross-System Information (Central User-Administration).
3.
Choose the Execute option next to Users by System.
4. We now have the following options:
To determine the CUA systems in which a certain user exists, enter the name of
the user, and then choose Execute.
To determine all or some of the users in one or more CUA systems, either enter
the user name only a placeholder or some of the name and the placeholder, such as
FER*.
Result
The result list appears. Depending on our selection, the user names and receiving systems are
displayed as well as the last outbound IDoc number of the respective user master record.
For the reports Users by Role and Users by Profile, we can restrict the selection further:
Users by Role (RSUSR_SYSINFO_ROLE)

We can use this report to display, system-specifically, which roles are assigned to users, or the
users to which specific roles are assigned.
We can restrict the selection using the name and validity of the role assigned to the user: all
roles that exist and that are valid today or during a particular time period.
Users by Profile (RSUSR_SYSINFO_PROFILE)
We can use this report to display, system-specifically, which manual profiles are assigned to
the users, or the users to which specific manual profiles are assigned.
We can restrict the selection using the names of the profiles assigned to the user. For
example, to find all users with the profile SAP_ALL in all child systems, enter SAP_ALL in
the Profile field and choose Execute.
Users by Complex Selection Criteria (RSUSR002)
Use
This evaluation provides a total screen Users by Complex Selection Criteria on which
subordinate selection criteria that can also be used directly (such as by user name, by role, by
authorization values) are combined. To obtain users, restrict the selection by entering data in
the fields. If we execute the report without making any entries, all users of the current system
are displayed.
Procedure
To compare, for example, the master records of two users at the level of authorization for an
object, follow this procedure:
1.
In our SAP System, open two sessions to perform the procedure in parallel for both
authorization objects to be compared.
2.
In the user information system, choose Users Users by complex selection criteria
by user ID, or execute report RSUSR002 using transaction SA38.
3.
Specify the user name in the User field.
4.
Choose Execute.
5.
By double clicking the user name, we can display the list for the user.
6.
Select the first node <user name>, and choose Select/Expand Sub tree.
The Restrict User Values to the Following Simple Profiles and Auth. Objs screen appears.
7.
Specify the authorization object to be compared, such as F_BKPF_BUK, and choose

Execute.
Result
In the hierarchy display of the user master record, all branches that contain authorizations for
the selected object are expanded.
By Critical Combinations of Authorizations at Transaction Start (RSUSR008)
Report RSUSR008 is obsolete and has been replaced by report RSUSR008_009_NEW. We
can start this report in the User Information System by choosing Users With Critical
Authorizations (New Version).
This evaluation allows us to monitor task separation. It lists all users that simultaneously have
authorizations for up to five transactions whose combination was rated as critical. The
authorization object S_TCODE is checked.
We can use the Display Critical Combinations button to activate or deactivate the SAP
proposals for each line in the Deletion Indicator column, by choosing inactive or SAP
Proposals.
We can also permanently restrict the evaluation by critical combinations. To do this, choose
the change button Crit.Comb. To call the table of combinations and delete or change table
rows as required. However, we can only import SAP proposals again during the next upgrade.
By Logon Date and Password Change (RSUSR200)
We can determine the date of the last logon and whether the user in question has changed his
or her initial password. To do this, use either a variant with predefined selection criteria (Get
Variant) or specify selection criteria our-self (with multiple selection and generic input).
The selection criteria Days since last logon and Days since password change mean that at
least the specified number of days has passed since the last logon or password change.
We can use the following selection options to restrict the result list:
Selection by the validity of the user
Users valid today
Users not valid today

Selection by the status of the user
Users not locked
Locked users
Users with incorrect logon attempts

Selection by user type
Dialog user
Communication user
System user
Service user
Reference user
Selection by the status of the password
Users with valid password
Users with initial password
Users with inactive password

The entries in the Last Change and Password Changed columns of the result list mean the
following:
Last Change
Row
Explanation
Unused
The user has not yet logged on to this
system.
with date and time

Password Changed
Row
The user last logged on at the specified date

and time.
Explanation
The password is initial; that is, the user has
never yet changed it.
with date
The user changed his or her password on
the specified date.
with date
The user has not logged on to the system
again since the administrator changed the
password.
inactive
The password has been deactivated.
To change a user in the result list, select it and choose Select. The user maintenance
transaction (transaction SU01) appears.
With Critical Authorizations (RSUSR009)
Use
Report RSUSR009 is obsolete and has been replaced by report RSUSR008_009_NEW. We
can start this report in the User Information System by choosing Users With Critical
Authorizations (New Version).
We can use this report to determine the users that have critical combinations of
authorizations, as defined in table USKRIA.
A table entry consists of the specification of an authorization object with field name and field
value. The entries are combined using a common four-character ID and the logical linking
operators AND or OR.
Example of an Entry Schema
ID
Object
Field
From To AND/OR Text For
Color
ZT01
S_TABU_DIS ACTVT
02
03 AND
Combination1 1
ZT01
S_TABU_DIS DICBERCLS PSNO
AND
1
ZT01
S_TCODE
TCD
SU01
AND
1
In the above example, a user is displayed in the result list if all three authorizations are
contained in his or her user master record. Critical combinations for the same object must
exist in the same authorization (see SAP Note 674212). If the linkage OR was used instead of
AND, the user would be displayed in the result list if he or she had only one of the three
authorizations in his or her user master record.
We can call the maintenance dialog for creating and changing entries in table USKRIA both
on the initial screen and from the result list of the report.
Notes on Maintaining Critical Authorizations
Within one ID, use only uniform and completely entered linking operators (exclusively
AND or exclusively OR).
There is no input help available for entering authorization objects, fields, and field
values.
We can copy the defaults delivered by SAP (again) by choosing SAP Default (Control
and F3).
Warning
When we do so, we overwrite all previously maintained entries.
Table USKRIA is a cross-client table. This means that we cannot maintain this table in
systems that are locked for cross-client Customizing. In this case, we must deliver the
data by transport from the development system.
Procedure
We can restrict the evaluation by critical combinations by choosing the button Change
Crit.Comb. To call the table of combinations and deleting or changing table rows as
required.
1.
Start the user information system (transaction SUIM).
2.
Expand the Users node.
3.
Choose the option Execute next to List of Users with Critical Authorizations.
4.
Choose Change Crit. Comb.
The Entry of Critical Authorizations for Report RSUSR009 view appears, on which we
can enter the critical authorizations in a table. We can also call this screen from the result list
by choosing Change Crit. Auth.
5. We can delete the existing combinations or add new combinations by choosing New
Entries.
6.
To create new combinations, enter the required data.
For more information, see the above example.
Data of a Critical Authorization
Field
Comment
ID
Name of the authorization objects link
Object
Name of the authorization object
Field Name
Name of the authorization field. Optional
specification, without which, the system
searches in the user master records only for
the authorization object.
From
First authorization value.
Optional specification, without which, the
system searches in the user master records
only for the authorization object.
If we leave the From field empty, the
program searches for authorizations with
spaces for the specified field and object
(see SAP Note 674212).
If we enter an asterisk (*) in the From field,
the report searches for full authorization for
the specified field.
For fields with fixed values, the report
searches for authorizations that contain all
possible fixed values and displays the users
to which authorizations of this type are
assigned.
To
Last authorization value.
Optional specification, without which, the
system searches in the user master records
only for the authorization object.
AND/OR
Linkage type
Text for Critical Authorizations
Enter a short text to explain the critical
combination in the Text for Critical
Authorizations field of the first entry of
each ID. This text is displayed in the result
list after the report has been executed.
Any texts that are not in the first entry are
not taken into account.
Color
We can assign any critical combination a

number from 1 to 7 in the Color field to
define the background color of the ID in the
result list. The numbers correspond to the
following colors:
Color: 1 = blue, 2 = white, 3 = yellow, 4 =
turquoise, 5 = green, 6 = red, 7 = purple
The color code only takes effect if we
maintain it completely for all entries of the
ID, and all entries are identical. The default
setting is red.
7.
Save our entries in a transport request.
8.
Choose Back and Execute.
Result
The system displays a list of all users that have the combination of authorizations for which
we are searching.
With Critical Authorizations (New Version, RSUSR008_009_NEW)
Use
This report replaces the reports RSUSR008 and RSUSR009 and offers the following
improvements:
Differentiation between SAP defaults for critical data for different business areas.
Previously, we could only use and change defaults collectively.
Extended combination options for critical authorization data
Improved performance
Filter for the users to be displayed
More analysis options for users in the result list
Improved user-friendliness
We can either start the report using transaction SA38 or in the User Information System
(transaction SUIM) by choosing Users With Critical Authorizations (New Version).
The report is provided as of SAP Web AS 6.20 with the following Support Packages:
SAP Web AS 6.20, as of SAPKB62039
SAP Web AS 6.40, as of SAPKB64003

We can continue to use the old programs RSUSR008 and RSUSR009 until SAP Web AS
6.40. The new report is delivered with the old SAP defaults for critical authorization data,
which were already used for RSUSR009. The data is combined in the variant
SAP_RSUSR009.
Analyzing Users with Critical Authorizations
With the following procedure, we first define critical authorizations and the associated
authorization data. We then combine the critical authorizations into a variant with which we
then perform the evaluation.
1.
To maintain critical authorizations, choose Critical Authorizations on the initial screen.
A dialog box appears that displays four folders, which form two hierarchies:
Variants for Critical Authorizations Crit. Authorizations
Crit. Authorizations Authorization Data

The Critical Authorizations folder consists of the IDs of critical authorizations. Each ID
contains a list with critical data. The Ids are used to define report variants.
2.
In change mode, open the Crit. Authorization folder in the lower hierarchy by doubleclicking it, and choose New Entries.
3.
4.
5.
Specify the following data in the table control:

The name of the ID in accordance with the naming convention (customer namespace)
A text
The color in the result list
The transaction code, if required
Save our entries.
To maintain the authorization data, select the entry that we have just created and open
the Authorization Data folder by double-clicking it.
A new view appears.
a.
Choose New Entries.
b.
Fill out all required fields, which are identified with an asterisk (*).
Note the following when filling out the fields:
All entries within a group must have the same operand AND or OR. The individual
groups are essentially linked with AND. An OR link is not possible.
We can specify critical data for different authorization objects within the same group.
If we specify a transaction code for an ID, all authorization data required to execute the
transaction and maintained in transaction SE93 is automatically entered as critical data,
after we have confirmed and saved the dialog box.
If we leave the From field empty, the program searches for authorizations with spaces
for the specified field and object. If we enter an asterisk (*) in the From field, the report
searches for full authorization for the specified field. (See SAP Notes 216557 and
674212)
c.
Save your entries.
6.
Create a variant.
a.
Open the folder Variants for Critical Authorizations by double-clicking it, and then
choose New Entries.
b.
Enter the name and description of the variant.
c.
Save our entries.
7.
Assign the IDs of critical authorizations to the variant that we have just created.
a.
Select the variant and choose the Critical Authorizations folder under the Variants for
Critical Authorization folder by double-clicking it.
b.
Choose New Entries.
c.
Use the input help to choose existing IDs.
d.
Save our entries.
8.
Execute the report variant with critical authorizations.
a.
On the initial screen of the report, choose the option For Critical Authorizations under
Name of the Variant
b.
Use the input help to select an existing variant, and choose Execute.
The users identified for each ID are displayed by the program in the result list.
Analyzing Users with Critical Combinations of Authorizations
We can use the report RSUSR008_009_NEW to combine the IDs for critical authorizations
in any way, and to create variants with these combinations.
1.
To maintain critical combinations, choose Critical Combinations on the initial screen.
A dialog box appears that displays four folders in two hierarchies:
Variants for Critical Combinations of Authorizations Combination
Combination Critical Authorization

We specify IDs of critical authorizations that we have maintained in accordance with the
procedure above, and now want to combine with each other in the in the Combination folder.
A variant consists of a list of critical combinations.
2.
In change mode, open the Combination folder in the lower hierarchy by double-clicking
it, and choose New Entries.
Specify the following data in the table control:
The name
The color for the result list
The description of the combination
Save our entries.
Assign the IDs of critical authorizations to the combination.
Select the combination and open the Critical Authorization folder by double-clicking it.
Choose New Entries.
Use the input help to select IDs of critical authorizations.
Save our entries.
a.
b.
3.
a.
b.
c.
d.
Note
The selected IDs are essentially linked with AND. An OR link is not possible.
4.
Create a variant.
a.
Open the folder Variants for Critical Combinations of Authorizations by double-clicking
it, and then choose New Entries.
b.
Specify the name and description of the variant in accordance with the namespace
convention.
c.
Save our entries.
5.
Assign critical combinations to the variant.
a.
Select the variant and choose the Combination folder under the Variants for Critical
Combinations of Authorizations folder by double-clicking it.
b.
Choose New Entries.
c.
Use the input help to choose existing combinations.
d.
Save our entries.
6.
Execute the report variant with critical combinations.
a.
On the initial screen of the report, choose the option For Critical Combinations under
Name of the Variant
b.
Use the input help to choose an existing variant.
c.
Choose Execute.
The result list displays the users for each combination within the selected variant.
Additional Selection Criteria
We can use the group Selection Criteria for Users to define additional properties that the users
to be displayed must fulfill. This makes analysis quicker and more flexible.
Note that the User Group field relates to entries in the field User Group for Authorization
Check on the Logon Data tab page of user maintenance (transaction SU01), while entries in
the field User Group (General) evaluate the data specified on the Groups tab page of user
maintenance (transaction SU01).
We can use the indicator Display Only Valid Users to restrict the display to users whose
validity period covers the date of the report execution.
Evaluation of the Result List
The result lists are different, depending on the type of the selection variant:
For Critical Authorizations

The selected users are grouped by the IDs of critical authorizations. To check which critical
data is represented by an ID, click on the name of the ID. To analyze the authorization data of
a user master record, select the user by double-clicking it. The other fields provide additional
information about the user.
We can use the Profiles and Roles buttons to display lists of profiles and roles assigned to the
selected users.
All other functions are standard functions of the ALV Grid Control.
For Critical Combinations

The selected users are grouped by critical combinations. If we select a combination name, the
corresponding critical data is displayed.
The other functions correspond to those for critical authorizations.
Examples of Using Critical Authorizations and Combinations
Example 1
We determine all users that have development authorization for either executable programs
(reports) or function groups.
For a user to be able to develop, he or she requires the following authorizations:
Authorization for the object S_TCODE that contains at least one of the transaction
SE80, SE37, or SE38
An authorization for the object S_DEVELOP with the value PROG or FUGR in the
OBJTYPE field and the value 02 in the ACTVT field
The ID to be created with critical authorization data therefore contains three groups, for each
of which the values are each linked with OR.
ID Example 1
Group
Object*
Field Name From
To
AND/OR*
A001
S_TCODE
TDC
SE80
OR
A001
S_TCODE
TDC
SE37
OR
A001
S_TCODE
TDC
SE38
OR
A002
S_DEVELOP OBJTYPE
PROG
OR
A002
S_DEVELOP OBJTYPE
FUGR
OR
A003
S_DEVELOP ACTVT
02
any (OR or
AND)
Example 2
In a modification of the first example, we now determine users that have development
authorization both for executable programs and for function groups. To do this, split the ID of
the first example into two individual IDs and create a combination of these two IDs:
ID 1
Group
Object*
Field Name From
To
AND/OR
A001
S_TCODE
TCD
SE80
OR
A001
S_TCODE
TCD
SE38
OR
A002
S_DEVELOP OBJTYPE
PROG
AND
A002
S_DEVELOP ACTVT
02
AND
and
ID 2
Group
Object*
Field Name From
To
AND/OR
A001
S_TCODE
TCD
SE80
OR
A001
S_TCODE
TCD
SE37
OR
A002
S_DEVELOP OBJTYPE
FUGR
AND
A002
S_DEVELOP ACTVT
02
AND
Determining Roles, Profiles, Authorizations, and Authorization Objects
Use
These reports RSUSR070 (roles), RSUSR020 (profiles), RSUSR030 (authorizations), and
RSUSR040 (authorization objects) are constructed in the same way: The first node by
complex selection criteria represents a combination of the nodes below in each case. The
evaluation for the Roles node is presented as an example. In this way, we can, for example,
find all roles that contain the authorization post document (F_BKPF_BUK, activity 01).
Procedure
1.
2.
Expand the Roles node.
3.
Choose the Execute option next to Roles by complex selection criteria.
4.
Under Selection by authorization values, enter F_BKPF_BUK in the Object1 field, and
choose Input Values (we cannot enter any values for report RSUSR040).
The fields previously hidden for entering the values are now ready for input.
5.
Enter the activity 1 as the value.
The result list appears.
6. There are additional functions available to us on the result list, depending on the search
area:
Detail: Starts transaction PFCG: displaying the role
User assignment
Profile assignment
Transaction assignment
Value Input
The input values for the Value field of the authorization object are interpreted as follows:
Value
no input
A*
*
*
VALUE
Explanation
The system displays all authorization objects, irrespective of the value
entered in the field.
The system displays all authorization objects whose field contains a space
as the value.
The system displays all authorizations values whose field value begins with
A.
The system displays all authorization objects whose field contains the
placeholder asterisk as the value.
The system displays all authorization objects whose field contains the
placeholder asterisk as the value.
The system displays all authorization objects whose field contains
VALUE as the value.
Determining Transactions (RSUSR010)

We can use this report to determine the transactions that a user can start. A user can start a
transaction if he or she has the authorization S_TCODE and, if appropriate, the authorization
object entered in transaction SE93 for this transaction. For more information about
prerequisites for starting transactions, see Authorization Checks.
The report also determines transactions that are executable with a certain profile (generated
authorizations of a role), a particular single or composite role, or with a certain authorization
for an authorization object.
1.
2.
Expand the Transactions node.
3.
Choose the Execute option next to Executable for User.
4.
Under Transaction Executable, restrict the selection using the field For User.
5.
Choose Execute.
The result list appears, in which we can select a transaction and choose Select to display the
list of authorization objects and values for this transaction.
Note:
With the selection For User, the reference user assigned to this user is also taken into account.
If we specify a reference user in the Executable for User selection, only the authorizations
assigned directly to this user are taken into account. Since a reference user cannot log on to a
system, the transactions displayed by the report cannot be directly started by the reference
user. Only a dialog user that has been assigned this reference user can do so.
Authorization Checks
To ensure that a user has the appropriate authorizations when he or she performs an action,
users are subject to authorization checks.
The following actions are subject to authorization checks that are performed before the start
of a program or table maintenance and which the SAP applications cannot avoid:
Starting SAP transactions (authorization object S_TCODE)
Starting reports (authorization object S_PROGRAM)
Calling RFC function modules (authorization object S_RFC)
Table maintenance with generic tools (S_TABU_DIS)

Checking at Program Level with AUTHORITY-CHECK
Applications use the ABAP statement AUTHORITY-CHECK, which is inserted in the source
code of the program, to check whether users have the appropriate authorization and whether
these authorizations are suitably defined; that is, whether the user administrator has assigned
the values required for the fields by the programmer. In this way, we can also protect
transactions that are called indirectly by other programs.
AUTHORITY-CHECK searches profiles specified in the user master record to see whether
the user has authorization for the authorization object specified in the AUTHORITY-CHECK.
If one of the authorizations found matches the required values, the check is successful.
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.
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.
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).
Note
If we create a transaction in transaction SE93, we can assign an additional authorization to
this transaction. This is useful, if we want to be able to protect a transaction with a separate
authorization. If this is not the case, we 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:
We have deactivated the check of the authorization objects for the transaction (with
transaction SU24) using check indicators, that is, we have removed an authorization object
entered using transaction SE93. We cannot deactivate the check for objects from the SAP
NetWeaver and HR areas.
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. We can therefore deactivate
authorization checks of this type in a targeted manner using transaction SU24.
We have globally deactivated authorization objects for all transactions with transaction
SU24 or transaction SU25.
So that the entries that we have made with transactions SU24 and SU25 become
effective, we 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.
Starting Report Classes
We can perform additional authorization checks by assigning reports to authorization classes
(using report RSCSAUTH). We can, for example, assign all PA* reports to an authorization
class for PA (such as PAxxx). If a user wants to start a PA report, he or she requires the
appropriate authorization to execute reports in this class.
We do not deliver any predefined report classes. We must decide our-self which reports we
want to protect in this way. We can also enter the authorization classes for reports with the
maintenance functions for report trees. This method provides a hierarchical approach for
assigning authorizations for reports. We can, for example, assign an authorization class to a
report node, meaning that all reports at this node automatically belong to this class. This
means that we have a more transparent overview of the authorization classes to which the
various reports are transported.
Note
We must consider the following:
After we have assigned reports to authorization classes or have changed assignments,

we may have to adjust objects in our authorization concept (such as roles (activity
groups), profiles, or user master records).
There are certain system reports that we cannot assign to any authorization class. These
include:
RSRZLLG0
STARTMEN (as of SAP R/3 4.0)
Reports that are called using SUBMIT in a customer exit at logon (such as SUSR0001,
ZXUSRU01).
Authorization assignments for reports are overwritten during an upgrade. After an

upgrade, we must therefore restore our customer-specific report authorizations.
Calling RFC Function Modules
When RFC function modules are called by an RFC client program or another system, an
authorization check is performed for the authorization object S_RFC in the called system.
This check uses the name of the function group to which the function module belongs. We
can deactivate this check with parameter auth/rfc_authority_check.
Checking Assignment of Authorization Groups to Tables
We 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.
We can assign a table to authorization group Z000. (Use transaction SM30 for table TDDAT)
A user wants to access this table must have authorization object S_TABU_DIS in his or her
profile with the value Z000 in the field DICBERCLS (authorization group for ABAP
Dictionary objects).
See also:
SAP Notes 7642, 20534, 23342, 33154, and 67766
Documentation for RSCSAUTH

Check Indicators
As of SAP NetWeaver 7.0, the check status (check/do not check) is separate from the
authorization default status (authorization default value yes/no) and there are the following
check indicators and default values:
New Check Indicator
Check with default to be set
(Yes or No)
Old Check Indicator

U: Unmaintained
Do not check with default

No
N: Do not check
Check with default No
P: Check
Check with default Yes
PP: Check/maintain
Explanation
Check for the corresponding
authorization object takes
place in accordance with
values defined by
programmer.
If the authorization default
value is set to yes, the
administrator must specify a
default when creating a role.
Field values are not
displayed in the role
administration tool.
Check disabled. Field
values are not displayed in
the role administration tool.
This indicator can only be
set for transactions, and not
for HR or Basis
authorization objects. For
services, this is technically
not possible.
Check always executed.
Field values are not
displayed in the role
administration tool, since
there is no authorization
default value.
Check always executed.
Field values are displayed in
the role administration tool.
A yellow traffic light means
that an authorization default
value still contains at least
one empty field.

Globally Deactivating Authorization Checks
As of SAP R/3 4.5, we can globally suppress authorization checks for individual
authorization objects. If we use this option, the system does not perform any authorization
checks at all for the specified objects. If we are using the Profile Generator, the option
significantly reduces authorization maintenance. The Profile Generator does not enter any
authorization data for deactivated authorization checks in profiles. We also do not have to
post process the authorization data after an upgrade for transactions for which we have
globally deactivated the corresponding authorization objects.
Warning
If we suppress authorization checks, we allow users to perform activities without ensuring
that the users have the required authorization. This can have undesired consequences.
Consider very carefully before suppressing authorization checks for authorization objects.
To suppress authorization checks for specific authorization objects, set the profile parameter
auth/object_disabling_active to the value "Y". We then select the affected authorization
objects using transaction SU25 (or transaction AUTH_SWITCH_OBJECTS). [We deactivate
authorization objects in the tree display by selecting the checkbox to the left of the object.
The deactivated authorization objects are then displayed in red. Then activate our settings
(only then are the authorization checks ignored in the system).]
Note that:
We cannot suppress authorization checks for authorization objects that belong to Basis
components or to Human Resources (HR).
We require authorization for the object S_USER_OBJ to be able to suppress

authorization checks for authorization objects. We recommend that we assign the
relevant activities (saving, activating, or transporting) to different administrators.
If we reactivate previously suppressed authorization checks for authorization objects,

we must post process the authorization data for the relevant roles.
These authorization objects are not contained in any role. In this case, call transaction PCFG
and choose Read old status and compare with the new data on the tab page
Authorizations in expert mode to generate profiles. Maintain missing authorization values
and then regenerate the profile.
When transporting the settings (in transaction AUTH_SWITCH_OBJECTS), for

security reasons, the system does not transport the active version of the settings, but
rather the saved version. We need to explicitly activate these in the target system
(Authorization Objects Activate Data).
Note
To save or activate deactivated authorization checks for authorization objects, we require
authorization for the object S_USER_OBJ. For security reasons, we should assign the
authorizations for saving and for activating deactivated authorizations checks for
authorization objects to different users. It makes sense to deactivate the authorization checks
only if at least two people agree on this.
Comparing Cross-System Users, Authorizations, Roles, and Profiles (RSUSR050)
Use
We can use this procedure to compare two user master records, roles (including composite
roles), profiles, or authorizations in the same system or different systems in the User
Information System. We define the name of the RFC destination with transaction SM59.
When comparing composite roles, we receive as the result a list of the single roles and then
below this, a comparison of the authorization objects.
This example describes how we can compare two users (the procedure is the same for roles,
profiles, or authorizations). The master records are resolved to authorization field level and
compared.
Procedure
1.
2.
Expand the Comparisons node.
3.
Choose the Execute function in the From Users line.
4.
In the User A and User B fields, enter the names of the users to be compared.
5.
To compare users in different systems, choose the Across Systems button.
To compare a user of the current system with a user from another system, enter the user
name for user A and the RFC destination and the user name for user B. We can use the
input help to select from the available RFC destinations.
To compare a user from another system A with a user from a further system B from the
current system, enter the RFC destinations of these systems in the fields RFC
Destination for System A and RFC Destination for System B.
6.
Choose Execute.
The system displays the Comparisons screen, on which a comparison of the two users is
displayed. This is divided into same values, different objects, same values, and different
values. In the case of different objects, only the user for which an authorization object is
displayed has the object. Different values means that although both users have authorizations
for the same object, the values are different. Same values mean that both the authorization
object and the authorization values of the two users match.
To display documentation for an authorization object, select the object and choose
Documentation.
To display a sorted comparison of the values by authorization fields, select the relevant
line and choose Select.
Result
The authorizations from different profiles were resolved, combined by objects and sorted by
fields. This means that we have a compact comparison of the values for each field.
Note that this display allows a quick comparison, but that the interaction of the fields within
an authorization is of vital importance. In particular, it can be the case for the objects listed
under "same values" that although two users have the same values for an object, they do not
have the same authorizations, as the field values are combined differently in different
authorizations. We should therefore regard this comparison function only as a utility for
finding differences and not for documenting equality.
For information about investigating the user master records of two users for an object at the
authorization level, see the Users by complex selection criteria section of Determining Users
with the Users Node.
Creating Where-Used Lists for Profiles (RSUSR002)
Use
We can use this report to create where-used lists for profiles, authorization objects,
authorizations, and authorization values. We are looking for, for example, all users to which a
certain profile (such as SAP_ALL) is assigned.
Procedure
1.
2.
Expand the nodes Where-Used List and Profiles.
3.
Choose the Execute option next to one of the following search areas (in this example,
next to In Users):
In Users

In Roles
In Composite Profiles
4.
Specify the profile (in our example, SAP_ALL), and choose Execute.
The result list By Complex Selection Criteria appears.
5.
There are additional functions available to us on the result list, depending on the search
area.
Result
The result list shows the where-used list of the object in the specified search area; in our
example, therefore, all users to which the SAP_ALL profile is assigned.
Functions in the Result List for the In Users Search Area
Function
Display Details
List with Roles
List with Profiles
Change Documents
Comment
Display details for the user.
List of users with their role assignment
List of the users with all profiles assigned to the user
List of change documents for a user
Functions in the Result List for the In Roles Search Area

Function
Display Details
User Assignment
Profile Assignment
Contained in
Composite Roles
Contained Single
Roles
Transaction
Assignment
Comment
Starts role maintenance (transaction PFCG) for the selected role.
Starts the where-used list for the users assigned the role selected in
the result list
List of the profiles for a role, from which, in turn, we can create a
where-used list for the profiles contained in the list.
Displays a list of composite roles in which the single role selected
in the result list are contained.
Displays which single roles are contained in the selected
composite role from the result list.
List of all transactions contained in the role, for which we can
display all fields and values by choosing Details.
Functions in the Result List for the In Composite Profiles Search Area
Function
Display Details
Where-Used List
Comment
Display details for the profile.
Where-used list for a profile selected in the result list that contains
the profile for which we originally performed the search in the
where-used list. The same selection options are available again on
the Profile Where-Used List dialog box (use in profiles, user
master records, or roles)
Change Documents
List of change documents for a profile
Creating Where-Used Lists for Authorization Objects (RSUSR002)
Use
authorizations, and authorization values.
Procedure
1.
2.
Expand the nodes Where-Used List and Authorization Objects.
3.
Choose the Execute option next to In Programs.
4.
Enter the authorization object and choose Execute.
The Authorization Object Where-Used List dialog box appears.
5.
Specify the search area. Use in:
Programs
Classes
BSP Applications
Transactions
Package Interfaces
Result
The result list displays the where-used list for the authorization object in the specified search
area. Additional functions are available to us in the result list.
Functions in the Result List
Function
Comment
Change
Calls the ABAP Editor in change mode for the program.
Display
Calls the ABAP Editor in display mode for the program.
Where-used list
Displays all programs, classes, and so on that use the selected
program.
Delete
Deletes the program
Complete List
Additional properties of the programs are displayed in the complete
list.
Creating Where-Used Lists for Authorizations (RSUSR002)
Use
authorizations, and authorization values.
Procedure
1.
2.
Expand the nodes Where-Used List and Authorizations.
3.
Choose the Execute option next to one of the following search areas:
In Users
In Profiles
4.
Enter the authorization and the associated authorization object, and choose Execute.
5.
area.
Result
area.
Function
Comment
Display Details
Display details for the user.
List with Roles
Displays all roles of the users in the result list
List with Profiles

Change Documents
Displays all profiles of the users in the result list

List of change documents for the users selected in the result list
Functions in the Result List for the In Profiles Search Area

Function
Display Details
Where-used list
Change Documents
Comment
Display details for the profile.
Starts the where-used list for the profile selected in the result list
List of change documents for the selected profile
Creating Where-Used Lists for Authorization Values (RSUSR002)

Use
We can use this report to search for certain authorization values, such as all users that have
authorization to post goods receipt.
Procedure
1.
2.
Expand the nodes Where-Used List and Authorization Values.
3.
Choose the Execute option next to one of the following search areas:
In Users
In Roles
In Profiles
In Authorizations
4.
Specify the authorization object (such as M_MSEG_WWE), for the values of which we
want to create the where-used list, and the values for the authorization object in the
fields, which are different, depending on the authorization object (in this example,
activity = 01).
5.
Choose Execute.
6.
area.
Result
area.
Function
Display Details
Roles
Profiles
Change Documents
Comment
Displays profiles for the selected user, including the authorization
objects, authorizations, and authorization fields
List of users with their roles
List of users with their profiles
List of change documents for the users selected in the result list
Functions in the Result List for the In Roles Search Area

Function
Display Details
User Assignment
Comment
Starts the role maintenance transaction (PFCG).
Displays a list of the users assigned to the role.
Profile Assignment
Contained in
Composite Roles
Contained Single
Roles
Transaction
Assignment
Displays a list of the profiles assigned to the role.

Displays a list of composite roles in which the single role selected
in the result list are contained.
Displays which single roles are contained in the selected composite
role from the result list.
Displays a list of the transactions assigned to the role.
Functions in the Result List for the In Profiles Search Area

Function
Display Details
Where-Used List
Change Documents
Comment
Displays all authorization objects, authorizations, and authorization
values for the profile
Starts the where-used list for the profile selected in the result list
List of change documents for the profiles in the result list
Functions in the Result List for the In Authorizations Search Area

Function
Display Details
Where-Used List
Change Documents
Comment
Displays the authorization values for the authorization.
Starts the where-used list for the authorization selected in the result
list
List of change documents for the authorization selected in the result
list
Determining Change Documents

Use
We can use this report to determine all changes to the following objects:
A user (RSUSR100)
A profile (RSUSR101)
An authorization (RSUSR102)
A role assignment (RSSCD100_PFCG)
A role (RSSCD100_PFCG)
Note that changes for users, profiles, and authorizations are divided into two areas:
Changes to authorizations: creating the user, changing, adding, or removing profiles
Changing header data: password changes, validity, user type, user group, account
number, lock status
We can select both fields to obtain all information. In this case, the left column shows the
status before the change the right column the changed entry.
We determine the changes for roles and role assignments using a separate interface.
Determining Documents for Users, Profiles, and Authorizations
1.
2.
Expand the Change Documents node.
3.
Choose the Execute option next to For Users (or For Profiles or For Authorizations).
4.
Specify the user (or the profile, or the authorization) and other restricting values, and
choose Execute.
The result list Lists of Change Documents for Users appears.
5.
We can display details for profiles and authorizations by double clicking the appropriate
object in the result list.
Determining Documents for Roles and Role Assignments
The interface for determining change documents for role assignment is a section of the
interface to determine the change documents for roles.
1.
2.
Expand the Change Documents node.
3.
Choose the Execute option next to For Roles (or For Role Assignments).
4.
Enter the required details and then choose Execute.
We can select an individual role or a particular change document with the fields Name of the
Role and Change Number of the Document. We can use the fields Changed By and To Date
or To Time to further restrict the selection. We can use the button next to Changed By to enter
our user name in the input field.
We can also choose the following document types under Change Documents, where an
additional input field is displayed at the end of the list for some document types:
Overview of change documents
Creating and deleting roles
Role description
Single roles in composite roles
Transactions in the role menu
Other objects in the role menu
Authorization data
Org. level value
Authorization profile
Attributes
MiniApps
Composite role home page
User assignment
With the User Assignment option, we can use the input field Assigned User to display the
changes to role assignments for individual users.
We can use the option All Change Documents (Technical View) to display the contents of the
key fields of the table entered in the field Change Document Table. If we enter an asterisk (*)
as a placeholder or leave the field empty, all tables are used in the evaluation.
Result
Initial entries for role data are differentiated from empty entries in the result list by the
comment unknown.
We can also create user-specific ALV list variants in the result list.

User Master Records

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

User Master Records

Încărcat de

Drepturi de autor:

Formate disponibile

Creating and Editing User Master Records

Authorization for the authorization profiles we assign to users (object S_USER_PRO)

Authorization to create and edit authorizations (object S_USER_AUTH)

The SAP System super user, SAP*

The user has the password "PASS", which cannot be changed.

Assign a new password to SAP* in clients 000 and 001.

we use the predefined profiles, and

we follow SAP's other user and authorization maintenance recommendations.

Authorization data administrator, who creates roles (transaction selection and

Changing role data

Templates and Roles

with T_..... for

Using the User

d. Generate an authorization profile in each case.

If appropriate, restrict the authorizations of the administrators further:

If an error occurred during the authorization check, this is displayed in a log.

Customer and vendor master

Site master (Retail)

Sales and Distribution documents: Document addresses and one-time customer

SAP office addresses (external communication)

Customizing addresses (SM30)

MM Purchasing: Permanent delivery addresses, manual delivery addresses in

PM/SM (functional locations, equipment, notification, order)

IS-U (connection objects, contracts)

IS-Oil (service stations)

SAP Business Partners

New Dimension products such as SFA, BW, APO, CRM

Integration into SAP connect

Provision of archiving classes for the Archive Development Kit (ADK)

Support of addresses as objects in the BOR

Provision of interfaces for application-specific enhancements

Automatic writing of change documents for address data changes

International address requirements (print output according to international mail

By means of a where-used list, we can determine which application objects reference

Address data is updated together with the application data.

Addresses are grouped by their assignment to an application, which can be used as a

Transport or distribution methods or tools

Distribution using ALE (Application Link

Methods for transporting addresses within the

Methods for client copy and BAPIs for central

For general information on creating business objects see the documentation on

Provides an object oriented view of R/3 System data and processes.

Manages BAPIs in release updates.

Ensures interface stability.

Distributed R/3 scenarios with asynchronous connections using Application Link

Connecting R/3 Systems to the Internet using Internet Application Components

Workflow applications that extend beyond system boundaries

Customers' and partners' own developments

For more information, see http://www.sdn.sap.com/irj/sdn/javadocs

The format for decimals

CATT test status

To generate the password, choose Generate ( ).

To deactivate the password, choose Deactivate ( ).

Login Parameters for password rules

User Maintenance Functions, Change Password section.

We can change this with profile parameters

Predefined in SAP system

The first three characters may not

Predefined in SAP system

Predefined in SAP system

Can be changed. The default value is that all

Predefined in SAP system

The password can only be

Predefined in SAP system