Fflog Upload Says Log Contains No Fights

Howdy!

Configuring EAM in GRC 10 isn't a difficult task, just there are some details you take to take into account. The document "Air-conditioning 10.0 Pre-Implementation From Post-Installation to First Emergency Access" is useful, merely it doesn't  consider all the details. Here I'll try to requite you a complete explanation about how to configure EAM successfully.

Configure Parameters:

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

The following parameters should be set according to the tabular array:

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

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

Yous 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 exist included in a ship asking, yous should release the transport to your QA/PROD systems when yous cease the EAM tests and adapt the parameters according to your requirements.

Parameter 4010: What's for?

If you've been working with GRC five.three, this parameter should sound weird to you.

The purpose is to place to the application that the user who is logging on to the target organisation is a Fire fighter ID. The target system makes a telephone call to the GRC Box and reads this configuration to cheque if the user has this role assigned to them.

That ways that you have to create the part that you've set in parameter 4010 in all the target systems with the exact name provided there. Unremarkably, you re-create it from the standard SAP_GRC_SPM_FFID (information technology contains RFC authorizations).

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

Kindly check annotation: 1668255 – Firefighter ID role name for Param ID 4010

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

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

Adding connector to the SUPMG Scenario:

Delight check: Notation 1562760 – AC10.0 – Intergration Scenarios to Connector link

At this bespeak you have already created the connectors.

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

Click hither:

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 demand at least to create a copy for the post-obit roles and generate the corresponding profiles:

You can just name them equally 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:

Annotation 1663949 – EAM Say-so Fixes for Central Owners and Reason Codes

There are some changes you lot take to made to the standard roles and also at that place's a consummate explanation of the authorization objects.

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

Security considerations for EAM Roles:

Kindly read a specific say-so guide for EAM that is fastened to the note:
Annotation 1663949 – EAM: Authorization Fixes for Cardinal Owners and Reason Codes

and take into business relationship the authorization concept for the roles:

1730649 – Firefighter possessor can assign Whatsoever Firefighter ID to Firefighter User

"As per the functionality in AC10, nosotros have concept of role based authorisation. If a user is having SAP_GRAC_SUPER_USER_MGMT_OWNER  part at the backend, and so he  should be able to assign whatever 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 exercise all available owner action for all connector.
The Auth. Object used for fire-eater Maintenance is GRAC_FFOWN & GRAC_OWNER"

—->>> vote for a simpler style if you disagree with this weird role-based model !! –>>> Elementary setting for EAM owner/controller authorization

If you are not going to apply 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 testify a sample for testing, Information technology'south necessary to create (or use existing ones) three users:

FF_OWNER : This user will serve as possessor for the fire-eater ID. It should exist assigned to the role Z_SAP_GRAC_SUPER_USER_MGMT_OWNER

FF_CONTROL: This is the fire-eater controller. Y'all assign Z_SAP_GRAC_SUPER_USER_MGMT_CNTLR.

Circumspection: This user MUST have a valid eastward-mail accost maintained in SU01 if y'all want the controller to receive notifications via east-post.

Firewoman: This is the fire fighter user, who will exist able to access in the target arrangement with the Fireman ID. You assign Z_SAP_GRAC_SUPER_USER_MGMT_USER in add-on to the base roles. If y'all don't assign the base of operations roles you lot won't see the user (Fire fighter in this case) bachelor for choice in the Firefighters IDs.

<your user>: The user who is going to perform the configurations, must accept at to the lowest degree the office Z_SAP_GRAC_SUPER_USER_MGMT_ADMIN assigned.

In add-on 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 organisation:

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

Circumspection: The proper name of this role MUST be the same configured in the parameter 4010 in the GRC Box. In this case: Z_SAP_GRC_SPM_FFID.

Required users in the target system:

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

This user should be of blazon: "Service" as per note 1702439

The following note describes an consequence you'll face with this kind of users: Annotation 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 consequence.

Take into account this of import notation for service users: 1945098 – Service users are not considered in decentralized firefighter

Creating central Owners and controllers:

Admission 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 Fire-eater controller and owner:

Creating reason codes:

Y'all accept to create at least 1 reason code to be able to use the firefighter ID after.

Associate the entry to the respective target system.

Synchronization Jobs:

In accord with annotation: 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 Fire-eater 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 lawmaking SPRO => Governance, Risk & Compliance => Access Control => Maintain Configuration Settings

three. Run User/Part/Profile/Auth synchronization jobs. The Link to run these jobs tin can be found Nether transaction code SPRO => Governance, Risk & Compliance => Access Command => Synchronization Jobs.

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

Run across besides Note 1668255

…One time you lot are done with the above steps, re-run an Incremental/Full User Sync for the Fire-eater 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 Fire fighter ID and this should be available in Firefighter ID listing.

                          …

Assign Owners:

Assign Firefighter IDs to Firefighters

Here y'all assign the Firefighter ID to the corresponding Firefighters users (one or more)

And in t h eastward controller tab prepare the co ntroll er us er:

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 hither 1744929 – Mass Upload of Assignments for EAM

As well check the post-obit note if you lot 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 Chore:

Execute tx. GRAC_SPM_LOG_SYNC and schedule the log collection periodically every bit per annotation: 1617529

Known problems with time zones:

Notation 1595462 – Logs non visible in the SPM Reports

Note 1775432 – Transaction logs are non getting captured by GRC ten.0

Known problem when connector is set to "*":

Note 1726157 – GRAC10 EAM GRAC_SPM_LOG_SYNC_UPDATE doesn t collect data

Performance problems :

Annotation 1750024 – GRAC – Operation of the SPM Log Sync

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

Other errors:

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

Note 1776070 – GRC EAM plan is giving a short dump and no logs generated

Note 1731923 – EAM:Transaction Logs are not existence captured while sync

Have you lost EAM logs?

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

1934127 – GRC10 EAM: EAM recovery plan to retrieve missing log and to generate the missing workflows

E-mail configuration (Centralized Firefighter):

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

• Brand certain your Ground team has properly configured outgoing e-emails from GRC Box (Tx. SCOT)
• Controller notification method was prepare to: Email (see above)
• SPRO parameters:

4002 Send Eastward-mail service Immediately Aye

4007 Send Log Report Execution

Notification Immediately Yep

4008 Ship FirefightID Logon Notification Aye

4009 Log Written report Execution Notification Yes

• Controller user (FF_CONTROL) has "Comm.Method" set to "E-Mail" in SU01 and has a valid email address.
• WF-BATCH User must as well have an e-post address in SU01; otherwise you lot'll get the following mistake in tx. SLG1:

Co-ordinate to the configuration settings guide:

You lot can modify the parameter and use another user to transport the due east-mails.

