Freigeben über


Microsoft Entra-App-Manifest (Azure AD Graph-Format).

Das Anwendungsmanifest enthält eine Definition aller Attribute eines Anwendungsobjekts auf der Microsoft Identity Platform. Darüber hinaus dient es als Mechanismus für die Aktualisierung des Anwendungsobjekts. Weitere Informationen zur Anwendungsentität und zum zugehörigen Schema finden Sie in der Dokumentation zur Anwendungsentität der Graph-API.

Sie können die Attribute einer App über das Microsoft Entra Admin Center oder programmgesteuert mithilfe der Microsoft Graph-API oder des Microsoft Graph PowerShell SDK konfigurieren. Es gibt aber einige Szenarien, in denen Sie das App-Manifest bearbeiten müssen, um das Attribut einer App zu konfigurieren. Zu diesen Szenarien gehören:

  • Wenn Sie die App als mehrinstanzenfähige Microsoft Entra-App und für persönliche Microsoft-Konten registriert haben, können Sie die unterstützten Microsoft-Konten nicht über die Benutzeroberfläche ändern. In diesem Fall müssen Sie den unterstützten Kontotyp mithilfe des Anwendungsmanifest-Editors ändern.
  • Zum Definieren der Berechtigungen und Rollen, die von Ihrer App unterstützt werden, müssen Sie das Anwendungsmanifest ändern.

Konfigurieren des App-Manifests

Konfigurieren Sie das Anwendungsmanifest wie folgt:

  1. Melden Sie sich beim Microsoft Entra Admin Center mindestens mit der Rolle Anwendungsentwickler an.
  2. Navigieren Sie zu Identität>Anwendungen>App-Registrierungen.
  3. Wählen Sie die App aus, die Sie konfigurieren möchten.
  4. Wählen Sie im Abschnitt Verwalten der App die Option Manifest aus. Ein webbasierter Manifest-Editor wird geöffnet, mit dem Sie das Manifest bearbeiten können. Optional können Sie Herunterladen wählen, um das Manifest lokal zu bearbeiten, und dann Hochladen verwenden, um es wieder auf Ihre Anwendung anzuwenden.

Manifestreferenz

In diesem Abschnitt werden die Attribute im Anwendungsmanifest beschrieben.

id-Attribut

Schlüssel Werttyp
id String

Ein eindeutiger Bezeichner für die App im Verzeichnis. Diese ID ist nicht der Bezeichner, der verwendet wird, um die App in einer Protokolltransaktion zu bezeichnen. Dadurch können Sie in Verzeichnisabfragen auf das Objekt verweisen.

Beispiel:

    "id": "00aa00aa-bb11-cc22-dd33-44ee44ee44ee",

acceptMappedClaims-Attribut

Schlüssel Werttyp
acceptMappedClaims Nullwerte zulassender boolescher Wert

Laut Dokumentation für den apiApplicationRessourcentyp kann eine Anwendung die Anspruchszuordnung verwenden, ohne einen benutzerdefinierten Signaturschlüssel anzugeben. Anwendungen, die Token empfangen, basieren auf der Tatsache, dass die Anspruchswerte von Microsoft Entra autoritativ ausgestellt werden und nicht manipuliert werden können. Wenn Sie jedoch den Tokeninhalt durch Anspruchszuordnungsrichtlinien ändern, sind diese Annahmen möglicherweise nicht mehr korrekt. Anwendungen müssen explizit bestätigen, dass Token vom Ersteller der Anspruchszuordnungsrichtlinie geändert wurden, um sich vor Anspruchszuordnungsrichtlinien zu schützen, die von böswilligen Akteuren erstellt wurden.

Warnung

Legen Sie die acceptMappedClaims-Eigenschaft für mehrinstanzenfähige Apps nicht auf true fest. Dies kann dazu führen, dass böswillige Akteure Anspruchszuordnungsrichtlinien für Ihre App erstellen.

Beispiel:

    "acceptMappedClaims": true,

requestedAccessTokenVersion-Attribut

Schlüssel Werttyp
requestedAccessTokenVersion Nullable Int32

Gibt die Zugriffstokenversion an, die von der Ressource erwartet wird. Dieser Parameter ändert die Version und das Format des erzeugten JWT unabhängig vom Endpunkt oder Client, der zum Anfordern des Zugriffstokens verwendet wird.

