Intermediate โฑ 90 min ๐Ÿ“‹ 12 Steps

Deploy App Connectors & Session Controls

Connect enterprise SaaS apps via API connectors in Microsoft Defender for Cloud Apps, configure Conditional Access App Control for real-time session monitoring, create session policies for download and upload protection, and test enforcement end-to-end.

๐Ÿ“‹ Overview

About This Lab

App connectors use the APIs of app providers to enable greater visibility and control by Microsoft Defender for Cloud Apps over the apps you connect. API connectors provide richer data about user activities, file sharing, permissions, and account status. Conditional Access App Control extends this with real-time session monitoring and enforcement. allowing you to monitor sessions, block downloads, protect uploads, and prevent data exfiltration without blocking app access entirely.

๐Ÿข Enterprise Use Case

A financial services company uses Microsoft 365, Salesforce, Box, and ServiceNow. Employees frequently access these apps from personal devices and untrusted networks. The CISO requires real-time visibility into SaaS activities, the ability to block sensitive file downloads from unmanaged devices, and protection against data exfiltration through copy/paste in browser sessions. The security team must deploy API connectors for deep visibility and Conditional Access App Control for real-time enforcement. all without disrupting employee productivity.

๐ŸŽฏ What You Will Learn

  1. Understand API connector architecture and supported SaaS apps
  2. Connect Microsoft 365 via the built-in connector and verify data ingestion
  3. Connect third-party SaaS apps (Salesforce, Box, ServiceNow) via API connectors
  4. Verify connector health and troubleshoot data ingestion issues
  5. Configure Conditional Access App Control prerequisites in Entra ID
  6. Create Conditional Access policies to route sessions through MDA
  7. Onboard custom apps to Conditional Access App Control
  8. Create session policies for download blocking and upload protection
  9. Create access policies for unmanaged device restrictions
  10. Test session controls end-to-end with various scenarios
  11. Monitor session activity and investigate policy matches
  12. Tune policies and configure alerting for session violations

๐Ÿ”‘ Why This Matters

Without app connectors, your security team is blind to SaaS data movement. you cannot see who shared what files, which accounts have excessive privileges, or which OAuth apps access corporate data. Without session controls, you face a binary choice: block the app entirely or allow unrestricted access. Conditional Access App Control provides the granular, real-time enforcement that modern zero-trust architectures require: monitor, protect, and control. without blocking productivity.

โš™๏ธ Prerequisites

  • Licensing: Microsoft Defender for Cloud Apps (standalone or via Microsoft 365 E5 / E5 Security / EMS E5)
  • Entra ID: Microsoft Entra ID P1 or P2 for Conditional Access policies
  • Portal Access: Global Administrator or Security Administrator role in the Microsoft Defender portal
  • SaaS Admin Access: Admin credentials for third-party apps you plan to connect (Salesforce, Box, etc.)
  • Conditional Access: Conditional Access Administrator role in Entra ID
  • Test Account: A non-admin test user account for validating session controls
  • Lab 01 Completed: Cloud Discovery configured from Lab 01

Step 1 ยท Understand API Connector Architecture

API connectors establish a secure API connection between Defender for Cloud Apps and the target SaaS application. Each connector type provides different levels of visibility depending on the app’s API capabilities.

Connector Types and Capabilities

  • Built-in connectors: Microsoft 365 (Exchange, SharePoint, OneDrive, Teams), Azure, AWS, GCP. deepest integration with activity logs, file scanning, and user accounts
  • API connectors for third-party apps: Salesforce, Box, Dropbox, ServiceNow, Google Workspace, Okta, GitHub. provide activity logs, file visibility, and governance actions
  • Conditional Access App Control: Reverse-proxy architecture for real-time session monitoring and enforcement on any SAML 2.0 or OIDC app

Review Connected Apps Status

  1. Navigate to security.microsoft.com > Cloud Apps > Connected apps
  2. Review the App connectors tab to see any currently connected apps
  3. Note the Status column: Connected, Disconnected, or Authorization required
  4. Review the Conditional Access App Control apps tab for session-controlled apps
๐Ÿ’ก Pro Tip: Microsoft 365 is automatically connected in most E5 tenants. If you see it listed with a “Connected” status, you already have activity data flowing. Third-party apps require explicit administrator consent and API configuration.

Step 2 ยท Connect Microsoft 365 via the Built-in Connector

The Microsoft 365 connector provides deep visibility into Exchange Online, SharePoint Online, OneDrive, and Teams activities without any external API configuration.

