1 . How many fields can be present in one Authorization object?
Ans : 10 fields.
2 . Which Authorization Objects are Checked in Role Maintenance ?
The role maintenance functions (and the profile generator) check the following authorization objects.
|S_USER_AUT||User master maintenance: Authorizations
This authorization object defines which authorizations the administrator can process. You can use the activities to specify the types of processing (such as creating, deleting, displaying change documents).
|S_USER_GRP||User master maintenance: User groups
The authorization object is used in role maintenance when assigning users to roles and during the user master comparison.
You can divide user administration between several administrators with this authorization object, by assigning only a certain user group to an administrator. You can use the activities to specify the administrator’s processing types for the group (such as creating, deleting, and archiving).
|S_USER_PRO||User master maintenance: Authorization profiles
Profiles are protected with this authorization object. You can use the activities to specify the administrator\’s processing types for the profile (such as creating, deleting, and archiving).
|S_USER_AGR||Authorization system: Check for roles
This authorization object protects roles. The roles combine users into groups to assign various properties to them; in particular, transactions and authorization profiles.
You can use this authorization object together with the authorization objects S_USER_GRP, S_USER_AUT, S_USER_PRO, S_USER_TCD, and S_USER_VAL to set up a distributed user administration.
|S_USER_TCD||Authorization system: Transactions in roles
This authorization object determines the transactions that an administrator can assign to a role, and the transactions for which he or she can assign transaction authorization (object S_TCODE).
Note that a user can only maintain ranges of transactions for the S_TCODE authorization object in the Profile Generator if he or she has full authorization for the S_USER_TCD authorization object. Otherwise, he or she can only maintain individual values for the S_TCODE object.
|S_USER_VAL||Authorization system: Field values in roles
This authorization object allows the restriction of values that a system administrator can insert or change in a role in the Profile Generator.
This authorization object relates to all field values with the exception of the values for the object S_TCODE.
The authorization to include transactions in a role or to change the transaction start authorization in a role is linked to the authorization object S_USER_TCD.
|S_USER_SYS||Authorization object for system assignment in the Central User Administration (CUA).
You can distribute users from a central system to various child systems of a system group. The object S_USER_SYS is used to check the systems to which the user administrator can assign the users. This authorization object is also checked when setting up the CUA.
|S_USER_SAS||User master maintenance: System-specific assignments
The authorization object S_USER_SAS is checked in transactions SU01, SU10, PFCG, and PFUD when you assign roles, profiles, and systems to users. It represents a development of the authorization objects S_USER_GRP, S_USER_AGR, S_USER_PRO, and S_USER_SYS, which the system previously checked when users made assignments. If you do not activate the authorization object S_USER_SAS using the Customizing switch, the previously-used authorization objects are checked.
To activate authorization object S_USER_SAS, use transaction SM30 to create the Customizing switch CHECK_S_USER_SAS with the value YES in the table PRGN_CUST. All authorization checks for the objects S_USER_AGR, S_USER_PRO, S_USER_GRP, and S_USER_SYS with the activity assign are replaced by authorization checks for the object S_USER_SAS.
|S_USER_ADM||Administration functions for user and authorization administration.
The authorization object S_USER_ADM protects general Customizing and administration tasks for user and authorization administration. It consists solely of the authorization field S_ADM_AREA.
Until now, there was only the fixed value CHKSTDPWD, with which special users (such as SAP*) could be displayed, including their default passwords. SAP extends additional fixed values as required for other general administration functions in the area of user and authorization administration, which are listed in SAP Note 704307.
3 . Which T-Codes are used to see overview of the Authorization Object and Profile details?
SU03 – overview of any authorization Object
SU02 – to see the details of profiles.
SU21 also provides the same editing structure as SU03 but we can create a new authorization object using SU21. Here, we need to click on “Display Object Documentation“ button to see the documentation for the authoriztion Object and we need to click on “Permitted activity values“ to see the list of permitted activities for the fields.
These details are fetched from table TACT.
4. How to restrict the user access to one particular table in display mode ?
Ans : If the system is BASIS 700, we can use the authorization object S_TABU_NAM. In this auth. Object, we can maintain the values for required activity and the table name.
If the system version is lower than 700, and the table is z* table then
- Create a new authorization Group using SE54.
- Assign the table in question to the newly created authorization Group in table TDDAT using SM30.
If the table is SAP standard table then we can restrict user access by creating new tcode in SE93.
5.How to check the table Logs ?
First, we need to check if the logging is activated for table using tcode SE13. If table logging is enabled then we can see the table logs in t-code SCU3.
6. What’s the basic difference in between SU22 & SU24 ?
SU22 displays and updates the values in tables USOBT and USOBX, while SU24 does the same in tables USOBT_C and USOBX_C. The _C stands for Customer. The profile generator gets its data from the _C tables. In the USOBT and USOBX tables the values are the SAP standard values as shown in SU24. With SU25 one can (initially) transfer the USOBT values to the USOBT_C table.
7. 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 programed). 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.
8. What does user compare do ?
If you are also using the role to generate authorization profiles, then you should note that the generated profile is not entered in the user master record until the user master records have been compared. You can automate this by scheduling report PFCG_TIME_DEPENDENCY on a daily or by executing the t-code PFUD.
9. Can we convert Authorization field to Organizational field ?
Authorization field can be changed to Organization field using PFCG_ORGFIELD_CREATE or ZPFCG_ORGFIELD_CREATE.
Use SE38 or SA38 to run the above report.
- Organizational level fields should only be created before you start setting up your system. If you create organizational level fields later, you might have to do an impact analysis. The authentication data may have to be post processed in roles.
- The fields “Activity“, “ACTVT” and “Transaction code“, “TCD” cannot be converted into an organizational level field.
In addition, all affected roles are analyzed and the authorization data is adjusted. The values of the authorization field which is now to become the organizational level field are removed and entered into the organizational level data of the role.
Note: Table for Organizational Element- USORG. Refer to Note 323817 for more detail.
10. What is 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:
- 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/number_in_userbuffer.
11. How to remove duplicate roles with different start and end date from user master ?
You can use PRGN_COMPRESS_TIMES to do this. Please refer to note 365841 for more info.
Leave a Reply