Вы находитесь на странице: 1из 33

ACTT for SAP

Advanced document for ACTT usage on SAP engagements

ACTT SAP Team - Ann Paul Sara, Jagadish Bhandaru, Krishna Vogeti
Contents
ACTT SAP RULE TEMPLATE...................................................................................................................... 3
RULE TEMPLATE FEATURES..................................................................................................................... 4
SYSTEM SCOPING ............................................................................................................................ 4
MULTIPLE SYSTEM SCOPING ........................................................................................................ 4
CROSS SYSTEM SCOPING ............................................................................................................... 5
BUILD RULES............................................................................................................................................ 6
ACTIVITY GROUP & SUB-GROUP CONCEPT ............................................................................... 7
GROUP CONCEPT ............................................................................................................................. 7
SUB-GROUP CONCEPT .................................................................................................................... 7
“*” & “BLANK” VALUES .................................................................................................................. 8
PERFORMANCE ................................................................................................................................ 8
EXCLUDE/INCLUDE USERS, ROLES, USER TYPE ......................................................................... 9
ORGANIZATIONAL VARIABLE SCOPE ......................................................................................... 10
CC RULE VARIABLES ...................................................................................................................... 11
ADAVANCED OPTIONS ................................................................................................................. 12
PROCESSING OPTIONS ................................................................................................................. 13
DATA EXTRACTION ........................................................................................................................ 15
DATA VALIDATION ................................................................................................................................ 16
NUMBER OF TABLES ..................................................................................................................... 16
DISTRIBUTED ACCESS BEHAVIOR .......................................................................................................... 17
USER VIEW ...................................................................................................................................... 17
ROLE VIEW ...................................................................................................................................... 17
SOD KEYSTONE REPORT ........................................................................................................................ 18
INFORMATION ............................................................................................................................... 18
SUMMARY REPORT ....................................................................................................................... 19
ROLE MATRIX ................................................................................................................................. 22
USER MATRIX ................................................................................................................................. 22
USER ROLE RELATIONSHIP .......................................................................................................... 23
ALL VIEWS WITHIN RULE SHEETS .............................................................................................. 23
CC KEYSTONE REPORT........................................................................................................................... 26
EXPORT REPORT .................................................................................................................................... 28
UNICODE SUPPORT ............................................................................................................................... 29
CONSIDERATIONS ................................................................................................................................. 30

1
LEGACY TEMPLATES .............................................................................................................................. 30
TROUBLESHOOTING .............................................................................................................................. 32

2
ACTT SAP RULE TEMPLATE
The ACTT SAP rule set includes a set of risks that come standard with ACTT. The rule set is compared
to the SAP security setup to analyze how many rules have been violated within the roles and users.
The output of the analysis provides information regarding the depth of related control deficiencies.

The rule set has not been tailor-made for any single industry or organization. Instead, it has been
developed along standard SAP business processes and transactions that represent industry’s best
practices. There may be certain risks which are not applicable to your organization and there may be
other risks that need to be added. Therefore, based on the relevant organization’s security strategy,
rules can be included or excluded. However, the standard rule set is often applicable to many of the
clients for which ACTT is used.

There are two types of rule templates available: the audit rule template for attest engagements and
the relationship rule template for non-attest engagements.

The audit rule set has been developed based upon the collusion concept: any user who has the
capability to perform a complete cycle of activities will be identified in the audit SOD rules.
Advantages of leveraging the audit rule template include:

 The number of attest SOD rules may be reduced dramatically—both simplifying the results
and making them more relevant
 Many high risk rules will have more than two SOD legs
 GCC rules are developed in congruence with the SAP Basis framework released by the US
FS&ICA team

3
RULE TEMPLATE FEATURES
This section covers the various features available within the ACTT rule template for performing
analysis.

SYSTEM SCOPING
Click on the “Scope” link next to “Systems” to scope the application name and version details.

MULTIPLE SYSTEM SCOPING


ACTT provides an option to scope in multiple applications. If the engagement team wants to perform
the analysis of two or more SAP applications, they can scope the applications in the rule template by
providing the application details as shown below. Results will be captured in one Keystone report for
both the applications.

