Purpose

The purpose of this document is to provide a list of the top 10 most viewed SAP KBA's for GRC Access Control in the month of October 2014.

Overview

Below are the top 10 most viewed SAP KBA's for GRC Access Control

Please note, in order to view the contents of the Knowledgebase Articles (KBA), you will need to be logged into Service Marketplace.

Purpose

The purpose of this document is to provide a list of the top 10 most viewed SAP KBA's for GRC Process Control in the month of October 2014.

Overview

Below are the top 10 most viewed SAP KBA's for GRC Process Control

Please note, in order to view the contents of the Knowledgebase Articles (KBA), you will need to be logged into Service Marketplace

Purpose

The purpose of this document is to provide a list of the top 10 most viewed SAP KBAs for GRC Access Control in the month of November 2014.

Overview

Below are the top 10 most viewed SAP KBAs for GRC Access Control

Please note, in order to view the contents of the Knowledgebase Articles (KBA), you will need to be logged into Service Marketplace.

Purpose

The purpose of this document is to provide a list of the top 10 most viewed SAP KBAs for GRC Process Control in the month of November 2014.

Overview

Below are the top 10 most viewed SAP KBAs for GRC Process Control.

Please note, in order to view the contents of the Knowledgebase Articles (KBA), you will need to be logged into Service Marketplace.

The aim of this document is to focus on the system controls for password self service to enable you to consider how best to design and configure SAP GRC Password Self Service in your environment. This topic was raised as part of feedback in the document Password Self Service & End User Logon Configuration - AC10 by Leo and requested as part of the GRC Collaboration Project. If you are interested in specific configuration steps, please refer to Leo’s document or search SCN space for your requirements.

The scope of the document is SAP standard configuration specific to the SAP GRC component. If anyone would like to add suggestions on how to add additional security layers (tokens, SSO, etc) please add your comments in the section below for discussion.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A PSS tool needs to go through the basic process which includes verifying the identity of the user before the password can be issued. A critical design requirement for PSS is the ability to prevent an intruder masquerading as a valid user to obtain access to their account.  Within GRC, there is more than way one to achieve this.

The above diagram is a conceptual view of the complete steps if all Password Self Service configuration steps are activated. Below is a summary on the intention of each step and impact if they are not used.

Network Perimeter

This is not so much a step in GRC configuration but recognises that network security will determine if the HTTP service for End User Login is Internet Facing. Assuming GRC system access is only accessible via internal network access, you have limited potential intruders to those who have network access. It has been included to recognise network perimeter security has a part in the GRC solution but will not be discussed in this document.

End User Logon

The GRC End User Logon functionality utilises a SAP Service Account to authenticate access for the HTTP service. This means, a SU01 Service Username and password is stored against the SICF web services and the end users do not require a SAP GRC account. The positive of this functionality is that end users do not need to be set up in SAP GRC component (simplify maintenance as well as license cost).

GRC makes use of Data Sources for User Authentication, Search and Details for end user functionality. Data Sources are configured via the GRC IMG (transaction SPRO) based on the use of connectors defined in the Integration Framework. Synchronisation jobs are then executed to import the user details. The End User Log-in page can be configured to force authentication against a specific data source. This means, when the user accesses End User Logon functionality, they will required to enter their password for a system defined in the authentication configuration (such as Active Directory or SAP ERP/ECC) and a real-time call is performed to authenticate the user. It is possible to use SAP GRC as an authentication system as well – although this would defeat the purposes in End Users not requiring a SAP GRC account.

Screen Shot: Impacts for configuration setting for Data Sources Verification

Challenge

Challenge Response provides another way for a user to prove their identity through providing answers to pre-configured questions. The system issues a challenge (secret question) to which the user must respond (provide their answer). These questions and answers are stored in GRC tables with the answers in hashed form.

Challenge Response requires a registration step in which the use must provide this information. System configuration can provide template/global questions and the user can also create their own.

Screen Shots: Impacts for configuration setting for Challenge Response in PSS Global Settings

Reset Password

Once a user has proven their identity (End User Logon or Challenge Response) they can now select the system they require a password reset for. Users will only see the systems for which PSS has been enabled (IMG configuration controls this) and the user has access to. In this document, the example of SAP ECC has bee chosen. Therefore, a BAPI is called via RFC connection to reset the user password.

Emailing User

SAP GRC component will generate an email and send the login details to the user. System configuration can control if the password is specified in the email or if a URL is embedded instead. The URL example has been shown in this diagram.

URL Link and Password Change

The GRC configuration allows you to choose send a password URL link or the actual password. This is set within the configuration for User Provisioning. As part of sending URL link only, you will need to specify how long the link is valid for before it expires. If Yes is chosen,the initial password is sent to the user. If no is set, the user receives an email with the URL to launch to then obtain the password.

At the end of this process, the user is now able to login with the initial password and change it. The change password rules adhere to the plug-in system configuration (USR40 password dictionary, RZ10 configuration parameters and security policy). These rules are not specific to GRC but based on SAP login sequence.

Conclusion

When you design your PSS process you need to choose the appropriate combination of steps for your organisation. At a minimum, you must define at least one step where you have confidence that only the user will know the information. This may be the Initial Logon, Challenge Response or Email.

Feedback and suggestions are encouraged, Please add your comments below – especially if you can contribute any more risks that should be considered as part of the PSS design process.

Regards

Col and Ale

Review and input by Gretchen Lindquist and S A

This document has been written to explain the Default Approver functionality in Business Roles Management and provide the high level steps to configure. Please note, the configuration of this CND_GRP (Condition Group) is not the same as Role Methodology (I will cover this is a separate document). Both concepts do however use BRF+ and IMG Configuration to achieve.

Default Approval Usage

The purpose of default approval is to allow you to centrally maintain approvers based on a set of criteria to default to your roles. In doing this, you do you reduce human error of assigning the incorrect role assignment or content approver to the role. These Access Control Owners are used as Agents in MSMP for Business Role Management Approval and Access Request Management workflows.

Requirements for Approver Setup

For approvers to be assigned to a BRM role they must be setup in GRC system and the following configuration in place:

1. SAP GRC User Masters via SU01
2. NWBC Access Control Owners (assign as Role Owner)
3. NWBC Role Owners (User to Condition Group)
4. BRFplus Function for APPROVER
5. Assign Condition Groups to BRFplus Functions
6. Default the approvers on the role

Steps 3 onwards will be detailed in this document.

Pen to Paper and Get your Design Right

Before you start to configure these you need to determine your mappings. To do this you need think through the following:

• Role Content Approvers
  • Who is allowed to approve a security role content change (i.e. the BRM workflow approval and role certification)?
  • Is it the same approver for all roles?
  • Do you have different Role Owners based on an attribute (you might split based on Process Area and/or Role Type, etc)?
• Role Assignment Approvers
  • Who is allowed to approver access to the roles (i.e. the ARQ/CUP/UAR workflows)?
  • Same types of questions as the ones you needed to answer for Role Content Approval

The system will allow you to have different approvers for Role Content and Role Approval for the same condition group. If you find yourself thinking that you need managers to approve, etc, for access request then you would not use the Role Owner Agent in the MSMP. Role Owner approval would be useful where you have specific roles requiring approval by a central person/area (such as a sensitive roles).

To assist in your Condition Group to Approver Mappings and BRF+ configuration, it is useful to start building up a spreadsheet as you identify your scenarios. For each of these scenarios you come up with, you will need to create a condition group. However, you need to consider that each role can only “calculate” one condition group in the return (more on this later).

