Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
MartinRaepple
Active Participant

This blog post guides you through the setup of an end-to-end scenario for implementing multi-factor authentication (MFA) for SAP GUI with Microsoft Entra ID (formerly known as Microsoft Azure Active Directory, AAD). The integration with Microsoft Entra ID is accomplished by SAP Cloud Identity Service and the SAP Secure Login Service for SAP GUI. Kudos to @Christian_Cohrs for supporting the setup of the test environment and thoroughly reviewing this blog post.

Tune in to the SAP on Azure video podcast episode 183 to see Christian and me explaining the concepts and to see a live demo of the scenario.

Scenario walk-through

Figure 1 (source draw.io file attached to this blog post) illustrates the setup for the scenario and the end-to-end communication flow for the MFA-secured and SSO (Single-Sign-On)-enabled login process:Figure 1 SAP GUI MFA scenarioFigure 1 SAP GUI MFA scenario

  1. The test user in this scenario, Jack Davis, logs on to his workstation with his Active Directory (AD) domain account. Upon successful login, AD issues a Kerberos ticket. Jack then launches SAP GUI and SAP Secure Login Client (SLC).
  2. In SLC, Jack starts the authentication process with the SAP Secure Login Service for SAP GUI (SLS) via the SLS Profile.
  3. The authentication request from SLC is delegated by SLS to the SAP Cloud Identity Services - Identity Authentication (IAS) tenant that is configured as a trusted identity provider in the SAP Business Technology Platform (BTP) subaccount of the SLS subscription.   
  4. The IAS tenant delegates the authentication request from SLS as an identity provider (IdP) proxy for the SAML (Security Assertion Markup Language) 2.0 protocol to Jack’s corporate Cloud IdP, the Entra ID tenant. This requires setting up a mutual trust relationship between the IAS and Entra ID tenants by exchanging each other’s SAML 2.0 metadata, which includes public cryptographic information in the format of X.509 certificates to verify the authenticity and integrity of the SAML messages sent in this step. In the Entra ID tenant, an Enterprise Application registration represents the IAS tenant with its SAML 2.0 metadata, and the corresponding Corporate Identity Provider in IAS gets created by importing the Entra ID tenant’s metadata.
  5. The SAML request sent by IAS to Entra ID requires Jack to authenticate with his credentials. To offer a seamless single-sign-on (SSO) experience, Jack’s user account in Active Directory is securely synchronized with the Entra ID tenant by the Microsoft Entra Provisioning  Agent running on the domain controller. With the seamless SSO feature enabled, Jack can sign-in to his Entra ID tenant from a domain-joined device connected to the corporate network without typing in his username and password. Instead, Entra ID verifies the Kerberos ticket issued to Jack on his domain-joined workstation to sign him in silently.
  6. An Entra Conditional Access (ECA) policy enforces the second authentication factor. The policy is applied to the Enterprise Application registration for IAS in the Entra ID tenant and kicks-in for every new login request received for the app after first-factor authentication is completed. ECA continues the login process by asking Jack to enter a secure, time-based one-time passcode (TOTP).
  7. To enter the code, Jack must install an authenticator app that supports TOTP verification, such as the Microsoft Authenticator app, on a device he owns. For the initial setup of Jack's account in Entra ID for MFA, Jack scans a QR code generated by Entra ID with the authenticator app. On subsequent sign-ins, the authenticator app generates a new TOTP every 30 seconds that Jack can type in to complete the MFA process.
  8. Entra ID returns a SAML response to the (SAML) request from IAS in step 4. Likewise, IAS generates a SAML response to the SAML request from SLS in step 3, which finally results in a short-lived X.509 client certificate for Jack generated by SLS in response to step 2. The client certificate has the Common Name (CN) set to Jack’s user principal name (UPN) in Entra ID (e.g. jdavis@bestruncorp.onmicrosoft.com). It is signed by the SAP Cloud Root Certificate Authority (CA), and has a default lifetime of 12 hours. SLC provides the X.509 certificate for SSO and Secure Network Communications (SNC) between SAP GUI and the SAP Application Server (AS) ABAP. For SSO to work, the administrator of the SAP system must maintain the mapping from Jack’s user account in SAP to Jack’s CN (UPN). Furthermore, the backend must have a trust relationship established to the issuer of the client certificate, the SAP Cloud Root CA.

Prerequisites