Enable the Microsoft 365 Connector

  1. Go to Cloud Apps > Connected apps > App connectors
  2. Click + Connect an app > select Microsoft 365
  3. Select the components to connect: Azure AD users and groups, Azure AD management events, Azure AD sign-in events, Azure AD apps, Office 365 activities, Office 365 files
  4. Click Connect and authorize the connection with your Global Administrator account
  5. Wait for the status to change to Connected (typically 5–15 minutes)

Verify Data Ingestion

  1. Navigate to Cloud Apps > Activity log
  2. Filter by App: Microsoft 365
  3. Verify that recent activities appear: sign-ins, file access, admin operations
  4. Check Cloud Apps > Files to see shared files from SharePoint and OneDrive
โš ๏ธ Important: It can take up to 24 hours for historical data to fully populate after initial connection. File scanning begins immediately but may take time for large SharePoint environments.

Step 3 ยท Connect Third-Party SaaS Apps

Extend visibility to third-party SaaS apps by configuring API connectors. Each app requires administrator consent and specific API configuration in the target platform.

Connect Salesforce

  1. In Connected apps > App connectors, click + Connect an app > Salesforce
  2. Click Connect Salesforce. you will be redirected to the Salesforce login page
  3. Sign in with your Salesforce administrator account
  4. Authorize the Defender for Cloud Apps connection by accepting the permission request
  5. Return to the portal and verify the Salesforce connector shows Connected

Connect Box

  1. Click + Connect an app > Box
  2. Click Connect Box and sign in with your Box admin account
  3. Grant the requested permissions for activity monitoring and file scanning
  4. Enable Revoke app access and Change permissions governance actions

Connect ServiceNow

  1. In ServiceNow, create a dedicated integration user with the admin role
  2. Enable the REST API and generate an OAuth client ID and secret
  3. In MDA, click + Connect an app > ServiceNow
  4. Enter the ServiceNow instance URL, username, password, and client credentials
  5. Click Test, then Connect
๐Ÿ’ก Pro Tip: Always use a dedicated service account for API connectors. never your personal admin account. This ensures the connector remains functional when individual users change passwords or leave the organisation.

Step 4 ยท Verify Connector Health and Data Flow

After connecting apps, verify that data is flowing correctly and monitor connector health for ongoing reliability.

Check Connector Status

  1. Navigate to Cloud Apps > Connected apps > App connectors
  2. Review each connector: the status should be Connected with a green checkmark
  3. Click each connector to view detailed status: last activity sync, last user sync, last file sync
  4. Verify the Activities count is increasing over time

Validate Activity Data

  1. Go to Cloud Apps > Activity log
  2. Filter by each connected app and verify activities are appearing
  3. Check for user sign-in events, file operations, and administrative activities
  4. Use the Advanced filters to drill into specific activity types

Troubleshoot Common Issues

  • Status: Disconnected . The API token has expired. Reconnect by clicking the connector and re-authorizing
  • No activities showing . Check that the service account has sufficient permissions in the target app
  • Delayed data . Some connectors have a 4–12 hour delay for activity synchronization
  • Missing file data . File scanning requires file-level API access: verify OAuth scopes
โš ๏ธ Important: API connectors are subject to the SaaS provider’s API rate limits. High-volume environments may experience throttling. Configure email alerts for connector health issues under Settings > Cloud Apps > System > Mail settings.

Step 5 ยท Configure Conditional Access App Control Prerequisites

Conditional Access App Control uses a reverse-proxy architecture to intercept user sessions in real time. Before creating session policies, you must configure the Entra ID Conditional Access integration.

Verify Licensing and Roles

  • Confirm Microsoft Entra ID P1 or P2 licensing is assigned to all target users
  • Verify you have the Conditional Access Administrator role in Entra ID
  • Confirm the MDA instance is linked to your Entra ID tenant

Enable Conditional Access App Control in MDA

  1. Navigate to Settings > Cloud Apps > Conditional Access App Control
  2. Review the Default behavior setting: choose whether to monitor or block sessions for unrecognized apps
  3. Under User monitoring, enable notification to users that their session is being monitored (recommended for compliance)
  4. Under Device identification, configure options for client certificate checking if you use managed device identification