Build your BRF+ Rule

For the purpose of this document, I am only showing a simple decision table (this is the level also covered in GRC300 training) as the goal of this document is to show how the default proposals for approver work as opposed to how to configure BRF+.

Via the IMG (path Governance, Risk and Compliance > Access Control > Role Management > Generate BRFPlus Applications, Approvers, and Methodology Functions) you can generate the ERM BRF+ rule to contain the correct data structure and decision table for your rule.

You need to complete the Application Name and the BRF+ Approvers Rule (note, these names are used in the next step as well).

Within the BRF+ you need to maintain you decision table with the result field for condition group. When you maintain this, you need to capture all possible role scenarios. For example, if you are building you condition groups based on Business Process then make sure each business process is mapped to condition group.

If you put the effort into your design, you should rarely need to modify the BRF+ as it is transported. You might find need if you introduced new modules or criteria. However, condition groups should remain fairly static whilst the approvers assigned to them can change.

Tell BRM what to logic to execute when the “Default Approver” button is pressed

This step is really known in the IMG as “Assign Condition Groups to BRFPlus Functions” as per the screen shot below. However, this is actually the link from the user’s front end (via a few steps in code) to know what BRF+ function to execute.

This is where I used to get confused with the different “condition groups” as GRC has used condition group a few times for different purposes. In this particular step I pretend condition group is actually Scenario. You need to set up a Scenario for APPROVER.

You can only maintain one entry for the APPROVER and that is the BRF+ Application and Function that you just created above. Unlike other areas of GRC, this time you provide the actual name instead of the alphanumeric Id.

SAP delivered configuration in the backend included table GRACCNDGPTYPE that maps the Scenario (condition group) and identifies the output as the GRAC_CNDGP which is maintained as the result for the BRF+ function. Shown below for those interested…

Assign the Condition Group to Users

Navigate to NWBC  > Access Management > GRC Role Assignments > Role Owners (entries are stored in table GRACCNDGPAPV) to map the Condition Groups to the Access Control Owners (assumption that you have created the SU01 Account in GRC and also defined the user as Role Owners).

The following rules apply in this step:

• There is no check to verify that you have selected a valid condition group
• Although no check, enter condition group Ids that you specified in your BRF+ results
• A user can be assigned to multiple condition groups
• A user can be assignment approver, role content approver or both for the specified condition group
• Multiple uses can be assigned to a condition group (necessary if you are separating approvals)
• Alternative approver is optional
• Updating this table will not automatically update the approvers. You will need to edit the role and default the approvers in again (or mass update the impacted roles)

Make sure you have at least one approver for each condition group to avoid errors (or lack of default approvers) when users press the “Default Approver” button in BRM.

Time to Default the Approver

If your configuration is completed and correct, next time you press Default Approver:

• You will be asked to confirm that you want to proceed
• All current entries for the role will be removed
• The BRF+ function will be evaluated and condition group returned
• The approvers assigned to the condition group will added back to the table

In the example below, although the same approver remains they no longer have role content approval rights. If no other approvers are added, this will be an issue unless the methodology does not require an approval step.

Improvements

This functionality is good to consistently default approval. However, its shortcoming is managing changes to approvers. For example, if a person leaves the companies or changes job their approval activities are transition to someone else then you need to update each role to default the new approvals. As a result, I raised this idea (quite some time ago). If you like this functionality and agree with this shortcoming, then please upvote the idea.

Regards

Colleen

Some time we get requirement to define initiator for

1. Manager & Role Owner are same
2. Requester and Role owner same

In these scenario we normally keep single level of approval,again this is not mandatory depends upon business.

To achieve this you need to create a initiator using DBLOOKUP.

Goto >>SPRO>>>Governance Risk and Compliance>>Access Control>>Workflow flow for Access Control>Define Workflow Related MSMP Rules

Process ID: as SAP_GRAC_ACCESS _REQUSET, since the entire request submitted for user provisioning is associated to this process id.

Rule Kind: Initiator Rule, as this rule will be used to initiate a workflow to determine which path it should take upon submission of request

RuleID: The Name of the Rule you are going to build and can be identified in BRF+ my application.

Rule type: Its Always BRF+ Flat Line item rules since we check Line item of Request, not just Header to determine path

Now select Header and select REQTYPE as input parameter as we may have may REQUEST TYPE and we need this for specific request type.

Go to BRF+ tcode

now to get the

Manager is equal to Roleowner and Role owner is equal to Requester you need to create DBLOOKUP

1)First identify the request id

2)Get the Manager of that request

3)identify the Role ID

4)Get the Role Owner fro that role.

5)Get the Requester from the same table of from when Manager is picked

Right click on Initiator application and create a DBLOOKUP

Select single entry table GRACREQ, this table has information about SAP Access Request, so lookup input query in to table is Request NO created during submission in the table and output value is REQUESTID.

Select Request number from context data and put it into a new table in result data, save and activate

comeback to select element REQID element

NOW Create 1 more DBLOOKUP to get the role id from table GRACROLE

NOW Create 1 More DB Lookup to get Manager ID for the particular request.

Run a look up on table GRACREQOWER, and look for USER TYPE MAN in the DBLOOKUPQUERY

to get Manager ID for that request need have a query for REQ_ID to fetch the request number and Manger for that request.

Now create 1 more DB lookup to get Role owner.

Run a query for Role on Table GRACROLEAPPRVR and lookup for approver in Z_GETROLEID DBLOOKUP table.

Now we need to Create 1 more DBLOOKUP for getting requestor information from the table GRACREQOWNER using request id from ZGETREQ_ID lookup to get requestor for that request only.

Save and activate all the Lookups .

Now go to decision table.

Click Table setting Select the condition column and Result column, based on which as decision to be made.

(We had added the elements after creating result table ,reason is if you have element you can select condition column,if you dont then it will be in result column)

Put your conditions in decision table

This was my condition you can use your

activate decision table but  add you lookup tables in signature in Function id then activate

Added missing screenshot.

ensure its added and activate ..

now you can add it in MSMP.

.

Regards,

Prasant

User Access Review - Nightmare in GRC SP13 I will update this regularly with all our issues and fixes.

Customize Review Instructions

For customizing the UAR review instructions in the UAR request approval screen, please implement the below SAP notes:

Below note is for creating a program and then creating a SE61 template for maintaining the customized instructions for UAR

1926795 - Not possible to customize UAR review instructions

Below is note is to format the instructions in the same way as maintained in SE61 in request approval screen:

1946444 - UAR Review Instruction Format in Access Request

BRF+ Fields for UAR requests

During UAR implementation, in BRF+ rule use ROLE_CONNECTOR and however your BRF+ rule doesn't work. To fix this issue and to route your UAR requests based on System implelment below SAP note:

1917837 - UAM : Connector based brf + rule is not working

Basic UAR Issues

In the UAR request approval screen, we observed some below mentioned issues.

1. User Name is not coming

2. Individual Role can be forwarded to another approver

3. Sometimes only UserID shows up and no role details

We fixed all above issues mentioned using below SAP note:

1868950 - UAM: UAR request display, print and forward assignment issue

UAR Jobs - Issues

When we schedule UAR jobs, although they are completed, they are still shown with In-process status. For this SAP has provided a note specific to few customers only.

1997960 - UAM: Unable to generate request for UAR/SOD.

UAR Reports - Issues

When UAR request is forwarded to another approver, in the UAR status report Approver ID is showing wrong. To correct this we implemented below SAP note:

1895571 - UAM: User Access Review status report not working

We have raised a OSS message to SAP as there is no connector based search available for UAR status reports. Below is the note provided to us which is not yet released to all customers.

2072384 Connector Criteria available in UAR Status report

Attachment of this note also attached in this post. Please check.

Symptom:

1. UAR history and status reports dump due to huge data.

2. No system/connector criteria availabe in user review status report.

Reason and Prerequisites

All data for all request was being stored in an internal table

Solution

Implement attached correction instructions

Add connector in User review status report

   1. Go to T-code SE 11 and select View radio button.

   2. Enter V_GRFNREPFILTER and click on display button.

3. Click on highlighted icon.

4. Enter report name ‘GRAC_CUP_USR_RVW_RPT”.

5. Click on edit icon, a window will pop up and press enter.

6. Click on new entry and enter as new entry for connector as mentioned below.

7. Save and activate the view.

Other terms

UAR history, UAR status, reports, dump, memory overflow, connector

------------------------------------------------------------------------

|Manual Pre-Implement. |

------------------------------------------------------------------------

|VALID FOR |

|Software Component GRCFND_A GRCFND_A |

| Release V1000 SAPK-V1004INGRCFNDA - SAPK-V1017INGRCFNDA |

------------------------------------------------------------------------

Kindly follow the steps as mentioned in attached file

(Connector_add.docx)

________________________________________________________________________

Valid Releases

GRCFND_A

V1000

V1100

________________________________________________________________________

After implementing the SAP note 2072384, we got another issue in the UAR status report where Stage column in the report is showing the same stage for all requests. For this SAP has released another note for us which is not yet released to all customers. Below is the SAP note:

2096437 - UAM: User review status report showing Incorrect Stage details

Symptom

UAR- User Review status report shows incorrect stage details.

Reason and Prerequisites

Wrong value is passed.

Solution

Implement the correction instruction.

Other terms

GRC, AC, UAR, Stage, User Review Status, Report.

Purpose

The purpose of this document is to provide links to the top 10 most viewed SAP KBA's for Governance, Risk and Compliance.(GRC)

Overview

This page will be updated regularly as new documents are published.

Click on the month below to view the publications for each GRC component:

Access Control                                   

   March 2014

   April 2014

   May 2014

   June 2014

   July 2014

   August 2014

   September 2014

   October 2014

   November 2014

   December 2014

Process Control

   April 2014

   May 2014

   June 2014

   July 2014

   August 2014

   September 2014

   October 2014

   November 2014

   December 2014

Risk Management

   April 2014

   May 2014

   June 2014

   July 2014

   August 2014

   September 2014

Please note, in order to view the contents of the Knowledgebase Articles (KBA), you will need to be logged into Service Marketplace.

The aim of this document is to focus on the system controls for password self service to enable you to consider how best to design and configure SAP GRC Password Self Service in your environment. This topic was raised as part of feedback in the document Password Self Service & End User Logon Configuration - AC10 by Leo and requested as part of the GRC Collaboration Project. If you are interested in specific configuration steps, please refer to Leo’s document or search SCN space for your requirements.

The scope of the document is SAP standard configuration specific to the SAP GRC component. If anyone would like to add suggestions on how to add additional security layers (tokens, SSO, etc) please add your comments in the section below for discussion.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A PSS tool needs to go through the basic process which includes verifying the identity of the user before the password can be issued. A critical design requirement for PSS is the ability to prevent an intruder masquerading as a valid user to obtain access to their account.  Within GRC, there is more than way one to achieve this.

The above diagram is a conceptual view of the complete steps if all Password Self Service configuration steps are activated. Below is a summary on the intention of each step and impact if they are not used.

Network Perimeter

This is not so much a step in GRC configuration but recognises that network security will determine if the HTTP service for End User Login is Internet Facing. Assuming GRC system access is only accessible via internal network access, you have limited potential intruders to those who have network access. It has been included to recognise network perimeter security has a part in the GRC solution but will not be discussed in this document.

End User Logon

The GRC End User Logon functionality utilises a SAP Service Account to authenticate access for the HTTP service. This means, a SU01 Service Username and password is stored against the SICF web services and the end users do not require a SAP GRC account. The positive of this functionality is that end users do not need to be set up in SAP GRC component (simplify maintenance as well as license cost).

GRC makes use of Data Sources for User Authentication, Search and Details for end user functionality. Data Sources are configured via the GRC IMG (transaction SPRO) based on the use of connectors defined in the Integration Framework. Synchronisation jobs are then executed to import the user details. The End User Log-in page can be configured to force authentication against a specific data source. This means, when the user accesses End User Logon functionality, they will required to enter their password for a system defined in the authentication configuration (such as Active Directory or SAP ERP/ECC) and a real-time call is performed to authenticate the user. It is possible to use SAP GRC as an authentication system as well – although this would defeat the purposes in End Users not requiring a SAP GRC account.

Screen Shot: Impacts for configuration setting for Data Sources Verification

Challenge

Challenge Response provides another way for a user to prove their identity through providing answers to pre-configured questions. The system issues a challenge (secret question) to which the user must respond (provide their answer). These questions and answers are stored in GRC tables with the answers in hashed form.

Challenge Response requires a registration step in which the use must provide this information. System configuration can provide template/global questions and the user can also create their own.

Screen Shots: Impacts for configuration setting for Challenge Response in PSS Global Settings

Reset Password

Once a user has proven their identity (End User Logon or Challenge Response) they can now select the system they require a password reset for. Users will only see the systems for which PSS has been enabled (IMG configuration controls this) and the user has access to. In this document, the example of SAP ECC has bee chosen. Therefore, a BAPI is called via RFC connection to reset the user password.

Emailing User

SAP GRC component will generate an email and send the login details to the user. System configuration can control if the password is specified in the email or if a URL is embedded instead. The URL example has been shown in this diagram.

URL Link and Password Change

The GRC configuration allows you to choose send a password URL link or the actual password. This is set within the configuration for User Provisioning. As part of sending URL link only, you will need to specify how long the link is valid for before it expires. If Yes is chosen,the initial password is sent to the user. If no is set, the user receives an email with the URL to launch to then obtain the password.

At the end of this process, the user is now able to login with the initial password and change it. The change password rules adhere to the plug-in system configuration (USR40 password dictionary, RZ10 configuration parameters and security policy). These rules are not specific to GRC but based on SAP login sequence.

Conclusion

When you design your PSS process you need to choose the appropriate combination of steps for your organisation. At a minimum, you must define at least one step where you have confidence that only the user will know the information. This may be the Initial Logon, Challenge Response or Email.

Feedback and suggestions are encouraged, Please add your comments below – especially if you can contribute any more risks that should be considered as part of the PSS design process.

Regards

Col and Ale

Review and input by Gretchen Lindquist and S A

Hi All

If you are wondering what this document is all about then please refer to: Community Collaboration for GRC Blogs and Documents - you will find an overview of what this community collaboration is about and the rules on how you can contribute. You are still encouraged to write your own blogs and documents without participating in this process (it would be nice if you could update this document to let the community know you are working on something).

You are also welcome to be both the person who suggests the topic and the author. This can advertise you are working on the topic and hold yourself accountable to a deadline that the community is aware of.

Remember: Add a row below the 3rd row of the table to included your suggestion. Please do not change the first three heading rows as these rows indicate the title and a short summary of the content below. When including your name, please include your SCN profile as a hyperlink (easiest way to open your Profile in a new browser tab and copy the URL)