4
CROSS SYSTEM SCOPING
ACTT also has the capability to perform a cross application SOD analysis. Suppose a client has
implemented the Oracle financials module as well as SAP for other modules and the engagement
team would like to perform the controls testing. The team can run ACTT for both the applications.
Results showing SOD conflicts across systems will be available in one Keystone report for both
applications.

Note that in order to perform a cross application SOD analysis, system users must be mapped in the
rule template so that access of the same users in different systems is correctly considered.

5
BUILD RULES
Click on the “Scope” link next to “Rules” to view, edit, and/or create new rules and corresponding
activities. Clicking on the link will navigate you to the ‘Rules” sheet.

Click on the ACTT tab on the top ribbon and click the “Show SOD Activities” button to access the
“SOD Activities” sheet. This worksheet will have all the pre-defined activities with technical details
like T-Code and Authorization Objects. Make appropriate updates to the worksheet by adding new
activities or updating existing activities that correspond to the custom rule(s).

6
ACTIVITY GROUP & SUB-GROUP CONCEPT
The group and sub-group concept in the “SOD Activities” sheet provides a flexible and intuitive
approach for building custom rule sets.

GROUP CONCEPT
Group refers to a single query. It can consist of one or more T-Codes, Authorization Objects,
authorization fields and field values. In order for a user or role to have access to a specific activity,
they must have access to one or more groups in an activity.

SUB-GROUP CONCEPT
Sub-group logic defines the relation between the T-Codes, Authorization Objects, fields and field
values. The relation can either be an “AND” or “OR” relation. If the relation is an “OR” relation, the
sub-group number remains the same. If the relation is an “AND” relation, the sub-group number
changes.

After defining the activity, navigate to the “Rules” sheet. Fill in all the columns in the Rules sheet and
select the activity from the drop down in the “Activity” column.

7
Below is an example of sub-group logic. Wherever the number is repeated, it’s an “OR” relation and
wherever the number is increased, it’s an “AND” relation.

Maintain Data Dict 0 SE16N SE16N Display TCODE


Maintain Data Dict 0 N N Display TCODE
Maintain Data Dict 1 S_DEVELOP S_DEVELOP Display AuthObject ACTVT 01
Maintain Data Dict 1 S_DEVELOP S_DEVELOP Display AuthObject ACTVT 02
Maintain Data Dict 2 S_DEVELOP S_DEVELOP Display AuthObject OBJTYPE DEBUG

This query can be interpreted as follows:

(Tcode SE16N OR N) AND (S_DEVELOP ACTVT 01 OR S_DEVELOP ACTVT 02) AND (S_DEVELOP
OBJTYPE DEBUG)

“*” & “BLANK” VALUES


In the “SOD Activities” sheet of the rule template, the “Values” column should have the values given
to the Authorization field.

 If the field value is “Blank” (if no value is given for the field value item) it means access to
“ANY” values

 If the field value is “*” it means access to that query exclusively looks for ‘*’ in the role

Any All
SUIM Convention * “*”
ACTT Convention *

PERFORMANCE
Sometimes a group with many entries in an ‘OR’ relationship can result in performance issues. When
this happens, the recommendation is to split the group into multiple groups. For example, the query
below consists of many “OR” relationships within the single “MIGO” group.

8
Group Sub Technical Display Name Display in Type Field Value
Group Name Report?

MIGO 0 MIGO MIGO Display TCODE


MIGO 1 M_MSEG_BWA M_MSEG_BWA Display AuthObject ACTVT 01
MIGO 2 M_MSEG_BWA M_MSEG_BWA Display AuthObject BWART 101
MIGO 2 M_MSEG_BWA M_MSEG_BWA Display AuthObject BWART 102
MIGO 2 M_MSEG_BWA M_MSEG_BWA Display AuthObject BWART 103
MIGO 2 M_MSEG_BWA M_MSEG_BWA Display AuthObject BWART 104
MIGO 2 M_MSEG_BWA M_MSEG_BWA Display AuthObject BWART 105
MIGO 2 M_MSEG_BWA M_MSEG_BWA Display AuthObject BWART 106

Instead of having a single group for MIGO, we should split the group into several groups. The query
below is now split into several groups within the same activity.

Group Sub Technical Display Name Display in Type Field Value


