SAP GRC

1. Which ticketing tool you are using? Why it is used and how many tickets you will get per
day and how many you resolved a day?

 We are using Snow ticketing tool. Snow is software which provides solutions for the
tickets.
 Ticket means a problem. There are many ticketing tools are available. Ex: REMEDY,
Snow.
 Service Now is used for create an incident and resolve it.
 We are getting 10 to 15 tickets per day. I am going to resolve 7 tickets per day.

Prioritization of Incidents: ITIL (Information Technology Infrastructure Library) uses

three metrics for determining the order in which incidents are processed.
 Impact: The effect an incident has on business.(1-High, 2-Medium, 3-Low)
 Urgency: The extent to which the incident's resolution can bear delay. (Same as
above)
 Priority: How quickly the service desk should address the incident. (1-Critical, 2-
High, 3-Moderate, 4-Low, 5-Planning).

SEVIARITIES ABOUT TICKETS:

SERV 1: Need to resolve tickets in 0-4 hours

SERV 2: Need to resolve tickets in 0-8 hours
SERV 3: Need to resolve tickets in 3 working days.
Production Support: Should be on call support.
Situation Manager: Makes everyone to attend on call.
Q) When you are On Call Support when you get Severity 1 ticket, How do you take
action?
 Firstly open the ticket
 Read the message what the problem is about
 Login to targeted Servers.
 Check Logs depending on Error.
 Propagates first-hand information to STAKE HOLDER (DUTY
MANAGER).
 Sit on Issue, fix it, and Close it.
2. Why is GRC? Instead of it we can use Security right?
 Connector Configuration

ECC_RFC_USER (Communication User)

 A User ID needs to be created in ECC for the RFC setup, with required
authorizations.

Connectors:

 Connectors are the links between SAP Access Control tool and target systems to fetch
data into the SAP Access Control System.
 Connector is nothing but RFC connection to which you are connecting GRC system to
plug in systems to getting data about user authorization or to perform risk analysis.
 Connectors are used for communication between GRC system and target systems where
GRC plug-in is deployed.
 In SAP GRC Connectors and Connector types are defined globally.
 Create and maintaining connector settings from a SAP GRC system to any SAP / Non-
SAP systems to get different data, execute risk analysis or create and provide for roles.

Connector Types:

As a part of creating connectors, you need to define connection types and map the actual
connectors with the connection types.

Different types of connections that are available to use in SAP Access Control are…

 SAP
 LDAP
 SPML (Service Provisioning Markup Language)
 FILE
 EP
 LOCAL
Connector Groups:

 Connector group is a logical group to use common rule set. Like standard you can create
your own group map with rule set, whoever connector defined in that group will use the
same rule set.
 So, to clarify: If I have ECC, HR, SRM, CRM systems in my landscape and I want to use
same rule set across these systems I will use a Connector Group.

Connector Group Types:

1. Logical Group:

 Logical group consists of the systems that are logically the same.
 Ex: All SAP ERP systems or Oracle systems.

2. Cross-system Group:

 Cross system group consists of the systems with different environments.

 Ex: SAP CRM, SAP SRM, LDAP, and Oracle applications.

Steps for Connector Configuration:

Summary:

 SPRO  IMG GRC Common Component SettingsIntegration Framework 

1. Create Connectors
2. Maintain Connectors and Connection types
3. Maintain Connection Settings

 SPRO  IMG GRC Access Control

4. Maintain Connector Settings

5. Maintain Mapping for Actions & Connector Groups
1. Create Connectors: (SM59)

RFC Connections ABAP Connections  Create Button

RFC Destination: GRCCLNT100

Connection Type: 3 ABAP Connections
Description 1, 2, 3: RFC Destination to GRC Client 100

Technical Settings Tab:

 Target Host : INDIA and Enter button System No: 02

Logon & Security TAB

 Language: EN
 Client: 100
 User: SUDHA
 Password: india123

RFC Destination name and Client logical system name must be same

Testing RFC Connection:

 Clicking Connection Test button and Remote Logon button. (Or)

 Utilities ------- Test ----- Connection Test and ----- Authorization Test.

Start SAP ECC Server…

RFC Connections ABAP Connections Create Button

RFC Destination: T90CLNT090

Connection Type: 3 ABAP Connections
Description 1: RFC Destination to ECC Client 800

Technical Settings Tab Logon & Security TAB

Language: EN
Target Host: india.server.com Client: 800
System Number: 02 User: SAPUSER
Password: india123
Gateway Host: india.server.com
Gateway service: sapgw02
 NOTE 1:

You can find Gateway Host Name and Gateway service details, in
TCODE: SMGW
Menu Go to Parameter  Display

NOTE 2:
 Connection Test fails means need to check Technical settings tab Host name and System number.
 Authorization Test fails means need to check Logon Security Tab user name and Password.

2. Maintain Connectors and Connection types:

2. a. Define Connectors

2. a. I. Define Subsequent Connectors

2. b. Define Connector Groups

2. b. I. Assign Connector Groups to Groups Types

2. b. II. Assign Connectors to Connector Groups

2. a. Define Connectors:

 Double Click on Define Connectors on left side and

 Click on New Entries

Target Connection Source Connector Logical Port Max No. of

Connector Type BG WP
GRCCLNT100 SAP GRCCLNT100 GRCCLNT100 3
T90CLNT090 SAP T90CLNT090 T90CLNT090 3
From data point of view which The port through which data
system is consider to be has Source. exchange will be done b/w ECC &
Both are same as Source and Target. GRC

2. a. I. Define Subsequent Connectors:

 If portal connectors are planned in your project, you need to maintain the
subsequent connector definition.
  Subsequent connector meant to maintain a logical port as an additional
requirement to connect and get the data.
 Double click on Define Connectors ------ Select an entry
T90CLNT090and Double click on Define Subsequent Connector.
Note: Whenever we are going to Sub folder one entry has to be chosen
from Main folder.
 Subsequent Connectors are defined only for JAVA System not required
for ABAP System.

2. b. Define Connector Groups:

 Double Click on Define Connector Group ( left side)

 Click on NEW ENTRIES

Connector Group Connector Group Text Con. Type

BUSINESS Business Roles
SAP_CRM_LG SAP CRM
SAP_ECC_LG SAP ECCS SAP
SAP_GRC_LG SAP GRC Logical Group SAP
SAP_R3_LG SAP R3 SAP
ABAP_GROUP ABAP Group SAP
JAVA_GROUP JAVA Group EP
 2. b. I. Assign Connector Groups to Groups Types:

 Select SAP_GRC_LG and double click on Assign Connector

Groups to Group Types ---------New Entries
 Connector Group Type: Logical Group and Click on SAVE.
 The groups created in the earlier step should be declaring here as
Logical Group.

2. b. II. Assign Connectors to Connector Groups:

 Select SAP_GRC_LG Double Click on Assign Connectors to

Connector Groups
 Click on New Entries

Target Connector Connection Type

GRCCLNT100 SAP
T90CLNT090 SAP

 Click SAVE

3. Maintain Connection Settings:

 The integration scenario functionality is designed to work with different applications

from SAP Access Control.
 You can use integration scenarios to define what kind of connector you want, how you
want to maintain the connector, and how to technically deal with the connectors and
connection types for each SAP Access Control tool.

Integration Scenario Text

AM Automatic Monitoring (Process Control)
AUTH Authorization Management (ARA)
PROV Provisioning (ARM)
ROLMG Role Management (BRM)
SUPMG Super User Privilege Management (EAM)

 Ex: The AUTH Scenario is meant for the Access Risk Analysis tool of SAP Access Control
to connect with the target system.
  Integration Scenario: AUTH
 Tick

Sub scenario definition

Sub Scenario Sub Scenario Text
AUTH Authorization Management

 Select AUTH, and click on Scenario-Connection type link (left side)

Scenario-Connection type Link

Con.Type Connection Type Text Class/Interface
FILE File system for legacy CL_GRAC_AD_AUTH_MGMT_FILE
extraction
LDAP LDAP Connectors CL_GRAC_AD_AUTH_MGMT_LDAP
SAP SAP System CL_GRAC_AD_AUTH_MGMT_RFC
WS Web service CL_GRAC_AD_AUTH_MGMT_WS

 Select SAP, and click on Scenario-Connector Link (left side)

 New Entries

