SAP Community - Martin Pankraz

Re: SAP Private Link service use cases for SAP Cloud Integration and SAP Build Work Zone, Standard E

2025-03-31T16:23:42.443000+02:00

@stag_pune SAP BTP is a Internet-facing app by design. SAP Private Link is the only option for hyperscaler specific private networking options by the platform uni-directional from BTP. Some individual SAP SaaS apps implemented further options for VPN or ExpressRoute without BTP as a platform. As it stands today you need to file a feature request to SAP to request further private networking features.

SAP Principal Propagation without Secrets: How Managed Identity in APIM Simplifies Everything

2025-05-02T11:01:42.574000+02:00

Dear community,

SAP Principal Propagation (for simplicity often also referred to as SSO) is the gold standard for app integration – especially when it comes to 3rd party apps such as Microsoft Power Platform. Building on top of my prior blog on API Management usage for SAP SSO, I am sharing today how you can fully eliminate the passwords or certificates for the token exchange previously required.

No more password storing or rotation. No certificates to renew. No manual key rollover scripts.

Thank god!

The Microsoft Entra ID authentication handshakes with services such as SAP BTP, SuccessFactors, Azure, or M365 apps like Power Platform allows these apps to become native, dynamic, and self-maintaining.

This shift not only tightens security by reducing the attack surface but also significantly accelerates project delivery, improves compliance with modern Zero Trust principles, and cuts down on administrative overhead. It’s a small architectural change with a big real-world impact — and a logical next step for enterprise-grade app integrations in the SAP ecosystem.

A glimpse under the hood

The magic? It’s called Managed Identity for Azure. With a user-assigned managed identity in API Management, the platform takes care of the authentication for you — clean, automatic, and secret-free. Building on top of Workload Identity Federation enables using a managed identity as a credential, just like certificate or password, on Entra ID Applications.

See following updated flow diagram from the prior blog. It highlights with red and yellow arrows where it was possible to “eliminate” credentials.

When browsing Microsoft Learn or additional blogs, look for the technical term “Federated Identity Credential” for additional details.

Solving this challenge on Azure API Management level enables scaling the approach to arbitrary many different consumer solutions.

Find the updated policy on the Azure API Management repos for SAP ECC and S/4HANA here and for SuccessFactors here.

Learn more about this space in general from the blog series by my magnificent colleague Martin Raepple.

Create a user-assigned managed identity for your Azure API Management instance

See additional details on this Microsoft Learn article.

Create a “managed credential”

This step is being referred to by Microsoft Learn as Federated Identity Credential (FIC).

Click Add Credential as per below screenshot from the manage secrets pane of your Entra ID app registration which represents your API Management instance.
Choose scenario “Managed Identity”,
Select the id of your user-assigned-managed identity created before, and
Make sure the audience is listed as “api://AzureADTokenExchange”.

Import the updated policy

Navigate to your SAP OData API on Azure API Management and use the Azure portal UI to paste the policy as code, or leverage infrastructure-as-code with your devops pipeline to apply SAP Principal Propagation at scale. See this Azure Developer CLI sample using Bicep for reference.

See the APIM policy line doing the magical managed identity request. It is as simple as that:

<authentication-managed-identity resource="api://azureadtokenexchange" client-id="{{APIMUserAssignedManagedIdentityId}}" output-token-variable-name="msi-access-token" ignore-error="false" />

The rest happens under the hood.

Learn more about policy creation including Microsoft Copilot usage from this article and this video. In case you fancy GitHub Copilot apply the VS Code extension. See this community post for further inspiration.

Consider the governance and security trade-offs between mighty policies and SAP OAuth clients authorized for everything vs. a multitude of clients for each API and scope.

Configure the policy using named values

The configuration exercise is 99% the same as outlined in the earlier blog “SAP OData connector now supports OAuth2 and SAP Principal Propagation” before. However, now we replace the client secret setting for the Entra ID app registration that represents your API Management instance with the client id of your user-assigned managed identity.

Fill the values as per your environment:

Key	Value sample	Hints
AADTenantId	12a345bc-1234-56ab-78ab-zzzzzzzzz	Find it on the Azure portal (e.g. here)
APIMAADRegisteredAppClientId	999abce-7777-abcd-a6c9-zzzzzzzzzzz	The Application (client) id of the Entra ID app registration representing your Azure API Management instance.
APIMUserAssignedManagedIdentityId	7777abce-7777-abcd-a6c9-zzzzzzzzzzz	Client ID of user-assigned managed identity of APIM instance
AADSAPResource	https://a4h100	The provider’s name from your NetWeaver SAML setup. Typically, a URL with SID followed Client number
sap-oauth-client-username	ODATAOAUTH	User name provided on SOAUTH2 transaction (/sap/bc/webdynpro/sap/oauth2_config?sap-client=100) Create a named user on SU01 with minimum rights (S_SCOPE, S_SERVICE) and reference that on SOAUTH2. Don’t forget to assign authorized scope.
sap-oauth-client-password	Password for that oauth user	This is only used to request tokens not to authenticate to SAP.
sap-oauth-scope	ZPRODUCTSVIEW_CDS_0001	The scope assigned on SOAUTH2
SAPOAuthRefreshExpiry	86400	Option to set refresh token expiry (default on SAP 2 years). It is not part of the token response.
SAPOAuthServerAdressForTokenEndpoint	a4h-internal.cloudapp.net:44301	Host and port of the target SAP OAuth server. When SAP cloud connector is used, put the virtual hostname and port.