Group Name Report?

MIGO_101 0 MIGO MIGO Display TCODE


MIGO_101 1 M_MSEG_BWA M_MSEG_BWA Display AuthObject ACTVT 01
MIGO_101 2 M_MSEG_BWA M_MSEG_BWA Display AuthObject BWART 101
MIGO_102 0 MIGO MIGO Display TCODE
MIGO_102 1 M_MSEG_BWA M_MSEG_BWA Display AuthObject ACTVT 01
MIGO_102 2 M_MSEG_BWA M_MSEG_BWA Display AuthObject BWART 102
MIGO_103 0 MIGO MIGO Display TCODE
MIGO_103 1 M_MSEG_BWA M_MSEG_BWA Display AuthObject ACTVT 01
MIGO_103 2 M_MSEG_BWA M_MSEG_BWA Display AuthObject BWART 103
MIGO_104 0 MIGO MIGO Display TCODE
MIGO_104 1 M_MSEG_BWA M_MSEG_BWA Display AuthObject ACTVT 01
MIGO_104 2 M_MSEG_BWA M_MSEG_BWA Display AuthObject BWART 104
MIGO_105 0 MIGO MIGO Display TCODE
MIGO_105 1 M_MSEG_BWA M_MSEG_BWA Display AuthObject ACTVT 01
MIGO_105 2 M_MSEG_BWA M_MSEG_BWA Display AuthObject BWART 105
MIGO_106 0 MIGO MIGO Display TCODE
MIGO_106 1 M_MSEG_BWA M_MSEG_BWA Display AuthObject ACTVT 01
MIGO_106 2 M_MSEG_BWA M_MSEG_BWA Display AuthObject BWART 106

EXCLUDE/INCLUDE USERS, ROLES, USER TYPE


During the scoping process, the rule template allows for the exclusion/inclusion of users, roles and
user types.

When a practitioner wishes to perform analysis for only a specific set of users, roles or user types,
the practitioner can include those users, roles or user types in the rule template. Only the values
specified will be considered during analysis. Likewise, if a practitioner wishes to exclude a set of

9
users, roles or user types from analysis, the practitioner can exclude the users, roles and user types
in the rule template. All values except those specified will be considered during analysis.

On the main tab of the rule template, click on the “Scope” link next to “Users and Roles”. If you
would like to exclude or include Users, Roles or User Types, add the respective User IDs, Roles or
User Types in the corresponding columns. From the drop down menus, select “Include All Except
These” to exclude or select “Exclude All Except These” to include. Please note that wildcard
characters are not considered, so specific values as they exist in the client data must be entered in
the template.

ORGANIZATIONAL VARIABLE SCOPE


The rule template has an option to scope organizational values. When the analysis for any specific
organizational value is desired, the relevant values can be specified in the rule template resulting in
analysis being performed for the relevant organizational variables. If no scoping is required, then
practitioners can leave the fields blank.

Click on the “Scope” link next to “Organization Values”. It will navigate you to the “Organizational
Variables” sheet where you can specify the organizational variable details.

Please note that there are a few points to keep in mind:

 ACTT will pick up the values defined for variables in the variable sheet of the rule template.
Example: $BUKRS = 0010
 ACTT will consider multiple values for organizational values separated by a comma (,). So
roles/users having access to multiple values will be included in the reports
 ACTT will consider variables only for rules and activities that have values specified in the SOD
Activities sheet of the template. For example, if an activity does not include a variable name

10
in the Value column, the variables specified in the Organizational Variables sheet would not
be applicable to the Activity/Rule.

Note: Specifying SOD variables may increase processing time significantly. Please consider
the impact upon the analysis being performed.

CC RULE VARIABLES

For configurable control rules CC ITGC 104 and 116 there is an option to specify variables in the “SOD
Variables” sheet of the rule template.

For rule CC ITGC 104, certain profile parameters are specified by default in the Variable Value
column. If additional parameters are required for the analysis, engagement teams can specify other
parameters in the column “Variable Value”.

11
For rule CC ITGC 116, 4 important SAP notes are included. If engagement teams want to check the
implementation status of additional SAP notes, they can specify other note numbers in the “Variable
Value” column.

ADAVANCED OPTIONS

