SU24 Concept
Transaction SU24 maintains the USOBT_C and USOBX_C tables. These tables hold the relationships between the particular transaction and its authorization objects. It is possible to add or subtract the checks performed in the transaction by changing the appropriate flag.
- The benefit of transaction SU24 occurs when transactions are added to or deleted from Role Groups using the Profile Generator.
- When new transactions are added, the Profile Generator will add all authorization values maintained in SU24 for the transaction(s).
- When deleting transaction the Profile Generator will remove all authorization values that are maintained in SU24 for the transaction.
- Activities performed:
- Check/Maintain Authorization Values
- Addition of Authorization Object to tcode
- Deletion of Authorization Object from tcode.
| Check Ind. | Proposal | Meaning | Explanation |
| Check | YS | Check /Maintained | The object will be inserted along with the values in the role. The object will be checked along with the values during runtime of the transaction. |
| Check | NO | Check | This object will not be inserted into the roles. A check on the object along with the values will be done during the runtime of the transaction |
| Do not Check | NO | Do Not Check | The object will not be inserted into the roles and there will not be any check performed during runtime of the transaction |
Status Texts for authorizations
•Standard: All field values in the subordinate levels of the hierarchy are unchanged from the SAP defaults
•Maintained: At least one field in the subordinate levels of the hierarchy was empty by default and has since been filled with a value
•Changed: The proposed value for at least one field in the subordinate levels of the hierarchy has been changed from the SAP default value.
•Manual: You maintained at least one authorization in the subordinate hierarchy levels manually (it was not proposed by the Profile Generator).
Effect of SU24 changes in Role Groups
•Authorization objects are maintained in SU24 for a particular transaction code. When a transaction code is added to role, only the authorization objects having check as check indicator value and yes as proposal value, maintained for that tcode will be added into the role group.
•
1) Adding Tcodes to a role
When a new Tcode is added to a role
•When a new tcode is added to a role, going in either change authorization data or expert mode provides the same result. All the authorizations maintained for the tcode at SU24 level is added to the role.
•The program adds new standard authorizations for objects in the roles If the authorization default values contain objects that
were previously not existing
Or only had authorizations in the status Changed or Manual
•A new standard authorization is not included
if the authorization fields contain identical authorizations in the status Standard in both authorizations, and the fields maintained in the old authorizations are empty in the new standard authorization.
If there were already authorizations in the status Maintained (active or inactive) or Inactive Standard before the merge, the program compares the values and the maintenance status of all authorization fields to determine whether new standard authorizations must be extended.
Changing SU24 values for a tcode
If the authorization data is changed for any tcode in SU24 and tcode is already present in the role, then going in the expert mode with option “read old data and compare with new data” will only reflect the additional changes. Change authorization data will not pull the new data for the tcode maintained at SU24 level.
2) Removing Tcodes from the role
When you remove transactions from the role menu, this has the following effect on the authorizations.
•A standard authorization for which the associated transaction was removed from the role menu is removed during the merge, unless at least one other transaction that remains in the menu uses the same authorization default value. This applies both for active and inactive standard authorizations.
•Authorizations in the statuses Changed and Manual are not affected by the merge. They are therefore always retained.
The table USOBT_C defines for each transaction and for each authorization object which default values an authorization created from the authorization object should have in the Profile Generator.
•Standard: All field values in the subordinate levels of the hierarchy are unchanged from the SAP defaults
•Maintained: At least one field in the subordinate levels of the hierarchy was empty by default and has since been filled with a value
•Changed: The proposed value for at least one field in the subordinate levels of the hierarchy has been changed from the SAP default value.
•Manual: You maintained at least one authorization in the subordinate hierarchy levels manually (it was not proposed by the Profile Generator).
Effect of SU24 changes in Role Groups
•Authorization objects are maintained in SU24 for a particular transaction code. When a transaction code is added to role, only the authorization objects having check as check indicator value and yes as proposal value, maintained for that tcode will be added into the role group.
•
1) Adding Tcodes to a role
When a new Tcode is added to a role
•When a new tcode is added to a role, going in either change authorization data or expert mode provides the same result. All the authorizations maintained for the tcode at SU24 level is added to the role.
•The program adds new standard authorizations for objects in the roles If the authorization default values contain objects that
were previously not existing
Or only had authorizations in the status Changed or Manual
•A new standard authorization is not included
if the authorization fields contain identical authorizations in the status Standard in both authorizations, and the fields maintained in the old authorizations are empty in the new standard authorization.
If there were already authorizations in the status Maintained (active or inactive) or Inactive Standard before the merge, the program compares the values and the maintenance status of all authorization fields to determine whether new standard authorizations must be extended.
Changing SU24 values for a tcode
If the authorization data is changed for any tcode in SU24 and tcode is already present in the role, then going in the expert mode with option “read old data and compare with new data” will only reflect the additional changes. Change authorization data will not pull the new data for the tcode maintained at SU24 level.
2) Removing Tcodes from the role
When you remove transactions from the role menu, this has the following effect on the authorizations.
•A standard authorization for which the associated transaction was removed from the role menu is removed during the merge, unless at least one other transaction that remains in the menu uses the same authorization default value. This applies both for active and inactive standard authorizations.
•Authorizations in the statuses Changed and Manual are not affected by the merge. They are therefore always retained.
What is the difference between USOBX_C and USOBT_C?
The table USOBX_C defines which authorization checks are to be performed within a transaction and which not (despite authority-check command programmed ). This table also determines which authorization checks are maintained in the Profile Generator.
The table USOBT_C defines for each transaction and for each authorization object which default values an authorization created from the authorization object should have in the Profile Generator.
What authorization are required to create and maintain user master records?
The following authorization objects are required to create and maintain user master records:
- S_USER_GRP: User Master Maintenance: Assign user groups
- S_USER_PRO: User Master Maintenance: Assign authorization profile
- S_USER_AUT: User Master Maintenance: Create and maintain authorizations
User Buffer
When a user logs on to the SAP R/3 System, a user buffer is built containing all authorizations for that user. Each user has their own individual user buffer. For example, if user Smith logs on to the system, his user buffer contains all authorizations of role USER_SMITH_ROLE. The user buffer can be displayed in transaction SU56.
A user would fail an authorization check if:
A user would fail an authorization check if:
- The authorization object does not exist in the user buffer
- The values checked by the application are not assigned to the authorization object in the user buffer
- The user buffer contains too many entries and has overflowed. The number of entries in the user buffer can be controlled using the system profile parameter auth/auth_number_in_userbuffer.
SU25 – Upgrade Tool for Profile Generator
Why SU25 is required?
Step1: If you have not yet used the Profile Generator or you want to add all SAP default values again, use the initial fill procedure for the customer tables.
If you have used the Profile Generator in an earlier Release and want to compare the data with the new SAP defaults after an upgrade, use steps 2a to 2d. Execute the steps in the order specified here.
-Step 2a: is used to prepare the comparison and must be executed first.
-Step 2b - If you have made changes to check indicators or field values in transaction SU24, you can compare these with the new SAP default values. The values delivered by SAP are displayed next to the values you have chosen so that you can adjust them if necessary. If you double-click on the line, you can assign check indicators and field values. You maintain these as described in the documentation for transaction SU24.
Note on the list of transactions to be checked To the right of the list you can see the status which shows
whether or not a transaction has already been checked. At first the status is set to to be checked.
If you choose the transaction in the change mode and then choose save, the status is automatically set to checked.
By choosing the relevant menu option in the list of transactions you can manually set the status to checked without changing check indicators or field values, or even reset this status to to be checked.
If you want to use the SAP default values for all the transactions that you have not yet checked manually, you can choose the menu option to copy the remaining SAP default values.
-Step 2c: You can determine which roles are affected by changes to authorization data. The corresponding authorization profiles need to be edited and regenerated. The affected roles are assigned the status “profile comparison required”.
Alternatively you can dispense with editing the roles and manually assign the users the profile SAP_NEW (make sure the profile SAP_NEW only contains the subprofiles corresponding to your release upgrade. This profile contains authorizations for all new checks in existing transactions). The roles are assigned the status “profile comparison required” and can be modified at the next required change (for example, when the role menu is changed). This procedure is useful if a large number of roles are used as it allows you to modify each role as you have time.
-Step 2d: Transactions in the R/3 System are occasionally replaced by one or more other transactions.
This step is used to create a list of all roles that contain transactions replaced by one or more other transactions.
The list includes the old and new transaction codes. You can replace the transactions in the roles as needed. Double-click the list to go to the role.
Step 3: This step transports the changes made in steps 1, 2a, and 2b.
Tailoring the Authorization Checks
This area is used to make changes to the authorization checks.
Changes to the check indicators are made in step 4. You can also go to step 4 by calling transaction SU24.
-You can then change an authorization check within a transaction.
-When a profile to grant the user authorization to execute a transaction is generated, the authorizations are only added to the Profile Generator when the check indicator is set to Check/Maintain.
-If the check indicator is set to do not check, the system does not check the authorization object of the relevant transaction.
-You can also edit authorization templates that can be added to the authorizations for a role in the Profile Generator. These are used to combine general authorizations that many users need. SAP delivers a number of templates that you can add directly to the role, or copy and then create your own templates, which you can also add to roles.
In step 5 you can deactivate authorization objects system wide.
In step 6 you can create roles from authorization profiles that you generated manually. You then need to tailor and check these roles.
- After upgrading SAP with the new release, you need to make adjustment to the all the roles and transaction codes.SU25 is the transaction code for upgrading profile generator.
- This has 6 different steps and the execution of these steps depends on whether you were already using profile generator in the last release.
Step1: If you have not yet used the Profile Generator or you want to add all SAP default values again, use the initial fill procedure for the customer tables.
If you have used the Profile Generator in an earlier Release and want to compare the data with the new SAP defaults after an upgrade, use steps 2a to 2d. Execute the steps in the order specified here.
-Step 2a: is used to prepare the comparison and must be executed first.
Note on the list of transactions to be checked To the right of the list you can see the status which shows
whether or not a transaction has already been checked. At first the status is set to to be checked.
If you choose the transaction in the change mode and then choose save, the status is automatically set to checked.
By choosing the relevant menu option in the list of transactions you can manually set the status to checked without changing check indicators or field values, or even reset this status to to be checked.
If you want to use the SAP default values for all the transactions that you have not yet checked manually, you can choose the menu option to copy the remaining SAP default values.
-Step 2c: You can determine which roles are affected by changes to authorization data. The corresponding authorization profiles need to be edited and regenerated. The affected roles are assigned the status “profile comparison required”.
Alternatively you can dispense with editing the roles and manually assign the users the profile SAP_NEW (make sure the profile SAP_NEW only contains the subprofiles corresponding to your release upgrade. This profile contains authorizations for all new checks in existing transactions). The roles are assigned the status “profile comparison required” and can be modified at the next required change (for example, when the role menu is changed). This procedure is useful if a large number of roles are used as it allows you to modify each role as you have time.
-Step 2d: Transactions in the R/3 System are occasionally replaced by one or more other transactions.
This step is used to create a list of all roles that contain transactions replaced by one or more other transactions.
The list includes the old and new transaction codes. You can replace the transactions in the roles as needed. Double-click the list to go to the role.
Step 3: This step transports the changes made in steps 1, 2a, and 2b.
Tailoring the Authorization Checks
This area is used to make changes to the authorization checks.
Changes to the check indicators are made in step 4. You can also go to step 4 by calling transaction SU24.
-You can then change an authorization check within a transaction.
-When a profile to grant the user authorization to execute a transaction is generated, the authorizations are only added to the Profile Generator when the check indicator is set to Check/Maintain.
-If the check indicator is set to do not check, the system does not check the authorization object of the relevant transaction.
-You can also edit authorization templates that can be added to the authorizations for a role in the Profile Generator. These are used to combine general authorizations that many users need. SAP delivers a number of templates that you can add directly to the role, or copy and then create your own templates, which you can also add to roles.
In step 5 you can deactivate authorization objects system wide.
In step 6 you can create roles from authorization profiles that you generated manually. You then need to tailor and check these roles.
1 comment:
best post.
go langaunage training
azure training
java training
salesforce training
Post a Comment