This document describes how to perform mass change of mitigation assignments. I would like to give you an overview how the down-/upload program for mitigations can be used and in which business scenarios it might be helpful.

Please note that the used programs to perform mass mitigations are available with AC 10.0 SP10. See also OSS note: http://service.sap.com/sap/support/notes/1749804

Problems which can be handled:

• Change monitor of mitigating controls (e.g. replacements)
• Change validity date
• Change system
• Add / Remove a huge number of mitigations
• Activate / Deactivate a huge numbers of mitigations

The most complex scenario is to change a monitor of mitigating controls and this best practice process I would like to share in this document. All other scenarios are similar and can be handled analog to this.

Removing an existing monitor, who still monitors mitigations, must be changed before he can be removed from a control. The following error message will appear if you try to remove the monitor.

First we have to define the new monitor by adding a new row and define with assignment type = Monitor. Please be aware that the new monitor must be assigned to the organization unit and must be an owner (pre-requirements).

The following picture shows that BANZER_A is still monitoring an active mitigation for the user T-BANZER as we could see above. It is also possible that the user monitors more than one mitigation.

Updating all mitigations in NWBC would take some time and therefore you can use the following programs.

GRAC_DOWNLOAD_MIT_ASSIGNMENTS         To download all mitigations to a local file

GRAC_UPLOAD_MIT_ASSIGNMENTS               To upload all mitigations from a local file

Start the program via transaction SA38.

Beside user mitigations it is also possible to download profile, roles and role/user organizational mitigations. In this example we are going to change user mitigations and therefore we choose USER.

Personally I always download all mitigations as XLS file as it is easy to change the content with Excel (filter, search, etc.).

After downloading the file you will see all mitigations in the Excel. In my example I have only one mitigation for the user T-BANZER.

The structure of the file, as the titles are missing, is given below.

It is possible to update each column (system, validity, etc.) and also to add an additional lines for new user mitigations. Please be aware that the values are checked while uploading and wrong data will abort the upload.

As we can see in the following picture I have updated the monitor in column H to LIJA (user name of the new monitor).

After I am done with editing the file I save and upload via the upload program. Therefore I use again SA38.

Here it is also possible to upload user, role, profiles and organizational mitigations. Uploading mitigations can be done in two different modes. Append means the uploaded mitigations will be added to the existing, whereas overwrite will overwrite all existing mitigations. Please be aware if you have for example 1000 mitigations and you upload a single record and choose overwrite, all others will be deleted and the single mitigation is the only one existing in the system.

To avoid such scenarios I always download all mitigations to a file, copy the file, modify the copied and upload the modified file. In case if something goes wrong I can upload the old file.

If the file is uploaded successfully you will see the following message. Errors will also be reported.

In NWBC we had the following mitigation before uploading.

After uploading we can see the new monitor.

Now the old monitor can be removed and the mitigating control is successfully updated.

As mentioned above it is also possible to change other values in the local file such as validity date, systems, etc. which offers great functionalities to easily change a huge number of mitigations.

Let me know if you have other inputs to extend this document.

Best regards,

Alessandro

This document is a collection of the most useful SAP GRC Access Control documents, blogs, resources, links, etc. here in SCN.

Overview

Getting Started with SAP Governance, Risk and Compliance Solutions (GRC)

GRC Processes, Lifecycles and Responsibilities

General opinion and thought-leadership

Are you ready to implement GRC 10?

A lot of help from my friends

If I had it to do all over: looking back on GRC 10 projects

Lessons learned from SAP GRC projects

Remediating Access Control SoD Risks

Internal Controls - a step towards strong controls

Defining Mitigating Controls / Compensating Controls

IT Control Testing - SOX Compliance

A #GRC tool is just part of the solution

GRC General

Helpful transactions, tools, programs, tables, etc. for a SAP GRC Consultant

NWBC screen layout options for GRC

Customizing NWBC for New Menus with our own Transactions, Reports and Accessing SAP Backend Systems from NWBC

Configure LaunchPad for Menus

Customizing Access request and approval screens in GRC Access Control

Issues, Bugs in GRC SP13 - Related Fixes

General tips to help in troubleshooting scenarios

Access Control Debugging tips

SAP GRC AC 10.1 - Enhancements

HR Triggers

Understanding HR Triggers in Access Control 10.0 - Governance, Risk and Compliance - SCN Wiki

GRC 10.0 - HR Trigger configuration - Governance, Risk and Compliance - SCN Wiki

Example of decision table for GRC 10 HR Trigger rule, using BRF+ tool

GRC Access Control - Compliant User Provisioning: HR Triggers

Debugging HR Trigger - GRAC_HR_TRIGGER_EVENT_RECIEVER

Debugging HR Trigger - Simulation

Debugging HR Trigger - PA40 changes to infotypes

MSMP Workflows

AC 10.0 - Customizing Workflows for Access Management

MSMP - Multi Step Multi Process – GRC’s answer to Workflow Configuration Flexibility

LDAP

Configuring LDAP Connector in Compliant User Provisioning of GRC Access Control

LDAP Group parameter mapping.. what does it mean?

Mobile Apps in SAP GRC

Administrator guides for Access Approver, Policy Survey, etc.

Fiori apps in GRC – Install two applications in 5 easy steps

Access Control with Identity Management (IdM)

SAP BusinessObjects GRC 10.0 Integration Guide – Access Control 10.0 and NetWeaver Identity Management

SAP Access Control 10.0 Interface for Identity Management

Access Risk Analysis (ARA)

ARA - For the new kid on the block

Rule set - Rules & Rule Types

Business Risks / Rule Set

Download, Modify and Upload the Access Risk Analysis Rule Set in SAP Access Control 10.x.

How to set up a Configurable Business Rule

Online vs. Offline Risk Analysis

Creation of Mitigation Controls in GRC 10.0

Organizational Rules in GRC Access Control

Mass change of Mitigation Assignments

SAP GRC AC 10.0 Alerting

The Action Usage Sync job in technical details - GRC Access Control 10.0

The Repository - GRC Access Control 10.0 

Access Request Management (ARM)

ARM - For the new kid on the block

AC10.0/10.1: Create Rule Based on Risk Violation in Request, Using BRF+ Procedure Calls

Approve/Reject Own Requests

How to Change Subject Line in SAP GRC Email notification

Recommendations for using Business roles provisioning in access request

Configure Manager Look-Up in ARM for GRC 10

Role Search Screen Enhancement – GRC 10

Terminate Account - Request Process - GRC 10

Creating Access Request: Template Based Requests and Configuring End User Personalization forms for use with Access Requ…

GRC Request with both System and Role Line Items

Access Control 10 (ARM) – Risk Analysis Report Type is editable in Access Request.

Access Control: - Create Access Request Using Web Service in GRC10

Design Considerations to reduce Password Self Service (PSS) Intruder Risk

User Access Review(UAR) Workflow Configuration and Description - Governance, Risk and Compliance - SCN Wiki

Business Role Management (BRM)

BRM - For the new kid on the block

Maintain Default Roles in BRM GRC AC 10.1

Role Import - GRC 10

Import Role from ECC to GRC system

Business Roles concept and usability in GRC AC10 

BRM Default Approvers via Condition Groups

Emergency Access Management (EAM)

EAM - For the new kid on the block

Usage of EAM

EAM - Provisioning Strategies

ID-Based Firefighting vs. Role-Based Firefighting

