SAP GRC Access Control 10.0/10.1/12.0 – De-Centralized EAM
Purpose of the Document
In GRC 10.0 SAP has introduced the Centralized Emergency Access Management process unlike its older version GRC 5.3 which got mixed reviews from GRC users.
Initially a user has submitted his idea in SAP IDEA PLACE asking SAP to provide De-centralized EAM functionality in GRC 10.0 in the same way they have been using in GRC 5.3 and this has been supported by lot of GRC consultants.
Finally SAP has provided De-centralized firefighting feature in GRC 10.0 from support pack 10. Depending on the client’s needs, the option “log on centrally” (current version 10 behavior) or “log on locally” (5.3 behavior) can be configured in GRC 10 and GRC 10.1
Also system has the ability where both centralized and De-centralized approach can be configured but user can either login centrally or locally as there can be only one firefighter session at a time.
De-centralized EAM configuration – SP13 – ID based Firefighting
Step 1: Creating Connector and Assigning Integration Scenarios
Create new connector using SM59 Tcode or going through below mentioned path.
SPRO -> IMG -> GRC -> Common Component Settings -> Integration Framework -> Create Connectors
Under Logon & Security maintain the details as shown below. User “GRCSYSADM” is a system user which is available in S4HANA system with required authorizations.
Once you have finished the above steps, Save the connector perform Connection Test and Authorization Test. When the connection is successful, you will see the following message:
Maintain Connectors and Connection Types
Now click on Maintain connectors and Connection Types going to below path as this is required for assigning the connection type to our connector which is created in the above step.
You will get the below screen where you can see different types of connection types available in the GRC system.
Maintain the entries for your connector as mentioned below:
Connector needs to be further assigned connector group. This is similar to logical system in GRC 5.3 where we group similar systems under one logical system. You can create your own connector group or use the connector groups created in the system as part of BC sets activation. Then you can assign your connector to the connector group as shown below.
Once you have these connector groups, then assign the connector group to group type as shown below.
Next step is to assign connectors to connector group as shown below.
Maintain Connection Settings
Connectors must be assigned to the all integration scenarios (AM, ROLMG, SUPMG, AUTH, PROV) available as it is a good practice according to SAP (under Common Component Settings -> Integration Framework -> Maintain Connector Settings). In the same way mentioned below repeat for ROLMG, SUPMG and PROV scenarios.
Maintain Connector Settings
Now go to below mentioned path for maintaining connectors with application types .
Maintain Mapping for actions and Connector Groups
For POC purpose we are connecting GRC 10 system to S4HANA system and hence only one Connector group is there in active status. From the same screen we can define default connector to be used for different actions as shown below.
For example if you are creating LDAP connector then the mapping between AC and LDAP fields are maintained in assign group field mapping. Once all the above mentioned steps are performed, then the next step would be to schedule the synchronization jobs in the order advised by SAP.
Step 2: Creating FF Users, FF Owners, FF Controllers in GRC 10
FF Users executes Tcode /n/GRCPI/GRIA_EAM from Plug-in system and login with firefighter Id’s assigned to them. So users no need to exist in GRC system any more.
Following role must be assigned to the Firefighter user.
SAP_GRAC_SUPER_USER_MGMT_USER for the centralization as well as Decentralization.
FF Id’s will be created in plug-in system and assign the role SAP_GRAC_SPM_FFID or its “Y” or “Z” equivalent to make it recognizable as FF Id.
- FF Owner, FF Controller, Reason Codes are created and maintained in GRC system.
NWBC -> Setup -> SuperUser Assignment and NWBC -> Setup -> SuperUser Maintenance
- FF Controller should also exist in the plug-in system with valid Email ID as FF login notifications will be sent to controller’s Mail Id maintained in plug-in system.
- FF log notifications are sent to FF controller’s mailed maintained in GRC system. Hence FF controller should exist in both GRC and Plug-in systems.
Step 3: Synchronization Jobs in GRC 10
In GRC 10 synchronization jobs can be run from SPRO->IMG, navigating to Governance, Risk & Compliance>Access Control>Synchronization Jobs
Synchronizes PFCG Authorization data
Repository Object Synch
Synchronizes Profiles, Roles, and Users master data
Action Usage Synch
Synchronizes action usage data
Role Usage Synch
Synchronize role usage data
Firefighter Log Synch
Synchronizes the firefighter logs from plug-in system to GRC system
Firefighter Workflow Synch
Initiates FF log report review workflow based up on your workflow settings which sends the FF log report to FF controller for review.
EAM Master Data Synch
This is the new job introduced as part of De-centralized firefighting. Synchronizes the EAM data from GRC box to Plug-in system. Once you have created all required users execute this job to synchronize the data from GRC to plug-in system.
These reports can also be maintained as scheduled background jobs.
Step 4: Configuration Parameters
SAP has introduced a new configuration parameter 4015 which has to be maintained as “YES” in order to enable De-Centralized firefighting as shown below.
Configuration Parameters – GRC system
Configuration Parameters – Plug-in system
In GRC System:
Step 5: Assigning FF Ids to Users
Unable to find FF Id’s in NWBC.
Please check whether configuration parameters are maintained as mentioned in step 3.
Please check whether all synchronization jobs are executed as mentioned in step 2.
Please check whether the user who is searching for FF ID’s in NWBC has required access.
Please check the below mentioned configuration also.
Assign Owner, and Controller:
Without assigning an owner and a controller, you might not be able to assign the FF ID to a Firefighter. From NWBC –> Setup –> Super User Assignment, assign Owner, and NWBC –> Setup –> Super user Maintenance, assign Controller.
Now you can assign the Firefighter Id to Firefighters either directly or through GRC access request.
In plug-in system you will find all the FF roles required for user, controller etc. You need to create Y or Z copy of them and should assign them to the users.
Step 6: FF ID is assigned to the FF User
FF user has been assigned with the FF Id.
Now FF Users executes the Tcode /n/GRCPI/GRIA_EAM in plug-in system and can see the FF Id assigned to his User ID. When FF users tries to login with the FF Id assigned user will get the below error.
We already have RFC connector S4HANA created in GRC system to connect from GRC to S4HANA and vice-versa. This error was resolved after creating RFC connection locally by the same name S4HANA as system is expecting a local RFC connection with the same name.
Once this issue is fixed, users are able to login as Firefighters from plug-in systems and complete their tasks.
Step 7: Fire fighter Login and Log notifications
Configurations required for the Login Notification:
- In the GRC Box, maintain configuration parameters as mentioned above in Step 4.
- Make sure that ‘EAM master sync job’ is complete.
- Into the Plug-in system, maintain configuration parameters as mentioned above in Step 4.
- In the Plug-in system, FFID controller must exist with a valid email Id, as email notification is sent from the Plug-in system.
- Login notification mail will be sent from Firefighter User SU01 Mail Id itself in de-centralized model. Make sure that email Id of the firefighter User is also maintained properly.
- FF User time zone and system time zone should be the same in plug-in system.
Login Notification sent from Plug-in system:
Configurations required for the Log report Notification
Unlike Login notification, Log Report notification is sent from the GRC Box. Almost, all of the steps are same as in case of centralization.
- Make sure that the configuration parameter 4002 is maintained into the GRC BOX.
- If the 4007 is set to ‘Yes’ then schedule only job ‘GRAC_SPM_LOG_SYNC_UPDATE’. This job will send the Log Report notification as well.
- If the 4007 is set to ‘NO’ then schedule job GRAC_SPM_LOG_SYNC_UPDATE for synchronization. It will not send the Log Report Notification. For the Log Report, another job is required to be scheduled which is ‘GRAC_SPM_WORKFLOW_SYNC’.
- Controller of the FFID is configured with the valid Email Id.
- In the NWBC -> Access Management -> Controller -> make sure that ‘Notification By’ column is selected to ‘Email’.
- Make sure that ‘EAM master sync job’ is complete.
- There is no setting which is required to be maintained into Plug-in system in this case.
Log Notification sent from GRC system
Firefighter Login Issues – Plug-in system
Login as firefighter using Tcode – /n/GRCPI/GRIA_EAM
User will enter the reason code and activity details and click OK.
User will be presented with a login screen.
User should be assigned to the below roles and make sure user also has access to S_USER_GRP object with Activity 03,05
EAM for Webdynpro and Web based applications
Firefighter functionality is primarily designed for use with ABAP systems. Lot of us had a requirement to implement EAM for webdynpro or web based applications, but there are lot of limitations for using EAM for webdynpro and web based applications.
To understand about EAM functionality with Webdynpro applications, please check out the below blog post.
Wrong Firefighter ID Status – De-centralized EAM:
When firefighter tries to logon to the system via transaction /n/GRAC_SPM, error comes:
“<Firefighter ID> is logged on using <some other firefighter id> firefighter id.”
Please check below SAP notes to resolve the issue.
1895204 – Error message: <Firefighter ID> is logged on using <some other firefighter id> firefighter ID
1702370 – Wrong Firefighter Id Status
Thanks for reading.
Looking forward for your inputs in improving this blog with additional details or scenarios ?
Madhu Babu Sai