RSUSR200 Report - List user according to system, validity, User type, lock status and logon attempts

1. Execute SA38 > RSUSR200
   
   
   
2. There are many selection. This screen show that you can select by system
   
   
3. You may also choose by User Type
   
   
   
4. Execute and report display as below
   

Display a list of user's password status and lock status

1. Execute tcode rsusr200 or 
2. Tcode SUIM > User > By Complex Selection Criteria > By Logon Date and Password change
3. Enter a list of user.
4. You will be able to see details as below

SU24 Concept

SOURCES: http://sapsecurity.info/2010/07/su24/

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.

Difference between SU22, SU24 and SU25

Difference between SU22, SU24 and SU25

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 SAP standard values as shown in SU24.

With SU25 one can (initially) transfer theUSOBT values to the USOBT_C table

Table USR02 - User Lock value

1. Execute SE16
2. Enter USR02
3. Below are the value and its description:

Value:

0	Not locked
16	Lock
32	Locked by CUA admin (User Admin)
64	Locked by system Administrator
128	Locked due to incorrect logon attempts or too many failed attempts
192	A combination of both. The user is locked by admin and user tries to logon with incorrect passwords and gets locked ( 192 = 64+128)

GRC 5.3 - Valid to date is always the current date during submission of a new request

1. GRC 5.3 provision user with validity period the same day user was created. SU01 screen as below:
   
2. In GRC you can see the following when request for a new account:
   
3. This was cause by following settings in GRC 5.3 in Configuration > Field Mapping > LDAP Mapping > Additional Fields > validToDate
   
4. Remove this entries and try again.

GRC 5.3 SNC - Provision with upper case userid which cause SNC to fail

1. GRC 5.3 is able to provision SNC settings to SU01 but USERID appears in upper case format as below:
   
   
   
2. SNC is case sensitive, thus it will failed when user tried to login.
   
3. Because GRC 5.3 convert user id to UPPERCASE as below:
   
   
   
4. This can be resolved in two step.
   
5. Step 1: Configuration > Request Form Customization > SNC Name >
   Default value > p:#!#userId#!#@DOMAIN.COM
   
   
   
6. Step 2: Configuration > Field Mapping > LDAP Mapping > Additional Fields > Add SAP_User_ID and then map it to the correct LDAP fields. In our case, its "mailNickname" because it is in lowercase.
   
   
7. GRC will then replace userId with the LDAP field "mainNickname" which is in lowercase
   
   
   
8. Once provision, SNC field in SU01 will be in this format p:zmolan@DOMAIN.COM

SOD Scan using /n/virsa/zvrat

1. Tcode /n/virsa/zvrat
2. Ok
   
   
   
3. Enter userid
   
4. Choose the system where user id was created
   
   
   
5. Then execute
6. If the system id was not found, you may add the system using those entries in SM59.
7. To add, execute /n/virsa/zvrat_s16
8. Select Comp Calibrator Configuration
   
   
   
9. Under Parameter 19, add in a new system
   
   
   
10. Save and try scan again

VIRSA - HOW TO export mitigation control

1. SA38 or SE38 and execute  /VIRSA/ZVRAT_L03
2. Enter the following details:

3. Exported file looks like:

HOW TO SAP - Perform system trace for missing authorization

How to perform system trace for authorization

1. Execute tcode ST01
   
2. Check Authorization Check (you may select more)
   
   
   
3. Click Trace On (Make sure to turn it off after you are done!)
   
   
   
4. Now ask user to perform their task.
5. *If there is more then one app server, go tcode SM51
6. *Then double click on the app server.
7. *Then repeat step 1 to 3
8. Remember - Once user completed the test, turn of all trace from ST01
   
9. Now, click Analysis
   
   
   
10. Filter the trace like below (select what you need)
    
11. For authorization issue, anything above RC=0 meaning there is missing authorization.
    

Table usla04 to locate single role coming from which child system in CUA

In CUA system, you can use table USLA04 to  check the role originates from which child system.

1. SE16
2. Enter USLA04
   

Performance issue on MDG - Manual Pre Implementation Step (Note 1719803)

1. Tcode PFCG, Edit the MDG role
2. Click on Menu tab
3. Expand the Hierarchy
4. Go to Role Menu > Supplier Governance > Change Request > Search Supplier > 
5. Right Click on WDY_Application - Enterprise Search  > Details
   
6. Update Application configuration according to SAP note
   
7. This is where you update the field application config:
   
   
   
8. Now do the same for others.
   
9. After this is done, Basis can perform the note 1719803 implementation now

SBWP > No Administrator Found for the task

This is nothing to do with authorization. To resolve, go to
SO01--> settings --> workflow settings-->refresh organization environment

SAP SECURITY AUTHORIZATION: S_TABU_DIS has no 01 Activity

Given the high criticality and increasing complexity related to table access –
SAP® has introduced a new authorization object for a more refined
table access control.

The authorization object S_TABU_NAM was introduced last year.
This authorization object consists of two fields ACTVT (Activity)
and TABNAME (name of table or view).
This concept is valid for generic table access through transactions like SE16,
SE16N, SE17, SM30, SM31, SM34 as well as generic function modules
(e.g. RFC_READ_TABLE)

The authority-check was integrated in the function module
VIEW_AUTHORITY_CHECK as per Release 7x with corresponding
Support Packages (Please refer to OSS Notes 141950 and 1434284
for more details).

To make sure the new object is downwards compatible with the previous
checks on S_TABU_DIS and S_TABU_CLI where applicable;
the check will only be performed if the check on S_TABU_DIS was not successful.