Scenario-Connector Link
Target Connector Con.Type Connection Type Text
GRCCLNT100 SAP SAP System
T90CLNT090 SAP SAP System

 Click SAVE
 Do the same for rest of the integration scenarios like PROV, ROLMG, and
SUPMG.

4. Maintain Connector Settings:

 Click on New Entries

Dialog Structure
 Maintain Connector Settings Maintain Connector Setting
 Assign Attributes to the Target Appl Environme Path PSS
connector Connector Type nt Id
T90CLNT090 1 Production 

5. Maintain Mapping for Actions & Connector Groups:

5. a. Maintain Connector Group status

5. b. Assign default connectors to Connector Group

5. a. Maintain Connector Group status:

New Entries

Dialog Structure
 Maintain Connector Group Status Maintain Connector Group Status
 Assign default connector to Connection Group Active Appl Type
connector group SAP_R3_LG  1
 Assign group field ABAP_GROUP  2
mapping
 Assign group
parameter mapping

5. b. Assign default connectors to Connector Group:

 Double Click on Assign default connectors to Connector Group.

 Click on New Entries

Dialog Structure
 Maintain Connector Group Status Maintain Connector Group Status
 Assign default connector to Conn. Group Action Target Connector Default
connector group SAP_R3_LG 1 T90CLNT090 
 Assign group field SAP_R3_LG 2 T90CLNT090 
mapping SAP_R3_LG 3 T90CLNT090 
 Assign group SAP_R3_LG 4 T90CLNT090 
parameter mapping SAP_R3_LG 5 T90CLNT090 

 If the Connector Group has more than one system, than this step has to be
repeated for every system under the connector group.
 Only one system can be defined as Default connector for one action under
connector group.

Action List:

1. Role Generation
2. Role risk Analysis
3. Authorization Maintenance
4. Provisioning
5. HR Trigger
 Post Installation Steps

1. Check for required Software components as mentioned below.

2. Activate all the BC Sets related to *GRAC* and *MSMP* through T Code: SCPR20.
3. Activate all the Services related to *GRAC* and *NWBC* through T Code: SICF.
4. Activate all relevant Applications in the client.
5. Workflow for Perform Automatic workflow customizing or SWU3.
6. Workflow for Perform – Task specific customizing.

1. Check for required Software components as mentioned below:

 GRCFND_A ======== GRC

 GRCPINW ======== ECC
 GRCPIERP ======== HR

 Login into SAP GRC ======= Systems ===== Status ==== SAP
System Data ===== Component information.

2. Activate all the BC Sets related to *GRAC* and *MSMP* using T Code: SCPR20:

 BC Set ====== *GRAC* click on Continue button ====== Select each BC Set
===== Click on “Activate BC Set (F7) symbol”. Or Menu BC Set  Activate.
 BC Set Activated or not we can check through ============ Click on
“Activation Logs symbol”.
 If we want to check BC Set details / delivered values ========= Click on
“Overall View button (F6)”.
 To see list of Activated BC Sets === SE16 ===== SCPRACTP.

 ARM ====== Access_Request (4 BC Sets)

 ARA ====== Rule Set (12 BC Sets)
 BRM ====== Role_MGMT (5 BC Sets)
 EAM ====== SPM_CRITICALITY (01 BC Sets)

 Total BC Sets in *GRAC* = 22 BC Sets.

 Total BC Sets in *MSMP* = 3 BC Sets.
 Use Expert mode for activation and make sure that you see the message Activation
Successfully Completed.

3. Activate all the Services related to *GRAC* and *NWBC* through T Code: SICF:

 T Code: SICF ===== Hierarchy Type: SERVICE

Service Name: *GRAC* / *NWBC*
And Click on Execute.
 Expand Node Defaults ====== SAP ===== BC === Web dynpro ===
SAP ====== Right click on each node ===== “Activate Service”.

And also

Default_host=== SAP === BC === Web Dynpro === SAP

Default_host === SAP === BC === Work flow === NWBC

Default_host === SAP === BC === NWBC

Defaults ====== SAP === GRC === NWBC

4. Activate all relevant Applications in the client:

 SPRO ====== IMG ====== GRC ==== General Settings =====

Activate Applications in the Client.

Active applications in client

App Active
GRC – AC 
GRC – PC 
GRC – RM 

5. Workflow for Perform Automatic workflow customizing or SWU3:

 SPRO ====== IMG ====== GRC ==== General Settings =====

Workflow ===Perform Automatic workflow customizing. Or SWU3.
 All entries inside this screen should be “GREEN”.
  If not Green ==== Take a screen shot ==== send to BASIS team and ask them
to turn it has “Green”.
 Maintain Runtime Environment
 Maintain Definition Environment
 Maintain Additional Settings and Services
 Classify Tasks as General
 Guided Procedures

 We have to activate all of the steps from this transaction individually at all the five
sub-heading level to complete basic workflow engine related settings.

 Right click on each activity and Click on Execute Activity / Auto Customizing.
Or
 Select the Sub Activity under Main Activity ====== Click on Execute. ======
To activate all the items, you need to update WF-BATCH which is carrying
Background Jobs.
T Code: SU01
User: WF-BATCH ===== Modify User
Change password to india123
Email: nvrsudhakara@gmail.com (Compulsory)
Profiles: SAP_ALL and SAP_NEW

6. Workflow for Perform – Task specific customizing:

 SPRO ====== IMG ====== GRC ==== General Settings =====

Workflow === Perform Task specific customizing.
 Go to GRC folder and Click on “Assign agents”.
Select the task that is Blank ==== Attribute button
 Select General Task and Click on “Transfer” and

 Click on “Activate Event Linkage”.

 Expand all events started with “WS***” ====Click on “Detail view”
===== It opens “Properties of event Linkage”
Linkage status: No Errors

 Do the same for GRCAC subfolders also.

 EMERGENCY ACCESS MANAGEMENT (EAM)
3. Why EAM?

 The purpose of EAM is to allow users to complete tasks outside their normal day to day
responsibility (authorizations). Means never and rarely used T Codes required to users to
resolve some production issues or critical &emergency access conditions.

SAP (Firefighter) -------- USER + Extra privilege’s.

 EAM component gives temporary access (24 Hours / 2 Days) to users when assigned for
solving a problem by giving broad - regulated access which can be audited.

 This temporary access is monitored and recorded in the application.

 Emergency Access Management helps reduce your business downtime due to any
authorization-related issues.
 The use of Emergency Access Management to manage and utilize firefighting activities
centrally in GRC Access Control 10.0 application and also follow the channel for log
files can be distributed to controllers and owners via workflow for additional approval.

Advantages/ Uses of EAM:

1. EAM allow users to perform additional activities outside of their normal job function.
2. Allow temporary access for users when they required resolving some business tasks but
regulated access.
3. This temporary access will monitor and reviewed by the FF Controllers.

Pre requisites:

 Never assign SAP_ALL profile to FFID; instead FFIDs are classified according to
module wise like… FFDEV1, FFDEV2, FFDEV3 (OR) FFBI1, FFBI2, FFBI3…………
these separate set of IDs are assigned with respective development access.
 If we assign SAP _ALL to FFID, then FFID becomes itself a risk.
Example:
If we assign Finance FFID with SAP_ALL, he will have the possibility of modifying the
system and it is a risk.
 To handle extreme conditions beyond Development access, we create a FFID accessible
to all teams with a role (Which is a copy of SAP_ALL Profile). These FFIDs will need
highest approval (Senior Manager) and its usage is strictly monitoring.
 4. Firefighter types or user types in GRC?

User Type Responsibility Role

Firefighter ID Extra privileged user ID. All activities performed are SAP_GRAC_SPM_FFID
(ECC) tracked for audit purpose.
Firefighter Person who performs some additional activities by using SAP_GRAC_SUPER_USER_
(GRC) a Firefighter ID. MGMT_USER
Firefighter ID Person who owns the ID and has authority to assign SAP_GRAC_SUPER_USER_
Owner (GRC) firefighter IDs to others. MGMT_OWNER
Firefighter ID Person who reviews the reason code/description and SAP_GRAC_SUPER_USER_
Controller audit trail to ensure that access was used appropriately. MGMT_CNTLR
(GRC) The user can be notified when firefighter IDs are checked
in/out and notified of all activities performed via email
trigger.

I. Fire Fighter:

 FF is a normal user requiring emergency access to perform extra activities.

 The user who requires emergency access.
 Ex: Mr. Rama is a user in SAP ERP System. Rama seeks additional access, so we will