Hints on troubleshooting

There was good feedback on the Postman collection to verify proper SAP Principal Propagation setup. Be aware that the on-behalf-of flow step to request the SAML assertion from Entra involving the managed identity cannot be tested via a REST client from your local device, because only Azure services are trusted for the request.

In general, I would recommend testing the auth flow with the least components involved as possible to reduce problem surface. Meaning, test with a REST client of your choice with client secrets to make sure that your SAP SSO setup and OAuth settings are working. Keep the API Management part and managed identity to after successful initial integration with SAP.

The wider integration context

Q: Does Managed Identity for Azure work only for SAP on Azure?

A: No, using Azure API Managment self-hosted Gateway you can bring that capability any-premises. Besides deploying the gateway directly into your local network, consider also Azure public cloud routing options (ExpressRoute, NVAs, VPN, etc.)

Q: SAP Cloud Connector already supports Principal Propagation for on-premises. Why would I choose this managed identity approach?

A: SAP Integration Suite using SAP Cloud Connector for instance is a prime choice - well established and mature. Nothing wrong with that. Still the credentials need to be managed. You may consider a hybrid where Integration Suite realizes connectivity, while Managed Identity for Azure provides passwordless token requests. Be aware to avoid configuring Principal Propagation twice (OAuth2SAMLBearer flow vs. the Cloud Connector setting with short-lived x.509 certs)

Thoughts on production readiness

Managed Identities are a well-established platform feature on Azure with large scale adoption across services. Furthermore, it is the recommended way of configuring service to service authentication.

Credentials remain in place for the SAP OAuth server as per its OAuth2 flow capabilities. Halfway there so to say. Luckily, token users have a much lower risk profile than actual users.

Final Words

That’s a wrap 🌯. Today you saw how SAP Principal Propagation goes secret-less on Microsoft Entra ID — no passwords, and no certificates. Entra ID with Managed Identity handles it all, mapping Microsoft identities to SAP users while keeping your authorizations intact.

This is what native, secure integration should look like.

👉If you’re still managing credentials manually in 2025, it’s time for an upgrade. It only gets worse from here: Certificate authorities agreed to reduce lifespan to 47 days in stages over the next 1-3 years.

Cheers Martin

SAP LeanIX integrating Microsoft Defender for Cloud Apps

2025-05-06T10:33:38.725000+02:00

When Enterprise Architects and IT Security Speak the Same Language

This blog was co-authored by @Michelle10 (PM @ SAP LeanIX)

Dear community,

In most enterprises, IT security and enterprise architecture are two critical disciplines, each with their own priorities, tools, and perspectives. One is laser-focused on threat detection, compliance, and access control. The other is mapping capabilities, rationalizing applications, and shaping long-term IT strategy.

What happens when these personas complement each other – not just in theory, but in tooling?

That’s exactly where the integration between SAP LeanIX and Microsoft Defender for Cloud Apps comes in.

But wait, what about my managed apps governed by my corporate identity provider? No worries, SAP LeanIX may be integrated with Microsoft Entra ID for discovery and keeping track which apps have SSO etc. as well.

Connecting Two Worlds

Microsoft Defender for Cloud Apps is your frontline for SaaS security and governance to detect threat attacks that arise from your SaaS app interactions and reduce the exposure to such attacks. Furthermore, it helps security teams uncover shadow IT, assess risk, and monitor data flows across

SAP LeanIX, meanwhile, gives enterprise architects the visibility they need to manage complexity – mapping applications to business capabilities, tracking lifecycle data, and supporting IT transformation.

The magic happens when you combine them.

From Discovery to Decision-Making

With this integration, you can pull application usage and risk data from Defender for Cloud Apps directly into SAP LeanIX. That means:

Security teams discover new or risky SaaS apps…

…Architects contextualize those apps within business functions and processes.

You’re no longer just identifying what’s out there - you’re aligning it with your architecture strategy. This turns ad-hoc discovery into intentional governance.

Business Outcomes

Eliminate shadow IT with traceable business context.
Support rationalization with usage-driven decisions.
Align security and strategy with shared data and mutual visibility.

Why It Matters

This integration fosters collaboration between two personas that often operate in parallel but rarely intersect. With Microsoft Defender for Cloud Apps and SAP LeanIX, they do - bringing security and architecture into a shared conversation around risk, capability, and value.

The result? Better decisions, stronger governance, and a much clearer view of your SaaS landscape. All powered from the Defender and Entra ID APIs. Not too bad, huh?

