All variants for principal propagation in this blog series used HTTP secured by Transport Layer Security (TLS) as the application layer protocol for calling a Web service on BTP (see part I), an OData service on SAP NetWeaver Gateway (see parts II, III, IV and V), or the Graph API (see part VI) to call Microsoft 365 services. The OAuth 2.0 Authorization Framework is the de-facto security standard for restricting access to the data exposed by these RESTful services. To enable principal propagation, additional standards such as the Security Assertion Markup Language (SAML) 2.0 and OpenID Connect (OIDC) 1.0 are required for a secure and interoperable transfer of the security context and identity information of the authenticated user (or principal) across system- and network boundaries. Please refer to the other parts of this blog series for a detailled explanation how OAuth, SAML and OpenID can be combined for secure principal propagation.

For RFCs and BAPIs, none of the beforementioned protocols can be used to secure the communication and propagate the principal between an external client and the SAP Application Server (AS) ABAP. For these services, Secure Network Communications (SNC) can be applied to secure RFCs. SNC uses the standardized Generic Security Service Application Program Interface (GSS-API) for integrating with a cryptographic library for encrypting the data traffic on the network level and supporting single sign-on (SSO) to an SAP system using X.509 client certificates or the Kerberos protocol as specified in RFC 4120.

Principal Propagation with Kerberos Delegation

The Kerberos protocol, named after the three-headed guard dog of Hades from the Greek mythology, requires a trusted authority, the Key Distribution Center (KDC), to facilitate SSO between the client and a “kerberized” service or resource on a server. The protocol not only defines these three entities, but also three phases of their message exchange as illustrated in figure 1:

Figure 1: The Kerberos protocol

1. Authentication Service (AS) exchange: The client requests a ticket-granting ticket (TGT) with an authentication service request (AS_REQ) message (1) from the Authentication Service (AS) of the KDC. The user authenticates at the AS by encrypting this message with her secret key K_C that is created by hashing the user’s password stored in the KDC’s account directory. Upon successfull decryption, the KDC constructs the TGT for the user and returns it to the client with a AS_REP (2) message. The TGT is encrypted with the KDC’s secret key K_K and is a special type of Kerberos ticket that can only be used by the client to obtain other tickets from the KDC.
2. Ticket-Granting Service (TGS) exchange: To establish an authenticated communication session with the service, the client uses the TGT (instead of the long-term secret key K_C from the user’s hashed password) and requests a service ticket (ST) from the KDC’s Ticket Granting Service (TGS) with a ticket-granting service request (TGS_REQ) message (3). The service for which the ST is requested for is identified by its Service Principal Name (SPN). SPNs uniquely identify an instance of a service and are registered on a user or computer account in the KDCs account directory by setting the servicePrincipalName attribute of the object. The KDC returns the ST for the service encrypted with the service key K_S to the client with a ticket-granting service response (TGS_REP) message (4).
3. Client/Server Authentication (AP) exchange: The client sends the ST to the service with an application server request (AP_REQ) message requesting access to the service (5). The server can validate the ticket by decrypting it with its service key K_S where it finds the user’s unique name (cname). Optionally, the client might request that the server verify its own identity by sending back a application server response (AP_REP) message (6).

For propagating the authenticated user from the service to another service, the Kerberos protocol provides the Service for User (S4U) extensions. These extensions allow a service to obtain a Kerberos service ticket for a different service on-behalf-of a user that has not authenticated to the KDC. S4U includes the S4U2self and S4U2proxy extensions:

• The Service-for-User-to-Self (S4U2self) extension is intended to be used by a service to obtain a ticket for itself on-behalf-of a user who has authenticated in some other way than by using Kerberos to the service. With S4U2self, the service gets a ticket just as if the user had used Kerberos.
• The Service-for-User-to-Proxy (S4U2proxy) extension allows a service to
  call another service, acting on-behalf-of the user. The first service uses a Kerberos service ticket as if the user had obtained the service ticket for it and sends the ticket to a second service directly. Configuration at the KDC’s TGS can be used to limit the scope of the S4U2proxy extension, also known as constrained delegation. The second service is typically a proxy performing some work for the first service, and the proxy requires to do that work under the authorization context of the user.

Figure 2 shows the two S4U Kerberos extensions (steps 10 to 13) in the context of the complete end-to-end message flow for the scenario in this blog post:

Figure 2: System landscape and message flow