create a Fire Fighter User in GRC System (Rama Fire Fighter).
 So, Rama has to login to the GRC system and perform additional activities in ECC.

II. Fire Fighter ID/Role:

 User ID with extra privileges; it can only be accessed in the GRC server using transaction
GRAC_SPM. As per latest update from SAP 10.1 FFID user type either Dialog/ Service.
 Firefighting: The act of using a firefighter ID.
 Fire Fighter ID/Role will be created on Target SAP ERP System.
 Fire Fighter ID will be synchronized to the SAP GRC System.
 Fire Fighter ID will be added to the Fire Fighter using NWBC Setup work set.

Difference between FF and FFID:

  In order to perform/ handled an extraordinary situation FF (Normal user) requests for
elevated access, which is assigned through FFID.
 We don’t assign FF access to Business users and only for Technical users we assign.

Rama Rama FF

SAP GRC System

SAP ERP System

Fire Fighter ID/Role

Fire Fighter ID/Role

FF Owner

Fire Fighter Controller

III. Fire Fighter Owner: (Manager of AP Team, GL Team)

 FFID Owners are responsible for maintaining Firefighter IDs and their assignment to
Controllers and Firefighters.
 FF Owners are responsible to assign FFIDs to FFs and FF Controllers.
 FFID Owner is a person from respective modules (GL, AP and BASIS Manager) who
approves assignment of FFID to FF.
 Create a user called Fire Fighter Owner in SAP GRC System.
 And Assign Fire Fighter Owner to Fire Fighter using NWBC Setup work set.

IV. Fire Fighter Controller: (Controls Team)

 Reviews and approves (if necessary) the log files generated by a firefighter.
 FFID Controller is responsible for monitoring and reviewing of activities done by FF
by using FFID.(SM20 FF Audit Logs)
 As we provided fire fighter to the Rama, we have to monitor the Rama activities.
 Fire Fighter Controller is responsible to monitor the activities of Fire Fighter Users.
 Assign Fire Fighter to Fire Fighter Controller using NWBC Setup work set.
 Generally this person is from Controls Team, who reviews Audit logs against the
Reason Codes and T Codes mentioned by FF before using his FFID access.
 FFID Controller can be notified in 3 ways.
a. Email
b. Workflow
 c. Log display

1. Create the User IDs in ECC and GRC :

SAP ECC System: SU01

Firefighter ID
USER ID RAMAFFID
TYPE Service
Roles SAP_GRAC_SPM_FFID

GRC System: SU01

Firefighter Firefighter Owner Firefighter Controller

RAMAFF FFOWNER FFCNTLR

Dialog Dialog Dialog
SAP_GRAC_SUPER_USER_MGMT SAP_GRAC_SUPER_USER_MGMT SAP_GRAC_SUPER_USER_MGMT
_USER _OWNER _CNTLR

SAP_GRC_FN_BASE SAP_GRC_FN_BASE SAP_GRC_FN_BASE

SAP_GRC_FN_BUSINESS_USER SAP_GRC_FN_BUSINESS_USER SAP_GRC_FN_BUSINESS_USER
SAP_GRC_NWBC SAP_GRC_NWBC SAP_GRC_NWBC

2. Declare FFID Owner and Controller:

NWBC -------- Setup ---------- Access Owners -------- Access Control Owners.

3. Define FFID Owner & Controller for the FFID in GRC system:

NWBC --------- Setup --------- Super User Assignment -------- Owner

NWBC --------- Setup --------- Super User Maintenance ------- Controllers

4. Define Reason codes:

NWBC --------- Setup --------- Super User Maintenance -------- Reason Codes.
4. Technically wise types of Firefighter Applications?

 This is configured in IMG using parameter 4000 (Application Type).

 Only one application type can be configured at a given time.
 There are two types of Firefighter applications.
1. ID Based FF
2. Role Based FF

1. ID Based Firefighter:

 The Firefighter ID created in the ECC System will be assigned to the user in the
GRC system. Either manually or via an access request (NWBC).
 The Firefighter accesses their assigned Firefighter ID in the GRC server using the
SAP GUI and transaction GRAC_SPM.
 The Firefighter ID for all remote systems assigned to the firefighter will be
accessed from this transaction.

2. Role Based Firefighter:

 The Firefighter roles created in the remote system will be assigned to the user in
the GRC server.
 The Firefighter directly logs into the remote system using their user ID and
performs activities which are provided in the user’s role and Firefighter role
assigned to the user.
 The web interface facilitates the following:
  Firefighter ID/Role Owner Maintenance.
 Firefighter ID/Role Controller Maintenance.
 Reason Code Maintenance (system specific).
 Firefighter ID/Role assignment to Firefighter, Owner, Controller.

Note: Firefighter access is done centrally using the GRC server. Firefighters will log on to the
GUI backend and execute transaction GRAC_SPM. Firefighter IDs for emergency access for all
systems assigned to the user will display.

5. Usage of FF Concept or Difference b/w Centralized and Decentralized Firefighter? Or

From End-user point of view and from GRC AC 10, SP10 FF activity usage types?

Access Control 10.0 provides a centralized logon pad for accessing the Firefighter IDs in all
connected backend systems. There are 2 types of FFs.

i) Centralized FF concept
ii) Decentralized FF concept
 1. Centralized FF Concept:

 When Firefighter activity is done by logging into GRC system, it is known as

Centralized FF. Login into GRC and through GRC logon into ECC using RFC
connection is called Centralized FF.
 Log onto the GRC system, and use transaction GRAC_EAM to remotely access
all authorized plug-in systems. In this scenario, the GRC system and the EAM
Launch pad provide a centralized access point to the plug-in systems for
firefighting.

The centralized logon pad allows:

 Displaying all Firefighter ID assigned to the user.

 Logging in to all connected backend systems.
 Sending messages to other Firefighters who are using a specific Firefighter ID.
 Unlocking a Firefighter session not closed properly.

Centralized Firefighter steps summary:

 The Firefighter logons to central GRC system.

 T Code: GRAC_SPM, a screen will open up which will display all Firefighter
IDs which are assigned to the current Firefighter in various systems.
 Click Logon to login into any of the systems assigned.
 Select a Reason Code.
 Enter a description.
 Enter a list of the actions to be performed.
 Click on Execute.

Note: The Firefighter can now do Firefighting activities on the connected backend system. When
finished you need to close the session.

Centralized Firefighter Prerequisites:

 Application type is 1 for ID Based Firefighter.

 Set Parameter Group 6 super users management.
 Set Parameter ID 4000- Application type.
 Firefighter user must exist in the central access control system and the role
SAP_GRAC_SPM_FIREFIGHTER.
While a Firefighter Session is running the status of the firefighter ID will display in red -
reasons:

The Firefighter can take the following actions:

 Click Additional Activity to enter more information.

 If the firefighter ID is in use by another firefighter, choose Message to send
notification to the other firefighter.
 Choose Unlock to unlock the Firefighter ID if it is locked.

Advantages:

 A FF can login into any plugin system from centralized GRC System.(Instead
of user login into each plugin system)
 Since license cost increases planning to move to Decentralized.

Disadvantage:

 When GRC system is down for maintenance, all plugin systems are down and
FF concept is not working.
 FF has to exist in GRC system. This increases license cost.

2. Decentralized FF Concept:

 When firefighter activity is done from backend system, it is known as Decentralized FF

concept.
 Firefighters can directly logon to the plug-in systems for firefighting; using the GRC
system only for maintaining emergency access assignments and reporting.
 Log onto the respective plug-in systems, and use transaction /NGRCPI/GRIA_EAM to
perform the firefighting activities.
 In this scenario, as firefighting is performed locally on each of the plug-in systems, you
have uninterrupted firefighting access in case the GRC system is not available, however,
you must make sure you have user accounts on each of the plug-in systems.
 Functions such as assignments, and reporting is still maintained in the GRC system.
6. Synchronization Jobs in GRC?

 The purpose of Synch jobs is to identify plug-in system data in GRC through NWBC.

SPRO------>IMG-----GRC----------> Access Control----------> Synchronization Jobs.

1. Authorization Synch:

 Synchronizes PFCG Authorization data.

 Once in a month we run.

2. Repository Object Synch:

 Synchronizes Profiles, Roles, and Users master data.

 Daily once we run.

3. Action Usage Synch:

 Synchronizes action usage data (or)

 T Codes used by Users.