AC 10.0 - Centralized Emergency Access

Configure Emergency Access (EAM) in GRC 10

De-centralized EAM GRC 10.0

EAM - Approve through Wrokflow

Emergency Access Management Reporting

Analysis and Recommended Settings of the Security Audit Log (SM19 / SM20)

See also

SAP GRC Process Control - Useful Documents, Blogs, Resources, etc.

SAP GRC Risk Management - Useful Documents, Blogs, Resources, etc.

SAP Fraud Management - Useful Documents, Blogs, Resources, etc.

Legend

	SAP SCN Documents
	SAP SCN Blogs
	SAP Wiki

Please help in updating the collection so that new users can get a well structured overview for their information.

Best regards,

Alessandro

A fragmented, reactive approach to managing access risk isn't just inefficient and costly - it's bad for business. The SAP BusinessObjects Access Control application can enable your business to confidently manage and reduce access risk across the enterprise by helping you prevent unauthorized access and achieve real-time visibility into access risk.

To learn more about SAP GRC solutions, please visit our product page, or go to the GRC area of BPX. We also invite you to learn more about SAP GRC Access Control 5.3.

• Getting Started
• Access Risk Analysis
• Emergency Access
• Business Role Management
• Access Request Management
• Integration with Other Applications
• Access Control 5.3

Getting Started

GRC 10.0 Pre-Installation 
The presentation explains the new architecture and the necessary prerequisites for a successful installation of SAP BusinessObjects GRC 10.0 and guides the reader through the installation procedure of the software.

GRC 10.0 Post-Installation 
The presentation explains the necessary post-installation steps in SAP BusinessObjects GRC 10.0.

AC 10.0 Post-Installation  
The presentation covers the basic steps required for setting up SAP BusinessObjects GRC 10.0. For setting up specific functionality please refer to corresponding pre-implementation guide.

AC 10.0 - Installation Checklist 
This guide provides a checklist for your installation activities for the Access Control 10.0 application.

Access Risk Analysis

AC 10.0 Pre-Implementation From Post-Installation to First Risk Analysis
This document allows implementation consultants and administrators to setup the required functionality for running a user level risk analysis after the post-installation has been finished. This is by no means a comprehensive guide for setting up the Access Risk Analysis component, rather it allows testing the application is working properly by setting up a basic test case.

AC 10.0 - Enhanced Access Risk Analysis  
This document describes the major enhancements to the access risk analysis capability of GRC, including end user customization and personalization. It covers how to navigate through the different reports, and also about new functionality such as new bulk maintenance, automation, audit trail, and mitigation options.

Emergency Access

AC 10.0 Pre-Implementation From Post-Installation to First Emergency Access 
This document allows implementation consultants and administrators to setup the required functionality for running an emergency access (firefighter) session after the post-installation has been finished. This is by no means a comprehensive guide for setting up the Emergency Access Management component, rather it allows testing the application is working properly by setting up a basic test case.

AC 10.0 - Centralized Emergency Access 
This document is a detailed guide on the emergency access capability of Access Control 10.0. It explains the basic concepts about emergency access and provide details on how to configure the application. Also this document includes additional information on the types of logs available for monitoring the emergency accesses.

Business Role Management

AC 10.0 Pre-Implementation From Post-Installation to First Role Creation  
This document allows implementation consultants and administrators to setup the required functionality for creating a single role in AC after the post-installation has been finished. This is by no means a comprehensive guide for setting up the Business Role Management component, rather it allows testing the application is working properly by setting up a basic test case.

AC 10.0 - Business Role Management 
This document allows implementation consultants and administrators to setup the required functionality for creating roles in AC after the post-installation has been finished. This guide provides the configuration steps for setting up Business Role Management.

Access Request Management

AC 10.0 Pre-Implementation From Post-Installation to First Access Request 
This document allows implementation consultants and administrators to setup the required functionality for creating an access request after the post-installation has been finished, please notice that it is required to configure Role Management before being able to request role assignments. This is by no means a comprehensive guide for setting up MSMP workflows, rather it allows testing the application is working properly by setting up a basic test case.

AC 10.0 - Customizing Workflows for Access Management
This document allows implementation consultants and administrators to setup the required functionality for enabling the workflow engine in AC 10.0. You will learn the main components of the new workflow engine and how to customize them, also how to create agents and initiators using Function Modules and BRFplus.

AC 10.0 - How to Customize Notification Templates for AC Workflow  
This how-to-guide explains how to set up the SAPconnect communication interface in your application server in order to send out email notifications triggered by workflow events in Access Control 10.0. This guide provides a comprehensive overview of workflow events that can trigger email notifications and notification variables used to populate the message bodies with information that is specific to each request. The guide also explains how the pre-delivered message bodies can be replaced by custom messages as well as how email reminders are set up.

AC 10.0 - Managing Custom Fields for Access & Role Management 
This document explains how to setup the required functionality for adding custom fields to access requests and roles maintained in GRC 10.0.

AC 10.0 - End User Personalization  
This how-to-guide explains the End User Personalization concept in Access Control 10.0 and the technical configuration to attain that functionality.

AC 10.0 - Performing Segregation of Duties Review 
This how-to-guide explains the Segregation of Duties Review concept and the technical configuration to attain that functionality.

Integration with Other Applications

GRC 10.0 Integration Guide:

Access Control 10.0 and NetWeaver Identity Management

SAP Access Control 10.0 Interface for Identity Management
These documents cover all the new web services for Access Control 10.0 and integration scenarios with IDM solutions. The main foundation for this integration is based on NetWeaver Identity Management 7.2.

SAP BusinessObjects GRC 10.0 Integration Guide - Access and Process Control 10.0 

With the release of GRC 10.0, Access Control and Process Control are offered as an integrated solution, both at the data layer and at the user interface layer. This new unified platform enables increased harmonization of key master data. Organization, process and control structures can now be shared across components of Access Control and Process Control, which supports a more integrated approach to governance, risk, and compliance. Access risks identified in Access Control can be mitigated using controls managed by Process Control, as an example. This document details methods for harmonizing data across Access Control and Process Control.

Access Control 5.3

SAP GRC Access Control 5.3  
SAP GRC Solutions for Access Control handle sustainable prevention of segregation-of-duties (SoD) violations.

Hello!

Configuring EAM in GRC 10 isn’t a difficult task, but there are some details you have to take into account. The document “AC 10.0 Pre-Implementation From Post-Installation to First Emergency Access” is useful, but it doesn’t  consider all the details. Here I’ll try to give you a complete explanation about how to configure EAM successfully.

Configure Parameters:

In GRC Box, execute transaction SPRO and navigate to here:

The following parameters should be set according to the table:

For a complete description of the above parameters, please refer to the guide:

https://service.sap.com/instguides - > SAP BusinessObjects Governance, Risk and Compliance (GRC) -> Acess Control -> Release 10.0 -> Maintaining Configuration Settings Guide - SAP AC 10.0

You might want to change some of them; the recommended values only serve as a guide for the initial configuration.

Changes in the parameters table will be included in a transport request, you should release the transport to your QA/PROD systems when you finish the EAM tests and adapt the parameters according to your requirements.

Parameter 4010: What’s for?

If you’ve been working with GRC 5.3, this parameter should sound weird to you.

The purpose is to identify to the application that the user who is logging on to the target system is a Firefighter ID. The target system makes a call to the GRC Box and reads this configuration to check if the user has this role assigned to them.