1. Jack Davis as the application test user in this tutorial logs on to the domain-joined Windows workstation on the corporate network. This results in a Kerberos TGT issued by the local Active Directory Domain Service (AD DS) acting as the KDC (see figure 1, steps 1 & 2). The same applies to services in the corporate domain, such as the OPDG, that also obtains a TGT from AD DS.
2. The user launches the “SAP Product Search” Power Platform app in a web browser. The app consists of two components (see figure 3): A canvas app providing the user interface to search for the price of a product in the Enterprise Procurement Model (EPM) demo application of the SAP system in the corporate network. The business logic to connect to SAP, transforming the BAPI response data, and error handling, is implemented in a Power Automate flow. The flow uses the SAP ERP Connector‘s prebuilt Call SAP function (V2) action to invoke the BAPI_EPM_PRODUCT_GET_DETAIL Business Application Programming Interface (BAPI) of the EPM demo application.Figure 3: Application components 
3. For authentication to Power Platform, the app requires an OpenID Connect (ID) token for authentication and an OAuth access token for authorization, and redirects the user to the app’s Azure AD tenant authorization endpoint to trigger authentication with the OAuth 2.0 authorization code flow. For a complete SSO experience, the setup in this scenario synchronizes the user accounts from the corporate Active Directory Domain Services (AD DS) to the Azure AD tenant with Azure AD Connect and Password Hash Synchronisation (PHS) enabled. With PHS, hashes of the user passwords in AD DS are synchronized by Azure AD Connect to Azure AD so that the users can login with the same password on-premises and in the cloud. This feature can be combined with Seamless SSO in Azure AD Connect to automatically sign-in users when they are on their corporate devices connected to the corporate network. The following steps 4 to 6 explain this process in more detail.
4. Azure AD challenges the browser to provide a Kerberos ticket for the user by sending an HTTP 401 Unauthorized response.
5. The browser requests the Kerberos ticket from AD DS for the computer account representing Azure AD in AD DS.
6. The browser forwards the encrypted Kerberos ticket to Azure AD which can decrypt it using the shared key for the account.
7. Upon successful SSO to the cloud, the Azure AD tenant generates an OAuth 2.0 authorization code for the user and sends it to the SAP Product Search app by redirecting the user’s web browser.
8. The app redeems the authorization code for an OAuth access token and OpenID Connect (ID) token by sending the authorization code to the Azure AD tenant’s token endpoint.
9. When the user enters a product ID and clicks the search button, the app triggers the flow which in turn uses the SAP ERP connector to call the SAP system’s BAPI via the OPDG on the corporate network. The flow passes the product ID to the BAPI’s input parameters and sends the user’s ID token in the call to the SAP ERP Connector. The ID token must successfully pass the validations of its claims, such as the intended recipient (audience), the trusted issuer who constructed the token (Azure AD tenant), and the validity of the expiration of the token, before the User Principal Name (UPN) is extracted from it and send to the OPDG.
10. OPDG uses the Kerberos S4U2self extension to retrieve a forwardable service ticket for itself on behalf of the Azure AD-authenticated user. To do so, OPDG has to run under a service user account (e.g. CORPGatewaySvc) within the AD domain, uniquely identified by its SPN (e.g. gateway/WIN-OPDG). OPDG needs to map the UPN from the Azure AD-authenticated user to a different UPN of the user in the on-premise AD, using an unused Active Directory attribute such as msDS-cloudExtensionAttribute1 in this scenario. This lab setup requires user mapping because the user’s UPN suffix in Azure AD (e.g. jdavis@bestruncorp.onmicrosoft.com) is different from her suffix in the corporate AD (e.g. jdavis@corp.bestrun.com). As specified by the S4U2self extension, OPDG creates the PA_FOR_USER data structure with the mapped user name and sends it with a TGS_REQ message to AD DS.
11. AD DS uses OPDG’s identity from its TGT sent with the TGS_REQ message to create the OPDG service ticket and returns the service ticket for the user in the TGS_REP message.
12. The SAP system is configured for SNC and Kerberos-based SSO (e.g. for SAP GUI), which requires registration of an SPN for the SAP system’s service account in AD DS following the format “SAP/<SID>”, e.g. SAP/A4H. OPDG is now attempting to obtain a service ticket for the SAP system on-behalf-of the user with the S4U2proxy Kerberos extension. OPDG sends the TGS_REQ message with the user’s service ticket for OPDG obtained in the previous step as an additional-ticket in the request.
13. AD DS makes sure the forwardable flag is set in the OPDG’s service ticket found in the  additional-ticket and uses its local policy to determine if OPDG is allowed to obtain a service ticket on behalf of a user to the SAP system. If these conditions are met, the TGS crafts the TGS_REP message to return the user’s service ticket to the SAP. This response contains the cname field identifying the user’s UPN in AD DS that was taken from the additional-ticket.
14. OPDG utilizes the locally installed SAP Connector for Microsoft .NET 3.0 (NCo 3.0) and SAP Cryptographic Library to make a secure, SNC-protected synchronous RFC call to the BAPI, authenticated with the Kerberos ticket from the previous step for the SAP system obtained on-behalf-of the Azure AD-authenticated user from AD DS. The SAP system can single sign-on the user with the Kerberos ticket by mapping its cname to the user’s SNC name (e.g. p:CN=JDAVIS@CORP.BESTRUN.COM).
15. If all authorization checks for the propagated user are successfull (such as the permission to call the BAPI), the response from the BAPI is sent back by the SAP ERP Connector to the flow, checked for any errors, and parsed for the price of the product which is returned to the app.