Der verwendete Endpunkt, v1.0 oder v2.0, wird vom Client ausgewählt und wirkt sich nur auf die Version der ID-Token aus. Ressourcen müssen requestedAccessTokenVersion explizit konfigurieren, um das unterstützte Zugriffstokenformat anzugeben.

Mögliche Werte für requestedAccessTokenVersion sind 1, 2 oder null. Wenn der Wert null (0) ist, ist dieser Parameter standardmäßig 1. Dies entspricht dem v1.0-Endpunkt.

Wenn signInAudience auf AzureADandPersonalMicrosoftAccount festgelegt ist, muss der Wert 2 lauten.

Beispiel:

    "requestedAccessTokenVersion": 2,

addIns-Attribut

Schlüssel Werttyp
addIns Collection

Definiert ein benutzerdefiniertes Verhalten, mit dem eine App in bestimmten Kontexten von einem Verbraucherdienst aufgerufen werden kann. Beispielsweise kann für Anwendungen, die Dateidatenströme rendern können, die addIns-Eigenschaft für die Funktionalität „FileHandler“ festgelegt werden. Dieser Parameter ermöglicht Diensten wie Microsoft 365, die Anwendung im Kontext eines Dokuments aufzurufen, an dem der Benutzer arbeitet.

Beispiel:

    "addIns": [
       {
        "id": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
        "type":" FileHandler",
        "properties": [
           {
              "key": "version",
              "value": "2"
           }
        ]
       }
    ],

allowPublicClient-Attribut

Schlüssel Werttyp
allowPublicClient Boolean

Gibt den Fallbackanwendungstyp zurück. Microsoft Entra ID leitet den Anwendungstyp standardmäßig von „replyUrlsWithType“ ab. Es gibt bestimmte Szenarien, in denen Microsoft Entra ID den Client-App-Typ nicht bestimmen kann. Ein solches Szenario ist beispielsweise der ROPC-Flow, bei dem die HTTP-Anforderung ohne URL-Umleitung erfolgt. In diesen Fällen interpretiert Microsoft Entra ID den Anwendungstyp basierend auf dem Wert dieser Eigenschaft. Wird für diesen Wert TRUE verwendet, wird der Fallbackanwendungstyp als öffentlicher Client festgelegt, etwa als installierte App, die auf einem mobilen Gerät ausgeführt wird. Der Standardwert ist FALSE. Das bedeutet, dass der Fallbackanwendungstyp ein vertraulicher Client ist, etwa eine Web-App.

Beispiel:

    "allowPublicClient": false,

appId-Attribut

Schlüssel Werttyp
appId String

Gibt den eindeutigen Bezeichner für die App an, die einer App von Microsoft Entra ID zugewiesen wird.

Beispiel:

    "appId": "00001111-aaaa-2222-bbbb-3333cccc4444",

appRoles-Attribut

Schlüssel Werttyp
appRoles Collection

Gibt Auflistung der Rollen an, die von einer App deklariert werden können. Diese Rollen können Benutzern, Gruppen oder Dienstprinzipalen zugewiesen werden. Weitere Beispiele und Informationen finden Sie unter Hinzufügen von App-Rollen in Ihrer Anwendung und Empfangen der Rollen im Token.

Beispiel:

    "appRoles": [
        {
           "allowedMemberTypes": [
               "User"
           ],
           "description": "Read-only access to device information",
           "displayName": "Read Only",
           "id": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
           "isEnabled": true,
           "value": "ReadOnly"
        }
    ],

errorUrl-Attribut

Schlüssel Werttyp
errorUrl String

Nicht unterstützt.

groupMembershipClaims-Attribut

Schlüssel Werttyp
groupMembershipClaims String

Konfiguriert den in einem Benutzer- oder OAuth 2.0-Zugriffstoken ausgegebenen Anspruch groups, der von der App erwartet wird. Um dieses Attribut festzulegen, verwenden Sie einen der folgenden gültigen Zeichenfolgenwerte:

  • "None"
  • "SecurityGroup" (für Sicherheitsgruppen und Microsoft Entra Rollen)
  • "ApplicationGroup" (diese Option umfasst nur Gruppen, die der Anwendung zugewiesen sind)
  • "DirectoryRole" (ruft die Microsoft Entra Verzeichnisrollen ab, in der der Benutzer Mitglied ist)
  • "All" (ruft alle Sicherheitsgruppen, Verteilergruppen und Microsoft Entra-Verzeichnisrollen ab, in denen der angemeldete Benutzer ein Mitglied ist).

