What are the checks that the SAP authorization tool performs when a TCODE is executed in order to ensure authorization of that user?

EXPERT RESPONSE

When initiating a transaction, a system program performs a series of checks to ensure the user is authorized.

1. The program checks whether the transaction code exists in table TSTC.

2. The program checks whether the transaction code is locked by the administrator (transaction code SM01).

3. The program checks whether the user has the authority to start the transaction. Authorization object S_TCODE (transaction start) contains the authorization field TCD (transaction code). The user must have the appropriate authorization for the transaction code to be started (for example, FK01, Create Vendor).

4. The program checks whether an authorization object is assigned to the transaction code. If this is the case, the program checks whether the user has an authorization for this authorization object. The transaction code/authorization object assignment is stored in table TSTCA.
Note: An SAP program controls steps 1 through 4. It displays an automatic message to the user if an authorization attempt fails in the step.

5. The system performs authorization checks in the ABAP program using the ABAP statement AUTHORITY-CHECK.

I want to get a list of all transactions used per user in a specific time period. Basically I’m looking for a list of all users logged in SAP and the details of the tcodes they used. Is there any standard report or tcode available to view this info?

EXPERT RESPONSE

There is no standard transaction. The information is available for configurable time periods using transaction ST05N but it is not organized to readily provide a report of users and transactions. Also the information available summarizes a user’s use of a transaction. There will be one entry (with count data) per user per time period. Daily, weekly and monthly summaries can be created and they are stored for configurable durations.
The information is summarized into a cluster table called MONI based on the STAT files that are written in the file system and regularly refreshed. MONI cannot be queried via SE16 etc., but SAP delivers a number of function modules that retrieve data from these tables.

It is also possible to configure audit logging via SM19 and read the log files via SM20. This will provide more detail but it also introduces new file management issues and requires a change to system settings.

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)

The authorization objects S_TCODE, S_PROGRAM, S_RFC, and S_TABU_DIS
are standard SAP provided.
Creating a new authorization object is not in the scope of ABAP developer. It will
be taken care by SAP BASIS team.

This is a preview of Authorization Check:

My admin user ID has been locked out. Is there a table I can update in Oracle to reset the flag and enable myself to log in?

EXPERT RESPONSE

Select all entries of table USR02 where ‘UFLAG’=128. These users are locked by reason of incorrect logons. ‘UFLAG’=64 will give you the users that are blocked by Administrator. Set ‘UFLAG’ to 0, to unlock your account.

SAP Authorization Concept

The SAP authorization concept is based upon the logical relationship between a user ID and the range of system authorizations with which it can be associated. The architecture of the authorization system is based upon the utilization of several individuals but related logical components: Profiles, Objects, Fields, and Authorizations. The user ID refers exclusively to profiles. Each profile grants a set of specific system access authorizations to user.

Composite Profiles

Composite profiles refer to the various employee roles available in the corporation (for instance: Purchasing / Receiving Clerk or Accounts Agent). As the name suggests, composite profiles may contain multiple user IDs necessary to perform all the business operations associated with a particular role. A composite profile may encapsulate another composite profile(s). In practice, a model composite profile should be recognized for each possible role in the organization, which may be used to produce hybrid composite profiles. The over-existence of the hybrids can defy the very purpose of composite profiles and they should be created only when specific needs arise.

User Ids

User ids allow access to SAP applications. Each user must have a corresponding profile specifically assigned. In many situations, multiple composite profiles can be assigned to a user ID, depending on the role(s) an individual user is responsible for, in the business processes.

Authorizations

Authorizations are the key building blocks of SAP security. Authorization is the process of assigning values to fields present in authorization objects. In SAP, access to all system functionality is achieved through a complex array of authorizations. Sometimes users find that they lack the necessary authorizations to perform a certain function in the system, in which case the message: “You are not authorized…” is displayed at the bottom of the screen.