4. Role Usage Synch:

 Synchronize role usage data (or)

 Roles used by users.

5. Firefighter Log Synch:

 Synchronizes the firefighter logs from plug-in system to GRC system.

 This is used to synch to usage of FFID in ECC system.

6. Firefighter Workflow Synch:

 This is used to send the FF log report to FF controller for review.

7. Fetch IDM Schema:

 IDM- Identity Management
 This job is especially used for EP/ Java Systems only, not required for ABAP.
Note:

 SM37 ------ Checking Synch Job status.

 SLG1 ----- For Troubleshooting Synch Jobs.
 For ABAP systems the below 2 jobs have to be executed as soon as connector
configuration done.
 Authorization Synch
 Repository Object Synch
 For JAVA system
 Repository Object Synch
 IDM Schema

7. If FFID Controller is on leave or not available? What you can do in this situation?

 In order to avoid this type of situation a single FFID Owner is not available
then……..
a) We maintain 2 FFID Owners for both Onshore (US) & Offshore
(India). (Multiple Owner Strategy)
b) Delegation of Ownership – Controls team can delegate the
approval of FFID Owner from one person to another person.

8. If there is more than one FF accessing the system, how the controllers get FF Logs?

 Only one FFID can be used by FF one time.

 If the other user wants to use the FF at the same time it will be shown as a RED
status and need to send a message to FF.

9. How do you pull FF Logs? (Or) How are you getting FF Logs?

 FF Log synch.
 Reports and Analytics Work center ----------- Consolidated Log Synch.
 From STAD pulls the data.

EAM Reports:

 Consolidated Log Report

 Invalid Super User Report
 FF Log summary Report
 Reason code & Activity Report
 SoD Conflict Report for FFIDs
10. Configuration Parameters – GRC system?

 IMG GRC Access ControlMaintain Configuration Settings

Parameter Parameter Parameter Value Description

Group ID
Workflow 1113 WF-BATCH Access Control E-mail sender
EAM 4000 1 Application type
EAM 4001 02 Default Firefighter Validity Period (Days)
EAM 4002 YES Send Email Immediately
EAM 4003 YES Retrieve Change log
EAM 4004 YES Retrieve system log
EAM 4005 YES Retrieve Audit log
EAM 4006 YES Retrieve OS command log
EAM 4007 YES Send log report execution notification
immediately
EAM 4008 YES Send Firefighter ID login notification
EAM 4009 YES Log report execution notification
EAM 4010 SAP_GRC_SPM_ FFID Firefighter ID role name
EAM 4015 YES Enabling Decentralized FF
Access Risk Analysis (ARA)
11. Why Access Risk Analysis?

 Access risk means one / more actions or permissions that are available to a single
user/ single role/ profile/ HR Object that leads to fraud or unintentional errors. To
avoid this type of miss use of authorizations SAP introduces SAP GRC ARA.
 The Access Risk Analysis tool is the backbone of SAP GRC Access Control. This
is used to detect, remove, and prevent access and authorization risks means
reporting SoD violations before they occur.

ARA performs following activities:

I. Identifying the Risk and notifying the access and authorization-related IT tasks.
II. Risk Remediation means when the risk identified we are going to remove the
access of T Codes and Authorizations if they are conflicting.
III. Risk Mitigation means when the risk identified and can’t be removed access due
to job nature or for some other reason and we are going to monitor their activities.

12. What is Risk?

 Risk means one or more T Codes or Authorization Objects are available to a single
user is called as Risk. Risk means potential threat which needs to be managed in order
to avoid potential losses to the organization.
 Example: SCC4 + SE09 or SCC4: S_TABU_DIS+ SE09: S_TRANSPORT.

13. Types of Risk?

In SAP GRC there are 3 types of risks.

1. SoD Risk (SoD Risk at Action Level and Permission Level )

2. Critical Action Risk
3. Critical Permission Risk

1. SoD Risk:

 SoD means one person having the ability to perform two or more conflicting
functions to control a whole process from beginning to end without the
involvement of others.
 When a user having access to two or more Conflicting Functions that is called as
SoD Risk.

 Example: One person might be able

  Maintain Purchase Order (ME21N, ME22N) Vs. Manage Goods
Receipt (MIGO – Goods Movement, MB01 – Post GR PO) or
 Transport Administration (TMS, STMS, SE09) Vs. Role
Administration (PFCG). Here risk is the person fraudulently create
role and move transport across the landscape.

 Even within SoD risk, risk can be of two types.

a. SoD Risk at Action level:

 Combination of two or more conflicting T Codes is called as SoD

Risk at Action level.

b. SoD Risk at Permission level:

 Combination of two or more conflicting Authorization Objects and

Authorization values is called as SoD Risk at Permission level.

Note: In order to avoid false positives we need to run risk analysis at Permission
level also.

2. Critical Action Risk:

 When a user is having the access to a Critical T Codes, which alone can damage
the SAP system it is called as Critical Action Risk.

Example:

 SPRO/SCC5/ SCC4/STMS etc……..

 In production system having change or generate access of PFCG is a
critical action risk.
 Having change access to tables under SE16 T Code.

 Some T Codes are so critical in nature, who has access needs to be identified and
assigned to ensure that access is appropriate.
 This is different from SoD risks in this the person only needs to have access to a
single function.
 3. Critical Permission Risk:

 Like a critical action, there is some Critical permission (Authorization Objects)

that is considered critical on their own.

Example:
 Having background job administration permissions might be considered
critical by certain organizations.
 S_DEVLOP (01, 02) / S_TABU_DIS or NAM (01, 02, 06-Delete) /
S_PROGRAM (01, 02, 05- Execute).

 Risk levels are 4 types:

o Low
o Medium
o High
o Critical
Note: Always Permission level report (1023) value= 02 gives accurate results.
We are not going to create Risk ID with Single Function.

14. What is Global Rule set, Business Process and Sub Process? Risk ID? Function ID?

A. Global Rule Set:

 Rule set is a combination of risks and generated rules, using which we do risk analysis of
plug in system for different types of risks. Rules generated from the Risk are called as
Rule set.
 Why Rule Set: To create Risk Ids, generate rules from risk ids and for running risk
analysis Rule set is required.
 Identifying any combination of these conflicting actions and permissions from user
profiles is more difficulty to handle manually.
 To simplify this activity Access Risk Analysis Rule Set is created by grouping of
Transactions and Functions. Conflict between two functions is called as SoD.
 There are 154 risks identified and delivered in SAP GRC system as part of the Global
Rule Set.
 T Code: SCPR20 and BC Set: GRAC_RA_RULESET_COMMON and then activate
it. This populates the Business Process, Sub-Process, Functions and Rule Set.
SPRO --- IME --- GRC --- AC --- Maintain Business Process and Sub Process.

Business Configuration Sets: Activation

BC Set GRAC_RA_RULESET_COMMON
 Short Text Rule set for Common Rules

 Rule Set is used for determining the group of access risks that are used when running an
ARA. Several Rules are combined together in a Rule set. The Rules are available as
Rule IDs in a separate table called GRAC ACT RULE (SoD Action Rule Details).

B. Business Process:

 BP includes categorization of our business functions. Ex: Finance, MM, CRM, HR.

C. Sub process:

 Even within business process we can define sub process. This sub process is used for
Mitigation control and maintenance.
 Ex: In my organization they define IT has BP and sub processes like BASIS, Security,
and DBA. Finance BP ------> AP, AR, GL, Asset Management.
 Both Functions and sub process are a sub classification of Business process. Whereas
Functions are used for defining a risk and Sub process is used for Mitigation control
and maintenance.

D. Risk ID:

 Risk IDs are combination of two or more conflicting functions. Each function is grouped
with Actions and permissions. Actions are T Codes of SAP ERP system and Permissions
are Authorization Objects.

E. Function IDs:

 Function IDs are group of Actions and permissions. Functions are a sub classification of
Business process and used for defining a risk.
 Ex: Under BASIS BP we have functions like Client & Transport Administration.

15. Rule Set types and How to create Customized Rule Set?

Rule set is a combination of risks and generated rules using which we do risk analysis
of plug in system for different types of risks.

There are two types of Rule Sets.

a) Global Rule Set (GRS)

b) Customized Rule Set
a. Global Rule Set:

 Activate BC sets below

GRAC_RA_RULESET_COMMON
GRAC_RA_RULESET_SAP_R3