Beispiel:

    "groupMembershipClaims": "SecurityGroup",

optionalClaims-Attribut

Schlüssel Werttyp
optionalClaims String

Die optionalen Ansprüche, die im Token vom Sicherheitstokendienst für diese spezifische App zurückgegeben werden.

Apps, die sowohl persönliche Konten als auch Microsoft Entra ID unterstützen, können keine optionalen Ansprüche verwenden. Apps, die nur für Microsoft Entra ID unter Verwendung des Endpunkts v2.0 registriert sind, können jedoch die optionalen Ansprüche abrufen, die sie im Manifest angefordert haben. Weitere Informationen finden Sie unter Optionale Ansprüche.

Beispiel:

    "optionalClaims": null,

identifierUris-Attribut

Schlüssel Werttyp
identifierUris String Array

Benutzerdefinierte URIs, die eine Web-App innerhalb des zugehörigen Microsoft Entra-Mandanten oder einer überprüften kundeneigenen Domäne eindeutig identifizieren. Wenn eine Anwendung als Ressourcen-App verwendet wird, wird der identifierUri-Wert verwendet, um die Ressource eindeutig zu identifizieren und darauf zuzugreifen. Für eine öffentliche Clientanwendung kann der Wert für identifierUris nicht vorhanden sein.

Für Anwendungs-IDs auf Basis von API- oder HTTP-Schemas werden die folgenden URI-Formate unterstützt. Ersetzen Sie die Platzhalterwerte anhand der Liste, die im Anschluss an die Tabelle aufgeführt ist.

Unterstützte Anwendungs-ID
URI-Formate
URIs für Beispiel-App-IDs
api://<appId> api://00001111-aaaa-2222-bbbb-3333cccc4444
api://<tenantId>/<appId> api://aaaabbbb-0000-cccc-1111-dddd2222eeee/00001111-aaaa-2222-bbbb-3333cccc4444
api://<tenantId>/<string> api://aaaabbbb-0000-cccc-1111-dddd2222eeee/api
api://<string>/<appId> api://productapi/00001111-aaaa-2222-bbbb-3333cccc4444
https://<tenantInitialDomain>.onmicrosoft.com/<string> https://contoso.onmicrosoft.com/productsapi
https://<verifiedCustomDomain>/<string> https://contoso.com/productsapi
https://<string>.<verifiedCustomDomain> https://product.contoso.com
https://<string>.<verifiedCustomDomain>/<string> https://product.contoso.com/productsapi
  • <appId>: Die AppId-Eigenschaft (Anwendungsbezeichner) des Anwendungsobjekts.
  • <string>: Der Zeichenfolgenwert für den Host oder das API-Pfadsegment.
  • <tenantId>: Eine von Azure generierte GUID, die den Mandanten in Azure repräsentiert.
  • <tenantInitialDomain> - <tenantInitialDomain>.onmicrosoft.com, wobei <tenantInitialDomain> der anfängliche Domänenname ist, den der Mandantenersteller bei der Mandantenerstellung angegeben hat.
  • <verifiedCustomDomain> – eine überprüfte benutzerdefinierte Domäne, die für Ihren Microsoft Entra-Mandanten konfiguriert ist.

Hinweis

Wenn Sie das api:// Schema verwenden, fügen Sie direkt nach dem "api://" einen Zeichenfolgenwert hinzu. Beispiel: api://<Zeichenfolge>. Dieser Zeichenfolgenwert kann eine GUID oder eine beliebige Zeichenfolge sein. Wenn Sie einen GUID-Wert hinzufügen, muss er entweder mit der App-ID oder der Mandanten-ID übereinstimmen. Der Wert des Anwendungs-ID-URI muss für Ihren Mandanten eindeutig sein. Wenn Sie api://<tenantId> als Anwendungs-ID-URI hinzufügen, kann dieser URI in keiner anderen App verwendet werden. Es wird empfohlen, stattdessen api://<appId> oder das HTTP-Schema zu verwenden.

Wichtig