Later on executing the GRAC_SPM_LOG_SYNC_UPDATE, please execute tx. SOST and check if the e-mails were generated (y'all have to access the firewoman to get the e-mails).

Implement Fireman user Leave:

Despite the Fire-eater ID password is inverse by the application each time you showtime the firefighter (you tin can check information technology via modify documents in the target organisation), Fire fighter Ids need to exist 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 Go out.

Cheque

1545511 – Firefighter User Exit

1735971 – User exit to prevent direct firewoman login

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

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

Required RFC connections for EAM:

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

"Yes information technology 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 (encounter comments below). The notation is for Centralized FF and true is that information technology works anyway with not trusted connectedness. In case of decentralized model the connector is used to call back logs, so it doesn't demand to be trusted.

Links to more than documentation:

Note 1394281 – Superuser Privilege Management Log Study Content

Notation 1065048 – Firefighter Log Not sent in Electronic mail to Controller <<- for 5.3, merely useful

Notation 1618040 – Performance fix for SPM transaction logs for big systems

Note 1732938 – Firefighter incorrect language setting on ERP Production

Note 1730649 – Firewoman possessor can assign Any Fire fighter ID to Firefighter User

Note 1747283 – EAM: Entries in EAM logon pad not Visible for a fire-eater

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

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

The most important advantage of decentralized firefighting is that you tin go on using firefighter fifty-fifty when the GRC Box is down. In my opinion, information technology'southward likewise more than "convenient" since the firefighter doesn't accept to log on to GRC Box in order to start the firefighting session, he/she merely 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 virtually of import thing is that with SP10 you have to option to cull and beneath you'll discover information that'll help yous to configure decentralized Firefighting.

The idea of a decentralized firefighting wassubmitted by Daniela Bork on SAP Idea Identify: Access Fireman application locally in AC10

So, if you lot take a skilful Thought, please share it with SAP customers and employees in the Idea Identify and maybe it becomes a new functionality!

Primary documentation can exist constitute in the guide fastened to the note: Notation 1690964 – Emergency Admission 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 ready to the value "Yep"

Additionally a new synchronization task is bachelor and must exist executed in lodge to synchronize the EAM information from GRC Box to the plug-in system. Remember that configurations (firefighter assignments, controllers, owners, reason codes, etc.) are still maintained in a centralized fashion, i.e in the GRC Box.

In order to sync this information with the plug-in, a new task is available and can be institute here:

In the connector field you have to set the corresponding plug-in connector.  In lodge to keep you lot 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, y'all should follow the same approach as with the log synch: create individual jobs for each connector instead of a unique chore with connector value "*".

Configuration in the plug-in organisation

In the plug-in system you lot'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 oasis't  set the parameter 1000 in the plug-in organization, you'll have to exercise it in order to utilise decentralized firefighting, otherwise yous'll get an mistake message as described here: 1800772 – Error 'No Destination specified' when using transaction /GRCPI/GRIA_EAM

Then, cheque the parameter every bit described below:

If the parameter thousand isn't nowadays you have to create it and ready the value to an RFC destination pointing to the organization 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, allow's say "GRC_CONNECTOR" and transport the configuration throughout your entire mural. Merely nowadays, this parameter is used in the log-in notification electronic mail to the controller, and if you are going to employ that functionality yous might desire to create a organization name independent connector, i.eastward. "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 merely has to point to the correct system/case and a specific client.

Required users

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

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.

Email considerations (Decentralized model)

Log-in notifications are sent from the plug-in system (the e-mail is sent with the Fire-eater user, so recollect to properly configure information technology in SU01):

Merely, 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 eastward-mail service in decentralized EAM:

1877706 – Login and Log Written report Notifications are not existence sent to the firewoman 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 post-obit authorization to it:

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

This office is assigned to the fire fighter users. Bear in listen that these users should not have access to user maintenance transactions, for example SU01. If the firewoman IDs are properly assigned to a group and you lot can restrict the CLASS field this is not a large upshot, since despite they could change the password, they won't exist able to access considering the user exit is implemented in club to forestall it.

This extra potency 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 comprise this solution as unofficial, but now has become official.

"..The firefighter is not having the authorisation to change the passowrd. In centralized firefighting the password is inverse by RFC user, only in decentralized version as in that location is not RFC connection, the password is changed by firefighter. The functionality works as in EAM 5.3…."

In addition to this function you also have to create roles for administrator and owner. Call up that extending the validity period is a new activeness bachelor in the plug-in organisation and owners and administrators should take admission to it.

Known Issues ( 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 Consequence: Logon screen appears when starting FF session

It's possible that we go 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 authorisation cheque 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.
• Cheque 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 alter the password of the Firefighter ID each time you log-on from the launchpad, the CUA's initial password needs to be fix equally 'Everywhere' or 'Proposal'. Please bank check point 6 of note 1861981 – Things to check when error message 'Mistake in opening RFC destination' appears in GRAC_SPM
• Have a look at the post-obit notes:

1861981 – Things to check when error bulletin 'Error in opening RFC destination' appears in GRAC_SPM

1777094 – EAM log on is non possible with the fault: 'Fault found in RFC (plug in arrangement) and respective logon\logons are disabled'

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

Notation 1872709 – Logon popup shown when launching the EAM session

Common Consequence Ii: Logs are not getting captured

If you cannot get the FF Logs don't become frustrated. This is non unusual. I'll give some tips (and hopefully you lot can help in society 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 authority effect with the RFC      user. The usual ane is related to object S_TOOLS_EX every bit described 1916172 – User Action Usage Sync Error – User ID showing as — ? — . Anyway you tin can trace the RFC user via ST01 in the back-finish while performing a log synch and cheque 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 Organization -> Status at "the same time" in both systems. A clock skew of 1-two minutes tin can cause severe issues in the log collection. Time zones do not need to be same… information technology doesn't make sense by the way, cause having the GRC box in a Server in India and the ECC in Argentina will exist impossible. Even here in Due south America we ordinarily piece of work with Servers in Republic of chile, Brazil, Argentine republic and these countries sometimes do not use the aforementioned fourth dimension zone. So…using dissimilar time zones has to be a possibility, but you lot have to be very careful with the clock skews, and if you lot have differences ask your Server Admins to bank check information technology and employ a NTP Sever to keep all systems synched.
• Bank check that y'all have information in transaction STAD and ST03N  in the plugin system for the FF ID yous're trying to get the logs. If necessary bank check with your Footing team if the Statics are being collected  properly.Endeavour executing an action usage synch and check in table GRACACTUSAGE if you have information for the FF ID.
• Recall to schedule the job hourly equally per SAP  recommendation an not running it just when y'all desire to get the logs. This probably will crusade lose of data.
• Check transaction SLG1 in the GRC Box in order to know   the consequence of the collection. Sometimes you get there the exact cause, for instance "RFC Timeout", "RFC error", etc.
• Check for dumps in the plugin system (transaction ST22) and wait 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. But to name one of them that isn't included in
  the latest SP: 1962440 – GRC EAM – Change Log Drove Operation Enhancement simply you'll find others in the marketplace an probably SAP will release more than. Brand certain you accept all the corrections applied.
• A last resort when y'all have problems with log collection (due to operation) 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 tabular array in instance of  time out issue due to huge data Creating an index on such table is something that you have to hash out with your DBA, Basis and Development teams. You lot accept to be very careful with that and y'all should ask SAP if this is recommended to your scenario and in that location're no chances to meliorate the queries in the code. The table stores change documents and too tin exist reduced via archiving and this should be also an option to talk over before creating an index.
• SAP released a annotation recently indicating that mass activities cannot be performed by Firefighters: 1378276 – Mass Transaction back up through Firefighter product

Common Effect III: Firewoman 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 up (check SM04 in the plugin organisation) but the FF is still locked in the launchpad it might be due to a known issues, for example:

2035815 – Fire-eater ID (FFID) is shown locked in EAM launchpad, even though no fire-eater user is using the same FFID

Co-existence of firefighting models

Both models could be used. The decentralized fire-eater configuration doesn't block the centralized firewoman approach. Since you tin can start merely one fire-eater session at a fourth dimension, you cannot use both at the same time and this is automatically controlled by the awarding.

Administration functions

The administration functions are maintained in the GRC Box. The decentralized firefighting adds a couple of tasks in the plugin system such equally 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 fastened to note mentioned earlier (1690964).

Access to decentralized FF

Some standard roles practise not include the correct SPM transaction. In society to start decentralized FF the Firewoman user take to blazon /due north/GRCPI/GRIA_EAM in the transaction bar. If you lot utilise other tcodes might come across an empty table, and if you don't utilize /n you lot'll receive a message stating something similar it's incommunicable to execute this function.

GRC 10.1 – What'due south new for EAM??

In GRC 10.ane a new option is included in order to prepare the Fire-eater ID Office (parameter 4010) in a system-contained style.

SPRO documentation:

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

For example, you lot can specify the post-obit:

For Target Connector ERP_001, the fire fighter ID part is Z_SAP_FF01.

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

If you choose to non 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 gild to meliorate this guide.

Well folks, that'south all. Hope this document has helped you to successfully configure GRC EAM 😉

Cheers!

Diego.

garlinghichly.blogspot.com

Source: https://blogs.sap.com/2012/11/03/configure-emergency-access-eam-in-grc-10/

Share this post