Impact Ratings: There are three risk levels: “High”, “Medium” and “Low” based on the severity of
the risk.

A rule is defined as High risk when a single individual is able to execute end-to-end processing of a
transaction; this indicates a lack of control over the multiple steps within a single business process.
Typically in this scenario, a user can complete a whole process from initiation and authorization to
approval and execution without any checks or balances. When more than one individual is required
to execute a transaction, the rule is given a Medium or Low risk level.

Each conflict poses a different risk to the business and ideally, each conflict should be rated
according to the likelihood and impact of a user executing the conflicting transactions. The correct
assessment and definitions of risk ratings is a key factor in delivering benefits from a risk-based
approach. The ACTT SAP rule set and the severity levels are customizable and as per the
organizations’ security strategy, the rules and the severity levels can be modified.

Cycles: Practitioners can define the business cycles in scope of the analysis in the “Cycles”
worksheet.

Header Translation: Practitioners can provide the name of the column as they want it to appear in
the SOD Keystone report.

12
Show All Sheets: The “Show All Sheets” button in the ribbon enables the user to view all the sheets
in the rule template.

PROCESSING OPTIONS
The “Processing Options” sheet contains a listing of flagged items, some of which can be used by
engagement teams to change the processing and/or the output of the analysis that ACTT performs.
To navigate to this sheet, click on the “Advanced” ribbon and select the “Processing Options”
button.

Below are some of the items included in the “Processing Options” sheet:

 SAP_UFLAG (for User Lock codes): ACTT will exclude all users who are locked out based
upon the specified flag values.

 Perform Cross Auth Exclusions: ACTT will remove false positives when Authorization Objects
belong to different Sub-Profile numbers. By default, this flag is set to “TRUE”.

This processing option feature would be relevant when there are multiple instances of the
object in the same role. A user in the system obtains access through multiple instances of
the same object.

Rule Design:

13
User Access:
User SAP_TEST_11 is having below access

User Role T-Code Auth Object Field Field Value


ACTTROLESE54 SE54 S_TABU_DIS ACTVT 2
DICBERCLS FC
SAP_TEST_11
ACTTROLESE54_2 SE54 S_TABU_DIS ACTVT 3
DICBERCLS SVIM

Ideally, this user should not appear in the output report as this user does not have Change
access (02) to Authorization group SVIM. The “Perform Cross Auth Exclusions” flag removes
these types of users; when this flag is turned off (set to “FALSE”), users with this kind of
access will appear in the output report.

 Skip.dbo.Analyse_Method_of_Access: If set to “TRUE”, ACTT will skip the code that


determines whether an "X" or a "D" should be outputted in the Method of Access column of
the SOD Keystone report. In this case, an "X" will appear in all relevant results for the
Method of Access. By default, this flag is set to “FALSE” and the Method of Access is
considered. Refer to the Distributed Access Concept for more information.

 Include Roles with No Users: By default, this flag is set to “FALSE” and ACTT will exclude
roles without users. However, when this flag is set to “TRUE”, ACTT will create a fictitious
"Spurious" user for each role that doesn't have a user associated with it so that roles without
users will be displayed in the reports.

 Maximum Filter List Records for Single Rule: This is the maximum number of rows allowed
in the "Filter List" view section within an individual rule related sheet of the SOD Keystone
report. If the numbers of rows in the result are greater than the specified value, no records
will be displayed in the "Filter List" view section for that particular rule in the report. If a rule
returns fewer records than the specified amount, the filter list section will display all results
for that particular rule.

 Maximum Filter List Records for All Rules: The value specified is the maximum number of
rows for all the "Filter List" view sections of all rules in the SOD Keystone report. If the total
number of records returned for all rules is above this amount, no records will be displayed in
any "Filter List" view sections of the report.

14
 SAP Perform Profile Level Analysis: This flag is used to consider access through profiles
when performing analysis. If this flag is set to “False”, profile based analysis will not be
considered. This feature is currently available only in the 10 & 10.1 Versions. If table USR12
table is missing then this functionality may not work and the flag will be turned off
automatically.

DATA EXTRACTION
Multiple extraction methods like local download, download in App server and background mode are
included to improve performance based upon size of data.