Once these BC Sets are activated, it will create a Globalized Rule set delivered by SAP.

 Generate SoD rules for the uploaded Rule set:

SPRO -----------> IMG ---------> GRC ------------> AC --------> ARA --------> SoD Rules
--------------> Generate SoD Rules.
 After generation of SoD rules our Global Rule Set becomes active and can be used for
risk analysis.
 However in real time people don't use GRS. Clients preferred to use CRS.

b. Customized Rule Set:

 Creating a copy of GRS into our own name space.

 Discuss with the business teams or Control teams or Internal Audit teams relating to
"types of risks" you want to include in your customized rule set.

Activities:
 Creating a new SoD Risk.
 Creating a new Critical Action Risk or Critical Permission Risk.
 Activating or Inactivating a Risk.
 Increasing or Decreasing the Risk levels (High, Low).
 Creating risks for Customized T Codes and Authorization objects.

 Ex: According to SAP GRS having Functions - Client admin and Transport admin is a
High/Medium level SoD risk. Where as in real time companies can't afford to have
separate BASIS teams for Client admin and Transport Administration. So we will discuss
with Control/business teams to make it has Low level/ De activate.

Prerequisites: Run the Authorization synch Job and Repository Object synch Jobs.

16. Risk analysis and types of Risk Analysis?

 Risk means potential threat which needs to be managed in order to avoid potential
losses to the organization. Risk means two or more T Codes and Authorization
Objects are available to a single user is called as Risk.
  This risk can be analysis in 2 ways.
1. User Level Risk Analysis: We analysis only Roles at user level.
2. Role Level Risk Analysis: We analysis T Codes (Action).

 Risk Analysis: NWBC----- Access Management ------ ARA ------ User Level.

17. Risk life cycle or when we use RS, RR, and RM?

Risk Life cycle:

Defining Risk

↓
Risk Identification

(User & Role Level)

↓
Remove Risk (R Remediation)

↓
Reduce Risk (R Mitigation)

↓
Continues Compliance (Simulation)

18. Risk Simulation?

 Simulation or what if mode was used during Continues compliance/ support phase
whenever changes to be made we are expect to run risk analysis in Simulation mode
in GRC Development / Quality system connected to my Plug in Development system.
 Simulation or what if mode means where risk analysis is done before actual roles or
users gets created/ modified.
 Risk simulation, means Role assigned to a user or T Codes added/removed from a
role and sees the possible changes will make on the risk analysis.
 Ex: A new user needs to be created a set of roles. (or) Existing user may request for a
new role.

Risk Simulation can be done in 2 cases / RS requirements:

 User Modification (Role assigned to a user).

 Role Modification (Adding/removing T Codes + A.Os from a role).

How/ when do you use Simulation?

 If the project has only ARA and EAM components we will do risk analysis
manually.
 If we are using ARM also my risk analysis stage is configure to run risk
analysis in Simulation mode using ARM.

Types of Risk Simulation:

I. User Level Simulation:

 We simulate only Roles in user level.

 Ex: Role1+Role2= No Risk + Role3= before assigning Role3 to a user
we are doing Risk Simulation.
 Exclude values: Simulation in Removal of access.
 Risk from Simulation only: To check the new risk is coming due to
simulation only.

II. Role Level Simulation:

 We simulate only at Action level (T Codes).

 Ex: Role1 = T1+T2+T3+T4 now adding T5 to same role. This is Risk
Simulation at role level.

How does simulation get its role data?

 Repository Object synch which pulls data of Users, Roles and Profiles.
 Using Role Import we need to import all technical roles from plug in system into
BRM Repository.
19. Risk Remediation?

 Removal of risk is called as RR. RR is an activity which is run after doing risk analysis; it
aims to cleanup roles in plug in system.
 Removing the T Codes from the role which are conflicting in nature and ensuring role is
SoD free.
 It is a time consuming part, as you need to check each and every role for risk analysis.

Activities in RR:

 Remove unused roles in plug in system. (AGR_USERS, SUIM - we find unused

roles).
 Remove repetitive roles- roles having a common T Code.
 Check your role design- always assign composite role based on job function of
the user.
 Remove extra access/ roles assigned to users and try to provide this extra access
through FFIDs.

There are 3 ways to start the cleaning process:

 Removal of Role to User.

 Removal of T Codes from the role.
 Mitigate the risk using mitigation control assignment against the user and monitor
on a regular basis.

Note: The first option is selected on daily basis, whenever user has a risk at user
level. Second option is selected when there is a risk at role level or the same risk
is repeated for multiple users.

20. Risk Mitigation?

 Even though there are SoD conflicts, which cannot be removed from the role and allows
the users to access them. These T Codes might be necessary for that particular role to
execute that task and assign Mitigation Controllers to monitor user activities.
 Here t-codes will be retained in the role itself and monitor user activities using GRC
system through Mitigation Controls.
 Security team creates Mitigation Controllers in GRC system and internal control team is
responsible for assigning Mitigation Controllers to Risk IDs.
 Required attributes for RM:
 Mitigation Controllers (Owners and Monitors).
 Organizational Hierarchy.
 Risk IDs.

How to create Mitigation Control IDs:

 Create Mitigation Controllers (Owners and Monitors) with required roles using SU01 in
GRC System.
 Add Mitigation Owner and Controller in Owners table using NWBC --------> Setup ---->
Access Owners ----------> Access Control Owners.
 Create Root organization Hierarchy using SPRO --------> IMG -------> GRC --------->
Shared Master Data settings -----------> Create Root organization Hierarchy.
 Define owners for the Root Organization Hierarchy using NWBC --------> Setup ------->
Organizations ---------> Organizations.
 Assign Mitigation Control IDs to Risk IDs and others using NWBC ---------> Setup ---->
Mitigation Controls --------> Mitigation Controls.
 Once a set of Mitigation Control IDs are created during implementation phase then at
SoD Control stage my internal control teams will take care of assigning Mitigation
Control IDs to users/ requestor.

21. Online Risk Analysis and Offline Risk Analysis?

 Before run offline risk analysis must be configure Parameter 1027 “Enable Offline Risk
Analysis” to YES.
 Offline risk analysis is not real-time data, but it is dependent on the last date of the
running Batch Risk Analysis. The Batch Risk Analysis is run as background job in GRC
by using
T Code: GRAC_BATCH_RA
Program: GRAC_BATCH_RISK_ANALYSIS.
 The benefit of using offline risk analysis is it responds in time.
 The system uses Offline Risk Analysis data to update and generate UAR review
workflow requests.
 This is the same batch risk analysis that is run to update the management reports and
companies should be running this on a frequent basis to ensure their management reports
are accurate. Running the Offline analysis is the same as drilling down via the
Management View.
 Ex: Whenever we are running risk analysis, we have the option to change ignored locked
users field other than what is set up in the configuration. However, if you change this to
 NOT ignore locked users and run RA in Offline mode, you will not receive any conflicts.
Because no locked users were evaluated during the batch risk analysis. Running this
report in online mode may turn up conflicts with locked users.

22. Types of Users in ARA?

GRC System --------TCODE: SU01

Risk Owner Mitigation Controller/ Approver Mitigation Monitor

SHIVARO KRISHMITCO MITMONITOR

Dialog Dialog Dialog
SAP_GRAC_RISK_OWNER SAP_GRAC_CONTROL_OWNER SAP_GRAC_CONTROL_MONITOR
SAP_GRC_FN_BASE SAP_GRAC_CONTROL_APPROVER SAP_GRC_FN_BASE
SAP_GRC_FN_BUSINESS_USER SAP_GRC_FN_BASE SAP_GRC_FN_BUSINESS_USER
SAP_GRC_NWBC SAP_GRC_FN_BUSINESS_USER SAP_GRC_NWBC
SAP_GRC_NWBC
Net WEAVER BUSINESS CLIENT

NWBCSETUP WORK CENTER ACCESS OWNERS ACCESS CONTROL OWNERS

A. Create Button

Group Type

 Owner
 Owner Group
 LDAP Group

Owner: SHIVARO

Type Description Select

Risk Owner 

Click SAVE
Click Close

B. Create Button

Group Type

 Owner
 Owner Group
 LDAP Group

Owner: KRISHMITCO

Type Description Select

Mitigation Approvers 

Click SAVE
Click Close

C. Create Button

Group Type

 Owner
 Owner Group
 Owner: MITMONITOR