An authorization process may ask for second associated authorization process which in turn asks for third and so on. For example, the task of paying a vendor invoice may require 10 different authorizations.

---Original Message-----
Subject: Profile Generator tables?
From: Paul Ellis

We maintain profiles in a Development system using Profile Generator, but only transport the authorisation profile and not the activity group to Staging/Production.

We are about to refresh the Development system with a copy of Production. What tables do I need to export from Development prior to the refresh, and later re-import, to ensure that Profile Generator is able to maintain the activity groups created in Development?

Thanks in advance.

Paul Ellis

-----Reply Message-----
Subject: Re: Profile Generator tables? - more
From: Mike O'Carroll

oh, and maybe these tables for profile genrator stuff......
(from top include for PFCG)
000010 function-pool rhum.
000020
000030 tables: hrv1220, hrp1001, hrp1000.
000040 tables: pchdy, pphdx, p1000,
000050 pt1220, t77fc, t77fd.
000060 tables: *objec, objec, *p1000.
000070 tables: pdrhum, t77aw, t777o.
000080 tables: xu213.
000090 tables: t777e, usr05, tprprof.

and you may need to do the same with menu tables - I'm not sure which ones
-
(from top include from SSM1)
000010 function-pool smnu. "MESSAGE-ID ...
000020 *
000030 tables: indx, tstct, dsyax,
000040 smenca_new, smen_obnew, smen_conew,
000050 smenusenew, smenentnew,
000060 smen_dates, ssm_stat, ssm_start, ssm_langu,
000070 smensapt, smencust, smenentt,
000080 smensapnew, smencusnew,
000090 smenselect, t002t,
000100 ssm_rele, smenintnew, smenintt.

--------------------------------------------------------------------------------

Regards,
Mike O'Carroll

