SAP GUI MFA with Microsoft Entra (Part I): Integration with SAP Secure Login Service

[MartinRaepple]

Part I of this blog post series 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 in this part 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. Part II of the blog post series describes an alternative approach for the same scenario using Microsoft Entra Private Access.

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 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:

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.

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).
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.
2.3	On the Start page of the SAP Single Sign-On Wizard, click Continue.
2.4	Accept the default values for profile parameters and click Continue.
2.5	Click Close.
2.6	Log off from the SAP system.
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").
2.8	Login with your admin user and start the SNC Wizard again with transaction code SNCWIZARD. Click Continue.
2.9	Since we don’t want to configure SNC for Kerberos, click Skip on the Kerberos Credentials page.
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.
2.11	Click Continue. This will start the Trust Manager with transaction STRUST.
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.
2.13	Click Import certificate.
2.14	Stay on the File tab and select the file path  for the downloaded SAP Cloud Root CA certificate. Click OK.
2.15	Click Add to Certificate List. Click Save (or press Ctrl+S).
2.16	Click the Display/Change button or press Ctrl+F1 to switch to display mode.
2.17	Click Exit.
2.18	Click Complete.

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.
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.

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.
4.2	Select your domain name and right-click on Group Policy Objects > Default Domain Policy. Click Edit... from the context menu.
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.
4.4	The Certificate Import Wizard starts. Click Next.
4.5	Click Browse… and open the SAP Cloud Root CA certificate file downloaded in step 1.1.
4.6	Click Next.
4.7	Select the Trusted Root Certification Authorities to store the certificate. Click Next.
4.8	Click Finish.
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

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 Cockpit. Then 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.
5.2	Open the SLC on the workstation. Select File -> Options… from the menu.
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.
5.3	The new SLS profile is added which can be used later to obtain the X.509 client certificate from SLS.

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.
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.
6.3	Enter a name (e.g. “SLSIASTenant”). Click Create.
6.4	Upon successful registration of the Enterprise application, click the Set up  Single Sign-On tile.
6.5	Click the SAML tile.
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.
6.7	Go back to the Entra admin center. Click Upload metadata file.
6.8	Select the downloaded metadata.xml. Click Add.
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.
6.10	Copy the App Federation Metadata Url to the clipboard for the next step.

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.
7.2	Click Create.
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.
7.4	On the Trust tab of the new corporate identity provider, select SAML 2.0 Configuration.
7.5	Paste the URL copied to the clipboard in step 6.10 into the Metadata URL field and click Load.
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.

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.
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.
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.

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.
9.2	Logon with your admin user name and password.
9.3	Start User Maintenance with transaction code SU01.
9.4	Select a user account (e.g. DEVELOPER in the ABAP Platform Trial system) and click Change (Shift+F6).
9.5	Switch to the SNC tab. Click Change SNC Name.
9.6	Paste the value from the clipboard in the text field. Click OK.
9.7	Click Save.
9.8	Log Off from the system

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.
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.
10.3	Click on the link in the Target resources section.
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.
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.
10.6	Click the link in the Grant section of the new policy.
10.7	Choose Grant access from the options. Activate the checkbox to Require multifactor authentication.
10.8	Click Select.
10.9	Choose On from the Enable policy options. Click Create.

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.
11.2	Open SLC and select the SLS profile. Right-click and select Log in.
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
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.
11.5	The user enters the number in the Authenticator App to sign in.
11.6	Upon successful validation of the second factor, SLC received a new short-lived X.509 certificate for the user.
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).

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. 

Don't miss part II of this blog series that introduces a Zero Trust Network Access approach with Entra Private Access for SAP GUI MFA.

[nizarfanany]

Thank you for sharing

[Colt]

really enjoy Martin's blogs; I'm a big fan. Can I have the draw.io pictures? 🙂

[ankitkumarpatel]

Thanks for the detailed explanation

[MartinRaepple]

Hi @Colt ! Thanks a lot for your feedback. I've attached the source draw.io diagram to the blog post.

[Colt]

Hi, really enjoyed watching this engaging video featuring the three of you. 😉 However, I need to point out a concern that requires a bit of digging. Starting around 34:40 in the video, you explained how to create a Conditional Access Policy for the SAP GUI MFA login to enforce MFA for SAP GUI. You can set up a policy that checks conditions, for example, coming from user JDAVIS and the app SLSDemoIASTenant. It's crystal clear.