Note: Please add “/” or “\” at the end of the file path in the “Enter File Path” field for
accurate file names while extracting data from the SAP system.

15
DATA VALIDATION

NUMBER OF TABLES
A total of 117 files are generated by the ACTT ABAP program when run for both CC (configurable
control) and SOD analysis. 113 of these table files are CC, SOD or SA related and the remaining 4 files
are configuration files that are used for analysis and reporting to display details like data extraction
date, report run date, number of tables extracted, etc. Data files are extracted in .actt format.

Note: The number of tables will change based on the version of the SAP extractor, the SAP systems
(CRM, SRM, BI, etc.) and the options selected when running the extractor.

16
DISTRIBUTED ACCESS BEHAVIOR
In the SOD Keystone Report, “X” indicates default access and “D” indicates distributed access.

USER VIEW
When a “D” is noted, the following is true:

 The user has multiple roles.


 The user has access to all the necessary objects and T-Codes, but the access is spread across
more than one role.
 While the user might not have complete access via one role to the required T-Code and/or
AuthObjects, the combination of access to relevant objects via multiple roles will show up as
access denoted with a "D" for partial access.
 All the users that have “D” access do have the SOD violation. The access associated with the
violation is spread across multiple roles.

Activity 1: T-Code ME21 and Object M_BEST_EKO ACTVT 01

In the example above, a user has access to two roles: Role 1 has access to a T-Code (ME21)
of Activity 1 of an SOD rule and complete access to Activity 2 of an SOD rule. Role 2 has
access to Authorization Object (Object M_BEST_EKO) of Activity 1 and complete access to
activity 2. In the output report, the user will be displayed as having “D” for Activity 1 because
the user has access from two different roles.

ROLE VIEW
When a “D” is noted, the following is true:

 The role has access to some of the necessary objects.


 The role will be a composite role. The access to all the required objects and T-Codes will be
obtained from multiple single roles within the composite role.
 The composite role does have an SOD conflict and all users assigned to this composite role
would be marked as an exception in the User View.

Activity: T-Code ME21 and Object M_BEST_EKO ACTVT 01

In the example above, a composite role has access to two single roles (1 and 2): single role 1
has access to T-Code (ME21) of the activity and role 2 has access to Authorization Object
(M_BEST_EKO) of the activity. In the output report, the composite role will be displayed as
“D” under the activity because the composite role has complete access from single roles 1
and 2.

17
SOD KEYSTONE REPORT
When the SOD Keystone report is opened for the first time, a pop up window will prompt you to
format the report. Click on the “Format the report” link. Once formatting has completed, save the
file.

INFORMATION
The information sheet includes the following sections:

 Instructions
 Processing Options
 Users – Included/Excluded
 Roles – Included/Excluded
 User Types
 SAP Org Value Scoping

18
SUMMARY REPORT
1) Violation Count Summary: This view provides a count of total rules, roles and users with
and without violations.

19
In the above example, 113 rules have 102 have violations and 11 rules do not have any
violations. Out of 754 roles, 89 have violations and 665 roles do not have any violations.
Out of 539 users, 496 have violations and 43 users do not have any violations. When
users or roles are being excluded/included, then the user and role counts will be
impacted by the users and/or roles provided in the exclude/include list.

2) Violation By Business Cycle: This view provides the net violations ( i.e. User-Role
combinations) per business cycle for each risk level.

In the above example, there are 527 High user-role violations within the expenditure
cycle.

3) Application Summary: This view provides the total number of User-Role violations.
These values are unique and do not contain duplicate values arising from the same
violation appearing across multiple business cycles.

4) Top 10 Roles with Violations: This view provides the number of roles with “High” risk
rule violations. These values are unique and do not contain duplicate values arising from
the same violation appearing across multiple business cycles.

20
5) Top 10 Users with Violations: This view provides the number of users with “High” risk
rule violations. These values are unique and do not contain duplicate values arising from
the same violation appearing across multiple business cycles.

6) Top Ten Rule Violations: This view provides the ten most violated rules.