Prerequisites and lab setup

The following list of prerequisites must be met to successfully complete the exercises of part VII:

• A Power Platform environment. You can reuse the environment from part IV, or (if you started your journey here) can get a new one with a free Power Apps trial account or Microsoft 365 Developer license and by following these instructions.
• Administrative access to an Active Directory domain and on-premises systems for simulating the corporate network in your lab environment. You can create the required systems in your lab environment as Hyper-V VMs and configure them according to the table below:
  

  System	Operating system & software
  Active Directory Domain Controller (AD DC)	Windows Server 2019 Active Directory Domain Services (AD DS role). Installing the AD DS role and promoting a Windows Server to a domain controller is documented here. The domain name used in this tutorial is corp.bestrun.com (NetBIOS: CORP), but you can also choose any other name. Azure AD Connect, version 2.1.20.0, following these installation instructions.
  On-Premises Data Gateway (OPDG) Server	Windows Server 2019, domain-joined On-Premises Data Gateway, minimum version 3000.178.9 (June 2023) or newer. Installation instructions and how to register the OPDG in your Power Platform environment can be found here. SAP Connector for Microsoft .NET 3.0 (NCo 3.0). Select NCo 3.0 compiled with .NET Framework 4.0 – SAP Connector for Microsoft .NET 3.0.25.0 for Windows 64 bit (x64) from July 20, 2022 for download. SAP Cryptographic Library (sapcrypto.dll) 64 bit, version 8.5.25 (or newer). Download the latest version of the SAP Cryptographic Library from the SAP Support Portal’s Software Download (S-User required). Search for “CommonCryptoLib" in the Support Packages and Patches area. Optional tools for troubleshooting: Wireshark
  Workstation	Windows 10 Pro, domain-joined SAP GUI 7.70 SAP Secure Login Client 3.0
  SAP System	SAP Application Server ABAP Note: The SAP system is not required to be domain-joined and to have line-of-sight to the AD DC. Therefore you can run it also in the cloud. If you don’t have a system available for testing, the SAP Cloud Appliance Library (CAL) provides a simple way to deploy a test and development system for evaluation purposes on Azure. Use the SAP ABAP Platform 1909, Developer Edition appliance template which fulfills all requirements for this tutorial by installing an SAP Application Server ABAP 7.54 SP2.

  Table 1: Lab setup

• Administrative access to an Azure AD tenant (which is included in the Microsoft 365 Developer license). The domain name of the tenant used in this tutorial is bestruncorp.onmicrosoft.com, but you can also choose any other name.
• Checkout branch part7 of the blog series GitHub repository with a Git client of your choice and the following commands:

  git clone https://github.com/raepple/azure-scp-principal-propagation.git
  cd azure-scp-principal-propagation
  git checkout part7

The following exercises require switching between different roles. The table below lists those user roles and corresponding accounts used in the configuration steps of the scenario:

You will start the exercises to setup the end-to-end scenario illustrated in figure 2 by configuring the service account and SPN in the corporate Active Directory for the SAP system and setup the SAP system for SNC to test single sign-on with the SAP GUI. You can skip the following section if your SAP system is already configured for Kerberos-based SSO.

Configure SAP for Kerberos-based SSO with Active Directory