Type Description Select

Mitigation Monitors 

Click SAVE
Click Close

It’s mandatory to configure the Access Control Owners (Risk Owner, Mitigation
Controller/Approver, and Mitigation Monitor) in Organization.

 NWBCSetupOrganizations
 Organization Hierarchy  Root Org Unit Open

Owners TAB

AC Owners and Add Row

Name Type User ID

SHIVA RISK OWNER Owner SHIVARO
KRISHNA MITIGATION CONTROLLER Owner KRISHMITCO
MITIGATION MONITOR Owner MITMONITOR
Click on save button.

Mitigation Controller/Approvers:

MAs are assigned to control and they are responsible for approving changes to the control
definition and assignment when workflow is enabling.

Mitigation Monitor:

MMs are assigned to control to monitor activity and may receive control monitor alerts.

23. Risk Terminator?

The plug-in system is configured to connect with Access Risk Analysis and stop any further
processing if you have risk during one of the following four scenarios:

 When transactions are added to a role and it’s generated using T Code: PFCG.
 When users are assigned to a role using T Code: PFCG.
 When a role/profile is assigned to a user using T Code: SU01
 When a role/profile is assigned to a user using T Code: SU10.
 24. Maintaining SAP Access Control ARA Configuration Parameters and checks?

SPRO  IMG GRC Access Control Maintain Configuration Settings

Parameter Group Parameter Value Description

ID
Mitigation 1011 365 Default expiration time for M Control Assignment
Mitigation 1012 NO Consider Rule ID also for mitigation assignment
Mitigation 1013 NO Consider System for mitigation assignment
Risk Analysis 1021 No Consider organization rules for other applications
Risk Analysis 1022 T90CLNT090
Risk Analysis 1023 2 Default report type for risk analysis
Risk Analysis 1024 3 Default risk level for risk analysis
Risk Analysis 1025 Global Default rule set for risk analysis
Risk Analysis 1026 A Default user type for risk analysis
Risk Analysis 1027 YES Enable Offline Risk Analysis
Risk Analysis 1028 No Include expired users
Risk Analysis 1029 No Include locked users
Risk Analysis 1030 YES Include mitigated users
Risk Analysis 1031 YES Ignore critical roles and profiles
Risk Analysis 1032 YES Include reference user when doing user analysis
Risk Analysis 1033 YES Include role/profile mitigating controls in risk
analysis
Risk Analysis 1034 100 Maximum number of objects in a package for parallel
processing.
Risk Analysis 1035 YES
Risk Analysis 1036 NO
Risk Analysis 1037 YES
Workflow 1061 NO Mitigating Control Maintenance
Workflow 1062 NO Mitigation Assignment
Workflow 1063 NO Risk Maintenance
Workflow 1064 NO Function Maintenance
ARA Configuration checks:
  Check RFC to the concern plug in system.
 Check connector configuration checks like "Assigning Integration Scenarios to
Connectors".
 BC sets activation.
GRAC_RA_RULESET_COMMON
GRAC_RA_RULESET_SAP_R3
Once these BC Sets are activated it will create a Globalized Rule set delivered by SAP.
 People generally don't use Global Rule Set directly delivered by SAP. Instead they
modify the GRS and copy into their own names space.
 Check parameters related to ARA.
 Run synchronization jobs like Authorization Synch and Repository Object Synch.

25. Batch Risk Analysis? Why it is used?

 The risk analysis can be performed against single users or multiple users; similarly Batch
Risk Analysis also applies to single or multiple roles or profiles from SAP NWBC.
 Performing the risk analysis across the entire system for users and roles is called as
Batch Risk Analysis.
 SAP GUI GRC System

TCODE: GRAC_BATCH_RA

Job Name: RISK ANALYSIS BATCH MODE_25MAY

System: T90CLNT090

Batch Processing Mode: Full

Rule set: GLOBAL

Object Selection:

 User Analysis

User: *

User Group: *

 Role Analysis

Role: *

 Technical Role
  Profile Analysis

Profile: *

Risk Analysis Type

 Action Level
 Permission / Critical Action / Critical Permission Level
 Critical Role / Profile Level

Click Execute Button

You will get result, your background job scheduled successfully.

Now, you can monitor the background JOB with TCODE: GRACRABATCH_MONITOR

After completion of this background job, you should be able to view various reports from Access
Risk Analysis reporting dashboard.

26. Risk Analysis Reports?

NWBC ------------> Reports and Analytics ----------> ARA Reports

 Access Rule Summary

 Access Rule Detail
 Mitigation Control Report
 Mitigation Object Report
 User Risk Violation Report
 Role Risk Violation Report
 Profile Risk Violation Report
 Access Request Management (ARM)
VIRSA 4.0 ----------- Access Enforcer

GRC AC 5.3 --------- Compliant User Provisioning (CUP)

GRC AC 10.1 ------- Access Request Management (ARM)

Compliant: Following or obeying the rules and regulations (SOX Law).

Purpose of using ARM:

 Automate Approvals through Workflow.

 Auto provisioning – Automate User Maintenance.

Advantages of Automation:

 No time delays in user maintenance.

 Reduction of errors.
 Enforce that process can be followed.

User Administration:

 User Creation
 User Modification
 User Deletion.

Process to be followed for User Administration:

 User has to fill the SAP Access form.

 It has to be approved by his Reporting Manager.
 It has to be approved by Role Owner (for the roles user is requesting).
 Security team will create or modify or delete the user as per request.

How can you ensure that above process is not violated?

27. Why Access Request Management?

 ARM is used for automated user administration process and other things.
 Access Request Management (ARM) is the provisioning tool that will provide the
company with the ability to manage SAP user access management and Role assignment
within connected system.
  Provisioning access to users involves the user completing the forms that request access to
backend system.
 Access request is created in GRC by requestors and submitted for approval. The
requestor would be responsible for selecting required by the user. Once submitted the
request is routed online by workflow to relevant approvers.
 User Access Management automates the access provisioning approval process and
provisioning appropriate roles and permissions via workflow to the respective requested
plug-in systems.
 When a user (requestor) requests resources (roles or access privileges) for which the user
doesn’t have permissions using User Access Management.
It automatically forwards the access request to designated managers and approvers via
workflow.
At the end of approval process, roles and permissions are automatically applied to the
respective systems with requested privileges when the access requests are approved.
During this process User Access Management checks for Segregation of Duties (SoD)
and Critical Access Analysis for the user by combining the user’s existing privileges with
those requested using the integrated Access Risk Analysis tool.

In our project 4 stages are there:

Whenever a Requestor submit a request (New or Change request), the request goes through 4
different stages for approvals.
a. Manager
b. Role Owner
c. Risk Analysis Stage (Detour Path)
d. Security Stage

Detour Path - Explain?

 Whenever a request at Risk analysis stage is found with risk the request now its take a
Detour path to internal controls team to assign Mitigation Controllers.
 At user level we assign Mitigation Controllers.

Notes:

 We have made configuration for ARM request if one role is rejected at any level whole
request it gets rejected.
 User needs to submit the request again.

Escalation Path:
  Whenever approver fails to approve especially role owner after 5 days, the request will
get alternative approver (every BR will have 2 approvals i.e. Primary & Alternative).
 Security team making sure that roles are provisioning to user correctly to check the logs
SLG1 in GRC System.
 We have a problem for removal of groups in portal in remove request. In that case we
need to check SLG1 logs for errors.
 Sometimes whenever Manager is on Out Of Office (OOO), security team is asked to
forward the request to "Managers Manager" . (Go to search request -----> Enter the
request no. -------> Click on Administrator --------> Click on Action type Forward and to
give Managers Manager USER ID).
 To find the status of request at which stage it is pending ---------> Go to search request
------------> Click on Incident status.
 If somebody raises a wrong request, will cancel the request at Cancel Incident.
 For JAVA systems providing FF access we will manually assign FF Role to users
(Technical Team) based on Incident.
 We are not using FFID concept directly in JAVA systems.

28. Different User Roles in User Access Management?

The available roles for user access management are:

1. General Users
2. Requestors
3. Approvers
4. Administrators
5. Auditors

1. General Users:

 For some customers the situation demands some or all of the new users not to
have any other authorization, but still they need to create their user requests to
have proper IT access to perform their duties.
 This can be performed by the user if the user can access a generic URL.

 SAP_GRC_FN_BASE