This is how modern IT operates: cross-functional, data-driven, and strategically aligned.

Get Started

Anyone curious about uncovering shadow IT and making better SaaS app decisions? Just reach out to me and Michelle or leave a comment.

Cheers

Martin & Michelle

______________

References:

Re: SAP Principal Propagation without Secrets: How Managed Identity in APIM Simplifies Everything

2025-05-06T13:32:27.628000+02:00

@vbalko-claimate good question. Added a small Q/A section on that.

Re: Integrating low code solutions with Microsoft using SAP Integration Suite has never been easier!

2025-05-07T13:15:39.896000+02:00

@JorgeCalderon the jwt token from caller is part of the standard Authorization header. The sender in my scenario was the SAP OData connector in PowerAutomate. Cheers Martin

How to customize your SAP LogServ solution in Microsoft Sentinel - Part 2

2025-05-23T16:18:26.636000+02:00

Find your way to our central blog series entry here.

Dear community,

Following the product release blog by SAP regarding the integration of SAP LogServ and Microsoft Sentinel, I am going to share some details on customizing the solution to your needs.

The SAP LogServ service in SAP RISE, private cloud edition, gets you access to all the logs produced by the underlying services managed by SAP ECS. Microsoft Sentinel without LogServ is limited to the application layer only. LogServ holds the promise to get a glimpse into the inner workings of RISE to…

Satisfy your auditing needs, and
Integration with the SIEM solution Microsoft Sentinel.

However, ALL logs are a bit much for many of you and the security value varies a lot. This blog gets you started to make cost conscious decisions while not compromising too much on threat protection insights. The most discussed log in my conversations so far was SAP HANA database.

Which logs should I choose?

That needs to be answered based on your needs, what is available, and what you want to achieve. Some just want all logs to store beyond the 365 days covered by LogServ, others only want the HANA DB log, and some want a specific subset across gateways, network, and database. For an up-to-date list always check with SAP.

Here is my opinionated subset that serves as an intro to the topic with no ambition for completeness. Otherwise, this becomes a master thesis kind of thing😉

LogServ source	In Scope of your shared responsibility	Threat Protection value	Chattiness (volume indication in t-shirt sizes)	Comment
OS (Linux + Windows)	No	Medium	L	Without integration into your EDR less relevant
Database (HANA, ASE, DB2, etc.)	Yes	High	M	Audit relevant
Web Application Firewall	No	Medium	XL	Only http connection info and routing without context
Load Balancer	No	Low	L	Layer 4 /TCP/IP) communication only without context
Network, Flow Logs	No	Medium	XXXL	Useful to trace back lateral movement on a compromise
SAP Cloud Connector	Yes	High	M	Audit log holds all info on connections from SAP BTP
SAP Web Dispatcher	No	Medium	L	Only http connection info and routing with IPs from last hop rather than original client.
ICM	No	Medium	L	Same challenge as with Web Dispatcher.
SAP Gateway (OData)	Yes	Low	M	Mostly exceptions on OData requests. SAP Cloud Connector audit log covers this with higher value.
…

For the latest list of LogServ source folder names etc. consult with SAP and their documentation.

Be aware, for AS ABAP and AS JAVA security audit log integration you still require the agentless Sentinel Solution for SAP. See the overview diagram in SAP’s blog for more details on the LogServ Addon in combination with the Sentinel for SAP.

How do I select those logs?

SAP published a native solution to Microsoft Sentinel. By using the Microsoft platform, you may configure the ingestion rule on the Data Collection Rule instance in Azure.

Once you have deployed the LogServ connector on Sentinel, you can browse the same Azure resource group to identify your generated Data Collection rule. It will read something like “-SAPLogServDCR-”. Tailor the existing Kusto Query Language (KQL) transformation to your needs (step 4). The default one takes all logs.

Consider the kql snippet below to filter the log by types. In my sample the data collection rule only accepts HANA db, Linux OS, and DNS.

let fromUnixTime = (t: real) {
    datetime(1970-01-01) + t * 1sec
};
source
| extend TimeGenerated = fromUnixTime(_time)
| extend Raw = _raw
| extend UnixTimestamp =_time
| where clz_dir in ("hana", "linux", "dns")
| project-away  _raw, _time

You have full control over your selections. For audit relevant long term retention consider the data lake tier. SAP LogServ data is being mirrored to the Sentinel Data Lake for the same period of time as your Analytics tier setting (typically 30 days). You can extend that period on the lake up to 12 years at low cost. Learn more about security data lake tiers here. See a video on capabilities here.

By design the LogServ connector comes with a built-in table in Analytics tier set up for real-time SAP threat protection needs. The table is called SAPLogServ_CL. Weigh retention time, real time needs, and storage cost. See this article for additional details and tier comparison.

Microsoft recommends to distinguish between primary (critical, real-time monitoring) and secondary security data (infrequently needed, compliance data, high-volume). The security data lake tier reflects that with capabilities and cost.

What about network traffic cost (ingress)?

