Zum Zeitpunkt des Verfassens (April 2024) unterstützt Microsoft noch nicht, dass Enterprise Apps in Administrativen Units hinzugefügt werden
Tatsächlich kenne ich keine offizielle Previews. Dieser Artikel ist rein spielerisch von mir erstellt; wenn Sie hieraus etwas in Produktion verwenden, liegt die Verantwortung bei Ihnen.

Ich habe schon einige Artikel geschrieben, die zumindest am Rande das Prinzip der geringsten Privilegs behandeln, daher sollte es nicht überraschen, dass ich Administrativen Units mag. Tatsächlich mag ich sie sehr – wer mag es nicht, Berechtigungen zu entziehen, die Menschen nicht benötigen – aus Sicherheitsgründen. Nun, ich glaube nicht, dass es überhaupt vielen in den Sinn kommt, aber darum geht es nicht. 😤

In meinem Artikel, in dem ich die Verwendung von Application.ReadWrite.All Applikationsrechten anprangere, führe ich als mögliche Lösung ausdrücklich Administrativen Units (AUs) auf, die Enterprise Apps und deren App Registrations enthalten. Aber das ist nicht der einzige Ort, an dem sie sehr hilfreich wären. Wenn Sie Cloud App Administrator nicht bereits als Globalen Administrator behandeln, sollten Sie einen Bericht über Ihre Enterprise Apps erstellen und sich an folgendes erinnern: Ein Cloud App Administrator kann all diese saftigen Anwendungsberechtigungen nutzen, indem er neue App-Anmeldeinformationen erstellt.

Es wäre großartig, wenn wir eine Gruppe aller weniger kritischen Anwendungen für unsere Administratoren im Tagesgeschäft erstellen könnten und die Verwaltung aller Anwendungen auf unsere vertrauenswürdigsten Personen beschränken könnten – ohne ein lästiges Netzwerk von Ownern oder Rollenzuweisungen zu knüpfen…

Ich sage, wir sollten keine IAM-Connectoren oder Schnittstellen marke Eigenbau benötigen. Ich sehe euch, Mitschöpfer von Apps, die in 2-5 Jahren legacy sein werden. 👁️

Wie nah sind wir also dran, Zugriff auf diese Funktions­erweiterung zu erhalten?


Die offizielle Ansicht

Werfen wir doch zunächst einen Blick in die offizielle Dokumentation, um zu sehen, was wir tun können sollen:

supportedAdminUnitScenarios


Also können wir Benutzer, Gruppen und Geräte einbeziehen, sonst nichts. Diese Einschränkung spiegelt sich im GUI wider, wo auch nur diese Kategorien aufgeführt sind:

OfferedObjectType

Wenn wir versuchen, ein Mitglied hinzuzufügen, werden die verfügbaren Objekte immer entsprechend der Kategorie gefiltert. Da Enterprise Apps also im GUI nicht verfügbar sind und nicht explizit dokumentiert sind, ist das Aufnehmen von Apps in Admin Units unmöglich, richtig?


Aufnehmen von Apps in Admin Units

Ich glaube nicht an GUIs.

Ich nutze sie und erkenne ihren Nutzen an. Um jedoch bei etwas sicher zu sein oder seltsames Verhalten zu verstehen, wende ich mich immer der Befehlszeile, Konfigurationsdateien oder in diesem Fall der API zu. Dies gilt insbesondere, da Microsoft einem API-First-Paradigma folgt, was generell bedeutet, dass robustere und aktuellere Optionen über die Graph-API verfügbar sind. Es sei denn, die Anwendung oder Funktion ist älter als das, was sich wie ein Cut-Off-Datum von 2020 anfühlt. Aber ich schweife ab.

Also – da wir wissen, dass uns die Benutzeroberfläche nicht spielen lässt, sehen wir uns an, was uns Graph an die Hand gibt:

Voraussetzungen: Ein Benutzer mit Privileged Role Administrator und eine bereits erstellte AU. Die AU-ID kann aus "Overview" abgerufen werden.

# Ersetzen Sie die Platzhalter durch Ihre Werte
$enterpriseAppObjectID   = "<Enterprise App Object ID>"
$appRegistrationObjectID = "<App Registration Object ID>"
$adminUnitID             = "<Admin Unit Object ID>"

# Enterprise App und App Registration zu der Admin Unit hinzu fügen:
$params = @{
    "@odata.id" = "https://graph.microsoft.com/v1.0/servicePrincipals/$enterpriseAppObjectID"
}
Invoke-MgGraphRequest POST "https://graph.microsoft.com/v1.0/directory/administrativeUnits/$adminUnitID/members/`$ref" -Body $params