The setup instructions in this tutorial assume that you've met all of the following prerequisites:

  • Administrative access to an Entra ID P1 or P2 tenant to enable hybrid identity management with provisioning of the users from the on-premise Active Directory  to the Microsoft Entra ID tenant, and multi-factor-authentication using Entra Conditional Access (CA). This requires Conditional Access Administrator, Security Administrator, or Global Administrator privileges. If you need to, you can request a free Microsoft 365 Developer license, which includes a P2 tenant for development and testing purposes. The domain name of the tenant used in this tutorial is bestruncorp.onmicrosoft.com, but you can also choose any other name. Please follow this tutorial to install the Entra provisioning agent in your lab environment and configure Entra Connect Cloud Sync for your domain and tenant.
  • Administrative access to an IAS tenant.
  • Administrative access to an SAP BTP subaccount that has trust established to the IAS tenant (see instructions).
  • A valid license for the SAP Secure Login Service for SAP GUI service to be visible as an entitlement in your BTP subaccount. You should have already created an instance of the service in your subaccount following these instructions.
  • Administrative access to an Active Directory (AD) domain controller (DC) and a domain-joined workstation for simulating the corporate network. You can create the required systems in your lab environment as Hyper-V VMs and configure them according to the table below:

System

Configuration

Domain Controller

  • Windows Server 2019 or later
  • 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.
  • Microsoft Entra provisioning agent (for installation see this tutorial or these instructions)

Workstation

  • Windows 10 Pro or later, domain-joined
  • SAP GUI 7.70 or later
  • SAP Secure Login Client 3.0 SP02 Patch Level (PL) 16 or later
  • A non-administrator account used for testing the scenario in your local domain that is synchronized with the Entra ID tenant
  • Administrative access to an SAP Application Server ABAP for testing the SNC SSO with SAP GUI and the SLS-issued client certificate. One of the easiest ways to setup a development and test system is to run the ABAP Platform Trial on Docker. Setup of the SNC configuration will be covered in the following tutorial steps.

Download the SAP Cloud Root CA certificate

The chain of trust or certification path for the short-lived client (user) certificates issued by SLS has its trust anchor in the SAP Cloud Root CA and two intermediate CAs (SAP PKI Certificate Service Client CA and SAP BTP Client CA) as shown in the following picture:

MartinRaepple_0-1708700854903.png

Figure 2: SLS client certificate chain of trust

To successfully verify the SLS-issued certificates for SSO, the SAP Cloud Root CA certificate must be downloaded and distributed to all domain-joined workstations and the SAP system.

Step

Description

Screenshot

1.1

Login to your domain controller as the domain administrator.

 

Open a web browser and go to https://www.pki.co.sap.com to download the SAP Cloud Root CA certificate (or click this link).

 

Store the file on shared folder that is accessible from the domain-joined workstation.

MartinRaepple_1-1708700854912.png

 

Configure SNC in the SAP AS ABAP

You will setup SNC for X.509-based SSO in the SAP AS ABAP using transaction SNCWIZARD. Make sure that your lab environment’s ABAP application server (such as the Docker-based ABAP Platform Trial in my setup) uses the SAP Cryptographic Library (CommonCryptoLib) as the default cryptographic library for SNC.

Step

Description

Screenshot

2.1

Login with your test user to the workstation and start SAP GUI.

Login to the SAP AS ABAP with your admin user (e.g. DEVELOPER for the ABAP Platform Trial system).

MartinRaepple_0-1708898891648.png

2.2

Start transaction SNCWIZARD.

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.

MartinRaepple_1-1708898891657.png

 

2.3

On the Start page of the SAP Single Sign-On Wizard, click Continue.

MartinRaepple_2-1708898891669.png

2.4

Accept the default values for profile parameters and click Continue.

MartinRaepple_3-1708898891678.png

2.5

Click Close.

MartinRaepple_4-1708898891685.png

2.6

Log off from the SAP system.

MartinRaepple_5-1708898891686.jpeg

2.7

You must restart the application server. If you run the server in Docker, go to your running container instance in Docker Desktop, select the Exec tab, and enter the command

su <SID>adm

As SAP system user <SID>adm, use the commands
sapcontrol -nr <instance_number> -function Stop
and
sapcontrol -nr <instance_number> -function Start
to restart the server.

Replace <SID> with your system ID (e.g. “A4H”), and <instance_number> with the number of your application service instance (e.g. "00").

MartinRaepple_6-1708898891694.png

 

2.8

Login with your admin user and start the SNC Wizard again with transaction code SNCWIZARD.

Click Continue.

MartinRaepple_7-1708898891704.png

2.9

Since we don’t want to configure SNC for Kerberos, click Skip on the Kerberos Credentials page.