Great, the data collection rule takes care of cost-efficient log ingest based on customizable filters, but what about the involved network traffic? At the time of writing and since many years all ingress to Azure from outside is free.

When in doubt, check the official Azure Bandwith pricing page for the latest info.

Final Words

That’s a wrap 🌯. Today you saw how a single line of KQL (Kusto Query Language) makes all the difference between drinking from the SAP RISE logs firehose that is SAP LogServ and selectively choosing SAP logs that mean something to your use case. The Microsoft Sentinel Data Lake powers your long term retention needs while the "hot" Log Analytics tables power your SAP real-time threat protections .

Get started with your deployment from here. Stay tune for more detections and security content.

What use cases and detections are you implementing with LogServ and Microsoft Sentinel? Let me know in the comments or reach out directly.

Cheers Martin

Ultimate Blog Series: SAP LogServ Integration with Microsoft Sentinel

2025-06-13T09:16:46.846000+02:00

TLDR; let me deploy already (scroll down there to the prerequisites section)!

Welcome to the landing page of this blog series on the SAP LogServ solution in Microsoft Sentinel. Find all the things you always wanted to know and more.

Beyond Application Monitoring: Complete SAP RISE Visibility

Running RISE with SAP, S/4HANA Cloud Private Edition, or SAP Cloud ERP private? Microsoft Sentinel by itself already delivers powerful SAP application-layer monitoring – tracking SAP user activity, business transactions, and critical events while correlating them with threat signals across your entire IT estate. That's just the beginning.

SAP LogServ is an optional service in your SAP Cloud ERP private package that unlocks access to all logs from SAP's managed services. It takes your security posture to the next level by extending Sentinel's reach deep into your infrastructure managed by SAP. Think complete HANA database insights, system-level security telemetry, and audit trails - all flowing seamlessly into your existing security operations workflow.

The result: Your security team finally gets full visibility into the managed SAP stack, from business logic to infra to database layer.

What This Series Covers

Comprehensive guidance from planning your LogServ + Sentinel deployment, log selection, customizing the solution, to advanced threat protection. Blogs are co-authored by SAP SE and Microsoft engineering.

Part	Topic
Limited Preview Announcement Lead author: Hemanth	Initial introduction to the solution and integration between LogServ and Microsoft Sentinel
General Availability Announcement Lead author: Hemanth	Deployment overview with Step-by-step SAP LogServ connector setup in Sentinel, insights on prerequisites
Part 0: First Smoke test Lead author: Martin	Due to the asynchronous integration between SAP LogServ and Microsoft Sentinel, it's advisable to perform a smoke test yourself before sharing your config data with SAP for speedy onboarding. Here is how.
Part 1: Microsoft Sentinel for SAP goes agentless Lead author: Martin	SAP ERP Application layer integration with agentless data connector in Sentinel Solution for SAP
Part 2: How to customize your SAP LogServ solution in Microsoft Sentinel Featuring: Sentinel Data Lake Lead author: Martin	Understand log types available in LogServ (volume, cost, threat protection value, etc); how to filter logs, configure long term retention for compliance needs, and how to customize the solution in Sentinel to optimize cost,
Part 3: Deploy built-in detection rules and extend to your needs Lead author: Martin	See the already available analytic rules shipped by SAP, and discover how to craft your own based on your needs
Part 4: Observability of SAP LogServ on Microsoft Sentinel Lead author: Martin	Gain operational insights with the built-in Workbook on Microsoft Sentinel for SAP LogServ. Understand log ingestion patterns, create alerts for anonmalies, and discover available sources visually.

Target audiences: SAP Basis admins, security architects, SOC analysts, and compliance teams looking to enhance their SAP monitoring capabilities.

Architecture Overview

Reference diagrams for planning your implementation

Detailed Component Architecture

High-Level Integration Flow across the whole stack

Ready to transform your SAP Cloud ERP private security posture? Let's get started from here.

Which logs from RISE do you need most? Let me know in the comments or reach out directly.

Cheers Martin and Hemanth

Deploy built-in SAP LogServ detection rules in Microsoft Sentinel and extend to your needs - Part 3

2025-07-02T14:13:55.796000+02:00

Find your way to our central blog series entry here.

Dear community,

Following the product release blog by SAP regarding the integration of SAP LogServ and Microsoft Sentinel, I am going to share some details on the built-in detection rules and how you can build upon them.

The most discussed log in my customer conversations so far was SAP HANA database. So, let’s start with that.

Discover the available built-in detections from the Content Hub

Find the relevant section both from the Azure or the unified Defender portal under Rule templates in the Analytics section. They are available from version 3.0.2 of the SAP LogServ solution.

Typical database threat scenarios involve tampering with audit log settings, admin authorizations or privileged role assignments.

We have taken the existing battle-proven Microsoft Sentinel Solution for SAP rules for HANA DB and translated them to be compatible with the LogServ schema. The raw log source is Syslog in both cases. So, the only remaining step was “unboxing” of the JSON wrapper.