21
ROLE MATRIX
The Role Matrix sheet provides a listing of roles/profiles that violate the given SOD or SA rule
completely. In other words, it shows the roles that have access to all legs of an SOD rule or the single
activity of an SA rule. The roles are on the Y axis while business cycles, impact ratings, Rule IDs, and
conflict names are on the X axis. Conflicts may appear more than once if they exist in multiple cycles.
For example, if an SOD rule has one leg in Expenditure, and the other leg in Fixed Assets, that rule
will appear under each of these cycles.

USER MATRIX
The User Matrix sheet provides a listing of User IDs that violate the given SOD or SA rule completely.
In other words, it shows the User IDs that have access to all legs of an SOD rule or the single activity
of an SA rule. The User IDs are on the Y axis while the business cycles, impact ratings, Rule IDs, and
conflict names are on the X axis.

22
USER ROLE RELATIONSHIP
The User Role Relationship sheet can be used to better understand the following:

 For a given user, what are all the roles that are assigned to this user
 For a given role, what are all the users that have access to this role

ALL VIEWS WITHIN RULE SHEETS


1) Rule Information: The Rules sheet provides the user and role count for the SA and SOD rules
in scope. A rule can exist in more than one business cycle and the user count may be greater
than the role count since a user can gain access to both legs of the SOD rule through
different roles. In this scenario, individual roles may not have the violation but the user will.

23
2) Rule Design: This view provides the details of the queries associated with the particular rule.

3) Role View: This view lists only the roles/profiles (both single and composite) that have
role/profile violations. Note that a “D” indicates that a composite role/profile has a conflict
when considering the access from all its single roles/profiles.

4) User View: This view lists only the users that have complete access to the rule. Note a “D” in
this case indicates that access for the relevant activity is obtained from multiple roles.

24
5) Filter View: This view provides all the user, role, activity and Method of Access information.
The detailed information in this view may not be required for your client. This view is used
for trouble-shooting access related queries.

25
CC KEYSTONE REPORT
The CC Keystone Report includes two different types of sheets:

1. The Rules sheet displays all configurable control rules that are in scope.

2. The rule specific sheets contain the detailed results of the analysis for a particular rule.

The rule specific sheets contain two sections:

1. The Rule Information section includes the Rule Name, Rule ID, Description and
Recommendation.

2. The Operational Effectiveness section includes the Output Description, Judgment Required
and deviation results.

Note that ACTT was designed to display data relating only to deviations in the report for configurable
controls. If the test result is “Deviation”, then the report will show the test results and the records
that resulted in the deviation. If the test result is “Pass”, no results are displayed.

For CC rules, the following scenarios are possible:

 Judgment Required = True


 Judgment Required = False
o As Expected
o Deviation

The cases above are represented in the CC Keystone report as explained below.

26
CASE 1: JUDGMENT REQUIRED = TRUE

When Judgment required = True, the Deviation/As Expected scenarios are not relevant and it is up to
the organization to setup their controls based upon the organization’s security strategy.

For example, control rule CC ITGC 104 checks the System Profile Parameters and displays the “User
defined values” and “System default values”. For this rule, there will be no deviation because
parameter values should be defined by the organization based upon their security strategy.

CASE 2: JUDGMENT REQUIRED = FALSE

When Judgment Required = False, the result can be either “As Expected” or “Deviation”.

In the example below, the result should be interpreted as “Deviation” since the “Judgment
Required” field displays “False” and the “System Status” field is “Modifiable”.

However, if the “System Status” field would have shown as “Blank” in the example above, the result
would be “As Expected”.

In the next example, the result should be interpreted as “As Expected”. The reason is that the
“Judgment Required” field displays “False” and the “User Id” and “Locked Status” fields are blank.

27
However, if the result was “Deviation” in the example above, it would have shown the User Id and
Locked Status as below.

EXPORT REPORT
The Export report contains two worksheets: the “User Export” sheet and the “Role Export” sheet.

The User Export sheet displays all users with relevant conflicts.

The Role Export sheet displays all roles with relevant conflicts.

28
UNICODE SUPPORT
The latest version (10.1) supports Unicode data extraction and analysis.

Rule Template:

SOD Keystone Report:

29
CONSIDERATIONS

 Users/Roles with future validity dates will not be excluded from the access analysis.