Step	Description	Screenshot
1	As a domain administrator, launch the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in on the Domain Controller host. Right-click on Users in your domain to open the context menu and select New → User to create the new service account for the SAP system.
2	Enter Kerberos<SID> as the First name, Full name and User login name. Replace <SID> with the ID of your SAP system (e.g. “A4H”). Click Next.
3	Enter the password for the new service user account. Select User cannot change password and Password never expires. Click Next.
4	Click Finish.
5	Start the ADSI Editor (adsiedit.msc) to maintain the Service Principal Name (SPN) of the new service account. Select CN=Users from your domain’s default naming context, and right-click on the CN=Kerberos<SID> user object. From the context menu, select Properties. Alternatively to steps 5 to 8, you can also use the command line as an Administrator and enter the following command: setspn –A SAP/A4H <domain>Kerberos<SID> Replace <domain> with the NetBIOS name of your domain (e.g. “CORP”), and <SID> with the ID of your SAP system (e.g. “A4H”).
6	Select servicePrincipalName from the list. Click Edit.
7	Enter the Service Principal Name (SPN) for the SAP service account in the format “SAP/<SID>”. Replace <SID> with the ID of your SAP system (e.g. “A4H”). Click Add.
8	Click OK.
9	Go back to the Active Directory Users and Computers MMC snap-in and select the new SAP service account Kerberos<SID> from the Users list. Right-click on it and select Properties from the context menu.
10	Switch to the Account tab. Under Account options, activate the checkbox for This account supports Kerberos AES 256 bit encryption. Click OK.
11	Login to the domain on the workstation host with your application test user (e.g. CORPjdavis).
12	Start SAP GUI and login as the SAP administrator. Run transaction SNCWIZARD to start the SNC Configuration wizard.
13	If you see the error message “DEFAULT profile in the DB and in the file system are different” then run transaction RZ10 first, and select Utilities → Import Profiles → Of active servers, and return to the SNCWIZARD. On the Start page of the SNC Configuration wizard, click Continue.
14	Accept the default value for system’s SNC Identity and click Continue.
15	Click Continue.
16	Click Close.
17	Log off from the SAP system to restart the application server.
18	As SAP system user <SID>adm, use the commands sapcontrol -nr <instance_number> -function StopSystem and sapcontrol -nr <instance_number> -function StartSystem to restart the application server. Replace <instance_number> with the number of your application service instance, e.g. “00”.
19	After the restart of the application server, log on to SAP GUI and run transaction SNCWIZARD again.
20	On the Start screen, click Continue.
21	Click Continue.
22	In the SPNEGO Configuration, click Display/Change to switch into edit mode.
23	Click Add to configure a new Kerberos User Principal.
24	Enter the following values: User Principal Name: Kerberos<SID>@<full-qualified name of your Active Directory Domain in uppercase letters, e.g. “CORP.BESTRUN.COM”> Password: <The password you specified in step 3> Confirm Password: <The password you specified in step 3>
25	Click Exit. Click Save to store the updated SPNEGO Configuration.
26	Click Skip on the X.509 Credentials wizard step.
27	Click Complete to finalize the wizard.
28	Open the SAP Secure Login Client and right-click on the Kerberos Token from the Profiles list. Select Copy SNC name to clipboard from the context menu.
29	Go back to SAP GUI and run transaction SU01 to maintain the application user’s SNC mapping. Enter the application test user’s ID (e.g. JDAVIS) in the User field and click Change.
30	Switch to the tab SNC. Maintain the user’s SNC name by pasting the value you copied in step 28 from the clipboard (e.g. p:CN=JDAVIS@CORP.BESTRUN.COM). Click Save.
31	Repeat the last two steps for maintaining the SNC mapping for the developer’s user account. Enter the developer user’s ID (e.g. DEVUSER) in the User field and click Change.
32	Switch to the tab SNC. Maintain the developer user’s SNC name (e.g. p:CN=DEVUSER@CORP.BESTRUN.COM). Click Save.
33	Log off as the administrator from SAP GUI.
34	Right-click on the SAP system connection and select Properties… from the menu.
35	Switch to the Network tab. Activate the checkbox Activate Secure Network Communication. In the SNC Name field, enter the SAP system’s SNC Identity from step 12. Click Finish.
36	Right-click on the system’s connection and select SNC Logon with Single Sign-On to test the new SNC setup.
37	You should be single signed-on as user JDAVIS to the SAP system. Click Log off (or select System → Log off from the menu) to log out as user JDAVIS.

Configure OPDG for Kerberos Constrained Delegation

By default, OPDG runs as the machine-local service account NT ServicePBIEgwService. To use Kerberos Constrained Delegation with the protocol’s S4U extensions, OPDG has to run under a service account in the domain.

Step	Description	Screenshot
38	On the Domain Controller host, go back to the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in. Right-click on Users in your domain and select New → User from the context menu. Enter “GatewaySvc“ as the First name, Full name and User login name. Click Next.
39	Enter the password for the OPDG domain service account. Select User cannot change password and Password never expires. Click Next.
40	Click Finish.
41	As the domain administrator, run the following command to create an SPN for the new service account which is required to configure the Kerberos delegation in the next step: setspn –S gateway/<OPDG hostname> <domain>GatewaySvc Replace <OPDG hostname> with the hostname of your OPDG system. You can find out the name by entering the command hostname.
42	Right-click on the new service account and select Properties from the context menu.
43	Switch to the Delegation tab. Select Trust this user for delegation to specified services only and Use any authentication protocol. Click Add.
44	Click Users or Computers.
45	Enter “Kerberos<SID>” in the object names field. Replace <SID> with your SAP system’s ID, e.g. “A4H”. Click Check Names to resolve it to the full existent name. Click OK.
46	The list of allowed services now contains the value from the SPN (Service Type / Computer) of the SAP system. The new OPDG service account can request a service ticket only for the SAP system on-behalf-of the propagated user with the Kerberos S4U2proxy protocol extension. Click Select All.
47	Click OK.
48	Click OK.
49	The OPDG service account must be granted to local policies on the OPDG host. Perform this configuration with the Local Group Policy Editor by running gpedit.msc from an Administrator command prompt.
50	Go to Local Computer Policy → Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment.  Grant the OPDG domain service account (e.g. “CORPGatewaySvc”) the local policy Act as part of the operating system by double-clicking on it. Click Add User or Group.
51	Enter the name of your OPDG’s domain service account (e.g. “GatewaySvc”) and click Check Names to resolve it to the full existent name. Click OK. The service account’s domain name (e.g. “CORPGatewaySvc”) is now added to the policy’s user list. Click OK to apply the new configuration.
52	Repeat the same step for the Impersonate a client after authentication policy by double-clicking on it. Click Add User or Group and resolve the OPDG’s service account to the full existent name with Check Names. Click OK.
53	The service account’s name (e.g. “CORPGatewaySvc”) is now added to the policy’s user list. Click OK. Close the Local Group Policy Editor.
54	Start the OPDG app from the desktop link on the gateway host, or by running C:Program FilesOn-premises data gatewayEnterpriseGatewayConfigurator.exe. Click Sign in to login as the Power Platform System administrator user who registered the OPDG in the environment.
55	Select Service Settings from the configurator’s menu. Click Change account.
56	Click Apply and Restart.
57	Enter your OPDG’s service account name (e.g. “CORPGatewaySvc”) and password from step 34. Click Configure.
58	Provide your Power Platform System administrator sign-in account, by clicking on Sign in.
59	Choose Migrate, restore or takeover an existing gateway to restore your gateway registration.
60	Select your gateway cluster and instance from the drop-down boxes and provide the recovery key you’ve chosen during the initial registration. Click Configure.
61	After the restoration is complete, your OPDG service instance uses the domain service account (e.g. “CORPGatewaySvc”).
62	Add the OPDG service account to the Windows Authorization and Access Group. This is requried because the user accounts that the gateway will impersonate are in Azure AD and thus not in the same domain as the OPDG service account. On the Domain Controller host, go back to the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in. Select the Builtin folder for your domain and double-click on the Windows Authorization and Access Group security group.
63	Switch to the Members tab of the security group. Click Add.
64	Enter the name of your OPDG’s domain service account (e.g. “GatewaySvc”) and click Check Names to resolve it to the full existent SPN. Click OK.
65	The OPDG service account is now added to the policy’s user list. Click OK to apply the new configuration.

