c-sec-2405 SAP Certified Associate - Security Administrator Practice Questions

Dialog users are for interactive system access by a single person (e.g., via SAP GUI).

System users are for dialog-free communication within a system, such as background processing or RFC calls.

Service users are typically used for anonymous system access for a larger, anonymous group of users (e.g., through an ITS service).

In SAP GRC Access Control, an 'Access Risk' (or SoD Risk) is defined as a combination of two or more conflicting functions (e.g., create vendor and pay vendor) that could potentially be exploited for fraudulent activity. The GRC ruleset is built upon these risk definitions to analyze user and role assignments for violations.

This is a two-part requirement. First, the specific tables that store vendor bank details (like LFBK) must have the 'Log data changes' flag set in their technical settings (transaction SE11). Second, table logging must be activated system-wide for the client by setting the rec/client profile parameter. Once both are active, changes made via standard transactions will be recorded in the DBTABLOG table and can be viewed with transaction SCU3.

A fundamental prerequisite for CUA to function correctly is that all roles assigned in the central system must also exist in the child systems where they are being assigned. CUA only distributes the assignment of the role to the user, not the role definition itself. The roles must be transported to all relevant child systems independently. If the role definition is missing in the target system, the IDoc containing the user's assignment data will fail to process.

Derived roles are used to efficiently manage authorizations for users who perform the same function but in different organizational units (e.g., company code, plant). A master role is created with all the necessary transactions and non-organizational authorizations. Derived roles inherit this data, and the administrator only needs to maintain the specific organizational level values in each derived role. This significantly reduces maintenance effort.

For Kerberos authentication to work across different Active Directory forests, a proper two-way forest trust must be established. Furthermore, if 'selective authentication' is enabled on the trust, the service account running the SAP application server must be explicitly granted the 'Allowed to Authenticate' permission on the domain controllers of the other forest. This is a common point of failure in complex multi-forest Kerberos setups.

Modern Fiori analytical apps are built on ABAP CDS views. Access to the data presented by these views is controlled by an additional authorization layer called Data Control Language (DCL). Even if the user has the OData service authorization (which controls access to the service endpoint), they will still get an error if the DCL access controls prevent them from seeing the data itself. This is a common troubleshooting step after verifying OData authorizations.

Transaction SCUM (Central User Administration - System Landscape) is the primary tool for managing the CUA landscape. Within SCUM, the 'Field distribution' tab allows an administrator to specify for each user master data field whether it should be maintained globally (in the central system only), locally (in child systems), or proposed from the central system. This is crucial for enforcing consistent user data across the landscape.

Each system needs its own SNC PSE, which contains its private key and public key certificate. For the systems to trust each other, the public key certificate of each system must be imported into the other system's PSE certificate list.

Profile parameters like snc/gssapi_lib (pointing to the cryptographic library) and snc/identity/as (defining the system's SNC name) must be set on both systems to enable SNC and identify the systems to each other.

Activating table logging causes the system to record changes (inserts, updates, deletes) made to the table data. This logging is primarily triggered by standard maintenance transactions. The logs can then be analyzed using transaction SCU3. It does not log read access or changes made via native SQL.