SAP_GRC_FN_BUSINESS_USER

 These are basic roles, required to log on to the SAP Access Control system to
create a new request or change a request.
 2. Requestors:

 Sometimes this role is confused with general users. The simple variations is
that a requestor is the person who creates a request on behalf of others,
whereas a general user is the terminology used to represent the person whose
user ID is in the access request.
 Requestors should have privileges to access the SAP GRC system, and the
roles are the same as mentioned previously for general users.

3. Approvers:

 In SAP Access Control there are different types of users in the system, such as
firefighter ID, firefighter users, owners, controllers, and so on.
 Various Approvers in the SAP Access Control System are role content owners, role
assignment owners, function approvers, control owners, mitigation owners, and
various access approvers that will be maintained in various stages in the MSMP
workflow.

4. Administrators:

 SAP GRC System administrators are privileged to configure, maintain master data or
change master data, and troubleshoot some issues in the system.
 This type of user has all of the privileges of the SAP Access Control system. While
providing wide access to the system, make sure that all changes carried out by anyone
who has privilege to change master data in SAP Access Control are captured in the
change log of the system to monitor and audit them later.

5. Auditors:

 Auditors are those who verify whether IT or system access are provided correctly, and
they are in place to meet the governance and compliance enforced in the company to
avoid any access risks.
 These users will get only the reporting authorization to execute various reports in the
SAP Access Control System.

29. Configuration Parameters in GRC ARM?

 You only need to configure User Access Management related configuration parameter groups
such as Workflow, LDAP, Role selection, and Role mapping.

Param Group Param Parameter Description

ID …
Risk Analysis – Access Request 1071 NO Enable risk analysis on for submission
Risk Analysis – Access Request 1072 NO Mitigation of critical risk required before approving
the request
Access Request Role Selection 2031 YES Allow all roles for approver
Access Request Role Selection 2032 A Approver role restriction attribute
Access Request Role Selection 2033 YES Allow all roles for requestor
Access Request Role Selection 2034 A Requestor role restriction attribute
Access Request Role Selection 2035 YES Allow role comments
Access Request Role Selection 2036 No Role comments mandatory
Access Request Role Selection 2037 YES Display expired roles for existing roles
Access Request Role Selection 2038 YES Auto approve roles without approvers
Access Request Default Roles 2009 NO Consider default roles
Access Request Default Roles 2011 REQUST Default Role Level
Access Request Role Mapping 2014 NO Enable Role Mapping
Access Request Role Mapping 2015 NO Applicable to Role Removal

30. Configure the MSMP Workflow?

  The Multi-stage Multi-path (MSMP) workflow is the key engine that moves the request
from one stage to the next stage within the ABAP workflow engine.
 SPROGRC  Access Control  Workflow for Access Control  Maintain
MSMP workflows.
 Alternatively, you can execute T Code: GRFNMW_CONFIGURE_WD to open the
MSMP application setup in a browser window.

MSMP Steps:

1. Process Global Settings

2. Maintain Rules
3. Maintain Agents
4. Variables & Templates
5. Maintain Paths

1. Process Global Settings:

 Select SAP_GRAC_ACCESS_REQUEST.
 Click on Display/Change button.
 Click Add or Modify button from the Notification Settings area.
 This global setting is required for the first two workflow processes only, and the
rest may not require this Notification Settings because they send notification to
pass information to the user or requestor about access request upon submission of
the request, at the start of the workflow, and completion of request at the end of
workflow.

Notification Event Template ID Recipient ID

END_OF_REQUEST GRAC_AR_CLOSE GRAC_USER
REQUEST_SUBMISSION GRAC_AR_SUBMIT GRAC_REQUESTER

2. Maintain Rules:

 These are the default rules for different rule types such as agent rules, initiator rules,
notification rules, and so on.
 You need to maintain the global rules for the initiator and for notification; you can have
one initiator per process.

// accept default settings here…

Process Initiator: GRAC_AR_INITIATOR

Notification Rule: GRAC_NOTIF_VAR_RULE_AR

 3. Maintain Agents:

 It’s a more generic setting, and those who are approvers are actually defined in
every stage and maintained in step 5 – Maintain Paths.

4. Variables & Templates:

 It is used in notifications to various uses of User Access Management.

 The two steps – Maintain Agents (step 3) and Variables & Templates (step 4) –
can be used with default SAP – provided values.

5. Maintain Paths:

 For the MSMP workflow configuration, you maintain the workflow path and
define various stages.

Path ID Path description

DELETE_PATH DELETE PATH
DETOUR_PATH DETOUR PATH
GRAC_DEFAULT_PATH Default Path
NEW_USER_PATH New User Path

 Approvers or agents are assigned to these stages with the functions or tasks that
need to be performed at every stage. You also define here what type of
notification is sent to whom.

MSMP
TCODE: GRFNMW_CONFIGURE_WD (or)

T Code: SPROGRC  Access Control  Workflows for Access ControlMaintain MSMP

Workflows.

 MSMP is the new workflow engine used within SAP Access Controls 10.0 and is capable
of directing requests down multiple approver routes simultaneously.
 It’s used for the management of automated approval workflows in User Access
Management but can also be triggered for the other SAP Access Control modules,
including Access Risk Analysis master data updates or role building approval workflows.
 The big change is that it works off of a multitude of different rules to govern what should
happen to the requests. All of these rules to be defined up front before they can be
assigned in the configuration and used in the workflow processes.
 Based on the GRC_MSMP_CONFIGURATION BC Set activation, there are eight
different processes and process ID’s such as Access Requests, Function or Risk
Maintenance, User Access Review, SoD review and Firefighter Log Review and so on.
Components of all these processes are populated with MSMP related core values in these
various steps to carry out configuration.

i. Configure Process Global Setting

ii. Maintain Rules and Rule Results
iii. Maintain Agents
iv. Variables and Templates
v. Maintain Paths and Assign Stages to Path
vi. Maintain Route Mapping.
vii. Generate version.
 i. Configure Process and Global Setting:

 Upon invoking MSMP workflow, MSMP workflow initial screen shows seven steps with
the first process SAP_GRAC_ACCESS_REQUEST highlighted.
 Process ID’s are pre-delivered as part of the MSMP BC Set
GRC_MSMP_CONFIGURATION activation.
 These processes basically cover a specific scenario and the process description for each
process ID is self-explanatory for scenarios.

You can start editing the entire MSMP process by clicking the Display/Change button.

PROCESS GLOBAL SETTINGS there are two variables for you to set.

 This setting applies to each and every stage/path uniformly.

 In this stage we don't have to check Enable Escalation.
 Escalation in terms of Days.
 If an approver fails to approve an request, Escalation happens in two ways.

a. Escalation Notification sent to the Approver.

b. Escalated to the Alternative Approver.
 1. Enable Escalation:

 It enables global escalation on any workflow that was pending for

approval and the deadline monitoring for the fixed date. After this
date all work items escalate for this process.

2. Escalation Date:

 This is the date on which all work items for this process are
escalated.

NOTIFICATION SETTINGS the variables you should set are:

1. Notification Event:

 It means you are configuring a predefine Notification/Mail that

will trigger based on an event.
 In this case every Process ID needs to be configure with a
Notification Event.
 Notification Event is beginning of event with
REQUEST_SUBMITION and ending of event with
END_OF_REQUEST. (SAP Standard Notifications).

2. Template ID:

 The template is maintained for the message that has to be sent

either at REQUEST_SUBMITION or at the
END_OF_REQUEST processing notifying the requestor or user
of the outcome as message what is the request number that had
been created with details or approval information after the end of
the workflow process.

3. Recipient ID:

 This is the recipient of the end of request notification message

(configured as an agent) which can be user or requestor.
 Self + Request = User
 Other + Request # User.
ESCAPE CONDITIONS the variables you should set are:

1. Escape Conditions:

 This table has two entries, one each for two escape conditions:
a. Approver Not Found
b. Auto Provisioning Failure.

2. Set Escape Routing:

 This checkbox need to be set to activate the respective escape

paths.

3. Escape Path:

 Path the request follows if no agents are found for any stage or
failure during auto-provisioning. This is set in Step 5 and is
required when Escape Routing is enabled.
 To maintain the escape path, it should be created in Step 5 to set
the stage for the above mentioned escape path to which the request
should follow.

4. Escape Stage:

 This escape stage number dictates at which approval stage this