Install and configure the SAP Cryptographic Library

For SNC communication between the OPDG and the SAP system, the SAP Cryptographic Library must be installed on the gateway host along with SAP NCo 3.0.

Step	Description	Screenshot
66	Download the latest version of the SAP Cryptographic Library from the SAP Support Portal’s Software Download (S-User required), and copy the library file (sapcrypto.dll) to the OPDG’s installation directory on the gateway host (C:Program FilesOn-premises data gateway). Right-click on the sapcrypto.dll file and select Properties from the context menu.
67	Switch to the Details tab to check the version of the library. It should be 8.5.25 or newer. Click OK.
68	Create a new text file sapcrypto.ini in the same directory (C:Program FilesOn-premises data gateway) with the following content: ccl/snc/enable_kerberos_in_client_role = 1 Save the file.
69	Grant read and execute permissions to both the sapcrypto.ini and sapcrypto.dll files to the gateway service user account and the AD user(s) that the service user impersonates. Right-click on the files and select Properties from the context menu. Switch to the Security tab. Check that the groups Domain Users and Authenticated Users are in the list. Click OK.
70	Create a CCL_PROFILE system environment variable and set its value to the path of thesapcrypto.iniconfiguration file. On the gateway host, launch the Control Panel and navigate to System and Security → System. Click Advanced system settings.
71	Click Environment Variables.
72	Under System variables, click New.
73	Enter CCL_PROFILE as the variable name. For the variable value, enter the full path to your sapcrypto.ini file, e.g. C:Program FilesOn-premises data gatewaysapcrypto.ini Click OK.
74	Click OK.

Configure User Mappings in Active Directory

To enable Kerberos-based principal propagation for a user in this scenario, a mapping from the user’s full username (User Principal Name, UPN) in Azure AD to the user’s local name in AD is required. For this purpose we will use the unused attributemsDS-cloudExtensionAttribute1 of the local AD user to store the Azure AD UPN. Any other unused Active Directory attribute can be used as well.

For the application test user Jack Davis in this scenario, you will set the msDS-cloudExtensionAttribute1 attribute of the local AD domain user account jdavis@corp.bestrun.com to the user’s Azure AD UPN jdavis@bestruncorp.onmicrosoft.com for linking his two accounts. The same applies to the application development user devuser, who requires a mapping from devuser@corp.bestrun.com to devuser@bestruncorp.onmicrosoft.com.

Step	Description	Screenshot
75	On the gateway host, open the file Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config in the OPDG installation folder (C:Program FilesOn-premises data gateway) in an editor.
76	Search for the setting ADUserNameReplacementProperty and set its value to SAMAccountName.
77	Search for the setting ADUserNameLookupProperty and set it to the value msDS-cloudExtensionAttribute1. Save the changes in the file.
78	Click Restart now from the OPDG’s configurator Service Settings tab to apply the changes.
79	On the Domain Controller host, click Start, and select Windows Administrative Tools → ADSI Edit from the menu. In the ADSI Editor, navigate in the left-side object tree to CN=Users under the domain’s Default naming context. Right-click on the test user’s object (e.g. CN=Jack Davis) and select Properties from the context menu.
80	Select the attribute msDS-cloudExtensionAttribute1 from the list and click Edit.
81	Enter the test user’s Azure AD UPN (e.g. jdavis@<domainname>.onmicrosoft.com) in the Value field. Replace <domainname> with your Azure AD tenant’s domain name, e.g. bestruncorp. Click OK.
82	Repeat steps 79 to 81 for the developer user object (e.g. CN=Developer User) and map it to the user’s Azure AD UPN (e.g. devuser@<domainname>.onmicrosoft.com).via the msDS-cloudExtensionAttribute1 attribute. Click OK and close the ADSI Editor.