Example: If a user is created today with validity from 01/01/2020 to 12/31/9999, this user is
not excluded from the analysis during ACTT processing that is triggered today. Note: this
functionality is useful when performing access analysis before potential Go-Live. An update
to address this particular item is planned for an upcoming release of ACTT.

 In the “user view” of the SOD Keystone report, the representation of access that comes
through a reference user to a dialog user is not displayed. This representation of access is
planned for an upcoming release of ACTT.

 Currently ACTT does not exclude the false positives for organizational elements.
Example: A user obtains access to Activity 1 of a rule only for plant 0010 and access to
Activity 2 for only plant 0020. Ideally, this user should not be considered as having a conflict
since both the legs of the SOD rule are not relevant to the same organization unit. ACTT
currently does not support removal of these false positives. Note: If a single organizational
value (example: single plant value) is maintained in the SOD variable sheet of the rule
template, ACTT will look for the same organizational value in both legs of all SOD rules. In
this case, false positives will not occur.

 The ACTT reports currently include false positives if the roles have inactive authorization
profiles (in SAP, roles with an authorization tab of yellow).
Example: A role is first assigned with TCode A and generated properly and assigned to users.
When this role is later assigned with TCode B and the profile is not generated, the users
who are assigned to this role should not have access to TCode B. However, ACTT displays
these users in the report for TCode B. An update to address this particular item is planned
for an upcoming release of ACTT.

LEGACY TEMPLATES
ACTT supports the older versions of extractors and extracted data (.csv format). Please use the
legacy rule templates when past extractors are used (prior to release 10.0) for data in .csv format as
well as SAP 4.6C system analysis.

30
Below some items to consider in the ACTT analysis when the older extractors are used:

1. ACTT will not consider the access available through profiles directly assigned to an SAP user
without an associated role. ACTT would only consider access available through roles assigned to the
user.

2. ACTT displays false positives in the report when a user obtained access to two fields of the same
authorization object from two or more different SAP authorizations. Since access to relevant field
values did not come from the same authorization, it should not have been considered as valid
access.
Example: A role has an authorization object "S_TABU_DIS" with two authorizations "T-A699036100"
and "T-A699036101" and the authorization fields are maintained as below:

T-A699036100: ACTVT = 01
DICBERCLS = AA
T-A699036101: ACTVT = 02
DICBERCLS = BB

In this case, if an ACTT rule is looking for roles with access to authorization object S_TABU_DIS with
ACTVT = 01 and DICBERCLS=BB, the ACTT report will show that the role above has access. However,
the access is not valid since each field of the rule comes from different authorizations for the same
authorization object.

3. ACTT will not eliminate the inactive/under maintenance authorizations in the profiles during
analysis.
Example: A profile is created with one authorization “ZAUTH28” (that has the initial value for
S_TCODE= SU01) which is activated and then the profile is activated and assigned to the user. If the
authorization is later maintained with a new value “PFCG” and not activated further, the user should
not have access to PFCG. However, ACTT previously displayed these users for PFCG.

4. ACTT will not eliminate the roles without authorization profile in SAP, i.e., if the authorization
profile field in a role (in the "PFCG" transaction code->Authorization tab) is BLANK which is possible
in the following two cases:
a) If a new role is created and authorization profile for that role is not generated
b) If the authorization profile is manually deleted from the role through the PFCG transaction code

31
TROUBLESHOOTING

The tables below that are extracted via the SAP extractor can be used for troubleshooting:

ADRP These tables are used to obtain first and last names of users. This information can be
USR21 used for performing a comparison with the Terminated user listing.
AGR_1251 This table is used to obtain authorization data assigned to roles. Status of the object
can also be seen using this table. Note that an additional field in this table (Column J)
indicates whether the object within the rule is in an active state. An ‘X’ in this
column indicates that the object is inactive.
AGR_1252 This table is used to obtain Organizational Values maintained for roles.
AGR_AGRS This table is used to obtain single roles assigned to a composite role.
AGR_USERS This table provides the information about roles assigned to users.
USR02 This table provides User ID information.
USREFUS Reference users assigned to Dialog user
AGR_1016 Profile assigned to Role
USR10 Authorization Profiles
UST04 User Profiles
UST10C Composite Profiles
UST10S Single Profiles
UST12 User Master Authroizations

32

Вам также может понравиться