MartinRaepple_8-1708898891712.png

 

2.10

On the X.509 Credentials page, copy the Distinguished Name (DN) of the system’s SNC private key from the Subject field into the clipboard.

MartinRaepple_9-1708898891719.png

 

2.11

Click Continue. This will start the Trust Manager with transaction STRUST.

MartinRaepple_10-1708898891728.png

2.12

Double-click on the SNC SAPCryptolib entry in the PSE list.

Click the Display/Change button or Ctrl+F1 to enter edit mode.

MartinRaepple_11-1708898891736.png

2.13

Click Import certificate.

MartinRaepple_12-1708898891757.png

2.14

Stay on the File tab and select the file path  for the downloaded SAP Cloud Root CA certificate.

Click OK.

MartinRaepple_13-1708898891762.png

2.15

Click Add to Certificate List.

Click Save (or press Ctrl+S).

MartinRaepple_14-1708898891773.png

2.16

Click the Display/Change button or press Ctrl+F1 to switch to display mode.

MartinRaepple_15-1708898891780.png

2.17

Click Exit.

MartinRaepple_16-1708898891785.png

2.18

Click Complete.

MartinRaepple_17-1708898891795.png

Configure SNC in SAP GUI

Step

Description

Screenshot

3.1

Right-click in SAP GUI on the system connection for your SAP system and select Properties... from the context menu.

MartinRaepple_0-1708899261718.png

3.2

Switch to the Network tab.

Activate the checkbox Activate Secure Network Communication.

In the SNC Name field, paste the SAP system's SNC private key DN copied in step 2.10. and add the prefix "p:" (e.g. "p:CN=A4H, OU=IINITIAL, OU=SAP Web AS, O=SAP Trust Community, C=DE").

Click Finish.

MartinRaepple_1-1708899261720.png

Distribute the SAP Cloud Root CA Certificate

To ensure that the client workstation can verify SLS and ultimately its trust anchor, the SAP Cloud Root CA, as a trusted issuer for the short-lived client certificates, the SAP Cloud Root CA certificate must be imported into the workstation’s local certificate store. In an Active Directory domain, Group Policies provide a centralized management, configuration and software distribution tool to the domain-joined devices. You will use the Default Domain Policy to distribute the SAP Cloud Root CA certificate to the workstation.

Step

Description

Screenshot

4.1

Login to the Domain Controller and open the Control Panel from the Start menu.

Start the Group Policy Management editor from System and Security > Administrative Tools.

MartinRaepple_0-1708899342849.png

 

4.2

Select your domain name and right-click on Group Policy Objects > Default Domain Policy.

Click Edit... from the context menu.

MartinRaepple_1-1708899342862.png

 

4.3

Go to Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies.

Right-click on Trusted Root Certification Authorities and select Import… from the context menu.

MartinRaepple_2-1708899342880.png

 

4.4

The Certificate Import Wizard starts.

Click Next.

MartinRaepple_3-1708899342888.png

 

4.5

Click Browse… and open the SAP Cloud Root CA certificate file downloaded in step 1.1.

MartinRaepple_4-1708899342892.png

 

4.6

Click Next.

MartinRaepple_5-1708899342897.png

 

4.7

Select the Trusted Root Certification Authorities to store the certificate.

Click Next.

MartinRaepple_6-1708899342901.png

 

4.8

Click Finish.

MartinRaepple_7-1708899342905.png

 

4.9

Login to the client workstation and open a command line window.

Group Policy is automatically refreshed when the domain-joined workstation restarts, or when a user logs on to the computer. In addition, Group Policy is periodically refreshed every 90 minutes with a randomized offset of up to 30 minutes.

You can also run a Group Policy update to install the SAP Cloud Root CA certificate in the workstation’s local certificate store with the command

gpupdate.exe /force

MartinRaepple_8-1708899342907.png

 

Configure the Secure Login Client

Download the client authentication policies of the Secure Login Service (SLS) to the Secure Login Client (SLC) in a profile group.

Step

Description

Screenshot

5.1

Login to your BTP global account with SAP BTP CockpitThen select the subaccount in which your SLS instance is subscribed to.

Select the SLS subscription from the list in Instances and Subscriptions and copy the instance URL to the clipboard. 

MartinRaepple_0-1708930939580.png

5.2

Open the SLC on the workstation.

Select File -> Options… from the menu.

MartinRaepple_0-1708899460383.png

 

5.3

Switch to the Policy Groups tab.

In the Host field paste the URL of your SLS service instance you've copied in step 5.1.