# ---------------------------------------------------------------
# PURPOSE: Verify Conditional Access readiness by listing all
#          existing Conditional Access policies in Entra ID.
# WHY: Before creating a new policy to route sessions through MDA,
#      you need to review existing policies to avoid conflicts.
#      Conflicting policies (e.g. one blocking browser access while
#      another routes to MDA) can cause authentication failures.
# PREREQUISITES: Install Microsoft.Graph PowerShell module:
#   Install-Module Microsoft.Graph -Scope CurrentUser
# OUTPUT: Table of policy names, state (enabled/disabled/report-only),
#         and creation dates. Look for existing session control
#         policies that might conflict with the one you're creating.
# ---------------------------------------------------------------
Connect-MgGraph -Scopes "Policy.Read.All"

# Retrieve all Conditional Access policies and display key fields.
# State values: "enabled", "disabled", "enabledForReportingButNotEnforced"
Get-MgIdentityConditionalAccessPolicy | 
    Select-Object DisplayName, State, CreatedDateTime |
    Format-Table -AutoSize
๐Ÿ’ก Pro Tip: Start with Monitor only mode for Conditional Access App Control. This lets you observe session traffic patterns before enforcing block or protect actions, reducing the risk of disrupting user workflows.

Step 6 ยท Create a Conditional Access Policy for Session Routing

Create a Conditional Access policy in Entra ID that routes user sessions through Defender for Cloud Apps for real-time monitoring and enforcement.

Create the Conditional Access Policy

  1. Navigate to entra.microsoft.com > Protection > Conditional Access > Policies
  2. Click + New policy
  3. Name the policy: Route SaaS Apps Through Cloud App Security
  4. Under Users: include All users (or a pilot group for initial testing)
  5. Under Target resources > Cloud apps: select the specific apps to protect (e.g., SharePoint Online, Exchange Online, Salesforce)
  6. Under Conditions > Client apps: select Browser (session controls only apply to browser sessions)
  7. Under Session: select Use Conditional Access App Control
  8. Choose Use custom policy (this routes to MDA for policy evaluation)
  9. Under Grant: set Require multifactor authentication and Require device to be marked as compliant (optional but recommended)
  10. Set the policy to Report-only first, then switch to On after validation