$params = @{
    "@odata.id" = "https://graph.microsoft.com/v1.0/applications/$appRegistrationObjectID"
}
Invoke-MgGraphRequest POST "https://graph.microsoft.com/v1.0/directory/administrativeUnits/$adminUnitID/members/`$ref" -Body $params

# Ergebnis anzeigen:
$res = Invoke-MgGraphRequest GET "https://graph.microsoft.com/v1.0/directory/administrativeUnits/$adminUnitID/members/"
$res.value.'@odata.type'

Et voilà: Wir haben erfolgreich die Regeln gebogen. Normalerweise gibt es Sicherheitsvorkehrungen, um sicherzustellen, dass wir nur autorisierte Elemente hinzufügen können. Vielleicht ist diese Funktion bald für eine offizielle Vorschau bereit, was uns etwas Spielraum ermöglicht?

addedMembers

Anwendungen sind immer noch nicht in der GUI sichtbar – es gibt keine "Alle Mitglieder" Schaltfläche 😉


Application Rollen auf Admin Units beschränken

Anwendungsobjekte zu AUs hinzufügen ist allein nicht besonders nützlich. Ohne die Möglichkeit, einfach App-Mitgliedschaften innerhalb von AUs anzuzeigen, werden Apps nicht leichter kategorisiert (dafür haben wir custom security attributes). Der eigentliche Wert von AUs liegt darin, gezieltere Rollenzuweisungen zu ermöglichen und das Prinzip des geringsten Privilegs zu unterstützen, indem eingeschränkte Zuweisungen von "Cloud App Administrator" ermöglicht werden.

Prüfen wir zuerst, ob wir über die GUI "Cloud App Administrator" hinzufügen können:

Admin Unit Rollenverwaltungsdialog "Role Hinzufügen" Dialog
AdminUnitRolesOffered RoleScopesOffered

Nun, es stellt sich heraus, dass weder Hinzufügen der Rolle über Privileged Identity Management (PIM) noch der AU-spezifische Rollendialog die benötigten Optionen bietet. Also wenden wir uns wieder unserem zuverlässigen Freund, der Graph-API, zu:

# Hier könnte auch eine Enterprise-App-ID verwendet werden
$userID = "<ID meines noch nicht privilegierten Benutzers>"
# Wir müssen UPNs auflösen, da sie nicht in Rollenzuweisungen erlaubt sind
$userID = (Invoke-MgGraphRequest GET "https://graph.microsoft.com/v1.0/users/$userID").id

$params = @{
    "@odata.type" = "#microsoft.graph.unifiedRoleAssignment"
    roleDefinitionId = "158c047a-c907-4556-b7ef-446551a6b5f7" # Cloud Application Administrator
    principalId = "$userID"
    directoryScopeId = "/administrativeUnits/$adminUnitID"
}
Invoke-MgGraphRequest POST "https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments" -Body $params

Notiz am Rande: Die PIM-Benutzeroberfläche ist flexibel genug, um diese Rollenzuweisung anzuzeigen – was das Tracking im Vergleich zum Ausführen eines Skripts zum Abrufen aller "Owner" Zuweisungen vereinfacht.

RoleASsignmentInUI

Now that we have a user with permissions scoped to the Admin Unit, let’s verify everything behaves as expected. I’ll log into both the GUI and PowerShell as BiancaP, the newly assigned Cloud App Administrator, using fresh sessions. Next, we’ll perform common administrative tasks to see where access is denied — or erroneously granted:

Jetzt, da wir einen Benutzer mit auf die AU beschränkten Berechtigungen haben, überprüfen wir, ob alles wie erwartet funktioniert. Ich werde mich sowohl in der GUI als auch in PowerShell als BiancaP, dem neu zugewiesenen Cloud App Administrator, in frischen Sitzungen anmelden. Anschließend führen wir gängige administrative Aufgaben durch, um zu sehen, wo der Zugriff verweigert – oder fälschlicherweise gewährt wird:


Verwaltung von App-Eigenschaften

Zur Wiederholung, wir handeln nun als AU beschränkter Cloud App Admin BiancaP für App Registrations und Enterprise Applications, die unserer AU hinzugefügt wurden, es sei denn, es wird ausdrücklich etwas anderes angegeben!

Die Tests auf unseren AU Apps waren in der GUI überraschend erfolgreich. Daher macht es mehr Sinn, die aktuellen Einschränkungen (Stand April 2024) zu listen:

  1. Hinzufügen von Ownern zu Enterprise App und App Registration
    • Begegnete Inkonsistenz: Anfangs konnte ich den Benutzer selbst und dann andere hinzufügen, aber ich erhielt unregelmäßig "permission denied" Fehlermeldungen
    • Diese Einschränkung gilt nicht für direkte API-Aufrufe, bei denen ich keine Probleme festgestellt habe
  2. Aktualisieren des Manifests
    • Ich fand keine Möglichkeit, die Manifestdatei als BiancaP zu bearbeiten