Der Wert für den Anwendungs-ID-URI darf nicht mit einem Schrägstrich (/) enden.

Beispiel:

    "identifierUris": "https://contoso.onmicrosoft.com/00001111-aaaa-2222-bbbb-3333cccc4444",

informationalUrls-Attribut

Schlüssel Werttyp
informationalUrls String

Gibt die Links zu den Nutzungsbedingungen und Datenschutzbestimmungen der App an. Die Nutzungsbedingungen und Datenschutzbestimmungen werden auf der Oberfläche für die Benutzerzustimmung angezeigt. Weitere Informationen finden Sie unter Nutzungsbedingungen und Datenschutzerklärung für registrierte Microsoft Entra-Apps.

Beispiel:

    "informationalUrls": {
        "termsOfService": "https://MyRegisteredApp/termsofservice",
        "support": "https://MyRegisteredApp/support",
        "privacy": "https://MyRegisteredApp/privacystatement",
        "marketing": "https://MyRegisteredApp/marketing"
    },

keyCredentials-Attribut

Schlüssel Werttyp
keyCredentials Collection

Enthält Verweise auf von der App zugewiesene Anmeldeinformationen, auf Zeichenfolgen basierende gemeinsame geheime Schlüssel und X.509-Zertifikate. Diese Anmeldeinformationen werden beim Anfordern von Zugriffstoken verwendet (wenn die App nicht als Ressource, sondern als Client agiert).

Beispiel:

    "keyCredentials": [
        {
           "customKeyIdentifier":null,
           "endDateTime":"2018-09-13T00:00:00Z",
           "keyId":"<guid>",
           "startDateTime":"2017-09-12T00:00:00Z",
           "type":"AsymmetricX509Cert",
           "usage":"Verify",
           "value":null
        }
    ],

knownClientApplications-Attribut

Schlüssel Werttyp
knownClientApplications String Array

Wird zur Bündelung der Zustimmung verwendet, wenn Sie eine aus zwei Teilen bestehende Lösung haben (eine Client-App und eine benutzerdefinierte Web-API-App). Wenn Sie hier die App-ID der Client-App eingeben, muss der Benutzer nur einmal seine Zustimmung zur Verwendung der Client-App geben. Microsoft Entra ID weiß, dass die Zustimmung zum Client der impliziten Zustimmung zur Web-API entspricht. Dienstprinzipale werden automatisch sowohl für den Client als auch die Web-API bereitgestellt. Die Client- und Web-API-App müssen beim selben Mandanten registriert sein.

Beispiel:

    "knownClientApplications": ["00001111-aaaa-2222-bbbb-3333cccc4444"],

logoUrl-Attribut

Schlüssel Werttyp
logoUrl String

Schreibgeschützter Wert, der auf die CDN-URL des Logos verweist, das hochgeladen wurde

Beispiel:

    "logoUrl": "https://MyRegisteredAppLogo",

logoutUrl-Attribut

Schlüssel Werttyp
logoutUrl String

Die URL zum Abmelden von der App.

Beispiel:

    "logoutUrl": "https://MyRegisteredAppLogout",

name-Attribut

Schlüssel Werttyp
name String

Der Anzeigename für die App.

Beispiel:

    "name": "MyRegisteredApp",

oauth2AllowImplicitFlow-Attribut

Schlüssel Werttyp
oauth2AllowImplicitFlow Boolean

Dieser Wert gibt an, ob die Web-App Zugriffstoken des impliziten OAuth 2.0-Flusses anfordern kann. Die Standardeinstellung ist „false“. Dieses Flag wird für browserbasierte Apps, z. B. JavaScript-basierte Single-Page-Anwendungen, verwendet. Wenn Sie weitere Informationen benötigen, geben Sie im Inhaltsverzeichnis OAuth 2.0 implicit grant flow ein, und sehen Sie sich die Themen zum impliziten Flow an. Wir raten jedoch davon ab, die Verwendung impliziter Gewährung auch in SPAs zu verwenden und empfehlen die Verwendung des Autorisierungscodeflusses mit PKCE.

Beispiel:

    "oauth2AllowImplicitFlow": false,

oauth2AllowIdTokenImplicitFlow-Attribut

Schlüssel Werttyp
oauth2AllowIdTokenImplicitFlow Boolean