Configure SAP User Authorizations

Next, the SAP system is configured for the application test user and power platform developer who need a different set of authorizations. The developer needs a set of authorizations used by the SAP ERP Connector for looking up the RFCs offered by the system during development of the Power Automate flow and at runtime. In addition, the application test user role requires the authorization to call the BAPI_EPM_PRODUCT_GET_DETAILS BAPI to search the product catalog with the Power App.

Step	Description	Screenshot
83	Go back to SAP GUI and log in as the administrator user. Start transaction PFCG to define a new role for the application users in this scenario.
84	Enter PRODUCT_SEARCH_BAPI in the Role field. Click Single Role.
85	Click Save.
86	Switch to the Authorization tab. Click the pencil button to edit the new role’s authorization data.
87	Click Do not select templates.
88	Click Manually.
89	Enter S_RFC for the Authorization Object in the first row. Click OK.
90	Click the pencil button to edit the authorization checks for field RFC_NAME.
91	Enter the following values in the Value Intrvl table’s ‘From’ column:  BAPI_EPM_PRODUCT_GET_DETAILS RFCPING RFC_FUNCTION_SEARCH RFC_METADATA_GET Click Save.
92	Click the pencil button to edit the authorization checks for field Activity (ACTVT).
93	Select Execute from the list. Click Save.
94	Click the pencil button to edit the authorization checks for field RFC_TYPE.
95	Select FUNC (Function Module) from the list. Click Save.
96	Click Save to save the application user role.
97	Click Generate.
98	Click Exit.
99	Switch to the User tab. Enter your application test user’s ID (e.g. JDAVIS) in the first row of the User Assignment table. Click Save.
100	Click User Comparison.
101	Click Full Comparison, then Close the dialog window.
102	Click Exit.
103	Next, create the role for the application developer. Enter PRODUCT_SEARCH_DEVELOPER in the Role field. Click Single Role.
104	Repeat steps 85 to 90 for the new role. Enter the following values in the Value Intrvl table’s ‘From’ column: DD_LANGU_TO_ISOLA RFCPING RFC_FUNCTION_SEARCH RFC_METADATA_GET Click Save. Continue by repeating steps 92 to 98 for the application developer role.
105	Switch to the User tab. Enter your application test user’s ID (e.g. DEVUSER) in the first row of the User Assignment table. Click Save.
106	Click User Comparison.
107	Click Full Comparison, then Close the dialog window.
108	Click Exit.

Setup the Power Platform canvas app and flow

All on-premise components (SAP system, OPDG, and AD) are now configured properly for Kerberos-based principal propagation of the Azure AD-authenticated user in the Power Platform canvas app which triggers the Power Automate flow to call the SAP system.

In this step, you will import the application components as a solution in your Power Platform environment and configure them according to your test lab setup. If you want to deploy to a new environment for this scenario, go to Power Platform admin center and create it.