SAML-Konfiguration: Denken Sie daran, dass Administratorrechte sowohl für die App Registration als auch für die Enterprise Application erforderlich sind, um Anpassungen vorzunehmen (z.B. Weiterleitungs-URI und Bezeichner, die Eigenschaften der App Registration sind)


Für die API-Verifizierung führte ich schnelle Stichproben durch. Da die GUI mit der Graph-API interagiert kann man erwarten, dass die API ähnlich reagiert, wenn sie nicht sogar mehr Möglichkeiten bietet, wo die GUI an ihre Grenzen stößt.

# Deaktivieren der Enterprise App ( = Enabled for users to sign-in )
$params = @{
    accountEnabled = $false
}
Invoke-MgGraphRequest PATCH "https://graph.microsoft.com/v1.0/servicePrincipals/$enterpriseAppObjectID" -Body $params

# Public Client aktivieren, Redirect URI hinzufügen ( die primäre Redirect-URI kann nicht entfernt werden)
$params = @{
    isFallbackPublicClient = $true
    web = @{
        redirectUris = @("https://jwt.ms/saml", "https://jwt.ms/demo")
    }
}
Invoke-MgGraphRequest PATCH "https://graph.microsoft.com/v1.0/applications/$appRegistrationObjectID" -Body $params

Beide werden erfolgreich ausgeführt und haben das erwartete Ergebnis:

Aktualisierte App Registration Aktualisierte Enterprise App
UpdatedAppRegistration UpdatedEnterpriseApp


Wenn wir versuchen die Eigenschaften einer Applikation zu editieren, die nicht in der AU enhalten ist, werden wir wie erwartet blockiert:

App Registration

AttemptToEditRegOutsideOU

Enterprise App

AttemptingtoEditAppOutsideOu

API Aufrufe (die vorhin funktioniert haben 😉)

RequestDeniedPATCH


Owner verwalten

Wie bereits erwähnt, um das seltsame Verhalten in der GUI zu umgehen habe ich getestet, einen Besitzer über die Graph-API hinzuzufügen. Diese Methode umgeht auch Einschränkungen beim Bearbeiten des Manifests und ermöglicht es uns, Enterprise Apps und App Registrations zu löschen. Obwohl dies nützlich für Tests ist, würde ich es nicht als angemessen für regelmäßige administrative Nutzung bezeichnen.

$userID = $GraphConfig.AUUser
$userID = (Invoke-MgGraphRequest GET "https://graph.microsoft.com/v1.0/users/$userID").id

$params = @{
    "@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/$userID"
}
Invoke-MgGraphRequest POST "https://graph.microsoft.com/v1.0/applications/$appRegistrationObjectID/owners/`$ref" -Body $params

$params = @{
    "@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/$userID"
}
Invoke-MgGraphRequest POST "https://graph.microsoft.com/v1.0/servicePrincipals/$enterpriseAppObjectID/owners/`$ref" -Body $params

Ergebnisse sind wieder wie erwartet:

App Registration Owner Enterprise App Owner
OwnerToAppReg OwnerToEnterpriseApp


Erstellen und Löschen von Apps

Ich werde nicht zur GUI zurückkehren, da es keinen Anwendungsreiter innerhalb der AU gibt — Definition des Wahnsinn, stimmts? 🤪 Zusätzlich ist das Erstellen von Apps außerhalb der AU vorhersehbarerweise deaktiviert:

GUISaysNoToAddingNewApps

Leider stoßen wir nun auf explizitere Einschränkungen des API-Endpunkts. Erstellen kann man Gruppen, und nur Gruppen, innerhalb von AUs:

createObjectDocumentation

Wenn wir es trotzdem versuchen, erhalten wir den dokumentierten Fehler:

#Neues Mitglied erstellen:
$params = @{
    "@odata.type" = "#Microsoft.Graph.Application"
    "displayName" = "New Member"
}
$res = Invoke-MgGraphRequest POST "https://graph.microsoft.com/v1.0/directory/administrativeUnits/$adminUnitID/members/" -Body $params -OutputType PSObject

APISaysNoToAddingNewApps

Für diejenigen, die sich fragen, ob es einfach ein Tippfehler war, das würde einen ganz anderen Fehler auslösen — den ich, natürlich absichtlich, getestet habe. 😇
AddingWrongType

Weiter geht’s. Berechtigungen, die auf die AU beschränkt sind, erlauben nicht das Entfernen von Apps, wie hier demonstriert:

deleteApplicationGUI

Ein Versuch, über die Graph-API zu löschen, führt ebenfalls zur Ablehnung:

Invoke-MgGraphRequest DELETE "https://graph.microsoft.com/v1.0/directory/administrativeUnits/$adminUnitID/members/$appRegistrationObjectID"
requestDenied