Dieser Wert gibt an, ob die Web-App ID-Token des impliziten OAuth 2.0-Flusses anfordern kann. Die Standardeinstellung ist „false“. Dieses Flag wird für browserbasierte Apps, z. B. JavaScript-basierte Single-Page-Anwendungen, verwendet. Wir raten jedoch davon ab, die Verwendung impliziter Gewährung auch in SPAs zu verwenden und empfehlen die Verwendung des Autorisierungscodeflusses mit PKCE.

Beispiel:

    "oauth2AllowIdTokenImplicitFlow": false,

oauth2Permissions-Attribut

Schlüssel Werttyp
oauth2Permissions Collection

Gibt die Sammlung von OAuth 2.0-Berechtigungsbereichen an, die die Web-API-App (Ressource) für Client-Apps verfügbar macht. Diese Berechtigungsbereiche können Client-Apps im Zuge der Zustimmung gewährt werden.

Beispiel:

    "oauth2Permissions": [
       {
          "adminConsentDescription": "Allow the app to access resources on behalf of the signed-in user.",
          "adminConsentDisplayName": "Access resource1",
          "id": "<guid>",
          "isEnabled": true,
          "type": "User",
          "userConsentDescription": "Allow the app to access resource1 on your behalf.",
          "userConsentDisplayName": "Access resources",
          "value": "user_impersonation"
        }
    ],

oauth2RequiredPostResponse-Attribut

Schlüssel Werttyp
oauth2RequiredPostResponse Boolean

Gibt an, ob Microsoft Entra ID im Rahmen von OAuth 2.0-Tokenanforderungen POST-Anforderungen zulässt (im Gengensatz zu GET-Anforderungen). Beim Standartwert FALSE sind nur GET-Anforderungen zulässig.

Beispiel:

    "oauth2RequirePostResponse": false,

parentalControlSettings-Attribut

Schlüssel Werttyp
parentalControlSettings String
  • countriesBlockedForMinors gibt die Länder/Regionen an, in denen die App für Minderjährige blockiert wird.
  • legalAgeGroupRule gibt die Regel für die rechtliche Altersgruppe an, die für Benutzer der App gilt. Dieser Wert kann auf Allow, RequireConsentForPrivacyServices, RequireConsentForMinors, RequireConsentForKids oder BlockMinors festgelegt werden.

Beispiel:

    "parentalControlSettings": {
        "countriesBlockedForMinors": [],
        "legalAgeGroupRule": "Allow"
    },

passwordCredentials-Attribut

Schlüssel Werttyp
passwordCredentials Collection

Siehe Beschreibung für die keyCredentials-Eigenschaft.

Beispiel:

    "passwordCredentials": [
      {
        "customKeyIdentifier": null,
        "displayName": "Generated by App Service",
        "endDateTime": "2022-10-19T17:59:59.6521653Z",
        "hint": "Nsn",
        "keyId": "<guid>",
        "secretText": null,        
        "startDateTime":"2022-10-19T17:59:59.6521653Z"
      }
    ],

preAuthorizedApplications-Attribut

Schlüssel Werttyp
preAuthorizedApplications Collection

Listet Anwendungen und angeforderte Berechtigungen für die implizite Einwilligung auf. Ein Administrator muss seine Einwilligung zur Anwendung gegeben haben. Bei „preAuthorizedApplications“ muss der Benutzer den angeforderten Berechtigungen nicht zustimmen. Für die in „preAuthorizedApplications“ aufgelisteten Berechtigungen ist keine Benutzereinwilligung erforderlich. Weitere angeforderte Berechtigungen, die nicht in „preAuthorizedApplications“ aufgeführt sind, erfordern jedoch die Benutzereinwilligung.

Beispiel:

    "preAuthorizedApplications": [
       {
          "appId": "00001111-aaaa-2222-bbbb-3333cccc4444",
          "permissionIds": [
             "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
            ]
        }
    ],

publisherDomain-Attribut

Schlüssel Werttyp
publisherDomain String

Die überprüfte Herausgeberdomäne für die Anwendung. Schreibgeschützt.

Beispiel:

    "publisherDomain": "{tenant}.onmicrosoft.com",

replyUrlsWithType-Attribut

Schlüssel Werttyp
replyUrlsWithType Collection

