{"id":638,"date":"2024-04-15T22:01:47","date_gmt":"2024-04-15T20:01:47","guid":{"rendered":"https:\/\/sparrow365.de\/?p=638"},"modified":"2024-12-24T19:33:16","modified_gmt":"2024-12-24T18:33:16","slug":"grenzerkundung-kleine-vorschau-von-entra-id-administrative-units-fuer-enterprise-apps","status":"publish","type":"post","link":"https:\/\/sparrow365.de\/index.php\/2024\/04\/15\/grenzerkundung-kleine-vorschau-von-entra-id-administrative-units-fuer-enterprise-apps\/","title":{"rendered":"Grenzerkundung: Kleine Vorschau von Entra ID Administrative Units f\u00fcr Enterprise Apps"},"content":{"rendered":"
\n

Zum Zeitpunkt des Verfassens (April 2024) unterst\u00fctzt Microsoft noch nicht, dass Enterprise Apps in Administrativen Units hinzugef\u00fcgt werden<\/em><\/strong>
\nTats\u00e4chlich 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.<\/em><\/strong><\/p>\n<\/blockquote>\n

Ich habe schon einige Artikel geschrieben, die zumindest am Rande<\/em> das Prinzip der geringsten Privilegs behandeln, daher sollte es nicht \u00fcberraschen, dass ich Administrativen Units mag. Tats\u00e4chlich mag ich sie sehr \u2013 wer mag es nicht, Berechtigungen zu entziehen, die Menschen nicht ben\u00f6tigen – aus Sicherheitsgr\u00fcnden. Nun, ich glaube nicht, dass es \u00fcberhaupt vielen in den Sinn kommt, aber darum geht es nicht.<\/em> \ud83d\ude24<\/p>\n

In meinem Artikel, in dem ich die Verwendung von Application.ReadWrite.All Applikationsrechten anprangere<\/a>, f\u00fchre ich als m\u00f6gliche L\u00f6sung ausdr\u00fccklich Administrativen Units (AUs<\/strong>) auf, die Enterprise Apps und deren App Registrations enthalten. Aber das ist nicht der einzige Ort, an dem sie sehr hilfreich w\u00e4ren. Wenn Sie Cloud App Administrator nicht bereits als Globalen Administrator behandeln, sollten Sie einen Bericht \u00fcber Ihre Enterprise Apps<\/a> erstellen und sich an folgendes erinnern: Ein Cloud App Administrator kann all diese saftigen Anwendungsberechtigungen nutzen, indem er neue App-Anmeldeinformationen erstellt.<\/p>\n

Es w\u00e4re gro\u00dfartig, wenn wir eine Gruppe aller weniger kritischen Anwendungen f\u00fcr unsere Administratoren im Tagesgesch\u00e4ft erstellen k\u00f6nnten und die Verwaltung aller<\/em> Anwendungen auf unsere vertrauensw\u00fcrdigsten Personen beschr\u00e4nken k\u00f6nnten – ohne ein l\u00e4stiges Netzwerk von Ownern oder Rollenzuweisungen zu kn\u00fcpfen…<\/p>\n

\n

Ich sage, wir sollten keine IAM-Connectoren oder Schnittstellen marke Eigenbau ben\u00f6tigen. Ich sehe euch, Mitsch\u00f6pfer von Apps, die in 2-5 Jahren legacy sein werden.<\/em> \ud83d\udc41\ufe0f <\/p>\n<\/blockquote>\n

Wie nah sind wir also dran, Zugriff auf diese Funktions\u00aderweiterung zu erhalten?<\/p>\n


<\/p>\n

Die offizielle Ansicht<\/h2>\n

Werfen wir doch zun\u00e4chst einen Blick in die offizielle Dokumentation<\/a>, um zu sehen, was wir tun k\u00f6nnen sollen<\/strong>:<\/p>\n

\"supportedAdminUnitScenarios\"<\/p>\n


<\/p>\n

Also k\u00f6nnen wir Benutzer, Gruppen und Ger\u00e4te einbeziehen, sonst nichts. Diese Einschr\u00e4nkung spiegelt sich im GUI wider, wo auch nur diese Kategorien aufgef\u00fchrt sind:<\/p>\n

\"OfferedObjectType\"<\/p>\n

Wenn wir versuchen, ein Mitglied hinzuzuf\u00fcgen, werden die verf\u00fcgbaren Objekte immer entsprechend der Kategorie gefiltert. Da Enterprise Apps also im GUI nicht verf\u00fcgbar sind und nicht explizit dokumentiert sind, ist das Aufnehmen von Apps in Admin Units unm\u00f6glich<\/strong><\/em>, richtig?<\/p>\n


<\/p>\n

Aufnehmen von Apps in Admin Units<\/h2>\n

Ich glaube nicht an GUIs.<\/p>\n

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 \u00fcber die Graph-API verf\u00fcgbar sind. Es sei denn, die Anwendung oder Funktion ist \u00e4lter als das, was sich wie ein Cut-Off-Datum von 2020 anf\u00fchlt. Aber ich schweife ab.<\/em><\/p>\n

Also – da wir wissen, dass uns die Benutzeroberfl\u00e4che nicht spielen l\u00e4sst, sehen wir uns an, was uns Graph an die Hand gibt:<\/p>\n

\n

Voraussetzungen: Ein Benutzer mit Privileged Role Administrator und eine bereits erstellte AU. Die AU-ID kann aus "Overview" abgerufen werden.<\/em><\/p>\n<\/blockquote>\n

# Ersetzen Sie die Platzhalter durch Ihre Werte\n$enterpriseAppObjectID   = "<Enterprise App Object ID>"\n$appRegistrationObjectID = "<App Registration Object ID>"\n$adminUnitID             = "<Admin Unit Object ID>"\n\n# Enterprise App und App Registration zu der Admin Unit hinzu f\u00fcgen:\n$params = @{\n    "@odata.id" = "https:\/\/graph.microsoft.com\/v1.0\/servicePrincipals\/$enterpriseAppObjectID"\n}\nInvoke-MgGraphRequest POST "https:\/\/graph.microsoft.com\/v1.0\/directory\/administrativeUnits\/$adminUnitID\/members\/`$ref" -Body $params\n\n$params = @{\n    "@odata.id" = "https:\/\/graph.microsoft.com\/v1.0\/applications\/$appRegistrationObjectID"\n}\nInvoke-MgGraphRequest POST "https:\/\/graph.microsoft.com\/v1.0\/directory\/administrativeUnits\/$adminUnitID\/members\/`$ref" -Body $params\n\n# Ergebnis anzeigen:\n$res = Invoke-MgGraphRequest GET "https:\/\/graph.microsoft.com\/v1.0\/directory\/administrativeUnits\/$adminUnitID\/members\/"\n$res.value.'@odata.type'<\/code><\/pre>\n
Et voil\u00e0: Wir haben erfolgreich die Regeln gebogen. Normalerweise gibt es Sicherheitsvorkehrungen, um sicherzustellen, dass wir nur autorisierte Elemente hinzuf\u00fcgen k\u00f6nnen. Vielleicht ist diese Funktion bald f\u00fcr eine offizielle Vorschau bereit, was uns etwas Spielraum erm\u00f6glicht?<\/p>\n
\"addedMembers\"<\/p>\n
\n
Anwendungen sind immer noch nicht in der GUI sichtbar – es gibt keine "Alle Mitglieder" Schaltfl\u00e4che \ud83d\ude09<\/p>\n<\/blockquote>\n

<\/p>\n
Application Rollen auf Admin Units beschr\u00e4nken<\/h2>\n
Anwendungsobjekte zu AUs hinzuf\u00fcgen ist allein nicht besonders n\u00fctzlich. Ohne die M\u00f6glichkeit, einfach App-Mitgliedschaften innerhalb von AUs anzuzeigen, werden Apps nicht leichter kategorisiert (daf\u00fcr haben wir custom security attributes<\/a><\/em>). Der eigentliche Wert von AUs liegt darin, gezieltere Rollenzuweisungen zu erm\u00f6glichen und das Prinzip des geringsten Privilegs zu unterst\u00fctzen, indem eingeschr\u00e4nkte Zuweisungen von "Cloud App Administrator" erm\u00f6glicht werden.<\/p>\n
Pr\u00fcfen wir zuerst, ob wir \u00fcber die GUI "Cloud App Administrator" hinzuf\u00fcgen k\u00f6nnen:<\/p>\n\n\n\n\n\n
Admin Unit Rollenverwaltungsdialog<\/th>\n"Role Hinzuf\u00fcgen" Dialog<\/th>\n<\/tr>\n<\/thead>\n
\"AdminUnitRolesOffered\"<\/td>\n\"RoleScopesOffered\"<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n
Nun, es stellt sich heraus, dass weder Hinzuf\u00fcgen der Rolle \u00fcber Privileged Identity Management (PIM) noch der AU-spezifische Rollendialog die ben\u00f6tigten Optionen bietet. Also wenden wir uns wieder unserem zuverl\u00e4ssigen Freund, der Graph-API, zu:<\/p>\n
# Hier k\u00f6nnte auch eine Enterprise-App-ID verwendet werden\n$userID = "<ID meines noch nicht privilegierten Benutzers>"\n# Wir m\u00fcssen UPNs aufl\u00f6sen, da sie nicht in Rollenzuweisungen erlaubt sind\n$userID = (Invoke-MgGraphRequest GET "https:\/\/graph.microsoft.com\/v1.0\/users\/$userID").id\n\n$params = @{\n    "@odata.type" = "#microsoft.graph.unifiedRoleAssignment"\n    roleDefinitionId = "158c047a-c907-4556-b7ef-446551a6b5f7" # Cloud Application Administrator\n    principalId = "$userID"\n    directoryScopeId = "\/administrativeUnits\/$adminUnitID"\n}\nInvoke-MgGraphRequest POST "https:\/\/graph.microsoft.com\/v1.0\/roleManagement\/directory\/roleAssignments" -Body $params<\/code><\/pre>\n
\n
Notiz am Rande: Die PIM-Benutzeroberfl\u00e4che ist flexibel genug, um diese Rollenzuweisung anzuzeigen – was das Tracking im Vergleich zum Ausf\u00fchren eines Skripts zum Abrufen aller "Owner" Zuweisungen vereinfacht.<\/p>\n
\"RoleASsignmentInUI\"<\/p>\n<\/blockquote>\n
\n
Jetzt, da wir einen Benutzer mit auf die AU beschr\u00e4nkten Berechtigungen haben, \u00fcberpr\u00fcfen 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\u00dfend f\u00fchren wir g\u00e4ngige administrative Aufgaben durch, um zu sehen, wo der Zugriff verweigert – oder f\u00e4lschlicherweise gew\u00e4hrt wird:<\/p>\n

<\/p>\n
Verwaltung von App-Eigenschaften<\/h2>\n
\n
Zur Wiederholung, wir handeln nun als AU beschr\u00e4nkter Cloud App Admin<\/strong> BiancaP f\u00fcr App Registrations und Enterprise Applications, die unserer AU hinzugef\u00fcgt wurden<\/strong>, es sei denn, es wird ausdr\u00fccklich etwas anderes angegeben!<\/p>\n<\/blockquote>\n
Die Tests auf unseren AU Apps waren in der GUI \u00fcberraschend erfolgreich. Daher macht es mehr Sinn, die aktuellen Einschr\u00e4nkungen (Stand April 2024)<\/em> zu listen:<\/p>\n
    \n
  1. Hinzuf\u00fcgen von Ownern zu Enterprise App und App Registration\n