That means that you have to create the role that you’ve set in parameter 4010 in all the target systems with the exact name provided there. Usually, you copy it from the standard SAP_GRC_SPM_FFID (it contains RFC authorizations).

Only the users who have that role assigned in the target system will be available for selection in the GRC Box as Firefighters IDs.

Kindly check note: 1668255 - Firefighter ID role name for Param ID 4010

For more information regarding default roles provided by SAP, please refer to Security Guide available here:

https://service.sap.com/instguides - > SAP BusinessObjects Governance, Risk and Compliance (GRC) -> Acess Control -> Release 10.0 -> Security Guide - SAP Access Control 10.0

Adding connector to the SUPMG Scenario:

Please check: Note 1562760 - AC10.0 - Intergration Scenarios to Connector link

At this point you have already created the connectors.

Now you have to link the corresponding connectors to the SUPMG scenario:

Click here:

And:

Required roles in the GRC Box:

SAP provides standard roles that must be copied to the customer namespace. For this sample configuration you should need at least to create a copy for the following roles and generate the corresponding profiles:

You can just name them as Z_<full standard role name> or use a naming convention according to your company requirements.

CAUTION: Please, follow he instructions provided in tha attachment of note:

Note 1663949 - EAM Authorization Fixes for Central Owners and Reason Codes

There are some changes you have to made to the standard roles and also there's a complete explanation of the authorization objects.

For more information, kindly refer to the Security Guide (link provided above).

Security considerations for EAM Roles:

Kindly read a specific authorization guide for EAM that is attached to the note:
Note 1663949 - EAM: Authorization Fixes for Central Owners and Reason Codes

and take into account the authorization concept for the roles:

1730649 - Firefighter owner can assign ANY Firefighter ID to Firefighter User

"As per the functionality in AC10, we have concept of role based authorization. If a user is having SAP_GRAC_SUPER_USER_MGMT_OWNER  role at the backend, then he  should be able to assign any FFID to any Firefighter user.

The user Assigned with the Role of EAM Admin “SAP_GRAC_SUPER_USER_MGMT_ADMIN”
and EAM Owner “SAP_GRAC_SUPER_USER_MGMT_OWNER” can do all available owner action for all connector.
The Auth. Object used for firefighter Maintenance is GRAC_FFOWN & GRAC_OWNER"

---->>> vote for a simpler way if you disagree with this weird role-based model !! -->>> Simple setting for EAM owner/controller authorization

If you are not going to use ARM workflows and you want to restrict Owners, please have a look at the thread:

GRC EAM Authorizations: Few Anomalies in Standard Roles

(Provided by Akshay Gupta)

Required users in the GRC Box:

In order to show a sample for testing, It’s necessary to create (or use existing ones) three users:

FF_OWNER: This user will serve as owner for the firefighter ID. It should be assigned to the role Z_SAP_GRAC_SUPER_USER_MGMT_OWNER

FF_CONTROL: This is the firefighter controller. You assign Z_SAP_GRAC_SUPER_USER_MGMT_CNTLR.

CAUTION: This user MUST have a valid e-mail address maintained in SU01 if you want the controller to receive notifications via e-mail.

FIREFIGHTER: This is the firefighter user, who will be able to access in the target system with the Firefighter ID. You assign Z_SAP_GRAC_SUPER_USER_MGMT_USER in addition to the base roles. If you don't assign the base roles you won't see the user (FIREFIGHTER in this case) available for selection in the Firefighters IDs.

<your user>: The user who is going to perform the configurations, must have at least the role Z_SAP_GRAC_SUPER_USER_MGMT_ADMIN assigned.

In addition to all the mentioned roles above, all users must have the roles Z_SAP_GRAC_NWBC and Z_SAP_GRAC_BASE assigned.

For a theoretical explanation of the users and its responsibilities, refer to https://help.sap.com/saphelp_grcac10/helpdata/en/16/404938695540b398a5e76fe8cfb067/frameset.htm

Required roles in the target system:

In the target system you have to make a copy of the role SAP_GRAC_SPM_FFID and generate the profile.

CAUTION: The name of this role MUST be the same configured in the parameter 4010 in the GRC Box. In this example: Z_SAP_GRC_SPM_FFID.

Required users in the target system:

You have to create a user (FIREFIGHTER_ID) in the target system with the corresponding roles required roles/profiles according to your requirements. In addition you must assign to the FIREFIGHTER_ID the role Z_SAP_GRC_SPM_FFID.

This user should be of type: “Service” as per note 1702439

The following note describes an issue you'll face with this kind of users: Note 1586989 - Object Services icon not available in Firefighter ID session

I'll update this document when a specific note for GRC 10 is released regarding this issue.

Take into account this important note for service users: 1945098 - Service users are not considered in decentralized firefighter

Creating central Owners and controllers:

Access to the NWBC:  http://<server>:<port>/nwbc/ or execute Tcode NWBC in the GRC Box.

Go to the “Setup” tab and:

Create entries for the Firefighter controller and owner:

Creating reason codes:

You have to create at least one reason code to be able to use the firefighter ID later.

Associate the entry to the corresponding target system.

Synchronization Jobs:

In accordance with note: 1585079

You have to execute the synchronization Jobs in order to make the FF IDs available in GRC Box for selection:

Please make sure that you have performed following configuration steps:

1. Integration Scenarios are configured as explained in note 1562760

2. Please make sure the Firefighter role is assigned to Firefighter IDs in the corresponding client system and that the same role has been given as parameter value for configuration parameter 4010. Configuration parameters can be configured in the transaction code SPRO => Governance, Risk & Compliance => Access Control => Maintain Configuration Settings

3. Run User/Role/Profile/Auth synchronization jobs. The Link to run these jobs can be found Under transaction code SPRO => Governance, Risk & Compliance => Access Control => Synchronization Jobs.

Once you have executed the Repository Sync job with the corresponding target connector, the FF ID will be available for selection in the GRC Box.

See also Note 1668255

…Once you are done with the above steps, re-run an Incremental/Full User Sync for the Firefighter IDs with the Firefighter Role to be SYNCed into the GRC box.Now re-launch the application via NWBC or Portal and then search for the Firefighter ID and this should be available in Firefighter ID list.

                          …

Assign Owners:

Assign Firefighter IDs to Firefighters

Here you assign the Firefighter ID to the corresponding Firefighters users (one or more)

And in the controller tab set the controller user:

Mass upload of assignments: In case you need to perform an initial load or a mass maintenance you can use one of the programs provided for migration as described here 1744929 - Mass Upload of Assignments for EAM

Also check the following note if you require a mass reassignment, for example, mass change of an owner that is currently assigned to many FF IDs:

2072846 - FF mass maintenance

Firefighter collector Job:

Execute tx. GRAC_SPM_LOG_SYNC and schedule the log collection periodically as per note: 1617529

Known problems with time zones:

Note 1595462 - Logs not visible in the SPM Reports

Note 1775432 - Transaction logs are not getting captured by GRC 10.0

Known problem when connector is set to “*”:

Note 1726157 - GRAC10 EAM GRAC_SPM_LOG_SYNC_UPDATE doesn t collect data

Performance problems :

Note 1750024 - GRAC - Performance of the SPM Log Sync

You'll find many notes in SAP Marketplace related to performance issues.

Other errors:

Note 1773855 - EAM10.0 Sometimes Workflows and transaction logs are missed

Note 1776070 - GRC EAM program is giving a short dump and no logs generated

Note 1731923 - EAM:Transaction Logs are not being captured while sync

Have you lost EAM logs?

