SAP SECURITY INTERVIEW QUESTIONS & ANSWERS -2

SAP SECURITY INTERVIEW QUESTIONS & ANSWERS  

1.Please explain the personalization tab within a role. 

Personalization is a way to save information that could be common to users, I meant to a user role...  E.g. you can create SAP queries and manage authorizations by user groups. Now this information can be stored in the personalization tab of the role.  (I supposed that it is a way for SAP to address his ambiguity of its concept of user group and roles: is "usergroup" a grouping of people sharing the same access or is it the role who is the grouping of people sharing the same access)

2.Is there a table for authorizations where I can quickly see the values entered in a group of fields?  

In particular I am looking to find the field values for P_ORGIN across a number of authorization profiles, without having to drill down on each profile and authorization.
AGR_1251 will give you some reasonable info.

3.How can I do a mass delete of the roles without deleting the new roles ? 

There is a SAP delivered report that you can copy, remove the system type check and run. To do a landscape with delete, enter the roles to be deleted in a transport, run the delete program or manually delete and then release the transport and import them into all clients and systems.
It is called: AGR_DELETE_ALL_ACTIVITY_GROUPS.
To used it, you need to tweak/debug & replace the code as it has a check that ensure it is deleting SAP delivered roles only. Once you get past that little bit, it works well.

4.Someone has deleted users in our system, and I am eager to find out who. Is there a table where this is logged? 

Debug or use RSUSR100 to find the info's.
Run transaction SUIM and down its Change documents.

5.How to insert missing authorization? 

su53 is the best transaction with which we can find the missing authorizations.and we can insert those missing authorization through pfcg.

6.What is the difference between role and a profile? 

Role and profile go hand in hand. Profile is bought in by a role. Role is used as a template,  where you can add T-codes, reports..Profile is one which gives the user authorization.  When you create a role, a profile is automatically created.

7.What profile versions? 

Profile versions are nothing but when u modifies a profile parameter through a RZ10 and generates a new profile is created with a different version and it is stored in the database.

8.What is the use of role templates? 

User role templates are predefined activity groups in SAP consisting of transactions, reports and web addresses.

9.What is the different between single role & composite role? 

A role is a container that collects the transaction and generates the associated profile.  A composite roles is a container which can collect several different roles

10.Is it possible to change role template? How? 

Yes, we can change a user role template.  There are exactly three ways in which we can work with user role templates
- we can use it as they are delivered in sap
- we can modify them as per our needs through pfcg
- we can create them from scratch.

For all the above specified we have to use pfcg transaction to maintain them.

SAP SECURITY INTERVIEW QUESTIONS & ANSWERS -1

SAP SECURITY  INTERVIEW QUESTIONS & ANSWERS

Q.SAP Security T-codes
A.Frequently used security T-codes
SU01 Create/ Change User SU01 Create/ Change User
PFCG Maintain Roles
SU10 Mass Changes
SU01D Display User
SUIM Reports
ST01 Trace
SU53 Authorization analysis

Q.How to create users?
A.Execute transaction SU01 and fill in all the field. When creating a new user, you must enter an initial password for that user on the Logon data tab. All other data is optional. Click here for turotial on creating sap user id.

Q.What is the difference between USOBX_C and USOBT_C?
A.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.

Q.What authorization are required to create and maintain user master records?
A.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

Q.List R/3 User Types
A.1.Dialog users are used for individual user. Check for expired/initial passwords Possible to change your own password. Check for multiple dialog logon
2.A Service user - Only user administrators can change the password. No check for expired/initial passwords. Multiple logon permitted
3.System users are not capable of interaction and are used to perform certain system activities, such as background processing, ALE, Workflow, and so on.
4.A Reference user is, like a System user, a general, non-personally related, user. Additional authorizations can be assigned within the system using a reference user. A reference user for additional rights can be assigned for every user in the Roles tab.