Step	Description	Screenshot
109	Login to Power Apps Studio at https://make powerapps.com with your Power Platform developer user. From the top menu, select the environment to deploy the scenario components.
110	Click Import solution from the top menu bar.
111	Click Browse and select the file SAPProductSearchSolution.zip from the Git repository’s /ProductSearchApp folder. Click Next.
112	Click Next.
113	Open the drop-down box and select New connection.
114	In the SAP ERP Connection dialog, select Azure AD integrated as the Authentication Type. In the Choose a gateway drop-down box, select your OPDG instance for this scenario. Click Create.
115	The new connection requires authentication to your Azure AD tenant. Click Fix connection.
116	Sign-in to your Azure AD tenant with your development user’s account that you configured the SNC mapping in step 32 and AD mapping in step 82, and assigned the PRODUCT_SEARCH_DEVELOPER role in step 105.
117	Upon successful sign-in, switch back to the previous browser tab.
118	Click Refresh.
119	The new connection is now selected by the import solution wizard. Click Import.
120	Wait for the completion of the import as indicated by the green banner. Then select the imported SAP Product Search Solution from the list.
121	From the solution components, select the SAPERPSettings environment variable. This variable is used by the SAP ERP connector action in the Power Automate flow to configure the SAP system connection parameters. It is in JSON format.
122	Click New value to overwrite the default value.
123	Enter the SAPERPSettings environment variable’s new value according to your lab setup and the example below. You can use the default value as a template in a text editor.  { "AppServerHost": "<SAP system IP address or hostname, e.g. 23.123.153.183>", "Client": "<your client ID, e.g. 001>", "SystemNumber": "<your system numner, e.g. 00", "LogonType": "ApplicationServer", "SncLibraryPath": "C:\Program Files\ On-premises data gateway\sapcrypto.dll", "SncPartnerName": "<SAP system's SNC name, e.g. 'p:CN=A4H'>", "SncQOP": "Default", "SncSso": "On", "SystemID": "<SAP system's ID, e.g. A4H>", "UseSnc": "true" } Click Save.
124	Select the SAP Product Search canvas app from the solution.
125	The Power Apps Studio opens the SAP Product Search canvas app in edit mode. Click Allow.
126	Select Power Automate from the left-side navigation menu to list the flows used by the canvas app. From the list, select the ellipsis (‘…’) next to the GetProductDetailsFromSAP flow. Click Refresh.
127	Click Publish.
128	Click Publish this version.
129	You need to provide your application test user(s) access to the app. Click Share.
130	Enter your application test user’s name (e.g. “Jack Davis”) in the search field. Click on the user account. Note: Instead of configuring single users, you can also type “Everyone” in the search filed and share the app with “Everyone in <tenant org>”.
131	Deactivate the checkbox Send an email invitation to the user. Click Share.
132	Close the Share dialog box.
133	Click the Copy link to clipboard icon next to the app’s Web link.
134	Since the SAP Product Search app uses the SAP ERP Connector which is Premium tier connector, the application test user requires a Power App license to use this app. In a new browser tab, open the Microsoft 365 admin center at https://admin.microsoft.com/ and login as your Power Platform administrator. Select Billing → Licenses from the left-side navigation menu. Click Microsoft Power App Plan 2 Trial.
135	Click Assign licenses. In the search box, enter your application test user’s name and select the user’s account from the list. Click Assign. You can now log out from the Microsoft 365 admin center.
136	Similar to the canvas app, it is also required to set the user’s permission to access the OPDG instance. Go to the Power Platform admin center at https://admin.powerplatform.microsoft.com and login as your Power Platform admin user. Select Data (Preview) from the left-side navigation menu and switch to the On-premises data gateway tab. For the OPDG instance in your scenario, select the ellipsis (‘…’). From the context menu, select Manage users.
137	In the search field, start entering your application test user’s name. Select the user’s account from the list to add it.
138	Click Share.

Testing the scenario

All required components are configured for testing the scenario in the following steps.

Step	Description	Screenshot
139	Login to the domain on the workstation host with your application test user (e.g. CORPjdavis).
140	Open a web browser and paste the URL copied in step 133 into the address field.
141	Since you have synchronized your AD users with Azure AD Connect, you are single signed-on with the application test user to your Azure AD tenant and the app is loaded.
142	The SAP ERP connector requires a connection on-behalf-of the authenticated user. Click Allow to give consent to the requested permission to use this connection.
143	Enter a product ID form the catalog in the entry field, e.g. AR-FB-1000. Click Search.
144	The app triggers the flow which calls the SAP system on-behalf-of the Azure AD-authenticated user. The SAP ERP connector obtains a Kerberos ticket from Active Directory for the user found in the msDS-cloudExtensionAttribute1 attribute. Upon receiving the Kerberos ticket with the BAPI call, the SAP system is able to map the AD user via the SNC mapping to a local user in the system, for whom it checks the proper authorizations to invoke the BAPI. Finally, the response with the product details is returned to the Power Automate flow, which parses the response and sends the price information back to the canvas app.

Congratulations! You’ve successfully completed the scenario. The following sections provide additional information about optional settings to improve the end user’s experience and some troubleshooting tips.

Bypass the user consent

In step 142, the user has been asked to confirm the requested permissions of the SAP ERP Connector. In most enterprise scenarios, this user consent is usually not required, and can be bypassed with the following Powershell commands for Power apps administration:

Step	Description	Screenshot
145	Start a Windows Powershell as an administrator. Import the necessary modules using the following commands: Install-Module -Name Microsoft.PowerApps.Administration.PowerShell Install-Module -Name Microsoft.PowerApps.PowerShell -AllowClobber Confirm the questions with “Y”.
146	Provide your Power Platform administrator credentials using the following command: Add-PowerAppsAccount
147	The command opens the prompt to collect your Power Platform administrator credentials.
148	Run the Power Apps cmdlet Get-AdminPowerAppEnvironment and copy the value for your scenario’s EnvironmentName to a temporary textfile.
149	Run the Power Apps cmdlet Get-AdminPowerApp -EnvironmentName <value from step 148> with the value obtained in the previous step. Copy the value for your app’s AppName to the temporary textfile.
150	With the two values for EnvironmentName and AppName run the command: Set-AdminPowerAppApisToBypassConsent -EnvironmentName <value from step 148> -AppName <value from step 149> This command changes the bypassConsent flag of the SAP Product Search app to true.

Troubleshooting

