1. Users & Authorization
Users must be setup and roles assigned to user
master records before you can use the SAP
System.
A user can only log on to the system if he or she
has a user master record. A user menu and
authorizations are also assigned to the user
master record via one or more roles.
2. Users in the R/3 Environment
Present.
Operating System OS User
Server
R/3 User
Application
Operating System OS User
Server
Dispatcher
D B V ...
Admin. User
Database Server
Database
Operating System OS User
Server
DB User
3. The User Master Record
All user data required for
R/3 System access is stored
in the user master record
in eight categories
6. Authorization Concept
User master record User master record
Profile Profile
Authorization Authorization
for Task A for Task B
Action Action
Transaction permitted?
Authorizations assigned?
Objects needing protection
Vendor Material
Company code Plant
7. Authorization Check
SAP GUI
Dynpro
Authority User
Check Context
OK? No
Message
Yes
Processing
8. Authorization
Customer company code:
Authorization object Authorization A
Object
class Object: Customer 0001-0009
company code
Financial display, change
Company Code
Accounting
Activity Customer company code:
Authorization B
*
display
9. Object Fields Value Meaning
User Master 01 Create
ACTIVITY
Maintenance: 02 Change
Authorizations 03 Display
(S_USER_AUT) 06 Delete
07 Activate
08 Display change documents
22 Assign authorization profiles
24 Archive
AUTH Limited name space
for the assignment
of authorization names
OBJECT Authorization objects
10.
11. Central User Administration
With central user administration, the
creation and maintenance of all user
master data is performed in a single
R/3 System
Client 100 QAS System
Client 200
Client 100
Client 200
Client 300
PRD System
DEV System Client 100
This unit focuses on the R/3 user within the R/3 System. However, it is important for the R/3 System administrator to control access to both the operating system (OS) where the R/3 Systems reside and the database (DB). External user IDs exist both at the OS and DB levels that can be used to disrupt normal operation of the R/3 System. Access to the R/3 System is controlled at the client level. Each R/3 user must have a user master record in the client in which that user will work. In R/3, authorizations are used to restrict access to programs and data. This unit focuses on: The creation of user master records Authorization profiles Controlling access to transactions and data in the R/3 System
To create and maintain user master records, use transaction SU01 . For each user, the user master record contains all data and settings required for client access for the user. This data is arranged with tabs and includes the following: Address : basic user information such as name, physical location, and telephone number Login date : password information as well as the validity period for the record Defaults : defined default values for start menu, date format, printers, and so on Parameters : defined default values (PIDs) for R/3 fields such as company code 001 Systems : central user administration system information Activity Groups : defined activity groups (with validity period) associated with user Profiles : all profiles assigned to user master record, including standard profiles and profiles generated by the profile generator Groups : all user groups associated with the user master record Tab Systems only appears if central user administration is activated. Current status and change history can be displayed for the current record. To access a detailed change history outlining all change to the user master record, use transaction SUIM .
In R/3, for each user who requires access in a client, the authorization administrator creates a user master record for that user in that client. The user master record includes one-to-many (1-n) profiles containing all the authorizations needed by the user to perform tasks in the specified client. An authorization provides the permission(s) required to access certain transactions, reports, or data. For each user activity or transaction, an authorization check is performed to see if the required authorizations have been assigned to that user. Authorizations limit access to transactions and objects in the R/3 System that need protection, for example, a company code or vendor. The R/3 authorization concept enables authorizations to be assigned at the transaction level. If a user who is not authorized to perform a certain task attempts to run the corresponding transaction, R/3 sends a message denying access to that transaction. Authorization checks are performed at various points during the execution of a transaction or report to verify that the user has the required authorization(s) for the objects requested. For example, R/3 may check if the user is authorized to access data for company code 001.
When a user logs on to the R/3 System, all authorizations in the profiles assigned to the corresponding user master record are loaded into the user buffer for the application server to which the user is connected. Once the dispatcher assigns the user request to an available dialog work process, the relevant program is loaded and the user context is checked to see if the user has the necessary authorizations. The user context contains the user authorizations. These are checked against the authorization objects called in the authority check specified in the ABAP code. The user authorizations are checked using OR logic to determine if an exact match exists. If the required authorization exists the user is allowed to proceed and processing continues. If none of the authorizations contain the required combination of field values, a message is sent denying the user access to that object. Once the dialog step has been completed, the user context for the user is rolled out of the dialog process and the process is free to work for another user. The user context remains in the user buffer and is available for use during the next dialog step. To adjust or cancel authorization checks either globally or for individual transactions, the authorization administrator must use transaction SU24 . Checks can be adjusted, for example, if detailed authorization checks are not needed in certain transactions. To adjust or cancel checks, set profile parameter auth/no_check_in _some_cases to value Y (this is the system default value in Release 4.6).
5 5 To maintain authorizations, run transaction SU03. The initial screen lists various object classifications. An object class is a logical grouping of authorization objects that share a similar purpose or business area. For example, object class Basis: Administration contains authorization objects that control access to Basis transactions. The authorization object is the template from which the authorization is created. It is used in the ABAP code for authorization checks. Each object has up to 10 fields that are checked using AND logic before access is granted to the desired transaction. The authorization administrator creates authorizations from the authorization object. The authorizations contain the field values (permissions) for each field contained in the object. Field values control access to the business area or data addressed by the transaction. To create or change an authorization, enter or change the relevant values in the fields of the authorization. All authorizations are positive, in that they grant permissions to the user.
The graphic lists the authorization objects that are checked when working with the Profile Generator and when maintaining users: S_USER_AUT (create and change authorizations, enter authorizations in profiles, ...)
31 Managing users across the system landscape can become a complex task. Central User Administration enables you to maintain user master records in a central repository and easily access: An overview of all users Existing user groups Systems defined within the system group Activity groups Central User Administration allows you to maintain user master records within a single client on the central system and distribute this information to all systems in your landscape. In this context, the central system is defined as an R/3 System that keeps and controls user master data for the entire system landscape. Reasons for using Central User Administration include: The system landscape is complex, with several clients in different systems The same user works in more than one system The same user ID should represent the same individual in all systems An enormous effort is otherwise required to synchronize user data in all systems To access Central User Administration, use transaction SCUM . For more information on Central User Administration, take SAP Basis Class BC305 Advanced Administration.
The information system provides a basis for conducting detailed analysis of user master records, profiles, authorizations, and activity groups. To access the information system, use transaction SUIM . The information system report tree enables you to access the standard delivered SAP user analysis reports. You can search in these reports using complex search criteria that provide detailed information on: Users Profiles Authorization objects Authorizations Transactions User master record comparisons Change documents To identify pre-delivered reports from SAP for Users and User Administration, call transaction SE38 . Enter RSUSR* in the program field and select the down arrow. This provides a listing of the user reports. To obtain detailed information on a report, select the report and view the documentation written by the developer.