To understand the individual columns of the LogServ output, see SAP’s HANA Audit Trail Layout for Trail Target documentation. For ease of use we have numbered the columns and applied the same names SAP mentions on their docs.

Activate the new rules

Navigate to the Analytics pane and select the rule you want, click “Create Rule” from the button with the three dots and follow the configuration wizard. See the severity classification and pre-defined MITRE attack framework mapping. These mappings help streamline your SOC analysts’ triage efforts.

Verify the rule execution schedule and consider automated responses where feasible. Creating ServiceNow tickets for instance is a popular action. See my dedicated blog series on SOAR for SAP for inspiration.

From the “Review + Create” section click save. Your rule is now live!

Build upon or extend the provided analytic rules

Since the Kusto Query is fully transparent to you (see above screenshot) it is easy to derive your own tailored scenarios from it.

For instance, take analytic rule “Deactivation of Audit Trail” and extend the client IP address attribute (client_ip_address__col_7) to project in plain English if that is an internal or external IP.

| extend GeoLocation= iff(ipv4_is_private(client_ip_address__col_7),
dynamic({"IsPrivate": true}),
geo_info_from_ip_address(client_ip_address__col_7))

I have a feeling this might be of interest during your incident triage process 😉

Final Words

That’s a wrap🌯. You saw today how to discover the built-in analytic rules of the SAP LogServ solution in Microsoft Sentinel and how easy it is to extend them for your own individual needs. The rule catalog gets extended continuously based on customer demand.

Your existing investments in SAP infrastructure detections in Sentinel can easily be made compatible with the LogServ schema, because SAP simply forwards the logs unaltered as raw messages. The only required step is the unboxing of their JSON root message.

#Kudos to @Hemanth_Kusampudi and team for the partnership.

Get started with your deployment from here today.

Which detections or analytic rules for RISE do you need most? Let me know in the comments or reach out directly.

Cheers Martin

First smoke test after SAP LogServ solution deployment in Microsoft Sentinel - Part 0

2025-07-02T14:34:47.839000+02:00

Find your way to our central blog series entry here.

Dear community,

Due to the asynchronous integration between SAP LogServ and Microsoft Sentinel, it's advisable to perform a smoke test yourself before sharing your config data with SAP. This helps confirm if your receiving connector setup works and ensures the correct configuration will be shared with SAP the first time round.

Run a smoke test for ease of mind

Once the SAP LogServ push-connector is deployed on Microsoft Sentinel, you can start posting data towards its data collection endpoint. Use the provided REST client collection, or scripts to replicate the exact requests details that LogServ is performing too.

Maintain the variables as per your environment, see the LogServ sample payload and start posting. A working request shows http code 204 with no content on the response. See a sample output from the provided powershell script for reference. I prefer REST clients but people are different 😎

Find the parameters from the SAP LogServ Sentinel connector wizard on initial connect (see screenshot below). You can also get them directly from the individual resources. The data collection endpoint and data collection rule are created in the same resource group as your Log Analytics workspace underpinning Sentinel. They are prefixed with “SAPLogServ”. The app registration on Entra ID can be found from the Entra Application ID field.

Use the 2 KQL queries below to inspect your first data entry on the SAPLogServ_CL table in Sentinel.

SAPLogServ_CL
| take 10

SAPLogServ_CL
| summarize count() by clz_dir, clz_subdir
| order by clz_dir asc, clz_subdir asc

Wait a minute or two on first try. The population of new tables takes a short time initially.

Alternatively, deploy the SAP LogServ insights workbook on Sentinel for visual oversight.

Once saved to your workspace, start looking for the smoke test result. It covers all your observabilty needs going forward.

Hurray you have a functioning data collection endpoint for the SAP LogServ data🎉

Now, continue your onboarding journey by sharing the config data with SAP over your chosen channel. Find the details on SAP's blog here.

What if you don’t see the data entry on the LogServ table?

Verify the connection details: Did you really hit the right endpoint? Are you looking in the right tenant and log analytics workspace?
Verify selection criteria: Is your Time range filter accurate? The smoke tests create entries for NOW or 30mins earlier in UTC.
Did enough time pass on the initial table population? Consider a retry of the KQL query.
Verify the Data collection rule has not been changed to filter all results or similar. See this blog part and KQL snippet for more details.

Deployment fully messed up?

The simplest way to a fresh start is a delete and redeployment of the Log Analytics workspace. In case that is not an option you need to delete the LogServ connector resources to reset the LogServ solution in Sentinel. The data collection endpoint, data collection rule and entra id app registration can be deleted from the Azure portal. But the data connector itself needs to be deleted via API.

For your convenience, use this REST API request collection to drop the resources. Once performed the LogServ connector UI will activate the deploy button again. In case you went fully bazooka and also deleted the SAPLogServ_CL table from your Log Analytics worksapce that needs to be reverted too. If the table had data you need to run a restore operation from Azure CLI.

Final Words

