Connection string changes in Fabric Warehouse: What to expect for auditing (Generally Available)

Author: Pradeep Srikakolapu, Senior Product Manager

As Microsoft Fabric Data Warehouse continues to evolve, we are making updates to how connection strings are interpreted—specifically how the Initial Catalog (database) value influences connectivity behavior and downstream auditing.

These changes improve predictability, correctness, and security, but they can also impact how login and audit events appear, especially for applications that connect through master before switching databases.

This post explains:

• What is changing in connection behavior
• How Initial Catalog affects where a session lands
• Why some login events may not appear in audit logs
• How to achieve full audit traceability

Connection string behavior: What’s changing

Historically, some connection scenarios resulted in Fabric routing sessions to a random warehouse in a workspace when the database context was ambiguous or invalid. This behavior is changing to make connections deterministic and explicit. The following list offers a summary of behavior changes:

Figure: Current vs. expected connection behavior based on the Initial Catalog value (after the fix, ambiguous/invalid catalogs default to master, and missing warehouses result in an error).

How initial catalog impacts auditing

Fabric Data Warehouse auditing is artifact‑scoped (database‑scoped)—not workspace‑ or server‑scoped. This means audit events are emitted only when a session has a valid warehouse (database) context. As a result, how a connection starts directly impacts audit visibility. Because auditing is database‑scoped, the presence (or absence) of Initial Catalog during login matters.

Auditing design principle

• Audit events require a valid user warehouse context.
• Sessions that start without a database context (for example, on master) cannot emit database audit events.
• This is by design and consistent with existing system behavior.

Connection scenarios and audit visibility

Connection lands directly on a warehouse—the recommended and fully auditable pattern.

When this happens:

• Connection string specifies a valid warehouse name or ID.
• UX establishes the database context before running queries.

Audit behavior:

• Login event is recorded in the warehouse audit log (if auditing is enabled).
• All subsequent activity is audited as expected.

Connection lands on master, then switches database—this behavior is expected and aligns with current system design.

When this happens:

• No Initial Catalog is provided
• Initial Catalog=master is explicitly specified
• Application connects to master and later runs USE [db]

Audit behavior:

• Initial login event is not recorded in warehouse audit logs
  (no artifact context at login time)
• After USE <db>, subsequent queries are audited under the target warehouse
• The original login event permanently remains absent from database audit logs

Important:
Authentication events are captured through the DBAs action group (Database Authentication). If auditing is enabled but this action group is not included in the audit configuration, those events will not be logged.

In scenarios where the connection starts on master, the initial authentication event still won’t appear in the warehouse audit log because there is no warehouse context at login time. After the session switches context with USE [db], subsequent events configured for capture—such as Batch Completed—can appear in the target warehouse audit log.

Impact on customers

If your application:

• Connects to master first
• Switches database context later
• And relies solely on warehouse audit logs

Then you may observe missing login events, even though query activity is fully audited afterward. This does not indicate data loss or auditing failure—it reflects how artifact‑scoped auditing works.

How to trace logins when connections start on master

For complete, end‑to‑end traceability, combine platform‑level logs with database audit logs.

Recommended approach

• Use Fabric / Power BI Platform Logs
  • Identify authentication and connection events such as:
    • InitiateCloudOAuthLogin
    • ConnectWarehouseAndSqlAnalyticsEndpointLakehouseFromExternalApp

Learn more: Operation list

• Export Platform Logs
  • Export logs to a Lakehouse or Microsoft Purview for analysis
• Correlate with Database Audit Logs
  • Match platform login events with later USE <db> and query activity
  • This provides a full lifecycle view:
    • Initial login
    • Database context switch
    • Subsequent warehouse operations

Together, this yields complete traceability—even when login begins on master.

Conclusion

These updates make Fabric Warehouse connectivity more predictable and reduce ambiguity in how sessions are established. To ensure complete auditing coverage, connect directly to a specific warehouse whenever possible and use platform-level logs when connections start on master.

For full details and implementation guidance, review the documentation and share feedback in the comments.