But since this IAS typically includes other apps besides SAP Secure Login Service, such as various BTP or SaaS as well as SAP On-Prem, all of which also delegate everything through the Corporate Identity Provider to Entra ID, this CA policy would also enforce MFA for these logins.

Is there a practical solution to ensure that MFA is enforced at every SAP GUI login, while other apps connected through the same Corporate IdP in the same IAS are configured to be less demanding in terms of AuthN/MFA? 

During my search, I stumbled upon this, but the documentation isn't clear, and it's not exactly apparent what needs to be done. Do I need two or more enterprise apps for the same IAS tenant in Entra ID to achieve that or would that be possible with just one Corporate IdP in IAS and one Enterprise App in Entra ID?

Hope you get what I'm aiming at with this question? 🙂

Cheers Carsten

[Christian_Cohrs]

Hi Carsten,

yes, you found the relevant documentation. By using the described approach, you allow Entra Id to distinguish between authentication requests coming from SAP Secure Login Service and requests from other apps in the same SAP Cloud Identity tenant. You can then have 2 enterprise apps with different policies in Entra Id, so that the configuration done for SAP Secure Login Service does not affect other apps. 

Best regards,
Christian 

[Colt]

Great, thanks - need to set this up soon and check it out 🙂

[sapnabasis]

Hi Team,

Very good article
Can you please explain on below
1.Under Prerequisites - Noticed as Domain Controller
Brief me in detail what is this about and why is need of the same

[MartinRaepple]

Hi, the main reason for the AD Domain Controller is that the user can single sign-on with their hybrid identities for the first authentication factor to the Entra ID tenant by enabling the Entra Cloud Sync or Entra Connect. I think that most of the SAP GUI scenarios already have an existing Domain Controller in place that is configured for Kerberos-based SSO to SAP. Thus, to make this tutorial more realistic, we also start from here, and expand it towards the Cloud with Secure Login Service and Entra ID.

[gerhard_klein]

Hi, we need a solution for SAPgui on workstation not domain-joined. 

[Colt]

Hi Gerhard,

so exactly this will be possible with the SLS for SAP GUI as well 😉 

[gerhard_klein]

Hi Colt,

we use SLC with kerberos for SAPgui and SAML2 for webgui. Consultants using AD user/password for global protect VPN und use SAP user/password for SAPgui. Kerberos doesn't work on workstations not domain joined. We couldn't find a consultant to close this gap. Another post for SAPgui SAML2 authentification for users working with workstations not domain joined would be great.

BR

Gerhard

[Colt]

Hi Gerhard,

feel free to get in touch before read this blog: https://www.linkedin.com/pulse/navigating-sap-sso-choosing-between-single-sign-on-30-carsten-olt-jyr...

In Short: SAP GUI SSO with X.509 via ODIC/SAML2 auth against the IdP is now possible even for users on Workstations w/o domain join

Cheers Colt

[sapnabasis]

Hi Martin,

Thanks for the document

Please help to understand on the below

As per flow to achieve SAPGUI SSO using Secure Login Service is as below
User -->SAP GUI -->SAP Secure Login ( Installed on Workstations)--> Communicate to Secure login Service ( Available on BTP)--->SLS redirects to IAS for SAML Authorization-->IAS Redirects to Identity Provider ( either SAP IDP or Azure Cloud) to autheticate user --> Upon authetication it sends IAS gives a SAML assestion response to SLS -->SLS gived X.509 cert to Secure Login Client --> Trust Establishes and Users are able to login

1.IAS plays a role as Proxy , my question are below
1.What is detailed role of IAS over here
2.Can SAPGUI SSO achieved without IAS, if so How

2.Referred the below blog
https://community.sap.com/t5/technology-blogs-by-members/exploring-sap-secure-login-service-for-sap-...
"Not clear on the point Support for Customer on ( Cloud CA SAP -Managed)

3.By using this Secure Login Service can we achieve SAGUI SSO for Onpremise and Cloud Hosted SAP systems , if so how the trust establishment works between onpremise and cloud hosted Secure Login Service

4.Can we achieve Webgui , irj SSO also using this Secure Login Service if so how the same can be achieved

