CIPP (Beta)

👍

Quick Details

Recommended Agent: On-Demand
Supported Agents: On-Demand and Self-Managed
Is Auto-Discovered By: N/A
Can Auto-Discover: CIPP Child Inspectors (one per managed tenant)
Parent/Child Type Inspector: Yes
Inspected via: API
Default Frequency: Daily. (max every 8 hours)
Data Summary: CIPP Inspector Summary

Overview

CIPP Inspector (Beta)

CIPP (CyberDrain Improved Partner Portal) is the open-source, self-hosted multi-tenant Microsoft 365 management platform many MSP Partners already use to manage every Customer's M365 tenant through Microsoft's GDAP delegated-admin model. The CIPP Inspector (Beta) connects to a Partner's self-hosted CIPP instance and reports each managed tenant's Microsoft Secure Score, license utilization, Conditional Access policies, standards compliance, MFA posture, and Microsoft 365 Defender incidents back into Liongard — turning one CIPP instance into per-Customer configuration-drift monitoring across the Partner's whole M365 book of business.

What you can monitor

The CIPP Inspector collects GDAP relationship health, security posture, and licensing data for each managed tenant, including:

  • GDAP delegated-admin relationship health, including relationships nearing expiry
  • Microsoft Secure Score per managed tenant
  • Conditional Access policy configuration and drift
  • CIPP Standards compliance state
  • License SKU counts and utilization
  • MFA coverage (legacy per-user state)
  • Dormant accounts (no sign-in in 180+ days)
  • Open Microsoft 365 Defender security incidents
  • New or removed managed tenants

How it works

A parent launchpoint authenticates once to the Partner's CIPP instance and enumerates every managed Microsoft 365 tenant. Liongard automatically creates a child launchpoint for each tenant, mapped to that Customer's Liongard Environment, so each tenant's security and licensing posture is tracked independently.

Benefits

  • Catch a Conditional Access policy being disabled or deleted before it becomes an incident.
  • Get ahead of a GDAP relationship expiring, which would silently cut off management access to a Customer's tenant.
  • Detect a Microsoft Secure Score decline before the next security review.
  • Spot dormant accounts still consuming licenses and representing attack surface.
  • Track license SKU counts per Customer for true-up and rightsizing conversations.
  • Surface open Microsoft 365 Defender incidents alongside the rest of a Customer's configuration record.

Inspector Setup Preparation

⚠️

Prerequisites & Access Requirements

To configure the CIPP Inspector, ensure you have the following:

  • Administrative access to the Partner's self-hosted CIPP instance
  • Ability to create an API client and Custom Role within CIPP
  • The Azure Entra ID Tenant ID of the tenant hosting CIPP

Inspector Setup:

Step 1: Create the API Client in CIPP

  1. Sign in to the CIPP instance.
  2. Navigate to Settings → CIPP-API & MCP.
  3. Create a new API client.
  4. Assign the client a Custom Role granting read access to:
    • CIPP.Core.Read
    • Tenant.Directory.Read
    • Tenant.Reports.Read
    • Tenant.Standards.Read
    • Tenant.ConditionalAccess.Read
    • Identity.User.Read
    • Security.Incident.Read
  5. Record the Client ID and Client Secret.
  6. On the client's row in the CIPP-API Clients table, select Copy API Scope and record the copied value. This value is required and cannot be derived from the Client ID.
  7. Record the Azure Tenant ID of the Microsoft Entra ID tenant that hosts the CIPP instance — this is the Partner's own tenant, not a Customer's.

Step 2: Configure the CIPP Inspector in Liongard

  1. Log in to the Liongard platform.
  2. In Liongard, navigate to Admin > Inspectors > Inspector Types > Navigate to the CIPP Inspector > Select Add System.

Since CIPP is a multi-tenant system where a single instance manages many Microsoft 365 tenants, you'll set up a single "Parent" Inspector that will then auto-discover a "Child" Inspector for each managed tenant.

Fill in the following information:

  • Type of Inspector: Parent
  • Environment: Select your MSP's Environment
  • Friendly Name: Suggested Naming: [Customer Name] CIPP Parent
  • Agent: Select the On-Demand Agent
  • Inspector Version: Latest
  • CIPP Instance URL: The Partner's self-hosted CIPP address, e.g. cipp.example.com
  • CIPP Azure Tenant ID: The Entra ID tenant hosting CIPP, from Step 1
  • CIPP API Client ID: From Step 1
  • CIPP API Client Secret: From Step 1
  • CIPP API Scope: The value copied in Step 1 — not the same as the Client ID
  • CIPP Managed Tenant Filter: Leave blank. A blank filter is what identifies this launchpoint as the parent
  • Scheduling: The Inspector will default to run once a day at the time it's set up. Here you can adjust the schedule
  • Select Save. The Inspector will now be triggered to run within the minute.

Step 3: Child Inspector Setup

After the first run of the Parent Inspector, each managed Microsoft 365 tenant will be auto-discovered and surfaced in the Discovered Systems tab on the Inspectors > CIPP Inspector page, mapped to that Customer's Environment by the tenant's default domain name.

  • Activate or Archive your Discovered Systems by ensuring they're mapped to the correct Environment > Check the checkbox to the left of Inspector(s) > Select the Actions drop-down menu > Activate Launchpoints (or Archive Launchpoints).
  • Click Save.

If a managed tenant appears in the parent's Tenants view but no Child Inspector was created for it, one of three things is true: that tenant's CIPP record has no usable default domain name, the row is CIPP's AllTenants placeholder rather than a real tenant, or another tenant shares the same default domain — duplicates produce one child, not two.

Troubleshooting

  • Authentication failed: credentials were rejected: The Client ID, Client Secret, Azure Tenant ID, or API Scope is wrong, or the API client was revoked in CIPP. Most often the cause is the API Scope — it isn't the same as the Client ID and can't be constructed from it. Re-copy it using Copy API Scope on the client's row in CIPP.
  • The API client cannot list tenants: The Custom Role is missing CIPP.Core.Read. Add it under Settings → CIPP-API & MCP and re-run.
  • One Customer's data is incomplete while others are complete: That Customer's GDAP relationship is likely expired or revoked. Verify it in CIPP — the rest of the run is unaffected.
  • Fewer Child Inspectors than managed tenants: Expected when a tenant's CIPP record lacks a usable default domain name — compare the Tenants view against the discovered count.
  • MFA Coverage Percentage reads 0% for a tenant known to enforce MFA: Expected. This Inspector reads Microsoft Entra ID's legacy per-user MFA setting, not MFA registration. Tenants enforcing MFA through Conditional Access or Security Defaults report 0% here.
⚠️

Known V1 Limitations

No asset inventory — this Inspector ships no asset mappings by design. MFA is measured from Entra ID's legacy per-user state, not registration state — see the Troubleshooting note above. Very large tenants may show a truncated user list — CIPP's own user endpoint is understood to cap responses server-side with no continuation token, though the exact threshold is unconfirmed. No write-back — the Inspector is strictly read-only and never changes CIPP settings, Standards, or Customer tenant configuration. Secure Score and incident data reflect CIPP's cache of Microsoft's data rather than a live query at collection time. One CIPP instance per parent launchpoint — Partners running multiple CIPP instances need one parent per instance. Standards compliance, dormant-account, security-incident, and license-utilization field names were not confirmed against a live CIPP tenant during testing — they're sourced from CIPP's own API code rather than observed on the wire, so treat those four data areas as provisional pending further validation.

Inspector FAQs


Did this page help you?