Q What is a derived role?
A.•Derived roles refer to roles that already exist. The derived roles inherit the menu structure and the functions included (transactions, reports, Web links, and so on) from the role referenced. A role can only inherit menus and functions if no transaction codes have been assigned to it before.
•The higher-level role passes on its authorizations to the derived role as default values which can be changed afterwards. Organizational level definitions are not passed on. They must be created anew in the inheriting role. User assignments are not passed on either.
•Derived roles are an elegant way of maintaining roles that do not differ in their functionality (identical menus and identical transactions) but have different characteristics with regard to the organizational level.

Q.What is a composite role?
A.•A composite role is a container which can collect several different roles. For reasons of clarity, it does not make sense and is therefore not allowed to add composite roles to composite roles. Composite roles are also called roles.
•Composite roles do not contain authorization data. If you want to change the authorizations (that are represented by a composite role), you must maintain the data for each role of the composite role.
•Creating composite roles makes sense if some of your employees need authorizations from several roles. Instead of adding each user separately to each role required, you can set up a composite role and assign the users to that group.
•The users assigned to a composite role are automatically assigned to the corresponding (elementary) roles during comparison.

Q.What does user compare do?
A.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 FCG_TIME_DEPENDENCY on.

Q.How do I change the name of master / parent role keeping the name of derived/child role same? I would like to keep the name of   derived /child role same and also the profile associated with the child roles.
A.First copy the master role using PFCG to a role with new name you wish to have. Then you have to generate the role. Now open each derived role and delete the menu. Once the menus are removed it will let you put new inheritance. You can put the name of the new master role you created. This will help you keep the same derived role name and also the same profile name. Once the new roles are done you can transport it. The transport automatically includes the Parent roles.

Q.What is the difference between C (Check) and U (Unmentioned)?
A.Background:
When defining authorizations using Profile Generator, the table USOBX_C defines which authorization checks should occur within a transaction and which authorization checks should be maintained in the PG. You determine the authorization checks that can be maintained in the PG using Check Indicators. It is a Check Table for Table USOBT_C.
In USOBX_C there are 4 Check Indicators.
•CM (Check/Maintain)
-An authority check is carried out against this object.
-The PG creates an authorization for this object and field values are displayed for changing.
-Default values for this authorization can be maintained.
•C (Check)
-An authority check is carried out against this object.
-The PG does not create an authorization for this object, so field values are not displayed.
-No default values can be maintained for this authorization.
•N (No check)
-The authority check against this object is disabled.
-The PG does not create an authorization for this object, so field values are not displayed.
-No default values can be maintained for this authorization.
•U (Unmaintained)
-No check indicator is set.
-An authority check is always carried out against this object.
-The PG does not create an authorization for this object, so field values are not displayed.
-No default values can be maintained for this authorization..

SU24 Concept

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

What is the difference between USOBX_C and USOBT_C?

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?

What authorization are required to create and maintain user master records?

     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

                                                          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/auth_number_in_userbuffer.

SAP GRC Access Control: Configuring compliant user provisioning (formerly Virsa Access Enforcer) into CUA Systems

SAP GRC Access Control: Configuring compliant user provisioning (formerly Virsa Access Enforcer) into CUA Systems


Introduction

It is recommended for organizations with complex SAP landscape consisting of many SAP systems to use the Central User Administration (CUA) for user administration tasks. Use of CUA enables security admins to maintain user master records centrally from one system. Even though Access Enforcer provides an ability to perform user provisioning centrally from one place into multiple SAP systems, by no means Access Enforcer has the ability to replace CUA. Access Enforcer mainly deals with compliant automated provisioning. This article describes how to properly configure Access Enforcer to work with CUA. Some troubleshooting steps while using the CUA provisioning from AE are also discussed.

Procedure for Configuring CUA 

        a. Configure Connectors in AE :

1. It is very important to note that connector names in Access Enforcer should be exactly the same as the logical system names defined in CUA master and child systems. The screen shot below displays the logical system names of the CUA master system and one child system.

Basic Concepts-SAP Security

Basic Concepts-SAP Security