That’s a wrap🌯. You saw today how to streamline your onboarding experience of SAP LogServ in Microsoft Sentinel. Simple smoke tests ensure a speedy onboarding and confidence in the shared setup configuration.

#Kudos to @Hemanth_Kusampudi and team for the partnership.

Get started with your deployment from here today.

Cheers Martin

Gaining Operational Insights with the SAP LogServ Workbook on Microsoft Sentinel - Part 4

2025-07-29T09:54:55.825000+02:00

Find your way to our central blog series entry here.

Dear community,

Following our previous deep-dives into LogServ usage with Microsoft Sentinel for SAP and customization, let's explore the operational insights available through Sentinel's built-in workbook for SAP LogServ monitoring.

Near real-time visibility atyYour fingertips

The SAP LogServ Insights Dashboard on Azure transforms raw log data into actionable intelligence. Navigate to Microsoft Sentinel > Workbooks > Templates and locate the pre-configured dashboard.

Save to your workspace and open to get started. Make sure to select the Log Analytics workspace powering your Sentinel tenant first.

Key metrics that matter

The workbook provides comprehensive monitoring across four critical dimensions:

Total Events: Track log ingestion volumes (4M events shown)
Active Systems: Monitor connected hosts (36 active systems)
Data Freshness: Near real-time status indicators with color-coded alerts
Log Distribution: Understand log ingestion patterns across your SAP landscape components

The Log Volume Timeline reveals ingestion patterns, helping identify peak usage periods and potential anomalies. Notice how the 24-hour view shows consistent data flow with the characteristic SAP workload patterns.

Pay attention to the status legend: Fresh (green), Recent (orange), Older (red), and Stale (dark red). These indicators help SAP Security and SOC teams quickly assess data currency - critical for incident response.

The workbook automatically refreshes, ensuring your security operations center maintains current visibility into your SAP RISE environment's log ingestion health.

Proactive Alert Configuration

Transform workbook insights into actionable alerts using the Create Alert Rule button visible above the timeline. This creates Azure Monitor alerts directly from your LogServ metrics, enabling threshold-based notifications for critical scenarios like data ingestion anomalies or system connectivity issues. Configure alert rules to monitor total event volumes, data freshness status changes, or active system counts falling below expected baselines.

Azure Monitor's alert engine integrates seamlessly with action groups for email, SMS, Microsoft Teams, or webhook notifications to your operations team. For detailed configuration guidance, reference the Azure Monitor alerts documentation.

For those of you who prefer PowerBI for dashboarding...

See this Microsoft Learn article how to craft a dashboard from the Microsoft Sentinel queries for SAP LogServ.

Final Words

That’s a wrap🌯. You saw today how to observe log ingestion health and use data freshness indicators for your SAP LogServ solution in Microsoft Sentinel. The built-in views are easy to extend and customize for your own individual needs.

#Kudos to @Hemanth_Kusampudi and team for the partnership.

Get started with your deployment from here today.

What visuals are most helpful for your daily operations? Do you want special breakdowns for HANA database, and proxy components like the SAP WebDispatcher? Let us know in the comments or reach out directly.

Cheers Martin & Hemanth

Re: Deploy built-in SAP LogServ detection rules in Microsoft Sentinel and extend to your needs - Par

2025-09-23T17:05:26.744000+02:00

Hey @Utkarsh1113, this blog us about logserv integration. See BTP related integration here. Any detection logic on user priveleges can be applied. Deactivating access requires use of playbooks and BTP api calls however. See this sample here regarding SAP CIS for inspiration.

Cheers Martin

Re: SAP LogServ integration with Microsoft Sentinel for SAP RISE customers is now GA.

2025-09-24T10:21:43.700000+02:00

@krishnakbhat SAP has a LogServ document they share as part of RISE conversation which details this integration. Beyond that there is the official Microsoft reference here.

Finally, pointing out this is SAP's official blog page and the post authored by the product lead of SAP LogServ.

Let us know if doubts remain.

Re: SAP Principal Propagation without Secrets: How Managed Identity in APIM Simplifies Everything

2025-09-30T21:08:16.013000+02:00

Hey @m1m,

your scenario is described in another part of the series here. Injecting optional IAS on top of the mandatory components is not described. Complexity and points of failure increase of course. Let the community know how you get on.

Cheers Martin

SAP Ariba is now integrated with Microsoft Sentinel Solution for SAP

2026-02-09T13:34:21.343000+01:00

Quick link to GitHub.

Supply chain is a critical topic in almost every industry these days. We live in times where a controversial social media post and actions of government officials can disrupt factory operations almost the next day. See this Reuters (2025) article that sheds light on car production halt in Germany caught in the crossfire of political turmoil in 2 other countries. SAP Ariba helps diversify the risk between buyers and suppliers in tightly interconnected supply chains.

What a juicy target for cyber criminals one might say 😉

Therefore, meet the new kid on the blog when it comes to Microsoft Sentinel for SAP integration – SAP Ariba.

This cloud-native integration adds real-time threat detection, investigation, and response to your SAP Ariba environment and puts it into the context of your wider IT estate.

