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 not 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:
Click here:
And:
You can just name them as Z_<full standard role name> or use a naming convention according to your company requirements.
Access to the NWBC: http://<server>:<port>/nwbc/ or execute tx. 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:
Once you have executed the auth & repository sync job with the corresponding target connector, the FF ID will be available for selection in the GRC Box.
See also Note 1668255
…
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:
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
"Yes it is mandatory to make a trusted relationship so that communication can be established between the GRC system and the plug-in."
Note 1747283 - EAM: Entries in EAM logon pad not Visible for a firefighter
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!
WARNING: THE FOLLOWING PROCEDURE ISN’T PROPERLY DOCUMENTED. I’LL ADD INFORMATION OR CHANGE THE PROCEDURE AS SOON AS NEW GUIDES ARE AVAILABLE.
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 recommend to create a new RFC destination in DEV, QAS and PRD system with the same name, let’s say “GRC_CONNECTOR”. This will allow you to transport the configuration throughout your entire landscape.
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
Log-in notifications are sent from the plug-in system:
But, as with the decentralized approach, Log notifications are sent from GRC Box
These requires a proper mail configuration (tx. SCOT) in both systems: plug-in and GRC Box.
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.
The authorization added to the role SAP_GRAC_SUPER_USER_MGMT_USER isn’t properly documented by SAP yet. It might be another way to configure it...but this was the same approach used in GRC 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
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.
In GRC Box, execute transaction SPRO and navigate to here:
The following parameters should be set according to the table:
Parameter
|
Recommended value (for initial configuration)
|
4000‐Application type
|
1
|
4001‐Default Firefighter Validity Period (Days)
|
30
|
4002‐Send Email Immediately
|
YES
|
4003‐Retrieve Change Log
|
YES
|
4004‐Retrieve System log
|
YES
|
4005‐Retrieve Audit log
|
YES
|
4006‐Retrieve OS Command log
|
YES
|
4007‐Send Log Report Execution Notification Immediately
|
YES
|
4008‐Send FirefightId Login Notification
|
YES
|
4009‐Log Report Execution Notification
|
YES
|
4010‐Firefighter ID role name
|
Chose a role name, for example
Z_SAP_GRC_SPM_FFID
|
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
Current direct link:
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
Current direct link:
Adding connector to the SUPMG Scenario:
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:
SAP_GRAC_SUPER_USER_MGMT_OWNER
|
Emergency Access management owner
| |||
SAP_GRAC_SUPER_USER_MGMT_CNTLR
|
Emergency Access management controller
| |||
SAP_GRAC_SUPER_USER_MGMT_USER
|
Emergency Access management firefighter
| |||
SAP_GRAC_SUPER_USER_MGMT_ADMIN
|
Emergency Access management administrator
| |||
|
Gives basic authorizations required for all AC users. You must assign this role to all AC users.
| |||
|
| |||
CAUTION: Please, follow he instructions provided in tha attachment of note:
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).
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.
Creating central Owners and controllers:
Go to the “Setup” tab and:
Create entries for the Firefighter controller and owner:
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.
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:
- 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 auth & 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:
Here you assign the Firefighter ID to the corresponding Firefighters users (one or more)
And in the controller tab set the controller user:
Firefighter colector Job:
Execute tx. GRAC_SPM_LOG_SYNC and schedule the log collection periodically as per note: 1617529
Known problems with time zones:
Known problem when connector is set to “*”:
Performance problems:
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
E-mail configuration:
If you want the controller to receive e-mails (firefighter logon 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
Required RFC connections for EAM:
Please check: Note 1701047 - Is it mandatory to use trusted connection in the RFC destination for Firefighter Connector?
Links to more documentation:
!!NEW: Decentralized firefighting (as in GRC 5.3) is available as of SP10
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.
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!
In order to sync this data with the plug-in, a new job is available and can be found here:
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 recommend to create a new RFC destination in DEV, QAS and PRD system with the same name, let’s say “GRC_CONNECTOR”. This will allow you to transport the configuration throughout your entire landscape.
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.
You should add the following authorization to it:
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.
The authorization added to the role SAP_GRAC_SUPER_USER_MGMT_USER isn’t properly documented by SAP yet. It might be another way to configure it...but this was the same approach used in GRC 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.
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.
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.
No comments:
Post a Comment