GRC 10.1 - Firefighter Error - User cannot be assigned as firefighter

[former_member316191]

Hi All,

We are working on a fresh implementation of GRC 10.1 support pack 15, during which we are facing an issue while assigning a firefighter ID to a firefighter User. The system doesn't allows us to assign the FF ID to the FF User and throws an error message 'User cannot be assigned as firefighter'

I have gone thru the complete setup and have ensured that the Firefighter users are not the owner/controller. I have looked into the below discussion and couldn't find an answered solution.

https://archive.sap.com/discussions/thread/3952527

Also our EAM setup is decentralized, I will not be able to assign the authorization GRFN_USER (ACTVT 16) to my FF users as my FF users exist in the target system only and not in the GRC system and the object GRFN_USER doesn't exist in the target system or in the SAP delivered EAM user role. Does this mean even for decentralized EAM setup the FF users should exist in GRC also?

I really appreciate your input on this.

Thanks

Narsimha R Katipally

[former_member279014 · Accepted solution]

I solved this one, at least for me. So just in case my situation matches yours, here's the data ...

I had this problem under GRC10.0 using EAM decentralized for over 4 years and noticed it after moving from SP13 to SP24 on the central system (back-end was already up-to-date). Something related to all this changed somewhere in those SPs.

I made a change to a Firefighter(FF)-user relationship. There were 2 users on the FF ID; one should come off and be replaced with a new one. But when attempting to save the change, GRC would not save because of the 2nd user (which was already there for years) and GRC gave an unhelpful, non-descriptive error message, "User cannot be assigned as firefighter." This was not the same message as when trying to assign a Controller of an FF ID as a User of that same FF ID. So, I was forced to take the other existing user off to make the change and troubleshoot from there.

The user with the error had the same role in the back-end system as the new one I just added, and as others I could still add.

The user was a Controller for some other FF IDs but definitely not for this FF ID.

Ultimately, here's the reason:

In a decentralized environment, Controllers still need an ID in the central system in order to login and approve/reject the workflow after the fact. In the central system, this user had a role to be an EAM Controller but not a role for EAM User; this had previously worked, but no longer. Other Controllers I had no problem with also already had EAM User access centrally. Users without any ID in the central system only needed, and still only need, an EAM User role on the back-end.

What apparently changed was, if a user involved in a Save exists in the central system, that is being checked first now and can fail without checking the back-end/target system for permission. This is not necessarily "wrong," but it is a change to what it was and now it requires us to check the central system roles for EAM Users if they have an ID there.

NOTE: This problem was especially difficult to search and obtain info on because it is so specific and lesser used: decentralized GRC, after a certain recent(?) Support Pack, only affects Controllers/central users without explicit EAM User access on their GRC central ID.

I don't know if that is the same scenario for Narsimha or anyone else here, but this worked for us and our user is happy again.