6 7 users authorization

12
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.

Upload: matheusl1987

Post on 18-Dec-2015

18 views

Category:

Documents


0 download

DESCRIPTION

SAP BASIS

TRANSCRIPT

  • Users & AuthorizationUsers 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.

  • Users in the R/3 EnvironmentDatabase ServerDatabaseServerOperating SystemOperating SystemOperating SystemApplicationServerPresent.ServerR/3 UserOS UserDB UserOS UserOS UserAdmin. User

  • The User Master RecordAll user data required for R/3 System access is storedin the user master recordin eight categories

  • Types of users

  • User master record

    User master record

    Authorizations assigned? Objects needing protection

    VendorCompany codePlantMaterialActionTransaction permitted?Authorization Concept ProfileAuthorizationfor Task AAuthorizationfor Task BProfileAction

  • Authorization CheckSAP GUIOK?AuthorityCheckNoProcessingUser ContextMessageYesDynpro

  • FinancialAccountingAuthorizationdisplay, changeCustomer company code: Authorization A

    Customer company code: Authorization B

    0001-0009*displayObject: Customer company codeCompany CodeActivityAuthorization objectObjectclass

  • Object Fields Value Meaning

  • Central User AdministrationClient 100 PRD SystemClient 100Client 200QAS SystemClient 100 Client 200 Client 300DEV SystemWith central user administration, the creation and maintenance of all user master data is performed in a single R/3 System

  • Information System

    *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 recordsAuthorization profilesControlling 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 numberLogin date: password information as well as the validity period for the recordDefaults: defined default values for start menu, date format, printers, and so onParameters: defined default values (PIDs) for R/3 fields such as company code 001Systems: central user administration system informationActivity Groups: defined activity groups (with validity period) associated with userProfiles: all profiles assigned to user master record, including standard profiles and profiles generated by the profile generatorGroups: all user groups associated with the user master recordTab 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). *55To 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, ...)*31Managing 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 usersExisting user groupsSystems defined within the system groupActivity groupsCentral 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 systemsThe same user works in more than one systemThe same user ID should represent the same individual in all systemsAn enormous effort is otherwise required to synchronize user data in all systemsTo 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:UsersProfilesAuthorization objectsAuthorizationsTransactionsUser master record comparisonsChange documentsTo 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.