Wenn wir uns selbst als Besitzer hinzufügen, können wir die Anwendung auf herkömmliche Weise löschen:
Invoke-MgGraphRequest DELETE "https://graph.microsoft.com/v1.0/applications(appId='$appID')"

Alles in allem kein besonders zufriedenstellendes Ergebnis.


Wie Ich hier gelandet bin

Der Hauptgrund, warum ich mit diesen Tests angefangen habe? Ich konnte einfach nicht glauben, dass es keinen effizienten Weg gibt, die Erstellung von Apps zu ermöglichen, ohne mir und meinen Entra-Admin Kollegen weitreichende Berechtigungen anzulegen. Das ganze Problem dreht sich wirklich um Eigenheiten der Rolle "Application Developer".

Mein erster Kopfschmerz ist die Nachvervolgung, wem was gehört. Wenn ein "Application Developer" eine App erstellt, wird er automatisch als Owner hinzugefügt, da er sie sonst nicht verwalten könnte. Aber wenn Sie darauf abzielen, Apps gemeinsam zu verwalten, muss der erste Owner manuell alle weiteren erforderlichen Benutzer hinzufügen – Gruppen sind keine Option. Entweder das, oder wir müssten eine Automatisierung einrichten, wahrscheinlich unter Verwendung benutzerdefinierter Sicherheitsattribute, um die Dinge zu vereinfachen. Es fühlt sich so an, als ob es einen besseren Weg geben sollte, oder?

Wichtiger ist, dass ein Application Developer keine SAML-Anwendungen erstellen kann, da dies "Instantiieren" einer Anwendungsvorlage erfordert, eine Aufgabe, die außerhalb der Berechtigungen der Rolle liegt. Konkret braucht es microsoft.directory/applicationTemplates/instantiate, was nicht im Application Developer enthalten ist. Selbst wenn diese Berechtigung über eine benutzerdefinierte Rolle gewährt wird, der Ersteller wird nicht automatisch zum Besitzer, was bedeutet, dass der Application Developer aus der gerade erstellten Anwendung ausgesperrt ist.

Dank geht an Merill Fernando’s Browser-Plugin Graph X-Ray für Zeitersparnis bei der Recherche – ich musste nur den Knopf in der Entra-GUI drücken und konnte den richtigen Endpunkt und die zugehörige Dokumentation zu finden

Microsoft Lösungsvorschlag wäre es, eine App Registration mit ‘Application.ReadWrite.OwnedBy’ Berechtigungen zu erstellen und die Anmeldeinformationen an Administratoren zu verteilen. Meiner Meinung nach ist dieser Ansatz für den täglichen Gebrauch nicht praktikabel – nicht jeder ist mit der Verwendung von PowerShell vertraut.

Referenz: Kommentare in meiner Q&A akzeptierten Antwort als ich dieses Problem zum ersten Mal angegangen bin


Was wir gelernt haben

Da dies eine ziemliche Reise war, halte ich es kurz:

  • Das Feature ist noch nicht für Produktion geeignet, wenn nicht offensichtlich genug durch Mangel an offiziellem Support durch Microsoft
  • Für Szenarien, die nur einmalige Einrichtung erfordern, ist die administrative Erfahrung bereits akzeptabel
  • Sobald wir Mitglieder häufig aktualisieren müssen, macht fehlende GUI das Management zu umständlich
  • Die Unfähigkeit, Apps zu erstellen, verringert signifikant die Vorteile der im Vergleich zu Alternativen


Unterstützte Alternativen und Workarounds:

  1. App Owner
    • Verfolgung durch regelmäßige Überprüfungen oder Automatisierung
  2. PIM Groups Scoped to Specific Application Objects
    • Kombination mit "Application Developer", um App-Erstellungen zu ermöglichen
    • Deckt alles außer der Erstellung von SAML-Anwendungen ab
  3. Automatisierung / App Registrierung basierend auf Application.ReadWrite.OwnedBy


Die Notwendigkeit von feiner granulierten Berechtigungen ist zumindest mir klar. In der Zwischenzeit werde ich PIM-Gruppen verwenden und automatisierte App-Erstellungs-Endpunkte entwickeln. Alternativ empfehle ich, dass besonders privilegierte Admins Anwendungen für ihre weniger privilegierten Kollegen erstellen. (Cloud-) App Administrator sollte nicht frei verteilt werden.


Haben Sie Gedanken zu diesen Ergebnissen oder sehen Sie etwas, das ich übersehen habe? Ich würde gerne von Ihnen hören 😊. Nehmen Sie an der Diskussion auf meinem zugehörigen LinkedIn-Beitrag.

Wenn Sie an den Dingen interessiert sind, die ich tue, folgen Sie mir auf LinkedIn.

Zuletzt bearbeitet: 17. April 2024