If you lost some EAM logs and the data is still available in the plug-in system you can schedule a time-based special sync:

1934127 - GRC10 EAM: EAM recovery program to retrieve missing log and to generate the missing workflows

E-mail configuration (Centralized Firefighter):

If you want the controller to receive e-mails (firefighter log on notification and firefighter session details) you have to check the following:

• Make sure your Basis team has properly configured outgoing e-emails from GRC Box (Tx. SCOT)
• Controller notification method was set to: Email (see above)
• SPRO parameters:

4002 Send E-mail Immediately YES

4007 Send Log Report Execution

Notification Immediately YES

4008 Send FirefightID Logon Notification YES

4009 Log Report Execution Notification YES

• Controller user (FF_CONTROL) has "Comm.Method” set to “E-Mail” in SU01 and has a valid e-mail address.
• WF-BATCH User must also have an e-mail address in SU01; otherwise you’ll get the following error in tx. SLG1:

According to the configuration settings guide:

You can change the parameter and use another user to send the e-mails.

After executing the GRAC_SPM_LOG_SYNC_UPDATE, please execute tx. SOST and check if the e-mails were generated (you have to access the firefighter to get the e-mails).

Implement Firefighter user Exit:

Despite the Firefighter ID password is changed by the application each time you start the firefighter (you can check it via change documents in the target system), Firefighter Ids need to be restricted from Logging in into SAP System directly via SAP GUI. For this purpose either we need to create and modify the SAP User Login Exit.

Check

1545511 - Firefighter User Exit

1735971 - User exit to prevent direct firefighter login

Security Issue???: http://scn.sap.com/thread/3273562

If the user exit is properly implemented you'll get the following message when trying to log-on directly with a Firefighter ID (or any user assigned to role configured in the parameter 1090 in the plug-in System !!!):

Required RFC connections for EAM:

Please check: Note 1701047 - Is it mandatory to use trusted connection in the RFC destination for Firefighter Connector?

"Yes it is mandatory to make a trusted relationship so that communication can be established between the GRC system and the plug-in."

This topic has been discussed here (see comments below). The note is for Centralized FF and true is that it works anyway with non trusted connection. In case of decentralized model the connector is used to retrieve logs, so it doesn't need to be trusted.

Links to more documentation:

Note 1394281 - Superuser Privilege Management Log Report Content

Note 1065048 - Firefighter Log Not sent in Email to Controller <<- for 5.3, but useful

Note 1618040 - Performance fix for SPM transaction logs for large systems

Note 1732938 - Firefighter incorrect language setting on ERP Production

Note 1730649 - Firefighter owner can assign ANY Firefighter ID to Firefighter User

Note 1747283 - EAM: Entries in EAM logon pad not Visible for a firefighter

Decentralized firefighting (as in GRC 5.3) is available as of GRC 10.0 SP10

As of SP10, Emergency Access decentralized firefighting features are available.Users can install and use the EAM Launchpad to perform ID-based firefighting directly on plug-in systems. This means that Firefighter session could be started from the plugin system itself without the need to access the GRC Box. This approach was used in GRC 5.3. With GRC 10 SP10 you can chose between centralized or decentralized firefighting.

The most important advantage of decentralized firefighting is that you can continue using firefighter even when the GRC Box is down. In my opinion, it’s also more “user-friendly” since the firefighter doesn’t have to log on to GRC Box in order to start the firefighting session, he/she only needs to execute a transaction in the plugin system. For some companies, the centralized approach is better since the user access to a system (GRC Box) and can start firefighter sessions in multiple systems.

Bottom line, the most important thing is that with SP10 you have to option to choose and below you’ll find information that’ll help you to configure decentralized Firefighting.

The idea of a decentralized firefighting was submitted by Daniela Bork on SAP Idea Place: Access Firefighter application locally in AC10

So, if you have a good Idea, please share it with SAP customers and employees in the Idea Place and maybe it becomes a new functionality!

Main documentation can be found in the guide attached to the note: Note 1690964 - Emergency Access Management Overview Documentation

In the GRC Box a new parameter is available and must be set accordingly:

Under transaction SPRO, navigate to here:

And create a new entry for parameter 4015 which has to be set to the value “YES”

Additionally a new synchronization job is available and must be executed in order to synchronize the EAM data from GRC Box to the plug-in system. Remember that configurations (firefighter assignments, controllers, owners, reason codes, etc.) are still maintained in a centralized way, i.e in the GRC Box.

In order to sync this data with the plug-in, a new job is available and can be found here:

In the connector field you have to set the corresponding plug-in connector.  In order to keep you plugin system updated with the changes you made in the GRC Box, this report should be scheduled periodically, I think hourly would be fine. In addition, if you have multiple plug-in systems, you should follow the same approach as with the log synch: create individual jobs for each connector instead of a unique job with connector value “*”.

Configuration in the plug-in system

In the plug-in system you’ll find new activities under SPRO:

These activities are described in here: 1804207 - GRC EAM 10.0: Configuration parameters introduced in SP10 for EAM

If you haven’t  set the parameter 1000 in the plug-in system, you’ll have to do it in order to use decentralized firefighting, otherwise you’ll get an error message as described here:1800772 - Error 'No Destination specified' when using transaction /GRCPI/GRIA_EAM

Then, check the parameter as described below:

If the parameter 1000 isn’t present you have to create it and set the value to an RFC destination pointing to the system itself:

Since this configuration is transported I used to recommend to create a new RFC destination in DEV, QAS and PRD system with the same name, let’s say “GRC_CONNECTOR” and transport the configuration throughout your entire landscape. But nowadays, this parameter is used in the log-in notification e-mail to the controller, and if you are going to use that functionality you might want to create a system name independent connector, i.e. "P01CLNT800" and temporally change the client settings in SCC4 in order to allow the table modification in production systems.

The RFC connection does not require a user. It just has to point to the correct system/instance and a specific client.

Required users

Controllers have to be created in the GRC Box as well as with centralized firefighting. In addition these users must exist in the plugin system and have a valid e-mail address because login notifications are sent from plug-in system

With the decentralized scheme it’s not necessary to create the firefighter users in the GRC Box, because they’ll start firefighter transaction from the plug-in system.

E-mail considerations (Decentralized model)

Log-in notifications are sent from the plug-in system (the e-mail is sent with the Firefighter user, so remember to properly configure it in SU01):

But, as with the Centralized approach, Log  notifications are sent from GRC Box

These requires a proper mail configuration (tx. SCOT) in both systems: plug-in and GRC Box.

General Note for problems with e-mail in decentralized EAM:

1877706 - Login and Log Report Notifications are not being sent to the firefighter controller in case of decentralized firefighting

Plug-in roles

You’ll have to create a new role as a copy of SAP_GRAC_SUPER_USER_MGMT_USER.

You should add the following authorization to it:

For some NW releases ACTVT=02 will be also required. Kindly Check 1753459 - EAM: S_USER_GRP with ACTVT=02 required

This role is assigned to the firefighter users. Bear in mind that these users should not have access to user maintenance transactions, for example SU01. If the firefighter IDs are properly assigned to a group and you can restrict the CLASS field this is not a big issue, since despite they could change the password, they won’t be able to access because the user exit is implemented in order to prevent it.

This extra authorization was documented by SAP in November 2013 in the note:

1944417 - In decentralized firefighting firefighter is not able to perform firefighter logon

Previous versions of this post contain this solution as unofficial, but now has become official.

