Solution Manager as a Landscape-Wide Pivot

SAP Solution Manager’s core job is central technical oversight of the whole SAP landscape: system monitoring via the Computing Center Management System (CCMS), EarlyWatch Alert health checks, Custom Code Lifecycle Management, and patch/System Recommendations all require it to reach every managed system. In practice that means Solution Manager holds RFC connections - frequently Trusted RFC connections - to nearly every SAP system in the company, development through production.

That connectivity is exactly why it is a favored pivot target: Solution Manager itself carries little or no business data and few functional end users, so it is routinely perceived and secured as “just a technical system” rather than as the keys to the landscape it actually is. An attacker who cannot reach a well-hardened HR or finance production system directly can instead land on the comparatively soft Solution Manager and ride its pre-existing, firewall-approved RFC trust straight into it.

Two further specifics compound the exposure:

• Diagnostics/service accounts - Solution Manager Diagnostics (SMD) and the wider Solution Manager stack ship dedicated technical users (SMD_ADMIN, SMD_RFC, SMD_AGENT, SMD_BI_RFC, SOLMAN_ADMIN, and similar) that are frequently left on their SAP-shipped default password - see Default SAP users and passwords.
• Diagnostics Agents deployed on every managed system’s host connect back to Solution Manager and locally to that host, extending the trust relationship beyond the ABAP layer to OS-level monitoring reach on each managed server.

Compromising Solution Manager compromises the RFC-trust map of the entire landscape it manages: an attacker who obtains a foothold there inherits the ability to reach, and potentially impersonate privileged users on, every connected system via the same trusted-RFC mechanisms documented for RFC in general. Because Solution Manager is designed to touch every tier - development, QA, and production alike, across every business area - a single successful pivot from it can bypass network segmentation and access-control boundaries that were carefully built around each individual managed system. Default-password diagnostics accounts turn this from “requires exploitation” into “requires only reconnaissance.” Confidentiality, integrity, and availability impact extends to every system in scope of the Solution Manager instance, not just Solution Manager itself.

• Recon - enumerate Solution Manager’s outbound RFC destinations (SM59, RSRFCCHK) to map which managed systems it can reach and whether those connections are Trusted RFC; every connection found is a candidate pivot target.
• Default-credential check on diagnostics/service users - test SMD_ADMIN, SMD_RFC, SMD_AGENT, SMD_BI_RFC, SOLMAN_ADMIN and similar technical users for the SAP-shipped default password before attempting any exploitation; see Default SAP users and passwords for the full standard-user table and testing caveats (sequential testing, lockout awareness).
• Trusted-RFC impersonation from Solution Manager outward - once a foothold on Solution Manager is held, apply the trusted-RFC impersonation and callback abuse technique against its outbound connections; check each managed system’s S_RFCACL posture for the trusting/RFC_EQUSER/RFC_USER misconfiguration that allows arbitrary-user impersonation.
• S_RFC scope abuse - Solution Manager RFC users (often of user type System or Communication) are frequently over-scoped on S_RFC; an over-broad grant lets a compromised Solution Manager session call sensitive function groups on any connected system directly, independent of Trusted RFC status.
• Diagnostics Agent as a secondary pivot - where Diagnostics Agents are deployed on managed-system hosts, treat each as a potential local foothold on that host’s OS, extending reach beyond the ABAP layer.
• Cross-reference Critical RFC-enabled function modules for what becomes reachable once a usable RFC identity on a target system is established.

• Apply the same authorization-concept rigor to Solution Manager as to your most sensitive managed system - it is not “just technical.” Build a dedicated, minimal data-security and authorization concept rather than relying on default roles.
• Avoid Trusted RFC from Solution Manager to production systems wherever a conventional, password-authenticated connection meets the operational need; where Trusted RFC is used, leave RFC_USER blank in the target’s S_RFCACL so the connection cannot be used to assert an arbitrary identity (see trusted-RFC impersonation and callback abuse).
• Set unique, vaulted passwords for every SMD_*/SOLMAN_* diagnostics/service user immediately after installation; never leave them on the SAP-shipped default.
• Scope S_RFC for Solution Manager’s RFC users to only the function groups its monitoring/management functions actually require - avoid full function-group wildcards on System/Communication users.
• Restrict and monitor Diagnostics Agent connectivity and local OS privileges on managed hosts; treat each agent as a monitored trust boundary, not a blind spot.
• Include Solution Manager explicitly in the organization’s RFC-destination inventory and periodic review process (see RFC trusted systems and callback abuse mitigation guidance) rather than treating it as out of scope because it is “infrastructure.”

• Security Audit Log (SM20) on both Solution Manager and every managed system for RFC logons originating from Solution Manager’s system ID/client outside expected monitoring/patching activity windows.
• Any successful logon as SMD_ADMIN, SMD_RFC, SMD_AGENT, SMD_BI_RFC, SOLMAN_ADMIN, or similar diagnostics/service accounts - these should only ever authenticate via their designated automated function, never interactively.
• RSRFCCHK/SM59 drift monitoring on Solution Manager specifically, given its outsized blast radius - new or modified Trusted RFC destinations are high-priority review items.
• CCMS/Diagnostics Agent connection logs for unexpected agent registration or reconnection events on managed hosts.

• Book: SAP-Systeme schützen (Rheinwerk/SAP PRESS), Chapter 7 “Schutz des SAP NetWeaver AS ABAP”, §7.2 “Der SAP NetWeaver AS ABAP als Angriffsziel” - explicit “Solution Manager als Pivot-System” callout (p.168); Chapter 3 “SAP-Sicherheit – Standards und aktuelle SAP-Werkzeuge”, §3.5 “SAP Solution Manager als Steuerungsinstrument” (EarlyWatch, Security Self-Service, Custom Code Lifecycle Management, pp.97–99)
• Book: SAP Security and Risk Management (SAP PRESS), Chapter 19 “SAP Solution Manager”, §19.2 “Risks and Controls” and §19.4.3 “RFC Communication Security” - over-broad S_RFC risk on System/Communication RFC users, Trusted RFC risk management measures, S_RFCACL/RFC_USER guidance
• Default SAP users and passwords
• Trusted-RFC impersonation and callback abuse
• Critical RFC-enabled function modules
• Lateral movement