Hi Peers,
In Part 1, I covered the business case why SAP MDG needs Azure Active Directory and the five use cases it enables. If you haven’t read that, I’d recommend starting there for context. Below is the link for Part 1.
SAP MDG + Azure AD – Part 1: The Why, The Gap, and… – SAP Community
In this post, I’ll walk you through the complete setup Azure account, app registration, client secrets, API permissions, RFC destinations, SSL certificates, configuration tables, and finally running the program that fetches Azure AD user data into SAP.
Here’s the flow in technical terms. SAP sends an HTTP POST to Azure AD’s token endpoint with the Client ID and Client Secret. Azure validates these credentials and returns a JWT bearer token. SAP then sends an HTTP GET to the Microsoft Graph API /users endpoint with that token in the Authorization header. Graph API validates the token, checks the app’s permissions, and returns user data as JSON. SAP deserializes the JSON into an ABAP internal table.
Two HTTP calls. Two RFC destinations. Three config tables. That’s the architecture.
Before jumping in What helped me get through this was the ABAP SDK for Azure repository on GitHub and the work its contributors have put into the documentation and demo programs. Solid resource , I’d recommend you to have a look into it if you need any further clarification.
Now Lets split this technical Deep dive into two parts based on Azure configuration and SAP configuration
Part A: Azure Side Configuration
Step 1: Set Up Your Azure Account and Tenant
Sign up for Azure and follow the below steps to set up a new Tenant, Once logged in, go to All Services → Microsoft Entra ID → Manage Tenant → Create a new Tenant. Note down the Tenant ID you will need this later when configuring the RFC destination in SAP.
Step 2: Register an Application
Now let us Register and Application, this application you register here represents your SAP system in Azure. It gives SAP an identity to authenticate with Azure services.
For this Go to App Registrations → New Registration → Enter a name for your application (e.g., ABAPSDK-DEMO-APP) → Select “Single tenant only” → Click Register.
Step 3: Note the Key Values
After registration, the Overview page displays two values you need to save:
Application ID : Unique ID used to identify our application in ABAP Program
Directory (Tenant ID): This Unique ID represents our organization and this will be used in SM59 as a prefix for the path to identify our Tenant with SAP
Copy both and keep them safe. You will use them throughout the SAP configuration.
Step 4: Generate a Client Secret
Under the registered application, go to Certificates & Secrets → Create a new Client Secret → Set an expiration date → Click Add.
Azure will display two columns: Value and Secret ID. Copy the Value immediately. Value is basically an API key, This is your actual client secret it goes into the ZADF_CONFIG table in SAP.
Important: Azure shows the Value only once. If you navigate away from this page without copying it, you will not be able to retrieve it again. You would have to delete the secret and create a new one.
Step 5: Configure API Permissions
Go to API Permissions → Add a Permission → Select Microsoft Graph → Select Application permissions (not Delegated) → Search for User.Read.All → Add it.
Note: While Creating a new API permission make sure to go with Application permissions are required because SAP uses the OAuth2 client credentials flow which is a server-to-server call with no interactive user sign-in.
Step 6: Grant Admin Consent
After adding the permission, click “Grant admin consent for <your tenant name>” → Confirm by clicking Yes.
Your tenant name in the sense is the new created tenant in our first Step
Verify that the Status column should show a green checkmark with “Granted for <your tenant name>” next to each permission. If the button is greyed out or shows a different tenant name, you are not an administrator of that tenant.
With this, the Azure side configuration is complete.
Part B: SAP Side Configuration
Initial Step: Install the ABAP SDK for Azure
The ABAP SDK provides the classes, interfaces, configuration tables, and demo programs needed to communicate with Azure. Refer to the official installation guide on GitHub: https://github.com/Microsoft/ABAP-SDK-for-Azure
Step 1: Create the RFC Destination for Azure AD
Open transaction SM59 and create a new RFC destination of connection type G (HTTP Connection to External Server).
Step 2: Configure Technical Settings
Now configure Target Host, service Port and Path prefix with the following values:
login.microsoftonline.com, 443, /<YOUR_TENANT_ID>/oauth2/token
Replace <YOUR_TENANT_ID> with the Tenant ID you noted in Step 3 of the Azure configuration. Make sure there is a forward slash at the beginning of the path prefix.
Step 3: Configure Logon & Security
Now navigate to Logon & Security Tab under it configure the following, SSL->Active (select the radio button) and SSL Certificate DFAULT SSL Client (Standard)
Save the destination. Do not test the connection yet it will fail until the SSL certificates are imported.
Step 4: Download SSL Certificates
SAP needs to trust the SSL certificate from login.microsoftonline.com to establish a secure HTTPS connection. Without this, SAP will throw a SSSLERR_PEER_CERT_UNTRUSTED error.
To download the certificates, open Chrome and navigate to: https://login.microsoftonline.com/<YOUR_TENANT_ID>/oauth2/token
You will see an error page saying “The endpoint only accepts POST, OPTIONS requests.” This is normal the token endpoint only accepts POST requests. You are here only to download the certificate.
Click the lock icon next to the URL → View Certificate → Go to the Certification Path tab → Export every certificate in the chain
Warning: You must export ALL certificates in the chain not just one. If you miss the root or intermediate certificate, the SSL handshake will still fail.
Step 5: Import Certificates into STRUST
Contact your Basis team and share the downloaded certificates to STRUST and restart ICM
The “Add to Certificate List” step is critical importing alone loads the certificate but does not add it to the trust store. Without this step, the handshake will still fail.
Step 6: Test the RFC Connection
After the certificates are imported and the ICM is restarted, go back to SM59 and test the connection. You should see HTTP 200 OK. If you still get the SSL error, verify that all certificates in the chain were imported and added to the certificate list.
Step 7: Configure the ABAP SDK Tables
The ABAP SDK uses three configuration tables. Each Azure service interface requires entries
ZREST_CONFIG – Interface to RFC Mapping
This is the master table that links an Interface ID to an RFC destination.
Field
Value
Interface ID
DEMO_AZ_AD
RFC Destination
AZURE_ABAPSDKKDEMO-AAD (your SM59 destination)
ZREST_CONF_MISC – Operational Settings
This table controls the HTTP method, retry logic, and alert settings.
Field
Value
Interface ID
DEMO_AZ_AD
METHOD
POST (the OAuth token endpoint only accepts POST)
MAX_RETRY
1
EMAIL_ID
Your email address (for failure alerts)
MAIL_BODY_TXT
Error text identifier
RETRY_METHOD
Leave blank
ZADF_CONFIG — Azure-Specific Configuration
This table holds the authentication type, client secret, and processing mode.
Field
Value
Interface ID
DEMO_AZ_AD
Interface Type
Azure Active Directory (select from dropdown)
SAS_KEY
Paste your client secret VALUE from Azure Step 4
URI
Leave blank
SERVICE_TYPE
S (Synchronous)
IS_TRY
Leave blank
This table holds the authentication type, client secret, and processing mode.
Important: The Interface ID must be exactly the same across all three tables. It is case-sensitive.
Important: The Interface Type in ZADF_CONFIG determines which ABAP class the SDK factory creates. For AAD token generation, it must be “Azure Active Directory”. Setting it to anything else will result in a MOVE_CAST_ERROR at runtime.
With this, the connection between Azure Active Directory and your SAP system is established.
Now let us configure one more RFC destination To fetch data from Azure, we need API access to Microsoft Graph. This requires a separate RFC destination for the Graph API endpoint.
Step 8: Create the RFC Destination for Graph API
Open SM59 and create a new destination:
Step 9: Configure Logon & Security
Follow the same SSL certificate process to download the certificate chain from https://graph.microsoft.com, import into STRUST, restart ICM, and test the connection. You should get HTTP 200.
Step 10: Configure the ABAP SDK Tables for Graph API
now Create entries in all three tables with a new Interface ID:
ZREST_CONFIG
Field
Value
Interface ID
AZ_GRAPH
RFC Destination
AZURE_GRAPH
ZREST_CONF_MISC
Field
Value
Interface ID
AZ_GRAPH
METHOD
GET
MAX_RETRY
1
ZADF_CONFIG
Field
Value
Interface ID
AZ_GRAPH
Interface Type
Microsoft Graph (select from dropdown)
SAS_KEY
Same client secret VALUE as DEMO_AZ_AD
URI
Leave blank
SERVICE_TYPE
S
IS_TRY
Leave blank
Important: The Interface Type for the Graph API interface must be “Microsoft Graph” not “Azure Active Directory”. The factory class uses this value to instantiate the correct service class. Wrong type means wrong class, which means a MOVE_CAST_ERROR.
With this, the connection between Microsoft Graph API and your SAP system is established.
Now let us test the connection with The ABAP SDKs existing program this includes a demo program called ZADF_DEMO_AZURE_GRAPH that can fetch users from Azure AD.
Step 11: Open and Update the Program
Go to transaction SE38 and open program ZADF_DEMO_AZURE_GRAPH. Update the Interface ID constants at the top of the program to match your configuration:
Step 12: Execute
Run the program (F8). On the selection screen:
Field
Value
Select
“Read Users” radio button
Azure Client ID
Your Application (Client) ID from Azure Step 3
Step 13: Review the Output
The program will request an AAD token from login.microsoftonline.com, call the Microsoft Graph API /users endpoint with that token, and display the user data in JSON format.
If the program returns user data, your end-to-end integration is working. SAP is authenticating with Azure AD, calling Microsoft Graph API, and receiving data all of this from ABAP.
What’s Next
That’s the complete technical setup of Azure side and SAP side. Two RFC destinations, three config tables each, and a working demo program pulling live user data from Azure Active Directory into SAP.
But fetching data through a demo program is just the foundation. In Part 3, I’ll show you how to take this further by building a reusable ABAP class that wraps the entire Azure authentication and Graph API flow into a clean interface that can be consumed in to FPM UI in MDG Business Partner screen. That’s where this moves from a technical demo to a practical MDG solution.
Stay tuned.
Hi Peers, In Part 1, I covered the business case why SAP MDG needs Azure Active Directory and the five use cases it enables. If you haven’t read that, I’d recommend starting there for context. Below is the link for Part 1.SAP MDG + Azure AD – Part 1: The Why, The Gap, and… – SAP CommunityIn this post, I’ll walk you through the complete setup Azure account, app registration, client secrets, API permissions, RFC destinations, SSL certificates, configuration tables, and finally running the program that fetches Azure AD user data into SAP.Here’s the flow in technical terms. SAP sends an HTTP POST to Azure AD’s token endpoint with the Client ID and Client Secret. Azure validates these credentials and returns a JWT bearer token. SAP then sends an HTTP GET to the Microsoft Graph API /users endpoint with that token in the Authorization header. Graph API validates the token, checks the app’s permissions, and returns user data as JSON. SAP deserializes the JSON into an ABAP internal table.Two HTTP calls. Two RFC destinations. Three config tables. That’s the architecture.Before jumping in What helped me get through this was the ABAP SDK for Azure repository on GitHub and the work its contributors have put into the documentation and demo programs. Solid resource , I’d recommend you to have a look into it if you need any further clarification.Now Lets split this technical Deep dive into two parts based on Azure configuration and SAP configurationPart A: Azure Side ConfigurationStep 1: Set Up Your Azure Account and TenantSign up for Azure and follow the below steps to set up a new Tenant, Once logged in, go to All Services → Microsoft Entra ID → Manage Tenant → Create a new Tenant. Note down the Tenant ID you will need this later when configuring the RFC destination in SAP.Step 2: Register an ApplicationNow let us Register and Application, this application you register here represents your SAP system in Azure. It gives SAP an identity to authenticate with Azure services.For this Go to App Registrations → New Registration → Enter a name for your application (e.g., ABAPSDK-DEMO-APP) → Select “Single tenant only” → Click Register.Step 3: Note the Key ValuesAfter registration, the Overview page displays two values you need to save:Application ID : Unique ID used to identify our application in ABAP ProgramDirectory (Tenant ID): This Unique ID represents our organization and this will be used in SM59 as a prefix for the path to identify our Tenant with SAPCopy both and keep them safe. You will use them throughout the SAP configuration.Step 4: Generate a Client SecretUnder the registered application, go to Certificates & Secrets → Create a new Client Secret → Set an expiration date → Click Add.Azure will display two columns: Value and Secret ID. Copy the Value immediately. Value is basically an API key, This is your actual client secret it goes into the ZADF_CONFIG table in SAP.Important: Azure shows the Value only once. If you navigate away from this page without copying it, you will not be able to retrieve it again. You would have to delete the secret and create a new one.Step 5: Configure API PermissionsGo to API Permissions → Add a Permission → Select Microsoft Graph → Select Application permissions (not Delegated) → Search for User.Read.All → Add it.Note: While Creating a new API permission make sure to go with Application permissions are required because SAP uses the OAuth2 client credentials flow which is a server-to-server call with no interactive user sign-in.Step 6: Grant Admin ConsentAfter adding the permission, click “Grant admin consent for <your tenant name>” → Confirm by clicking Yes.Your tenant name in the sense is the new created tenant in our first StepVerify that the Status column should show a green checkmark with “Granted for <your tenant name>” next to each permission. If the button is greyed out or shows a different tenant name, you are not an administrator of that tenant.With this, the Azure side configuration is complete. Part B: SAP Side ConfigurationInitial Step: Install the ABAP SDK for AzureThe ABAP SDK provides the classes, interfaces, configuration tables, and demo programs needed to communicate with Azure. Refer to the official installation guide on GitHub: https://github.com/Microsoft/ABAP-SDK-for-AzureStep 1: Create the RFC Destination for Azure ADOpen transaction SM59 and create a new RFC destination of connection type G (HTTP Connection to External Server).Step 2: Configure Technical SettingsNow configure Target Host, service Port and Path prefix with the following values:login.microsoftonline.com, 443, /<YOUR_TENANT_ID>/oauth2/tokenReplace <YOUR_TENANT_ID> with the Tenant ID you noted in Step 3 of the Azure configuration. Make sure there is a forward slash at the beginning of the path prefix.Step 3: Configure Logon & SecurityNow navigate to Logon & Security Tab under it configure the following, SSL->Active (select the radio button) and SSL Certificate DFAULT SSL Client (Standard)Save the destination. Do not test the connection yet it will fail until the SSL certificates are imported.Step 4: Download SSL CertificatesSAP needs to trust the SSL certificate from login.microsoftonline.com to establish a secure HTTPS connection. Without this, SAP will throw a SSSLERR_PEER_CERT_UNTRUSTED error.To download the certificates, open Chrome and navigate to: https://login.microsoftonline.com/<YOUR_TENANT_ID>/oauth2/tokenYou will see an error page saying “The endpoint only accepts POST, OPTIONS requests.” This is normal the token endpoint only accepts POST requests. You are here only to download the certificate.Click the lock icon next to the URL → View Certificate → Go to the Certification Path tab → Export every certificate in the chainWarning: You must export ALL certificates in the chain not just one. If you miss the root or intermediate certificate, the SSL handshake will still fail.Step 5: Import Certificates into STRUSTContact your Basis team and share the downloaded certificates to STRUST and restart ICMThe “Add to Certificate List” step is critical importing alone loads the certificate but does not add it to the trust store. Without this step, the handshake will still fail.Step 6: Test the RFC ConnectionAfter the certificates are imported and the ICM is restarted, go back to SM59 and test the connection. You should see HTTP 200 OK. If you still get the SSL error, verify that all certificates in the chain were imported and added to the certificate list.Step 7: Configure the ABAP SDK TablesThe ABAP SDK uses three configuration tables. Each Azure service interface requires entriesZREST_CONFIG – Interface to RFC MappingThis is the master table that links an Interface ID to an RFC destination.FieldValueInterface IDDEMO_AZ_ADRFC DestinationAZURE_ABAPSDKKDEMO-AAD (your SM59 destination)ZREST_CONF_MISC – Operational SettingsThis table controls the HTTP method, retry logic, and alert settings.FieldValueInterface IDDEMO_AZ_ADMETHODPOST (the OAuth token endpoint only accepts POST)MAX_RETRY1EMAIL_IDYour email address (for failure alerts)MAIL_BODY_TXTError text identifierRETRY_METHODLeave blankZADF_CONFIG — Azure-Specific ConfigurationThis table holds the authentication type, client secret, and processing mode.FieldValueInterface IDDEMO_AZ_ADInterface TypeAzure Active Directory (select from dropdown)SAS_KEYPaste your client secret VALUE from Azure Step 4URILeave blankSERVICE_TYPES (Synchronous)IS_TRYLeave blankThis table holds the authentication type, client secret, and processing mode.Important: The Interface ID must be exactly the same across all three tables. It is case-sensitive.Important: The Interface Type in ZADF_CONFIG determines which ABAP class the SDK factory creates. For AAD token generation, it must be “Azure Active Directory”. Setting it to anything else will result in a MOVE_CAST_ERROR at runtime.With this, the connection between Azure Active Directory and your SAP system is established.Now let us configure one more RFC destination To fetch data from Azure, we need API access to Microsoft Graph. This requires a separate RFC destination for the Graph API endpoint.Step 8: Create the RFC Destination for Graph APIOpen SM59 and create a new destination:Step 9: Configure Logon & SecurityFollow the same SSL certificate process to download the certificate chain from https://graph.microsoft.com, import into STRUST, restart ICM, and test the connection. You should get HTTP 200.Step 10: Configure the ABAP SDK Tables for Graph APInow Create entries in all three tables with a new Interface ID:ZREST_CONFIGFieldValueInterface IDAZ_GRAPHRFC DestinationAZURE_GRAPHZREST_CONF_MISCFieldValueInterface IDAZ_GRAPHMETHODGETMAX_RETRY1ZADF_CONFIGFieldValueInterface IDAZ_GRAPHInterface TypeMicrosoft Graph (select from dropdown)SAS_KEYSame client secret VALUE as DEMO_AZ_ADURILeave blankSERVICE_TYPESIS_TRYLeave blankImportant: The Interface Type for the Graph API interface must be “Microsoft Graph” not “Azure Active Directory”. The factory class uses this value to instantiate the correct service class. Wrong type means wrong class, which means a MOVE_CAST_ERROR.With this, the connection between Microsoft Graph API and your SAP system is established.Now let us test the connection with The ABAP SDKs existing program this includes a demo program called ZADF_DEMO_AZURE_GRAPH that can fetch users from Azure AD.Step 11: Open and Update the ProgramGo to transaction SE38 and open program ZADF_DEMO_AZURE_GRAPH. Update the Interface ID constants at the top of the program to match your configuration:Step 12: ExecuteRun the program (F8). On the selection screen:FieldValueSelect”Read Users” radio buttonAzure Client IDYour Application (Client) ID from Azure Step 3Step 13: Review the OutputThe program will request an AAD token from login.microsoftonline.com, call the Microsoft Graph API /users endpoint with that token, and display the user data in JSON format.If the program returns user data, your end-to-end integration is working. SAP is authenticating with Azure AD, calling Microsoft Graph API, and receiving data all of this from ABAP. What’s NextThat’s the complete technical setup of Azure side and SAP side. Two RFC destinations, three config tables each, and a working demo program pulling live user data from Azure Active Directory into SAP.But fetching data through a demo program is just the foundation. In Part 3, I’ll show you how to take this further by building a reusable ABAP class that wraps the entire Azure authentication and Graph API flow into a clean interface that can be consumed in to FPM UI in MDG Business Partner screen. That’s where this moves from a technical demo to a practical MDG solution.Stay tuned. Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