"..The firefighter is not having the authorization to change the passowrd. In centralized firefighting the password is changed by RFC user, but in decentralized version as there is not RFC connection, the password is changed by firefighter. The functionality works as in EAM 5.3...."

In addition to this role you also have to create roles for administrator and owner. Remember that extending the validity period is a new activity available in the plug-in system and owners and administrators should have access to it.

Known Problems ( specific to decentralized EAM)

Note 1849289 - For Decentral EAM No Reasoncode and Activity desc captured

Specific for CUA systems:Note 1814400 - Decentral call is opening different session in CUA

(Documentation provided by:Guido Stusinsky)

Common Issue: Logon screen appears when starting FF session

It's possible that we get a log on screen after starting the FF session. This is an incorrect behavior since the user doesn't need to enter the FF ID password.

Here some tips:

• Check the RFC connection. Perform an authorization check in SM59 to check if the RFC user is OK.
• Check that the RFC is pointing to the correct client.
• Look for dumps in ST22 in the plugin system.
• Check if the FF ID password is productive, reset the password or check with changing the user to type "Service" if you are using "Dialog" user for FF ID.
• CUA Systems: Since EAM requires to change the password of the Firefighter ID each time you log-on from the launchpad, the CUA's initial password needs to be set as 'Everywhere' or 'Proposal'. Please check point 6 of note 1861981 - Things to check when error message 'Error in opening RFC destination' appears in GRAC_SPM
• Have a look at the following notes:

1861981 - Things to check when error message 'Error in opening RFC destination' appears in GRAC_SPM

1777094 - EAM log on is not possible with the error: 'Error found in RFC (plug in system) and respective logon\logons are disabled'

Note 1886332 - GRC 10.0 EAM prompts for user/password while logging

Note 1872709 - Logon popup shown when launching the EAM session

  Common Issue II: Logs are not getting captured

If you cannot get the FF Logs don't get frustrated. This is not unusual. I'll give some tips (and hopefully you can help in order to add more!):

• General recommendations an errors are included in note: 2029368 - EAM Synchronization Jobs Not Completing Resulted in Data Loss
• It could be to an authorization issue with the RFC      user. The usual one is related to object S_TOOLS_EX as described 1916172 - User Action Usage Sync Error - User ID showing as -- ? -- . Anyway you can trace the RFC user via ST01 in the back-end while performing a log synch and check if you have some authorization issue.
• Clock skew: check the system time in the GRC box and compare with the plugin system. You can do it  by check System -> Status at "the same time" in both systems. A clock skew of 1-2 minutes can cause severe problems in the log collection. Time zones do not need to be same... it doesn't make sense by the way, cause having the GRC box in a Server in India and the ECC in Argentina will be impossible. Even here in South America we usually work with Servers in Chile, Brazil, Argentina and these countries sometimes do not use the same time zone. So...using different time zones has to be a possibility, but you have to be very careful with the clock skews, and if you have differences ask your Server Admins to check it and use a NTP Sever to keep all systems synched.
• Check that you have data in transaction STAD and ST03N  in the plugin system for the FF ID you're trying to get the logs. If necessary check with your Basis team if the Statics are being collected  properly.Try executing an action usage synch and check in table GRACACTUSAGE if you have data for the FF ID.
• Remember to schedule the job hourly as per SAP  recommendation an not running it just when you want to get the logs. This probably will cause lose of data.
• Check transaction SLG1 in the GRC Box in order to know   the result of the collection. Sometimes you get there the exact cause, for example "RFC Timeout", "RFC error", etc.
• Check for dumps in the plugin system (transaction ST22) and look for dumps created by the RFC user. TIME_OUT or memory related dumps are usual for large systems.
• SAP has released many enhancements and corrections related to log collection. Just to name one of them that isn't included in
       the latest SP: 1962440 - GRC EAM - Change Log Collection Performance Enhancement but you'll find others in the marketplace an probably SAP will release more. Make sure you have all the corrections applied.
• A last resort when you have problems with log collection (due to performance) would be to create an index on CDHDR table if the dumps in the back-end are related to some queries with such tables and indicate that. The official note is 1741151 - GRC 10.0 Indexing on CDHDR table in case of  time out issue due to huge data Creating an index on such table is something that you have to discuss with your DBA, Basis and Development teams. You have to be very careful with that and you should ask SAP if this is recommended to your scenario and there're no chances to improve the queries in the code. The table stores change documents and also can be reduced via archiving and this should be also an option to discuss before creating an index.
• SAP released a note recently indicating that mass activities cannot be performed by Firefighters: 1378276 - Mass Transaction support through Firefighter product

Common Issue III: Firefighter sessions remain open

SAP considers that such issue isn't specific to EAM: 1290018 - Firefighter ID is locked in Superuser Privilege Management

If the session isn't open (check SM04 in the plugin system) but the FF is still locked in the launchpad it might be due to a known bug, for example:

2035815 - Firefighter ID (FFID) is shown locked in EAM launchpad, even though no firefighter user is using the same FFID

Co-existence of firefighting models

Both models could be used. The decentralized firefighter configuration doesn’t block the centralized firefighter approach. Since you can start only one firefighter session at a time, you cannot use both at the same time and this is automatically controlled by the application.

Administration functions

The administration functions are maintained in the GRC Box. The decentralized firefighting adds a couple of tasks in the plugin system such as logging notification customizations and the possibility to extend the validity date of firefighters if the GRC Box is down. You’ll find a nice illustration in the guide attached to note mentioned earlier (1690964).

Access to decentralized FF

Some standard roles do not include the correct SPM transaction. In order to start decentralized FF the Firefighter user have to type /n/GRCPI/GRIA_EAM in the transaction bar. If you use other tcodes might see an empty table, and if you don't use /n you'll receive a message stating something like it's impossible to execute this function.

GRC 10.1 - What's new for EAM??

In GRC 10.1 a new option is included in order to set the Firefighter ID Role (parameter 4010) in a system-independent manner.

SPRO documentation:

"This allows you the flexibility of specifying different firefighter ID roles per plug-in system.

For example, you can specify the following:

For Target Connector ERP_001, the firefighter ID role is Z_SAP_FF01.

For Target Connector ERP_002, the firefighter ID role is Z_SAP_FF02.

If you choose to not use this option, the application uses the role name specified in the configuration parameter Firefighter ID Role Name 4010 for all systems including plug-in systems"

Please share your thoughts, comments or documentation in order to improve this guide.

Well folks, that’s all. Hope this document has helped you to successfully configure GRC EAM

Cheers!

Diego.

Purpose

The purpose of this document is to provide a list of the top 10 most viewed SAP KBA's for GRC Process Control in the month of October 2014.

Overview

Below are the top 10 most viewed SAP KBA's for GRC Process Control

Please note, in order to view the contents of the Knowledgebase Articles (KBA), you will need to be logged into Service Marketplace

Purpose

The purpose of this document is to provide a list of the top 10 most viewed SAP KBAs for GRC Access Control in the month of November 2014.

Overview

Below are the top 10 most viewed SAP KBAs for GRC Access Control

Please note, in order to view the contents of the Knowledgebase Articles (KBA), you will need to be logged into Service Marketplace.

Purpose

The purpose of this document is to provide a list of the top 10 most viewed SAP KBAs for GRC Process Control in the month of November 2014.

Overview

Below are the top 10 most viewed SAP KBAs for GRC Process Control.

Please note, in order to view the contents of the Knowledgebase Articles (KBA), you will need to be logged into Service Marketplace.