Diese Eigenschaft, die mehrere Werte zulässt, enthält die Liste der registrierten „redirect_uri“-Werte, die von Microsoft Entra ID bei der Rückgabe von Token als Ziele akzeptieren. Jeder URI-Wert muss einen zugehörigen App-Typwert enthalten. Folgende Typwerte werden unterstützt:

  • Web
  • InstalledClient
  • Spa

Erfahren Sie mehr über Einschränkungen bei der Antwort-URL.

Beispiel:

    "replyUrlsWithType": [
       {
          "url": "https://localhost:4400/services/office365/redirectTarget.html",
          "type": "InstalledClient"
       }
    ],

requiredResourceAccess-Attribut

Schlüssel Werttyp
requiredResourceAccess Collection

Mit dynamischer Einwilligung steuert requiredResourceAccess die Einwilligungsoberfläche für Administratoren und Benutzer, die statische Einwilligung verwenden. Dieser Parameter steuert jedoch nicht die Oberfläche für die Benutzerzustimmung für den Allgemeinfall.

  • resourceAppId ist der eindeutige Bezeichner für die Ressource, auf die die App zugreifen muss. Dieser Wert muss mit der „appId“ identisch sein, die für die Zielressourcen-App deklariert wurde.
  • resourceAccess ist ein Array, das die OAuth 2.0-Berechtigungsbereiche und App-Rollen auflistet, welche die App für die jeweilige Ressource erfordert. Enthält die id- und type-Werte der jeweiligen Ressourcen.

Beispiel:

    "requiredResourceAccess": [
        {
            "resourceAppId": "00000002-0000-0000-c000-000000000000",
            "resourceAccess": [
                {
                    "id": "311a71cc-e848-46a1-bdf8-97ff7156d8e6",
                    "type": "Scope"
                }
            ]
        }
    ],

samlMetadataUrl-Attribut

Schlüssel Werttyp
samlMetadataUrl String

Die URL zu den SAML-Metadaten für die App.

Beispiel:

    "samlMetadataUrl": "https://MyRegisteredAppSAMLMetadata",

signInUrl-Attribut

Schlüssel Werttyp
signInUrl String

Gibt die URL zur Startseite der App an.

Beispiel:

    "signInUrl": "https://MyRegisteredApp",

signInAudience-Attribut

Schlüssel Werttyp
signInAudience String

Gibt an, welche Microsoft-Konten für die aktuelle Anwendung unterstützt werden. Diese Werte werden unterstützt:

  • AzureADMyOrg: Benutzer mit einem Geschäfts-, Schul- oder Unikonto von Microsoft im Microsoft Entra-Mandanten meiner Organisation (z. B. einzelner Mandant)
  • AzureADMultipleOrgs: Benutzer mit einem Geschäfts-, Schul- oder Unikonto von Microsoft im Microsoft Entra-Mandanten einer beliebigen Organisation (z. B. mehrere Mandanten)
  • AzureADandPersonalMicrosoftAccount: Benutzer mit einem persönlichen Microsoft-Konto oder einem Geschäfts-, Schul- oder Unikonto im Microsoft Entra-Mandanten einer beliebigen Organisation
  • PersonalMicrosoftAccount: Persönliche Konten, die für die Anmeldung bei Diensten wie Xbox und Skype verwendet werden

Beispiel:

    "signInAudience": "AzureADandPersonalMicrosoftAccount",

tags-Attribut

Schlüssel Werttyp
tags String Array

Benutzerdefinierte Zeichenfolgen, die zum Kategorisieren und Identifizieren der Anwendung verwendet werden können

Beispiel:

    "tags": [
       "ProductionApp"
    ],

Häufige Probleme

Grenzwerte für das Manifest

Ein Anwendungsmanifest verfügt über mehrere Attribute, die als Sammlungen bezeichnet werden, beispielsweise „appRoles“, „keyCredentials“, „knownClientApplications“, „identifierUris“, „redirectUris“, „requiredResourceAccess“ und „oauth2Permissions“. Im gesamten Anwendungsmanifest für jede Anwendung wurde die Gesamtanzahl von Einträgen in allen kombinierten Sammlungen auf 1200 begrenzt. Wenn Sie vorher im Anwendungsmanifest 100 Umleitungs-URIs angeben, können Sie in allen anderen kombinierten Sammlungen, aus denen das Manifest besteht, nur noch 1.100 weitere Einträge verwenden.

