Entra ID Multi-Tenant-Apps sind für viele Unternehmen ein zweischneidiges Schwert: Einerseits ermöglichen sie eine nahtlose Zusammenarbeit über Tenant-Grenzen hinweg, andererseits öffneten sie bisher oft Tür und Tor für jeden beliebigen Tenant, der die Application ID kannte. Um dieses Sicherheitsrisiko zu minimieren, hat Microsoft die Sign-In Audience Restrictions eingeführt.
Dieses Feature erlaubt es Dir, den Zugriff auf Deine Multi-Tenant-Anwendungen explizit auf eine Liste vertrauenswürdiger Tenants zu beschränken, anstatt sie dem gesamten Microsoft-Ökosystem zur Verfügung zu stellen.
Die Architektur der Zugriffskontrolle
Bisher galt bei Multi-Tenant-Apps: Sobald die App registriert war und der signInAudience-Typ auf AzureADMultipleOrgs stand, konnte jeder Administrator weltweit einen Service Principal dieser App in seinem Tenant erstellen. Das ist besonders kritisch bei Eigenentwicklungen, die sensible Graph-Berechtigungen nutzen.
Mit dem neuen Modell wird eine zusätzliche Filterebene eingezogen. Das System prüft nun bei der Erstellung eines Service Principals (oder beim Login), ob der anfragende Tenant in der allowedTenantIds-Liste der App-Registrierung hinterlegt ist.
Implementierung via Microsoft Graph PowerShell
Da sich das Feature aktuell in der Beta-Phase befindet, ist die Konfiguration primär über die Microsoft Graph API bzw. das entsprechende PowerShell-SDK möglich. Du benötigst hierfür mindestens die Berechtigung Application.ReadWrite.All.
Schritt 1: Ziel-Audienz definieren
Zuerst musst Du sicherstellen, dass die App überhaupt als Multi-Tenant-Anwendung konfiguriert ist. Dies geschieht über die Eigenschaft signInAudience.
# Setzt die App auf Multi-Tenant (falls noch nicht geschehen)
Update-MgApplication -ApplicationId 'DEINE_APP_OBJECT_ID' -SignInAudience "AzureADMultipleOrgs"
Schritt 2: Mandanten-Einschränkungen konfigurieren
Hier definierst Du, welche externen Tenants (Tenant-IDs) berechtigt sind, Deine Anwendung zu nutzen. Beachte, dass die Liste aktuell auf maximal 20 Einträge begrenzt ist.
# Liste der erlaubten Tenant-IDs (GUIDs)
[array]$AllowedTenants = "22e90715-3da6-4a78-9ec6-b3282389492b", "72f988bf-86f1-41af-91ab-2d7cd011db47"
# Konstruktion des Body-Parameters für die Beta-API
$SignInRestrictions = @{
"@odata.type" = "#microsoft.graph.allowedTenantsAudience"
"isHomeTenantAllowed" = $true
"allowedTenantIds" = $AllowedTenants
}
$Params = @{
"signInAudience" = "AzureADMultipleOrgs"
"signInAudienceRestrictions" = $SignInRestrictions
}
# Update über den Beta-Endpunkt
Update-MgBetaApplication -ApplicationId 'DEINE_APP_OBJECT_ID' -BodyParameter $Params
Auswirkungen im Ziel-Tenant
Wenn ein Administrator eines nicht autorisierten Tenants nun versucht, Deine App hinzuzufügen (z. B. durch Erstellen eines Service Principals), wird Entra ID dies mit einem Fehler quittieren. Der Fehler besagt explizit, dass die SignInAudienceRestrictions-Konfiguration die Erstellung des Service Principals verhindert.
Dies verhindert effektiv das „Sideloading“ Deiner App-Logik durch Dritte, die lediglich Deine Client-ID kennen.
Rückbau der Einschränkungen
Solltest Du die App wieder für alle Tenants öffnen wollen, musst Du den Typ der Restriktion auf unrestrictedAudience zurücksetzen. Ein einfaches Leeren der Liste reicht nicht aus, da das System mindestens eine ID erwartet, solange der Typ auf allowedTenantsAudience steht.
PowerShell
$ResetParams = @{
"signInAudience" = "AzureADMultipleOrgs"
"signInAudienceRestrictions" = @{
"@odata.type" = "#microsoft.graph.unrestrictedAudience"
}
}
Update-MgBetaApplication -ApplicationId 'DEINE_APP_OBJECT_ID' -BodyParameter $ResetParams
Fazit und Sicherheitsbewertung
Die Einführung von Sign-In Audience Restrictions schließt eine seit Jahren bestehende Lücke in der Governance von Entra ID App-Registrierungen. Bisher mussten Entwickler oft auf komplexe Logiken innerhalb des Codes zurückgreifen (z. B. Validierung des tid-Claims im JWT), um unbefugte Tenants abzuweisen. Durch die Verlagerung dieser Kontrolle auf die Plattform-Ebene wird die Sicherheit massiv erhöht, da der Zugriff bereits blockiert wird, bevor die Anwendung überhaupt ausgeführt werden kann.
Aus Admin-Sicht ist die aktuelle Limitierung auf 20 Tenants ein deutliches Zeichen dafür, dass dieses Feature primär für B2B-Szenarien, Partner-Konstellationen oder interne Multi-Tenant-Strukturen (z. B. Test- und Produktionstenants) gedacht ist. Für ISVs mit hunderten Kunden bleibt dieses Feature in der jetzigen Form ungeeignet – hier greifen weiterhin Mechanismen wie der Microsoft AppSource Zertifizierungsprozess oder eigene Lizenz-Validierungen.
Kritisch zu betrachten ist die aktuelle Exklusivität im Beta-Endpunkt. Für produktive Umgebungen bedeutet dies ein erhöhtes Monitoring-Intervall, da sich Beta-Schemas jederzeit ändern können. Dennoch empfehle ich jedem Admin, der eigene Multi-Tenant-Tools (wie Backup-Skripte oder Report-Apps) betreibt, diese sofort auf die erlaubten Partner-Tenants einzuschränken. Es reduziert die Angriffsfläche Deines Tenants signifikant, da Deine App-Identität nicht mehr als Sprungbrett für „Consent Phishing“ in fremden Tenants missbraucht werden kann.
Sicherheitsaspekt: Kombiniere diese Einschränkung immer mit strengen Conditional Access Policies, um den Zugriff auf die App zusätzlich auf verwaltete Geräte oder spezifische IP-Ranges zu limitieren. Nur die Kombination aus Identitäts-Audienz und Zugriffs-Kontext bietet einen modernen Zero-Trust-Schutz.
This post is also available in:
Deutsch
Hinterlasse jetzt einen Kommentar