SAP Certified Associate - Security Administrator Free Sample Questions

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.

Transaction SU25 is crucial for post-upgrade authorization adjustments. Steps 2a, 2b, and 2c are used to compare the authorization default values (from SU24) of the old release with the new S/4HANA release. This process helps administrators identify which of their existing PFCG roles contain transactions with changed authorization data, allowing them to manually review and merge the new defaults to ensure the roles function correctly in S/4HANA.

False. The recommended best practice in SAP S/4HANA Cloud, Public Edition, is to copy the standard business role templates provided by SAP and then adjust the copy. This approach ensures that the role is based on a tested and supported foundation, simplifies future upgrades, and leverages the pre-configured business catalogs and applications associated with the template.

SAML 2.0 integration relies on a trust relationship established by exchanging metadata. The SAP Gateway system acts as the Service Provider (SP). Its SP metadata must be exported and given to the Identity Provider (IdP). Conversely, the IdP's metadata must be imported into the SAP system (using transaction SAML2). Additionally, the core SICF services for SAML processing (/sap/public/bc/sec/saml2 and /sap/bc/webdynpro/sap/saml2) must be active.

In transaction PFCG, a yellow status light on the Authorizations tab indicates that the authorization data has been modified (e.g., by adding new transactions or manually changing objects) but the corresponding authorization profile has not yet been generated. The administrator must enter the authorization data in expert mode to maintain the values and then generate the profile, which will turn the light green.

The reginfo (registration info) file controls which external RFC server programs are allowed to register themselves with the SAP Gateway using a specific Program ID. The secinfo (security info) file defines which clients (based on host and user) are permitted to start external programs via the Gateway. Together, they form a critical access control list (ACL) for protecting the Gateway from unauthorized external program execution and registration.