“Sign in with Microsoft” – as convenient as it is for users, it quickly becomes a nightmare for administrators. Over the years, countless “enterprise applications” accumulate in almost every Microsoft 365 tenant. Often we don’t even know where they come from or what permissions they actually have.
In this article, I’ll show you why freely adding apps by users (and even admins in the wrong context) is a bad idea and how to take back control.
The Problem: The Click in Passing
You may be familiar with this: you test a new AI tool or add-in, quickly click “Accept” because the requested permissions look harmless, and forget about the app five minutes later.
This happens even to experienced IT professionals. A classic scenario: During the audit, a service principal – let’s call him “GuideAnts” for example – suddenly stands out, who has recently been added. Nobody remembers it.
A quick analysis of the Unified Audit Log (via PowerShell:Search-UnifiedAuditLog with Operation “Add Service Principal”) often brings to light the sobering truth: It was you yourself.
The protocol mercilessly shows:
- Actor: Your admin account
- Target: ServicePrincipal (e.g. GuideAnts)
- Timing: Sometime late at night
A comparison with the browser history often confirms: It was only a short login, a quick test. But the app remains in the tenant and has access.
The Three Deadly Sins of Enterprise Apps
This example can be used to derive three basic security mistakes that happen every day in many environments:
- Lack of care: Apps are often added without in-depth examination of necessity.
- Unverified publishers: Often these apps come from “Unverified Publishers”. This means that Microsoft has not validated the identity of the publisher. An unnecessary security risk.
- Admin privileges abused: If you add such apps with your Global Admin or another highly privileged account, you often bypass security mechanisms that (hopefully) apply to normal users.
The solution: Admin consent workflow instead of self-service
The most important step to prevent uncontrolled growth and shadow IT is to deactivate the option for users to consent (agree) to apps independently.
Why? If a normal user tries to add an app, they should be blocked. Instead, the Admin Consent Workflow takes effect. The user must enter a reason, and you as the administrator will receive a request (e.g. by email or in the admin center).
This has two decisive advantages:
- Four-eyes principle: Even if you make the request, the process forces you to think for a moment: “Do I really need this?” and “Is this redirect URL trustworthy?”.
- Central control: You can check if the app is verified and if the scopes requested are proportionate.
You can find more details about the setup in our article:
Consent and permissions
Practice: Analysis & Cleanup with PowerShell
To shed light on the darkness, two specific scripts will help you. The prerequisite is that you have installed the appropriate modules.
1. Who added what? (Audit Log)
If you’re wondering where a particular app comes from, a look at the Unified Audit Log will help. Since the search in the Compliance Center is often sluggish, PowerShell is faster.
This script looks for the “Add service principal” operation of the last 90 days:
# Voraussetzung: ExchangeOnlineManagement Modul
Connect-ExchangeOnline
# Zeitraum definieren (z. B. letzte 90 Tage)
$StartDate = (Get-Date).AddDays(-90)
$EndDate = (Get-Date)
Write-Host "Durchsuche Audit Logs..." -ForegroundColor Cyan
# Suche nach dem Event "Add service principal"
$Events = Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate -Operations "Add service principal" -ResultSize 5000
# Ergebnis aufbereiten
$Results = $Events | Select-Object CreationTime, @{N='User';E={$_.UserIds}}, @{N='AppName';E={($_.AuditData | ConvertFrom-Json).Target[3].ID}}
# Ausgabe in GridView zur schnellen Filterung
$Results | Out-GridView -Title "Hinzugefügte Enterprise Apps (Letzte 90 Tage)"2. Inventory: What apps do I have at all?
The best way to get a quick overview of all third-party apps in your tenant (excluding Microsoft’s own services) is to use Microsoft Graph.
Note: Pay special attention to entries that PublisherName are empty or contain “Unverified”. These are the first candidates for review or deletion.
# Voraussetzung: Microsoft.Graph Modul
Connect-MgGraph -Scopes "Application.Read.All"
Write-Host "Lade Service Principals..." -ForegroundColor Cyan
# Alle Service Principals abrufen
$AllApps = Get-MgServicePrincipal -All
# Filtern: Wir wollen keine Microsoft-First-Party Apps, sondern "echte" Enterprise Apps
# Hinweis: Das Filtern nach "nicht Microsoft" ist komplex, oft hilft der Check auf leere Tags oder Publisher.
# Hier ein Ansatz, um neuere Apps zu finden:
$RecentApps = $AllApps | Where-Object { $_.CreatedDateTime -gt (Get-Date).AddDays(-180) } | Select-Object DisplayName, AppId, PublisherName, CreatedDateTime, AccountEnabled
# Tabelle ausgeben, sortiert nach Datum (neueste zuerst)
$RecentApps | Sort-Object CreatedDateTime -Descending | Format-Table -AutoSizeConclusion & Checklist
In addition to prevention, regular hygiene in the tenant is essential. Thanks to the improved Microsoft Graph PowerShell SDK , it’s now much easier to pull reports on all enterprise apps, their usage, and permissions.
My tip:
Don’t rely on your users (or your colleagues) to be security-conscious.
[ ] Disable user consent for apps.
[ ] Enable the Admin Consent Workflow.
[ ] Check regularly via Script / Entra ID Portal which Service Principals are new and remove corpses.
We all learn from mistakes – but it’s best if the system prevents us from making them in the first place.
Microsoft Learn – Admin Consent Workflow: https://learn.microsoft.com/de-de/entra/identity/enterprise-apps/configure-admin-consent-workflow
Microsoft Graph PowerShell SDK: https://learn.microsoft.com/de-de/powershell/microsoftgraph/installation
PhinIT.DE Internal article with more details:
ENTERPRISE APPLICATIONS – Consent and Permissions
Be the first to comment