escape routing should be triggered in case of if any escape
condition arises.
 2. Maintain Rules and Rule Results:

 The purpose of Rules and Rule Results is to identify agents in the workflow and
condition based determination of different workflow paths.
 Rules are decisions that are associated with rule results.
 MSMP Workflow engine makes use of rules and their rule results to take decisions like....
a. In case of New Request, the request has to take which path.
b. Within a stage who should be the Approver.
 Four different rule types are available to maintain in the system:
 1. ABAP Class Based Rule

2. BRF Plus Rule

3. BRF Plus Flat Rule (Line item by Line item)

4. Function Module Based Rule

 These rules are used to find the correct Path, Agents or Routing to a different path based
on logic designed in the rules.

Example: If the user request to a role in System A, then workflow should go to

Path_1; if the system is different, then workflow should route to Path_2.

 Under RULE ID MAINTENANCE table a list of rules is provided by default, which

can be modified or new rules can be added as needed.

1. Rule ID:

 The unique name for the rule to identify different rule types and
rule kinds that are used in the MSMP workflow process.

2. Rule Description:

 Meaningful description to the purpose of the rule.

3. Rule Type:

 There are four rule types based on the underlying technology that
helps to make decisions.

4. Rule Kind:

 Four different rule kinds are used during the execution of the
MSMP workflow process to determine results for initiator, agents,
routing, and notification variables.

A. Agent Rule
B. Initiator Rule
C. Routing Rule
D. Notification Variable Rule
A. AGENT RULE:

 Agents are approvers that need to approve a request at a particular stage in

order to make the request proceed to next stage.
Ex: Manager, Security, Role Owner.
 You can create multiple rule IDs for the agents rule kind based on your
definition of multiple agents such as Role Owner, Risk Owner or any
other custom agent.

B. INITIATOR RULE:

 This rule is used to direct the workflow path based on the rule, result
which is defined by the rule type.
 This rule determines the path which a request needs to take when a request
is successfully submitted.

Ex: a. Request Type (New User) it should take Path 1.

b. Request Type (Delete User) it should take Path 2.

 Only one initiator rule per process can be defined.

 In SAP Access Control 10.x, rather than specifying an initiator for each
workflow path, you now only have one that contains all of the different
possible variations that can be achieved by rule result values.
 SAP provides one Standard Initiator Rule/ Default Initiator Rule. i.e. .........
GRAC_AR_INITIATOR with only one default rule result. This is
FMBR.
 We need to do customization i.e. Create Initiator Rule by using BRF Plus
Flat Rules.
Ex 1: Using BRF Plus Flat Rule we can define any of the Rule kind.
Ex 2: Using ABAP Based Rule we can create any of the Rule Kind.

C. ROUTING RULE:

 You can use this rule to route a request from one path to another based on
the rule result.
 These rule determines route which a request should take if a condition it
meet.
Ex: When the request faces SoD Violation the request should be routed to
another path (Detour) to controls team to assign Mitigation Controls to
User IDs.
  Most of the times we make use of SAP Standard FMBR Routing rules in
our MSMP Workflow.

D. NOTIFICATION VARIABLES RULE:

 This is also defined once per process in global settings. This rule helps to
send notifications to various agents.

Rule Results:

 The rule result value can be a single or multiple results, which is used in
workflow paths or stages to determine either agents or paths depending on the
rule kind.

Trigger Value Description:

 Rule results require meaningful description, which you maintain here.

Process Initiator:

 There can be only one active initiator per process. This initiator needs to cover all
paths defined for the process that are to participate in the process.

Notification Rule:

 Rule to determine notification variables used in notification templates.

I. BRF PLUS RULE:

 Rule defined in the BRF+ application to get rule results depending on conditions
inside the rule

ii. FUNCTION MODULE BASED RULE:

 Function module coded to output the rule results.

III. ABAP CLASS BASED RULE:

 Class method coded to output rule results.

IV. BRF PLUS FLAT RULE (LINE-ITEM BY LINE-ITEM):

 BRF+ rule defined for only one line item. (This rule is called once for each line
item in the request).

3. Maintain Agents
 After configuring rules and rule results, we have to define various agents like
Access Request Approvers, Role Owners and Notification agents (requestors and
end users involved in workflow process).

a. Agent ID: Define the logical approver ID, which is a required field.
b. Agent Name: Give a description of the logical approver ID.
c. Agent Purpose: Agents are defined in the MSMP workflow for either approval purposes
or to notify about the activities.

Approval: This agent will get work item from workflow for approval purpose.

Notification: Agents in the system for notification purpose to convey the information about the
workflow.

Agent Type: -Define dynamic approvers that can be assigned to any workflow stage.

 Directly Mapped Users:

This configuration is used for defining static user groups used within workflow process.

 PFCG Roles:
PFCG roles assigned to a user as agent and workflow determines the agent based on the
role assignment.

 PFCG User Groups:

PFCG groups assigned to a user; for example this can be specific process owners that are
define in a user group.

 GRC API Rules7:

This is used to fetch rule-based approvers such as manager, role owners, risk owners, and
so on via associated function modules. This field is mandatory if AGENT TYPE is defined
as FUNCTION MODULE BASED RULE in an earlier step.
 For ex: - manager approval stage with GRAC_MSMP_MANAGER_AGENT

4. Variables and Templates

 These templates are used to send email messages to the approvers/notification
receivers that contain some fixed texts and variables, such as user ID, user name,
request type, role or provisioning details, system name, to give the message to the
receiver of this workflow content for decision making on approval or rejection.
 All of this customization can be done to these templates and variables using
TCODE: SE61
 Notification Templates
 Template ID
 Message Class
 Message Number
 Notification Variables
 Temp. Variable
 Variable Description

5. Maintain Paths and Assign Stages to Path

 Every workflow path contains one or more intermediate nodes for the decision making
process called stages in the SAP Access Control Workflow.
 You can create stage less workflow also. At every stage you need to define various
parameters that are important for decision making and workflow processes.
 Dynamic conditions such as SoD violations identified in making the request or type of
request, changing the stage owner, or adding a role might require switching the entire
workflow path to a different one. For this reason you need to maintain multiple workflow
paths within the process. At the approval stage level, if there is any SoD risk violation,
you need to define whether any routing is required. These details will be maintained in
next step, MAINTAIN ROUTE MAPPING, with approval stage information and paths
where it is routing from and to.
 Business Role Management (BRM)

31. Why / Purpose of using BRM?

 Role methodology for creating roles from GRC System.

 Role repository for ARM request.

Note: Whenever a user requests a role from ARM he needs to select a Business Role.

32. Business Role - explain in detail?

Business Role is like a shell role / Composite role created in GRC system containing individual
technical roles from different plug-in systems.

Example: Security Admin / BASIS Admin Business Role.

Once a request is approval the user is getting created in all the plug-in systems in one go.

 BASIS Admin Business Role contains Technical roles like...........

 YECC Composite Role
 YBI Single Role
 YHR Derived Role
 YPR Portal Group
 You have to create Business Role in GRC System and add Technical Roles. (Added to
GRC System by Role Import from backend system)
 Set the status of Business Role to provisioning status has Complete, Primary and
Alternative approvers and Provisioning status has Production.

 Go to Role Maintenance ----------> Click on Create BR. There are 3 stages. i.e.
1. Define Role
2. Provisioning
3. Complete
Note: Every role must be moved to complete status, otherwise it will not visible in
requestors ARM request.
33. User searches for Business Role in GRC system but however he is unable to find out-
Explain the reason?

 Check the provisioning status has Production / not.

 Check the role status has complete / not. (After you have done Technical roles imported
from plug-in system and added to the Business Role created in GRC system).
34. How to add or remove Role Owners in BRM?

 They need to be assigned with Approval role name in GRC system.

 Approver’s need to add has assignment approver. (Role content approver is for role
methodology)
 Every Business Role needs to have a Primary and Alternative Approvals.
 We don't give Owners to Technical Roles.

35. Role Import explains?

 Role Import can be done for a Single Role or Mass by using TEXT Templates.
 In Risk Analysis we run Repository Object Synch and in BRM we need to bring roles
into GRC System using Role Import.

NWBC ------- Access management ------- Role Mass Maintenance ------- Role Import.
Mandatory Fields:

 Role Methodology Status: Complete.

 Role Status: Production.
 If it is Business Role, then Approvers.

NOTE:

If importing multiple Technical Roles from File on Desktop:

Go to Templates ------ Click here to download attribute file template.