Securing and Troubleshooting SAC Connections: Authentication, SSO, and Network Reachability
Learn how SAC connections authenticate to source systems, how single sign-on and technical users are configured for live and import connections, and how to systematically troubleshoot the most common connection failures in production.
Explanation
Once a connection type (live or import) has been chosen for a given source, the next critical decision is how SAC authenticates to that source and how network traffic actually reaches it. This lesson focuses on the operational and security layer of SAC connections, which is where most production incidents occur after go-live. For on-premise sources such as SAP BW or SAP HANA reached through live connections, SAC typically requires a connectivity path via SAP Cloud Connector (for BTP-based scenarios) or a direct reverse-proxy style setup, depending on the landscape. The Cloud Connector exposes specific on-premise system resources to the cloud tenant without opening the whole network, using virtual-to-internal host mappings. A live connection in SAC references a specific location ID and virtual host/port pair configured in Cloud Connector, so any change to the on-premise system's host, port, or SSL certificate must be reflected on both sides. Authentication for live BW/HANA connections is commonly implemented using SAML single sign-on trust between SAC and the source system, or in some scenarios a technical communication user; the exact supported options depend on the source system release and the deployment model, so this must be validated against current SAP documentation for the specific landscape rather than assumed. For cloud sources such as SAP Datasphere, SAP S/4HANA Cloud, or SAP SuccessFactors, connections are usually established through OAuth-based trust or pre-configured cloud integration channels, where a client is registered on the source side and a corresponding connection is created in SAC referencing that client. Import connections to file-based or database sources (for example, an ODBC-type or cloud storage connection) typically rely on stored credentials or key-based authentication, which introduces different rotation and expiry considerations than SSO trust. Troubleshooting connection issues follows a layered approach. First, isolate whether the failure is at the network/reachability layer (timeout, DNS, Cloud Connector not running or misconfigured) or the authentication layer (certificate expired, trust not established, user locked, insufficient authorizations on the source). SAC typically surfaces a generic error message in the UI, so the real diagnosis often requires checking Cloud Connector logs, the source system's security audit or trace logs, and the connection test feature within SAC itself, which usually validates reachability separately from data retrieval. Second, check whether the issue is connection-level (affecting all models on that connection) or model-level (affecting only specific queries or views, often due to changed or deleted objects on the source, or authorization restrictions specific to certain InfoProviders or Calculation Views). Third, consider recent changes: certificate renewals, source system upgrades, firewall changes, or password/credential expiry are the most frequent root causes of previously working connections suddenly failing. From a security governance perspective, connections should be reviewed periodically for stale technical users, overly broad authorizations, and certificate expiry dates, since a connection configured once during a project often gets forgotten until it silently breaks in production. Documenting the connection's authentication method, responsible owner, and renewal schedule as part of connection metadata significantly reduces mean time to resolution for these incidents.
Real project scenario
A production SAC dashboard built on a live connection to an on-premise BW system started failing intermittently every few weeks with generic 'data could not be retrieved' errors. Initial investigation focused on the BW queries themselves, wasting time, until the team checked Cloud Connector and found the SSL certificate used for the SAC-to-Cloud-Connector trust was nearing expiry and being renewed inconsistently by a separate infrastructure team without coordination with the SAC application owners. The resolution was to add the certificate expiry date to a shared operations calendar and assign joint ownership between Basis and the SAC platform team, eliminating recurrence.
Common mistakes
• Assuming a connection failure is always a query or model issue and not checking Cloud Connector or network layers first • Letting technical users or service accounts used for connections expire or get locked without an alerting process • Not documenting which team owns certificate renewal for SAC-to-on-premise trust, causing recurring outages • Granting overly broad source-system authorizations to a connection's technical user instead of scoping access to only the required InfoProviders or views • Ignoring the difference between a successful connection test and a successful data query, since a connection can test as reachable but still fail on specific model authorizations
Best practices
• Maintain a connection inventory documenting authentication method, technical user or trust owner, and renewal schedule for every SAC connection • Use the built-in connection test feature to isolate reachability issues before investigating model or query-level problems • Coordinate certificate and credential renewal schedules jointly between Basis/infrastructure teams and SAC platform owners • Scope technical users and service accounts to least-privilege access on the source system rather than broad administrative rights • Set up monitoring or alerting for connection health where the platform supports it, rather than relying solely on end-user error reports
Interview angle
Interviewers assess whether a candidate understands that SAC connection issues are rarely just an SAC problem: they expect you to describe a layered troubleshooting approach separating network reachability, authentication/trust, and authorization, and to explain the role of Cloud Connector for on-premise live connections, showing you have handled real production incidents rather than only initial connection setup.