-----Reply Message-----
Subject: Re: Profile Generator tables? (Document link: Michael O'Carroll)
From: Michael O'Carroll/UK

user masters: USR01 to 09, UST04,
profiles: USR10, USR11, UST10S, UST10C,
authorisations: USR12, USR13, UST12.
password exceptions USR40.
History tables(may not be applicable but FYI): users: USH02, USH04,
profiles: USH10, auths USH12.

activity groups are stored in table PLOGI along with loads of other object types. the activity groups are object type T.
You could export the table data with a manual transport request via SE01, using R3TR TABU and specify the keys to use for all objects of type T(ie all activity groups). Remember to include all clients in the selection.

OR, if you are using the client copy functions to refresh you DEV from PROD, then you could use the RSCCEXCT (see OSS note 70290) to list all these tables and exclude them from the copy, hence the corresponding original DEV tables should not be overwritten in DEV.
I suggest you export a transport request with with all these tables from DEV just in case, so you can re-import them again if it goes pear shaped.
In 3.x I don't think the activity group names involve client number or SID, but I've heard some differences in 4.6 - Guy Holchester has sent many notes to the list about it - have a look at the archives, but I think as long as you aren't copying between different versions (eg from Prod 4.6 to Dev 3.x, or vice versa) then it should be OK.

If you choose to re-import the tables from transport requests, you might want to run the sync tool in the target client (DEV) afterwards - ie run function module SUSR_SYNC_USER_TABLES, or run SU30, just to check for any dodgy links or inconsistencies.

Also, if you are re-importing user masters too, run RSSODELT and RSSOUSER to recreate all SAPOffice mailboxes and link them to the new user IDs in the target client.

hope this helps.
cheers,
Mike

-----Reply Message-----
Subject: Re: Profile Generator tables?
From: Kenneth Marquardt

I would use RHMOVE30 and create a transport of your activity groups. To be safe test import the activity groups to QAS prior to refreshing DEV with PRD. Then once you have completed the refresh import the transport you created. For more info on this look at the Authorization is made easy guide available online on page 11-6 release 4.0b.

Remember to run SUPC after you import to regenerate the profiles.

-----End of Reply Message-----

How to check the missing authorisation for the user not having the option "/nsu53 ?"

You can use the following procedures to determine which authorizations a user requires to carry out a transaction:

You can use Trace function, ST01, you can trace the user activity and from the log you can see the authorization missing.

Start an authorization trace using the ST01 transaction and carry out the transaction with a user who has full authorizations. On the basis of the trace, you can see which authorizations were checked.

This procedure generally works well. However, sometimes the result is very surprising because certain programs can and do ignore some authorization checks by using preliminary checks and buffered results. In such cases, these methods are not very effective. You can recognize these cases because certain fields of the corresponding programs are specified with * or DUMMY at some point of the authorization check.

Analyzing authorization problems in an unknown program

The most frequently used method to analyze authorization problems in an unknown program involves you setting the Debugger breakpoints to the AUTHORITY-CHECK and MESSAGE commands. Then execute the program and analyze its behavior.

Determining all the authorizations a user has for an authorization object

When troubleshooting, it is often helpful to find out all the authorizations a specified user has for a specific authorization object. A simple method of reading these authorizations as raw data from the user master record is to execute the GET_AUTH_VALUES function module in the SUSR function group. Use the SE37 transaction or SE80 in test mode to do so. The result table is not formatted for output, but is very compact and easy to understand for authorization experts.

Analyzing an authorization problem that occurs for only one user

It is often the case that a certain authorization problem occurs for only one specific user. This kind of authorization problem generally affects users with no Debugging authorization. If you want to assign a user Debugging authorization without changing the HR authorizations, you can add the S_A.DEVELOP authorization profile (if available) to the user’s authorization profiles. In production systems, note that changes such as these to authorizations enable users (with relevant knowledge of the development environment) to access any system data easily (especially in other clients).

I want to create new user for SAP module. I am having user id as sap* (someone has said that this is super user id); when I login with this id and go to IMG for configurations. A message is displayed that I am not authorised to change the details with sap* user.

What is the procedure for creating new user which have all features define under SAP* user and which could allow me to make the configruations.

Creating new user with superuser authorizations.

1. Goto SU01 --
username : sapuser
|-->Create.

2. In default settings, give
:Mr
first name : sap
lastname : user

3. Goto next tab,
give initial password :1234
repeat password : 1234

4. Goto profiles.
type- sap_all (say enter)
sap_new (say enter)
Then save....
See the message in status bar, (user created successfully)

5. Login with the new user. change the password. now this user contains all superuser authorizations.

How to compare the roles where created or defined in two different systems?

For role comparision both the roles must be in the same system, in same client

Transaction code SUIM -> Comparision-> Roles

If the roles are in different system, then tranport the role into one of the system and do comparision. If no transport connection defined then, you can use the upload and download option in the PFCG

Steps for Role Comparing:

1. Run the t-code SUIM

2. Go To Comparison and select the option of roles

3. Click on Across systems option it will give option to select the sys name under Remote Comparison there enter the SYS ID between which system you want to do comparison and put the role name in compare role section then execute it will give you the result.

4. If there is any difference b/wn the t-codes it will b in red colour otherwisein yellow.

1. How to check the name of all users who has been authorised to use a particular transaction? I am trying to find through SUIM, but failing to find the name or total number of users of a particular t-code say SPRO.

2. I know that a particular transaction say SPRO is available in a particular role and I want to remove that t-code from that role. But I am unable to find that node through PFCG. If I am using the search for a t-code inside menu tab after putting the edit mode it is not coming in PFCG, but through SUIM its existence is coming in that role. That particular role contains a lot of t-code and reports, say about 2000.

1. Goto SUIM and select USER node, then select USERS BY COMPLEX SELECTION CRITERIA node then execute BY TRANSACTION AUTHORIZATION report then give the Tran. code and it will return you the number of users having that trans with relevatn details.

Follows these steps :-

- Go to SUIM .
- Choose Roles --> By Transaction assignment.
- Enter Transaction : "SPRO"
- Choose execute.
- Double click on a role in which you want to remove "SPRO" authorisation.
- Click on pen mark to change into change mode.
- Go to tab "Authorization"
- Choose change authorization data.
- Choose Utilities --> Technical names on .
- Choose --> cross application authorization objects-->
- Expand the selection for Object "s_tcode" , under the corresponding profile look the values maintained for "TCD" and remove value "SPRO" from the list to eliminate the authorization.
- Don't forget to regenerate profiles.

2. You should able to find this via menu tab otherwise try to do this in authorization tab --> change authorization data by search.

When you encounter errors during testing of roles, you can use SU53 and ST01 to analyze the error.

1. Ask the user to run SU53 to display the result of the last failed authorization. It is important the user run SU53 immediately after failed authorization check, as only the last object the failed the authorization check is saved.
2. You can run trace using ST01 to further analyze the error.

• Authorization objects enable complex checks of an authorization, which allows a user to carry out an action. An authorization object can group up to 10 authorization fields that are checked in an AND relationship.
• For an authorization check to be successful, all field values of the authorization object must be maintained accordingly. The fields in an object should not be seen as input fields on a screen. Instead, fields should be regarded as system elements, such as infotypes, which are to be protected.
• You can define as many system access authorizations as you wish for an object by creating a number of allowed values for the fields in an object. These value sets are called authorizations. The system checks these authorizations in OR relationships.

Once I had couple of roles which where made just t hold reports. The number of reports where huge. Here is how I did it.
First create a CATT script with a dummy role and add one tcode. Make the role and T-code as variant. Once you have this you can add any number of tcode to any existing role. Icould resuse this tocreate another roles where I had to insert lot of T-codes.

1. Open two sessions

2. Execute transaction ST01 in one of the sessions

3. Select the authorisation checkbox, note the other traces you can perform (SQL, RFC, Table Buffer etc)

4. Click the ‘Trace On’ button

5. Within your other session execte the transaction/report you want to trace or get the user in question to do it

6. Return to the session where you turned the trace on and click on ‘Trace Off’ otherwise it will continue to record all athorisation checks

7. Click on the ‘Analysis’ button

8. Enter appropriate data into selection screen such as Username, type of trace records (i.e. Authorization check)

9. Click on the Execute button.

10. Report displaying trace results will now be displayed

Administrators who use the Profile Generator require authorization for the following authorization objects: S_USER_AGR Authorization Check for Activity Groups

S_USER_TCD Transaction Assignment of Transactions to Activity Groups

S_USER_GRP User Master Maintenance: User groups S_USER_PRO User Master Maintenance: Authorization Profile S_USER_AUT User Master Maintenance: Authorizations S_USER_VAL Maintenance of Authorization Values in Activity Groups

This all depends. In some cases authorization groups must exist in a custom table before they can be used. This is true for table authorization groups (authorization group in table TBRG assigned to tables in table TDDAT via transaction SE54) and user groups (created in transaction SUGR). In some cases authorization groups are merely created when they are assigned to the object in a standard maintenance transaction (e.g. vendor master data, customer master data, material master data etc.) In other cases the authorization group has an optional validation table that is used in search helps but no where else (ABAP programs in table TPGP and TPGPT, report writer authorization groups (via table TBRG) etc. Authorization groups are essentially labels that you assign to objects (tables, programs, master data etc.) that allow authorization checks for access to the objects with the label.

Authorizations

Access control in SAP is composed of several concepts:

1. Program code that calls an authorization check using the authority-check statement. This will look something like:

   authority-check object id field

2. Authorization fields (corresponding to the in the above code) that define a scope of possible values. Examples of authorization fields would be:

   ACTIVITY: defines the type of activity the user is doing with the data. Possible values are 'DISPLAY', 'MODIFY', 'DELETE', etc.

   
   

   COMPANY_CODE: possible values are any single value, or any range of values, or any combination thereof (such as '0438' and '0600' thru '1100')

3. Authorization objects that define a group of fields. For example, an authorization object called 'CO_MDATA', containing our above fields ACTIVITY and COMPANY_CODE, might used to control access to the company master data tables.

4. Authorizations, each of which belong to exactly one authorization object, that define authorization values (within the scopes defined by the authorization objects) to be granted to users. Note that an authorization is different from an authorization object!! Extending our previous examples, we might have an authorization, belonging to the authorization object 'CO_MDATA', called 'CO_MDATA_ALL', that grants all access to all company master data. Then 'CO_MDATA_ALL' would have the following values:

   FIELD	VALUE
   ACTIVITY	*
   COMPANY_CODE	*

5. Profiles, each of which may contain several authorizations or profiles. A simple profile contains a group of authorizations. A composite profile contains a group of profiles (simple or composite). [Profiles can be conceptualized as forming the structure of a tree, in which end nodes (leaves) are authorizations, and all other nodes are profiles. Simple profiles are nodes whose children are all end nodes, and composite profiles are nodes, other than end nodes, who have no end nodes for children.]

   Profiles are designed to define set or one or more functions or positions. For example, a functional profile might define all the authorizations that are required for doing a goods receipt, or for making a payment in the AP module. A position profile, on the other hand, might define all of the authorizations that are granted to an accountant, or to a warehouse supervisor. Often, a position profile is a composite profile consisting of several functional profiles.

6. Users, to whom profiles are assigned. A user is assigned one or more profiles by the system administrator. These profiles define all of the user's system authorizations.

It sounds complicated, but once you start working with authorizations, it's pretty easy.

Access control in SAP is composed of several concepts:

1. Program code that calls an authorization check using the authority-check statement. This will look something like:

   authority-check object id field

2. Authorization fields (corresponding to the in the above code) that define a scope of possible values. Examples of authorization fields would be:

   ACTIVITY: defines the type of activity the user is doing with the data. Possible values are 'DISPLAY', 'MODIFY', 'DELETE', etc.

   
   

   COMPANY_CODE: possible values are any single value, or any range of values, or any combination thereof (such as '0438' and '0600' thru '1100')

3. Authorization objects that define a group of fields. For example, an authorization object called 'CO_MDATA', containing our above fields ACTIVITY and COMPANY_CODE, might used to control access to the company master data tables.

4. Authorizations, each of which belong to exactly one authorization object, that define authorization values (within the scopes defined by the authorization objects) to be granted to users. Note that an authorization is different from an authorization object!! Extending our previous examples, we might have an authorization, belonging to the authorization object 'CO_MDATA', called 'CO_MDATA_ALL', that grants all access to all company master data. Then 'CO_MDATA_ALL' would have the following values:

   FIELD	VALUE
   ACTIVITY	*
   COMPANY_CODE	*

5. Profiles, each of which may contain several authorizations or profiles. A simple profile contains a group of authorizations. A composite profile contains a group of profiles (simple or composite). [Profiles can be conceptualized as forming the structure of a tree, in which end nodes (leaves) are authorizations, and all other nodes are profiles. Simple profiles are nodes whose children are all end nodes, and composite profiles are nodes, other than end nodes, who have no end nodes for children.]

   Profiles are designed to define set or one or more functions or positions. For example, a functional profile might define all the authorizations that are required for doing a goods receipt, or for making a payment in the AP module. A position profile, on the other hand, might define all of the authorizations that are granted to an accountant, or to a warehouse supervisor. Often, a position profile is a composite profile consisting of several functional profiles.

6. Users, to whom profiles are assigned. A user is assigned one or more profiles by the system administrator. These profiles define all of the user's system authorizations.

It sounds complicated, but once you start working with authorizations, it's pretty easy.