In complex integration scenarios across various system-, network- and technology-boundaries, troubleshooting usually starts with gathering information about what the issue is and where it occurs. Therefore the techniques in this last section start with troubleshooting the scenario from the user’s perspective and then explain how to obtain detailled error traces from the system components along the end-to-end communication path.

Debugging with the Power Platform tools

To starting debugging the application scenario, login to https://make powerautomate.com with your Power Platform developer user. Select My flows from the left-side navigation menu and click on the Run button of the GetProductDetailsFromSAP flow. You can enter a product ID to search for in the entry field and click Run flow to start a new instance of the flow (figure 4):

Figure 4: Manually triggering the flow in the scenario

In the confirmation dialog box (figure 5), click the Flow Runs Page link. This page shows the run history of the GetProductDetailsFromSAP flow. Click on the fist item in the list to see the results from the last run. As shown in the following screenshot, the 3rd step Call SAP function (V2) – BAPI EPM PRODUCT GET DETAIL failed with a BadGateway error. By clicking on Show raw outputs you can view more details about the underlying issue. The user who started the instance (in this case the Power Platform developer user) obviously didn’t have the required permissions in the SAP system to call the BAPI according to the exception message:

Figure 5: Monitor flow run

Lower-level issues such as Kerberos- or user-mapping-related problems are usually reported back to the flow as an InternalServerError by the SAP ERP Connector. In this case you should take a closer look at the available error traces in the different log files.

SNC and Kerberos troubleshooting

A good starting point for troubleshooting SNC and Kerberos is the Guided Answers wizard for SNC Kerberos Configuration for SAP GUI troubleshooting. In addition, the following (non-complete) list of SAP Notes also provides resolutions for common SNC-related problems:

• 1635019: No user exists with SNC name – canonical name not resolved
• 1696905: SNC name configuration to support Kerberos and Certificates
• 1848999: Central Note for CommonCryptoLib 8 (SAPCRYPTOLIB)
• 1878155: SNC Error Code A2210231: Kerberos ticket not yet valid
• 2265085: Unable to load GSS-API DLL sapcrypto.dll
• 2384027: Error A2210233:Kerberos ticket contains wrong service name target
• 2446327: SNC Error Code A221021D Server refuses offered key exchange algorithm
• 2497505: SNC Error Code A2200210 Peer certificate verification failed – Kerberos configuration

Turning on SNC traces for SAP NCo and the SAP system can further help with the root cause analysis:

• On the SAP system, login as the operating system administrator, and change to the directory where the SAP Cryptographic Library is loaded from, e.g /usr/sap/<SID>/<INST>/exe, and create a new text file named sectrace.ini with the following content:

  LEVEL=4
  DIRECTORY=<new-or-empty-subfolder>​

  DIRECTORY must be set to a valid folder name for the respective platform. It must be the subfolder of an existing one, and should be placed in a local drive. If DIRECTORY doesn’t exist it will be created. As an example, DIRECTORY can be set on a Linux system to /usr/sap/<SID>/<INST>/sectrace.
  The following screenshot shows the traces generated in file sec-disp+work-<nnnnnn>.trc by the SAP GUI login of the application test user in step 37:

• To enable SNC tracing on the OPDG, open the sapcrypto.ini (see step 68) and add the following two lines to it:

  ccl/trace/level=4
  ccl/trace/directory=C:snctrc​

  Generated trace files can be found in the directory specified by the ccl/trace/directory profile parameter.

As the size of the generated trace files may grow quickly and tracing also reduces the performance of the systems, it is recommended to remove sectrace.ini and/or the configuration profile parameters from sapcrypto.ini once the troubleshooting activities are completed.

An in-depth analysis of the Kerberos message exchange between OPDG and SAP is possible with Wireshark, a tool for capturing and analyzing network traffic. Install the tool on the OPDG host and follow the steps below to capture the Kerberos taffic of steps 10 to 14 from figure 2:

Launch Wireshark. Select the network interface(s), e.g. Ethernet, to capture traffic for, and click on Start capturing packets.
Run the application scenario (steps 139 to 144)
Enter “kerberos” in the display filter field and press Enter. In the captured messages filtered for the Kerberos protocol, look for any error messages. The screenshot shows the TGS_REQ message (figure 2, step 12) with the user’s service ticket for OPDG obtained in the previous step as an additional-ticket in the request.

Collecting the logs from OPDG

Launch the OPDG app (see step 54) and sign-in as the Power Platform administrator. Select Diagnostics and click Export logs as shown in figure 6:

Figure 6: Exporting OPDG logs

Unzip the file that is saved to the ODGLogs folder on your Windows desktop. Look for the most recent GatewayErrors* file in the archive. The following screenshot shows the log file with an error message that the SAP Cryptographic Library could not be found in the OPDG installation directory:

Figure 7: OPDG log excerpt

Other common issues

Finally, table 2 contains a non-complete list of common error message in the scenario and suggests possible ways to resolve them.

Table 2: Common error message and their possible resolution