Click Refresh, then Apply.

 

MartinRaepple_1-1708899460396.png

5.3

The new SLS profile is added which can be used later to obtain the X.509 client certificate from SLS.

MartinRaepple_2-1708899460458.png

 

Register IAS tenant in Entra ID

The IAS tenant must be registered in Entra ID to establish the trust relationship, which enables IAS to act as a SAML proxy in the scenario.

Step

Description

Screenshot

6.1

Login to the Entra admin center at https://entra.microsoft.com/

Select Identity à Applications à Enterprise applications from the left-side menu.

Click New application.

 

 

MartinRaepple_0-1708899690391.png

 

6.2

Enter “SAP Cloud Identity” in the search bar.

Click on the tile with the title SAP Cloud Identity Services from the search results.

MartinRaepple_1-1708899690414.png

 

6.3

Enter a name (e.g. “SLSIASTenant”).

Click Create.

MartinRaepple_2-1708899690428.png

 

6.4

Upon successful registration of the Enterprise application, click the Set up  Single Sign-On tile.

MartinRaepple_3-1708899690433.png

 

6.5

Click the SAML tile.

MartinRaepple_4-1708899690441.png

 

6.6

Open the SAML 2.0 metadata URL of your IAS tenant in a new Web Browser tab.

The URL has the following pattern:

https://<IAS FQDN>/saml2/metadata

e.g.

 https://myias.accounts.ondemand.com/saml2/metadata

Save the XML file.

MartinRaepple_5-1708899690459.png

 

6.7

Go back to the Entra admin center.

Click Upload metadata file.

MartinRaepple_6-1708899690468.png

 

6.8

Select the downloaded metadata.xml.

Click Add.

MartinRaepple_7-1708899690477.png

 

6.9

The SAML 2.0 configuration for the new enterprise application for the IAS tenant has been automatically populated with the content from the metadata file.

Click Save.

MartinRaepple_8-1708899690488.png

 

6.10

Copy the App Federation Metadata Url to the clipboard for the next step.

MartinRaepple_9-1708899690498.png

 

Configure Corporate Identity Provider in IAS tenant

The following step adds the Entra ID tenant as a corporate identity provider to the IAS tenant.

Step

Description

Screenshot

7.1

Login to the Administration Console of your IAS tenant.

Select Identity Providers à Corporate Identity Providers from the menu.

MartinRaepple_10-1708899759115.png

 

7.2

Click Create.

MartinRaepple_11-1708899759131.png

 

7.3

Enter a Display Name, e.g. Entra ID Tenant.

Select Microsoft ADFS / Azure AD (SAML 2.0) as the Identity Provider Type.

Click Create.

MartinRaepple_12-1708899759143.png

 

7.4

On the Trust tab of the new corporate identity provider, select SAML 2.0 Configuration.

MartinRaepple_13-1708899759148.png

 

7.5

Paste the URL copied to the clipboard in step 6.10 into the Metadata URL field and click Load.

MartinRaepple_14-1708899759155.png

 

7.6

The SAML 2.0 configuration of the corporate identity provider has been automatically populated with the content from the metadata URL of the Entra ID tenant.

Click Save.

MartinRaepple_15-1708899759163.png

 

Test SLC login with Entra ID without MFA

Let’s do a first test of the scenario to verify that the IAS tenant correctly delegates authentication of the user to Entra ID as the corporate IdP and seamlessly single signs-on the user. Enforcing a second factor with Entra CA will be configured in the next step.

Step

Description

Screenshot

8.1

In SLC, right-click on the new SLS profile and select Log In… from the context menu.

MartinRaepple_16-1708899799572.png

 

8.2

With seamless sign-on enabled in Entra Connect Cloud Sync, the currently logged in user on the domain-joined workstation gets single signed-on to the Entra ID tenant.

If you closely watch the communication flow in the embedded browser window you can see that the authentication request is delegated from IAS to Entra ID and the final response comes from IAS.  

MartinRaepple_17-1708899799573.png

 

 

 

 

MartinRaepple_18-1708899799576.png

 

8.3

The use should be successfully logged in with the new profile.

Right-click and choose Copy SNC name to clipboard. This value will be used in the next step to configure the required user mapping in AS ABAP.

Then choose Log Out from the context menu.

MartinRaepple_19-1708899799588.png

 

Configure user mapping in the SAP AS ABAP

With the SNC name copied from the short-lived certificate generated by SLS we can now go ahead and map it to the corresponding user account in AS ABAP.

Step

Description

