1 . How many fields can be present in one Authorization object?

Ans : 10 fields.
2 . Which Authorization Objects are Checked in Role Maintenance ?
Ans:
The role maintenance functions (and the profile generator) check the following authorization
objects.
AUTHORIZATION
DESCRIPTION
OBJECT

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 administrators 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

AUTHORIZATION
DESCRIPTION
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.

AUTHORIZATION
DESCRIPTION
OBJECT

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?
Ans:
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 TDDATusing 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 ?
Ans:
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. Whats the basic difference in between SU22 & SU24 ?

Ans:

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.
6. Whats the basic difference in between SU22 & SU24 ?
Ans:
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.
8. What does user compare do ?
Ans:
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 ?
Ans:
Authorization field can be changed to Organization field
using PFCG_ORGFIELD_CREATE orZPFCG_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 ?
Ans :
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 ?
Ans:
You can use PRGN_COMPRESS_TIMES to do this. Please refer to note 365841 for more
info.