Hinweis

Falls Sie versuchen, dem Anwendungsmanifest mehr als 1.200 Einträge hinzuzufügen, erhalten Sie möglicherweise die Fehlermeldung Fehler beim Aktualisieren der Anwendung xxxxxx. Fehlerdetails: Die Größe des Manifests hat den Grenzwert überschritten. Verringern Sie die Anzahl der Werte, und wiederholen Sie die Anforderung.

Nicht unterstützte Attribute

Das Anwendungsmanifest stellt das Schema des zugrunde liegenden Anwendungsmodells in Microsoft Entra ID dar. Wenn sich das zugrunde liegende Schema weiterentwickelt, wird der Manifest-Editor von Zeit zu Zeit dem neuen Schema entsprechend aktualisiert. Daher können Sie feststellen, dass neue Attribute im Anwendungsmanifest angezeigt werden. In seltenen Fällen kann es vorkommen, dass Sie eine syntaktische oder semantische Änderung der vorhandenen Attribute feststellen oder dass ein zuvor vorhandenes Attribut nicht mehr unterstützt wird. Beispielsweise werden neue Attribute in App-Registrierungen angezeigt, die in der (älteren) Benutzeroberfläche „App-Registrierungen“ unter einem anderen Namen bekannt sind.

App-Registrierungen (Vorgängerversion) App-Registrierungen
availableToOtherTenants signInAudience
displayName name
errorUrl -
homepage signInUrl
objectId Id
publicClient allowPublicClient
replyUrls replyUrlsWithType

Die Beschreibung dieser Attribute finden Sie im Abschnitt Manifestreferenz.

Wenn Sie versuchen, ein zuvor heruntergeladenes Manifest hochzuladen, wird möglicherweise eine der folgenden Fehlermeldungen angezeigt. Die Ursache dieses Fehlers ist wahrscheinlich, dass der Manifest-Editor dann eine neuere Version des Schemas unterstützt, die nicht mit der übereinstimmt, die Sie hochladen möchten.

  • „Fehler beim Aktualisieren der Anwendung xxxxxx“. Fehlerdetail: Ungültiger Objektbezeichner ‚nicht definiert‘. []."
  • „Fehler beim Aktualisieren der Anwendung xxxxxx“. Fehlerdetail: Mindestens ein Eigenschaftswert ist ungültig. []."
  • „Fehler beim Aktualisieren der Anwendung xxxxxx“. Fehlerdetail: „availableToOtherTenants“ darf in dieser API-Version nicht zur Aktualisierung festgelegt werden. []."
  • „Fehler beim Aktualisieren der Anwendung xxxxxx“. Fehlerdetail: Aktualisierungen der replyUrls-Eigenschaft sind für diese Anwendung nicht zulässig. Verwenden Sie stattdessen die Eigenschaft ‚replyUrlsWithType‘. []."
  • „Fehler beim Aktualisieren der Anwendung xxxxxx“. Fehlerdetail: Es wurde ein Wert ohne einen Typnamen gefunden, und es ist kein erwarteter Typ verfügbar. Wenn das Modell angegeben wird, muss jeder Wert in der Nutzlast einen Typ haben. Dieser kann entweder in der Nutzlast oder explizit durch den Aufrufer angegeben oder implizit aus dem übergeordneten Wert abgeleitet werden. []"

Wenn eine dieser Fehlermeldungen angezeigt wird, werden folgende Aktionen empfohlen:

  1. Bearbeiten Sie die Attribute einzeln im Manifest-Editor, anstatt ein zuvor heruntergeladenes Manifest hochzuladen. In der Tabelle Manifestreferenz können Sie die Syntax und Semantik alter und neuer Attribute einsehen und damit die gewünschten Attribute bearbeiten.
  2. Wenn Sie in Ihrem Workflow die Manifeste zur späteren Verwendung im Quellrepository speichern müssen, sollten Sie ein Rebase der gespeicherten Manifeste in Ihrem Repository mit dem in der Benutzeroberfläche App-Registrierungen angezeigten Manifest ausführen.

Nächste Schritte

Bitte geben Sie uns über den folgenden Kommentarabschnitt Ihr Feedback, um uns bei der Verbesserung unserer Inhalte zu unterstützen.