Skip to Content
avatar image
Former Member

Restricting SE16 access to HCM "/BIC/" tables in a BI 7.0 system

This is our scenario.

- We are already live on BI 7.0

- We will soon be implementing SAP HCM and will also be transferring HCM data to BI for reporting purposes.

We have a large number of SAP Support and Project technical staff (100+) and all have access to data browsers such as SE16. However, only a restricted number of technical staff should have access to HCM data via SE16. This is easy to implement in a HCM system because we know the table auth groups that SAP assigns to HCM tables. Hence, we can restrict SE16 access to HCM data using the auth object S_TABU_DIS.

In a BI system, InfoProviders have a corresponding underlying table that is accessible using SE16. The tables are all named starting "/BIC/" (we are not using standard business content cubes, so I am ignoring the tables named "/BI0/"). When SAP creates the "/BIC/" table, the table auth group is set to blank. Hence, anyone with access to SE16 can browse data in these tables, even the ones containing HCM data.

So, I am looking for the SAP recommended approach to securing SE16 access to the HCM related "/BIC/" tables.

One possible option is to use SE11 and manually update the table auth group. However, this doesn't seem appropriate because I think SAP automatically maintains the "/BIC/" tables in each system whenever the InfoProvider is transported.

Regards,

Richard Cooper.

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • avatar image
    Former Member
    Sep 23, 2009 at 06:47 AM

    That's easy to answer, but considerably more difficult to actually do in the wild.

    > Hence, anyone with access to SE16 can browse data in these tables, even the ones containing HCM data.

    This is not correct, or at least misleading.

    When a table is not assigned, the empty space is replaced with the symbolic value '&NC&' by the data browsers (SE16, etc etc). This means "Not Classified" --> all tables without auth groups have not (yet) had their data classified to find the correct level of protection for them.

    Simply remove '&NC&' from the S_TABU_DIS authorizations of the users, and if anyone complains that they cannot display a table anymore which they previously could, then you need to classify it (i.e. assign it to a group).

    > One possible option is to use SE11 and manually update the table auth group. However, this doesn't seem appropriate because I think SAP automatically maintains the "/BIC/" tables in each system whenever the InfoProvider is transported.

    Why don't you let them use RSA1 to browse the data? Here the new Analysis Authorizations will be checked, so you can re-use your existing concept without having to re-invent another one for direct table access and run both in parrallel.

    Cheers,

    Julius

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      BTW: Have you tried creating a transaction couple in SE97 between your BW transaction context and SE16. You can then maintain a "No check" indicator for it.

      It does not work in all cases, but most do.

      Cheers,

      Julius

  • avatar image
    Former Member
    Oct 13, 2011 at 06:22 PM

    Sorry this is late but I came across this while searching for an answer on another topic. We customized a solution with an SAP consultant, because our HR absolutely refused to allow a few technical people to have access to any HCM data.

    When our BI team creates any new info object part of the process is to inform security and if it is for HCM, we add it to a custom table. The table contains the infoobject name, version, and what auth groups we want the generated tables to be associated with. (These tables are generated with different names in each progression of the landscape.) We transport this table up the landscape (whats the point of securing production if you don't QA?) Then along each point of the transport we run a customized program that assigns auth groups appropriately.

    The draw back, TDDAT looks different per system, however, as seen with this question, it doesn't look like a great solution is availiable.

    Funny someone mentions (blank) auth groups that do not default to &nc& in this thread, as that is what I am looking for information on.

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      Someone necro-posted this thread without adding any useful infos, which is why it appeared again...

      Note that since then there is also object S_TABU_NAM and in RSA1 the analysis authorizations are also checked for access to the data.

      Cheers,

      Julius

  • avatar image
    Former Member
    Jan 05, 2015 at 12:20 PM

    This message was moderated.

    Add comment
    10|10000 characters needed characters exceeded