5.Based on your document  as per this document you also mentioned of using MFA , whereas if MFA is not required the section "Test the scenario with MFA" can be ignored or any further additonal steps 

[Christian_Cohrs]

Hi,

IAS is SAP's default identity provider. You can use it to authenticate users but also as a proxy that forwards authentication requests to other identity providers. When using SAP Secure Login Service, all requests go first to IAS and are then handled based on the conditional authentication configuration in IAS.

SAP Secure Login Service supports ABAP systems both on-premise and in the cloud. There is no trust required between the service and the ABAP system. However, the ABAP system needs to trust the CA that signs the certificates. 

You can also configure the ABAP system to accept certificates for browser SSO. However, in that scenario you could also rely directly on the identity provider, IAS or other.

Best regards,

Christian 

[Sridhar_CS]

Hi Cohrs, 

I also like to know can Sailpoint used on this configuration that manages access part if so how it plays the key role and what additonal steps need to done 

[Christian_Cohrs]

Hi Sridhar,

this approach can be combined with any identity management or access governance solution. Identity management can help to automate the creation of the user accounts in the identity provider and the ABAP systems, and set the correct user mapping in ABAP. This data will then be used during authentication.

Best regards,
Christian 

[Sridhar_CS]

Hi Christian, 

Thanks for the update 
I assume Integration has to done between Azure AD and Sailpoint and Along with SSO configuration setup 

i am not finding any relevant document or steps specific to achieve this , it will helpfull if you some more points specific to this 

[yaswanth]

Great Blog Martin and Christian, Thank you for sharing in very detailed format. 

I have 2 questions:

1. How to change the CN=<SAP USERID> in SAP Secure client, instead of email attribute. Is there a way to change in SAP Cloud IDP ?

2. Noticed, that CN value is a case sensitive and SAP strongly checks for same exact value, is there anyway to overwrite this ?

[Christian_Cohrs]

Yes, SAP Cloud Identity's Identity Authentication Service can help with both of these things:

• Configure the Subject Name Identifier Sent to the Application 
• Convert Subject Name Identifier to Uppercase or Lowercase 

[Camille_Ucar]

Great Blog Martin and Christian, Thank you it's very interesting. 

Great Blog Martin and Christian, Thank you it's very interesting. 

Step 5 says that 'Entra ID verifies the Kerberos ticket issued to Jack on his domain-joined workstation to sign him in silently.'
We can't avoid connexion popup to IAS.

We have ‘Entra ID Connect’ (version before ‘Entra ID tenant by the Microsoft Entra Provisioning Agent’).
The synchronization is same (with hash).

Is this solution ready with AD ‘Entra ID Connect’ ?
Why IAS popup appear instead of Azure AD popup connexion ?

thks for your help
Camille

[sumi_susan2]

Hi,

We have configured SSO for GUI using the Secure Login Service. We have a requirement of configuring SSO from power automate to this SAP environment. In Power Automate - for the "Add New Connection" option for the Authentication Type , we have used "Microsoft Entra ID (with certificate)"  option .

The configuration fails with the below error.

The dynamic operation request to API 'saperp' operation 'GenerateJsonSchema' failed with status code 'InternalServerError'. Error response: { "error": { "code": 500, "source": "default-8706b5bf-c37d-4f37-8ff1-0941e411ce20.15.common.europe002.azure-apihub.net", "clientRequestId": "301ewr18b5843-bcf4-4f4b-97f1-866144d90bd4", "message": "BadGateway", "innerError": { "error": { "code": "UnhandledException", "message": "Value cannot be null. Parameter name: Value cannot be null. Parameter name: findValue", "target": "System.Security.Cryptography.X509Certificates.X509Certificate2Collection.FindCertInStore(SafeCertStoreHandle safeSourceStoreHandle, X509FindType findType, Object findValue, Boolean validOnly)" } } } }

Kindly advise.

Regards,

Sam

[robveenman]

Should the Cryptolib Own certificate not be signed by the internal PKI after step 2.16?
Or at least: Export the self signed Own certificate and import it in the Trust store of every client?

If I don't do this, I get an error like mentioned in "2680913 - SNC Error Code A2200210:Peer certificate verification failed - Certificate X.509 configuration".
(PS : I  am not using SLS, but re-using an existing x.509 client certificate already stored on the client).