De-centralized EAM GRC 10.0

inShare2

Source:   http://scn.sap.com/community/grc/blog/2014/01/16/de-centralized-eam-grc-100

For Centralized EAM Configuration :
    http://atozgrc.blogspot.in/2013/10/configuration-of-emergency-access.html

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

https://ideas.sap.com/ct/ct_a_view_idea.bix?c=4F27C74D-5330-4569-8199-D69072C0D4AE&idea_id=5C643027-DCA7-4CB1-871E-BFFAF3A072B3

Finally SAP has enabled De-centralized firefighting feature in GRC 10.0 from GRC SP10. 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.

Also system had 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

Creating Connector:
Create new connector using SM59 Tcode or going through below mentioned path.

Create ABAP connector with the options as shown below.


Under Logon & Security maintain the details as shown below. User RFC_USER is a system user and is available in ECD system with S_RFC access.

Once you have maintained all these values. Save the connector and then click on Connection Test. If it is successful, you will get below screen.


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. Source connector is not required.

Now our connector needs to be 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 else, when you activate BC sets for SOD rules automatically connector groups gets created in the system which were used in the SOD rules. Then you can assign your connector to the connector group as shown below. Change the setting “Max No. of BG...“parameters to “3“ (i.e. this connector will use a maximum of 3 background jobs for synch jobs)

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 and enabling PSS.

Maintain Mapping for actions and Connector Groups
For POC purpose we are connecting GRC 10 system to ECC 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

1. 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.
2. 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.
3. FF Owner, FF Controller, Reason Codes are created and maintained in GRC system.

       NWBC -> Setup -> SuperUser Assignment and NWBC -> Setup -> SuperUser Maintenance
   4.    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.
   5.    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

Authorization Synch
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

Step 5: Assigning FF Ids to Users
Unable to find FF Id’s in NWBC.

1. Please check whether configuration parameters are maintained as mentioned in step 3.
2. Please check whether all synchronization jobs are executed as mentioned in step 2.
3. Please check whether the user who is searching for FF ID’s in NWBC has required access.
4. 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.

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

1. FF user has been assigned with the FF Id.
2. 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.
3. 
4. We already has RFC connector SECCLNT100 created in GRC system to connect from GRC to SEC and vice-versa. This error was resolved after creating RFC connection locally by the same name SECCLNT100 as system is expecting a local RFC connection with the same name.
5. 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:

1. In the GRC Box, maintain configuration parameters as mentioned above in Step 4.
2. Make sure that 'EAM master sync job' is complete.
3. Into the Plug-in system, maintain configuration parameters as mentioned above in Step 4.
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.
5. 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.
6. 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.

1. Make sure that the configuration parameter 4002 is maintained into the GRC BOX.
   1. 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.
   2. 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'.
2. Controller of the FFID is configured with the valid Email Id.
3. In the NWBC -> Access Management -> Controller -> make sure that 'Notification By' column is selected to 'Email'.
4. Make sure that 'EAM master sync job' is complete.
5. There is no setting which is required to be maintained into Plug-in system in this case.

Log Notification sent from GRC system