Screenshot

9.1

Since there is no user mapping yet you have to login to the SAP system without SSO.

Right-click on the connection entry in SAP GUI and select SNC Logon Without Single Sign-On.

MartinRaepple_0-1708900082284.png

 

9.2

Logon with your admin user name and password.

MartinRaepple_1-1708900082293.png

 

9.3

Start User Maintenance with transaction code SU01.

MartinRaepple_2-1708900082302.png

 

9.4

Select a user account (e.g. DEVELOPER in the ABAP Platform Trial system) and click Change (Shift+F6).

MartinRaepple_3-1708900082307.png

 

9.5

Switch to the SNC tab.

Click Change SNC Name.

MartinRaepple_4-1708900082315.png

 

9.6

Paste the value from the clipboard in the text field.

Click OK.

MartinRaepple_5-1708900082323.png

 

9.7

Click Save.

MartinRaepple_6-1708900082334.png

 

9.8

Log Off from the system

MartinRaepple_7-1708900082344.png

 

Setup the Entra CA policy for MFA

Entra Conditional Access (CA) enforces the multi-factor authentication in the scenario. This requires the assignment of your test user to a CA policy that also defines the cloud app(s) that trigger the policy. The cloud app in this scenario is the IAS tenant which has been registered in the Entra ID tenant in the previous steps. Finally, you configure the actions whenever the IAS tenant sends a login request for the specified user (or group of users) which require additional processing, such as prompting for multifactor authentication.

Step

Description

Screenshot

10.1

Go back to the Entra admin center at https://entra.microsoft.com/

Select Protection à Conditional Access from the left-side menu.

Click New policy.

MartinRaepple_8-1708900194552.png

 

10.2

Enter a Name for the new CA policy, e.g. “SAPGUIMFA”.

Click the link in the section Users under Assignments to select the test user.

Choose Select users and groups and activate the Users and groups checkbox.

Select a test user for the scenario from your Entra ID tenant.

MartinRaepple_9-1708900194563.png

 

10.3

Click on the link in the Target resources section.

MartinRaepple_10-1708900194574.png

 

10.4

Select Cloud apps from the drop-down list and choose Select apps from the options.

Click None to select an app from your Tenant.

MartinRaepple_11-1708900194587.png

 

10.5

Search for the name of the IAS enterprise application you registered in step 6.3, e.g. “SLSIASTenant”.

Select it by activating the checkbox in search results.

MartinRaepple_12-1708900194592.png

 

10.6

Click the link in the Grant section of the new policy.

MartinRaepple_13-1708900194604.png

 

10.7

Choose Grant access from the options.

Activate the checkbox to Require multifactor authentication.

MartinRaepple_14-1708900194608.png

 

10.8

Click Select.

MartinRaepple_15-1708900194610.png

 

10.9

Choose On from the Enable policy options.

Click Create.

MartinRaepple_16-1708900194615.png

 

Test the scenario with MFA

Before you start testing the scenario with MFA enforced for the test user by Entra CA, verify that your Entra ID MFA registration policy includes your test user to enforce MFA.

Step

Description

Screenshot

11.1

In the Entra admin center, go to Protection à Identity Protection.

Select Multifactor Authentication Registration Policy from the menu.

Check that the policy includes your test user and the status is Enabled.

MartinRaepple_0-1708900396082.png

 

11.2

Open SLC and select the SLS profile.

Right-click and select Log in.

MartinRaepple_1-1708900396093.png

 

11.3

If the test user hasn’t signed-in with MFA yet, Entra ID will prompt the user to start the setup process. This includes downloading the Authenticator App and setting it up

MartinRaepple_2-1708900396112.png

 

11.4

If the test user has already setup a device for MFA, Entra ID will display a number in the browser to enter in the Authenticator App.

MartinRaepple_3-1708900396125.png

 

11.5

The user enters the number in the Authenticator App to sign in.

MartinRaepple_4-1708900396138.png

 

11.6

Upon successful validation of the second factor, SLC received a new short-lived X.509 certificate for the user.

MartinRaepple_5-1708900396153.png

 

11.7

Login to the SAP system uses the X.509 client certificate with SNC to single sign-on the user. The SAP system can map the user to a known account based on the SNC mapping (see status bar).   

MartinRaepple_6-1708900396200.png

 

Conclusion

Congratulations! You've successfully completed the tutorial. With this integration scenario, an IT security administrator can now consistently enforce MFA across all types of SAP clients from Entra ID and Conditional Access as the central control plane.

5 Comments
Labels in this area