cancel
Showing results for 
Search instead for 
Did you mean: 

Centralized Firefighting : Access to GRAC_SPM

Former Member
0 Kudos

Hi Experts,

As we all know with GRC 10.0 the E&HP has been centralized, this means anyone who need to use the Firefighter ID need to have access on the GRC 10.0 system. This was not the case on 5.3 as FFid were managed in the individual backend systems.

  • This a big change with the regard to end user , as now he/she need to manage additional login details for the GRC system , since he/she is meant to use the GRC system may be couple of times a year , there is a high probability that they may forget the login credentials when in need.
  • It also means teams managing the access on GRC system will now have to manage additional users on the system which can go upto (in our case) 1000+ users as the whole support organization is enabled to request for FFids.

So my question here is , did any of you face a similar problem , what is the best way to manage this.

Some initial thought :We use LDAP as our data source , so is it possible that any user on LDAP can access GRAC_SPM tcode ,without actually creating and managing the user via SU01.

Thanks ,Ranjiv

Accepted Solutions (0)

Answers (4)

Answers (4)

Former Member
0 Kudos

Hello All,

For the centralized firefigther it is possible another persone (eg:DSI) make the request on behalf of another user? Because we have a team that are responsible to requests.

If we make the process with the own user to request, the behavior is correct, but if DSI request it isn' t possible.

Could you help me?

Regards,

Inês

Former Member
0 Kudos

Hi Ranjiv,

Further to Rajesh's comments above, GRC Access Control 10.0 SP10 or higher allows users to utilise the FireFighter component the same way they did when they were using the version 5.3 FireFighter (de-centralized).

SP10 or later allows the GRC team the option of choosing centralized FireFighting (logging into the central GRC system and then from there connecting via RFC to target systems) or de-centralized FireFighter (where they can access the FireFighter component from the target system just like in 5.3)

There are some small differences from a users perspective if the choice of de-centralized FireFighter is chosen. The user will now need to execute /GRCPI/GRIA_EAM transaction (replacement of 5.3 /virsa/vfat) and the new 'addtional activity' features allows users to maintain there actions anticipated field whilst using the FireFighter functionality.

To set up decentralized FireFighter, you must first configure the GRC system for Centralized FireFighter (maintain the config settings) and then switch to de-centralized FireFighter where you will need to maintain some config settings on the target system.

Hope this helps

Chris

Former Member
0 Kudos

Hi Ranjiv,

On which SP you are?

On SP10, users need not login to GRC 10 system and they can directly login to system in which         access is needed.

Hope this resolves the issue.

Regards,

Rajesh

Former Member
0 Kudos

Hi Ranjiv,

Have not found alternate way of getting access to firefighter in GRC 10. User account has to be created.

Initial Load of the users have to be managed by the security team. After that using workflows to create users and request access on GRC systems. Password self-service for the password issues after this.

SSO is still the best option to avoid password issues, if you have it.

Regards,

Ajesh.