The bigger picture

Attackers use the easiest way in. Each month the SAP Security Patch Day starts a new race between hackers and defenders despite responsible disclosure obligations to allow a head start to defenders on reported vulnerabilities etc.

This race wears down defenses eventually – a gap is deemed to happen. Therefore, you need to be prepared to identify attackers in your IT landscape and be quick to lock them out again before they reach valuable targets.

Seeing the context and trail of the interconnected signals that the attacker leaves behind are key to identify compromise.

How It Works

Create an application on your Ariba Developer portal to allow access to the audit-search api and collect your API key.
Deploy the latest Microsoft Sentinel integration package in SAP Integration Suite. See this video for a similar scenario for guidance. Ignore the ERP specific settings on Cloud Connector etc. They don’t apply to Ariba.

3. Configure a Destination on SAP BTP for your Ariba instance and the audit search api.

Property	Value	Description
Name	Ariba-[TenantId]	Destination name (e.g., Ariba-p2pTeSap-2)
Type	HTTP	Connection type
URL	https://[region.]openapi.ariba.com/api/audit-search/v2/[prod or sandbox]	SAP Ariba Audit Search API URL (Find your base URl under Configuration Details)
Proxy Type	Internet	Always internet because of the cloud nature of the SAP service
Authentication	OAuth2ClientCredentials	For productive use
Client ID	[ClientId]	if applicable
Client Secret	[ClientSecret]	if applicable
Token Service URL	[TokenEndpoint]/v2/oauth/token	Ariba OAuth token endpoint

Additional Properties	Value	Description
tenantId	[TenantId]	SAP Ariba tenant ID
apiKey	[apiKey]	Api key for your SAP Ariba tenant

4. Deploy the agentless data connector for the Microsoft Sentinel Solution for SAP. See this video for a walk-through of the first steps and the official Microsoft Learn page here. Ignore the ERP specific settings on Cloud Connector etc. They don’t apply to Ariba

5. Connect your Ariba flow on the data connector pane to start ingesting SAP Ariba logs.

6. On the Advanced section supply the path “/community/SAPAribaAuditSearch” to point at the default route of the Ariba iFlow on SAP Integration Suite.

Observe the message flowing on Cloud Integration and Microsoft Sentinel. You can use the following query to verify the Ariba logs. Filter by AgentGuid in case you have multiple connections:

SAPAuditLog
| where AgentGuid == "Ariba"

Congratulations, you have successfully onboarded SAP Ariba to Sentinel for SAP 😎

There is one more thing!

Many of you are fronting Ariba with the SAP Cloud Identity Services. When you consult the attack graph from the beginning of this post, you already know that this is an important signal in the attack story. Identity compromise remains the number one attack path even in 2026. Have a look at the Digital Defense Report 2025 for more details.

Onboard your SAP Cloud Identity Service amongst your SAP BTP subaccounts to Sentinel for SAP from here to close that loop.

What you see is what you get

AI enabled unified Security Operations

Correlate SAP Ariba events with enterprise telemetry in Microsoft Sentinel Solution for SAP and Microsoft Defender XDR ready for Microsoft Security Copilot.
Use prebuilt analytics rules, workbooks, and SOAR playbooks to detect and respond to threats like:

Privilege escalations
Unauthorized configuration changes
Suspicious transactions

Compliance-Ready Log Retention

Store SAP logs cost-efficient in Microsoft Sentinel Data Lake for up to 12 years.
Support threat hunting involving SAP on the Sentinel Data lake through KQL jobs.

What’s Next

Enriching the mapping of the Ariba logs further to activate the remaining analytic rules provided by the SAP ERP private cloud offering.
Adding further Ariba specific detections. Which ones are top of mind for you? Reach out to me.

Final Words

That's a wrap 🎬 you saw today how simple SAP Ariba integration with your SIEM product can be. Remember: bringing SAP apps under the protection of your central SIEM isn't just a checkbox - it's essential for comprehensive security and compliance across your entire IT estate.

Quick link to GitHub.

#Kudos to Syed Ammad Hussain Shah for his contributions during the early preview.

Feel free to reach out to talk more SAP Ariba.

Cheers, Martin

Re: SAP Ariba is now integrated with Microsoft Sentinel Solution for SAP

2026-02-10T18:46:50.165000+01:00

@YashikaYTD what threat scenario would that be? Can you elaborate? Happy to add when the scope checks out.

Configure certificate auth for Microsoft Sentinel with S/4HANA Cloud public edition

2026-02-11T09:57:05.546000+01:00

Configure client certificate authentication for Microsoft Sentinel Solution for SAP integration with S/4HANA Cloud public edition

Quick link to GitHub.

For many SAP S/4HANA Cloud public edition APIs basic authentication is the default. SAP recommends client certificate use for production tenants.

This article shows you how to use client certificate authentication with your Microsoft Sentinel Solution for SAP integration. Security Audit Log API serves as an example. Approach applies to any of your APIs governed by communication arrangements.