# ---------------------------------------------------------------
# PURPOSE: Create a Conditional Access policy via Microsoft Graph
#          that routes browser sessions to Defender for Cloud Apps
#          for real-time session monitoring and enforcement.
# WHY: This policy intercepts browser sessions to specified apps
#      (SharePoint, Exchange) and proxies them through MDA's reverse-
#      proxy, enabling session policies to inspect downloads, block
#      uploads, and control copy/paste in real time.
# KEY PARAMETERS:
#   - State = "enabledForReportingButNotEnforced" โ†’ Report-only mode
#     (safe to deploy; logs what WOULD happen without blocking).
#     Change to "enabled" after 48 hours of validation.
#   - IncludeApplications: GUIDs identify specific Microsoft apps:
#       00000003-0000-0ff1-ce00-000000000000 = SharePoint Online
#       00000002-0000-0ff1-ce00-000000000000 = Exchange Online
#   - ClientAppTypes = "browser": session controls only work in
#     browser sessions, not thick clients (Outlook desktop, etc.).
#   - CloudAppSecurityType = "mcasConfigured": routes sessions to
#     MDA for policy evaluation (vs. "monitorOnly" for logging).
# OUTPUT: The newly created policy object. Verify in Entra ID portal
#         under Protection > Conditional Access > Policies.
# ---------------------------------------------------------------
$params = @{
    DisplayName = "Route SaaS Apps Through Cloud App Security"
    State = "enabledForReportingButNotEnforced"   # Start in report-only mode
    Conditions = @{
        Users = @{ IncludeUsers = @("All") }       # Target all users
        Applications = @{
            IncludeApplications = @(
                "00000003-0000-0ff1-ce00-000000000000"  # SharePoint Online
                "00000002-0000-0ff1-ce00-000000000000"  # Exchange Online
            )
        }
        ClientAppTypes = @("browser")   # Only browser sessions (not desktop apps)
    }
    SessionControls = @{
        CloudAppSecurity = @{
            IsEnabled = $true
            CloudAppSecurityType = "mcasConfigured"  # Route to MDA for policy eval
        }
    }
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $params
โš ๏ธ Important: Always start Conditional Access policies in Report-only mode. Review the sign-in logs for at least 48 hours before enabling enforcement to identify any unintended blocks or disruptions.

Step 7 ยท Onboard Apps to Conditional Access App Control

Featured apps (Microsoft 365, Salesforce, Box, etc.) are automatically recognized by Conditional Access App Control. For custom or less common apps, you must onboard them manually.

Verify Featured App Recognition

  1. After enabling the Conditional Access policy, sign in to a target app with your test user
  2. You should see the MDA proxy URL in the address bar (e.g., *.mcas.ms)
  3. Navigate to Cloud Apps > Connected apps > Conditional Access App Control apps
  4. Verify the app appears in the list with a Connected status

Onboard a Custom SAML App

  1. In the Conditional Access App Control apps page, click + Add
  2. Select Any other app (custom)
  3. Enter the app name, SSO URL, and reply URL from your SAML configuration
  4. Follow the guided onboarding wizard to complete the proxy configuration
  5. Test the app by signing in through the Conditional Access flow
  6. Verify that the session is proxied (check the URL shows the .mcas.ms domain)
๐Ÿ’ก Pro Tip: For apps that use complex JavaScript or WebSocket connections, you may need to add specific domains to the Maintenance mode or Bypass list to avoid breaking app functionality. Test thoroughly before enforcing.

Step 8 ยท Create a Session Policy to Block Sensitive Downloads

Session policies provide real-time enforcement during user sessions. Create a policy that blocks download of sensitive files from unmanaged devices.

Create the Download Block Policy

  1. Navigate to Cloud Apps > Policies > Policy management
  2. Click + Create policy > Session policy
  3. Name the policy: Block Sensitive File Downloads from Unmanaged Devices
  4. Set Session control type: Control file download (with inspection)
  5. Under Activity source: set Device tag does not equal Intune compliant
  6. Under Files matching all of the following: set Sensitivity label equals Confidential or Highly Confidential
  7. Under Content inspection: optionally enable DLP scanning for credit card numbers, SSN, or custom patterns
  8. Set Actions: Block
  9. Configure Alerts: send alert to SOC team email when the policy triggers
  10. Click Create
๐Ÿ’ก Pro Tip: Use the Protect action instead of Block to allow downloads but automatically apply AIP encryption. This way, users can still work productively while sensitive data remains protected even if downloaded to an unmanaged device.

Step 9 ยท Create a Session Policy to Protect Uploads

Protect sensitive data at upload time by applying sensitivity labels automatically when users upload files containing sensitive content to monitored SaaS apps.

Create the Upload Protection Policy

  1. Click + Create policy > Session policy
  2. Name the policy: Auto-Label Sensitive Uploads to SaaS Apps
  3. Set Session control type: Control file upload (with inspection)
  4. Under Activity source: set App equals your target apps (SharePoint, Box, Salesforce)
  5. Under Content inspection method: select Built-in DLP
  6. Add inspection criteria: files containing credit card numbers, Social Security numbers, or matching your custom sensitive information types
  7. Set Actions: Apply sensitivity label > select Confidential
  8. Enable Alert for each matching upload
  9. Click Create
โš ๏ธ Important: Content inspection adds latency to file uploads (typically 2–5 seconds per file). For large-scale environments, consider limiting inspection to specific file types (e.g., .docx, .xlsx, .pdf) to minimize performance impact.

Step 10 ยท Create Access Policies for Unmanaged Devices

Access policies control whether a user can access an app at all, based on conditions like device compliance, location, or user risk. Create a policy to restrict access from unmanaged devices.

Create the Access Restriction Policy

  1. Click + Create policy > Access policy
  2. Name the policy: Restrict Sensitive Apps from Unmanaged Devices
  3. Under Activity source: set Device tag does not equal Intune compliant AND does not equal Hybrid Azure AD joined
  4. Set App equals your high-sensitivity apps (e.g., Salesforce, internal custom apps)
  5. Set Actions: Block with a custom block message explaining the policy
  6. Alternatively, set Actions: Test to audit before enforcing
  7. Configure alerts for blocked access attempts
  8. Click Create
๐Ÿ’ก Pro Tip: Combine access policies with session policies for a layered approach: allow access from unmanaged devices but restrict downloads and copy/paste. This provides security without completely blocking mobile and BYOD users.

Step 11 ยท Test Session Controls End-to-End

Validate all configured policies by testing with a representative user account across multiple scenarios.

Test Scenarios

  1. Managed device + sensitive download: Sign in from a compliant device and download a labeled file. should succeed
  2. Unmanaged device + sensitive download: Sign in from a personal browser (InPrivate/Incognito, non-domain-joined) and attempt to download a labeled file. should be blocked
  3. Upload with sensitive content: Upload a file containing credit card numbers. verify the sensitivity label is auto-applied
  4. Access from unmanaged device: Attempt to access a restricted app from an unmanaged device. verify the block page appears
  5. Copy/paste restriction: If configured, verify that copy/paste from a protected app is blocked in the browser session

Verify in the Activity Log

  1. Navigate to Cloud Apps > Activity log
  2. Filter by Policy name to see activities that matched your session policies
  3. Verify blocked downloads show a Blocked action status
  4. Verify auto-labeled uploads show the correct label applied
  5. Check Alerts to confirm alert notifications were generated
๐Ÿ’ก Pro Tip: Use an InPrivate or Incognito browser window from a non-domain-joined machine to simulate an unmanaged device. Clear cookies between tests to ensure a clean session state.

Step 12 ยท Monitor and Tune Session Policies

Ongoing monitoring and tuning ensures policies remain effective without causing excessive false positives or user friction.

Monitor Session Policy Effectiveness

  1. Navigate to Cloud Apps > Policies > Policy management
  2. Review the Count column to see how many times each policy has been triggered
  3. Click on a specific policy to view detailed match history
  4. Review Alerts to identify patterns: are the same users or apps triggering repeatedly?
  5. Check for false positives: legitimate workflows being blocked unintentionally

Tune Policies Based on Findings

  • Reduce false positives: Add exclusions for specific users, groups, or IP ranges that are trusted
  • Adjust sensitivity: Modify content inspection thresholds (e.g., require 5+ credit card numbers instead of 1)
  • Refine device filters: Adjust device tag conditions if managed devices are being incorrectly blocked
  • Add exceptions: Create bypass rules for service accounts or automated workflows

Set Up Ongoing Alerts

  1. Navigate to Settings > Cloud Apps > Mail settings
  2. Configure daily or weekly digest emails for policy matches
  3. Set up immediate alerts for high-severity blocks (e.g., bulk download attempts)
  4. Integrate alerts with your SIEM (Microsoft Sentinel) for unified SOC monitoring
โš ๏ธ Important: Review session policies quarterly. SaaS app updates, new user workflows, and organisational changes can affect policy accuracy. Schedule regular tuning reviews with application owners.

Summary

What You Accomplished

  • Connected Microsoft 365 and third-party SaaS apps via API connectors
  • Verified connector health and validated activity data ingestion
  • Configured Conditional Access App Control prerequisites in Entra ID
  • Created Conditional Access policies to route sessions through MDA
  • Onboarded apps to the session proxy for real-time monitoring
  • Created session policies for download blocking and upload protection
  • Created access policies for unmanaged device restrictions
  • Tested all policies end-to-end and validated enforcement
  • Established ongoing monitoring and tuning processes

Cost Considerations

  • Defender for Cloud Apps is included in Microsoft 365 E5, E5 Security, or available as a standalone add-on
  • Conditional Access requires Microsoft Entra ID P1 (included in M365 E3/E5)
  • API connectors and session controls do not incur additional data costs
  • Content inspection for DLP in session policies consumes compute resources but has no per-scan cost

Cleanup (Lab Environment Only)

  • Disable or delete the Conditional Access policy used for session routing
  • Remove test session and access policies from the MDA policy management page
  • Disconnect any test connectors you no longer need
  • Dismiss test alerts in the alerts queue

Next Steps

  • Next Lab: Investigate Risky OAuth Apps & Service Accounts
  • Integrate MDA alerts with Microsoft Sentinel for cross-product correlation
  • Configure anomaly detection policies for connected apps
  • Deploy endpoint-based session controls with MDE integration

๐Ÿ“š Documentation Resources

ResourceDescription
Connect apps to get visibility and controlOverview of API connector architecture and supported apps
Protect apps with Conditional Access App ControlArchitecture and deployment guide for session controls
Session policies in Defender for Cloud AppsCreate and manage session policies for real-time enforcement
Access policies in Defender for Cloud AppsControl app access based on device, location, and user conditions
Connect Microsoft 365 to Defender for Cloud AppsConfigure the built-in Microsoft 365 API connector
Deploy Conditional Access App Control for Entra ID appsStep-by-step deployment of session controls with Entra ID
Content inspection in Defender for Cloud AppsConfigure DLP content inspection for file policies
Troubleshoot Conditional Access App ControlResolve common issues with the reverse-proxy architecture
โ† Previous Lab Next Lab โ†’