How It Works

Instead of the native connector – which is limited to Basic Auth – choose the Sentinel for SAP extension package on SAP Integration Suite for full flexibility.

Create Communication Scenario SAP_COM_0750 the usual way.
Create a communication user for certificate authentication and upload your certificate. The built-in cert sap_cloudintegrationcertificate provided by every SAP Cloud Integration tenant is supported out-of-the-box for ease of use. For custom Client Certificates learn more from SAP's blog by @marc_roeder and ensure that the certificate signing authority is trusted by SAP. Find more details on SAP Note 2801396.

3. Configure a destination for your S/4HANA Cloud public edition tenant and set authentication to ClientCertificateAuthentication.

Property	Value	Description
Name	S4-PC-[SID]-[Client]	Destination name (e.g., S4-PC-YKJ-100)
Type	HTTP	Connection type
URL	https://[tenant]-api.s4hana.cloud.sap	S/4HANA Cloud system API URL
Proxy Type	Internet	Always internet because of the cloud nature of the SAP service
Authentication	ClientCertificateAuthentication	Authentication methods supported by S/4HANA Cloud public edition
Key Store Source	ClientProvided	this will be used as trigger for the iflow to use X509
Key Store Location	(empty)	not applicable
Key Store Password	(empty)	not applicable

This setting is evaluated during runtime on the iFlow. See below Screenshot for reference:

4. Deploy the latest Microsoft Sentinel extension package in SAP Integration Suite. See this video for a similar scenario for guidance. Ignore the ERP specific settings on Cloud Connector etc. They don’t apply to public cloud.

Deploy the agentless data connector for the Microsoft Sentinel Solution for SAP. See this video for a walk-through of the first steps and the official Microsoft Learn page here. Ignore the ERP specific settings on Cloud Connector etc. They don’t apply to public cloud.
Connect your new iFlow on the data connector pane on Sentinel to start ingesting SAP S/4HANA Cloud public edition logs. On the Advanced section supply the path “/community/ SAPS4_Public_Cloud_Security_Audit_Log” to point the route at the S4 public cloud iFlow on SAP Integration Suite.

Observe the messages flowing on SAP Cloud Integration monitoring and Microsoft Sentinel for SAP.

You can use the following kusto query on Azure Log Analytics or Defender portal to verify the S4 logs. Filter by SystemId in case you have multiple connections:

SAPAuditLog
| where SystemId == "your SID"

Continue your onboarding with Analytic Rules

Both SAP’s native connector and the integration suite based approach post data to the SAPAuditLog structures in Sentinel. This way the built-in security content for the private cloud solution is automatically lit up for public cloud too.

Be aware that detections for legacy interfaces such as RFC are not applicable anymore because they are disabled in public cloud tenants.

Final Words

That's a wrap 🎬 you saw today how to elevate the security of your integration of S/4HANA Cloud public edition with Microsoft Sentinel Solution for SAP using client certificate authentication. Good job!

Cherry on the cake: You can save some maintenance by using the pre-provided certificate of SAP Cloud Integration. SAP takes care of renewal. Only remaining task is to update the communication user on S4. This API allows full automation of that step even. See this blog for details on the automatic refresh approach in a similar scenario.

Quick link to GitHub.

Feel free to reach out to talk more SAP Security.

Cheers, Martin

Re: SAP Ariba is now integrated with Microsoft Sentinel Solution for SAP

2026-02-21T20:28:18.885000+01:00

That would be more internal fraud, misconfiguration monitoring rather than threat protection by the looks of it.

Which API do you have in mind @YashikaYTD ?

Re: Integrating low code solutions with Microsoft using SAP Integration Suite has never been easier!

2026-02-25T16:57:31.039000+01:00

Hey @JorgeCalderon,

the flow requires a SAML assertion to be passed to the SAP OAuth server for exchange. This article describes how to get a trusted SAML assertion issued by Entra ID for any known client app that wants to talk to SAP. If you generate your own SAML assertion you obtain the responsibility of an IDP like Entra yourself with all the risks that come with it.

The flow can not be shortened without compromising security.

Let the community know what you decided and why in the end 🙂

Re: Integrating low code solutions with Microsoft using SAP Integration Suite has never been easier!

2026-02-27T11:51:54.333000+01:00

Hey @JorgeCalderon,

in case you have a secure way to obtain a SAML assertion from a trusted IdP you can of course skip that part of the token exchange on APIM (simplify the policy) and directly forward that to the SAP backend for the exchange to OAuth2SAMLBearer token.

Would be curious what client app you are using that causes this situation.

Re: Integrating low code solutions with Microsoft using SAP Integration Suite has never been easier!

2026-03-04T12:56:41.756000+01:00

Your step 2 is step 3 on the diagram of this blog. So, if your step 1 uses a JWT based login you have the same situation as described here.

Also be aware that the policy I co-published with SAP has more features like token caching and SAP Cloud Connector setup compared to the one you shared.

KR Martin